Executables crash in the probestack function otherwise... I haven't debugged
much further than that.
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
Otherwise lprofGetHostName, used by the PGO generator, won't be available.
This means that PGO and coverage profiling would be restricted to systems with
uname, but that seems acceptable.
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
Stabilize the copy_closures and clone_closures features
In addition to the `Fn*` family of traits, closures now implement `Copy` (and similarly `Clone`) if all of the captures do.
Tracking issue: https://github.com/rust-lang/rust/issues/44490
Allow installing rustfmt without config.extended
This assertion was preventing `./x.py install rustfmt` if attempted
without an "extended" build configuration, but it actually builds and
installs just fine.
Remove slow HashSet during miri stack frame creation
fixes#49237
probably has a major impact on #48846
r? @michaelwoerister
cc @eddyb I know you kept telling me to use vectors instead of hash containers... Now I know why.
Fix DefKey lookup for proc-macro crates.
Add a special case for proc-macro crates for `def_key()` in the metadata decoder (like we already have for many other methods in there). In the long run, it would be preferable to get rid of the need for special casing proc-macro crates (see #49271).
Fixes https://github.com/rust-lang/rust/issues/48739 (though I wasn't able to come up with a regression test, unfortunately)
r? @eddyb
Document format_args! / Arguments<'a> behavior wrt. Display and Debug
This is a follow up PR to #49067 , this documents the behavior of `format_args!` (i.e: `Argument<'a>`) wrt. `Display` and `Debug`.
r? @steveklabnik
Stabilize termination_trait, split out termination_trait_test
For #48453.
First time contribution, so I'd really appreciate any feedback on how this PR can be better.
Not sure exactly what kind of documentation update is needed. If there is no PR to update the reference, I can try doing that this week as I have time.
Add a -Z flag for LLVM align attributes on arguments
LLVM seems to still put the assume calls in when inlining, so this probably isn't in a place where it can be turned on by default, but it's interesting to experiment with.
For example, this makes `mem::swap::<u64x8>` be 8x `vmovaps ymm` instead of 16x `vmovups xmm`, on my cpu.
rustbuild: Tweak where timing information goes
This commit tweaks where timing and step information is printed out as part of
the build, ensuring that we do it as close to the location where work happens as
possible. In rustbuild various functions may perform long blocking work as
dependencies are assembled, so if we print out timing information early on we
may accidentally time more than just the step we were intending to time!
Fix Issue #48345, is_file, is_dir, and is_symlink note mutual exclusion
The methods on the structures `fs::FileType` and `fs::Metadata` of (respectively) `is_file`, `is_dir`, and `is_symlink` had some ambiguity in documentation, where it was not noted whether files will pass those tests exclusively or not. It is now written that the tests are mutually exclusive.
Fixes#48345.
support elision in impl headers
You can now do things like:
```
impl MyTrait<'_> for &u32 { ... }
```
Each `'_` or elided lifetime is a fresh parameter. `'_` and elision are still not permitted in associated type values. (Plausibly we could support that if there is a single input lifetime.) The original lifetime elision RFC was a bit unclear on this point: [as documented here, I think this is the correct interpretation, both because it fits existing impls and it's most analogous to the behavior in fns](https://github.com/rust-lang/rust/issues/15872#issuecomment-338700138).
We do not support elision with deprecated forms:
```
impl MyTrait for std::cell::Ref<u32> { } // ERROR
```
Builds on the in-band lifetime stuff.
r? @cramertj
Fixes#15872
Lower the priority of unstable methods when picking a candidate.
Previously, when searching for the impl of a method, we do not consider the stability of the impl. This leads to lots of insta-inference-regressions due to method ambiguity when a popular name is chosen. This has happened multiple times in Rust's history e.g.
* `f64::from_bits` #40470
* `Ord::{min, max}` #42496
* `Ord::clamp` #44095 (eventually got reverted due to these breakages)
* `Iterator::flatten` #48115 (recently added)
This PR changes the probing order so that unstable items are considered last. If a stable item is found, the unstable items will not be considered (but a future-incompatible warning will still be emitted), thus allowing stable code continue to function without using qualified names.
Once the unstable feature is stabilized, the ambiguity error will still be emitted, but the user can also use newly stable std methods, while the current situation is that downstream user is forced to update the code without any immediate benefit.
(I hope that we could bring back `Ord::clamp` if this PR is merged.)
Use the same RUSTFLAGS for building and testing `bootstrap`
This avoids recompiling the whole dependency graph twice for every `./x.py test` run.
Fixes#49215
