Rollup of 7 pull requests
Successful merges:
- #133631 (Support QNX 7.1 with `io-sock`+libstd and QNX 8.0 (`no_std` only))
- #134358 (compiler: Set `target_abi = "ilp32e"` on all riscv32e targets)
- #135812 (Fix GDB `OsString` provider on Windows )
- #135842 (TRPL: more backward-compatible Edition changes)
- #135946 (Remove extra whitespace from rustdoc breadcrumbs for copypasting)
- #135953 (ci.py: check the return code in `run-local`)
- #136019 (Add an `unchecked_div` alias to the `Div<NonZero<_>>` impls)
r? `@ghost`
`@rustbot` modify labels: rollup
TRPL: more backward-compatible Edition changes
- Improve the discussion of `unsafe` blocks within `unsafe` functions.
- Fix formatting in Appendix A
- Incorporate line edits to Chapter 17 from NoStarch.
Support QNX 7.1 with `io-sock`+libstd and QNX 8.0 (`no_std` only)
Changes of this pull request:
1. Refactor code for qnx nto targets to share more code in file `nto_qnx.rs`
1. Add support for an additional network stack on nto qnx 7.1.
QNX 7.1 supports two network stacks:
1. `io-pkt`, which is default
2. `io-sock`, which is optional on 7.1 but default in QNX 8.0
As one can see in the [io-sock migration notes](https://www.qnx.com/developers/docs/7.1/index.html#com.qnx.doc.neutrino.io_sock/topic/migrate_app.html), this changes the libc API in a way similar to e.g. linux-gnu vs. linux-musl.
This change adds a new target which has a different value for `target_env`, so that e.g. libc can distinguish between both APIs.
2. Add initial support for QNX 8.0, thanks to AkhilTThomas. As it turned out, the problem with forking many processes still exists in QNX 8.0. Because if this, we are now using it for any QNX version (i.e. not check for `target_env` anymore).
Update emscripten std tests
This disables a bunch of emscripten tests that test things emscripten doesn't support and re-enables a whole bunch of tests which now work just fine on emscripten.
Tested with `EMCC_CFLAGS="-s MAXIMUM_MEMORY=2GB" ./x.py test library/ --target wasm32-unknown-emscripten`.
fix(libtest): Deprecate '--logfile'
rust-lang/testing-devex-team#9 proposed changing the behavior of `--logfile`. The given reasons were:
(1) Bazel can't programmatically process stdout. This seems like a limitation in Bazel and we recommend focusing on that. If we look at the wider Rust ecosystem, Rustc and Cargo don't support any such mechanism and the Cargo team rejected having one. Expecting this in libtest when its not supported elsewhere seems too specialized.
(2) Tests that leak out non-programmatic output that intermixes with programmatic output. We acknowledge this is a problem to be evaluated but we need to make sure we are stepping back and gathering requirements, rather than assuming `--logfile` will fit the needs.
Independent of the motive, regarding using or changing `--logfile`
(1) Most ways to do it would be a breaking change, like if we respect any stable `--format`. As suggested above, we could specialize this to new `--format` values but that would be confusing for some values to apply but not others.
(2) Other ways of solving this add new features to lib`test` when we are instead wanting to limit the feature set it has to minimize the compatibility surface that has to be maintained and the burden it would put on third party harnesses which are a focus area. Examples include `--format compact` or a `--log-format` flag
(3) The existence of `--logfile` dates back quite a ways (5cc050b265, rust-lang/rust#2127) and the history gives the
impression this more of slipped through rather than being an intended feature (see also
https://github.com/rust-lang/rust/pull/82350#discussion_r579732071). Deprecation would better match to how it has been treated. By deprecating this, we do not expect custom test harnesses (rust-lang/testing-devex-team#2) to implement this.
T-testing-devex held an FCP for deprecating in rust-lang/testing-devex-team#9 though according to
[RFC #3455](https://rust-lang.github.io/rfcs/3455-t-test.html), this is still subject to final approval from T-libs-api.
Closesrust-lang/testing-devex-team#9
Improve check-cfg expected names diagnostic
This PR improves the check-cfg `allow-same-level` test by ~~normalizing it's output and by~~ adding more context to the test.
It also filters the well known cfgs from the `expected names are` note, as to reduce the size of the diagnostic. Users can still find the full list on the [rustc book](https://doc.rust-lang.org/nightly/rustc/check-cfg.html#well-known-names-and-values), which is reinforced for Cargo users by adding a note in the Cargo check-cfg specific section.
Fixes https://github.com/rust-lang/rust/issues/135995
r? `@jieyouxu`
rust-lang/testing-devex-team#9 proposed changing the behavior of `--logfile`.
The given reasons were:
(1) Bazel can't programmatically process stdout. This seems like a
limitation in Bazel and we recommend focusing on that. If we look at
the wider Rust ecosystem, Rustc and Cargo don't support any such
mechanism and the Cargo team rejected having one. Expecting this in
libtest when its not supported elsewhere seems too specialized.
(2) Tests that leak out non-programmatic output that intermixes with
programmatic output. We acknowledge this is a problem to be evaluated
but we need to make sure we are stepping back and gathering
requirements, rather than assuming `--logfile` will fit the needs.
Independent of the motive, regarding using or changing `--logfile`
(1) Most ways to do it would be a breaking change, like if we respect
any stable `--format`. As suggested above, we could specialize this to
new `--format` values but that would be confusing for some values to
apply but not others.
(2) Other ways of solving this add new features to lib`test` when we are
instead wanting to limit the feature set it has to minimize the
compatibility surface that has to be maintained and the burden it would
put on third party harnesses which are a focus area. Examples include
`--format compact` or a `--log-format` flag
(3) The existence of `--logfile` dates back quite a ways
(5cc050b265,
rust-lang/rust#2127) and the history gives the
impression this more of slipped through rather than being an intended
feature (see also
https://github.com/rust-lang/rust/pull/82350#discussion_r579732071).
Deprecation would better match to how it has been treated.
By deprecating this, we do not expect custom test harnesses
(rust-lang/testing-devex-team#2) to implement this.
T-testing-devex held an FCP for deprecating in rust-lang/testing-devex-team#9
though according to
[RFC #3455](https://rust-lang.github.io/rfcs/3455-t-test.html),
this is still subject to final approval from T-libs-api.
Tidy Python improvements
Fixes display of Python formatting diffs in tidy, and refactors the code to make it simpler and more robust. Also documents Python formatting and linting in the Rustc dev guide.
Fixes: https://github.com/rust-lang/rust/issues/135942
r? `@onur-ozkan`
Implement `needs-subprocess` directive, and cleanup a bunch of tests to use `needs-{subprocess,threads}`
### Summary
Closes#128295.
- Implements `//@ needs-subprocess` directive in compiletest as requested in #128295. However, compiletest is a host tool, so we can't just try to spawn process because that spawns the process on *host*, not the *target*, under cross-compilation scenarios.
- The short-term solution is to add *Yet Another* list of allow-list targets.
- The long-term solution is to first check if a `$target` supports std, then try to run a binary to do run-time capability detection *on the target*. But that is tricky because you have to build-and-run a binary *for the target*.
- This PR picks the short-term solution, because the long-term solution is highly non-trivial, and it's already an improvement over individual `ignore-*`s all over the place.
- Opened an issue about the long-term solution in #135928.
- Documents `//@ needs-subprocess` in rustc-dev-guide.
- Replace `ignore-{wasm,wasm32,emscripten,sgx}` with `needs-{subprocess,threads}` where suitable in tests.
- Some drive-by test changes as I was trying to figure out if I could use `needs-{subprocess,threads}` and found some bits needlessly distracting.
Count of tests that use `ignore-{wasm,wasm32,emscripten,sgx}` before and after this PR:
| State | `ignore-sgx` | `ignore-wasm` | `ignore-emscripten` |
| - | - | - | - |
| Before this PR | 96 | 88 | 207 |
| After this PR | 36 | 38 | 61 |
<details>
<summary>Commands used to find out locally</summary>
```
--- before
[17:40] Joe:rust (fresh) | rg --no-ignore -l "ignore-sgx" tests | wc -l
96
[17:40] Joe:rust (fresh) | rg --no-ignore -l "ignore-wasm" tests | wc -l
88
[17:40] Joe:rust (fresh) | rg --no-ignore -l "ignore-emscripten" tests | wc -l
207
--- after
[17:39] Joe:rust (needs-subprocess-thread) | rg --no-ignore -l "ignore-sgx" tests | wc -l
36
[17:39] Joe:rust (needs-subprocess-thread) | rg --no-ignore -l "ignore-wasm" tests | wc -l
38
[17:39] Joe:rust (needs-subprocess-thread) | rg --no-ignore -l "ignore-emscripten" tests | wc -l
61
```
</details>
### Review advice
- Best reviewed commit-by-commit.
- Non-trivial test changes (not mechanically simple replacements) are split into individual commits to help with review. Their individual commit messages give some basic description of the changes.
- I *could* split some test changes out into another PR, but I found that I needed to change some tests to `needs-threads`, some to `needs-subprocess`, and some needed to use *both*, so they might conflict and become very annoying.
---
r? ``@ghost`` (need to run try jobs)
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: i686-mingw
try-job: x86_64-mingw-1
try-job: x86_64-apple-1
try-job: aarch64-apple
try-job: aarch64-gnu
try-job: test-various
try-job: armhf-gnu
QNX SDP 8.0 comes with newly renamed QNX OS 8.0, so update the page to talk about QNX, QNX Neutrino 7.0, QNX Neutrino 7.1 or QNX OS 8.0.
Also actually add a list of target triples.
Add NuttX support for AArch64 and ARMv7-A targets
This patch adds tier 3 support for AArch64 and ARMv7-A targets in NuttX, including:
- AArch64 target: aarch64-unknown-nuttx
- ARMv7-A target: armv7a-nuttx-eabi, armv7a-nuttx-eabihf
- Thumbv7-A target: thumbv7a-nuttx-eabi, thumbv7a-nuttx-eabihf
remove pointless allowed_through_unstable_modules on TryFromSliceError
This got added in https://github.com/rust-lang/rust/pull/132482 but the PR does not explain why. `@lukas-code` do you still remember? Also Cc `@Noratrieb` as reviewer of that PR.
If I understand the issue description correctly, all paths under which this type is exported are stable now: `core::array::TryFromSliceError` and `std::array::TryFromSliceError`. If that is the case, we shouldn't have the attribute; it's a terrible hack that should only be used when needed to maintain backward compatibility. Getting some historic information right is IMO *not* sufficient justification to risk accidentally exposing this type via more unstable paths today or in the future.
Get rid of RunCompiler
The various `set_*` methods that have been removed can be replaced by setting the respective fields in the `Callbacks::config` implementation. `set_using_internal_features` was often forgotten and it's equivalent is now done automatically.
Add test for checking used glibc symbols
This test checks that we do not use too new glibc symbols in the compiler on x64 GNU Linux, in order not to break our [glibc promises](https://blog.rust-lang.org/2022/08/01/Increasing-glibc-kernel-requirements.html).
One thing that isn't solved in the PR yet is to make sure that this test will only run on `dist` CI, more specifically on the `dist-x86_64-linux` runner, in the opt-dist post-optimization tests (it can fail elsewhere, that doesn't matter). Any suggestions on how to do that are welcome.
Fixes: https://github.com/rust-lang/rust/issues/134037
r? `@jieyouxu`
remove support for the (unstable) #[start] attribute
As explained by `@Noratrieb:`
`#[start]` should be deleted. It's nothing but an accidentally leaked implementation detail that's a not very useful mix between "portable" entrypoint logic and bad abstraction.
I think the way the stable user-facing entrypoint should work (and works today on stable) is pretty simple:
- `std`-using cross-platform programs should use `fn main()`. the compiler, together with `std`, will then ensure that code ends up at `main` (by having a platform-specific entrypoint that gets directed through `lang_start` in `std` to `main` - but that's just an implementation detail)
- `no_std` platform-specific programs should use `#![no_main]` and define their own platform-specific entrypoint symbol with `#[no_mangle]`, like `main`, `_start`, `WinMain` or `my_embedded_platform_wants_to_start_here`. most of them only support a single platform anyways, and need cfg for the different platform's ways of passing arguments or other things *anyways*
`#[start]` is in a super weird position of being neither of those two. It tries to pretend that it's cross-platform, but its signature is a total lie. Those arguments are just stubbed out to zero on ~~Windows~~ wasm, for example. It also only handles the platform-specific entrypoints for a few platforms that are supported by `std`, like Windows or Unix-likes. `my_embedded_platform_wants_to_start_here` can't use it, and neither could a libc-less Linux program.
So we have an attribute that only works in some cases anyways, that has a signature that's a total lie (and a signature that, as I might want to add, has changed recently, and that I definitely would not be comfortable giving *any* stability guarantees on), and where there's a pretty easy way to get things working without it in the first place.
Note that this feature has **not** been RFCed in the first place.
*This comment was posted [in May](https://github.com/rust-lang/rust/issues/29633#issuecomment-2088596042) and so far nobody spoke up in that issue with a usecase that would require keeping the attribute.*
Closes https://github.com/rust-lang/rust/issues/29633
try-job: x86_64-gnu-nopt
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
try-job: test-various
Treat other items as functions for the purpose of type-based search
specifically, constants and statics are nullary functions, and struct fields are unary functions.
fixes#130204
r? ``@notriddle``
constants and statics are nullary functions, and struct fields are unary functions.
functions (along with methods and trait methods) are prioritized over other
items, like fields and constants.
