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)
Fix LLVM offload install docs to use semicolon-separated CMake lists
Update so the LLVM CMake example uses and , which is the correct list separator syntax for LLVM CMake options.[Docs] Remove shortcode from models page heading
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.
Simplify macros for target-modifier and mitigation flags
- Rebased and revised version of https://github.com/rust-lang/rust/pull/154501.
---
The macros used for handling command-line flags that are “target modifiers” or “mitigations” are quite complicated, and can be significantly simplified by tweaking their syntax and by making use of `${ignore(..)}` metavars.
It's possible that more code could be moved out of macros (e.g. declaring some of the enums by hand), but that can be investigated in a potential follow-up.
There should be no change to compiler behaviour.
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)
Remove `HashStable` impl for `[hir::Attribute]`.
This impl skips:
- All doc comments
- A handful of other attributes, mostly `rustc_*` ones related to incremental compilation testing.
This skipping originated in rust-lang/rust#36025 and was extended a couple of times, e.g. in rust-lang/rust#36370. Those PRs don't have any explanation of why the skipping exists. Perhaps the reasoning was that doc comments should only affect rustdoc and rustdoc doesn't use incremental compilation? But doc comments end up in metadata, and there is a query `attrs_for_def` that returns a `&'tcx [hir::Attribute]`. So skipping some attributes just seems plainly wrong.
This commit removes the impl, which means `[hir::Attribute]` hashing falls back to the default impl for `[T]`. This has no noticeable effect on the test suite. It does slightly hurt performance, because of the doc comments. This perf regression seems worth it for the correctness benefits.
Add `#[rust_analyzer::prefer_underscore_import]` to the traits in `rustc_type_ir::inherent`
This is a new attribute (https://github.com/rust-lang/rust-analyzer/pull/21740) that instructs rust-analyzer to prefer importing the trait `as _`. It is useful for these traits since their names often clashes with the type.
resolve : mark repr_simd as internal
I changed ```repr_simd``` to ```internal``` and changed the position to ```feature-group-start: internal feature gates```.
closerust-lang/rust#154034
Remove some unnecessary lifetimes.
We have a number of structs with more lifetimes than necessary. This commit removes them.
LLM disclosure: I asked Claude Code to check for unnecessary lifetimes in all types with three or more lifetimes, and it produced a list of candidates (half of which were invalid). I did the modifications for the valid cases myself, and found a couple more cases along the way.
r? @JohnTitor
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.
Move `std::io::ErrorKind` to `core::io`
ACP: https://github.com/rust-lang/libs-team/issues/755
Tracking issue: https://github.com/rust-lang/rust/issues/154046
Related: https://github.com/rust-lang/rust/pull/152918
## Description
I consider rust-lang/rust#154046 to be really important for `no_std`, but I'm concerned rust-lang/rust#152918 might be too controversial. As an alternative, I'd like to propose starting small with `ErrorKind`, since it can be moved somewhat trivially. It has no dependencies on functionality in `std`, no platform specific behaviour, and could provide an excellent bridging point for `no_std` IO libraries.
Since `std::io::Error` implements `From<ErrorKind>`, libraries could write functions which return `Result<T, core::io::ErrorKind>`, and therefore be usable in `std`-using libraries with the `?` operator. For that reason, I'd consider this to be a worthwhile change even if the rest of `std::io` couldn't be moved to `core`/`alloc`, and entirely compatible with any efforts to make such a change in the future.
## Notes
* This is my first PR against Rust, please let me know if there's anything I should be doing that I have not done. I tried reading through the library contributors guide but I'm sure I've missed _something_.
* No AI tooling of any kind was used in the creation of this PR.
* I believe it's appropriate that this be a part of the linked tracking issue, but please let me know if that's not the case!
Oli Scherer