Warn windows-gnu users that the bundled gcc can't compile
Add a `DO NOT USE THIS gcc.exe FOR COMPILATION.txt` file to `lib\rustlib\*-pc-windows-gnu\bin` folders in `windows-gnu` installations in order to warn against attempting to use the bundled `gcc.exe` as a C compiler. I'm pretty sure that location is usually found manually, so this should be easily noticeable.
This mistake has been made plenty of times and has lead to misunderstandings:
Rust: [Bundled gcc (windows x64) is unable to build any c file](https://github.com/rust-lang/rust/issues/24418)
gtk-rs: [Compiling on windows](https://github.com/gtk-rs/gtk/issues/625)
bzip2-rs: [Build failure at gcc level: blocksort.c not found](https://github.com/alexcrichton/bzip2-rs/issues/30)
Alternatives: rename the bundled `gcc.exe` to e.g. `rustc-gcc.exe` or `gcc-linker.exe`. This might require a more comprehensive change or break crates already using it as a linker.
r? @alexcrichton
Store scalar pair bools as i8 in memory
We represent `bool` as `i1` in a `ScalarPair`, unlike other aggregates,
to optimize IR for checked operators and the like. With this patch, we
still do so when the pair is an immediate value, but we use the `i8`
memory type when the value is loaded or stored as an LLVM aggregate.
So `(bool, bool)` looks like an `{ i1, i1 }` immediate, but `{ i8, i8 }`
in memory. When a pair is a direct function argument, `PassMode::Pair`,
it is still passed using the immediate `i1` type, but as a return value
it will use the `i8` memory type. Also, `bool`-like` enum tags will now
use scalar pairs when possible, where they were previously excluded due
to optimization issues.
Fixes#51516.
Closes#51566.
r? @eddyb
cc @nox
Haiku: work around the lack of setrlimit
The default Unix codepath fails, because Haiku does not implement
setrlimit for stack size. Thus we create an additional path.
By default, Haiku has the desired 16 MB stack, therefore in general
we do not have to spawn a new thread. The code has been written in
such a way that any changes in Haiku or in Rust will be adapted to.
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.
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.
clarify why we're suggesting removing semicolon after braced items
Previously (issue #46186, pull-request #46258), a suggestion was added
to remove the semicolon after we fail to parse an item, but issue #51603
complains that it's still insufficiently obvious why. Let's add a note.
Resolves#51603.
Mostly fix metadata_only backend and extract some code out of rustc_codegen_llvm
Removes dependency on the `ar` crate and removes the `llvm.enabled` config option in favour of setting `rust.codegen-backends` to `[]`.
