| Age | Commit message (Collapse) | Author | Lines |
|---|
|
coverage-dump: Resolve global file IDs to filenames
The coverage-dump tool, used by coverage tests, currently includes “global file ID” numbers in its dump output.
This PR adds support for parsing coverage filename information from LLVM assembly `.ll` files, and resolving those file IDs to the corresponding filename, for inclusion in dump output.
This makes dump output more informative, especially for test cases involving multiple files, and will be important for testing expansion region support in the future.
---
The bootstrap changes don't necessarily have to land at the same time (e.g. they could be deferred to after the stage0 redesign if requested), but I would prefer to land them now if possible.
|
|
r=jieyouxu,wesleywiser
Implement RFC 3503: frontmatters
Tracking issue: #136889
Supercedes #137193. This implements [RFC 3503](https://github.com/rust-lang/rfcs/blob/master/text/3503-frontmatter.md).
This might break rust-analyzer. Will look into how to fix that.
Suggestions welcome for how to improve diagnostics.
|
|
Implement `Iterator::last` for `vec::IntoIter`
Avoid iterating everything when we have random access to the last element.
|
|
Consistent trait bounds for ExtractIf Debug impls
Closes #137654. Refer to that issue for a table of the **4** different impl signatures we previously had in the standard library for Debug impls of various ExtractIf iterator types.
The one we are standardizing on is the one so far only used by `alloc::collections::linked_list::ExtractIf`, which is _no_ `F: Debug` bound, _no_ `F: FnMut` bound, only `T: Debug` bound.
This PR applies the following signature changes:
```diff
/* alloc::collections::btree_map */
pub struct ExtractIf<'a, K, V, F, A = Global>
where
- F: 'a + FnMut(&K, &mut V) -> bool,
Allocator + Clone,
impl Debug for ExtractIf<'a, K, V, F,
+ A,
>
where
K: Debug,
V: Debug,
- F: FnMut(&K, &mut V) -> bool,
+ A: Allocator + Clone,
```
```diff
/* alloc::collections::btree_set */
pub struct ExtractIf<'a, T, F, A = Global>
where
- T: 'a,
- F: 'a + FnMut(&T) -> bool,
Allocator + Clone,
impl Debug for ExtractIf<'a, T, F, A>
where
T: Debug,
- F: FnMut(&T) -> bool,
A: Allocator + Clone,
```
```diff
/* alloc::collections::linked_list */
impl Debug for ExtractIf<'a, T, F,
+ A,
>
where
T: Debug,
+ A: Allocator,
```
```diff
/* alloc::vec */
impl Debug for ExtractIf<'a, T, F, A>
where
T: Debug,
- F: Debug,
A: Allocator,
- A: Debug,
```
```diff
/* std::collections::hash_map */
pub struct ExtractIf<'a, K, V, F>
where
- F: FnMut(&K, &mut V) -> bool,
impl Debug for ExtractIf<'a, K, V, F>
where
+ K: Debug,
+ V: Debug,
- F: FnMut(&K, &mut V) -> bool,
```
```diff
/* std::collections::hash_set */
pub struct ExtractIf<'a, T, F>
where
- F: FnMut(&T) -> bool,
impl Debug for ExtractIf<'a, T, F>
where
+ T: Debug,
- F: FnMut(&T) -> bool,
```
I have made the following changes to bring these types into better alignment with one another.
- Delete `F: Debug` bounds. These are especially problematic because Rust closures do not come with a Debug impl, rendering the impl useless.
- Delete `A: Debug` bounds. Allocator parameters are unstable for now, but in the future this would become an API commitment that we do not debug-print a representation of the allocator when printing an iterator.
- Delete `F: FnMut` bounds. Requires `hashbrown` PR: https://github.com/rust-lang/hashbrown/pull/616. **API commitment:** we commit to not doing RefCell voodoo inside ExtractIf to have some way for its Debug impl (which takes &self) to call a FnMut closure, if this is even possible.
- Add `T: Debug` bounds (or `K`/`V`), even on Debug impls that do not currently make use of them, but might in the future. **Breaking change.** Must backport into Rust 1.87 (current beta) or do a de-stabilization PR in beta to delay those types by one release.
- Render using `debug_struct` + `finish_non_exhaustive`, instead of `debug_tuple`.
- Do not render the _entire_ underlying collection.
- Show a "peek" field indicating the current position of the iterator.
|
|
Fix `-Zremap-path-scope` rmeta handling
This PR fixes the conditional remapping (`-Zremap-path-scope`) of rmeta file paths ~~by using the `debuginfo` scope~~ by conditionally embedding the local path in addition to the remapped path.
Fixes https://github.com/rust-lang/rust/issues/139217
|
|
|
|
|
|
Actually printing the filenames is deferred to a subsequent commit that will
simultaneously bless all affected tests.
|
|
|
|
|
|
|
|
This also causes the coverage-dump unit tests to run in CI and `./x test` by
default.
|
|
ismailarilik:handle-potential-query-instability-lint-for-rustc-middle, r=oli-obk
Handle `rustc_middle` cases of `rustc::potential_query_instability` lint
This PR removes `#![allow(rustc::potential_query_instability)]` line from [`compiler/rustc_middle/src/lib.rs`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_middle/src/lib.rs#L29) and converts `FxHash{Map,Set}` types into `FxIndex{Map,Set}` to suppress lint errors.
A somewhat tracking issue: https://github.com/rust-lang/rust/issues/84447
r? `@compiler-errors`
|
|
Rollup of 11 pull requests
Successful merges:
- #140080 (mir-opt: Use one MirPatch in MatchBranchSimplification)
- #140115 (mir-opt: execute MatchBranchSimplification after GVN)
- #140357 (bypass linker configuration and cross target check on `x check`)
- #140374 (Resolve instance for SymFn in global/naked asm)
- #140559 (Removing rustc_type_ir in the rustc_infer codebase)
- #140605 (`fn check_opaque_type_parameter_valid` defer error)
- #140636 (implement `PanicTracker` to track `t` panics)
- #140661 (Make `-Zfixed-x18` into a target modifier)
- #140670 (calculate step duration in a panic-safe way)
- #140672 (Deeply normalize in the new solver in WF)
- #140676 (Update books)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Update books
## rust-lang/reference
9 commits in 3bf3402aea982b876eb56c87da17b0685c6461d5..387392674d74656f7cb437c05a96f0c52ea8e601
2025-05-03 21:29:09 UTC to 2025-04-22 15:25:03 UTC
- Document `let_chains` again (rust-lang/reference#1740)
- Add: orphan rule rationale. (rust-lang/reference#1755)
- Remove apologies about the Reference (rust-lang/reference#1792)
- Clean up some inline assembly examples (rust-lang/reference#1804)
- Remove StructExprTuple and StructExprUnit (rust-lang/reference#1803)
- Improve documentation of struct expressions (rust-lang/reference#1799)
- Clarify interaction of asm-goto with IBT (rust-lang/reference#1790)
- naked functions (rust-lang/reference#1689)
- Relabel grammarRailroad-Button (rust-lang/reference#1798)
## rust-lang/rust-by-example
3 commits in 0d7964d5b22cf920237ef1282d869564b4883b88..8a8918c698534547fa8a1a693cb3e7277f0bfb2f
2025-04-30 12:20:49 UTC to 2025-04-22 17:42:30 UTC
- The example is not meant to be compiled. Changed the code block ann… (rust-lang/rust-by-example#1926)
- Non-tail recursive call note in testcase_linked_list.md (rust-lang/rust-by-example#1924)
- docs: mark illustrative 'static lifetime example with `ignore` (rust-lang/rust-by-example#1923)
|
|
Deeply normalize in the new solver in WF
We need to deeply normalize types we check for well-formedness, since we only collect implied bounds from normalized signature types.
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/194
r? lcnr
|
|
calculate step duration in a panic-safe way
obvious/self-explanatory change.
Fixes #129959
|
|
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`.
|
|
implement `PanicTracker` to track `t` panics
Trying to understand panics triggered by `t` macro is very exhausting (especially on CI failures) because it doesn't provide any information about where the macro was originally invoked. This change adds that missing information when an inner call inside the `t` macro panics.
Resolves #137557
|
|
`fn check_opaque_type_parameter_valid` defer error
Will be used in #139587 to silence opaque type errors if there are other borrowck failures. I think it can be merged separately.
r? `@compiler-errors`
|
|
Removing rustc_type_ir in the rustc_infer codebase
cc #138449
This is a second refactoring of rustc_type_ir to use rustc_middle instead, this time that's for rustc_infer
|
|
Resolve instance for SymFn in global/naked asm
`Instance::expect_resolve` ensures that we're actually going from trait item -> impl item.
Fixes #140373
|
|
bypass linker configuration and cross target check on `x check`
I was going to handle this using the untracked env approach, but I realized it somehow doesn't regress https://github.com/rust-lang/rust/issues/130108 anymore...
Anyway, if it works, it works. 😄 No need to dig deeper but my guess is we moved some cache-invalidating env from these functions to others.
Fixes https://github.com/rust-lang/rust/issues/133840
try-job: aarch64-apple
|
|
mir-opt: execute MatchBranchSimplification after GVN
This can provide more opportunities for MatchBranchSimplification.
Currently, rustc does not optimize the following code into a single statement at mir-opt, and this PR fixes the first case.
```rust
pub fn match1(c: bool, v1: i32, v2: i32) -> i32 {
if c { v1 - v2 } else { v1 - v2 }
}
pub fn match2(c: bool, v1: i32) -> i32 {
if c { v1 - 1 } else { v1 - 1 }
}
```
https://rust.godbolt.org/z/Y8xPMjrfM
r? mir-opt
|
|
mir-opt: Use one MirPatch in MatchBranchSimplification
|
|
Miri subtree update
r? `@ghost`
|
|
|
|
|
|
|
|
Supercedes #137193
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Subtree update of `rust-analyzer`
r? `@ghost`
|
|
|
|
|
|
|
|
alloc_addresses: when we are running out of addresses, start reusing more aggressively
|
|
move tests that are identical between SB and TB to shared files
|
|
aggressively
|
|
|
|
|
|
Tree Borrows: Correctly handle interior mutable data in `Box`
|
|
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`
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
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.
|
|
Remove -Zunique-is-unique
|
|
Rollup of 4 pull requests
Successful merges:
- #135734 (Correct `extract_if` sample equivalent.)
- #140307 (Refactor rustc_on_unimplemented's filter parser)
- #140644 (Revert "Avoid unused clones in Cloned<I> and Copied<I>")
- #140648 (Update `compiler-builtins` to 0.1.157)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Update `compiler-builtins` to 0.1.157
Includes the following changes:
* Use runtime feature detection for fma routines on x86 [1]
Fixes: https://github.com/rust-lang/rust/issues/140452
[1]: https://github.com/rust-lang/compiler-builtins/pull/896
|
|
Revert "Avoid unused clones in Cloned<I> and Copied<I>"
Per libs decision in https://github.com/rust-lang/rust/issues/140207#issuecomment-2842996190 this reverts commit ed5f31ab01d41a01b7206eafdf97b458dc41141a (#139745)
|
|
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:
|
