debuginfo/macro-stepping test: extend comments
Those `#locN` markers look like they are debuginfo compiletest magic (since `#break` is debuginfo compiletest magic). However, they are actually just magic strings used by the `check` commands in the test itself. This threw me off when I looked at the test (prompted by a CI failure), so let's leave a comment for the next poor soul that ends up lost in this test.
Also, for some reason the lldb instructions do not check for `#loc6`, unlike the gdb instructions. I do not know of an lldb version that actually makes the test pass (do we even run it with lldb at all on CI?), so I won't try to add a check for loc6, but let's at least add a comment to increase the chance that someone more knowledgeable about lldb and our test suite notices this in the future.
Compute jump threading opportunities in a single pass
The current implementation of jump threading walks MIR CFG backwards from each `SwitchInt` terminator. This PR replaces this by a single postorder traversal of MIR. In theory, we could do a full fixpoint dataflow analysis, but this has low returns as we forbid threading through a loop header.
The second commit in this PR modifies the carried state to a lighter data structure. The current implementation uses some kind of `IndexVec<ValueIndex, &[Condition]>`. This is needlessly heavy, as the state rarely ever carries more than a few `Condition`s. The first commit replaces this state with a simpler `&[Condition]`, and puts the corresponding `ValueIndex` inside `Condition`.
The three later commits are perf tweaks.
The sixth commit is the main change. Instead of carrying the goto target inside the condition, we maintain a set of conditions associated with each block, and their consequences in following blocks. Think: if this condition is fulfilled in this block, then that condition is fulfilled in that block. This makes the threading algorithm much easier to implement, without the extra bookkeeping of `ThreadingOpportunity` we had.
Later commits modify that algorithm to shrink the set of duplicated blocks. By propagating fulfilled conditions down the CFG, and trimming costly threads.
Tidying up UI tests [7/N]
> [!NOTE]
> Intermediate commits are intended to help review, but will be squashed add comment commit prior to merge.
part of rust-lang/rust#133895
removed directory `tests/ui/explicit`, `tests/ui/interior-mutability`, `tests/ui/invalid-module-declaration`, tests/ui/invalid-self-argument`
r? Kivooeo
make assoc fn inherit const stability from inherent `const impl` blocks
Pulled out of rust-lang/rust#147893, "Currently, one cannot add any const stability annotations on the individual assoc fns at all, as the specific pass that checks for const stability on const fn seems to run as a HIR visitor [and looks at HIR assoc fn constness, which should be changed to also look at its parent]. I suspect there are things to be cleaned up there."
I was slightly lazy so didn't add the "staged_api using staged_api in implicit const stable context, in const unstable context, in explicit const stable context" tests. nudge me if you want to see those!
Don't suggest unwrap for Result in const
closerust-lang/rust#149316
Regarding `const fn` that returns `Result`, we should avoid suggesting unwrapping. The original issue reported cases where types didn't match, but in practice, such suggestions may also appear when methods are not found, so this PR includes a fix for that case as well.
cmse: do not calculate the layout of a type with infer types
tracking issue: https://github.com/rust-lang/rust/issues/81391
tracking issue: https://github.com/rust-lang/rust/issues/75835
fixes https://github.com/rust-lang/rust/issues/130104
Don't calculate the layout of a type with an infer type (`_`). This now emits `LayoutError::Unknown`, causing an error similar to when any other calling convention is used in this location.
The tests use separate functions because only the first such error in a function body is reported.
r? `@davidtwco` (might need some T-types assistance)
coverage: Store signature/body spans and branch spans in the expansion tree
In order to support coverage instrumentation of expansion regions, we need to reduce the amount of code that assumes we're only instrumenting a flat function body. Moving more data into expansion tree nodes is an incremental step in that direction.
There should be no change to compiler output.
Fix bad intra-doc-link preprocessing
How did rust-lang/rust#147981 happen?
1. We don't parse intra-doc links as Rust paths or qpaths. Instead they follow a very lenient bespoke grammar. We completely ignore Markdown links if they contain characters that don't match `/[a-zA-Z0-9_:<>, !*&;]/` (we don't even emit lint *broken-intra-doc-links* for these).
2. PR [#132748](https://github.com/rust-lang/rust/pull/132748) made rustdoc intepret more Markdown links as potential intra-doc links. Namely, if the link is surrounded by backticks (and some other conditions apply) then it doesn't matter if the (partially processed) link contains bad characters as defined above (cc `ignore_urllike && should_ignore_link(path_str)`).
3. However, rustdoc's `preprocess_link` must be kept in sync with a simplified counterpart in rustc. More specifically, whenever rustdoc's preprocessor returns a successful result then rustc's must yield the same result. Otherwise, rustc doesn't resolve the necessary links for rustdoc.
4. This uncovered a "dormant bug" / "mistake" in rustc's `preprocess_link`. Namely, when presented with a link like `struct@Type@suffix`, it didn't cut off the disambiguator if present (here: `struct@`). Instead it `rsplit('``@')``` which is incorrect if the "path" contains ```@``` itself (yielding `suffix` instead of `Type@suffix` here). Prior to PR [#132748](https://github.com/rust-lang/rust/pull/132748), a link like ``[`struct@Type@suffix`]`` was not considered a potential intra-doc link / worth querying rustc for. Now it is due to the backticks.
5. Finally, since rustc didn't record a resolution for `Type@suffix` (it only recorded `suffix` (to be `Res::Err`)), we triggered an assertion we have in place to catch cases like this.
Fixesrust-lang/rust#147981.
I didn't and still don't have the time to investigate if rust-lang/rust#132748 led to more rustc/rustdoc mismatches (after all, the PR made rustdoc's `preprocess_link` return `Some(Ok(_))` in more cases). I've at least added another much needed "warning banner" & made the existing one more flashy.
While this fixes a stable-to-beta regression, I don't think it's worth beta backporting, esp. since it's only P-medium and since the final 1.91 release steps commence today / the next days, so it would only be stressful to get it in on time. However, feel free to nominate.
<sub>(I've written such a verbose PR description since I tend to reread my old PR descriptions in the far future to fully freshen my memories when I have to work again in this area)</sub>
r? ``@lolbinarycat``
std: split up the `thread` module
Almost all functionality in `std::thread` is currently implemented in `thread/mod.rs`, resulting in a *huge* file with more than 2000 lines and multiple, interoperating `unsafe` sections. This PR splits the file up into multiple different private modules, each implementing mostly independent parts of the functionality. The only remaining `unsafe` interplay is that of the `lifecycle` and `scope` modules, the `spawn_scoped` implementation relies on the live thread count being updated correctly by the `lifecycle` module.
This PR contains no functional changes and only moves code around for the most part, with a few notable exceptions:
* `with_current_name` is moved to the already existing `current` module and now uses the `name` method instead of calculating the name from private fields. The old code was just a reimplementation of that method anyway.
* The private `JoinInner` type used to implement both join handles now has some more methods (`is_finished`, `thread` and the `AsInner`/`IntoInner` implementations) to avoid having to expose private fields and their invariants.
* The private `spawn_unchecked_` (note the underscore) method of `Builder` is now a freestanding function in `lifecycle`.
The rest of the changes are just visibility annotations.
I realise this PR ended up quite large – let me know if there is anyway I can aid the review process.
Edit: I've simplified the diff by adding an intermediate commit that creates all the new files by duplicating `mod.rs`. The actual changes in the second commit thus appear to delete the non-relevant parts from the respective file.
const validation: remove check for mutable refs in final value of const
This check rejects code that is not necessarily UB, e.g. a mutable ref to a `static mut` that is very carefully used correctly. That led to us having to describe it in the Reference, which uncovered just how ad-hoc this check is (https://github.com/rust-lang/reference/issues/2074).
Even without this check, we still reject things like
```rust
const C: &mut i32 = &mut 0;
```
This is rejected by const checking -- the part of the frontend that looks at the source code and says whether it is allowed in const context. In the Reference, this restriction is explained [here](https://doc.rust-lang.org/nightly/reference/const_eval.html#r-const-eval.const-expr.borrows).
So, the check during validation is just a safety net. And it is already a safety net with gaping holes since we only check `&mut T`, not `&UnsafeCell<T>`, due to the fact that we promote some immutable values that have `!Freeze` type so `&!Freeze` actually can occur in the final value of a const.
So... it may be time for me to acknowledge that the "mutable ref in final value of const" check is a cure that's worth than the disease. Nobody asked for that check, I just added it because I was worried about soundness issues when we allow mutable references in constants. Originally it was much stricter, but I had to slowly relax it to its current form to prevent t from firing on code we intend to allow. In the end there are only 3 tests left that trigger this error, and they are all just constants containing references to mutable statics -- not the safest code in the world, but also not so bad that we have to spend a lot of time devising a core language limitation and associated Reference wording to prevent it from ever happening.
So... `@rust-lang/wg-const-eval` `@rust-lang/lang` I propose that we allow code like this
```rust
static mut S: i32 = 3;
const C2: &'static mut i32 = unsafe { &mut * &raw mut S };
```
`@theemathas` would be great if you could try to poke a hole into this. ;)
Test the coexistence of 'stack-protector' and 'safe-stack'
This is a test to detect the coexistence of 'stack-protector' and 'safe-stack', and it's a supplement to pr rust-lang/rust#147115 . After the solution to issue rust-lang/rust#149340, I rewrote a version using minicore to circumvent the 'abi_mismatch' error.
r? `@SparrowLii` (Do you have time to review it?)
Add `DefId::parent()` accessor for `rustc_public`
Adds a `parent()` method to `DefId` (the `rustc_pub` version) which exposes the parent path, ie. `foo::bar::baz` -> `foo::bar`.
This is useful for organizing/grouping definitions into a tree, and is probably simpler and less brittle than attempting to parse the fully-qualified name into path components (e.g. especially when handling path components with qualified generic parameters).
Add a regression test for issue 129865
Closesrust-lang/rust#129865
Looks like the previous versions (`< 1.85.0`) failed to normalize async block's upvar types containing constants but not anymore
Allow the global allocator to use thread-local storage and std:🧵:current()
Fixes https://github.com/rust-lang/rust/issues/115209.
Currently the thread-local storage implementation uses the `Global` allocator if it needs to allocate memory in some places. This effectively means the global allocator can not use thread-local variables. This is a shame as an allocator is precisely one of the locations where you'd *really* want to use thread-locals. We also see that this lead to hacks such as https://github.com/rust-lang/rust/pull/116402, where we detect re-entrance and abort.
So I've made the places where I could find allocation happening in the TLS implementation use the `System` allocator instead. I also applied this change to the storage allocated for a `Thread` handle so that it may be used care-free in the global allocator as well, for e.g. registering it to a central place or parking primitives.
r? `@joboet`
Fix issue with callsite inline attribute not being applied sometimes.
If the calling function had more target features enabled than the callee than the attribute wasn't being applied as the arguments for the check had been swapped round. Also includes target features that are part of the global set as the warning was checking those but when adding the attribute they were not checked.
Add a codegen-llvm test to check that the attribute is actually applied as previously only the warning was being checked.
Tracking issue: rust-lang/rust#145574
Tidying up UI tests [5/N]
> [!NOTE]
> Intermediate commits are intended to help review, but will be squashed prior to merge.
part of rust-lang/rust#133895
merge directory
* `macro_backtrace` -> `macros`
* `missing_non_modrs_mod` -> `modules`
* `modules_and_files_visibility` -> `modules`
* `qualified` -> `typeck`
* `while` -> `for-loop-whlie`
r? Kivooeo
Fix ICE when include_str! reads binary files
ICE occurred when an invalid UTF8 file with an absolute path were included.
resolve: rust-lang/rust#149304
