Add validation layer for Derefer
_Follow up work to #96549#96116#95857 #95649_
This adds validation for Derefer making sure it is always the first projection.
r? rust-lang/mir-opt
Replace `#[default_method_body_is_const]` with `#[const_trait]`
pulled out of #96077
related issues: #67792 and #92158
cc `@fee1-dead`
This is groundwork to only allowing `impl const Trait` for traits that are marked with `#[const_trait]`. This is necessary to prevent adding a new default method from becoming a breaking change (as it could be a non-const fn).
Finish bumping stage0
It looks like the last time had left some remaining cfg's -- which made me think
that the stage0 bump was actually successful. This brings us to a released 1.62
beta though.
This now brings us to cfg-clean, with the exception of check-cfg-features in bootstrap;
I'd prefer to leave that for a separate PR at this time since it's likely to be more tricky.
cc https://github.com/rust-lang/rust/pull/97147#issuecomment-1132845061
r? `@pietroalbini`
Update to rebased rustc-rayon 0.4
In rayon-rs/rayon#938, miri uncovered a race in `rustc-rayon-core` that had already been fixed in the regular `rayon-core`. I have now rebased that fork onto the latest rayon branch, and published as 0.4. I also updated `indexmap` to bump the dependency.
`Cargo.lock` changes:
Updating indexmap v1.8.0 -> v1.8.2
Updating rayon v1.5.1 -> v1.5.3
Updating rayon-core v1.9.1 -> v1.9.3
Updating rustc-rayon v0.3.2 -> v0.4.0
Updating rustc-rayon-core v0.3.2 -> v0.4.1
Try to cache region_scope_tree as a query
This PR will attempt to restore `region_scope_tree` as a query so that caching works again. It seems that `region_scope_tree` could be re-computed for nested items after all, which could explain the performance regression introduced by #95563.
cc `@Mark-Simulacrum` `@pnkfelix` I will try to trigger a perf run here.
Split dead store elimination off dest prop
This splits off a part of #96451 . I've added this in as its own pass for now, so that it actually runs, can be tested, etc. In the dest prop PR, I'll stop invoking this as its own pass, so that it doesn't get invoked twice.
r? `@tmiasko`
Add suggestion for relaxing static lifetime bounds on dyn trait impls in NLL
This PR introduces suggestions for relaxing static lifetime bounds on impls of dyn trait items for NLL similar to what is already available in lexical region diagnostics.
Fixes https://github.com/rust-lang/rust/issues/95701
r? `@estebank`
It looks like the last time had left some remaining cfg's -- which made me think
that the stage0 bump was actually successful. This brings us to a released 1.62
beta though.
Move various checks to typeck so them failing causes the typeck result to get tainted
Fixes#69487fixes#79047
cc `@RalfJung` this gets rid of the `Transmute` invalid program error variant
add a deep fast_reject routine
continues the work on #97136.
r? `@nnethercote`
Actually agree with you on the match structure 😆 let's see how that impacted perf 😅
When constructing a MIR from a THIR field expression, introduce an
additional downcast projection before accessing a field of an enum.
When rebasing a place builder on top of a captured place, account for
the fact that a single HIR enum field projection corresponds to two MIR
projection elements: a downcast element and a field element.
Lifetime variance fixes for rustc
#97287 migrates rustc to a `Ty` type that is invariant over its lifetime `'tcx`, so I need to fix a bunch of places that assume that `Ty<'a>` and `Ty<'b>` can be unified by shortening both to some common lifetime.
This is doable, since many lifetimes are already `'tcx`, so all this PR does is be a bit more explicit that elided lifetimes are actually `'tcx`.
Split out from #97287 so the compiler team can review independently.
Move the extended lifetime resolution into typeck context
Related to #15023
This PR is based on the [idea](https://github.com/rust-lang/rust/issues/15023#issuecomment-1070931433) of #15023 by `@nikomatsakis.`
This PR specifically proposes to
- Delay the resolution of scopes of rvalues to a later stage, so that enough type information is available to refine those scopes based on relationships of lifetimes.
- Highlight relevant parts that would help future reviews on the next installments of works to fully implement a solution to RFC 66.
Implement proper stability check for const impl Trait, fall back to unstable const when undeclared
Continuation of #93960
`@jhpratt` it looks to me like the test was simply not testing for the failure you were looking for? Your checks actually do the right thing for const traits?
correctly deal with user type ascriptions in pat
supersedes #93856
`thir::PatKind::AscribeUserType` previously resulted in `CanonicalUserTypeAnnotations` where the inferred type already had a subtyping relation according to `variance` to the `user_ty`.
The bug can pretty much be summarized as follows:
- during mir building
- `user_ty -> inferred_ty`: considers variance
- `StatementKind::AscribeUserType`: `inferred_ty` is the type of the place, so no variance needed
- during mir borrowck
- `user_ty -> inferred_ty`: does not consider variance
- `StatementKind::AscribeUserType`: applies variance
This mostly worked fine. The lifetimes in `inferred_ty` were only bound by its relation to `user_ty` and to the `place` of `StatementKind::AscribeUserType`, so it doesn't matter where exactly the subtyping happens.
It does however matter when having higher ranked subtying. At this point the place where the subtyping happens is forced, causing this mismatch between building and borrowck to result in unintended errors.
cc #96514 which is pretty much the same issue
r? `@nikomatsakis`
Remove `crate` visibility modifier
FCP to remove this syntax is just about complete in #53120. Once it completes, this should be merged ASAP to avoid merge conflicts.
The first two commits remove usage of the feature in this repository, while the last removes the feature itself.
Cache more queries on disk
One of the principles of incremental compilation is to allow saving results on disk to avoid recomputing them.
This PR investigates persisting a lot of queries whose result are to be saved into metadata.
Some of the queries are cheap reads from HIR, but we may also want to get rid of these reads for incremental lowering.
Rollup of 6 pull requests
Successful merges:
- #96565 (rustdoc: show implementations on `#[fundamental]` wrappers)
- #97179 (Add new lint to enforce whitespace after keywords)
- #97185 (interpret/validity: separately control checking numbers for being init and non-ptr)
- #97188 (Remove unneeded null pointer asserts in ptr2int casts)
- #97189 (Update .mailmap)
- #97192 (Say "last" instead of "rightmost" in the documentation for `std::str:rfind`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
interpret/validity: separately control checking numbers for being init and non-ptr
This lets Miri control this in a more fine-grained way.
r? `@oli-obk`
`simplify_type` improvements and cursed docs
the existing `TreatParams` enum pretty much mixes everything up. Not sure why this looked right to me in #94057
This also includes two changes which impact perf:
- `ty::Projection` with inference vars shouldn't be treated as a rigid type, even if fully normalized
- `ty::Placeholder` only unifies with itself, so actually return `Some` for them
r? `@nikomatsakis`
Rather than deferring to const eval for checking if a trait is const, we
now check up-front. This allows the error to be emitted earlier, notably
at the same time as other stability checks.
Also included in this commit is a change of the default const stability
level to UNstable. Previously, an item that was `const` but did not
explicitly state it was unstable was implicitly stable.
Prevent unwinding when `-C panic=abort` is used regardless declared ABI
Ensures that Rust code will abort with `-C panic=abort` regardless ABI used.
```rust
extern "C-unwind" {
fn may_unwind();
}
// Will be nounwind with `-C panic=abort`, despite `C-unwind` ABI.
pub unsafe extern "C-unwind" fn rust_item_that_can_unwind() {
may_unwind();
}
```
Current behaviour is that unwind will propagate through. While the current behaviour won't cause unsoundness it is inconsistent with the text reading of [RFC2945](https://rust-lang.github.io/rfcs/2945-c-unwind-abi.html).
I tweaked `fn_can_unwind` instead of tweaking `AbortUnwindingCalls` because this approach would allow Rust (non-direct) callers to also see that this function is nounwind, so it can prevent excessive landing pads generation.
For more discussions: https://rust-lang.zulipchat.com/#narrow/stream/210922-project-ffi-unwind/topic/soundness.20in.20mixed.20panic.20mode.
cc `@alexcrichton,` `@BatmanAoD`
r? `@Amanieu`
`@rustbot` label: T-compiler T-lang F-c_unwind
Change `Successors` to `impl Iterator<Item = BasicBlock>`
This PR fixes the FIXME in `compiler\rustc_middle\src\mir\mod.rs`.
This can omit several `&`, `*` or `cloned` operations on Successros' generated elements
Add a query for checking whether a function is an intrinsic.
work towards #93145
This will reduce churn when we add more ways to declare intrinsics
r? `@scottmcm`
Add EarlyBinder
Chalk has no concept of `Param` (e0ade19d13/chalk-ir/src/lib.rs (L579)) or `ReEarlyBound` (e0ade19d13/chalk-ir/src/lib.rs (L1308)). Everything is just "bound" - the equivalent of rustc's late-bound. It's not completely clear yet whether to move everything to the same time of binder in rustc or add `Param` and `ReEarlyBound` in Chalk.
Either way, tracking when we have or haven't already substituted out these in rustc can be helpful.
As a first step, I'm just adding a `EarlyBinder` newtype that is required to call `subst`. I also add a couple "transparent" `bound_*` wrappers around a couple query that are often immediately substituted.
r? `@nikomatsakis`
Initial work on Miri permissive-exposed-provenance
Rustc portion of the changes for portions of a permissive ptr-to-int model for Miri. The main changes here are changing `ptr_get_alloc` and `get_alloc_id` to return an Option, and also making ptr-to-int casts have an expose side effect.
don't encode only locally used attrs
Part of https://github.com/rust-lang/compiler-team/issues/505.
We now filter builtin attributes before encoding them in the crate metadata in case they should only be used in the local crate. To prevent accidental misuse `get_attrs` now requires the caller to state which attribute they are interested in. For places where that isn't trivially possible, I've added a method `fn get_attrs_unchecked` which I intend to remove in a followup PR.
After this pull request landed, we can then slowly move all attributes to only be used in the local crate while being certain that we don't accidentally try to access them from extern crates.
cc https://github.com/rust-lang/rust/pull/94963#issuecomment-1082924289
Remove `PartialOrd`/`Ord` impl for `PlaceRef`
This is a new attempt at #93315. It removes one usage
of the `Ord` impl for `DefId`, which should make it easier
to eventually remove that impl.
Implement a lint to warn about unused macro rules
This implements a new lint to warn about unused macro rules (arms/matchers), similar to the `unused_macros` lint added by #41907 that warns about entire macros.
```rust
macro_rules! unused_empty {
(hello) => { println!("Hello, world!") };
() => { println!("empty") }; //~ ERROR: 1st rule of macro `unused_empty` is never used
}
fn main() {
unused_empty!(hello);
}
```
Builds upon #96149 and #96156.
Fixes#73576
Gracefully fail to resolve associated items instead of `delay_span_bug`.
`codegen_fulfill_obligation` is used during instance resolution for trait items.
In case of insufficient normalization issues during MIR inlining, it caused ICEs.
It's better to gracefully refuse to resolve the associated item, and let the caller decide what to do with this.
Split from https://github.com/rust-lang/rust/pull/91743Closes#69121Closes#73021Closes#88599Closes#93008Closes#93248Closes#94680Closes#96170
r? `@oli-obk`
make sure ScalarPair enums have ScalarPair variants; add some layout sanity checks
`@eddyb` suggested that it might be reasonable for `ScalarPair` enums to simply adjust the ABI of their variants accordingly, such that the layout invariant Miri expects actually holds. This PR implements that. I should note though that I don't know much about this layout computation code and what non-Miri consumers expect from it, so tread with caution!
I also added a function to sanity-check that computed layouts are internally consistent. This helped a lot in figuring out the final shape of this PR, though I am also not 100% sure that these sanity checks are the right ones.
Cc `@oli-obk`
Fixes https://github.com/rust-lang/rust/issues/96221
Optimize switch sources representation and usage
* Avoid constructing switch sources unless necessary - switch sources are used by backward analysis with a custom switch int edge effects, but are otherwise unnecessarily computed.
* Use sparse representation of switch sources to avoid quadratic space overhead.
Some subst cleanup
Two separate things here. Both changes are useful for some refactoring I'm doing to add an "EarlyBinder" newtype. (Part of chalkification).
1) Remove `subst_spanned` and just use `subst`. It wasn't used much anyways. In practice, I think we can probably get most of the info just from the actual error message. If not, outputting logs should do the trick. (The specific line probably wouldn't help much anyways).
2) Call `.subst()` before `replace_bound_vars_with_fresh_vars` and `erase_late_bound_regions` in three places that do the opposite. I think there might have been some time in the past that the order here matter for something, but this shouldn't be the case anymore. Conceptually, it makes more sense to the of the *early bound* vars on `fn`s as "outside" the late bound vars.
Remove `#[rustc_deprecated]`
This removes `#[rustc_deprecated]` and introduces diagnostics to help users to the right direction (that being `#[deprecated]`). All uses of `#[rustc_deprecated]` have been converted. CI is expected to fail initially; this requires #95958, which includes converting `stdarch`.
I plan on following up in a short while (maybe a bootstrap cycle?) removing the diagnostics, as they're only intended to be short-term.
Switch sources are used by backward analysis with a custom switch int
edge effects, but are otherwise unnecessarily computed.
Delay the computation until we know that switch sources are indeed
required and avoid the computation otherwise.
make Size and Align debug-printing a bit more compact
In particular in `{:#?}`-mode, these take up a lot of space, so I think this is the better alternative (even though it is a bit longer in `{:?}` mode, I think it is still more readable).
We could make it even smaller by deviating further from what the actual code looks like, e.g. via something like `Size(4 bytes)`. Not sure what people would think about that?
Cc `````@oli-obk`````
Begin fixing all the broken doctests in `compiler/`
Begins to fix#95994.
All of them pass now but 24 of them I've marked with `ignore HELP (<explanation>)` (asking for help) as I'm unsure how to get them to work / if we should leave them as they are.
There are also a few that I marked `ignore` that could maybe be made to work but seem less important.
Each `ignore` has a rough "reason" for ignoring after it parentheses, with
- `(pseudo-rust)` meaning "mostly rust-like but contains foreign syntax"
- `(illustrative)` a somewhat catchall for either a fragment of rust that doesn't stand on its own (like a lone type), or abbreviated rust with ellipses and undeclared types that would get too cluttered if made compile-worthy.
- `(not-rust)` stuff that isn't rust but benefits from the syntax highlighting, like MIR.
- `(internal)` uses `rustc_*` code which would be difficult to make work with the testing setup.
Those reason notes are a bit inconsistently applied and messy though. If that's important I can go through them again and try a more principled approach. When I run `rg '```ignore \(' .` on the repo, there look to be lots of different conventions other people have used for this sort of thing. I could try unifying them all if that would be helpful.
I'm not sure if there was a better existing way to do this but I wrote my own script to help me run all the doctests and wade through the output. If that would be useful to anyone else, I put it here: https://github.com/Elliot-Roberts/rust_doctest_fixing_tool
Allow inline consts to reference generic params
Tracking issue: #76001
The RFC says that inline consts cannot reference to generic parameters (for now), same as array length expressions. And expresses that it's desirable for it to reference in-scope generics, when array length expressions gain that feature as well.
However it is possible to implement this for inline consts before doing this for all anon consts, because inline consts are only used as values and they won't be used in the type system. So we can have:
```rust
fn foo<T>() {
let x = [4i32; std::mem::size_of::<T>()]; // NOT ALLOWED (for now)
let x = const { std::mem::size_of::<T>() }; // ALLOWED with this PR!
let x = [4i32; const { std::mem::size_of::<T>() }]; // NOT ALLOWED (for now)
}
```
This would make inline consts super useful for compile-time checks and assertions:
```rust
fn assert_zst<T>() {
const { assert!(std::mem::size_of::<T>() == 0) };
}
```
This would create an error during monomorphization when `assert_zst` is instantiated with non-ZST `T`s. A error during mono might sound scary, but this is exactly what a "desugared" inline const would do:
```rust
fn assert_zst<T>() {
struct F<T>(T);
impl<T> F<T> {
const V: () = assert!(std::mem::size_of::<T>() == 0);
}
let _ = F::<T>::V;
}
```
It should also be noted that the current inline const implementation can already reference the type params via type inference, so this resolver-level restriction is not any useful either:
```rust
fn foo<T>() -> usize {
let (_, size): (PhantomData<T>, usize) = const {
const fn my_size_of<T>() -> (PhantomData<T>, usize) {
(PhantomData, std::mem::size_of::<T>())
}
my_size_of()
};
size
}
```
```@rustbot``` label: F-inline_const
Add a new Rust attribute to support embedding debugger visualizers
Implemented [this RFC](https://github.com/rust-lang/rfcs/pull/3191) to add support for embedding debugger visualizers into a PDB.
Added a new attribute `#[debugger_visualizer]` and updated the `CrateMetadata` to store debugger visualizers for crate dependencies.
RFC: https://github.com/rust-lang/rfcs/pull/3191
Cleanup `DebuggerVisualizerFile` type and other minor cleanup of queries.
Merge the queries for debugger visualizers into a single query.
Revert move of `resolve_path` to `rustc_builtin_macros`. Update dependencies in Cargo.toml for `rustc_passes`.
Respond to PR comments. Load visualizer files into opaque bytes `Vec<u8>`. Debugger visualizers for dynamically linked crates should not be embedded in the current crate.
Update the unstable book with the new feature. Add the tracking issue for the debugger_visualizer feature.
Respond to PR comments and minor cleanups.
Update `RValue::Discriminant` documentation
`RValue::Discriminant` returns zero for types without discriminant.
This guarantee is already documented for `discriminant_value`
intrinsics which is implemented in terms of `RValue::Discriminant`.
Only crate root def-ids don't have a parent, and in majority of cases the argument of `DefIdTree::parent` cannot be a crate root.
So we now panic by default in `parent` and introduce a new non-panicing function `opt_parent` for cases where the argument can be a crate root.
Same applies to `local_parent`/`opt_local_parent`.
