Guarantee 8 bytes of alignment in Thread::into_raw
When using `AtomicPtr` for synchronization it's incredibly useful when you've got a couple bits you can stuff metadata in. By guaranteeing that `Thread`'s `Inner` struct is aligned to 8 bytes everyone can use the bottom 3 bits to signal other things, such as a critical section, etc.
This guarantee is thus very useful and costs us nothing.
Upgrade the `fortanix-sgx-abi` dependency
0.6.1 removes the `compiler-builtins` dependency, part of RUST-142265. The breaking change from 0.5 to 0.6 is for an update to the `insecure_time` API [1].
I validated that `./x c library --target x86_64-fortanix-unknown-sgx` completes successfully with this change.
Link: a34e9767f3 [1]
Hint that choose_pivot returns index in bounds
Instead of using `unsafe` in multiple places, one `hint::assert_unchecked` allows use of safe code instead.
Part of #rust-lang/rust#144326
Fix broken TLS destructors on 32-bit win7
Fixesrust-lang/rust#141300
On the 32-bit win7 target, we use OS TLS instead of native TLS, due to issues with how the OS handles alignment. Unfortunately, this caused issues due to the TLS destructors not running, causing memory leaks among other problems.
On Windows, to support OS TLS, the TlsAlloc family of function is used by Rust. This function does not support TLS destructors at all. However, rust has some code to emulate those destructors, by leveraging the TLS support functionality found in the MSVC CRT (specifically, in tlssup.c of the CRT).
To use this functionality, the user must do two things:
1. They must put the address to their callback in a section between `.CRT$XLB` and `.CRT$XLY`.
2. They must add a reference to `_tls_used` (or `__tls_used` on x86) to make sure the TLS support code in tlssup.c isn't garbage collected by the linker.
Prior to this commit, this second bit wasn't being done properly by the Rust TLS support code. Instead of adding a reference to _tls_used, it instead had a reference to its own callback to prevent it from getting GC'd by the linker. While this is _also_ necessary, not having a reference on _tls_used made the entire support non-functional.
This commit reworks the code to:
1. Add an unconditional `#[used]` attribute on the CALLBACK, which should be enough to prevent it from getting GC'd by the linker.
2. Add a reference to `_tls_used`, which should pull the TLS support code into the Rust programs and not let it be GC'd by the linker.
Move `std_detect` into stdlib
This PR moves the `std_detect` crate from `stdarch` to be a part of rust-lang/rust instead.
The first commit actually moves the whole directory from the stdarch Josh subtree, so that git blame history is kept intact. Then I had to make a few changes to appease `tidy`.
The most complex thing here is porting the tests. We can't have `std_detect` both in r-l/r and stdarch, because they could get desynchronized, so we have to perform the move more or less "atomically", which means that we also have to port all the existing `std_detect` tests from the `stdarch` repository.
The stdarch repo runs the following `std_detect` tests:
### Build
The `build-std-detect.sh` script (e2b6512aed/ci/build-std-detect.sh) builds `std_detect` using the nightly compiler for several targets. This will be subsumed by normal `x build library` on our Tier 1/2 targets. However, the stdarch repository also tests the following targets:
- aarch64-unknown-freebsd
- armv6-unknown-freebsd
- powerpc-unknown-freebsd
- powerpc64-unknown-freebsd
- aarch64-unknown-openbsd
Which we don't build/test on our CI currently. I think we have mostly two options here:
1) Ignore these targets
2) Create a special CI job that will build stage 1 rustc and then cross-compile std (or just the `std_detect` crate?) for these targets.
### Documentation
The `dox.sh` script (3fec5adcd5/ci/dox.sh) builds and documents `std_detect` for several targets. All of them are Tier 2/we have `dist-` jobs for them, so I think that we can just skip this and let our normal CI subsume it?
### Tests
The `run.sh` script (1b201cec2c/ci/run.sh) runs `cargo test` on `std_detect` with a bunch of variations of feature flags. This will be subsumed by `x test library` in our CI. The only problem is that `stdarch` runs these tests for a ludicrous number of targets:
```
- tuple: i686-unknown-linux-gnu
- tuple: x86_64-unknown-linux-gnu
- tuple: arm-unknown-linux-gnueabihf
- tuple: armv7-unknown-linux-gnueabihf
- tuple: aarch64-unknown-linux-gnu
- tuple: aarch64_be-unknown-linux-gnu
- tuple: riscv32gc-unknown-linux-gnu
- tuple: riscv64gc-unknown-linux-gnu
- tuple: powerpc-unknown-linux-gnu
- tuple: powerpc64-unknown-linux-gnu
- tuple: powerpc64le-unknown-linux-gnu
- tuple: s390x-unknown-linux-gnu
- tuple: i586-unknown-linux-gnu
- tuple: nvptx64-nvidia-cuda
- tuple: thumbv6m-none-eabi
- tuple: thumbv7m-none-eabi
- tuple: thumbv7em-none-eabi
- tuple: thumbv7em-none-eabihf
- tuple: loongarch64-unknown-linux-gnu
- tuple: wasm32-wasip1
- tuple: x86_64-apple-darwin
- tuple: x86_64-apple-ios-macabi
- tuple: aarch64-apple-darwin
- tuple: aarch64-apple-ios-macabi
- tuple: x86_64-pc-windows-msvc
- tuple: i686-pc-windows-msvc
- tuple: aarch64-pc-windows-msvc
- tuple: x86_64-pc-windows-gnu
- tuple: aarch64-unknown-linux-gnu
- tuple: aarch64_be-unknown-linux-gnu
- tuple: armv7-unknown-linux-gnueabihf
- tuple: loongarch64-unknown-linux-gnu
- tuple: powerpc-unknown-linux-gnu
- tuple: powerpc64-unknown-linux-gnu
- tuple: powerpc64le-unknown-linux-gnu
- tuple: riscv32gc-unknown-linux-gnu
- tuple: riscv64gc-unknown-linux-gnu
- tuple: s390x-unknown-linux-gnu
- tuple: x86_64-unknown-linux-gnu
- tuple: aarch64-apple-darwin
- tuple: aarch64-apple-ios-macabi
```
We definitely do not run *tests* for all of these targets on our CI.
# Outcome
We have decided to just subsume std_detect tests by our normal test suite for now, and not create a separate CI job. Therefore, this PR performs the following changes in target testing for `std_detect`:
The following T3 targets would go from "build" to "nothing":
```
aarch64-unknown-freebsd (T3)
armv6-unknown-freebsd (T3)
powerpc-unknown-freebsd (T3)
powerpc64-unknown-freebsd (T3)
aarch64-unknown-openbsd (T3)
```
The following T3 targets would go from "test" to "nothing":
```
aarch64_be-unknown-linux-gnu (T3)
riscv32gc-unknown-liux-gnu (T3)
```
The following T2 targets would go from "test" to "build":
```
arm-unknown-linux-gnueabihf (T2)
armv7-unknown-linux-gnueabihf (T2)
riscv64gc-unknown-linux-gnu (T2)
powerpc-unknown-linux-gnu (T2)
powerpc64-unknown-linux-gnu (T2)
powerpc64le-unknown-linux-gnu (T2)
s390x-unknown-linux-gnu (T2)
i586-unknown-linux-gnu (T2)
loongarch64-unknown-linux-gnu (T2)
wasm32-wasip1 (T2)
x86_64-apple-ios-macabi (T2)
aarch64-apple-ios-macabi (T2)
aarch64-pc-windows-msvc (T2)
armv7-unknown-linux-gnueabihf (T2)
loongarch64-unknown-linux-gnu (T2)
powerpc-unknown-linux-gnu (T2)
```
I have confirmed in https://github.com/rust-lang/stdarch/pull/1873 that the current version of this PR would pass stdarch's CI testsuite.
r? `@ghost`
try-job: armhf-gnu
try-job: arm-android
- Use EFI_TCP4_GET_MODE_DATA to be able to query for ttl, nodelay,
peer_addr and socket_addr.
- peer_addr is needed for implementation of `accept`.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Rename `tests/{assembly,codegen}` into `tests/{assembly,codegen}-llvm` and ignore these testsuites if configured backend doesn't match
Follow-up of https://github.com/rust-lang/rust/pull/144125.
This PR changes `compiletest` so that `asm` tests are only run if they match the current codegen backend. To better reflect it, I renamed the `tests/ui/asm` folder into `tests/ui/asm-llvm`. Like that, we can add new asm tests for other backends if we want without needing to add extra code to `compiletest`.
Next step will be to use the new code annotations added in rust-lang/rust#144125 to ignore ui tests failing in cg_gcc until it's fixed on our side.
cc `@antoyo` `@oli-obk`
r? `@Kobzol`
flt2dec: replace for loop by iter_mut
Perf is explored in https://github.com/rust-lang/rust/issues/144118, which initially showed small losses, but then also showed significant gains. Both are real, but given the smallness of the losses, this seems a good change.
On the 32-bit win7 target, we use OS TLS instead of native TLS, due to
issues with how the OS handles alignment. Unfortunately, this caused
issues due to the TLS destructors not running, causing memory leaks
among other problems.
On Windows, to support OS TLS, the TlsAlloc family of function is used
by Rust. This function does not support TLS destructors at all. However,
rust has some code to emulate those destructors, by leveraging the TLS
support functionality found in the MSVC CRT (specifically, in tlssup.c
of the CRT). Specifically, the CRT provides the ability to register
callbacks that are called (among other things) on thread destruction. By
registering our own callback, we can run through a list of registered
destructors functions to execute.
To use this functionality, the user must do two things:
1. They must put the address to their callback in a section between
`.CRT$XLB` and `.CRT$XLY`.
2. They must add a reference to `_tls_used` (or `__tls_used` on x86) to
make sure the TLS support code in tlssup.c isn't garbage collected by
the linker.
Prior to this commit, this second bit wasn't being done properly by the
Rust TLS support code. Instead of adding a reference to _tls_used, it
instead had a reference to its own callback to prevent it from getting
GC'd by the linker. While this is _also_ necessary, not having a
reference on _tls_used made the entire support non-functional.
This commit reworks the code to:
1. Add an unconditional `#[used]` attribute on the CALLBACK, which
should be enough to prevent it from getting GC'd by the linker.
2. Add a reference to `_tls_used`, which should pull the TLS support
code into the Rust programs and not let it be GC'd by the linker.
address clippy formatting nits
- int_log10.rs: change top level doc comments to outer
- collect.rs: remove empty line after doc comment
- clippy fix: markdown indentation for indented items after line break: a markdown list item continued over multiples lines, but those following lines which are part of the same item are not indented
- clippy fix: bound in one place: when there is a bound in angle brackets and another bound on the same variable in a where clause
Remove deprecated `MaybeUninit` slice methods
These were left in to make migration a bit easier, although they should be removed now since they were never stable.
fix Zip unsoundness (again)
Some history: The Zip TrustedRandomAccess specialization has tried to emulate the side-effects of the naive implementation for a long time, including backwards iteration. #82292 tried to fix unsoundness (#82291) in that side-effect-preservation code, but this introduced some panic-safety unsoundness (#86443), but the fix#86452 didn't fix it for nested Zip iterators (#137255).
Rather than piling yet another fix ontop of this heap of fixes this PR reduces the number of cases in which side-effects will be preserved; the necessary API guarantee change was approved in #83791 but we haven't made use of that so far.
fixes#137255
