support duplicate entries in the opaque_type_storage
Necessary for the new solver as we may unify keys when eagerly resolving for canonical queries. See the relevant comment when instantiating query responses:
```rust
// We eagerly resolve inference variables when computing the query response.
// This can cause previously distinct opaque type keys to now be structurally equal.
//
// To handle this, we store any duplicate entries in a separate list to check them
// at the end of typeck/borrowck. We could alternatively eagerly equate the hidden
// types here. However, doing so is difficult as it may result in nested goals and
// any errors may make it harder to track the control flow for diagnostics.
if let Some(prev) = prev {
self.delegate.add_duplicate_opaque_type(key, prev, self.origin_span);
}
```
This will be far more relevant with #140497.
r? `@compiler-errors`
Rollup of 4 pull requests
Successful merges:
- #140135 (Unify sidebar buttons to use the same image)
- #140632 (add a test for issue rust-lang/rust#81317)
- #140658 (`deref_patterns`: let string and byte string literal patterns peel references and smart pointers before matching)
- #140681 (Don't ignore compiler stderr in `lib-defaults.rs`)
r? `@ghost`
`@rustbot` modify labels: rollup
`deref_patterns`: let string and byte string literal patterns peel references and smart pointers before matching
This follows up on #140028. Together, they allow using string and byte string literal patterns to match on smart pointers when `deref_patterns` is enabled. In particular, string literals can now match on `String`, subsuming the functionality of the `string_deref_patterns` feature.
More generally, this works by letting literals peel references (and smart pointers) before matching, similar to most other patterns, providing an answer to #44849. Though it's only partially implemented at this point: this doesn't yet let named const patterns peel before matching. The peeling logic is general enough to support named consts, but the typing rules for named const patterns would need adjustments to feel consistent (e.g. arrays would need rules to be usable as slices, and `const STR: &'static str` wouldn't be able to match on a `String` unless a rule was added to let it be used where a `str` is expected, similar to what #140028 did for literals).
This also allows string and byte string patterns to match on mutable references, following up on https://github.com/rust-lang/rust/pull/140028#discussion_r2053927512. Rather than forward the mutability of the scrutinee to literal patterns, I've opted to peel `&mut`s from the scrutinee. From a design point of view, this makes the behavior consistent with what would be expected from deref coercions using the methodology in the next paragraph. From a diagnostics point of view, this avoids labeling string and byte string patterns as "mutable references", which I think could be confusing. See [`byte-string-type-errors.rs`](https://github.com/rust-lang/rust/compare/master...dianne:rust:lit-deref-pats-p2?expand=1#diff-4a0dd9b164b67c706751f3c0b5762ddab08bcef05a91972beb0190c6c1cd3706) for how the diagnostics look.
At a high level, the peeling logic implemented here tries to mimic how deref coercions work for expressions: we peel references (and smart pointers) from the scrutinee until the pattern can match against it, and no more. This is primarily tested by [`const-pats-do-not-mislead-inference.rs`](https://github.com/rust-lang/rust/compare/master...dianne:rust:lit-deref-pats-p2?expand=1#diff-19afc05b8aae9a30fe4a3a8c0bc2ab2c56b58755a45cdf5c12be0d5e83c4739d). To illustrate the connection, I wasn't sure if this made sense to include in the test file, but I've translated those tests to make sure they give the same inference results as deref coercions: [(playground)](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=1869744cb9cdfed71a686990aadf9fe1). In each case, a reference to the scrutinee is coerced to have the type of the pattern (under a reference).
Tracking issue for deref patterns: #87121
r? `@oli-obk`
cc `@Nadrieril`
Be a bit more relaxed about not yet constrained infer vars in closure upvar analysis
See the writeup in `tests/ui/closures/opaque-upvar.rs`.
TL;DR is that this has to do with the fact that the recursive revealing uses, which have not yet been constrained from the defining use by the time that closure upvar inference is performed, remain as infer vars during upvar analysis. We don't really care, though, since anywhere we structurally match on a type in upvar analysis, we already call `structurally_resolve_type` right before `.kind()`, which would emit a true ambiguity error.
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/197
r? lcnr
Make `-Zfixed-x18` into a target modifier
As part of #136966, the `-Zfixed-x18` flag should be turned into a target modifier. This is a blocker to stabilization of the flag. The flag was originally added in #124655 and the MCP for its addition is [MCP#748](https://github.com/rust-lang/compiler-team/issues/748).
On some aarch64 targets, the x18 register is used as a temporary caller-saved register by default. When the `-Zfixed-x18` flag is passed, this is turned off so that the compiler doesn't use the x18 register. This allows end-users to use the x18 register for other purposes. For example, by accessing it with inline asm you can use the register as a very efficient thread-local variable. Another common use-case is to store the stack pointer needed by the shadow-call-stack sanitizer. There are also some aarch64 targets where not using x18 is the default – in those cases the flag is a no-op.
Note that this flag does not *on its own* cause an ABI mismatch. What actually causes an ABI mismatch is when you have different compilation units that *disagree* on what it should be used for. But having a CU that uses it and another CU that doesn't normally isn't enough to trigger an ABI problem. However, we still consider the flag to be a target modifier in all cases, since it is assumed that you are passing the flag because you intend to assign some other meaning to the register. Rejecting all flag mismatches even if not all are unsound is consistent with [RFC#3716](https://rust-lang.github.io/rfcs/3716-target-modifiers.html). See the headings "not all mismatches are unsound" and "cases that are not caught" for additional discussion of this.
On aarch64 targets where `-Zfixed-x18` is not a no-op, it is an error to pass `-Zsanitizer=shadow-call-stack` without also passing `-Zfixed-x18`.
Remove global `next_disambiguator` state and handle it with a `DisambiguatorState` type
This removes `Definitions.next_disambiguator` as it doesn't guarantee deterministic def paths when `create_def` is called in parallel. Instead a new `DisambiguatorState` type is passed as a mutable reference to `create_def` to help create unique def paths. `create_def` calls with distinct `DisambiguatorState` instances must ensure that that the def paths are unique without its help.
Anon associated types did rely on this global state for uniqueness and are changed to use (method they're defined in + their position in the method return type) as the `DefPathData` to ensure uniqueness. This also means that the method they're defined in appears in error messages, which is nicer.
`DefPathData::NestedStatic` is added to use for nested data inside statics instead of reusing `DefPathData::AnonConst` to avoid conflicts with those.
cc `@oli-obk`
Initial support for dynamically linked crates
This PR is an initial implementation of [rust-lang/rfcs#3435](https://github.com/rust-lang/rfcs/pull/3435) proposal.
### component 1: interface generator
Interface generator - a tool for generating a stripped version of crate source code. The interface is like a C header, where all function bodies are omitted. For example, initial crate:
```rust
#[export]
#[repr(C)]
pub struct S {
pub x: i32
}
#[export]
pub extern "C" fn foo(x: S) {
m1::bar(x);
}
pub fn bar(x: crate::S) {
// some computations
}
```
generated interface:
```rust
#[export]
#[repr(C)]
pub struct S {
pub x: i32,
}
#[export]
pub extern "C" fn foo(x: S);
pub fn bar(x: crate::S);
```
The interface generator was implemented as part of the pretty-printer. Ideally interface should only contain exportable items, but here is the first problem:
- pass for determining exportable items relies on privacy information, which is totally available only in HIR
- HIR pretty-printer uses pseudo-code(at least for attributes)
So, the interface generator was implemented in AST. This has led to the fact that non-exportable items cannot be filtered out, but I don't think this is a major issue at the moment.
To emit an interface use a new `sdylib` crate type which is basically the same as `dylib`, but it doesn't contain metadata, and also produces the interface as a second artifact. The current interface name is `lib{crate_name}.rs`.
#### Why was it decided to use a design with an auto-generated interface?
One of the main objectives of this proposal is to allow building the library and the application with different compiler versions. This requires either a metadata format compatible across rustc versions or some form of a source code. The option with a stable metadata format has not been investigated in detail, but it is not part of RFC either. Here is the the related discussion: https://github.com/rust-lang/rfcs/pull/3435#discussion_r1202872373
Original proposal suggests using the source code for the dynamic library and all its dependencies. Metadata is obtained from `cargo check`. I decided to use interface files since it is more or less compatible with the original proposal, but also allows users to hide the source code.
##### Regarding the design with interfaces
in Rust, files generally do not have a special meaning, unlike C++. A translation unit i.e. a crate is not a single file, it consists of modules. Modules, in turn, can be declared either in one file or divided into several. That's why the "interface file" isn't a very coherent concept in Rust. I would like to avoid adding an additional level of complexity for users until it is proven necessary. Therefore, the initial plan was to make the interfaces completely invisible to users i. e. make them auto-generated. I also planned to put them in the dylib, but this has not been done yet. (since the PR is already big enough, I decided to postpone it)
There is one concern, though, which has not yet been investigated(https://github.com/rust-lang/rust/pull/134767#issuecomment-2736471828):
> Compiling the interface as pretty-printed source code doesn't use correct macro hygiene (mostly relevant to macros 2.0, stable macros do not affect item hygiene). I don't have much hope for encoding hygiene data in any stable way, we should rather support a way for the interface file to be provided manually, instead of being auto-generated, if there are any non-trivial requirements.
### component 2: crate loader
When building dynamic dependencies, the crate loader searches for the interface in the file system, builds the interface without codegen and loads it's metadata. Routing rules for interface files are almost the same as for `rlibs` and `dylibs`. Firstly, the compiler checks `extern` options and then tries to deduce the path himself.
Here are the code and commands that corresponds to the compilation process:
```rust
// simple-lib.rs
#![crate_type = "sdylib"]
#[extern]
pub extern "C" fn foo() -> i32 {
42
}
```
```rust
// app.rs
extern crate simple_lib;
fn main() {
assert!(simple_lib::foo(), 42);
}
```
```
// Generate interface, build library.
rustc +toolchain1 lib.rs
// Build app. Perhaps with a different compiler version.
rustc +toolchain2 app.rs -L.
```
P.S. The interface name/format and rules for file system routing can be changed further.
### component 3: exportable items collector
Query for collecting exportable items. Which items are exportable is defined [here](https://github.com/m-ou-se/rfcs/blob/export/text/0000-export.md#the-export-attribute) .
### component 4: "stable" mangling scheme
The mangling scheme proposed in the RFC consists of two parts: a mangled item path and a hash of the signature.
#### mangled item path
For the first part of the symbol it has been decided to reuse the `v0` mangling scheme as it much less dependent on compiler internals compared to the `legacy` scheme.
The exception is disambiguators (https://doc.rust-lang.org/rustc/symbol-mangling/v0.html#disambiguator):
For example, during symbol mangling rustc uses a special index to distinguish between two impls of the same type in the same module(See `DisambiguatedDefPathData`). The calculation of this index may depend on private items, but private items should not affect the ABI. Example:
```rust
#[export]
#[repr(C)]
pub struct S<T>(pub T);
struct S1;
pub struct S2;
impl S<S1> {
extern "C" fn foo() -> i32 {
1
}
}
#[export]
impl S<S2> {
// Different symbol names can be generated for this item
// when compiling the interface and source code.
pub extern "C" fn foo() -> i32 {
2
}
}
```
In order to make disambiguation independent of the compiler version we can assign an id to each impl according to their relative order in the source code.
The second example is `StableCrateId` which is used to disambiguate different crates. `StableCrateId` consists of crate name, `-Cmetadata` arguments and compiler version. At the moment, I have decided to keep only the crate name, but a more consistent approach to crate disambiguation could be added in the future.
Actually, there are more cases where such disambiguation can be used. For instance, when mangling internal rustc symbols, but it also hasn't been investigated in detail yet.
#### hash of the signature
Exportable functions from stable dylibs can be called from safe code. In order to provide type safety, 128 bit hash with relevant type information is appended to the symbol ([description from RFC](https://github.com/m-ou-se/rfcs/blob/export/text/0000-export.md#name-mangling-and-safety)). For now, it includes:
- hash of the type name for primitive types
- for ADT types with public fields the implementation follows [this](https://github.com/m-ou-se/rfcs/blob/export/text/0000-export.md#types-with-public-fields) rules
`#[export(unsafe_stable_abi = "hash")]` syntax for ADT types with private fields is not yet implemented.
Type safety is a subtle thing here. I used the approach from RFC, but there is the ongoing research project about it. [https://rust-lang.github.io/rust-project-goals/2025h1/safe-linking.html](https://rust-lang.github.io/rust-project-goals/2025h1/safe-linking.html)
### Unresolved questions
Interfaces:
1. Move the interface generator to HIR and add an exportable items filter.
2. Compatibility of auto-generated interfaces and macro hygiene.
3. There is an open issue with interface files compilation: https://github.com/rust-lang/rust/pull/134767#issuecomment-2736471828
4. Put an interface into a dylib.
Mangling scheme:
1. Which information is required to ensure type safety and how should it be encoded? ([https://rust-lang.github.io/rust-project-goals/2025h1/safe-linking.html](https://rust-lang.github.io/rust-project-goals/2025h1/safe-linking.html))
2. Determine all other possible cases, where path disambiguation is used. Make it compiler independent.
We also need a semi-stable API to represent types. For example, the order of fields in the `VariantDef` must be stable. Or a semi-stable representation for AST, which ensures that the order of the items in the code is preserved.
There are some others, mentioned in the proposal.
Refactor rustc_on_unimplemented's filter parser
Followup to https://github.com/rust-lang/rust/pull/139091; I plan on moving most of this code into `rustc_attr_parsing` at some point, but want to land this separately first.
I have taken care to preserve the original behavior as much as I could:
- All but one of the new error variants are replacements for the ones originally emitted by the cfg parsing machinery; so these errors are not "new".
- the `InvalidFlag` variant is new, this PR turns this (from being ignored and silently doing nothing) into an error:
```rust
#[rustc_on_unimplemented(on(something, message = "y"))]
//~^ ERROR invalid boolean flag
//~^^ NOTE expected one of `crate_local`, `direct` or `from_desugaring`, not `something`
trait InvalidFlag {}
```
This does not occur anywhere except in this test. I couldn't find a way that I liked to keep allowing this or to do nothing, erroring was the cleanest solution.
- There are a bunch of FIXME throughout this and the previous PR, I plan on addressing those in follow up prs..
Finally, this gets rid of the "longest" dependency in rustc:
Rollup of 6 pull requests
Successful merges:
- #137280 (stabilize ptr::swap_nonoverlapping in const)
- #140457 (Use target-cpu=z13 on s390x codegen const vector test)
- #140619 (Small adjustments to `check_attribute_safety` to make the logic more obvious)
- #140625 (Suggest `retain_mut` over `retain` as `Vec::extract_if` alternative)
- #140627 (Allow linking rustc and rustdoc against the same single tracing crate)
- #140630 (Async drop source info fix for proxy-drop-coroutine)
r? `@ghost`
`@rustbot` modify labels: rollup
stabilize ptr::swap_nonoverlapping in const
Closes https://github.com/rust-lang/rust/issues/133668
The blocking issue mentioned there is resolved by documentation. We may in the future actually support such code, but that is blocked on https://github.com/rust-lang/const-eval/issues/72 which is non-trivial to implement. Meanwhile, this completes stabilization of all `const fn` in `ptr`. :)
Here's a version of the problematic example to play around with:
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=6c390452379fb593e109b8f8ee854d2a
Should be FCP'd with both `@rust-lang/libs-api` and `@rust-lang/lang` since `swap_nonoverlapping` is documented to work as an "untyped" operation but due to the limitation mentioned above, that's not entirely true during const evaluation. I expect this limitation will only be hit in niche corner cases, so the benefits of having this function work most of the time outweigh the downsides of users running into this problem. (Note that unsafe code could already hit this limitation before this PR by doing cursed pointer casts, but having it hidden inside `swap_nonoverlapping` feels a bit different.)
compiletest: Support matching on non-json lines in compiler output
and migrate most of remaining `error-pattern`s to it.
Such diagnostics use a new diagnostic kind `RAW`.
Also emit an error for `error-pattern`s that can be replaced with line annotations.
Also remove a number of conditions to check both line annotations and `error-pattern`s in more cases.
Also respect `//@ check-stdout` when collecting "actual errors" for comparing against line annotations.
(A couple of tiny refactorings is also included.)
Continuation of https://github.com/rust-lang/rust/pull/139760.
r? `@jieyouxu`
Don't name variables from external macros in borrow errors.
This came up as part of the expansion of format_args. However, it's a more general problem (and now solution).
I noticed that this does change another test, moving out of fields in derives on packed struct. However, I think this is a better error simply because it used to refer to `other.0` which is an implementation detail which doesn't really make sense.
cc `@m-ou-se`
compiletest: Do not require annotations on empty labels and suggestions
Unlike other empty diagnostics, empty labels (only underlining spans) and empty suggestions (suggestions to remove something) are quite usual and do not require any special attention and annotations.
This effectively reverts a part of https://github.com/rust-lang/rust/pull/139485.
r? `@jieyouxu`
Rollup of 7 pull requests
Successful merges:
- #139675 (Add the AVX10 target features)
- #140286 (Check if format argument is identifier to avoid error err-emit)
- #140456 (Fix test simd/extract-insert-dyn on s390x)
- #140551 (Move some tests out of tests/ui)
- #140588 (Adjust some ui tests re. target-dependent errors)
- #140617 (Report the `unsafe_attr_outside_unsafe` lint at the closest node)
- #140626 (allow `#[rustfmt::skip]` in combination with `#[naked]`)
r? `@ghost`
`@rustbot` modify labels: rollup
allow `#[rustfmt::skip]` in combination with `#[naked]`
fixes https://github.com/rust-lang/rust/issues/140623
We very deliberately use an allowlist to prevent weird interactions with `#[naked]`, hopefully we've now found all of the useful combinations.
cc `@Amanieu`
Report the `unsafe_attr_outside_unsafe` lint at the closest node
This PR have `AstValidation` track a linting node id and then uses it when reporting the `unsafe_attr_outside_unsafe` lint, so that instead of being bound at the crate-root, `#[allow]` of the lint works at any node.
Fixesrust-lang/rust#140602
r? `@jieyouxu`
Adjust some ui tests re. target-dependent errors
Alternatives to optional error annotations in #140586:
- Continue to ignore target-dependent additional errors in `tests/ui/panic-runtime/{two-panic-runtimes.rs,tests/ui/panic-runtime/want-abort-got-unwind.rs,tests/ui/panic-runtime/want-abort-got-unwind2.rs}` -- but explain why some targets have more errors than others.
- Use `-Cpanic=abort` for `tests/ui/cfg/cfg_false_no_std-2.rs`. In that test, the panic strategy does not matter w.r.t. test intention.
- Adjust FIXMEs in `tests/ui/debuginfo/debuginfo-type-name-layout-ice-94961-2.rs` to track it in #140620.
---
try-job: armhf-gnu
try-job: test-various
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: x86_64-mingw-1
try-job: aarch64-apple
try-job: x86_64-apple-1
Check if format argument is identifier to avoid error err-emit
Fixes#139104
When `argument` is not an identifier, it should not be considered a field access. I checked this and if not emit an invalid format string error. I think we could do with a little finer error handling, I'll open an issue to track this down later.
The first commit submits the ui test, the second commits the code and the changes to the test output.
r? compiler
Add the AVX10 target features
Parent #138843
Adds the `avx10_target_feature` feature gate, and `avx10.1` and `avx10.2` target features.
It is confirmed that Intel is dropping AVX10/256 (see [this comment](https://github.com/rust-lang/rust/issues/111137#issuecomment-2795442288)), so this should be safe to implement now.
The LLVM fix for llvm/llvm-project#135394 was merged, and has been backported to LLVM20, and the patch has also been propagated to rustc in #140502
`@rustbot` label O-x86_64 O-x86_32 A-target-feature A-SIMD
Set groundwork for proper const normalization
r? lcnr
Updates a lot of our normalization/alias infrastructure to be setup to handle mgca aliases and normalization once const items are represented more like aliases than bodies. Inherent associated consts are still super busted, I didn't update the assertions that IACs the right arg setup because that winds up being somewhat involved to do *before* proper support for normalizing const aliases is implemented.
I dont *intend* for this to have any effect on stable. We continue normalizing via ctfe on stable and the codepaths in `project` for consts should only be reachable with mgca or ace.
