Relaxed Debug constraints on {HashMap,BTreeMap}::{Keys,Values}.
I has hit by this yesterday too. 😄
And I've realised that Debug for BTreeMap::{Keys,Values} wasn't formatting just keys and values respectively, but the whole map. 🤔Fixed#41924
r? @jonhoo
rustc: Enable #[thread_local] for Windows
I think LLVM has had support for quite some time now for this, we just never got
around to testing it out and binding it. We've had some trouble landing this in
the past I believe, but it's time to try again!
This commit flags the `#[thread_local]` attribute as being available for Windows
targets and adds an implementation of `register_dtor` in the `thread::local`
module to ensure we can destroy these keys. The same functionality is
implemented in clang via a function called `__tlregdtor` (presumably provided in
some Windows runtime somewhere), but this function unfortunately does not take a
data pointer (just a thunk) which means we can't easily call it. For now
destructors are just run in the same way the Linux fallback is implemented,
which is just keeping track via a single OS-based TLS key.
I think LLVM has had support for quite some time now for this, we just never got
around to testing it out and binding it. We've had some trouble landing this in
the past I believe, but it's time to try again!
This commit flags the `#[thread_local]` attribute as being available for Windows
targets and adds an implementation of `register_dtor` in the `thread::local`
module to ensure we can destroy these keys. The same functionality is
implemented in clang via a function called `__tlregdtor` (presumably provided in
some Windows runtime somewhere), but this function unfortunately does not take a
data pointer (just a thunk) which means we can't easily call it. For now
destructors are just run in the same way the Linux fallback is implemented,
which is just keeping track via a single OS-based TLS key.
Set CXX_<target> in bootstrap
I came across this trying to cross-compile rustc for Redox. It was also mentioned in a comment on https://github.com/rust-lang/rust/pull/42206, but doesn't seem to have been corrected.
Print -Zincremental-info to stderr instead of stdout.
Fixes#42583.
The [cargo-incremental](https://github.com/nikomatsakis/cargo-incremental) tool probably does not need to be updated. It already merges stdout and stderr before parsing the compiler's output.
r? @alexcrichton
Remove most "```ignore" doc tests.
Unconditional ` ```ignore ` doc tests lead to outdated examples (e.g. https://github.com/rust-lang/rust/issues/42729#issuecomment-309346572). This PR tries to change all existing ` ```ignore ` tests into one of the following:
* Add import and declarations to ensure the code is run-pass
* If the code is not Rust, change to ` ```text `/` ```sh `/` ```json `/` ```dot `
* If the code is expected compile-fail, change to ` ```compile_fail `
* If the code is expected run-fail, change to ` ```should_panic `
* If the code can type-check but cannot link/run, change to ` ```no_run `
* Otherwise, add an explanation after the ` ```ignore `
The `--explain` handling is changed to cope with hidden lines from the error index.
Tidy is changed to reject any unexplained ` ```ignore ` and ` ```rust,ignore `.
Replaced by adding extra imports, adding hidden code (`# ...`), modifying
examples to be runnable (sorry Homura), specifying non-Rust code, and
converting to should_panic, no_run, or compile_fail.
Remaining "```ignore"s received an explanation why they are being ignored.
Print the two types in the span label for transmute errors.
Fixes#37157. I'm not entirely happy with the changes here but overall it's better in my opinion; we certainly avoid the odd language in that issue, which changes to:
```
error[E0512]: transmute called with differently sized types: <C as TypeConstructor<'a>>::T (size can vary because of <C as TypeConstructor>::T) to <C as TypeConstructor<'b>>::T (size can vary because of <C as TypeConstructor>::T)
--> test.rs:8:5
|
8 | ::std::mem::transmute(x)
| ^^^^^^^^^^^^^^^^^^^^^ transmuting between <C as TypeConstructor<'a>>::T and <C as TypeConstructor<'b>>::T
error: aborting due to previous error(s)
```
Change the for-loop desugar so the `break` does not affect type inference. Fixes#42618
Rewrite the `for` loop desugaring to avoid contaminating the inference results. Under the older desugaring, `for x in vec![] { .. }` would erroneously type-check, even though the type of `vec![]` is unconstrained. (written by @nikomatsakis)
Pass path to python from bootstrap.py to bootstrap.rs
When bootstrap is executed with python not in `$PATH`, (e. g.
`c:\Python27\python.exe x.py test`) bootstrap cannot find python
and crashes.
This commit passes path to python in `BOOTSTRAP_PYTHON` env var.
Make rustc errors colorful.
Rustbuild passes --message-format=json to Cargo to learn about the
dependencies for a given build, which then makes Cargo steal the
stderr/stdout for the compiler process, leading to non colorful output.
To avoid this, detection of stderr being a tty is added to rustbuild,
and an environment variable is used to communicate with the rustc shim.
Fixes https://github.com/rust-lang/rust/issues/42801.
r? @alexcrichton
Impl Clone for DefaultHasher
It's useful for a hasher to be `Clone`. It's also strange for any type to not be `Clone`. `DefaultHasher` is not meant to be used directly, but being in std it can be useful as a placeholder. I don't see any forward compatibility hazard if the hasher is changed since it's very rare for something to not be `Clone`.
Fixes bootstrapping with custom cargo/rustc.
config.mk is now always read when parsing the configuration to prevent
this from reoccurring in the future, hopefully.
Fixes https://github.com/rust-lang/rust/issues/42543.
r? @alexcrichton
cc @infinity0 @kyrias
Integrate jobserver support to parallel codegen
This commit integrates the `jobserver` crate into the compiler. The crate was
previously integrated in to Cargo as part of rust-lang/cargo#4110. The purpose
here is to two-fold:
* Primarily the compiler can cooperate with Cargo on parallelism. When you run
`cargo build -j4` then this'll make sure that the entire build process between
Cargo/rustc won't use more than 4 cores, whereas today you'd get 4 rustc
instances which may all try to spawn lots of threads.
* Secondarily rustc/Cargo can now integrate with a foreign GNU `make` jobserver.
This means that if you call cargo/rustc from `make` or another
jobserver-compatible implementation it'll use foreign parallelism settings
instead of creating new ones locally.
As the number of parallel codegen instances in the compiler continues to grow
over time with the advent of incremental compilation it's expected that this'll
become more of a problem, so this is intended to nip concurrent concerns in the
bud by having all the tools to cooperate!
Note that while rustc has support for itself creating a jobserver it's far more
likely that rustc will always use the jobserver configured by Cargo. Cargo today
will now set a jobserver unconditionally for rustc to use.
mark calls in the unwind path as !noinline
The unwind path is always cold, so that should not have bad performance
implications. This avoids catastrophic exponential inlining, and also
decreases the size of librustc.so by 1.5% (OTOH, the size of `libstd.so`
increased by 0.5% for some reason).
Fixes#41696.
r? @nagisa
Rustbuild passes --message-format=json to Cargo to learn about the
dependencies for a given build, which then makes Cargo steal the
stderr/stdout for the compiler process, leading to non colorful output.
To avoid this, detection of stderr being a tty is added to rustbuild,
and an environment variable is used to communicate with the rustc shim.
When bootstrap is executed with python not in `$PATH`, (e. g.
`c:\Python27\python.exe x.py test`) bootstrap cannot find python
and crashes.
This commit passes path to python in `BOOTSTRAP_PYTHON` env var.
