rename `select_where_possible` and `select_all_or_error`
r? `@lcnr`
I find that people get confused by what these methods do. The verb "select" is not really that helpful and is just a reference to somewhat of an implementation detail of the trait solvers that doesn't even apply to most obligation kinds.
I went with `try_evaluate_obligations` and `evaluate_obligations_error_on_ambiguity`. This maintains consistency with the new solvers `evalute_goal` entry point. it's unfortunate that we say obligations rather than goals but this maintains consistency with `register_obligation` functions which I think is a good thing. In the long term possibly we rename `Obligation` or `Goal` 🤷♀️
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#146865 (kcfi: only reify trait methods when dyn-compatible)
- rust-lang/rust#147205 (Add a new `wasm32-wasip3` target to Rust)
- rust-lang/rust#147322 (cg_llvm: Consistently import `llvm::Type` and `llvm::Value`)
- rust-lang/rust#147398 (Fix; correct placement of type inference error for method calls)
- rust-lang/rust#147410 (Update `S-waiting-on-team` refs to new `S-waiting-on-{team}` labels)
- rust-lang/rust#147422 (collect-license-metadata: Print a diff of the expected output)
- rust-lang/rust#147431 (compiletest: Read the whole test file before parsing directives)
- rust-lang/rust#147433 (Fix doc comment)
Failed merges:
- rust-lang/rust#147390 (Use globals instead of metadata for std::autodiff)
r? `@ghost`
`@rustbot` modify labels: rollup
compiletest: Read the whole test file before parsing directives
Few tests are larger than a handful of kilobytes, and nowadays we scan the whole file for directives anyway, so there's little reason not to just read the whole thing up-front.
This avoids having to deal with I/O within `iter_directives`, which should make it easier to overhaul directive processing.
r? jieyouxu
collect-license-metadata: Print a diff of the expected output
Previously, `x test collect-license-metadata` gave the following message on errors:
```
gathering license information from REUSE (this might take a minute...)
finished gathering the license information from REUSE in 78.69s
loading existing license information
The existing /home/runner/work/ferrocene/ferrocene/license-metadata.json
file is out of date.
Run ./x run collect-license-metadata to update it.
Error: The existing
/home/runner/work/ferrocene/ferrocene/license-metadata.json file doesn't
match what REUSE reports.
Bootstrap failed while executing `test collect-license-metadata`
```
Notable, this doesn't actually say what went wrong. Print a diff in addition so it's more clear what broke:
```
...
"license": {
"copyright": [
+ "2010 The Rust Project Developers",
"2016, 2017, 2018, 2019, 2020, 2021 AXE Consultants. All Rights",
+ "License. Subject to the terms and conditions of this",
"Notice",
- "The Ferrocene Developers"
+ "The Ferrocene Developers",
+ "[yyyy] [name of copyright owner]"
],
...
```
Currently, this prints the entire text of the JSON file as context. That's not ideal, but it's rare for this to fail, so I think it's ok for now.
I considered using `assert_json_diff` instead of `similar`, but its errors are a lot harder to read IMO, even though they are better at omitting unnecessary context:
```
Diff: json atoms at path ".files.children[0].children[10].license.copyright[0]" are not equal:
lhs:
"2016 The Fuchsia Authors"
rhs:
"2019 The Crossbeam Project Developers"
json atoms at path ".files.children[0].children[10].license.spdx" are not equal:
lhs:
"BSD-2-Clause AND (Apache-2.0 OR MIT)"
rhs:
"Apache-2.0 OR MIT"
json atom at path ".files.children[0].children[10].children" is missing from lhs
json atoms at path ".files.children[0].children[10].name" are not equal:
lhs:
"library/std/src/sys/sync/mutex/fuchsia.rs"
rhs:
"library/std/src/sync/mpmc"
...
```
Add a new `wasm32-wasip3` target to Rust
This commit adds a new tier 3 target to rustc, `wasm32-wasip3`. This follows in the footsteps of the previous `wasm32-wasip2` target and is used to represent binding to the WASIp3 set of APIs managed by the WASI subgroup to the WebAssembly Community Group.
As of now the WASIp3 set of APIs are not finalized nor standardized. They're in the process of doing so and the current trajectory is to have the APIs published in December of this year. The goal here is to get the wheels turning in Rust to have the target in a
more-ready-than-nonexistent state by the time this happens in December.
For now the `wasm32-wasip3` target looks exactly the same as `wasm32-wasip2` except that `target_env = "p3"` is specified. This indicates to crates in the ecosystem that WASIp3 APIs should be used, such as the [`wasip3` crate]. Over time this target will evolve as implementation in guest toolchains progress, notably:
* The standard library will use WASIp3 APIs natively once they're finalized in the WASI subgroup.
* Support through `wasi-libc` will be updated to use WASIp3 natively which Rust will then transitively use.
* Longer-term, features such as cooperative multithreading will be added to the WASIp3-track of targets to enable using `std::thread`, for example, on this target.
These changes are all expected to be non-breaking changes for users of this target. Runtimes supporting WASIp3, currently Wasmtime and Jco, support WASIp2 APIs as well and will work with components whether or not they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This means that changing the internal implementation details of libstd over time is expected to be a non-breaking change.
[`wasip3` crate]: https://crates.io/crates/wasip3
Print tip for human error format in runtest
When working on https://github.com/rust-lang/rust/pull/147354, spent some time to figure out that there is `//~ ERROR` left on test file, this PR will give a better error message for this scenario.
Few tests are larger than a handful of kilobytes, and nowadays we scan the
whole file for directives anyway, so there's little reason not to just read the
whole thing up-front.
This avoids having to deal with I/O within `iter_directives`, which should make
it easier to overhaul directive processing.
Update books
## rust-lang/reference
4 commits in e11adf6016a362766eea5a3f9832e193994dd0c8..8efb9805686722dba511b7b27281bb6b77d32130
2025-10-06 15:04:20 UTC to 2025-10-01 17:30:01 UTC
- Clarify that "or it is dropped" is meant restrictively (rust-lang/reference#2035)
- add lifetime extension tests for tuple struct temporaries (rust-lang/reference#2033)
- Add `target_env = "macabi"` and `target_env = "sim"` (rust-lang/reference#1781)
- Typo fixes for the Tokens page (additions -> editions) (rust-lang/reference#2031)
Fluent tidy improvements
Follow-up of rust-lang/rust#147345 and of rust-lang/rust#147191.
It uses `fluent_syntax` to parse `fluent` files (but not for blessing, not even sure how the current one works).
I also added an `assert` to ensure we never go to previous situation where the `fluent` files were actually not checked at all.
cc ``@Kivooeo``
r? kobzol
test: Subtract code_offset from width for ui_testing
`annotate-snippets` does not have a "UI test" mode like `rustc`, [where the code offset is not subtracted from the column width](https://github.com/rust-lang/rust/blob/f34ba774c78ea32b7c40598b8ad23e75cdac42a6/compiler/rustc_errors/src/emitter.rs#L1985-L1987). This makes it so `annotate-snippets` will shift the output for some very long tests 5 - 7 columns to the left. As part of my work to have `rustc` use `annotate-snippets`, and to reduce the test differences between the two, I figured it would be best if `rustc` started subtracting the code offset from the width as well.
The first commit exists to keep the test output changes of adding a new line to a test separate from adding the `--diagnostic-width` flag in the second commit. This makes it easier to verify that adding the flag does not affect the test's output.
[Zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/147480-t-compiler.2Fdiagnostics/topic/annotate-snippets.20hurdles)
Previously, `x test collect-license-metadata` gave the following message
on errors:
```
gathering license information from REUSE (this might take a minute...)
finished gathering the license information from REUSE in 78.69s
loading existing license information
The existing /home/runner/work/ferrocene/ferrocene/license-metadata.json
file is out of date.
Run ./x run collect-license-metadata to update it.
Error: The existing
/home/runner/work/ferrocene/ferrocene/license-metadata.json file doesn't
match what REUSE reports.
Bootstrap failed while executing `test collect-license-metadata`
```
Notable, this doesn't actually say what went wrong.
Print a diff in addition so it's more clear what broke:
```
...
"license": {
"copyright": [
+ "2010 The Rust Project Developers",
"2016, 2017, 2018, 2019, 2020, 2021 AXE Consultants. All Rights",
+ "License. Subject to the terms and conditions of this",
"Notice",
- "The Ferrocene Developers"
+ "The Ferrocene Developers",
+ "[yyyy] [name of copyright owner]"
],
...
```
Currently, this prints the entire text of the JSON file as context.
That's not ideal, but it's rare for this to fail, so I think it's ok for
now.
I considered using `assert_json_diff` instead of `similar`, but its
errors are a lot harder to read IMO, even though they are better at
omitting unnecessary context:
```
Diff: json atoms at path ".files.children[0].children[10].license.copyright[0]" are not equal:
lhs:
"2016 The Fuchsia Authors"
rhs:
"2019 The Crossbeam Project Developers"
json atoms at path ".files.children[0].children[10].license.spdx" are not equal:
lhs:
"BSD-2-Clause AND (Apache-2.0 OR MIT)"
rhs:
"Apache-2.0 OR MIT"
json atom at path ".files.children[0].children[10].children" is missing from lhs
json atoms at path ".files.children[0].children[10].name" are not equal:
lhs:
"library/std/src/sys/sync/mutex/fuchsia.rs"
rhs:
"library/std/src/sync/mpmc"
...
```
Complaints about it being distracting, and causing people to wait
until all of the results are loaded instead of using the incremental
results as they come in, make me think this is a bad idea.
[rustdoc] Cleanup "highlight::end_expansion"
~Looks like a ~5% improvement on the highlight benchmark.
Obviously, highlighting is only a small part of rustdoc's runtime, so improvement won't be as large on rustc-perf (if there's even an improvement), but holding fingers for a nice gain.~
Perf seems neutral, but IMHO this is a nice small cleanup regardless.
r? `@GuillaumeGomez` (& perf run please!)
bootstrap: relax `compiler-rt` root assertion
Not needed during tests. This would otherwise require `src/llvm-project` submodule to be initialized and `compiler-rt/` subdirectory to be present.
I need this and rust-lang/rust#147374 to get bootstrap self-tests to pass with no git submodules checked out locally.
r? `@Kobzol` (or bootstrap)
bootstrap: don't build book redirect pages during dry-run/test
Currently, `./x test bootstrap` does not automatically transitively checkout submodules needed to pass all involved test steps. Apparently one place where bootstrap's self-test can choke on locally is trying to build book redirect pages without the book submodules checked out.
This change is orthogonal to making bootstrap checking out required submodules for self-tests, and IMO is beneficial regardless since IMO we should not be building these redirect pages during test/dry-run _anyway_.
This was blocking me trying to rebless bootstrap self-tests for rust-lang/rust#147372. cf. [#t-infra/bootstrap > Bootstrap self-tests @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Bootstrap.20self-tests/near/543157194).
r? `@Kobzol` (or bootstrap)
Set opt-level flag for installing tool only on CI
## Context
ensure_version_or_cargo_install uses -Copt-level=0 for quicker installation. However, the flag affects the tool's performance. For example, typos-cli with opt-level=0 takes 15 seconds for checking /compiler on my local, but the tool with default opt-level only takes less than 1 sec.
It fixesrust-lang/rust#147331
## Changes
This PR enables the option only when the test tidy is run on CI.
We've discussed that opt-level=1 should be enough, so I also change the level from 0 to 1.
ensure_version_or_cargo_install uses -Copt-level=0 for quicker installation.
However, the flag affects the tool's performance. For example, typos-cli with opt-level=0 takes 15 seconds for checking ./compiler, but the tool with default opt-level only takes less than 1 sec.
This commit enables the option only when the test tidy is run on CI.
Fix doctest output json
Fixesrust-lang/rust#144798.
Hopefully it will work with the new changes in `libtest` without needing to do both at once.
This PR moves the `rustdoc` merged doctest extra information directly into `libtest` to ensure they share the same rendering to prevent the bug uncovered in rust-lang/rust#144798.
cc `@lolbinary` (as you reviewed the first PR)
And since we're making changes to `libtest`:
r? `@Amanieu`
Add documentation about unwinding to wasm targets
This commit adds some documentation about the state of `-Cpanic=unwind` for the following wasm targets:
* `wasm32-unknown-unknown`
* `wasm32-wasip1`
* `wasm32-wasip2`
* `wasm32v1-none`
Notably it's possible to use `-Cpanic=unwind` with `-Zbuild-std` and it's also mentioned that there are no concrete proposals at this time to adding a new set of targets which support unwinding. My hunch is that in a few years' time it would make sense to enable it by default on these targets (except for `wasm32v1-none`) but that's a problem for future folks to debate. For now this is an attempt to document the status quo.
Jana Dönszelmann