Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#155589 (Forbid `check-pass`/`build-pass`/`run-pass` directives in incremental tests)
- rust-lang/rust#155610 (Add missing `dyn` keyword to `trait_alias` page of the Unstable Book)
- rust-lang/rust#155615 (test cleanups for `ui/derives` and `ui/deriving`)
- rust-lang/rust#154874 (Fix ICE for inherited const conditions on const closures)
- rust-lang/rust#155605 (std: Update support for `wasm32-wasip3`)
- rust-lang/rust#155613 (c-variadic: tweak `std` docs)
- rust-lang/rust#155619 (Remove a bunch of unnecessary explicit lifetimes from the ast validator)
Fix ICE for inherited const conditions on const closures
Synchronize `evaluate_host_effect_for_fn_goal` with the behavior of `extract_fn_def_from_const_callable` in new solver.
Closesrust-lang/rust#153861 .
test cleanups for `ui/derives` and `ui/deriving`
The eventual goal is for `ui/deriving` to be merged into `ui/derives` entirely. This PR focuses on the `issue-*.rs` tests in `deriving` and a few other no-longer-useful tests.
r? @Kivooeo
Forbid `check-pass`/`build-pass`/`run-pass` directives in incremental tests
- Follow-up to https://github.com/rust-lang/rust/pull/155474
---
This PR forbids the use of `//@ check-pass`, `//@ build-pass`, and `//@ run-pass` directives in incremental tests. Tests that would have used those directives should use a revision name beginning with `cpass`/`bpass`/`rpass` instead.
(The `*-fail` directives are already forbidden in incremental tests.)
Existing incremental tests that used the `check-pass` and `build-pass` directives have been migrated. To allow migration of the check-pass tests, this PR also adds support for revision names beginning with `cpass`. No incremental tests were using `run-pass`.
---
Several of the migrated `build-pass` tests have a FIXME indicating that they could potentially be migrated to `check-pass` instead. This PR does not perform that migration.
In the future, I intend to do more cleanup of how compiletest handles pass/fail expectations, but I didn't want to cram too much into one PR.
r? jieyouxu
This is the subset of incremental tests that have a FIXME to consider migrating
to check-pass instead.
That migration is beyond the scope of this PR, but might be attempted later.
This is the subset of incremental tests that should continue to use `bpass`
even after `cpass` is supported, because they (presumably) involve codegen.
Fix incorrect `let` to `const` suggestion for pattern bindings
When a variable from a pattern binding was referenced inside a `const {}` block, the compiler incorrectly suggested replacing `let` with `const`. This was reported in rust-lang/rust#152831 for `if let`, but also applies to `while let` and `let ... else`.
Improve E0308 error message for `impl Trait` return mismatches
When a function returns `impl Trait`, all branches must return the same concrete type. Previously, the compiler showed:
expected `First` because of return type
This was misleading, as it suggested the return type was `First`, rather than any single type implementing the trait.
Update the diagnostic to:
expected a single type implementing `Value` because of return type
Also highlight the first return expression to make it clearer why subsequent returns do not match.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#152611 (Modify error message of importing inherent associated items when `#[feature(import_trait_associated_functions)]` is enabled)
- rust-lang/rust#155359 (Improperctypes refactor2.2)
- rust-lang/rust#155036 (Store a PathBuf rather than SerializedModule for cached modules)
- rust-lang/rust#155554 (add warning message when using x fix)
Modify error message of importing inherent associated items when `#[feature(import_trait_associated_functions)]` is enabled
Fixesrust-lang/rust#148009
This PR improves the diagnostic for importing inherent associated items from a struct or union when
`#[feature(import_trait_associated_functions)]` (rust-lang/rust#134691) is enabled.
Previously, this would result in a "not a module" error. This change provides a more specific error message clarifying that only trait associated items can be imported, while inherent associated items remain ineligible for import.
Enums are currently excluded from this change because their variants are valid import targets and require distinct handling.
Move diagnostic attribute target checks from check_attr
Move diagnostic attribute target checks into their targets. Part of https://github.com/rust-lang/rust/issues/131229#issuecomment-3959910413
This is much easier with `emit_dyn_lint` :) (thanks @GuillaumeGomez !)
I think there might be some opportunity to simplify all these `check_diagnostic_*` methods in `check_attr`. However there are some diagnostic attribute prs in flight and I'd like to wait for those to land first and then think about it. So that PR is not for today.
r? @JonathanBrouwer (or @GuillaumeGomez if you want)
Fix `#[expect(dead_code)]` liveness propagation
Fixes https://github.com/rust-lang/rust/issues/154324
Fixes https://github.com/rust-lang/rust/issues/152370 (cc @eggyal)
Previously, when traversing from a `ComesFromAllowExpect::Yes` item (i.e., with `#[allow(dead_code)]` or `#[expect(dead_code)]`), other `ComesFromAllowExpect::Yes` items reached during propagation would be updated to `ComesFromAllowExpect::No` and inserted into `live_symbols`. That caused `dead_code` lint couldn't be emitted correctly.
After this PR, `ComesFromAllowExpect::Yes` items no longer incorrectly update other `ComesFromAllowExpect::Yes` items during propagation or mark them live by mistake, then `dead_code` lint could behave as expected.
tests: add whitespace tests for vertical tab behavior
This PR adds two small tests to highlight how vertical tab (\x0B)
is handled differently across Rust's whitespace definitions.
The Rust lexer treats vertical tab as whitespace (Unicode
Pattern_White_Space), while `split_ascii_whitespace` follows the
WhatWG Infra Standard and does not include vertical tab.
These tests make that difference visible and easier to understand.
See: https://github.com/rustfoundation/interop-initiative/issues/53
* tests: add whitespace tests for vertical tab behavior
Add two small tests to highlight how vertical tab is handled differently.
- vertical_tab_lexer.rs checks that the lexer treats vertical tab as whitespace
- ascii_whitespace_excludes_vertical_tab.rs shows that split_ascii_whitespace does not split on it
This helps document the difference between the Rust parser (which accepts vertical tab)
and the standard library’s ASCII whitespace handling.
See: rust-lang/rust-project-goals#53
* tests: add ignore-tidy-tab directive to whitespace tests
* tests: expand vertical tab lexer test to cover all Pattern_White_Space chars
* tests: add whitespace/ README entry explaining lexer vs stdlib mismatch
* Update ascii_whitespace_excludes_vertical_tab.rs
* Update ascii_whitespace_excludes_vertical_tab.rs
make sure tabs and spaces are well checked
* Update ascii_whitespace_excludes_vertical_tab.rs
* fix tidy: add whitespace README entry
* Update README.md with missing full stop
* Update ascii_whitespace_excludes_vertical_tab.rs
* fix tidy: use full path format for whitespace README entry
* fix tidy: README order, trailing newlines in whitespace tests
* fix: add run-pass directive and restore embedded whitespace bytes
* fix tidy: remove duplicate whitespace README entry
*
Add failing UI test for invalid whitespace (zero width space)
This adds a //@ check-fail test to ensure that disallowed whitespace
characters like ZERO WIDTH SPACE are rejected by the Rust lexer.
* git add tests/ui/whitespace/invalid_whitespace.rs
git commit -m "Fix tidy: add trailing newline"
git push
* Fix tidy: add trailing newline
* Update invalid_whitespace.rs
* Update invalid_whitespace.rs
* Clean up whitespace in invalid_whitespace.rs
Remove unnecessary blank lines in invalid_whitespace.rs
* Update invalid_whitespace.rs
* Clarify ZERO WIDTH SPACE usage in test
Update comment to clarify usage of ZERO WIDTH SPACE.
* Improve error messages for invalid whitespace
Updated error messages to clarify the issue with invisible characters.
* Modify invalid_whitespace test for clarity
Update test to check for invalid whitespace characters.
* Resolve unknown token error in invalid_whitespace.rs
Fix whitespace issue causing unknown token error.
* Remove invisible character from variable assignment
Fix invisible character issue in variable assignment.
* Improve error message for invalid whitespace
Updated error message to clarify invisible characters.
* Improve error handling for invisible characters
Updated error message for invisible characters in code.
* Document error for unknown token due to whitespace
Add error message for invalid whitespace in code
* Update error message for invalid whitespace handling
* Modify invalid_whitespace.rs for whitespace checks
Updated the test to check for invalid whitespace handling.
* Correct whitespace in variable declaration
Fix formatting issue by adding space around '=' in variable declaration.
* Update error message for invalid whitespace
* Update invalid_whitespace.stderr
* Refine error handling for invalid whitespace test
Update the error messages for invalid whitespace in the test.
* Update invalid_whitespace.rs
* Fix whitespace issues in invalid_whitespace.rs
* Update invalid_whitespace.stderr file
* Clean up whitespace in invalid_whitespace.rs
Removed unnecessary blank lines from the test file.
* Update invalid_whitespace.stderr
Update books
## rust-embedded/book
2 commits in 2463edeb8003c5743918b3739a9f6870b86396f5..0789b0f29e73ecb91213cac10ad0eec1b9333770
2026-04-11 08:46:22 UTC to 2026-04-10 14:01:38 UTC
- remove IO chapter, is covered in next chapter (rust-embedded/book#411)
- add embassy chapter (rust-embedded/book#412)
## rust-lang/reference
10 commits in d2715c07e9dd9839c0c7675ecfa18bec539a6ee9..8c88f9d0bdd75ffdc0691676d83212ae22a18cee
2026-04-20 15:20:24 UTC to 2026-04-07 16:25:09 UTC
- typo in example code (rust-lang/reference#2232)
- oxford comma (rust-lang/reference#2233)
- improve readability (rust-lang/reference#2234)
- typo (rust-lang/reference#2230)
- Clarify items.fn.generics.param-bounds (rust-lang/reference#2229)
- follow formatting style guideline (rust-lang/reference#2228)
- Update `derive` export locations (rust-lang/reference#2223)
- Clarify that `{self}` imports require a module parent (rust-lang/reference#2221)
- stabilize s390x vector registers (rust-lang/reference#2215)
- Fix misuse of *usage* throughout the Reference (rust-lang/reference#2222)
## rust-lang/rust-by-example
2 commits in b31e3b8da01eeba0460f86a52a55af82709fadf5..898f0ac1479223d332309e0fce88d44b39927d28
2026-04-19 11:40:28 UTC to 2026-04-19 11:38:45 UTC
- remove debug printing for the u32 and bool in variable_bindings.md (rust-lang/rust-by-example#1999)
- Update for.md (rust-lang/rust-by-example#2008)
Suggest removing `&` when awaiting a reference to a future
Fixesrust-lang/rust#87211
When `.await`ing `&impl Future`, suggest removing the `&` instead of removing `.await`.
Make E0284 generic argument suggestions more explicit
Closesrust-lang/rust#147313
Previously, when type annotations were missing for a function call, rust suggested: "consider specifying the generic argument". This PR improves the diagnostics:
- If only one generic type is missing:
"consider specifying a concrete type for the generic type `<T>`" with the turbofish being "::\<SomeConcreteType>"
- If only one const generic is missing:
"consider specifying a const for the const generic `<CONST>`" with the turbofish being "::<SOME_CONST>"
Multiple missing generics still produce the original more general suggestion
Merge BuildReducedGraphVisitor into DefPathVisitor
These two visitors run right after each other on the same immutable AST. There's also a hash map for transferring the TyCtxtFeed created in the def collector to the BRG when it visits the same items. There are possibly more avenues for sharing logic, but I want to keep this PR simple.
only opening for perf runs for now. I'm still investigating how to ensure that future changes don't introduce subtle bugs by forgetting that def collection and reduced graph building are one pass now
Best reviewed commit-by-commit. I took a lot of care for making the individual changes reviewable, but all the `Merge *` commits aren't able to compile libcore until the last one.
Suggest returning a reference for unsized place from a closure
Fixesrust-lang/rust#152064
There are 3 similar note:
`the size for values of type str cannot be known at compilation time`
for different spans, maybe need more work to remove some of them.
This PR only adds a suggestion for using a reference.
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#154654 (Move `std::io::ErrorKind` to `core::io`)
- rust-lang/rust#145270 (Fix an ICE observed with an explicit tail-call in a default trait method)
- rust-lang/rust#154895 (borrowck: Apply `user_arg_index` nomenclature more broadly)
- rust-lang/rust#155213 (resolve: Make sure visibilities of import declarations make sense)
- rust-lang/rust#155346 (`single_use_lifetimes`: respect `anonymous_lifetime_in_impl_trait`)
- rust-lang/rust#155517 (Add a test for Mach-O `#[link_section]` API inherited from LLVM)
- rust-lang/rust#155549 (Remove some unnecessary lifetimes.)
- rust-lang/rust#154248 (resolve : mark repr_simd as internal)
- rust-lang/rust#154772 (slightly optimize the `non-camel-case-types` lint)
- rust-lang/rust#155541 (Add `#[rust_analyzer::prefer_underscore_import]` to the traits in `rustc_type_ir::inherent`)
- rust-lang/rust#155544 (bootstrap: Make "detected modifications" for download-rustc less verbose)
Add a test for Mach-O `#[link_section]` API inherited from LLVM
The format of the `#[link_section]` attribute is under-documented, but on Mach-O, I think it's roughly the following BNF:
```
LinkSection -> Segment `,` Section (`,` (SectionType (`,` (SectionAttributes)?)?)?)?
Segment -> <0 to 16 bytes>
Section -> <0 to 16 bytes>
SectionType -> `regular` | `zerofill` | `cstring_literals` | `4byte_literals` | `8byte_literals` | `literal_pointers` | `non_lazy_symbol_pointers` | `lazy_symbol_pointers` | `symbol_stubs` | `mod_init_funcs` | `mod_term_funcs` | `coalesced` | `interposing` | `16byte_literals` | `thread_local_regular` | `thread_local_zerofill` | `thread_local_variables` | `thread_local_variable_pointers` | `thread_local_init_function_pointers`
SectionAttributes -> SectionAttribute (`+` SectionAttribute)*
SectionAttribute -> `pure_instructions` | `no_toc` | `strip_static_syms` | `no_dead_strip` | `live_support`, `self_modifying_code` | `debug`
```
This PR adds a small test for a little part of this.
Once https://github.com/rust-lang/rust/issues/154429 is resolved, this should make it possible to test https://github.com/rust-lang/rustc_codegen_cranelift/pull/1648 end-to-end.
r? bjorn3
resolve: Make sure visibilities of import declarations make sense
That they are all ordered inside the module and not more private than the module itself.
The `import_decl_vis` logic is also reused when reporting `ambiguous_import_visibilities` lint.
Some asserts are hardened.
Some relevant tests are added.
Extracted from https://github.com/rust-lang/rust/pull/154149.
Fix an ICE observed with an explicit tail-call in a default trait method
Right now, explicit tail-calls cannot be used in functions that hold the `#[track_caller]` attribute. This check is performed on a resolved concrete instance of a function, which would be absent for a tail-call performed from the body of a default trait method. This PR fixes the issue by checking for the relevant attribute in default trait methods separately, without expecting a specific resolved instance.
Closes https://github.com/rust-lang/rust/issues/144985.
That they are all ordered inside the module and not more private than the module itself
The `import_decl_vis` logic is reused when reporting `ambiguous_import_visibilities` lint
Some asserts are hardened
Some relevant tests are added