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
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#147585 (Suppress the error for private fields with non_exhaustive attribute)
- rust-lang/rust#149215 (Emit `check-cfg` lints during attribute parsing rather than evaluation)
- rust-lang/rust#149652 (Add release notes for 1.92.0)
- rust-lang/rust#149720 (rustdoc book: mention inner doc attribute)
- rust-lang/rust#149730 (lint: emit proper diagnostic for unsafe binders in improper_ctypes instead of ICE)
- rust-lang/rust#149754 (Retire `opt_str2` from compiletest cli parsing)
- rust-lang/rust#149755 (bootstrap: Use a `CompiletestMode` enum instead of bare strings)
- rust-lang/rust#149763 (Add inline attribute to generated delegation function if needed)
- rust-lang/rust#149772 (test: Add a test for 146133)
- rust-lang/rust#149779 (Fix typo "an" → "and")
- rust-lang/rust#149782 (Remove `[no-mentions]` handler in the triagebot config)
Failed merges:
- rust-lang/rust#148491 ( Correctly provide suggestions when encountering `async fn` with a `dyn Trait` return type)
r? `@ghost`
`@rustbot` modify labels: rollup
This commit is a large change to the implementation of filesystem and
other system-related operations on WASI targets. Previously the standard
library explicitly used the `wasi` crate at the 0.11.x version track
which means that it used WASIp1 APIs directly. This meant that `std` was
hard-coded to use WASIp1 syscalls and there was no separate
implementation for the WASIp{2,3} targets, for example. The high-level
goal of this commit is to decouple this interaction and avoid the use of
the `wasi` crate on the WASIp2 target.
Historically when WASIp1 was originally added to Rust the wasi-libc
library was in a much different position than it is today. Nowadays Rust
already depends on wasi-libc on WASI targets for things like memory
allocation and environment variable management. As a libc library it
also has all the functions necessary to implement all filesystem
operations Rust wants. Recently wasi-libc additionally was updated to
use WASIp2 APIs directly on the `wasm32-wasip2` target instead of using
`wasm32-wasip1` APIs. This commit is leveraging this work by enabling
Rust to completely sever the dependence on WASIp1 APIs when compiling
for `wasm32-wasip2`. This is also intended to make it easier to migrate
to `wasm32-wasip3` internally in the future where now only libc need be
updated and Rust doesn't need to explicitly change as well.
The overall premise of this commit is that there's no need for
WASI-specific implementation modules throughout the standard library.
Instead the libc-style bindings already implemented for Unix-like
targets are sufficient. This means that Rust will now be using
libc-style interfaces to interact with the filesystem, for example, and
wasi-libc is the one responsible for translating these POSIX-ish
functions into WASIp{1,2} calls.
Concrete changes here are:
* `std` for `wasm32-wasip2` no longer depends on `wasi 0.11.x`
* The implementation of `std::os::wasi::fs`, which was previously
unstable and still is, now has portions gated to only work on the
WASIp1 target which use the `wasi` crate directly. Traits have been
trimmed down in some cases, updated in others, or now present a
different API on WASIp1 and WASIp2. It's expected this'll get further
cleanup in the future.
* The `std::sys::fd::wasi` module is deleted and `unix` is used instead.
* The `std::sys::fs::wasi` module is deleted and `unix` is used instead.
* The `std::sys::io::io_slice::wasi` module is deleted and `unix` is used
instead.
* The `std::sys::pal::{wasip1,wasip2}` modules are now merged together
as their difference is much smaller than before.
* The `std::sys::pal::wasi::time` is deleted and the `unix` variant is
used directly instead.
* The `std::sys::stdio::wasip{1,2}` modules are deleted and the `unix`
variant is used instead.
* The `std::sys:🧵:wasip{1,2}` modules are deleted and the `unix`
variant is used instead.
Overall Rust's libstd is effectively more tightly bound to libc when
compiled to WASI targets. This is intended to mirror how it's expected
all other languages will also bind to WASI. This additionally has the
nice goal of drastically reducing the WASI-specific maintenance burden
in libstd (in theory) and the only real changes required here are extra
definitions being added to `libc` (done in separate PRs). This might be
required for more symbols in the future but for now everything should be
mostly complete.
Update t-compiler beta nomination Zulip msg
Sister patch of [triagebot#2191](https://github.com/rust-lang/triagebot/pull/2191)
Follow-up to rust-lang/rust#147263
The triagebot now triggers a different message when a PR is nominated for backport, making it look like more a suggestion to evaluate for the author/reviewers than a mandatory decision for the team to take.
The wording (as per [triagebot#2191](https://github.com/rust-lang/triagebot/pull/2191)) is open to suggestions.
Thanks
No prejudice against re-enabling them if the nominations include a bit
more context on _why_ it's automatically nominated and _which_
regression(s) are being addressed. Or as proposed, it could also simply
become a reminder-to-nominate _comment_.
Simplify rustdoc-gui tester by calling directly browser-ui-test
The output and handling of `browser-ui-test` is now mostly the same as we did manually, so no need to keep our wrapper anymore. Lot of code removed! \o/
r? `@lolbinarycat`
Split `run-make` into two {`run-make`,`run-make-cargo`} test suites
## Summary
Split `tests/run-make` into two test suites, to make it faster and more convenient for contributors to run run-make tests that do not need in-tree `cargo`.
| New test suites | Explanation |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `tests/run-make` | The "fast path" test suite intended for run-make tests that do not need in-tree `cargo`. These tests may not use `cargo`. |
| `tests/run-make-cargo` | The "slow path" test suite that requires checking out `cargo` submodule and building in-tree `cargo`, and thus will have access to in-tree `cargo`. In practice, these constitute a very small portion of the original `run-make` tests. |
This PR carries out [MCP 847: Split run-make test suite into slower-building test suite with suitably-staged cargo and faster-building test suite without cargo](https://github.com/rust-lang/compiler-team/issues/847).
Fixesrust-lang/rust#135573 (for the tests that do not need in-tree `cargo`).
Fixesrust-lang/rust#134109.
## Remarks
- I considered if we want to split by in-tree tools previously. However, as discussed rust-lang/rust#134109, in practice `rustdoc` is not very slow to build, but `cargo` takes a good few minutes. So, the partition boundary was determined to be along in-tree `cargo` availability.
- The `run-make` tests previously that wanted to use `cargo` cannot just use the bootstrap `cargo`, otherwise they would run into situations where bootstrap `cargo` can significantly diverge from in-tree `cargo` (see https://github.com/rust-lang/rust/pull/130642).
---
try-job: aarch64-msvc-1
try-job: test-various
try-job: x86_64-gnu-debug
try-job: aarch64-gnu-debug
try-job: aarch64-apple
try-job: dist-various-1
Add `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` symbols
## Motivation
When Objective-C code uses ```@available(...)`,`` Clang inserts a call to [`__isPlatformVersionAtLeast`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/compiler-rt/lib/builtins/os_version_check.c#L276) (`__isOSVersionAtLeast` in older Clang versions). These symbols not being available sometimes ends up causing linker errors. See the new test `tests/run-make/apple-c-available-links` for a minimal reproducer.
The workaround is to link `libclang_rt.osx.a`, see e.g. https://github.com/alexcrichton/curl-rust/issues/279. But that's very difficult for users to figure out (and the backreferences to that issue indicates that people are still running into this in their own projects every so often).
For another recent example, this is preventing `rustc` from using LLVM assertions on macOS, see https://github.com/rust-lang/rust/pull/62592#issuecomment-510670657 and https://github.com/rust-lang/rust/pull/134275#issuecomment-2543067830.
It is also a blocker for [setting the correct minimum OS version in `cc-rs`](https://github.com/rust-lang/rust/issues/136113), since fixing this in `cc-rs` might end up introducing linker errors in places where we weren't before (by default, if using e.g. ```@available(macos`` 10.15, *)`, the symbol usually happens to be left out, since `clang` defaults to compiling for the host macOS version, and thus things _seem_ to work - but the availability check actually compiles down to nothing, which is a huge correctness footgun for running on older OSes).
(My super secret evil agenda is also to expose some variant of ```@available``` in Rust's `std` after https://github.com/rust-lang/rfcs/pull/3750 progresses further, will probably file an ACP for this later. But I believe this PR has value regardless of those future plans, since we'd be making C/Objective-C/Swift interop easier).
## Solution
Implement `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast` as part of the "public ABI" that `std` exposes.
**This is insta-stable**, in the same sense that additions to `compiler-builtins` are insta-stable, though the availability of these symbols can probably be considered a "quality of implementation" detail rather than a stable promise.
I originally proposed to implement this in `compiler-builtins`, see https://github.com/rust-lang/compiler-builtins/pull/794, but we discussed moving it to `std` instead ([Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Provide.20.60__isPlatformVersionAtLeast.60.20in.20.60std.60.3F/with/507880717)), which makes the implementation substantially simpler, and we avoid gnarly issues with requiring the user to link `libSystem.dylib` (since `std` unconditionally does that).
Note that this does not solve the linker errors for (pure) `#![no_std]` users, but that's _probably_ fine, if you are using ```@available``` to test the OS version on Apple platforms, you're likely also using `std` (and it is still possible to work around by linking `libclang_rt.*.a`).
A thing to note about the implementation, I've choosen to stray a bit from LLVM's upstream implementation, and not use `_availability_version_check` since [it has problems when compiling with an older SDK](https://github.com/llvm/llvm-project/issues/64227). Instead, we use `sysctl kern.osproductversion` when available to still avoid the costly PList lookup in most cases, but still with a fall back to the PList lookup when that is not available (with the PList fallback being is similar to LLVM's implementation).
## Testing
Apple has a lot of different "modes" that they can run binaries in, which can be a bit difficult to find your bearings in, but I've tried to be as thorough as I could in testing them all.
Tested using roughly the equivalent of `./x test library/std -- platform_version` on the following configurations:
- macOS 14.7.3 on a Macbook Pro M2
- `aarch64-apple-darwin`
- `x86_64-apple-darwin` (under Rosetta)
- `aarch64-apple-ios-macabi`
- `x86_64-apple-ios-macabi` (under Rosetta)
- `aarch64-apple-ios` (using Xcode's "Designed for iPad" setting)
- `aarch64-apple-ios-sim` (in iOS Simulator, as iPhone with iOS 17.5)
- `aarch64-apple-ios-sim` (in iOS Simulator, as iPad with iOS 18.2)
- `aarch64-apple-tvos-sim` (in tvOS Simulator)
- `aarch64-apple-watchos-sim` (in watchOS Simulator)
- `aarch64-apple-ios-sim` (in visionOS simulator, using Xcode's "Designed for iPad" setting)
- `aarch64-apple-visionos-sim` (in visionOS Simulator)
- macOS 15.3.1 VM
- `aarch64-apple-darwin`
- `aarch64-apple-ios-macabi`
- macOS 10.12.6 on an Intel Macbook from 2013
- `x86_64-apple-darwin`
- `i686-apple-darwin`
- `x86_64-apple-ios` (in iOS Simulator)
- iOS 9.3.6 on a 1st generation iPad Mini
- `armv7-apple-ios` with an older compiler
Along with manually inspecting the output of `version_from_sysctl()` and `version_from_plist()`, and verifying that they actually match what's expected.
I believe the only real omissions here would be:
- `aarch64-apple-ios` on a newer iPhone that has `sysctl` available (iOS 11.4 or above).
- `aarch64-apple-ios` on a Vision Pro using Xcode's "Designed for iPad" setting.
But I don't have the hardware available to test those.
``@rustbot`` label O-apple A-linkage -T-compiler -A-meta -A-run-make
try-job: aarch64-apple
