It didn't do anything (behaved like `item`), as with `enforceGranularity = false` (which is the default), the style of the current file is always preferred, regardless of the setting.
We could make it fail when the setting is `preserve` and the current file's style could not be detected, but that makes little sense.
It is a bit weird that the default is `crate` but `preserve` falls back to `item`, however that was the previous behavior.
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.
Return to needs-llvm-components being info-only
Partially revert a535042e80
Even with non-LLVM codegen backends, we want to allow for annotations that express dependencies to LLVM-specific parts of the test suite. This includes `//@ needs-llvm-components`, which just allows checking that LLVM is built with relevant target support before the test is run. It does not assert the test cannot work with another codegen backend.
Fix top level ui tests check in tidy
I got an error when pushing code:
```console
fmt check
fmt: checked 6330 modified files
tidy check
tidy [ui_tests (tests)]: ui tests should be added under meaningful subdirectories: `/Users/yukang/rust/tests/ui/.DS_Store`
tidy [ui_tests (tests)]: FAIL
```
I think it's better to use `ignore::WalkBuilder` for checking the path.
r? `@jieyouxu`
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.
Respect `-Z` unstable options in `rustdoc --test`
This PR makes rustdoc respect `-Z` unstable options when collecting doctests (`rustdoc --test`).
In the process I also realized that `--error-format` wasn't respected as well, making UI annotations impossible to write so I fixed that as well.
Best reviewed commit by commit.
Fixes https://github.com/rust-lang/rust/issues/147276
Fixes https://github.com/rust-lang/rust/issues/143930
r? fmease
add arm-maintainers to various targets
Add the ``@rust-lang/arm-maintainers`` team as maintainers to the following targets:
- `aarch64-unknown-linux-gnu`
- `aarch64-unknown-none`/`aarch64-unknown-none-softfloat`
- `aarch64-unknown-uefi`
- `armv7-unknown-linux-gnueabi`/`armv7-unknown-linux-gnueabihf`
- `armv7a-none-eabi`/`armv7a-none-eabihf`
- `armv7r-none-eabi`/`armv7r-none-abihf`
- `armv8r-none-eabihf`
- `thumbv7em-none-eabi`/`thumbv7em-none-eabihf`
- `thumbv7m-none-eabi`
- `thumbv8m.base-none-eabi`
- `thumbv8m.main-none-eabi`/`thumbv8m.main-none-eabihf`
cc `@thejpster`
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
Partially revert a535042e80
Even with non-LLVM codegen backends, we want to allow for annotations
that express dependencies to LLVM-specific parts of the test suite.
This includes `//@ needs-llvm-components`, which just allows checking
that LLVM is built with relevant target support before the test is run.
It does not assert the test cannot work with another codegen backend.
Chayim Refael Friedman