Skip to content

Conversation

@workflows-rustc-dev-guide
Copy link

Latest update from rustc.

Jesus Checa Hidalgo and others added 30 commits October 16, 2025 14:05
The `needs-asm-support` directive checks whether the host architecture
supports inline assembly, not the target architecture. For tests that
explicitly specify a target via `--target` in their compile-flags, this
directive is incorrect and unnecessary.

These tests are cross-compiling to specific targets (like x86_64, arm,
aarch64, riscv, etc.) that are already known to have stable asm support.
The directive was causing these tests to be incorrectly skipped on hosts
that don't support asm, even though the target does.

Tests with explicit targets should rely on `needs-llvm-components` to
ensure the appropriate backend is available, rather than checking host
asm support.

Improve documentation about `needs-asm-support` directive.
handle spurious returns of `wait_timeout` in test

Fixes rust-lang/rust#147885
Closes rust-lang/rust#147871

`wait_timeout` is allowed to spuriously return, hence the `timeout_nanoseconds` must not assume that the wakeup resulted from a `notify_all()`.
Stop invalidating CFG caches in CleanupPostBorrowck.

r? `@ghost`
move `once` module out of `poison`

From rust-lang/rust#134645 (comment), since `Once` will not have a non-poisoning variant, we remove it from the `poison` module.

Additionally:

1. Renames `once::ExclusiveState` to `OnceExclusiveState` since it was a bit confusing reading just `ExclusiveState` where it is used.
2. Reorders a few module definitions and re-exports in `library/std/src/sync/mod.rs` for clarity.

Also, once this is merged, I think that we can begin the process of stabilizing [`sync_poison_mod`](rust-lang/rust#134646)
Add `Cacheable` trait alias in `rustc_public_bridge`

r? `@celinval`
…es, r=notriddle,GuillaumeGomez

rustdoc search: relax rules for identifiers

fixes rust-lang/rust#147763
rustc-dev-guide subtree update

Subtree update of `rustc-dev-guide` to 7cb1f42.

Created using https://github.com/rust-lang/josh-sync.

r? `@ghost`
Rollup of 5 pull requests

Successful merges:

 - rust-lang/rust#147125 (move `once` module out of `poison`)
 - rust-lang/rust#147800 (Add `Cacheable` trait alias in `rustc_public_bridge`)
 - rust-lang/rust#147860 (rustdoc search: relax rules for identifiers)
 - rust-lang/rust#147916 (Update books)
 - rust-lang/rust#147924 (rustc-dev-guide subtree update)

r? `@ghost`
`@rustbot` modify labels: rollup
Add a test for the cold attribute

This adds a test for the cold attribute to verify that it actually does something, and that it applies correctly in all the positions it is expected to work.
Remove broken link

Idk if this link is any important but it does not work anymore so...
Make `UnevaluatedConst` have a specific ID type in the new solver

For the benefit of rust-analyzer.

r? types
`-Znext-solver` instantiate predicate binder without recanonicalizing goal

This strengthens the leak check to match the old trait solver. The new trait solver now also instantiates higher ranked goals in the same scope as candidate selection, so the leak check in each candidate detects placeholder errors involving this higher ranked goal.

E.g. let's look at tests/ui/higher-ranked/leak-check/leak-check-in-selection-2.rs
```rust
trait Trait<T, U> {}
impl<'a> Trait<&'a str, &'a str> for () {}
impl<'a> Trait<&'a str, String> for () {}
fn impls_trait<T: for<'a> Trait<&'a str, U>, U>() {}

fn main() {
    impls_trait::<(), _>();
}
```
Here proving `(): for<'a> Trait<&'a str, ?u>` via `impl<'a> Trait<&'a str, &'a str> for ()` equates `?u` with `&'!a str` which results in a leak check error as `?u` cannot name `'a`. If this leak check error happens while considering candidates we drop the first impl and infer `?u` to `String`. If not, this remains ambiguous.

This behavior is a bit iffy, see the FCP proposal in rust-lang/rust#119820 for more details on why this current behavior is somewhat undesirable. However, considering placeholders from higher-ranked goals for candidate selection does allow more code to compile and a lot of the code *feels like it should compile*. **This caused us to revert the change of rust-lang/rust#119820 in rust-lang/rust#127568.**

I originally expected that we can avoid breakage with the new solver differently here, e.g. by considering OR-region constraints. However, doing so is a significant change and I don't have a great idea for how that should work. Matching the old solver behavior for now should not make this cleaner approach any more difficult in the future, so let's just go with what actually allows us to stabilize the new solver for now.

This PR changing the new solver to match the behavior of the old one wrt the leak check. As the new solver is already used by default in coherence, this allows more code to compile, see `tests/ui/higher-ranked/leak-check/leak-check-in-selection-7-coherence.rs`:
```rust
struct W<T, U>(T, U);

trait Trait<T> {}
// using this impl results in a higher-ranked region error.
impl<'a> Trait<W<&'a str, &'a str>> for () {}
impl<'a> Trait<W<&'a str, String>> for () {}

trait NotString {}
impl NotString for &str {}
impl NotString for u32 {}

trait Overlap<U> {}
impl<T: for<'a> Trait<W<&'a str, U>>, U> Overlap<U> for T {}
impl<U: NotString> Overlap<U> for () {}

fn main() {}
```

This behavior is quite arbitrary and not something I expect users to rely on in practice, however, it should still go through an FCP imo.

r? `@BoxyUwU` originally implemented by `@compiler-errors` in rust-lang/rust#136997. Closes rust-lang/trait-system-refactor-initiative#120.
Remove current code for embedding command-line args in PDB

The compiler currently has code that will obtain a list of quoted command-line arguments, and pass it through to TargetMachine creation, so that the command-line args can be embedded in PDB output.

This PR removes that code, due to subtle concerns that might not have been apparent when it was originally added.

---

Those concerns include:
- The entire command-line quoting process is repeated every time a target-machine-factory is created. In incremental builds this typically occurs 500+ times, instead of happening only once. The repeated quoting constitutes a large chunk of instructions executed in the `large-workspace` benchmark.
  - See rust-lang/rust#146804 (comment) for an example of the perf consequences of skipping all that work.
  - This overhead occurs even when building for targets or configurations that don't emit PDB output.
- Command-line arguments are obtained in a way that completely bypasses the query system, which is a problem for the integrity of incremental compilation.
  - Fixing this alone is likely to inhibit incremental rebuilds for most or all CGUs, even in builds that don't emit PDB output.
- Command-line arguments and the executable path are obtained in a way that completely bypasses the compiler's path-remapping system, which is a reproducibility hazard.
  - rust-lang/rust#128842

---

Relevant PRs:
- rust-lang/rust#113492
- rust-lang/rust#130446
- rust-lang/rust#131805
- rust-lang/rust#146700
- rust-lang/rust#146973

Zulip thread:
- https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Some.20PDB.20info.20bypasses.20the.20query.20system.20and.20path.20remapping/with/541432211

---

According to rust-lang/rust#96475, one of the big motivations for embedding the command-line arguments was to enable tools like Live++. [It appears that Live++ doesn't actually support Rust yet](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/embeded.20compiler.20args.20and.20--remap-path-prefix/near/523800010), so it's possible that there aren't any existing workflows for this removal to break.

In the future, there could be a case for reintroducing some or all of this functionality, guarded behind an opt-in flag so that it doesn't cause problems for other users. But as it stands, the current implementation puts a disproportionate burden on other users and on compiler maintainers.
Forbid ShallowInitBox after box deref elaboration.

MIR currently contains a `ShallowInitBox` rvalue. Its principal usage is to allow for in-place initialization of boxes. Having it is necessary for drop elaboration to be correct with that in-place initialization.

As part of analysis->runtime MIR lowering, we canonicalize deref of boxes to use the stored raw pointer. But we did not perform the same change to the construction of the box.

This PR replaces `ShallowInitBox` by the pointer manipulation it represents.

Alternatives:
- fully remove `ShallowInitBox` and implement `Box` in-place initialization differently;
- remove the `ElaborateBoxDeref` pass and keep dereferencing `Box` in runtime MIR.
Update typos

I saw that `typos` was a few versions out of date and figured it would be a good idea to update it. Upgrading to `1.38.1` adds the [July](crate-ci/typos#1331), [August](crate-ci/typos#1345), and [September](crate-ci/typos#1370) dictionary updates. As part of this change, I also sorted the configuration file.
refactor: Move to anstream + anstyle for styling

`rustc` uses [`termcolor`](https://crates.io/crates/termcolor) for styling and writing, while `annotate-snippets` uses [`anstyle`](https://crates.io/crates/anstyle) for styling and currently writes directly to a `String`. When rendering directly to a terminal, there isn't/shouldn't be any differences. Still, there are differences in the escape sequences, which leads to slightly different output in JSON and SVG tests. As part of my work to have `rustc` use `annotate-snippets`, and to reduce the test differences between the two, I switched `rustc` to use `anstlye` and [`anstream`](https://crates.io/crates/anstream) for styling and writing.

The first commit migrates to `anstyle` and `anstream` and notably does not change the output. This is because it includes extra formatting to ensure that `anstyle` + `anstream` match the current output exactly. Most of this code is unnecessary, as it adds redundant resets or uses 256-color (8-bit) when it could be using 4-bit color. The subsequent commits remove this extra formatting while maintaining the correct output when rendered.

[Zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/147480-t-compiler.2Fdiagnostics/topic/annotate-snippets.20hurdles)
Split LTO out of the main codegen coordinator event loop into a separate event loop on the same thread

This will make it easier to in the future move all this code to link_binary.

Follow up to rust-lang/rust#146209
Part of rust-lang/compiler-team#908
… r=cuviper

Remove needs-asm-support directive in tests with explicit targets

The `needs-asm-support` directive checks whether the host architecture supports inline assembly, not the target architecture. For tests that explicitly specify a target via `--target` in their compile-flags, this directive is incorrect and unnecessary.

These tests are cross-compiling to specific targets (like x86_64, arm, aarch64, riscv, etc.) that are already known to have stable asm support. The directive was causing these tests to be incorrectly skipped on hosts that don't support asm, even though the target does.

Tests with explicit targets should rely on `needs-llvm-components` to ensure the appropriate backend is available, rather than checking host asm support.
refactor(rustdoc): Remove redundant langstr checks

These same checks feed into `doctest.can_be_merged`, making them redundant.
compiletest: Add concrete examples for some config/test path fields

Seeing a specific example path can be much more enlightening than trying to figure out what the prose is gesturing towards.

Also, in some cases the existing comments were incorrect or misleading, as demonstrated by the example paths.

The example paths were determined by dumping them directly out of the config with `dbg!`, and then lightly anonymizing them for example purposes.

---

No functional changes.

r? jieyouxu
Fix compiling `CondVar::wait_timeout` on 32-bit Apple platforms

Fixes rust-lang/rust#147776. I feel like there's a cleaner way to write this, but that probably requires further refactoring.

The build can be tested with `./x build --target arm64_32-apple-watchos` (or with any other 32-bit Apple target).

Tested it works at runtime on an Intel Macbook Pro with macOS 10.12.6, in x86 emulation mode with something similar to `./x test library/std --target x86_64-apple-darwin,i686-apple-darwin`, as well as with a custom test with a timeout of `Duration::from_secs((u32::MAX as u64) + 1)` (which the naive fix would have treated as a duration of 1 second).

r? libs
CC ``@joboet``
test(frontmatter): Rename tests to make coverage more obvious

When working on the stabilization report (rust-lang/rust#148051), I found it annoying to determine what cases were covered because areas of the frontmatter feature were either not in the file name or in inconsistent locations.

This moves the area of frontmatter to the start of the file name and the moves to more specific the later in the file name so coverage is easier to see.

Tracking issue: rust-lang/rust#136889
Rollup of 5 pull requests

Successful merges:

 - rust-lang/rust#147406 (Remove needs-asm-support directive in tests with explicit targets)
 - rust-lang/rust#148056 (refactor(rustdoc): Remove redundant langstr checks)
 - rust-lang/rust#148065 (compiletest: Add concrete examples for some config/test path fields)
 - rust-lang/rust#148072 (Fix compiling `CondVar::wait_timeout` on 32-bit Apple platforms)
 - rust-lang/rust#148073 (test(frontmatter): Rename tests to make coverage more obvious)

r? `@ghost`
`@rustbot` modify labels: rollup
StateTransform: Only load pin field once.

The current implementation starts by transforming all instances of `_1` into `(*_1)`, and then traverses the body again to transform `(*_1)` into `(*(_1.0))`, and again for `Derefer`.

This PR changes the implementation to only traverse the body once. As `_1.0` cannot be not modified inside the body (we just changed its type!), we have no risk of loading from the wrong pointer.
Rollup of 4 pull requests

Successful merges:

 - rust-lang/rust#143361 (Stop passing resolver disambiguator state to AST lowering.)
 - rust-lang/rust#148000 (Improvements to attribute suggestions)
 - rust-lang/rust#148007 (chore: Update to the latest annotate-snippets)
 - rust-lang/rust#148088 (compiletest: Simplify passing arguments to spawned test threads)

r? `@ghost`
`@rustbot` modify labels: rollup
remove a performance hack

This hack seems no longer used 🤔 nalgebra compiles without it.

Let's run perf to see whether it matters.

r? `@BoxyUwU`
…, r=tgross35

Unify and deduplicate max recip float tests

cc rust-lang/rust#141726

This is a proposal to unify and deduplicate max recip tests for f16 and f128
Don't require `T: RefUnwindSafe` for `vec::IntoIter<T>: UnwindSafe`

Closes rust-lang/rust#144707

r? t-libs-api
…oundwork, r=jieyouxu

compiletest: pass rustdoc mode as param, rather than implicitly

Spun out of rust-lang/rust#142642

In the future, I want the rustdoc-json test suite to invoke rustdoc twice, once with `--output-format=json`, and once with the (not yet implemented) `--output-format=postcard` flag.

Doing that requires being able to explicitly tell the `.document()` function which format to use, rather then implicitly using json in the rustdoc-json suite, and HTML in all others.

r? `@jieyouxu`

CC `@jalil-salame`
…,lolbinarycat

Improve source code for `highlight.rs`

I was very bothered by the complexity of this file, in particular the handling of `pending_elems` which was very tricky to follow.

So instead, here comes a more sane approach: the content is store in a stack-like type which handles "levels" of HTML (ie, a macro expansion can contain other HTML tags which can themselves contain other, etc). Making it much simpler to keep track of what's going on.

r? `@lolbinarycat`
bors and others added 3 commits October 26, 2025 23:44
resolve: When suppressing `out_of_scope_macro_calls` suppress `unused_imports` as well

Fixes the example from this comment - rust-lang/rust#147823 (comment).
Fixes rust-lang/rust#148143.
This updates the rust-version file to b1b464d6f61ec8c4e609c1328106378c066a9729.
Pull recent changes from https://github.com/rust-lang/rust via Josh.

Upstream ref: b1b464d6f61ec8c4e609c1328106378c066a9729
Filtered ref: f94cd4e
Upstream diff: rust-lang/rust@4068baf...b1b464d

This merge was created using https://github.com/rust-lang/josh-sync.
@rustbot
Copy link
Collaborator

rustbot commented Oct 27, 2025

Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using r? rustc-dev-guide or r? <username>.

@rustbot rustbot added the S-waiting-on-review Status: this PR is waiting for a reviewer to verify its content label Oct 27, 2025
@tshepang
Copy link
Member

rather tiny, but it is an update, so...

@tshepang tshepang merged commit b9fb8e9 into main Oct 27, 2025
1 check passed
@rustbot rustbot removed the S-waiting-on-review Status: this PR is waiting for a reviewer to verify its content label Oct 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants