compiletest: Isolate public APIs and minimize public surface area
As part of my ongoing efforts to improve directive parsing, I would like to be able to make internal changes without worrying about whether they're going to break the rustdoc-gui-test tool. That tool currently uses compiletest as a dependency to help with directive parsing.
This PR therefore isolates all of compiletest's public APIs into two dedicated modules, one used by rustdoc-gui-test, and one used by the compiletest binary in `compiletest/src/bin/main.rs`.
All other modules (and crate-root items) are then made non-`pub` to achieve the API isolation. Doing so reveals some unused items, which have been removed.
(To reduce the amount of immediate textual churn, this PR does not comprehensively replace `pub` with `pub(crate)` throughout the whole crate; that could be done in a follow-up PR.)
---
Ideally, rustdoc-gui-test would not depend on compiletest at all, but properly fixing that is out of scope for this PR.
- rust-lang/rust#143827
r? jieyouxu
bootstrap: add `Builder::rustc_cmd` that includes the lib path
When building with `rust.rpath = false`, every `rustc` invocation needs
to include the library path as well. I particularly ran into this in
`generate_target_spec_json_schema` when testing 1.91-beta in Fedora,
where we do disable rpath for our system builds. The new helper function
will hopefully encourage the right thing going forward.
Port the implemention of SIMD intrinsics from Miri to const-eval
Ported the implementation of most SIMD intrinsics from Miri to rustc_const_eval. Remaining are
- Math functions (as per `@RalfJung's` suggestions)
- FMA (non-deterministic)
- Funnel Shifts (not implemented in Miri yet)
- Unordered reduction intrinsics (not implemented in Miri yet)
All APIs used from outside the compiletest library crate have been isolated to
the `cli` and `rustdoc_gui_test` modules, so no other items need to be publicly
exported.
And:
- Remove it from being a query (it is only used for hover, where no caching is needed, and MIR evaluation of `needs_drop()`, which is rare).
- Fix handling of `PhantomData`.
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
When building with `rust.rpath = false`, every `rustc` invocation needs
to include the library path as well. I particularly ran into this in
`generate_target_spec_json_schema` when testing 1.91-beta in Fedora,
where we do disable rpath for our system builds. The new helper function
will hopefully encourage the right thing going forward.
Shoyu Vanilla (Flint)