Rustup #4203
Merged
Rustup #4203
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…er-errors
Emit dropck normalization errors in borrowck
Borrowck generally assumes that any queries it runs for type checking will succeed, thinking that HIR typeck will have errored first if there was a problem. However as of #98641, dropck isn't run on HIR, so there's no direct guarantee that it doesn't error. While a type being well-formed might be expected to ensure that its fields are well-formed, this is not the case for types containing a type projection:
```rust
pub trait AuthUser {
type Id;
}
pub trait AuthnBackend {
type User: AuthUser;
}
pub struct AuthSession<Backend: AuthnBackend> {
data: Option<<<Backend as AuthnBackend>::User as AuthUser>::Id>,
}
pub trait Authz: Sized {
type AuthnBackend: AuthnBackend<User = Self>;
}
pub fn run_query<User: Authz>(auth: AuthSession<User::AuthnBackend>) {}
// ^ No User: AuthUser bound is required or inferred.
```
While improvements to trait solving might fix this in the future, for now we go for a pragmatic solution of emitting an error from borrowck (by rerunning dropck outside of a query) and making drop elaboration check if an error has been emitted previously before panicking for a failed normalization.
Closes #103899
Closes #135039
r? `@compiler-errors` (feel free to re-assign)
interpret: adjust vtable validity check for higher-ranked types ## What Transmuting between trait objects where a generic argument or associated type only differs in bound regions (not bound at or above the trait object's binder) is now UB. For example * transmuting between `&dyn Trait<for<'a> fn(&'a u8)>` and `&dyn Trait<fn(&'static u8)>` is UB. * transmuting between `&dyn Trait<Assoc = for<'a> fn(&'a u8)>` and `&dyn Trait<Assoc = fn(&'static u8)>` is UB. * transmuting between `&dyn Trait<for<'a> fn(&'a u8) -> (&'a u8, &'static u8)>` and `&dyn Trait<for<'a> fn(&'a u8) -> (&'static u8, &'a u8)>` is UB. Transmuting between subtypes (in either direction) is still allowed, which means that bound regions that are bound at or above the trait object's binder can still be changed: * transmuting between `&dyn for<'a> Trait<fn(&'a u8)>` and `&dyn for Trait<fn(&'static u8)>` is fine. * transmuting between `&dyn for<'a> Trait<dyn Trait<fn(&'a u8)>>` and `&dyn for Trait<dyn Trait<fn(&'static u8)>>` is fine. ## Why Very similar to rust-lang/rust#120217 and rust-lang/rust#120222, changing a trait object's generic argument to a type that only differs in bound regions can still affect the vtable layout and lead to segfaults at runtime (for an example see `src/tools/miri/tests/fail/validity/dyn-transmute-inner-binder.rs`). Since we already already require that the trait object predicates must be equal modulo bound regions, it is only natural to extend this check to also require type equality considering bound regions. However, it also makes sense to allow transmutes between a type and a subtype thereof. For example `&dyn for<'a> Trait<&'a u8>` is a subtype of `&dyn Trait<&'static ()>` and they are guaranteed to have the same vtable, so it makes sense to allow this transmute. So that's why bound lifetimes that are bound to the trait object itself are treated as free lifetime for the purpose of this check. Note that codegen already relies on the property that subtyping cannot change the the vtable and this is asserted here (note the leak check): https://github.com/rust-lang/rust/blob/251206c27b619ccf3a08e2ac4c525dc343f08492/compiler/rustc_codegen_ssa/src/base.rs#L106-L153 Furthermore, we allow some pointer-to-pointer casts like `*const dyn for<'a> Trait<&'a u8>` to `*const Wrapper<dyn Trait<&'static u8>>` that instantiate the trait object binder and are currently lowered to a single pointer-to-pointer cast in MIR (`CastKind::PtrToPtr`) and *not* an unsizing coercion (`CastKind::PointerCoercion(Unsize)`), so the current MIR lowering of these would be UB if we didn't allow subtyping transmutes. --- fixes rust-lang/rust#135230 cc `@rust-lang/opsem` r? `@compiler-errors` for the implementation
…ddle Add customized compare for Link in rustdoc Maybe some other types in sidebar need to be sorted in this way, maybe add this crate `natord` is ok? r? clubby789 Fixes #137098
Restrict `bevy_ecs` `ParamSet` hack This limits the bevy WF hack to only apply to ADTs named `ParamSet` that come from crates named `bevy_ecs`, and references to the latter. Previously, we were applying it to all ADTs that contained the substring `"ParamSet"`. This could show up anywhere in the ADT name, and it could come from any crate. It's a bit concerning since other code could theoretically begin to rely on this behavior too (though I don't expect it to) This simplifies the logic a bit and turns it into a visitor. r? `@jackh726`
Make fewer crates depend on `rustc_ast_ir` I think it simplifies the crate graph and also exposes people less to confusion if downstream crates don't interact with `rustc_ast_ir` directly and instead just use its functionality reexported through more familiar paths. r? oli-obk since you introduced ast-ir
Register `USAGE_OF_TYPE_IR_INHERENT`, remove inherent usages I implemented a lint to discourage the usage of `rustc_type_ir::inherent` but never actually enabled it. People started using `rustc_type_ir::inherent` methods through globs, lol. r? fmease or reassign as you please
…errors MIR visitor tweaks Some minor improvements I found while looking at this code. r? `@tmandry`
Pattern Migration 2024: properly label `&` patterns whose subpatterns are from macro expansions See the failing test output in the first commit for an example of what this going wrong looks like. The error/lint diagnostic tries to point to just the `&` or `&mut` of reference patterns when labeling the causes, to make the output clearer (#134394). The trimming there wasn't quite right though: it used the interior of the reference pattern as a cutoff and extended backwards to find where to trim the pattern's span, but this breaks if the `&` and the interior are from different sources. This PR instead trims by starting at the start of the pattern and ending at the final character of the `&` (or `&mut`, `ref`, `ref mut`, or `mut`, depending on what the error/lint is labeling); that way, there's no opportunity for failure from mixing sources. I'm not 100% happy with this approach, but I'm also not sure what the best practices are as far as hacky `SourceMap` munching goes, so please let me know if something else would be preferred. Since `SourceMap::span_through_char` can't change the syntax context of the span, I've also removed a call to `Span::with_ctxt` (we care about the edition of the span in question since this is a hard error in Rust 2024). If we want to be extra safe in case that changes, I can re-add it or track error hardness separately in the `rust_2024_migration_desugared_pats` table.
…ors, r=tgross35 stabilize `inherent_str_constructors` fcp done in rust-lang/rust#131114 (comment). tracking issue: #131114 closes: #131114
…er-errors
Tweak "expected ident" parse error to avoid talking about doc comments
When encountering a doc comment without an identifier after, we'd unconditionally state "this doc comment doesn't document anything", swallowing the *actual* error which is that the thing *after* the doc comment wasn't expected. Added a check that the found token is something that "conceptually" closes the previous item before emitting that error, otherwise just complain about the missing identifier.
In both of the following cases, the syntax error follows a doc comment:
```
error: expected identifier, found keyword `Self`
--> $DIR/doc-before-bad-variant.rs:4:5
|
LL | enum TestEnum {
| -------- while parsing this enum
...
LL | Self,
| ^^^^ expected identifier, found keyword
|
= help: enum variants can be `Variant`, `Variant = <integer>`, `Variant(Type, ..., TypeN)` or `Variant { fields: Types }`
```
```
error: expected identifier, found `<`
--> $DIR/doc-before-syntax-error.rs:2:1
|
LL | <>
| ^ expected identifier
```
Fix #71982.
Rollup of 9 pull requests Successful merges: - #135296 (interpret: adjust vtable validity check for higher-ranked types) - #137106 (Add customized compare for Link in rustdoc) - #137253 (Restrict `bevy_ecs` `ParamSet` hack) - #137262 (Make fewer crates depend on `rustc_ast_ir`) - #137263 (Register `USAGE_OF_TYPE_IR_INHERENT`, remove inherent usages) - #137266 (MIR visitor tweaks) - #137269 (Pattern Migration 2024: properly label `&` patterns whose subpatterns are from macro expansions) - #137277 (stabilize `inherent_str_constructors`) - #137281 (Tweak "expected ident" parse error to avoid talking about doc comments) r? `@ghost` `@rustbot` modify labels: rollup
Bump sccache in CI to 0.9.1 We haven't updated the used sccache version for years, it has accrued a bunch of fixes and features in the meantime. It now supports the `--show-adv-stats` flag, which gives a more detailed summary of the results of caching. And it can also cache Rust code, which could be useful in the future (rust-lang/rust#136942 - although now there are no large wins). It also supports caching PGO now, but since the PGO profiles are always different, it won't make any real difference. rust-lang/rust#133076 previously tried to update the version to 0.3 (CC `@klensy)` r? `@marcoieni`
Emit `trunc nuw` for unchecked shifts and `to_immediate_scalar` - For shifts this shrinks the IR by no longer needing an `assume` while still providing the UB information - Having this on the `i8`→`i1` truncations will hopefully help with some places that have to load `i8`s or pass those in LLVM structs without range information
Simplify `slice::Iter::next` enough that it inlines Inspired by this zulip conversation: <https://rust-lang.zulipchat.com/#narrow/channel/189540-t-compiler.2Fwg-mir-opt/topic/Feedback.20on.20a.20MIR.20optimization.20idea/near/498579990> ~~Draft for now because it needs #136735 to get the codegen tests to pass.~~
Remove obsolete Windows ThinLTO+TLS workaround The bug #109797 has been fixed by #129079, so this workaround is no longer needed.
Remove `NtVis` and `NtTy` The next part of #124141. The first actual remove of `Nonterminal` variants. `NtVis` is a simple case that doesn't get much use, but `NtTy` is more complex. r? `@petrochenkov`
Update host LLVM to 20.1 on CI r? `@ghost`
Inject `compiler_builtins` during postprocessing and ensure it is made private Follow up of rust-lang/rust#135278 Do the following: * Inject `compiler_builtins` during postprocessing, rather than injecting `extern crate compiler_builtins as _` into the AST * Do not make dependencies of `std` private by default (this was added in #135278) * Make sure sysroot crates correctly mark their dependencies private/public * Ensure that marking a dependency private makes its dependents private by default as well, unless otherwise specified * Do the `compiler_builtins` update that has been blocked on this There is more detail in the commit messages. This includes the changes I was working on in rust-lang/rust#136226. try-job: test-various try-job: x86_64-msvc-1 try-job: x86_64-msvc-2 try-job: i686-mingw-1 try-job: i686-mingw-2
stabilize `(const_)ptr_sub_ptr` Tracking issue: #95892 Closes #95892 FCP Completed: rust-lang/rust#95892 (comment) r? ````@Noratrieb````
Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes
There are a few intertwined problems with `sym fn` operands in both inline and global asm macros.
Specifically, unlike other anon consts, they may evaluate to a type with free regions in them without actually having an item-level type annotation to give them a "proper" type. This is in contrast to named constants, which always have an item-level type annotation, or unnamed constants which are constrained by their position (e.g. a const arg in a turbofish, or a const array length).
Today, we infer the type of the operand by looking at the HIR typeck results; however, those results are region-erased, so during borrowck we ICE since we don't expect to encounter erased regions. We can't just fill this type with something like `'static`, since we may want to use real (free) regions:
```rust
fn foo<'a>() {
asm!("/* ... */", sym bar::<&'a ()>);
}
```
The first idea may be to represent `sym fn` operands using *inline* consts instead of anon consts. This makes sense, since inline consts can reference regions from the parent body (like the `'a` in the example above). However, this introduces a problem with `global_asm!`, which doesn't *have* a parent body; inline consts *must* be associated with a parent body since they are not a body owner of their own. In #116087, I attempted to fix this by using two separate `sym` operands for global and inline asm. However, this led to a lot of confusion and also some unattractive code duplication.
In this PR, I adjust the lowering of `global_asm!` so that it's lowered in a "fake" HIR body. This body contains a single expression which is `ExprKind::InlineAsm`; we don't *use* this HIR body, but it's used in typeck and borrowck so that we can properly infer and validate the the lifetimes of `sym fn` operands.
I then adjust the lowering of `sym fn` to instead be represented with a HIR expression. This is both because it's no longer necessary to represent this operand as an anon const, since it's *just* a path expression, and also more importantly to sidestep yet another ICE (rust-lang/rust#137179), which has to do with the existing code breaking an invariant of def-id creation and anon consts. Specifically, we are not allowed to synthesize a def-id for an anon const when that anon const contains expressions with def-ids whose parent is *not* that anon const. This is somewhat related to rust-lang/rust#130443 (comment), which is also a place in the compiler where synthesizing anon consts leads to def-id parenting issue.
As a side-effect, this consolidates the type checking for inline and global asm, so it allows us to simplify `InlineAsmCtxt` a bit. It also allows us to delete a bit of hacky code from anon const `type_of` which was there to detect `sym fn` operands specifically. This also could be generalized to support `const` asm operands with types with lifetimes in them. Since we specifically reject these consts today, I'm not going to change the representation of those consts (but they'd just be turned into inline consts).
r? oli-obk -- mostly b/c you're patient and also understand the breadth of the code that this touches, please reassign if you don't want to review this.
Fixes #111709
Fixes #96304
Fixes #137179
…ons, r=bjorn3,RalfJung compiler: untangle SIMD alignment assumptions There were a number of puzzling assumptions being made about SIMD types and their layout that I have corrected in this diff. These are mostly no-op edits in actual fact, but they do subtly alter a pair of checks in our invariant-checking and union layout computation that rested on those peculiar assumptions. Those unfortunately stand in the way of any further actual fixes. I submit this for review, even though it's not clearly motivated without its followups, because it should still be possible to independently conclude whether this is correct.
…f, r=Noratrieb stabilize `unsigned_is_multiple_of` tracking issue: rust-lang/rust#128101 fcp completed in: rust-lang/rust#128101 (comment) ### Public API A version of this for all the unsigned types ```rust fn is_multiple_of(lhs: u64, rhs: u64) -> bool { match rhs { // prevent division by zero 0 => lhs == 0, _ => lhs % rhs == 0, } } ```
…r=estebank Remove invalid suggestion of into_iter for extern macro Fixes #137345 #109082 is closed due to performance issue, do we have any other solution for this kind of issue?
Rollup of 6 pull requests Successful merges: - #135501 (Inject `compiler_builtins` during postprocessing and ensure it is made private) - #137121 (stabilize `(const_)ptr_sub_ptr`) - #137180 (Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes) - #137256 (compiler: untangle SIMD alignment assumptions) - #137383 (stabilize `unsigned_is_multiple_of`) - #137415 (Remove invalid suggestion of into_iter for extern macro) r? `@ghost` `@rustbot` modify labels: rollup
…u,Kobzol stabilize stage management for rustc tools rust-lang/rust#135990 got out of control due to excessive complexity. This PR aims to achieve the same goal with a simpler approach, likely through multiple smaller PRs. I will keep the other one read-only and open as a reference for future work. This work stabilizes the staging logic for `ToolRustc` programs, so you no longer need to handle build and target compilers separately in steps. Previously, most tools didn't do this correctly, which was causing the compiler to be built twice (e.g., `x test cargo --stage 1` would compile the stage 2 compiler before, but now it only compiles the stage 1 compiler). I also tried to document how we should write `ToolRustc` steps as they are quite different and require more attention than other tools. Next goal is to stabilize how stages are handled for the rustc itself. Currently, `x build --stage 1` builds the stage 1 compiler which is fine, but `x build compiler --stage 1` builds stage 2 compiler. ~~for now, r? ghost~~
Master bootstrap update https://forge.rust-lang.org/release/process.html#master-bootstrap-update-tuesday r? `@Mark-Simulacrum`
vectorcall ABI: require SSE2 According to the official docs at https://learn.microsoft.com/en-us/cpp/cpp/vectorcall, SSE2 is required for this ABI. Add a check that enforces this. I put this together with the other checks ensuring the target features required for a function are present... however, since the ABI is known pre-monomorphization, it would be possible to do this check earlier, which would have the advantage of checking even in `cargo check`. It would have the disadvantage of spreading this code in yet more places. The first commit just does a little refactoring of the mono-time ABI check to make it easier to add the new check. Cc `@workingjubilee` try-job: dist-i586-gnu-i586-i686-musl
…atrieb Misc. `rustc_codegen_ssa` cleanups 🧹 Just a bunch of stuff I found while reading the crate's code. Each commit can stand on its own. Maybe r? `@Noratrieb` because I saw you did some similar cleanups on these files a while ago? (feel free to re-assign, I'm just guessing)
intrinsics: unify rint, roundeven, nearbyint in a single round_ties_even intrinsic LLVM has three intrinsics here that all do the same thing (when used in the default FP environment). There's no reason Rust needs to copy that historically-grown mess -- let's just have one intrinsic and leave it up to the LLVM backend to decide how to lower that. Suggested by `@hanna-kruppe` in rust-lang/rust#136459; Cc `@tgross35` try-job: test-various
Add binary_format to rustc target specs Added binary format field to `TargetOptions` Fixes #135724 r? `@Noratrieb`
…tives, r=fmease Fix rustdoc test directives that were accidentally ignored 🧐 Replace "// `@"` with "//@ ", and fix the tests so they actually pass, after directives are checked. ~~Only the first commit is mandatory, other two are small drive-bys.~~
Update `compiler-builtins` to 0.1.147 Removes an ABI hack that used `<2 x i64>` to return `i128` in `xmm0` on Windows [1]. [1]: rust-lang/compiler-builtins#759 Link: rust-lang/rust#116558 Link: rust-lang/compiler-builtins#758 try-job: x86_64-mingw-1 try-job: x86_64-mingw-2
FIx `sym` -> `syn` typo in tail-expr-drop-order type opt-out The #131326 PR attempts to reduce some false positives for the `tail_expr_drop_order` lint by hard-coding some common ecosystem crate names. Specifically, I believe it attempts to opt out the drop impls from `syn` which only exist as optimizations. However, this was typo'd like "sym", which is a crate that has been [yanked](https://crates.io/crates/sym) (lol). This PR fixes that. cc `@dingxiangfei2009` `@nikomatsakis` -- did I mistake this? Was this meant to be a different crate? `@bors` rollup
…for-core-metadata, r=Kobzol bootstrap: add module docs for core:metadata Add module doc for bootstrap:core:metadata
rename sub_ptr to offset_from_unsigned i also made `byte_sub_ptr` `byte_offset_from_unsigned` fixes #137121 tracking issue #95892
avoid `compiler_for` for dist tools and force the current compiler Using `compiler_for` in dist steps was causing to install stage1 tools into the dist tarballs, which doesn't match with the stage2 compiler. Fixes rust-lang/rust#137469
Rollup of 8 pull requests Successful merges: - #136439 (Misc. `rustc_codegen_ssa` cleanups 🧹) - #136543 (intrinsics: unify rint, roundeven, nearbyint in a single round_ties_even intrinsic) - #136637 (Add binary_format to rustc target specs) - #137099 (Fix rustdoc test directives that were accidentally ignored 🧐) - #137297 (Update `compiler-builtins` to 0.1.147) - #137451 (FIx `sym` -> `syn` typo in tail-expr-drop-order type opt-out) - #137452 (bootstrap: add module docs for core:metadata) - #137483 (rename sub_ptr to offset_from_unsigned) r? `@ghost` `@rustbot` modify labels: rollup
Emit getelementptr inbounds nuw for pointer::add() Lower pointer::add (via intrinsic::offset with unsigned offset) to getelementptr inbounds nuw on LLVM versions that support it. This lets LLVM make use of the pre-condition that the offset addition does not wrap in an unsigned sense. Together with inbounds, this also implies that the offset is non-negative. Fixes rust-lang/rust#137217.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.