resolve: Identifier resolution refactorings
Mostly splitting large functions into smaller functions, including some parts from https://github.com/rust-lang/rust/pull/144131, there should be no functional changes.
See individual commits.
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. ;)
Remove an unnecessary `unwrap` in `rustc_codegen_gcc`
This should hopefully unblock rust-lang/rust#149425 (I couldn't find an in-flight PR that was already doing this).
I've tested locally with the `master` version of Clippy that `rustc_codegen_gcc` passes the lints (the syncing PR could still fail for other reasons however).
I understand that `rustc_codegen_gcc` is normally developed [outside of this repo](https://github.com/rust-lang/rustc_codegen_gcc) but my understanding is that that repo is two-way synced regularly and hopefully it is acceptable to do this tiny change here to unblock the Clippy syncing PR (is there an established process for how to unblock these syncing PRs?). Of course feel free to close if this isn't the expected process.
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).
Update books
## rust-lang/book
2 commits in f78ab89d7545ac17780e6a367055cc089f4cd2ec..8c0eacd5c4acbb650497454f3a58c9e8083202a4
2025-11-18 15:36:41 UTC to 2025-11-18 15:33:41 UTC
- Update ch07-02-defining-modules-to-control-scope-and-privacy.md (rust-lang/book#4570)
- use AND for search terms (rust-lang/book#4573)
## rust-lang/reference
4 commits in f9f1d2a4149f02582aec2f8fcdfa5b596193b4e2..f2ac173df9906de5c03b0ee50653321ef1c4ebe8
2025-11-26 02:52:23 UTC to 2025-11-18 21:54:51 UTC
- document `cfg` conditions on inline assembly templates and operands (rust-lang/reference#2063)
- remove unused "link reference definitions" (rust-lang/reference#2092)
- Add review process overview to review-policy.md (rust-lang/reference#2088)
- Remove restriction on dereferencing pointers in const (rust-lang/reference#2090)
## rust-lang/rust-by-example
5 commits in f944161716230641605b5e3733e1c81f10047fd4..111cfae2f9c3a43f7b0ff8fa68c51cc8f930637c
2025-11-27 20:16:42 UTC to 2025-11-20 21:40:02 UTC
- Use `From::from` fn pointer to convert to boxed errors (rust-lang/rust-by-example#1906)
- link the _tuple_ page instead "TupleStruct" (rust-lang/rust-by-example#1909)
- enum_use.md: avoid an uncommon term (rust-lang/rust-by-example#1976)
- make search less surprising (rust-lang/rust-by-example#1975)
- Update documentation for `any` function in iter_any.md (rust-lang/rust-by-example#1973)
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
Remove outdated comment
The comment was added in rust-lang/rust#136897 , but wasn't removed when the feature gate was stabilized (again).
Also, `it's` -> `its` :)
float::minimum/maximum: say which exact IEEE operation this corresponds to
There's both `minimum` and `minimumNumber`, so this seems worth clarifying.
Also use code font for these names to make it more clear that they are technical terms.
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
