triagebot: roll library reviewers for `{coretests,alloctests}`
Noticed in https://github.com/rust-lang/rust/pull/154761 that we are currently rolling fallback reviewers for `library/{alloctests,coretests}`
r? libs
Clang changed to representing tuples of scalable vectors as
structs rather than as wide vectors (that is, scalable vector types
where the `N` part of the `<vscale x N x ty>` type was multiplied by
the number of vectors). rustc mirrored this in the initial implementation
of scalable vectors.
Earlier versions of our patches used the wide vector representation and
our intrinsic patches used the legacy
`llvm.aarch64.sve.tuple.{create,get,set}{2,3,4}` intrinsics for creating
these tuples/getting/setting the vectors, which were only supported
due to LLVM's `AutoUpgrade` pass converting these intrinsics into
`llvm.vector.insert`. `AutoUpgrade` only supports these legacy intrinsics
with the wide vector representation.
With the current struct representation, Clang has special handling in
codegen for generating `insertvalue`/`extractvalue` instructions for
these operations, which must be replicated by rustc's codegen for our
intrinsics to use. This patch implements new intrinsics in
`core::intrinsics::scalable` (mirroring the structure of
`core::intrinsics::simd`) which rustc lowers to the appropriate
`insertvalue`/`extractvalue` instructions.
Notify stdarch maintainers on changes in std_detect
cc @Amanieu @folkertdev @Kobzol
It would be nice to be notified when std_detect changes, as it is spiritually a part of stdarch.
Also assign @rust-lang/libs to std_detect
num: Separate public API from internal implementations
Currently we have a single `core::num` module that contains both thin wrapper API and higher-complexity numeric routines. Restructure this by moving implementation details to a new `imp` module.
This results in a more clean separation of what is actually user-facing compared to items that have a stability attribute because they are public for testing.
The first commit does the actual change then the second moves a portion back.
Most of the files within the `dep_graph` module can be moved wholesale
into `rustc_middle`. But two of them (`mod.rs` and `dep_node.rs`) have
the same name as existing files in `rustc_middle`, so for those I just
copied the contents into the existing files.
The commit also moves `QueryContext` and `incremental_verify_ich*`
because they are tightly intertwined with the dep graph code. And a
couple of error structs moved as well.
Currently we have a single `core::num` module that contains both thin
wrapper API and higher-complexity numeric routines. Restructure this by
moving implementation details to a new `imp` module.
This results in a more clean separation of what is actually user-facing
compared to items that have a stability attribute because they are
public for testing.
Remove the compiler adhoc group
Since triagebot now allows configuring rotation mode through a specific team.
Original review rotation:
```toml
compiler = [
"@BoxyUwU",
"@chenyukang",
"@davidtwco",
"@eholk",
"@fee1-dead",
"@fmease",
"@jackh726",
"@jieyouxu",
"@jdonszelmann",
"@JonathanBrouwer",
"@madsmtm",
"@mati865",
"@Nadrieril",
"@nnethercote",
"@oli-obk",
"@petrochenkov",
"@SparrowLii",
"@TaKO8Ki",
"@tiif",
"@WaffleLapkin",
"@wesleywiser",
]
```
I went through all the remaining members of t-compiler now and set their `compiler` team rotation to be off, to match the original state. You can check it with `team-stats compiler`.
r? @davidtwco
triagebot: add A-rustdoc-js autolabel
Adds an autolabel rule for rustdoc JavaScript/TypeScript files so PRs touching
rustdoc frontend assets and related tests are automatically labeled `A-rustdoc-js`.
Fixesrust-lang/rust#137983
Reflection MVP
I am opening this PR for discussion about the general design we should start out with, as there are various options (that are not too hard to transition between each other, so we should totally just pick one and go with it and reiterate later)
r? @scottmcm and @joshtriplett
project goal issue: https://github.com/rust-lang/rust-project-goals/issues/406
tracking issue: https://github.com/rust-lang/rust/issues/146922
The design currently implemented by this PR is
* `TypeId::info` (method, usually used as `id.info()` returns a `Type` struct
* the `Type` struct has fields that contain information about the type
* the most notable field is `kind`, which is a non-exhaustive enum over all possible type kinds and their specific information. So it has a `Tuple(Tuple)` variant, where the only field is a `Tuple` struct type that contains more information (The list of type ids that make up the tuple).
* To get nested type information (like the type of fields) you need to call `TypeId::info` again.
* There is only one language intrinsic to go from `TypeId` to `Type`, and it does all the work
An alternative design could be
* Lots of small methods (each backed by an intrinsic) on `TypeId` that return all the individual information pieces (size, align, number of fields, number of variants, ...)
* This is how C++ does it (see https://lemire.me/blog/2025/06/22/c26-will-include-compile-time-reflection-why-should-you-care/ and https://isocpp.org/files/papers/P2996R13.html#member-queries)
* Advantage: you only get the information you ask for, so it's probably cheaper if you get just one piece of information for lots of types (e.g. reimplementing size_of in terms of `TypeId::info` is likely expensive and wasteful)
* Disadvantage: lots of method calling (and `Option` return types, or "general" methods like `num_fields` returning 0 for primitives) instead of matching and field accesses
* a crates.io crate could implement `TypeId::info` in terms of this design
The backing implementation is modular enough that switching from one to the other is probably not an issue, and the alternative design could be easier for the CTFE engine's implementation, just not as nice to use for end users (without crates wrapping the logic)
One wart of this design that I'm fixing in separate branches is that `TypeId::info` will panic if used at runtime, while it should be uncallable