This issue was reported to security@rust-lang.org by Sebastien Marie following
our recent [security advisory][1]. Because `/tmp` is typically globally writable
it's possible for one user to place symlinks in `/tmp` pointing to files in
another user's directories, causing `rustc` to overwrite the contents of
innocent files by accident.
This patch instead defaults the output path here to the cwd which should avoid
this issue.
[1]: https://blog.rust-lang.org/2018/07/06/security-advisory-for-rustdoc.html
This to-be-stable attribute is equivalent to `#[lang = "oom"]`.
It is required when using the alloc crate without the std crate.
It is called by `handle_alloc_error`, which is in turned called
by "infallible" allocations APIs such as `Vec::push`.
This turned out to be important on Windows.
Calling `handle_alloc_error(Layout:🆕:<[u8; 42]>())` caused:
```
Exception thrown at 0x00007FF7C70DC399 in a.exe: 0xC0000005:
Access violation reading location 0x000000000000002A.
```
0x2A equals 42, so it looks like the `Layout::size` field of type `usize`
was interpreted as a pointer to read from.
`Box::leak` mentions that it can return a `'static` reference, but it
wasn't immediately clear to me why it doesn't always do so. This is
because of the `T: 'a` constraint needed to form a valid reference, and
in general we want to be more flexible than requiring `T: 'static`.
This patch tries to clarify the relationship between `T` and `'a`.
Add the `alloc::prelude` module
It contains the re-exports that are in `std::prelude::v1` but not in `core::prelude::v1`.
Calling it prelude is somewhat of a misnomer since (unlike those modules in `std` or `core`) its contents are never implicitly imported in modules. Rather it is intended to be used with an explicit glob import like `use alloc::prelude::*;`. However there is precedent for the same misnomer with `std::io::prelude`, for example.
This new module is unstable with the same feature name as the `alloc` care. They are proposed for stabilization together in RFC https://github.com/rust-lang/rfcs/pull/2480.
Performance improvement of Vec's swap_remove.
The old implementation *literally* swapped and then removed, which resulted in unnecessary move instructions. The new implementation does use unsafe code, but is easy to see that it is correct.
Fixes https://github.com/rust-lang/rust/issues/52150.
Don't suggest `let` bindings if they don't help with borrows
@oli-obk I have added a condition to address #52049, right now, this is on WIP because I think code change is also required on `error_reporting.rs`. Plus I need to check if any test cases fail.
I will ping you again if everything passes
r? @oli-obk
This allows them to be used in #[repr(C)] structs without warnings. Since rust-lang/rfcs#1649 and rust-lang/rust#35603 they are already documented to have "the same in-memory representation as" their corresponding primitive types. This just makes that explicit.
