Cleanup docs for Allocator
This is an attempt to remove ungrammatical constructions and clean up the prose. I've sometimes had to try hard to understand what was being stated, so it is possible that I've misunderstood the original meaning. In particular, I did not see a difference between:
- the borrow-checker lifetime of the allocator type itself.
- as long as at least one of the allocator instance and all of its clones has not been dropped.
optimize slice::ptr_rotate for small rotates
r? `@scottmcm`
This swaps the positions and numberings of algorithms 1 and 2 in `slice::ptr_rotate`, and pulls the entire outer loop into algorithm 3 since it was redundant for the first two. Effectively, `ptr_rotate` now always does the `memcpy`+`memmove`+`memcpy` sequence if the shifts fit into the stack buffer.
With this change, an `IndexMap`-style `move_index` function is optimized correctly.
Assembly comparisons:
- `move_index`, before: https://godbolt.org/z/Kr616KnYM
- `move_index`, after: https://godbolt.org/z/1aoov6j8h
- the code from `#89714`, before: https://godbolt.org/z/Y4zaPxEG6
- the code from `#89714`, after: https://godbolt.org/z/1dPx83axc
related to #89714
some relevant discussion in https://internals.rust-lang.org/t/idea-shift-move-to-efficiently-move-elements-in-a-vec/22184
Behavior tests pass locally. I can't get any consistent microbenchmark results on my machine, but the assembly diffs look promising.
Rollup of 8 pull requests
Successful merges:
- #133382 (Suggest considering casting fn item as fn pointer in more cases)
- #136092 (Test pipes also when not running on Windows and Linux simultaneously)
- #136190 (Remove duplicated code in RISC-V asm bad-reg test)
- #136192 (ci: remove unused windows runner)
- #136205 (Properly check that array length is valid type during built-in unsizing in index)
- #136211 (Update mdbook to 0.4.44)
- #136212 (Tweak `&mut self` suggestion span)
- #136214 (Make crate AST mutation accessible for driver callback)
r? `@ghost`
`@rustbot` modify labels: rollup
uefi: process: Fix args
- While working on process env support, I found that args were currently broken. Not sure how I missed it in the PR, but well here is the fix.
- Additionally, no point in adding space at the end of args.
- While working on process env support, I found that args were currently
broken. Not sure how I missed it in the PR, but well here is the fix.
- Additionally, no point in adding space at the end of args.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Add missing allocator safety in alloc crate
### PR Description
In the previous PR [#135009](https://github.com/rust-lang/rust/pull/135009), PR [#134496](https://github.com/rust-lang/rust/pull/134496), some incomplete API documentation issues have been fixed.
Based on these changes, other inconsistencies related to the allocator have also been identified, including:
- `Box::from_non_null`
- `Box::from_non_null_in`
- `Weak::from_raw`
Enable `unreachable_pub` lint in `alloc`
This PR enables the [`unreachable_pub`](https://doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#unreachable-pub) lint as warn in the `alloc` crate.
Most of changes are in the btree implementation and in tests.
*The diff was mostly generated with `./x.py fix --stage 1 library/alloc/ -- --broken-code`, as well as manual edits for code in macros and in tests.*
Continuation of #134286 and #135366
r? libs
Put the core unit tests in a separate coretests package
Having standard library tests in the same package as a standard library crate has bad side effects. It causes the test to have a dependency on a locally built standard library crate, while also indirectly depending on it through libtest. Currently this works out fine in the context of rust's build system as both copies are identical, but for example in cg_clif's tests I've found it basically impossible to compile both copies with the exact same compiler flags and thus the two copies would cause lang item conflicts.
This PR moves the tests of libcore to a separate package which doesn't depend on libcore, thus preventing the duplicate crates even when compiler flags don't exactly match between building the sysroot (for libtest) and building the test itself. The rest of the standard library crates do still have this issue however.
compiler_fence: fix example
The old example was wrong, an acquire fence is required in the signal handler. To make the point more clear, I changed the "data" variable to use non-atomic accesses.
Fixes https://github.com/rust-lang/rust/issues/133014
Move `std::io::pipe` code into its own file
Also update the docs for the new location, create a section "Platform-specific behavior", don't hide required imports for code examples.
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
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 (https://github.com/rust-lang/rust/commit/5cc050b265509c19717e11e12dd785d8c73f5b11, 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
Stuart Cook