In commit "test: Consolidate `Hexf`, `Hexi`, and the `Hex` trait" we
unintentionally lost the difference between float hex and bitwise hex
formatting; instead, the float hex was getting printed twice. Resolve
this by printing the integer hex whenever the `-` format modifier is
specified. This also makes things simpler because we no longer need to
keep track of whether an `impl DisplayHex` is a float with `.to_bits()`
available or an integer without it, we can always just try to print both
forms.
As a result, we can use a common error message for all validation
checks.
Implement `__clear_cache` for Hexagon targets in Rust. Hexagon has
separate instruction and data caches, so this flushes dirty data cache
lines with `dccleaninva`, invalidates stale instruction cache lines
with `icinva`, then issues an `isync` barrier.
Based on the compiler-rt implementation from
llvm/llvm-project#188411.
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#154912 (Remove `BuiltinLintDiag`)
- rust-lang/rust#154598 (test `#[naked]` with `#[link_section = "..."]` on windows)
- rust-lang/rust#154719 (Hexagon inline asm: add reg_pair, vreg, vreg_pair, and qreg register classes)
- rust-lang/rust#154057 (Parenthesize block-like expressions in index base of pretty printer)
- rust-lang/rust#154893 (make `expected_literal` positive)
- rust-lang/rust#155002 (Clarify that `core::range` ranges do not have special syntax)
Parenthesize block-like expressions in index base of pretty printer
The AST pretty printer produces invalid Rust when a block expression is the base of an index operation inside a macro expansion. This is a gap in the parenthesization fix from rust-lang/rust#119105 — the `FixupContext` approach handles statement position but not the case where a block-index is nested inside another expression.
The following is a correct program:
```rust
macro_rules! block_arr {
() => {{ [0u8; 4] }};
}
macro_rules! as_slice {
() => {{ &block_arr!()[..] }};
}
fn main() { let _: &[u8] = as_slice!(); }
```
But `rustc -Zunpretty=expanded` produces output that is not valid Rust, because the closing brace of `{ [0u8; 4] }` creates a statement boundary, causing the parser to treat `[..]` as a separate expression:
```rust
fn main() { let _: &[u8] = { &{ [0u8; 4] }[..] }; }
```
```
error: expected one of `.`, `;`, `?`, `}`, or an operator, found `[`
```
Fixed output after this change:
```rust
fn main() { let _: &[u8] = { &({ [0u8; 4] })[..] }; }
```
Since `{ ... }[...]` never parses as indexing a block regardless of context, the fix unconditionally parenthesizes "complete" expressions (block, match, if, loop, etc.) when they appear as the base of an index operation.
test `#[naked]` with `#[link_section = "..."]` on windows
As a part of https://github.com/rust-lang/rust/pull/147811 I ran into that we actually don't match (current) LLVM output.
r? @mati865
Use fine grained component-wise span tracking in use trees
This often produces nicer spans and even doesn't need a Span field anymore (not that I expect the unused field to affect any perf, but still neat).
Cargo submodule update
11 commits in a357df4c26fc14514e66aae2a269456b5545c7db..101549dddbd2b08e806f50154e3aa4cb3374cc21
2026-04-03 16:47:15 +0000 to 2026-04-08 12:51:20 +0000
- Never include use extra-filename in build scripts (rust-lang/cargo#16855)
- fix(toml): Force script edition warnings on quiet (rust-lang/cargo#16848)
- GitHub fast path uses `http_async` (rust-lang/cargo#16847)
- feat(manifest): allow git dependency alongside alternate registry (rust-lang/cargo#16810)
- fix(auth): add auth scheme hint to token rejected error for alt registries (rust-lang/cargo#16794)
- Warn on invalid jobserver file descriptors (rust-lang/cargo#16843)
- docs(unstable): List the minimum required MSRV for 'public' field (rust-lang/cargo#16841)
- feat(lints): Emit unused_dependencies lint (rust-lang/cargo#16600)
- fix(tree): clarify error message when `-i` is used without a package name (rust-lang/cargo#16818)
- fix: Typo in target.<cfg>.linker (rust-lang/cargo#16839)
- Send Content-Type header with cargo publish requests (rust-lang/cargo#16832)
r? ghost
When a macro expands to a call whose callee is a block (or other
"complete" expression like `match`, `if`, `loop`), the AST pretty
printer emits the callee without parentheses. In statement position
the closing brace ends the expression and the argument list is parsed
as a separate tuple expression, producing a parse error.
match exhaustiveness: Show the guard exhaustivity note only when it's the guards alone that cause non-exhaustiveness
Only show the "match arms with guards don't count towards exhaustivity" note when removing all guards would make the match exhaustive, but also in the cases when the match contains arms without guards. Previously, this note was shown only if all arms had guards, but even if the patterns themselves were insufficient to cover all valid values of a type.
Do this by rerunning the exhaustiveness analysis with guards stripped to determine whether the guards are actually the cause of non-exhaustiveness. This only happens on an actual exhaustiveness error, so should not be a performance concern.
This will make a program like:
```rust
fn main() {
let some_condition = true;
let some_option: Option<u8> = None;
let _res = match some_option {
Some(val) if some_condition => val,
None => 0,
};
}
```
produce the note ”match arms with guards don't count towards exhaustivity” that previously would not have been appearing.
Closesrust-lang/rust#104653 as I think this addresses the spirit of that issue. I don’t believe it’s necessary to be any more elaborate in the diagnostics here?
Fix ICE in next-solver dyn-compatibility check
The next solver treated error-containing dispatchability goals as proven and misclassified the trait as dyn compatible. Short-circuit receivers with type errors so object-method confirmation stays on the normal error path.
Tracking issue: rust-lang/rust#130516Closes: rust-lang/rust#151311
Don't store `pattern_ty` in `TestableCase`
This field's only remaining use was in an assertion, but we can perform the same assertion earlier when constructing `TestableCase::Range`.
---
For background, the `pattern_ty` field was introduced in https://github.com/rust-lang/rust/pull/136435 to replace a reference to the full THIR pattern node. Since then, most uses of `pattern_ty` were removed by https://github.com/rust-lang/rust/pull/150238.
Fix private fields diagnostics and improve error messages
Fixesrust-lang/rust#151408
while the best solution may be check whether the code is under user's control, e.g. in the same workspace. but if user does not provide some fields, mention other private fields seems weird, see the test case:
```console
LL | let _ = std::collections::HashMap {};
| ^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: private field `base` that was not provided
```
since we already suggested to use associated function to construct, it's better to remove the note.
this fix only provide note on private fields when `did.is_local()` or user have already provide some fields.
move borrow checker tests
Hi, I have moved some tests I think should be in the borrowck category. Please let me know if there are issues. r? @Kivooeo
Related to rust-lang/rust#133895
remove unnecessary variables and delimiter check
Zulip discussion: https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/question.20about.20lex_token_tree_open_delim.20in.20rustc_parse/with/580552157
In `lex_token_tree_open_delim`, after calling `self.lex_token_trees(/* is_delimited */ true)`:
- If the delimiters are well-balanced, the value popped from the stack will always equal to `open_delim` and `pre_span`.
- If the delimiters are not balanced, `self.lex_token_trees(/* is_delimited */ true)` will return an error so this branch will not be reached
Therefore `open_delimiter` and `open_delimiter_span` can be removed.
Test `tests/ui/parser` all passed
constify DoubleEndedIterator
The only functions that can't be constified are `advance_back_by` (requires const range or const-hack), `nth_back` (requires `advance_back_by`), and `rfind` (requires const closures).
I've put it under `const_iter`, but I can open a separate tracking issue, though I think tracking all `Iterator` traits separately would be quite annoying, and we probably would prefer to constify them together anyway.
Folkert de Vries