Slight reorganization of sys/(fast_)thread_local
I was long confused by the `thread_local` and `fast_thread_local` modules in the `sys(_common)` part of libstd. The names make it *sound* like `fast_thread_local` is just a faster version of `thread_local`, but really these are totally different APIs: one provides thread-local "keys", which are non-addressable pointer-sized pieces of local storage with an associated destructor; the other (the "fast" one) provides just a destructor.
So I propose we rename `fast_thread_local` to `thread_local_dtor`, and `thread_local` to `thread_local_key`. That's what this PR does.
Obviate #[allow(improper_ctypes_definitions)]
Modifies the return type for `fn entry` so that allowing
improper_ctypes_definitions is no longer necessary. This change is
derived from a similar pattern in `libstd/sys/sgx/abi/usercalls/raw.rs`
with `UsercallReturn`.
cc @jethrogb
Add `read_exact_at` and `write_all_at` to WASI's `FileExt`
This adds `read_exact_at` and `write_all_at` to WASI's `FileExt`,
similar to the Unix versions of the same names.
Rename the existing read_at/write_at to read_vectored_at/write_vectored_at,
for consistency with libstd's read_vectored/write_vectored. And,
introduce new read_at/write_at functions which take a single buffer,
similar to all other targets which provide these functions, so this will
make it easier for applications to share code between WASI and other
targets.
Note that WASI's FileExt is currently unstable.
Fix the return type of Windows' `OpenOptionsExt::security_qos_flags`.
This adjusts the return type of Windows' `OpenOptionsExt::security_qos_flags`
to be consistent with the other functions in the trait.
Remap Windows ERROR_INVALID_PARAMETER to ErrorKind::InvalidInput from Other
I don't know if this is acceptable or how likely it is to break existing code, but it seem to me ERROR_INVALID_PARAMETER "The parameter is incorrect" should map to ErrorKind::InvalidInput "A parameter was incorrect". Previously this value fell through to ErrorKind::Other.
I can't speak for anyone but myself, but I instinctively thought it would be InvalidInput.
Modifies the return type for `fn entry` so that allowing
improper_ctypes_definitions is no longer necessary. This change is
derived from a similar pattern in `libstd/sys/sgx/abi/usercalls/raw.rs`
with `UsercallReturn`.
Fortanix SGX target libunwind build process changes
Ticket: https://github.com/fortanix/rust-sgx/issues/174
LLVM related changes (merged): https://github.com/rust-lang/llvm-project/pull/57
Description: libunwind changes needed to run code in sgx environment via rust-sgx.
Target that uses this in rust: x86_64-fortanix-unknown-sgx.
Without this change, rust std for this toolchain is forced to use a precompiled library loaded via environment variable.
With this change we act the same as musl target.
`improper_ctypes_definitions` lint
Addresses #19834, #66220, and #66373.
This PR takes another attempt at #65134 (reverted in #66378). Instead of modifying the existing `improper_ctypes` lint to consider `extern "C" fn` definitions in addition to `extern "C" {}` declarations, this PR adds a new lint - `improper_ctypes_definitions` - which only applies to `extern "C" fn` definitions.
In addition, the `improper_ctype_definitions` lint differs from `improper_ctypes` by considering `*T` and `&T` (where `T: Sized`) FFI-safe (addressing #66220).
There wasn't a clear consensus in #66220 (where the issues with #65134 were primarily discussed) on the approach to take, but there has [been some discussion in Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.2366220.20improper_ctypes.20definitions.20vs.20declarations/near/198903086). I fully expect that we'll want to iterate on this before landing.
cc @varkor + @shepmaster (from #19834) @hanna-kruppe (active in discussing #66220), @SimonSapin (#65134 caused problems for Servo, want to make sure that this PR doesn't)
This commit adds a new lint - `improper_ctypes_definitions` - which
functions identically to `improper_ctypes`, but on `extern "C" fn`
definitions (as opposed to `improper_ctypes`'s `extern "C" {}`
declarations).
Signed-off-by: David Wood <david@davidtw.co>
Converted all platform-specific stdin/stdout/stderr implementations to use io:: traits
Currently, some of the platform-specific standard streams (`src/libstd/sys/*/stdio.rs`) manually implement parts of the `io::Write` interface directly as methods on the struct, rather than by actually implementing the trait. There doesn't seem to be any reason for this, other than an unused advantage of `fn write(&self, ...)` instead of `fn write(&mut self, ...)`.
Unfortunately, this means that those implementations don't have the default-implemented io methods, like `read_exact` and `write_all`. This caused #72705, which adds forwarding methods to the user-facing standard stream implementations, to fail to compile on those platforms.
This change converts *all* such standard stream structs to use the standard library traits. This change should not cause any breakages, because the changed types are not publicly exported, and in fact are only ever used in `src/libstd/io/stdio.rs`.
Add a lint to catch clashing `extern` fn declarations.
Closes#69390.
Adds lint `clashing_extern_decl` to detect when, within a single crate, an extern function of the same name is declared with different types. Because two symbols of the same name cannot be resolved to two different functions at link time, and one function cannot possibly have two types, a clashing extern declaration is almost certainly a mistake.
This lint does not run between crates because a project may have dependencies which both rely on the same extern function, but declare it in a different (but valid) way. For example, they may both declare an opaque type for one or more of the arguments (which would end up distinct types), or use types that are valid conversions in the language the extern fn is defined in. In these cases, we can't say that the clashing declaration is incorrect.
r? @eddyb
Prevent attacker from manipulating FPU tag word used in SGX enclave
Insufficient sanitization of the x87 FPU tag word in the trusted enclave runtime allowed unprivileged adversaries in the containing host application to induce incoherent or unexpected results for ABI-compliant compiled enclave application code that uses the x87 FPU.
Vulnerability was disclosed to us by Fritz Alder, Jo Van Bulck, David Oswald and Frank Piessens
cc: @jethrogb
RISC-V Emulated Testing
Adds a disabled docker image on which to run RISC-V tests. Based on the armhf image.
Test using
```
./src/ci/docker/run.sh riscv64gc-linux
```
cc: @msizanoen1
Insufficient sanitization of the x87 FPU tag word in the trusted enclave runtime allowed unprivileged adversaries in the containing host application to induce incoherent or unexpected results for ABI-compliant compiled enclave application code that uses the x87 FPU.
Vulnerability was disclosed to us by Fritz Alder, Jo Van Bulck, David Oswald and Frank Piessens
