```
error[E0277]: the trait bound `Rc<RefCell<S>>: Borrow<S>` is not satisfied
--> $DIR/shadowed-intrinsic-method-deref.rs:16:22
|
LL | let sb : &S = &s.borrow();
| ^^^^^^ the trait `Borrow<S>` is not implemented for `Rc<RefCell<S>>`
|
help: the trait `Borrow<S>` is not implemented for `Rc<RefCell<S>>`
but trait `Borrow<RefCell<S>>` is implemented for it
--> $SRC_DIR/alloc/src/rc.rs:LL:COL
= help: for that trait implementation, expected `RefCell<S>`, found `S`
= note: there's an inherent method on `RefCell<S>` of the same name, which can be auto-dereferenced from `&RefCell<T>`
help: to access the inherent method on `RefCell<S>`, use the fully-qualified path
|
LL - let sb : &S = &s.borrow();
LL + let sb : &S = &RefCell::borrow(&s);
|
```
In the example above, method `borrow` is available both on `<RefCell<S> as Borrow<S>>` *and* on `RefCell<S>`. Adding the import `use std::borrow::Borrow;` causes `s.borrow()` to find the former instead of the latter. We now point out that the other exists, and provide a suggestion on how to call it.
In `Option::get_or_insert_with()`, forget the `None` instead of dropping it.
Per https://github.com/rust-lang/rust/pull/148486#issuecomment-3493665688
In `Option::get_or_insert_with()`, after replacing the `None` with `Some`, forget the `None` instead of dropping it.
This allows eliminating the `T: [const] Destruct` bounds, making the functions more flexible in (unstable) const contexts, and avoids generating an implicit `drop_in_place::<Option<T>>()` that will never do anything (and which might even persist after optimization).
Unicode data: reduce size of to_lower/to_upper tables
Reduces the combined size of to_lower and to_upper from 25,364 bytes to 3,110 bytes. Explained in detail in the doc comments
Update books
## rust-embedded/book
4 commits in 99d0341ff4e06757490af8fceee790c4ede50bc0..e88aa4403b4bf2071c8df9509160477e40179099
2026-02-28 20:13:44 UTC to 2026-02-28 20:07:25 UTC
- Clarify that a mini usb cable is used on the STM32F3DISCOVERY (rust-embedded/book#381)
- Update outdated qemu documentation (rust-embedded/book#403)
- Add TRACE32 to Debuggers section (rust-embedded/book#406)
- Add a link to Rust for Zephyr (rust-embedded/book#407)
## rust-lang/nomicon
4 commits in b8f254a991b8b7e8f704527f0d4f343a4697dfa9..cc6a6bae8c3bfa389974e533c54694662c1a9de6
2026-02-27 23:27:18 UTC to 2026-02-26 22:57:03 UTC
- Fix `Vec::push_all` ptr code in exception-safety (rust-lang/nomicon#418)
- Clarify parameter and argument compatibility (rust-lang/nomicon#516)
- Improve grammar in Variance section (rust-lang/nomicon#515)
- Explicit `extern "C"` ABI for FFI (rust-lang/nomicon#520)
## rust-lang/reference
7 commits in 50a1075e879be75aeec436252c84eef0fad489f4..c49e89cc8c7c2c43ca625a8d5b7ad9a53a9ce978
2026-03-04 15:39:00 UTC to 2026-03-01 06:34:18 UTC
- Resolve grammar rules in link reference definitions (rust-lang/reference#2198)
- Support non-ASCII Unicode in grammar rule names (rust-lang/reference#2196)
- Fix grammar for block comments (rust-lang/reference#2191)
- Fix an EN grammar error & add an item to place expr context list (rust-lang/reference#2189)
- Align attribute template with applied conventions (rust-lang/reference#2194)
- Update shebang (rust-lang/reference#2192)
- Remove RESERVED_NUMBER (rust-lang/reference#2193)
ast_passes: unsupported arch w/ scalable vectors
Fixesrust-lang/rust#153593
Emit an error when attempting to compile a `#[rustc_scalable_vector]` type for a architecture that fundamentally doesn't support scalable vectors. Ultimately this is just a diagnostic improvement for an internal attribute as users should never be doing this.
r? @lqd
rustdoc: don't give depreciation notes special handling
based on discussion in rust-lang/rust#149741
we're currently using pre-wrap here which forces us to do a bunch of other hacky weird stuff, but getting rid of all that would likely break some existing docs, so i'm proposing we do it across an edition.
r? @GuillaumeGomez
fix ICE in `const_c_variadic` when passing ZSTs
fixes https://github.com/rust-lang/rust/issues/153351
r? RalfJung
There was a mismatch between the caller and callee ABI where the caller does not pass ZST arguments, but the callee does expect them. Because ZSTs don't implement `VaArgSafe` the program must already be invalid if this comes up.
stop marking `deref_patterns` as an incomplete feature
This PR removes the `incomplete_feature` warning for `deref_patterns`. The reason given for this in the tracking issue (rust-lang/rust#87121) was
> Per policy, the `incomplete_feature` is supposed to stay on until the feature has an accepted RFC. We're slowly working on writing up that RFC so it'll take some more time unfortunately.
>
> I don't know of any compiler crashes it causes today. The feature should be pretty usable.
However, I could not find any evidence of such a policy. The [lint documentation](https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#incomplete-features) for `incomplete_features` also only mentions features that are more likely to cause errors.
There are also many other features without an RFC that are not considered incomplete, e.g. `macro_metavar_expr_concat`, `negative_impls` or `yeet_expr`.
The feature does not cause any known ICEs either.
The concrete motivation is to use this feature to replace `box_patterns` in the compiler and pave the way towards removing that legacy feature.
Always make tuple elements a coercion site
Previously we only used `check_expr_coercible_to_type` if we had an expectation (using `check_expr_with_expectation(NoExpectation)` otherwise). Normally that'd be fine, because without an expectation we can't insert a coercion anyway. However, for the case of never-to-any coercion specifically, we _do_ insert it eagerly, so this prevents some code from compiling, for example:
```rust
((),) = (loop {},);
```
With this PR we are always using `check_expr_coercible_to_type` (using an infer var if there is no expectation), which allows slightly more code to compile.
Fixesrust-lang/rust#112856
r? BoxyUwU
Emit an error when attempting to compile a `#[rustc_scalable_vector]`
type for a architecture that fundamentally doesn't support scalable
vectors. Ultimately this is just a diagnostic improvement for an internal
attribute as users should never be doing this.
Move some ui tests
> [!NOTE]
> I split the commits to make the review easier and to keep the git history easier to trace.
Renamed issue-xxx tests
`tests/ui/dyn-drop` -> `tests/ui/dyn-keyword`
`tests/ui/missing-trait-bounds` -> `tests/ui/trait-bound/missing-trait-bounds`
`tests/ui/recursion_limit` -> `tests/ui/recursion/recursion_limit`
`tests/ui/version` -> `tests/ui/compile-flags`
Reorganize `tests/ui/empty`
tweak r-a default settings
1. Explain that you need to make paths absolute in helix settings
2. Use the correct compiler (set `RUSTC` and `CARGO` to stage0, instead of `RUSTUP_TOOLCHAIN=nightly`)
3. Add comments to vscode and zed settings
NB: I only tested helix settings, but am pretty sure that the other changes shouldn't break anything.
tools: remote-test-server: Add UEFI run support
Tested with OVMF on QEMU with Linux as the host running remote-test-client. The instructions for running tests are provided below:
1. Use rust-lld linker: `bootstrap.toml`
```toml
[rust]
lld = true
[target.x86_64-unknown-uefi]
linker = "rust-lld"
```
2. Use a custom startup.nsh script to auto-launch remote-test-server. This is optional.
```shell
fs1:
run.efi --sequential --bind "10.0.2.15:12345" --batch
```
3. Launch remote-test-server in QEMU. I am using uefi-run script [0].
```shell
uefi-run build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-uefi/release/remote-test-server.efi -n --startup startup.nsh --tcp-port 12345
```
4. Run tests:
```shell
RUST_TEST_THREADS=1 TEST_DEVICE_ADDR="localhost:12345" ./x.py test tests/ui/abi --target x86_64-unknown-uefi --stage 1
```
Requires: https://github.com/rust-lang/rust/pull/151014
@rustbot label +O-UEFI
cc @nicholasbishop
[0]: https://github.com/Ayush1325/dotfiles/blob/2d13056bf8ca1931a234b72967d9e857c4afbf1a/uefi/.local/bin/uefi-run
std: organise `sys::pal::os`
Continuing rust-lang/rust#153341, this moves around some functions in `sys::pal`, so that `pal::os` only contains standard-path-related code (which I'll move later as part of rust-lang/rust#117276).
Best reviewed commit-by-commit.
tests: codegen-llvm: iter-repeat-n-trivial-drop: Allow non-zero lower bound to __rust_alloc size
LLVM emits a lower bound of 8 for the size parameter to `__rust_alloc` when targeting `x86_64-unknown-hermit`. Since that is also completely valid, relax the lower bound check.
I'm not really sure why LLVM is able to infer this - with the same setup targeting `x86_64-unknown-linux-gnu` I also see the lower bound of 0. Not that it's wrong, but I'd be curious to know which codegen options play into this.
Esteban Küber