Std/thread: deny unsafe op in unsafe fn
Partial fix of #73904.
This encloses `unsafe` operations in `unsafe fn` in `libstd/thread`.
`@rustbot` modify labels: F-unsafe-block-in-unsafe-fn
Move from {{closure}}#0 syntax to {closure#0} for (def) path components
Part of #70334
I followed the approach described by `@eddyb` and introduced a `DefPathDataName` enum.
To preserve compatibility, in various places, I had to rely on formatting manually by calling `format!("{{{{{}}}}}", namespace)`.
My questions are:
* Do we want to convert for places to use the new naming scheme? Or shall I re-add `DefPathData::as_symbol` but renamed as `DefPathData::as_legacy_symbol` to avoid manually allocating the legacy symbols?
* Do we want to `impl Display for DisambiguatedDefPathData` to avoid manually calling `write!(s, "{{{}#{}}}", namespace, component.disambiguator)`?
* We might also want to improve naming for `DefPathDataName` and `DefPathData::get_name`
r? `@eddyb`
Rollup of 15 pull requests
Successful merges:
- #76932 (Relax promises about condition variable.)
- #76973 (Unstably allow assume intrinsic in const contexts)
- #77005 (BtreeMap: refactoring around edges)
- #77066 (Fix dest prop miscompilation around references)
- #77073 (dead_code: look at trait impls even if they don't contain items)
- #77086 (Include libunwind in the rust-src component.)
- #77097 (Make [].as_[mut_]ptr_range() (unstably) const.)
- #77106 (clarify that `changelog-seen = 1` goes to the beginning of config.toml)
- #77120 (Add `--keep-stage-std` to `x.py` for keeping only standard library artifacts)
- #77126 (Invalidate local LLVM cache less often)
- #77146 (Install std for non-host targets)
- #77155 (remove enum name from ImplSource variants)
- #77176 (Removing erroneous semicolon in transmute documentation)
- #77183 (Allow multiple allow_internal_unstable attributes)
- #77189 (Remove extra space from vec drawing)
Failed merges:
r? `@ghost`
It's possible for method resolution to pick this method over a lower
priority stable method, causing compilation errors. Since this method
is permanently unstable, give it a name that is very unlikely to be used
in user code.
Install std for non-host targets
It seems reasonable that when configuring various targets you'd expect all of them to get std installed, even if you're not building compiler toolchains for each of those.
cc #76990
r? @alexcrichton
Invalidate local LLVM cache less often
This avoids a download of LLVM after every rebase. The downside to this is that if we land some patch affecting LLVM built in CI that breaks this option, but that PR does not update the LLVM submodule, we'll likely not notice until the next update -- but this seems unlikely to happen in practice and I am not personally worried about it.
r? @alexcrichton
Add `--keep-stage-std` to `x.py` for keeping only standard library artifacts
Unlike `--keep-stage 0`, `--keep-stage-std 0` will allow the stage 0 compiler artifacts (i.e., stage1/bin/rustc) to be rebuilt if it has changed. This allows contributors to iterate on later stages of the compiler in tandem with the standard library without needing to to rebuild the entire compiler. I often run into this when working on const-checking, since I may need to add a feature gate or make a small tweak to the standard library.
Make [].as_[mut_]ptr_range() (unstably) const.
Gated behind `const_ptr_offset`, as suggested by https://github.com/rust-lang/rust/issues/65807#issuecomment-697229404
This also marks `[].as_mut_ptr()` as const, because it's used by `as_mut_ptr_range`. I gated it behind the same feature, because I figured it's not worth adding a separate tracking issue for const `as_mut_ptr`.
BtreeMap: refactoring around edges
Parts chipped off a more daring effort, that the btree benchmarks judge to be performance-neutral.
r? @Mark-Simulacrum
Relax promises about condition variable.
For quite a while now, there have been plans to at some point use parking_lot or some other more efficient implementation of mutexes and condition variables. Right now, Mutex and CondVar both Box the 'real' mutex/condvar inside, to give it a stable address. This was done because implementations like pthread and Windows critical sections may not be moved. More efficient implementations based on futexes, WaitOnAddress, Windows SRW locks, parking_lot, etc. may be moved (while not borrowed), so wouldn't need boxing.
However, not boxing them (which would be great goal to achieve), breaks a promise std currently makes about CondVar. CondVar promises to panic when used with different mutexes, to ensure consistent behaviour on all platforms. To this check, a mutex is considered 'the same' if the address of the 'real mutex' in the Box is the same. This address doesn't change when moving a `std::mutex::Mutex` object, effectively giving it an identity that survives moves of the Mutex object. If we ever switch to a non-boxed version, they no longer carry such an identity, and this check can no longer be made.
Four options:
1. Always box mutexes.
2. Add a `MutexId` similar to `ThreadId`. Making mutexes bigger, and making it hard to ever have a `const fn new` for them.
3. Making the requirement of CondVar stricter: panic if the Mutex object itself moved.
4. Making the promise of CondVar weaker: don't promise to panic.
1, 2, and 3 seem like bad options. This PR updates the documentation for 4.
Ignore ZST offsets when deciding whether to use Scalar/ScalarPair layout
This is important because Scalar/ScalarPair layout previously would not be used if any ZST had nonzero offset.
For example, before this change, only `((), u128)` would be laid out like `u128`, not `(u128, ())`.
Fixes#63244
perf: move cold path of `process_obligations` into a separate function
cc #76575
This probably won't matter too much in the long run once #69218 is merged so we may not want to merge this.
r? `@ecstatic-morse`
Fix#76803 miscompilation
Fixes#76803
Seems like it was an oversight that the discriminant value being set was not compared to the target value from the SwitchInt, as a comment says this is a requirement for the optimization to be sound.
r? `@wesleywiser` since you are probably familiar with the optimization and made #76837 to workaround the bug
