fix Box::into_unique effecitvely transmuting to a raw ptr
Miri/Stacked Borrows treat `Box` specially: they assert that it is unique, and tag it appropriately. However, currently, `Box::into_inner` is not aware of that and returns a raw pointer (wrapped in a `Unique`) that carries the same tag as the box, meaning it carries a `Uniq` tag. This leads to all sorts of problems when people use the raw pointer they get out of the `Unique` type.
In the future, it'd be interesting to make `Unique` also carry some kind of uniqueness. In that case, something like this would instead be needed whenever a raw pointer is extracted from a `Unique`. However, that is out-of-scope for the current version of Stacked Borrows. So until then, this changes `into_unique` to perform a proper reference-to-raw-ptr-cast, which clears the tag.
Add specific feature gate error for const-unstable features
Before:
```
error: `impl Trait` in const fn is unstable
--> src/lib.rs:7:19
|
7 | const fn foo() -> impl T {
| ^^^^^^
error: aborting due to previous error
```
After:
```
error[E0723]: `impl Trait` in const fn is unstable (see issue #57563)
--> src/lib.rs:7:19
|
7 | const fn foo() -> impl T {
| ^^^^^^
= help: add #![feature(const_fn)] to the crate attributes to enable
error: aborting due to previous error
```
This improves the situation with https://github.com/rust-lang/rust/issues/57563. Fixes https://github.com/rust-lang/rust/issues/57544. Fixes https://github.com/rust-lang/rust/issues/54469.
r? @oli-obk
Stabilize slice_sort_by_cached_key
I was going to ask on the tracking issue (https://github.com/rust-lang/rust/issues/34447), but decided to just send this and hope for an FCP here. The method was added last March by https://github.com/rust-lang/rust/pull/48639.
Signature: https://doc.rust-lang.org/std/primitive.slice.html#method.sort_by_cached_key
```rust
impl [T] {
pub fn sort_by_cached_key<K, F>(&mut self, f: F)
where F: FnMut(&T) -> K, K: Ord;
}
```
That's an identical signature to the existing `sort_by_key`, so I think the questions are just naming, implementation, and the usual "do we want this?".
The implementation seems to have proven its use in rustc at least, which many uses: https://github.com/rust-lang/rust/search?l=Rust&q=sort_by_cached_key
(I'm asking because it's exactly what I just needed the other day:
```rust
all_positions.sort_by_cached_key(|&n|
data::CITIES.iter()
.map(|x| *metric_closure.get_edge(n, x.pos).unwrap())
.sum::<usize>()
);
```
since caching that key is a pretty obviously good idea.)
Closes#34447
rustc_mir: split qualify_consts' "value qualification" bitflags into separate computations.
Prerequisite for computing those bits through a dataflow algorithm ~~(which I might do in this PR later)~~.
This PR should not change behavior overall, other than treating `simd_shuffle*` identically to `#[rustc_args_required_const]` (maybe we should just have `#[rustc_args_required_const]` on the intrinsic imports of `simd_shuffle*`? cc @gnzlbg)
cc @oli-obk @alexreg
Rollup of 7 pull requests
Successful merges:
- #58309 (Add more profiler events)
- #58347 (Closure bounds fixes)
- #58365 (Add an option to print the status of incremental tasks / dep nodes after running them)
- #58371 (Check user type annotations for range patterns.)
- #58378 (rustc: Implement incremental "fat" LTO)
- #58407 (specify "upper camel case" in style lint)
- #58449 (Notify @topecongiro when the state of rustfmt has changed)
Failed merges:
r? @ghost
Notify @topecongiro when the state of rustfmt has changed
I would like to get notified when the state of rustfmt has changed.
Context: I am currently a leader of the rustfmt working group.
cc @nrc do you still want to get notified?
rustc: Implement incremental "fat" LTO
Currently the compiler will produce an error if both incremental
compilation and full fat LTO is requested. With recent changes and the
advent of incremental ThinLTO, however, all the hard work is already
done for us and it's actually not too bad to remove this error!
This commit updates the codegen backend to allow incremental full fat
LTO. The semantics are that the input modules to LTO are all produce
incrementally, but the final LTO step is always done unconditionally
regardless of whether the inputs changed or not. The only real
incremental win we could have here is if zero of the input modules
changed, but that's so rare it's unlikely to be worthwhile to implement
such a code path.
cc #57968
cc rust-lang/cargo#6643
Check user type annotations for range patterns.
Fixes#58299.
This PR builds on the fix from #58161 (which fixed miscompilation
caused by the introduction of `AscribeUserType` patterns for associated
constants) to start checking these patterns are well-formed for ranges
(previous fix just ignored them so that miscompilation wouldn't occur).
r? @arielb1
Closure bounds fixes
* Ensures that "nice region errors" are buffered so that they are sorted and migrated correctly.
* Propagates fewer constraints for closures (cc #58178)
* Propagate constraints from closures more precisely (#58127)
Closes#58127
r? @nikomatsakis
Add more profiler events
- Adds Start\Stop events for time spent loading incremental query results from disk.
- Adds Start\Stop events for time spent blocked waiting for queries to complete (when parallel queries are enabled).
r? @michaelwoerister
Hidden suggestion support
Add way to hide suggestion snippet window from cli output to avoid cluttered spans that don't enhance understanding.
r? @pietroalbini CC @zackmdavis
Tweak "incompatible match arms" error
- Point at the body expression of the match arm with the type error.
- Point at the prior match arms explicitly stating the evaluated type.
- Point at the entire match expr in a secondary span, instead of primary.
- For type errors in the first match arm, the cause is outside of the
match, treat as implicit block error to give a more appropriate error.
Fix#46776, fix#57206.
CC #24157, #38234.
Update the future/task API
This change updates the future and task API as discussed in the stabilization RFC at https://github.com/rust-lang/rfcs/pull/2592.
Changes:
- Replacing UnsafeWake with RawWaker and RawWakerVtable
- Removal of LocalWaker
- Removal of Arc-based Wake trait
