As Intel has walked back on the existence of AVX 10.1-256, LLVM
no longer uses evex512 and avx-10.n-512 are now avx-10.n instead,
so we can skip all the special handling on LLVM 22.
rustdoc: Fix ICE when deprecated note is not resolved on the correct `DefId`
Supersedes https://github.com/rust-lang/rust/pull/151237.
Follow-up of rust-lang/rust#151120.
The `span` overlapping approach wasn't good enough so instead we now check if the reexport itself has the `deprecated` attribute, and if so, we resolve the path to the reexport `DefId`, otherwise we resolve it on the reexported item's `DefId`.
cc @Zalathar
r? @lolbinarycat
Add new "hide deprecated items" setting in rustdoc
This PR adds a new JS setting which allows the JS to hide deprecated items. This is especially useful for crates like `std` which accumulates deprecated items but never removes them.
Nicely enough, the "deprecation" information was already in the search index, meaning I didn't need to change anything there. Before this PR, it was only used to make the deprecated items rank lower. Well now it's also used to generate an extra CSS class, allowing the JS setting to work.
This is taking over https://github.com/rust-lang/rust/pull/149551.
This feature got approved by the rustdoc team in the [meeting of december](https://rust-lang.zulipchat.com/#narrow/channel/393423-t-rustdoc.2Fmeetings/topic/2025-12-08/near/562553156).
You can give it a try [here](https://rustdoc.crud.net/imperio/hide-deprecated-items/foo/index.html).
r? @lolbinarycat
Add scalar support for offload
This PR adds scalar support to the offload feature. The scalar management has two main parts:
On the host side, each scalar arg is casted to `ix` type, zero extended to `i64` and passed to the kernel like that.
On the device, the each scalar arg (`i64` at that point), is truncated to `ix` and then casted to the original type.
r? @ZuseZ4
Add dist step for Enzyme
Now that Enzyme can be distributed as a separate dylib outside libLLVM.so, we can create a dist step for it. This is the bulk of the work required to make it distributable through rustup, once CI works and we check that the built component works locally, we can add it to Rustup through the manifest.
Note that this PR does not enable Enzyme distribution in CI yet, it just adds the dist step.
r? @ZuseZ4
try-job: dist-x86_64-linux
coverage: Sort the expansion tree to help choose a single BCB for child expansions
This PR is another incremental step on the road towards proper coverage instrumentation of expansion regions.
When creating coverage mappings for each relevant span in a function body, the current implementation also needs to do a separate tree traversal for each child expansion (e.g. macro calls like `println!("foo")`), in order to associate a single control-flow point (BCB) with that macro call's span.
This PR changes things so that we now keep track of the “minimum” and ”maximum” BCB associated with each node in the expansion tree, which makes it much easier for the parent node to get a single BCB (min or max) for each of its child expansions.
In order to make this (relatively) easy, we first need to sort the tree nodes into depth-first order. Once that's taken care of, we can iterate over all the nodes in reverse order, knowing that each node's children will have been visited before visiting the node itself.
compiler: upgrade to hashbrown 0.16.1
See also rust-lang/rust#135634, rust-lang/rust#149159, and rust-lang/hashbrown#662.
This includes an in-tree upgrade of `indexmap` as well, which uses the
new `HashTable` buckets API internally, hopefully impacting performance
for the better.
And finally, we can remove `#[rustc_unsafe_specialization_marker]` on `Copy`!
cc @joboet
r? @Amanieu
Remove `DiagMessage::Translated` in favour of `DiagMessage::Str`
This variant did not seem to be meaningfully different from `DiagMessage::Str`.
Am I missing something or was this just an oversight?
r? @davidtwco
THIR patterns: Use `ty::Value` in more places throughout `const_to_pat`
This PR changes `ConstToPat::valtree_to_pat` to take a `ty::Value` instead of separate type and valtree arguments, and propagates that change throughout other parts of the overall `const_to_pat` implementation.
The biggest under-the-hood change is that instead of combining valtrees from the constant with child types from the parent type, we now just rely on the types already embedded in children of the valtree.
I'm not *entirely* sure that this is correct, but it doesn't seem to cause any failures in the test suite, and from what I can tell the old way was a holdover from a time when the types weren't readily available from the value side.
---
My ulterior motive for this cleanup is that I'm hoping to eventually add some extra data to `thir::PatKind::Const`, which will be a little easier if creation of that `PatKind::Const` doesn't have to assemble a `ty::Value` from component parts.
HIR typeck cleanup: clarify and re-style `check_expr_unop`
Two small cleanups:
- The `oprnd_t` variable was previously used both for the type of unary operators' operands and for the type of the operator expression as a whole. I found this confusing, so I've changed it to only be used for the operand type. This also allowed for removing some negations from `if` conditions.
- I did a bit of re-styling in the second commit to remove some indentation levels, which also means fewer things have to be spread across multiple lines. This part is more to-taste; I'd be fine dropping it if it doesn't actually help.
Do not recover from `Trait()` if generic list is unterminated
If we encounter `fn foo<T: Trait()`, the recovery logic would it as if `Trait` was intended to use the Fn-like trait syntax, but if we don't know for certain that we've parsed a full trait bound (`fn foo<T: Trait()>`), we bail from the recovery as more likely there could have been a missing closing `>` and the `(` corresponds to the start of the fn parameter list.
Fixrust-lang/rust#141436.
Support pointers in type reflection
Tracking issue: rust-lang/rust#146922
This PR adds support for inspecting pointers `*const T` and `*mut T` through type reflection. It does so by adding the new `Pointer` struct + variant:
```rust
pub struct Pointer {
/// The type of the value being pointed to.
pub ty: TypeId,
/// Whether this pointer is mutable or not.
pub mutable: bool,
}
```
This can be gathered using `Type::of`, for example:
```rust
match const { Type::of::<*const u8>() }.kind {
TypeKind::Pointer(pointer) => {
assert_eq!(pointer.ty, TypeId::of::<u8>());
assert!(!pointer.mutable);
}
_ => unreachable!(),
}
```
Simplify some literal-value negations with `u128::wrapping_neg`
- Calling `overflowing_neg` and then discarding the overflow bit is the same as just calling `wrapping_neg`.
- Casting to `u128` to `i128`, negating, and then casting back produces the same result as just performing an unsigned `wrapping_neg`.
There should be no actual change to compiler behaviour.
std: implement `sleep_until` on Apple platforms
On Apple platforms, `nanosleep` is internally [implemented](55b54c0a0c/gen/nanosleep.c (L281)) using `mach_wait_until`, a function that waits until a deadline specified in terms of `mach_absolute_time`. Since `mach_wait_until` is [public](f6217f891a/osfmk/mach/mach_time.h (L50-L51))[^1], we can use it to implement `sleep_until` by converting `Instant`s (which are measured against `CLOCK_UPTIME_RAW`, which is equivalent to `mach_absolute_time`) into `mach_absolute_time` values.
Related tracking issue: https://github.com/rust-lang/rust/issues/113752
[^1]: It's badly documented, but it's defined in the same header as `mach_absolute_time`, which `std` used to use for `Instant` before rust-lang/rust#116238.
remote-test-server: Fix header in batch mode
In https://github.com/rust-lang/rust/pull/119999, the length field of the header was changed from 4 bytes to 8. One of the headers in `batch_copy` was missed though, so it sends the wrong size. Fix by switching to `create_header` in that spot too.
rustc_errors: Add (heuristic) Syntax Highlighting for `rustc --explain`
This PR adds a feature that enables `rustc --explain <error>` to have syntax highlighted code blocks. Due to performance, size and complexity constraints, the highlighter is very heuristc, relying on conventions for capitalizations and such to infer what an identifier represents. The details for the implementation are specified below.
# Changes
1. Change `term::entrypoint` to `term::entrypoint_with_formatter`, which takes an optional third argument, which is a function pointer to a formatter. ([compiler/rustc_errors/src/markdown/mod.rs](https://github.com/rust-lang/rust/compare/main...JayanAXHF:rust:rustc_colored_explain?expand=1#diff-a6e139cadbc2e6922d816eb08f9e2c7b48304d09e6588227e2b70215c4f0725c))
2. Change `MdStream::write_anstream_buf` to be a wrapper around a new function, `MdStream::write_anstream_buf_with_formatter`, which takes a function pointer to a formatter. ([compiler/rustc_errors/src/markdown/mod.rs](https://github.com/rust-lang/rust/compare/main...JayanAXHF:rust:rustc_colored_explain?expand=1#diff-a6e139cadbc2e6922d816eb08f9e2c7b48304d09e6588227e2b70215c4f0725c))
3. Change [`compiler/rustc_driver_impl/src/lib.rs`](https://github.com/rust-lang/rust/compare/main...JayanAXHF:rust:rustc_colored_explain?expand=1#diff-39877a2556ea309c89384956740d5892a59cef024aa9473cce16bbdd99287937) to call `MdStream::write_anstream_buf_with_formatter` instead of `MdStream::write_anstream_buf`.
4. Add a `compiler/rustc_driver_impl/src/highlighter.rs` file, which contains the actual syntax highlighter.
# Implementation Details
1. The highlighter starts from the `highlight` function defined in `compiler/rustc_driver_impl/src/highlighter.rs`. It creates a new instance of the `Highlighter` struct, and calls its `highlight_rustc_lexer` function to start highlighting.
2. The `highlight_rustc_lexer` function uses `rustc_lexer` to lex the code into `Token`s. `rustc_lexer` was chosen since it preserves the newlines after scanning.
3. Based on the kind of token (`TokenKind`), we color the corresponding lexeme.
## Highlighter Implementation
### Identifiers
1. All identifiers that match a (non-exhaustive and minimal) list of keywords are coloured magenta.
2. An identifier that begins with a capital letter is assumed as a type. There is no distinction between a `Trait` and a type, since that would involve name resolution, and the parts of `rustc` that perform name resolution on code do not preserve the original formatting. (An attempt to use `rustc_parse`'s lexer and `TokenStream` was made, which was then printed with the pretty printer, but failed to preserve the formatting and was generally more complex to work with)
3. An identifier that is immediately followed by a parenthesis is recognized as a function identifier, and coloured blue.
## Literals
5. A `String` literal (or its corresponding `Raw`, `C` and `Byte` versions) is colored green.
6. All other literals are colored bright red (orange-esque)
## Everything Else
Everything else is colored bright white and dimmed, to create a grayish colour.
---
# Demo
<img width="1864" height="2136" alt="image" src="https://github.com/user-attachments/assets/b17d3a71-e641-4457-be85-5e5b1cea2954" />
<caption> Command: <code>rustc --explain E0520</code> </caption>
---
This description was not generated by an LLM (:p)
cc: @bjorn3
Remove the diagnostic lints
Removes the `untranslatable_diagnostic` and `diagnostic_outside_of_impl` lints
These lints are allowed for a while already. Per https://github.com/rust-lang/compiler-team/issues/959, we no longer want to enforce struct diagnostics for all usecases, so this is no longer useful.
r? @Kivooeo
I recommend reviewing commit by commit (also feel free to wait with reviewing until the MCP is accepted)
@rustbot +S-blocked
Blocked by https://github.com/rust-lang/compiler-team/issues/959
Ignore `#[doc(hidden)]` items when computing trimmed paths for printing
The `trimmed_def_paths` query examines all items in the current crate, and all pub items in immediate-dependency crates (including the standard library), to see which item names are unique and can therefore be printed unambiguously as a bare name without a module path.
Currently that query has no special handling for `#[doc(hidden)]` items, which has two consequences:
- Hidden names can be considered unique, and will therefore be printed without a path, making it hard to find where that name is defined (since it normally isn't listed in documentation).
- Hidden names can conflict with visible names that would otherwise be considered unique, causing diagnostics to mysteriously become more verbose based on internal details of other crates.
This PR therefore makes the `trimmed_def_paths` query ignore external-crate items that are `#[doc(hidden)]`, along with their descendants.
As a result, hidden item names are never considered unique for trimming, and no longer interfere with visible item names being considered unique.
---
- Fixes https://github.com/rust-lang/rust/issues/148387.
