rustbuild: Verify sha256 of downloaded tarballs
Here's a quick first pass at this.
I don't use Python often enough to claim that this is totally Pythonic. I've left off some (almost certainly unnecessary) error handling regarding opening and processing files. The whole tarball is read into memory to calculate the hash, but the file isn't *so* large so that should be fine. I don't care for the output from `raise RuntimeError`, but that's how `run()` does it so I'm following precedent.
Tested by manually changing the value of `expected`, and by modifying the tarball then forcing `rustc_out_of_date()`. Both cases tripped the error.
Closes https://github.com/rust-lang/rust/issues/32902
Fix macro hygiene bug
This fixes#32922 (EDIT: and fixes#31856), macro hygiene bugs.
It is a [breaking-change]. For example, the following would break:
```rust
fn main() {
let x = true;
macro_rules! foo { () => {
let x = 0;
macro_rules! bar { () => {x} }
let _: bool = bar!();
//^ `bar!()` used to resolve the first `x` (a bool),
//| but will now resolve to the second x (an i32).
}}
foo! {};
}
```
r? @nrc
cargotest: Put output in build directory
Right now cargotest uses `TempDir` to place output into the system temp
directory, but unfortunately this means that if the process is interrupted then
it'll leak the directory and that'll never get cleaned up. One of our bots
filled up its disk space and there were 20 cargotest directories lying around so
seems prudent to clean them up!
By putting the output in the build directory it should ensure that we don't leak
too many extra builds.
Right now cargotest uses `TempDir` to place output into the system temp
directory, but unfortunately this means that if the process is interrupted then
it'll leak the directory and that'll never get cleaned up. One of our bots
filled up its disk space and there were 20 cargotest directories lying around so
seems prudent to clean them up!
By putting the output in the build directory it should ensure that we don't leak
too many extra builds.
rustbuild: Fix handling of the bootstrap key
Bring the calculation logic in line with the makefiles and also set the
RUSTC_BOOTSTRAP_KEY environment variable to enable the bootstrap on the stable
compiler.
collections: Add slice::binary_search_by_key
This method adds to the family of `_by_key` methods, and is the
counterpart of `slice::sort_by_key`. It was mentioned on #30423 but
was not implemented at that time.
Refs #30423
Deduplicate libraries on hash instead of filename.
Removes the need for canonicalization to prevent #12459.
(Now with passing tests!)
Canonicalization breaks certain environments where the libraries are symlinks to files that don't end in .rlib (e.g. /remote/cas/$HASH).
Fix conflicting link identifiers
Caused "Errors for non-exhaustive match patterns now list up to 3 missing variants while also indicating the total number of missing variants if more than 3." to link to "libsyntax: Restrict where non-inline modules can appear (fixes#29765)"
Add rustbuild option to use Ninja for LLVM build
This change adds support for a `ninja` option in the `[llvm]` section of rustbuild's `config.toml`. When `true`, the option enables use of the Ninja build tool. Note that this change does not add support for Ninja to the old makefile based build system.
Closes https://github.com/rust-lang/rust/issues/32809
r? @alexcrichton
librustc_back: fix incorrect comment about RUST_TARGET_PATH
The path `/etc/rustc/` is not the default last entry in
RUST_TARGET_PATH. This was in RFC131 but was never implemented in rustc
so it was removed as part of #31117 and rust-lang/rfcs#1473.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Don't read past limit for in BufRead instance of Take
Similar to `Read::read`, `BufRead::fill_buf` impl of `Take` should not call `inner.fill_buf` if the limit is already reached.
don't report errors in constants at every use site
partially fixes#32842
r? @arielb1
cc @retep998
I chose this way of implementing it, because the alternative (checking if the error span is inside the constant's expressions's span) would get confusing when combined with expression generating macros.
A next step would be to re-enable the re-reporting of errors if the original erroneous constant is in another crate.
It looks like before these config variables weren't actually taken
into account. This patch should make the build system skip over the
documentation steps correctly.
Add /obj/ to .gitignore
This is the build directory our buildbots use, and right now the bots are
running `git clean -f -f -d` to remove all untracked files between runs and this
is accidentally deleting `obj`, so we're building LLVM a lot.
Hopefully this keeps the bots caching `obj` so we can clean it out manually and
leave LLVM around.
This is the build directory our buildbots use, and right now the bots are
running `git clean -f -f -d` to remove all untracked files between runs and this
is accidentally deleting `obj`, so we're building LLVM a lot.
Hopefully this keeps the bots caching `obj` so we can clean it out manually and
leave LLVM around.
Replace consider_unification_despite_ambiguity with new obligation variant
Is work towards #32730. Addresses part one of #32286. Addresses #24210 and #26046 to some degree.
r? @nikomatsakis
Do not rely on file extensions after path canonicalization.
Rustc does not recognize libraries which are symlinked to files having extension other than .rlib. The problem is that find_library_crate calls fs::canonicalize on found library paths, but then the resulting path is passed to get_metadata_section, which assumes it will end in ".rlib" if it's an rlib (from https://internals.rust-lang.org/t/is-library-path-canonicalization-worth-it/3206).
cc #29433
