This test won't work on windows 7, as the Thread::set_name function is
not implemented there (win7 does not provide a documented mechanism to
set thread names).
Some implementations of `Write::write_vectored` in the standard
library (`BufWriter`, `LineWriter`, `Stdout`, `Stderr`) check all
buffers to calculate the total length. This is O(n) over the number of
buffers.
It's common that only a limited number of buffers is written at a
time (e.g. 1024 for `writev(2)`). `write_vectored_all` will then call
`write_vectored` repeatedly, leading to a runtime of O(n²) over the
number of buffers.
The fix is to only calculate as much as needed if it's needed.
Cleanup windows `abort_internal`
As the comments on the functions say, we define abort in both in panic_abort and in libstd. This PR makes the two implementation (mostly) the same.
Additionally it:
* uses `options(noreturn)` on the asm instead of using `core::intrinsics::unreachable`.
* removed unnecessary allow lints
* added `FAST_FAIL_FATAL_APP_EXIT` to our generated Windows API bindings instead of defining it manually (std only)
Use the OS thread name by default if `THREAD_INFO` has not been initialized
Currently if `THREAD_INFO` hasn't been initialized then the name will be set to `None`. This PR changes it to use the OS thread name by default. This mostly affects foreign threads at the moment but we could expand this to make more use of the OS thread name in the future.
Note: I've only implemented `Thread::get_name` for windows, linux and macos (and macos adjacent) targets. The rest just return `None`.
fix typo in documentation for std::fs::Permissions
Please check and re-check this PR carefully to see if I got this right.
But by my logic, if the `read_only` function returns `true`, I would not expect be able to write to the file (it being read only); so this text is meant to clarify that `read_only` being `false` doesn't mean *you* can actually write to the file, just that "in general" someone is able to.
The new interface has some similarities to Linux system call
getdents64. The system call reads several dirent64 structures.
At the end of each dirent64 is stored the name of the file.
The length of file name is implictly part of dirent64 because
d_reclen contains size of dirent64 plus the length of the file
name.
Delete architecture-specific memchr code in std::sys
Currently all architecture-specific memchr code is only used in `std::io`. Most of the actual `memchr` capacity exposed to the user through the slice API is instead implemented in `core::slice::memchr`.
Hence this commit deletes `memchr` from `std::sys[_common]` and replace calls to it by calls to `core::slice::memchr` functions. This deletes `(r)memchr` from the list of symbols linked to libc.
The interest of putting architecture specific code back in core is linked to the discussion to be had in #113654
Use volatile access instead of `#[used]` for `on_tls_callback`
The first commit adds a volatile load of `p_thread_callback` when registering a dtor so that the compiler knows if the callback is used or not. I don't believe the added volatile instruction is otherwise significant in the context. In my testing using the volatile load allowed the compiler to correctly reason about whether `on_tls_callback` is used or not, allowing it to be omitted entirely in some cases. Admittedly it usually is used due to `Thread` but that can be avoided (e.g. in DLLs or with custom entry points that avoid the offending APIs). Ideally this would be something the compiler could help a bit more with so we didn't have to use tricks like `#[used]` or volatile. But alas.
I also used this as an opportunity to clean up the `unused` lints which I don't think serve a purpose any more.
The second commit removes the volatile load of `_tls_used` with `#cfg[target_thread_local]` because `#[thread_local]` already implies it. And if it ever didn't then `#[thread_local]` would be broken when there aren't any dtors.
add platform-specific function to get the error number for HermitOS
Extending `std` to get the last error number for HermitOS.
HermitOS is a tier 3 platform and this PR changes only files, wich are related to the tier 3 platform.
Implement unwind safety for Condvar on all platforms
Closes#118009
This commit adds unwind safety consistency to Condvar. Previously, only select platforms implemented unwind safety through auto traits. Known by this committer: On Linux, `Condvar` implemented `UnwindSafe` but on Mac and Windows, it did not. This change changes the implementation from auto to explicit.
In #118009, it was suggested that the platform differences were a bug and that a simple PR could address this. In trying to determine the best information to put in the `#[stable]` attribute, it [was suggested](https://github.com/rust-lang/rust/issues/121690#issuecomment-1968298470) I copy the stability information from the previous unwind safety implementations.
Increase visibility of `join_path` and `split_paths`
Add some crosslinking among `std::env` pages to make it easier to discover `join_paths` and `split_paths`. Also add aliases to help anyone searching for `PATH`.
Closes#118009
This commit adds unwind safety to Condvar. Previously, only select
platforms implemented unwind safety through auto traits. Known by this
committer: Linux was unwind safe, but Mac and Windows are not before
this change.
Extending `std` to get the last error number for HermitOS.
HermitOS is a tier 3 platform and this PR changes only files,
wich are related to the tier 3 platform.
Add a new `wasm32-wasi-preview2` target
This is the initial implementation of the MCP https://github.com/rust-lang/compiler-team/issues/694 creating a new tier 3 target `wasm32-wasi-preview2`. That MCP has been seconded and will most likely be approved in a little over a week from now. For more information on the need for this target, please read the [MCP](https://github.com/rust-lang/compiler-team/issues/694).
There is one aspect of this PR that will become insta-stable once these changes reach a stable compiler:
* A new `target_family` named `wasi` is introduced. This target family incorporates all wasi targets including `wasm32-wasi` and its derivative `wasm32-wasi-preview1-threads`. The difference between `target_family = wasi` and `target_os = wasi` will become much clearer when `wasm32-wasi` is renamed to `wasm32-wasi-preview1` and the `target_os` becomes `wasm32-wasi-preview1`. You can read about this target rename in [this MCP](https://github.com/rust-lang/compiler-team/issues/695) which has also been seconded and will hopefully be officially approved soon.
Additional technical details include:
* Both `std::sys::wasi_preview2` and `std::os::wasi_preview2` have been created and mostly use `#[path]` annotations on their submodules to reach into the existing `wasi` (soon to be `wasi_preview1`) modules. Over time the differences between `wasi_preview1` and `wasi_preview2` will grow and most like all `#[path]` based module aliases will fall away.
* Building `wasi-preview2` relies on a [`wasi-sdk`](https://github.com/WebAssembly/wasi-sdk) in the same way that `wasi-preview1` does (one must include a `wasi-root` path in the `Config.toml` pointing to sysroot included in the wasi-sdk). The target should build against [wasi-sdk v21](https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-21) without modifications. However, the wasi-sdk itself is growing [preview2 support](https://github.com/WebAssembly/wasi-sdk/pull/370) so this might shift rapidly. We will be following along quickly to make sure that building the target remains possible as the wasi-sdk changes.
* This requires a [patch to libc](https://github.com/rylev/rust-libc/tree/wasm32-wasi-preview2) that we'll need to land in conjunction with this change. Until that patch lands the target won't actually build.
os::net: expanding TcpStreamExt for Linux with `tcp_deferaccept`.
allows for socket to process only when there is data to process, the option sets a number of seconds until the data is ready.
rename 'try' intrinsic to 'catch_unwind'
The intrinsic has nothing to do with `try` blocks, and corresponds to the stable `catch_unwind` function, so this makes a lot more sense IMO.
Also rename Miri's special function while we are at it, to reflect the level of abstraction it works on: it's an unwinding mechanism, on which Rust implements panics.
Always use WaitOnAddress on Win10+
`WaitOnAddress` and `WakeByAddressSingle` are always available since Windows 8 so they can now be used without needing to delay load. I've also moved the Windows 7 thread parking fallbacks into a separate sub-module.
Fix sgx unit test compilation
Fixes a compilation error:
```
error[E0583]: file not found for module `tests`
--> library/std/src/sys/locks/rwlock/sgx.rs:2:1
|
2 | mod tests;
| ^^^^^^^^^^
|
= help: to create the module `tests`, create file "library/std/src/sys/locks/rwlock/sgx/tests.rs" or "library/std/src/sys/locks/rwlock/sgx/tests/mod.rs"
= note: if there is a `mod tests` elsewhere in the crate already, import it with `use crate::...` instead
For more information about this error, try `rustc --explain E0583`.
error: could not compile `std` (lib test) due to 1 previous error`
```
When running command:
```
`TF_BUILD=True RUST_TEST_THREADS=1 ./x.py test --stage 1 "library/std" tests/assembly tests/run-make --target=x86_64-fortanix-unknown-sgx --no-doc --exclude src/tools/linkchecker --exclude src/tools/rust-demangler --no-fail-fast 2>&1
```
The fix is done by moving a file to the location suggested by the compiler.
The issue was introduced by PR: https://github.com/rust-lang/rust/pull/121177
Implement `MappedMutexGuard`, `MappedRwLockReadGuard`, and `MappedRwLockWriteGuard`.
ACP: https://github.com/rust-lang/libs-team/issues/260
Tracking issue: https://github.com/rust-lang/rust/issues/117108
<details> <summary> (Outdated) </summary>
`MutexState`/`RwLockState` structs
~~Having `sys::(Mutex|RwLock)` and `poison::Flag` as separate fields in the `Mutex`/`RwLock` would require `MappedMutexGuard`/`MappedRwLockWriteGuard` to hold an additional pointer, so I combined the two fields into a `MutexState`/`RwLockState` struct. This should not noticeably affect perf or layout, but requires an additional field projection when accessing the former `.inner` or `.poison` fields (now `.state.inner` and `.state.poison`).~~ If this is not desired, then `MappedMutexGuard`/`MappedRwLockWriteGuard` can instead hold separate pointers to the two fields.
</details>
The doc-comments are mostly copied from the existing `*Guard` doc-comments, with some parts from `lock_api::Mapped*Guard`'s doc-comments.
Unresolved question: Are more tests needed?
Fix incorrect doc of ScopedJoinHandle::is_finished
Fixes the explanation how to use `is_finished` to achieve a non-blocking join. The updated version matches the documentation of the non-scoped JoinHandle::is_finished.
Fixes the explanation how to use is_finished to achieve a non-blocking
join. The updated version matches the documentation of the non-scoped
JoinHandle::is_finished.
Help with common API confusion, like asking for `push` when the data structure really has `append`.
```
error[E0599]: no method named `size` found for struct `Vec<{integer}>` in the current scope
--> $DIR/rustc_confusables_std_cases.rs:17:7
|
LL | x.size();
| ^^^^
|
help: you might have meant to use `len`
|
LL | x.len();
| ~~~
help: there is a method with a similar name
|
LL | x.resize();
| ~~~~~~
```
#59450
Add manual Sync impl for ReentrantLockGuard
Fixes: #125526
Tracking Issue: #121440
this impl is even shown in the summary in the tracking issue, but apparently was forgotten in the actual implementation
Currently all architecture-specific memchr code is only used in
`std::io`. Most of the actual `memchr` capacity exposed to the user
through the slice API is instead implemented in core::slice::memchr.
Hence this commit deletes memchr from std::sys[_common] and replace
calls to it by calls to core::slice::memchr functions. This deletes
(r)memchr from the list of symbols linked to libc.
Specialize some methods of `io::Chain`
This PR specializes the implementation of some methods of `io::Chain`, which could bring performance improvements when using it.
Reduce monomorphisation bloat in small_c_string
This is a code path usually next to an FFI call, so taking the `dyn` slowdown for the 1159 llvm-line (fat lto, codegen-units 1, release build) drop in my testing program [t2fanrd](https://github.com/GnomedDev/t2fanrd) is worth it imo.
Move `OsStr::slice_encoded_bytes` validation to platform modules
This delegates OS string slicing (`OsStr::slice_encoded_bytes`) validation to the underlying platform implementation. For now that results in increased performance and better error messages on Windows without any changes to semantics. In the future we may want to provide different semantics for different platforms.
The existing implementation is still used on Unix and most other platforms and is now optimized a little better.
Tracking issue: https://github.com/rust-lang/rust/issues/118485
cc `@epage,` `@BurntSushi`
Tracking import use types for more accurate redundant import checking
fixes#117448
By tracking import use types to check whether it is scope uses or the other situations like module-relative uses, we can do more accurate redundant import checking.
For example unnecessary imports in std::prelude that can be eliminated:
```rust
use std::option::Option::Some;//~ WARNING the item `Some` is imported redundantly
use std::option::Option::None; //~ WARNING the item `None` is imported redundantly
```
fixes#117448
For example unnecessary imports in std::prelude that can be eliminated:
```rust
use std::option::Option::Some;//~ WARNING the item `Some` is imported redundantly
use std::option::Option::None; //~ WARNING the item `None` is imported redundantly
```
Use a hardcoded constant instead of calling OpenProcessToken.
Now that Win 7 support is dropped, we can resurrect #90144.
GetCurrentProcessToken is defined in processthreadsapi.h as:
FORCEINLINE
HANDLE
GetCurrentProcessToken (
VOID
)
{
return (HANDLE)(LONG_PTR) -4;
}
Since it's very unlikely that this constant will ever change, let's just use it instead of making calls to get the same information.
Make `io::BorrowedCursor::advance` safe
This also keeps the old `advance` method under `advance_unchecked` name.
This makes pattern like `std::io::default_read_buf` safe to write.
Now that Win 7 support is dropped, we can resurrect #90144.
GetCurrentProcessToken is defined in processthreadsapi.h as:
FORCEINLINE
HANDLE
GetCurrentProcessToken (
VOID
)
{
return (HANDLE)(LONG_PTR) -4;
}
Since it's very unlikely that this constant will ever change, let's just use it instead of making calls to get the same information.
std::thread update freebsd stack guard handling.
up to now, it had been assumed the stack guard setting default is not touched in the field but some user might just want to disable it or increase it. checking it once at runtime should be enough.
Make contributing to windows bindings easier
This PR does three things:
- Automatically sorts bindings so contributors don't have to. I should have done this to begin with but was lazy.
- Renames `windows_sys.lst` to `bindings.txt`. This [matches the windows-rs repository](8e71051ea8/crates/tools/sys/bindings.txt) (and repos that copy it). I believe consistency with other projects helps get people orientated.
- Adds a `README.md` file explaining what this is about and how to add bindings. This has the benefit of being directly editable and it's rendered when viewed online. Also people are understandably jumping right into the `windows_sys.rs` file via ripgrep or github search and so missing that it's generated. A `README.md` alongside it is at least slightly more obvious in that case. There is still a small note at the top of `windows_sys` in case people do read from the beginning.
None of this has any impact on the actual code generated. It's purely to make the new contributors workflow a bit nicer.
Rollup of 13 pull requests
Successful merges:
- #116387 (Additional doc links and explanation of `Wake`.)
- #118738 (Netbsd10 update)
- #118890 (Clarify the lifetimes of allocations returned by the `Allocator` trait)
- #120498 (Uplift `TypeVisitableExt` into `rustc_type_ir`)
- #120530 (Be less confident when `dyn` suggestion is not checked for object safety)
- #120915 (Fix suggestion span for `?Sized` when param type has default)
- #121015 (Optimize `delayed_bug` handling.)
- #121024 (implement `Default` for `AsciiChar`)
- #121039 (Correctly compute adjustment casts in GVN)
- #121045 (Fix two UI tests with incorrect directive / invalid revision)
- #121049 (Do not point at `#[allow(_)]` as the reason for compat lint triggering)
- #121071 (Use fewer delayed bugs.)
- #121073 (Fix typos in `OneLock` doc)
r? `@ghost`
`@rustbot` modify labels: rollup
Optimize away poison guards when std is built with panic=abort
> **Note**: To take advantage of this PR, you will have to use `-Zbuild-std` or build your own toolchain. rustup toolchains always link to a libstd that was compiled with `panic=unwind`, since it's compatible with `panic=abort` code.
When std is compiled with `panic=abort` we can remove a lot of the poison machinery from the locks. This changes the `Flag` and `Guard` types to be ZSTs. It also adds an uninhabited member to `PoisonError` so the compiler knows it can optimize away the `Result::Err` paths, and make `LockResult<T>` layout-equivalent to `T`.
### Is this a breaking change?
`PoisonError::new` now panics if invoked from a libstd built with `panic="abort"` (or any non-`unwind` strategy). It is unclear to me whether to consider this a breaking change.
In order to encounter this behavior, **both of the following must be true**:
#### Using a libstd with `panic="abort"`
This is pretty uncommon. We don't build libstd with that in rustup, except in (Tier 2-3) platforms that do not support unwinding, **most notably wasm**.
Most people who do this are using cargo's `-Z build-std` feature, which is unstable.
`panic="abort"` is not a supported option in Rust's build system. It is possible to configure it using `CARGO_TARGET_xxx_RUSTFLAGS`, but I believe this only works on **non-host** platforms.
#### Creating `PoisonError` manually
This is also unlikely. The only common use case I can think of is in tests, and you can't run tests with `panic="abort"` without the unstable `-Z panic_abort_tests` flag.
It's possible that someone is implementing their own locks using std's `PoisonError` **and** defining "thread failure" to mean something other than "panic". If this is the case then we would break their code if it was used with a `panic="abort"` libstd. The locking crates I know of don't replicate std's poison API, but I haven't done much research into this yet.
I've touched on a fair number of considerations here. Which ones do people consider relevant?
`compile_fail` should only be used when the code is meant to show
what *not* to do. In other words, there should be a fundamental flaw
in the code. However, in this case, the example is just incomplete,
so we should use `ignore` to avoid confusing readers.
Implement sys/thread for UEFI
Since UEFI has no concept of threads, most of this module can be ignored. However, implementing parts that make sense.
- Implement sleep
- Implement available_parallelism
Replace pthread `RwLock` with custom implementation
This is one of the last items in #93740. I'm doing `RwLock` first because it is more self-contained and has less tradeoffs to make. The motivation is explained in the documentation, but in short: the pthread rwlock is slow and buggy and `std` can do much better. I considered implementing a parking lot, as was discussed in the tracking issue, but settled for the queue-based version because writing self-balancing binary trees is not fun in Rust...
This is a rather complex change, so I have added quite a bit of documentation to help explain it. Please point out any part that could be explained better.
~~The read performance is really good, I'm getting 4x the throughput of the pthread version and about the same performance as usync/parking_lot on an Apple M1 Max in the usync benchmark suite, but the write performance still falls way behind what usync and parking_lot achieve. I tried using a separate queue lock like what usync uses, but that didn't help. I'll try to investigate further in the future, but I wanted to get some eyes on this first.~~ [Resolved](https://github.com/rust-lang/rust/pull/110211#issuecomment-1513682336)
r? `@m-ou-se`
CC `@kprotty`
Make cmath.rs a single file
It makes sense to have this all in one file. There's essentially only one target that has missing symbols and that's easy enough to handle inline.
Note that the Windows definitions used to use `c_float` and `c_double` whereas the other platforms all used `f32` and `f64`. They've now been made consistent. However, `c_float` and `c_double` have the expected definitions on all Windows platforms we support.
Since UEFI has no concept of threads, most of this module can be
ignored. However, implementing parts that make sense.
- Implement sleep
- Implement available_parallelism
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
Introducing a new config for this purpose as NetBSD 9 or 8 will be still around
for a good while. For now, we re finally enabling sys::unix::rand::getrandom.
up to now, it had been assumed the stack guard setting default is not
touched in the field but some user might just want to disable it or
increase it. checking it once at runtime should be enough.
Always check the result of `pthread_mutex_lock`
Fixes#120147.
Instead of manually adding a list of "good" platforms, I've simply made the check unconditional. pthread's mutex is already quite slow on most platforms, so one single well-predictable branch shouldn't hurt performance too much.
fix#120603 by adding a check in default_read_buf
Fixes#120603 by checking the returned read n is in-bounds of the cursor.
Interestingly, I noticed that `BorrowedBuf` side-steps this issue by using checked accesses. Maybe this can be switched to unchecked to mirror what BufReader does bf3c6c5bed/library/core/src/io/borrowed_buf.rs (L95)
Store SHOULD_CAPTURE as AtomicU8
`BacktraceStyle` easily fits into a u8, so `SHOULD_CAPTURE`, which is just `Atomic<Option<BacktraceStyle>>`, should be stored as `AtomicU8`
std: thread_local::register_dtor fix proposal for FreeBSD.
following-up 5d3d347 commit, rust started to spin
__cxa_thread_call_dtors warnings even without any TLS usage. using instead home made TLS destructor handler `register_dtor_fallback`.
close#120413
Revert outdated version of "Add the wasm32-wasi-preview2 target"
An outdated version of #119616 was merged in rollup #120309.
This reverts those changes to enable #119616 to “retain the intended diff” after a rebase.
```@rylev``` has agreed that this would be the cleanest approach with respect to the history.
Unblocks #119616.
r? ```@petrochenkov``` or compiler or libs
std: Update documentation of seek_write on Windows
Currently the documentation of `FileExt::seek_write` on Windows indicates that writes beyond the end of the file leave intermediate bytes uninitialized. This commentary dates back to the original inclusion of these functions in #35704 (wow blast from the past!). At the time the functionality here was implemented using `WriteFile`, but nowadays the `NtWriteFile` method is used instead. The documentation for `NtWriteFile` explicitly states:
> If Length and ByteOffset specify a write operation past the current
> end-of-file mark, NtWriteFile automatically extends the file and updates
> the end-of-file mark; any bytes that are not explicitly written between
> such old and new end-of-file marks are defined to be zero.
This commentary has had a downstream impact in the `system-interface` crate where it tries to handle this by explicitly writing zeros, but I don't believe that's necessary any more. I'm sending a PR upstream here to avoid future confusion and codify that zeros are written in the intermediate bytes matching what Windows currently provides.
Handle out of memory errors in io:Read::read_to_end()
#116570 got stuck due to a [procedural confusion](https://github.com/rust-lang/rust/pull/116570#issuecomment-1768271068). Retrying so that it can get FCP with the proper team now. cc `@joshtriplett` `@BurntSushi`
----
I'd like to propose handling of out-of-memory errors in the default implementation of `io::Read::read_to_end()` and `fs::read()`. These methods create/grow a `Vec` with a size that is external to the program, and could be arbitrarily large.
Due to being I/O methods, they can already fail in a variety of ways, in theory even including `ENOMEM` from the OS too, so another failure case should not surprise anyone.
While this may not help much Linux with overcommit, it's useful for other platforms like WASM. [Internals thread](https://internals.rust-lang.org/t/io-read-read-to-end-should-handle-oom/19662).
I've added documentation that makes it explicit that the OOM handling is a nice-to-have, and not a guarantee of the trait.
I haven't changed the implementation of `impl Read for &[u8]` and `VecDeque` out of caution, because in these cases users could assume `read` can't fail.
This code uses `try_reserve()` + `extend_from_slice()` which is optimized since #117503.
Adjust Behaviour of `read_dir` and `ReadDir` in Windows Implementation: Check Whether Path to Search In Exists
This pull request changes the `read_dir` function's and the `ReadDir` structure's internal implementations for the Windows operating system to make its behaviour more accurate.
It should be noted that `ERROR_FILE_NOT_FOUND` is returned by the `FindFirstFileW` function when *no matching files can be found*, not necessarily that the path to search in does not exist in the first place. Therefore, directly returning the "The system cannot find the file specified." may not be accurate.
An extra check for whether the path to search in exists is added, returning a constructed `ReadDir` iterator with its handle being an `INVALID_HANDLE_VALUE` returned by the `FindFirstFileW` function if `ERROR_FILE_NOT_FOUND` is indeed the last OS error. The `ReadDir` implementation for the Windows operating system is correspondingly updated to always return `None` if the handle it has is an `INVALID_HANDLE_VALUE` which can only be the case if and only if specifically constructed by the `read_dir` function in the aforementioned conditions.
It should also be noted that `FindFirstFileW` would have returned `ERROR_PATH_NOT_FOUND` if the path to search in does not exist in the first place.
Presumably fixes#120040.
Currently the documentation of `FileExt::seek_write` on Windows
indicates that writes beyond the end of the file leave intermediate
bytes uninitialized. This commentary dates back to the original
inclusion of these functions in #35704 (wow blast from the past!). At
the time the functionality here was implemented using `WriteFile`, but
nowadays the `NtWriteFile` method is used instead. The documentation for
`NtWriteFile` explicitly states:
> If Length and ByteOffset specify a write operation past the current
> end-of-file mark, NtWriteFile automatically extends the file and updates
> the end-of-file mark; any bytes that are not explicitly written between
> such old and new end-of-file marks are defined to be zero.
This commentary has had a downstream impact in the `system-interface`
crate where it tries to handle this by explicitly writing zeros, but I
don't believe that's necessary any more. I'm sending a PR upstream here
to avoid future confusion and codify that zeros are written in the
intermediate bytes matching what Windows currently provides.
following-up 5d3d347 commit, rust started to spin
__cxa_thread_call_dtors warnings even without any TLS usage.
using instead home made TLS destructor handler `register_dtor_fallback`.
close#120413
std: make `HEAP` initializer never inline
The system allocator for Windows calls `init_or_get_process_heap` every time allocating. It generates very much useless code and makes the binary larger. The `HEAP` only needs to initialize once before the main fn.
Concerns:
* I'm not sure if `init` will be properly called in cdylib.
* Do we need to ensure the allocator works if the user enables `no_main`?
* Should we panic if `GetProcessHeap` returns null?
Specialize `Bytes` on `StdinLock<'_>`
I noticed recently, while profiling a little project, that I was spending a lot of time reading from stdin (even with locking). I was using the `.bytes()` iterator adaptor; I figured, since `StdinLock` is a `BufReader` internally, it would work just as fast. But this is not the case, as `Bytes` is only specialized for the raw `BufReader`, and not the `StdinLock`/`MutexGuard` wrapper. Performance improved significantly when I wrapped the lock in a new `BufReader`, but I was still a bit sore about the double buffer indirection.
This PR attempts to specialize it, by simply calling the already specialized implementation on `BufReader`.
Clean up after clone3 removal from pidfd code (docs and tests)
https://github.com/rust-lang/rust/pull/113939 removed clone3 from pidfd code. This patchset does necessary clean up: fixes docs and tests
Add a new `wasm32-wasi-preview2` target
This is the initial implementation of the MCP https://github.com/rust-lang/compiler-team/issues/694 creating a new tier 3 target `wasm32-wasi-preview2`. That MCP has been seconded and will most likely be approved in a little over a week from now. For more information on the need for this target, please read the [MCP](https://github.com/rust-lang/compiler-team/issues/694).
There is one aspect of this PR that will become insta-stable once these changes reach a stable compiler:
* A new `target_family` named `wasi` is introduced. This target family incorporates all wasi targets including `wasm32-wasi` and its derivative `wasm32-wasi-preview1-threads`. The difference between `target_family = wasi` and `target_os = wasi` will become much clearer when `wasm32-wasi` is renamed to `wasm32-wasi-preview1` and the `target_os` becomes `wasm32-wasi-preview1`. You can read about this target rename in [this MCP](https://github.com/rust-lang/compiler-team/issues/695) which has also been seconded and will hopefully be officially approved soon.
Additional technical details include:
* Both `std::sys::wasi_preview2` and `std::os::wasi_preview2` have been created and mostly use `#[path]` annotations on their submodules to reach into the existing `wasi` (soon to be `wasi_preview1`) modules. Over time the differences between `wasi_preview1` and `wasi_preview2` will grow and most like all `#[path]` based module aliases will fall away.
* Building `wasi-preview2` relies on a [`wasi-sdk`](https://github.com/WebAssembly/wasi-sdk) in the same way that `wasi-preview1` does (one must include a `wasi-root` path in the `Config.toml` pointing to sysroot included in the wasi-sdk). The target should build against [wasi-sdk v21](https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-21) without modifications. However, the wasi-sdk itself is growing [preview2 support](https://github.com/WebAssembly/wasi-sdk/pull/370) so this might shift rapidly. We will be following along quickly to make sure that building the target remains possible as the wasi-sdk changes.
* This requires a [patch to libc](https://github.com/rylev/rust-libc/tree/wasm32-wasi-preview2) that we'll need to land in conjunction with this change. Until that patch lands the target won't actually build.
remove tests/ui/command/command-create-pidfd.rs . But it contains
very useful comment, so let's move the comment to library/std/src/sys/pal/unix/rand.rs ,
which contains another instance of the same Docker problem
riscv32im-risc0-zkvm-elf: add target
This pull request adds RISC Zero's Zero Knowledge Virtual Machine (zkVM) as a target for rust. The zkVM used to produce proofs of execution of RISC-V ELF binaries. In order to do this, the target will execute the ELF to generate a receipt containing the output of the computation along with a cryptographic seal. This receipt can be verified to ensure the integrity of the computation and its result. This target is implemented as software only; it has no hardware implementation.
## Tier 3 target policy:
Here is a copy of the tier 3 target policy:
> Tier 3 target policy:
>
> At this tier, the Rust project provides no official support for a target, so we
> place minimal requirements on the introduction of targets.
>
> A proposed new tier 3 target must be reviewed and approved by a member of the
> compiler team based on these requirements. The reviewer may choose to gauge
> broader compiler team consensus via a [[Major Change Proposal (MCP)](https://forge.rust-lang.org/compiler/mcp.html)](https://forge.rust-lang.org/compiler/mcp.html).
>
> A proposed target or target-specific patch that substantially changes code
> shared with other targets (not just target-specific code) must be reviewed and
> approved by the appropriate team for that shared code before acceptance.
>
> - A tier 3 target must have a designated developer or developers (the "target
> maintainers") on record to be CCed when issues arise regarding the target.
> (The mechanism to track and CC such developers may evolve over time.)
The maintainers are named in the target description file
> - Targets must use naming consistent with any existing targets; for instance, a
> target for the same CPU or OS as an existing Rust target should use the same
> name for that CPU or OS. Targets should normally use the same names and
> naming conventions as used elsewhere in the broader ecosystem beyond Rust
> (such as in other toolchains), unless they have a very good reason to
> diverge. Changing the name of a target can be highly disruptive, especially
> once the target reaches a higher tier, so getting the name right is important
> even for a tier 3 target.
> - Target names should not introduce undue confusion or ambiguity unless
> absolutely necessary to maintain ecosystem compatibility. For example, if
> the name of the target makes people extremely likely to form incorrect
> beliefs about what it targets, the name should be changed or augmented to
> disambiguate it.
> - If possible, use only letters, numbers, dashes and underscores for the name.
> Periods (`.`) are known to cause issues in Cargo.
>
We understand.
> - Tier 3 targets may have unusual requirements to build or use, but must not
> create legal issues or impose onerous legal terms for the Rust project or for
> Rust developers or users.
> - The target must not introduce license incompatibilities.
We understand and will not introduce incompatibilities. All of our code that we publish is licensed under Apache-2.0.
> - Anything added to the Rust repository must be under the standard Rust license (`MIT OR Apache-2.0`).
We understand. We are open to either license for the Rust repository.
> - The target must not cause the Rust tools or libraries built for any other
> host (even when supporting cross-compilation to the target) to depend
> on any new dependency less permissive than the Rust licensing policy. This
> applies whether the dependency is a Rust crate that would require adding
> new license exceptions (as specified by the `tidy` tool in the
> rust-lang/rust repository), or whether the dependency is a native library
> or binary. In other words, the introduction of the target must not cause a
> user installing or running a version of Rust or the Rust tools to be
> subject to any new license requirements.
We understand. The runtime libraries and the execution environment and software associated with this environment uses `Apache-2.0` so this should not be an issue.
> - Compiling, linking, and emitting functional binaries, libraries, or other
> code for the target (whether hosted on the target itself or cross-compiling
> from another target) must not depend on proprietary (non-FOSS) libraries.
> Host tools built for the target itself may depend on the ordinary runtime
> libraries supplied by the platform and commonly used by other applications
> built for the target, but those libraries must not be required for code
> generation for the target; cross-compilation to the target must not require
> such libraries at all. For instance, `rustc` built for the target may
> depend on a common proprietary C runtime library or console output library,
> but must not depend on a proprietary code generation library or code
> optimization library. Rust's license permits such combinations, but the
> Rust project has no interest in maintaining such combinations within the
> scope of Rust itself, even at tier 3.
We understand. We only depend on FOSS libraries. Dependencies such as runtime libraries for this target are licensed as `Apache-2.0`.
> - "onerous" here is an intentionally subjective term. At a minimum, "onerous"
> legal/licensing terms include but are *not* limited to: non-disclosure
> requirements, non-compete requirements, contributor license agreements
> (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms,
> requirements conditional on the employer or employment of any particular
> Rust developers, revocable terms, any requirements that create liability
> for the Rust project or its developers or users, or any requirements that
> adversely affect the livelihood or prospects of the Rust project or its
> developers or users.
There are no such terms present
> - Neither this policy nor any decisions made regarding targets shall create any
> binding agreement or estoppel by any party. If any member of an approving
> Rust team serves as one of the maintainers of a target, or has any legal or
> employment requirement (explicit or implicit) that might affect their
> decisions regarding a target, they must recuse themselves from any approval
> decisions regarding the target's tier status, though they may otherwise
> participate in discussions.
I am not the reviewer of this pull request
> - This requirement does not prevent part or all of this policy from being
> cited in an explicit contract or work agreement (e.g. to implement or
> maintain support for a target). This requirement exists to ensure that a
> developer or team responsible for reviewing and approving a target does not
> face any legal threats or obligations that would prevent them from freely
> exercising their judgment in such approval, even if such judgment involves
> subjective matters or goes beyond the letter of these requirements.
We understand.
> - Tier 3 targets should attempt to implement as much of the standard libraries
> as possible and appropriate (`core` for most targets, `alloc` for targets
> that can support dynamic memory allocation, `std` for targets with an
> operating system or equivalent layer of system-provided functionality), but
> may leave some code unimplemented (either unavailable or stubbed out as
> appropriate), whether because the target makes it impossible to implement or
> challenging to implement. The authors of pull requests are not obligated to
> avoid calling any portions of the standard library on the basis of a tier 3
> target not implementing those portions.
The target implements core and alloc. And std support is currently experimental as some functionalities in std are either a) not applicable to our target or b) more work in research and experimentation needs to be done. For more information about the characteristics of this target, please refer to the target description file.
> - The target must provide documentation for the Rust community explaining how
> to build for the target, using cross-compilation if possible. If the target
> supports running binaries, or running tests (even if they do not pass), the
> documentation must explain how to run such binaries or tests for the target,
> using emulation if possible or dedicated hardware if necessary.
See file target description file
> - Tier 3 targets must not impose burden on the authors of pull requests, or
> other developers in the community, to maintain the target. In particular,
> do not post comments (automated or manual) on a PR that derail or suggest a
> block on the PR based on a tier 3 target. Do not send automated messages or
> notifications (via any medium, including via ``@`)` to a PR author or others
> involved with a PR regarding a tier 3 target, unless they have opted into
> such messages.
We understand.
> - Backlinks such as those generated by the issue/PR tracker when linking to
> an issue or PR are not considered a violation of this policy, within
> reason. However, such messages (even on a separate repository) must not
> generate notifications to anyone involved with a PR who has not requested
> such notifications.
We understand.
> - Patches adding or updating tier 3 targets must not break any existing tier 2
> or tier 1 target, and must not knowingly break another tier 3 target without
> approval of either the compiler team or the maintainers of the other tier 3
> target.
> - In particular, this may come up when working on closely related targets,
> such as variations of the same architecture with different features. Avoid
> introducing unconditional uses of features that another variation of the
> target may not have; use conditional compilation or runtime detection, as
> appropriate, to let each target run code supported by that target.
We understand.
> If a tier 3 target stops meeting these requirements, or the target maintainers
> no longer have interest or time, or the target shows no signs of activity and
> has not built for some time, or removing the target would improve the quality
> of the Rust codebase, we may post a PR to remove it; any such PR will be CCed
> to the target maintainers (and potentially other people who have previously
> worked on the target), to check potential interest in improving the situation.
We understand.
Use `assert_unchecked` instead of `assume` intrinsic in the standard library
Now that a public wrapper for the `assume` intrinsic exists, we can use it in the standard library.
CC #119131
Fix tty detection for msys2's `/dev/ptmx`
Our "true negative" detection assumes that if at least one std handle is a Windows console then no other handle will be a msys2 tty pipe. This turns out to be a faulty assumption in the case of redirection to `/dev/ptmx` in an msys2 shell. Maybe this is an msys2 bug but in any case we should try to make it work.
An alternative to this would be to replace the "true negative" detection with an attempt to detect if we're in an msys environment (e.g. by sniffing environment variables) but that seems like it'd be flaky too.
Fixes#119658
Rollup of 10 pull requests
Successful merges:
- #117910 (Refactor uses of `objc_msgSend` to no longer have clashing definitions)
- #118639 (Undeprecate lint `unstable_features` and make use of it in the compiler)
- #119801 (Fix deallocation with wrong allocator in (A)Rc::from_box_in)
- #120058 (bootstrap: improvements for compiler builds)
- #120059 (Make generic const type mismatches not hide trait impls from the trait solver)
- #120097 (Report unreachable subpatterns consistently)
- #120137 (Validate AggregateKind types in MIR)
- #120164 (`maybe_lint_impl_trait`: separate `is_downgradable` from `is_object_safe`)
- #120181 (Allow any `const` expression blocks in `thread_local!`)
- #120218 (rustfmt: Check that a token can begin a nonterminal kind before parsing it as a macro arg)
r? `@ghost`
`@rustbot` modify labels: rollup
Co-authored-by: Frank Laub <flaub@risc0.com>
Co-authored-by: nils <nils@risc0.com>
Co-authored-by: Victor Graf <victor@risczero.com>
Co-authored-by: weikengchen <w.k@berkeley.edu>
Allow any `const` expression blocks in `thread_local!`
This PR contains a rebase of the macro change from #116392, together with adding a test under library/std/tests.
Testing this feature by making the documentation's example code needlessly more complicated was not appropriate as pointed out in https://github.com/rust-lang/rust/pull/116392#pullrequestreview-1753097757.
Without the macro change, this new test would fail to build as follows:
```console
error: no rules expected the token `let`
--> library/std/tests/thread.rs:26:13
|
26 | let value = 1;
| ^^^ no rules expected this token in macro call
|
note: while trying to match meta-variable `$init:expr`
--> library/std/src/thread/local.rs:189:69
|
189 | ($(#[$attr:meta])* $vis:vis static $name:ident: $t:ty = const { $init:expr }; $($rest:tt)*) => (
| ^^^^^^^^^^
```
Closes#116392.
Refactor uses of `objc_msgSend` to no longer have clashing definitions
This is very similar to what Apple's own headers encourage you to do (cast the function pointer before use instead of making new declarations).
Additionally, I'm documenting a few of the memory management rules we're following, ensuring that the `args` function doesn't leak memory (if you wrap it in an autorelease pool).
Motivation is to avoid issues with clashing definitions, like described in https://github.com/rust-lang/rust/issues/12707#issuecomment-1570735643 and https://github.com/rust-lang/rust/issues/46188#issuecomment-1288058453, CC ``@bjorn3.``
std::net: bind update for using backlog as `-1` too.
Albeit not documented, macOs also support negative value for the backlog argument.
ref: 2ff845c2e0/bsd/kern/uipc_socket.c (L1061)
xous: misc fixes + add network support
This patchset makes several fixes to Xous support. Additionally, this patch adds networking support.
Many of these fixes are the result of the recent patch to get `unwinding` support merged. As a result of this patch, we can now run rust tests. As a result of these tests, we now have 729 tests passing:
```
failures:
env::tests::test
env::tests::test_self_exe_path
env::tests::vars_debug
env::tests::vars_os_debug
os::raw::tests::same
path::tests::test_push
path::tests::test_set_file_name
time::tests::since_epoch
test result: FAILED. 729 passed; 8 failed; 1 ignored; 0 measured; 0 filtered out; finished in 214.54s
```
In the course of fixing several tests and getting the test sequence to reliably run, several issues were found. This patchset fixes those issues.
Our "true negative" detection assumes that if at least one std handle is a Windows console then no other handle will be a msys2 tty pipe. This turns out to be a faulty assumption in the case of `/dev/ptmx`.
On Windows and UEFI this improves performance and error messaging.
On other platforms we optimize the fast path a bit more.
This also prepares for later relaxing the checks on certain platforms.
Move OS String implementation into `sys`
Part of #117276. The new structure is really useful here, since we can easily eliminate a number of ugly `#[path]`-based imports.
In the future, it might be good to move the WTF-8 implementation directly to the OS string implementation, I cannot see it being used anywhere else. That is a story for another PR, however.
- Do not drop any character while reading
- eabdf == Unsupported status
- loop untill read character or error encountered
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
Add `display` method to `OsStr` for lossy display of an `OsStr` which may contain invalid unicode.
Invalid Unicode sequences are replaced with `U+FFFD REPLACEMENT CHARACTER`.
This change also makes the `std::ffi::os_str` module public.
std: Doc blocking behavior of LazyLock
Adding notes about blocking behavior of calls that can block the current thread, similar to those on https://doc.rust-lang.org/std/sync/struct.OnceLock.html
I'm not sure if the "This method never blocks." counterparts would be desired. If so, can add those, as well.
ARMv6K HorizonOS - Fix backlog for UnixListener
Simple `#[cfg]` fix to avoid using `libc::SOMAXCONN`, which isn't defined for the `armv6k-nintendo-3ds` target.
Edit: This is similar to #119632.
This is very similar to what Apple's own headers encourage you to do (cast the function pointer before use instead of making new declarations).
Additionally, I'm documenting a few of the memory management rules we're following, ensuring that the `args` function doesn't leak memory (if you wrap it in an autorelease pool).
This is an initial commit of network support for Xous.
On hardware, is backed by smoltcp running via a Xous server in a
separate process space.
This patch adds TCP and UDP client and server support as well as DNS
resolution support using the dns Xous server.
Signed-off-by: Sean Cross <sean@xobs.io>
When using the testing framework, a second copy of libstd is built and
linked. Use a global symbol for the `DLMALLOC` variable and mark it as
`extern` when building as a test.
This ensures we only have a single allocator even when running tests.
Signed-off-by: Sean Cross <sean@xobs.io>
When running tests, libstd gets implemented as a second library. Due to
this fact, the `create()` and `destroy()` functions come from different
libraries.
To work around this, stash the `destroy_tls()` pointer in the first
unused slot in the thread local storage pool. That way even if
the destruction comes from a different version of libstd, the correct
`DTORS` list will be consulted.
Signed-off-by: Sean Cross <sean@xobs.io>
Use the global queue implementation of Once when running on Xous. This
gets us a thread-safe implementation, rather than using the
non-threadsafe `unsupported` implementation.
Signed-off-by: Sean Cross <sean@xobs.io>
Add more checks to RwLock on Xous. As part of this, ensure the variable
is in a good state when unlocking.
Additionally, use the global `yield_now()` rather than platform-specific
`do_yield()`.
Signed-off-by: Sean Cross <sean@xobs.io>
Use blocking scalars when unlocking a mutex. This ensures that mutexes
are unlocked immediately rather than dangling.
Signed-off-by: Sean Cross <sean@xobs.io>
When updating memory flags via `update_memory_flags()`, ensure we
multiply the slice length by the element size to get the full memory
size.
Signed-off-by: Sean Cross <sean@xobs.io>
Rework the Condvar implementation on Xous to ensure notifications are
not missed. This involves keeping track of how many times a Condvar
timed out and synchronizing based on that.
Signed-off-by: Sean Cross <sean@xobs.io>
Fix a deadlock condition that can occur when a thread is awoken in
between the point at which it checks its wake state and the point where
it actually waits.
This change will cause the waker to continuously send Notify messages
until it actually wakes up the target thread.
Signed-off-by: Sean Cross <sean@xobs.io>
The amount of memory allocated was multiplied by sizeof::<T>(), so the
amount of memory to be freed should also be multiplied by sizeof::<T>().
Signed-off-by: Sean Cross <sean@xobs.io>
The `ret1` and `ret2` return values from lend operations are returned in
$a1 and $a2. This function incorrectly pulled them from $a6 and $a7,
causing them to always be `0`.
Signed-off-by: Sean Cross <sean@xobs.io>
Move platform modules into `sys::pal`
This is the initial step of #117276. `sys` just re-exports everything from the current `sys` for now, I'll move the implementations for the individual features one-by-one after this PR merges.
Making `User<T>` and `User<[T]>` `Send`
All `User` types in SGX point to owned memory in userspace. Special care is always needed when accessing this memory as it must be assumed that an attacker is always able to change its content. Therefore, we can also easily transfer this memory between thread boundaries.
cc: ``@mzohreva`` ``@vn971`` ``@belalH`` ``@jethrogb``
Fix broken build for ESP IDF due to #119026
`target_os = "espidf"` in `libc` lacks the `SOMAXCONN` constant, but that's probably irrelevant in this context, as `UnixListener` is not supported on ESP IDF - it being a single process "OS" only.
The PR just re-uses the `128` constant so that the code builds. Trying to use the listener on ESP IDF will fail with `ENOSYS`, which is fine.
*UPDATE* Might not fail with `ENOSYS` - need to test what error code would be returned, but that doesn`t change anything.
merge core_panic feature into panic_internals
I don't know why those are two separate features, but it does not seem intentional. This merge is useful because with https://github.com/rust-lang/rust/pull/118123, panic_internals is recognized as an internal feature, but core_panic is not -- but core_panic definitely should be internal.
Update `thread_local` examples to use `local_key_cell_methods`
`local_key_cell_methods` has been stable for a while and provides a much less clunky way to interface with thread-local
Additionaly add context to the documentation about why types with interior mutability are needed.
r? libs
Document that File does not buffer reads/writes
...and refer to `BufReader`/`BufWriter`.
This is a common source of efficiency issues in Rust programs written naively. Including this information with the `File` docs, and adding a link to the wrapper types, will help discoverability.
`local_key_cell_methods` has been stable for a while and provides a much less
clunky way to interface with thread-local variables.
Additionaly add context to the documentation about why types with interior
mutability are needed.
use the standard sysconf(_SC_NPROCESSORS_ONLN) way to get the number of
available processors (capable of running processes), and fallback to
sysctl([CTL_HW, HW_NCPU]) (number of CPUs configured) only on error.
it permits to differenciate CPUs online vs CPUs configured (and not necessary
capable of running processes).
while here, use the common code path for BSDs for doing that, and avoid code
duplication.
Problem initially reported to me by Jiri Navratil.
adds a column number to `dbg!()`
this would be very nice to have for a few reasons:
1. the rfc, when deciding not to add column numbers to macro, failed to acknowledge any potential ambiguous cases -- such as the one provided in #114910 -- which do exist
2. would be able to consistently and easily jump directly to the `dbg!()` regardless of the sutation
3. takes up, at a maximum, 3 characters of _horizontal_ screen space
fixes#114910
Collect lang items from AST, get rid of `GenericBound::LangItemTrait`
r? `@cjgillot`
cc #115178
Looking forward, the work to remove `QPath::LangItem` will also be significantly more difficult, but I plan on doing it as well. Specifically, we have to change:
1. A lot of `rustc_ast_lowering` for things like expr `..`
2. A lot of astconv, since we actually instantiate lang and non-lang paths quite differently.
3. A ton of diagnostics and clippy lints that are special-cased via `QPath::LangItem`
Meanwhile, it was pretty easy to remove `GenericBound::LangItemTrait`, so I just did that here.
Rollup of 3 pull requests
Successful merges:
- #116888 (Add discussion that concurrent access to the environment is unsafe)
- #118888 (Uplift `TypeAndMut` and `ClosureKind` to `rustc_type_ir`)
- #118929 (coverage: Tidy up early parts of the instrumentor pass)
r? `@ghost`
`@rustbot` modify labels: rollup
Add discussion that concurrent access to the environment is unsafe
The bug report #27970 has existed for 8 years, the actual bug dates back to Rust pre-1.0. I documented it since it's in the interest of the user to be aware of it. The note can be removed once #27970 is fixed.
Fix cases where std accidentally relied on inline(never)
This PR increases the power of `-Zcross-crate-inline-threshold=always` so that it applies through `#[inline(never)]`. Note that though this is called "cross-crate-inlining" in this case especially it is _just_ lazy per-CGU codegen. The MIR inliner and LLVM still respect the attribute as much as they ever have.
Trying to bootstrap with the new `-Zcross-crate-inline-threshold=always` change revealed two bugs:
We have special intrinsics `assert_inhabited`, `assert_zero_valid`, and `assert_mem_uniniitalized_valid` which codegen backends will lower to nothing or a call to `panic_nounwind`. Since we may not have any call to `panic_nounwind` in MIR but emit one anyway, we need to specially tell `MirUsedCollector` about this situation.
`#[lang = "start"]` is special-cased already so that `MirUsedCollector` will collect it, but then when we make it cross-crate-inlinable it is only assigned to a CGU based on whether `MirUsedCollector` saw a call to it, which of course we didn't.
---
I started looking into this because https://github.com/rust-lang/rust/pull/118683 revealed a case where we were accidentally relying on a function being `#[inline(never)]`, and cranking up cross-crate-inlinability seems like a way to find other situations like that.
r? `@nnethercote` because I don't like what I'm doing to the CGU partitioning code here but I can't come up with something much better
Windows: Allow `File::create` to work on hidden files
This makes `OpenOptions::new().write(true).create(true).truncate(true).open(&path)` work if the path exists and is a hidden file. Previously it would fail with access denied.
This makes it consistent with `OpenOptions::new().write(true).truncate(true).open(&path)` (note the lack of `create`) which does not have this restriction. It's also more consistent with other platforms.
Fixes#115745 (see that issue for more details).
remove redundant imports
detects redundant imports that can be eliminated.
for #117772 :
In order to facilitate review and modification, split the checking code and removing redundant imports code into two PR.
r? `@petrochenkov`
detects redundant imports that can be eliminated.
for #117772 :
In order to facilitate review and modification, split the checking code and
removing redundant imports code into two PR.
Add emulated TLS support
This is a reopen of https://github.com/rust-lang/rust/pull/96317 . many android devices still only use 128 pthread keys, so using emutls can be helpful.
Currently LLVM uses emutls by default for some targets (such as android, openbsd), but rust does not use it, because `has_thread_local` is false.
This commit has some changes to allow users to enable emutls:
1. add `-Zhas-thread-local` flag to specify that std uses `#[thread_local]` instead of pthread key.
2. when using emutls, decorate symbol names to find thread local symbol correctly.
3. change `-Zforce-emulated-tls` to `-Ztls-model=emulated` to explicitly specify whether to generate emutls.
r? `@Amanieu`
Currently LLVM uses emutls by default
for some targets (such as android, openbsd),
but rust does not use it, because `has_thread_local` is false.
This commit has some changes to allow users to enable emutls:
1. add `-Zhas-thread-local` flag to specify
that std uses `#[thread_local]` instead of pthread key.
2. when using emutls, decorate symbol names
to find thread local symbol correctly.
3. change `-Zforce-emulated-tls` to `-Ztls-model=emulated`
to explicitly specify whether to generate emutls.
Use `unwinding` crate for unwinding on Xous platform
This patch adds support for using [unwinding](https://github.com/nbdd0121/unwinding) on platforms where libunwinding isn't viable. An example of such a platform is `riscv32imac-unknown-xous-elf`.
### Background
The Rust project maintains a fork of llvm at [llvm-project](https://github.com/rust-lang/llvm-project/) where it applies patches on top of the llvm project. This mostly seems to be to get unwinding support for the SGX project, and there may be other patches that I'm unaware of.
There is a lot of machinery in the build system to support compiling `libunwind` on other platforms, and I needed to add additional patches to llvm in order to add support for Xous.
Rather than continuing down this path, it seemed much easier to use a Rust-based library. The `unwinding` crate by `@nbdd0121` fits this description perfectly.
### Future work
This could potentially replace the custom patches for `libunwind` on other platforms such as SGX, and could enable unwinding support on many more exotic platforms.
### Anti-goals
This is not designed to replace `libunwind` on tier-one platforms or those where unwinding support already exists. There is already a well-established approach for unwinding there. Instead, this aims to enable unwinding on new platforms where C++ code may be difficult to compile.
The main() function takes an argument that contains the eh_frame
address. Implement `unwinding` support by looking for unwinding data at
this address.
Signed-off-by: Sean Cross <sean@xobs.io>
std: Invert logic for inclusion of `sys_common::net`
The `library/std/src/sys_common/net.rs` module is intended to define common implementations of networking-related APIs across a variety of platforms that share similar APIs (e.g. Berkeley-style sockets and all). This module is not included for more fringe targets however such as UEFI or "unknown" targets to libstd (those classified as `restricted-std`). Previously the `sys_common/net.rs` file was set up such that an allow-list indicated it shouldn't be used. This commit inverts the logic to have an allow-list of when it should be used instead.
The goal of this commit is to make it a bit easier to experiment with a new Rust target. Currently more esoteric targets are required to get an exception in this `cfg_if` block to use `crate::sys::net` such as for unsupported targets. With this inversion of logic only targets which actually support networking will be listed, where most of those are lumped under `cfg(unix)`.
Given that this change is likely to cause some breakage for some target by accident I've attempted to be somewhat robust with this by following these steps to defining the new predicate for inverted logic.
1. Take all supported targets and filter out all `cfg(unix)` ones as these should all support `sys_common/net.rs`.
2. Take remaining targets and filter out `cfg(windows)` ones.
3. The remaining dozen-or-so targets were all audited by hand. Mostly this included `target_os = "hermit"` and `target_os = "solid_asp3"` which required an allow-list entry, but remaining targets were all already excluded (didn't use `sys_common/net.rs` so they were left out.
If this causes breakage it should be relatively easy to fix and I'd be happy to follow-up with any PRs necessary.
move exposed-provenance APIs into separate feature gate
We have already stated explicitly for all the 'exposed' functions that
> Using this method means that code is *not* following strict provenance rules.
However, they were part of the same feature gate and still described as part of the strict provenance experiment. Unfortunately, their semantics are much less clear and certainly nowhere near stabilization, so in preparation for an attempt to stabilize the strict provenance APIs, I suggest we split the things related to "exposed" into their own feature gate. I also used this opportunity to better explain how Exposed Provenance fits into the larger plan here: this is *one possible candidate* for `as` semantics, but we don't know if it is actually viable, so we can't really promise that it is equivalent to `as`. If it works out we probably want to make `as` equivalent to the 'exposed' APIs; if it doesn't, we will remove them again and try to find some other semantics for `as`.
Add substring API for `OsStr`
This adds a method for taking a substring of an `OsStr`, which in combination with [`OsStr::as_encoded_bytes()`](https://doc.rust-lang.org/std/ffi/struct.OsStr.html#method.as_encoded_bytes) makes it possible to implement most string operations in safe code.
API:
```rust
impl OsStr {
pub fn slice_encoded_bytes<R: ops::RangeBounds<usize>>(&self, range: R) -> &Self;
}
```
Motivation, examples and research at https://github.com/rust-lang/libs-team/issues/306.
Tracking issue: #118485
cc `@epage`
r? libs-api
The `library/std/src/sys_common/net.rs` module is intended to define
common implementations of networking-related APIs across a variety of
platforms that share similar APIs (e.g. Berkeley-style sockets and all).
This module is not included for more fringe targets however such as UEFI
or "unknown" targets to libstd (those classified as `restricted-std`).
Previously the `sys_common/net.rs` file was set up such that an
allow-list indicated it shouldn't be used. This commit inverts the logic
to have an allow-list of when it should be used instead.
The goal of this commit is to make it a bit easier to experiment with a
new Rust target. Currently more esoteric targets are required to get an
exception in this `cfg_if` block to use `crate::sys::net` such as for
unsupported targets. With this inversion of logic only targets which
actually support networking will be listed, where most of those are
lumped under `cfg(unix)`.
Given that this change is likely to cause some breakage for some target
by accident I've attempted to be somewhat robust with this by following
these steps to defining the new predicate for inverted logic.
1. Take all supported targets and filter out all `cfg(unix)` ones as
these should all support `sys_common/net.rs`.
2. Take remaining targets and filter out `cfg(windows)` ones.
3. The remaining dozen-or-so targets were all audited by hand. Mostly
this included `target_os = "hermit"` and `target_os = "solid_asp3"`
which required an allow-list entry, but remaining targets were all
already excluded (didn't use `sys_common/net.rs` so they were left
out.
If this causes breakage it should be relatively easy to fix and I'd be
happy to follow-up with any PRs necessary.
Implement thread parking for xous
This follows the pattern set by [the Windows parker](ddef56d5df/library/std/src/sys/windows/thread_parking.rs) when it uses keyed events. An atomic variable is used to track the state and optimize the fast path, while notifications are send via the ticktime server to block and unblock the thread.
ping `@xobs`
`@rustbot` label +T-libs +A-atomic
r? libs
unify read_to_end and io::copy impls for reading into a Vec
This ports over the initial probe (to avoid allocation) and the dynamic read sizing from the io::copy specialization to the `default_read_to_end` implementation which already had its own optimizations for different cases.
I think it should be a best-of-both now.
suggested by `@a1phyr` in https://github.com/rust-lang/rust/pull/117576#issuecomment-1803408492
Use an absolute path to the NUL device
While a bare "NUL" *should* be redirected to the NUL device, especially in this simple case, let's be explicit that we aren't opening a file called "NUL" and instead open it directly.
This will also set a good example for people copying std code.
r? libs
Update windows-bindgen and define `INVALID_HANDLE_VALUE` ourselves
We generate bindings to the Windows API via the `windows-bindgen` crate, which is ultimately what's also used to generate the `windows-sys` and `windows` crates. However, there currently is some custom sauce just for std which makes it a bit different from the vanilla bindings. I would love for us to reduce and eventually remove the differences entirely so that std is using the exact same bindings as everyone else. Maybe in the future we can even just have a normal dependency on `windows-sys`.
This PR removes one of those special things. Our definition of `INVALID_HANDLE_VALUE` relies on an experimental nightly feature for strict provenance, so lets bring that back in house. It also excludes it from the codegen step though that isn't strictly necessary as we override it in any case.
This PR also updates windows-bingen to 0.52.0.
Improve rewind documentation
The persistent use of an internal cursor for readers is expected for buffer data types that aren't read all at once, but for files it leads to the confusing situation where calling `read_to_end` on the same file handle multiple times only returns the contents of the file for the first call. This PR adds a note to the documentation clarifying that in that case, `rewind()` must first be called.
I'm unsure if this is the right location for the docs update. Maybe it should also be duplicated on `File`?
kmc-solid: I/O safety
Adds the I/O safety API (#87329) for socket file descriptors in [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets. All new public items are gated by the `solid_ext` library feature.
This PR adds the following public types and traits:
std::os::solid::io::AsFd
std::os::solid::io::BorrowedFd
std::os::solid::io::OwnedFd
std::os::solid::prelude::AsFd (re-export)
std::os::solid::prelude::BorrowedFd (re-export)
std::os::solid::prelude::OwnedFd (re-export)
And trait implementations:
From<std::net::TcpListener> for std::os::solid::io::OwnedFd
From<std::net::TcpStream> for std::os::solid::io::OwnedFd
From<std::net::UdpSocket> for std::os::solid::io::OwnedFd
From<std::os::solid::io::OwnedFd> for std::net::TcpListener
From<std::os::solid::io::OwnedFd> for std::net::TcpStream
From<std::os::solid::io::OwnedFd> for std::net::UdpSocket
std::fmt::Debug for std::os::solid::io::BorrowedFd<'_>
std::fmt::Debug for std::os::solid::io::OwnedFd
std::io::IsTerminal for std::os::solid::io::BorrowedFd<'_>
std::io::IsTerminal for std::os::solid::io::OwnedFd
std::os::fd::AsRawFd for std::os::solid::io::BorrowedFd<'_>
std::os::fd::AsRawFd for std::os::solid::io::OwnedFd
std::os::fd::FromRawFd for std::os::solid::io::OwnedFd
std::os::fd::IntoRawFd for std::os::solid::io::OwnedFd
std::os::solid::io::AsFd for &impl std::os::solid::io::AsFd
std::os::solid::io::AsFd for &mut impl std::os::solid::io::AsFd
std::os::solid::io::AsFd for Arc<impl std::os::solid::io::AsFd>
std::os::solid::io::AsFd for Box<impl std::os::solid::io::AsFd>
std::os::solid::io::AsFd for Rc<impl std::os::solid::io::AsFd>
std::os::solid::io::AsFd for std::net::TcpListener
std::os::solid::io::AsFd for std::net::TcpStream
std::os::solid::io::AsFd for std::net::UdpSocket
std::os::solid::io::AsFd for std::os::solid::io::BorrowedFd<'_>
std::os::solid::io::AsFd for std::os::solid::io::OwnedFd
Taking advantage of the above change, this PR also refactors the internal details of `std::sys::solid::net` to match the design of other targets, e.g., by redefining `Socket` as a newtype of `OwnedFd`.
This is where our Windows API bindings previously (and incorrectly) used `*mut` instead of `*const` pointers. Now that the bindings have been corrected, the mutable references (which auto-convert to `*mut`) are unnecessary and we can use shared references.
While a bare "NUL" *should* be redirected to the NUL device, especially in this simple case, let's be explicit that we aren't opening a file called "NUL" and instead open it directly.
This will also set a good example for people copying std code.
Adjust frame IP in backtraces relative to image base for SGX target
This is followup to https://github.com/rust-lang/backtrace-rs/pull/566.
The backtraces printed by `panic!` or generated by `std::backtrace::Backtrace` in SGX target are not usable. The frame addresses need to be relative to image base address so they can be used for symbol resolution. Here's an example panic backtrace generated before this change:
```
$ cargo r --target x86_64-fortanix-unknown-sgx
...
stack backtrace:
0: 0x7f8fe401d3a5 - <unknown>
1: 0x7f8fe4034780 - <unknown>
2: 0x7f8fe401c5a3 - <unknown>
3: 0x7f8fe401d1f5 - <unknown>
4: 0x7f8fe401e6f6 - <unknown>
```
Here's the same panic after this change:
```
$ cargo +stage1 r --target x86_64-fortanix-unknown-sgx
stack backtrace:
0: 0x198bf - <unknown>
1: 0x3d181 - <unknown>
2: 0x26164 - <unknown>
3: 0x19705 - <unknown>
4: 0x1ef36 - <unknown>
```
cc `@jethrogb` and `@workingjubilee`
Add Seek::seek_relative
The `BufReader` struct has a `seek_relative` method because its `Seek::seek` implementation involved dumping the internal buffer (https://github.com/rust-lang/rust/issues/31100).
Unfortunately, there isn't really a good way to take advantage of that method in generic code. This PR adds the same method to the main `Seek` trait with the straightforward default method, and an override for `BufReader` that calls its implementation.
_Also discussed in [this](https://internals.rust-lang.org/t/add-seek-seek-relative/19546) internals.rust-lang.org thread._
Add T: ?Sized to `RwLockReadGuard` and `RwLockWriteGuard`'s Debug impls.
For context, `MutexGuard` has `+ ?Sized` on its `Debug` impl, and all three have `+ ?Sized` on their `Display` impls.
It looks like the `?Sized` was just missed when the impls were added (the impl for `MutexGuard` was added in the same PR (https://github.com/rust-lang/rust/pull/38006) with support for `T: Debug + ?Sized`, and `RwLock*Guard`s did allow `T: ?Sized` types already); the `Display` impls were added later (https://github.com/rust-lang/rust/pull/42822) with support for `T: Debug + ?Sized` types.
I think this needs a T-libs-api FCP? I'm not sure if this also needs an ACP. If so I can make one.
These are changes to (stable) trait impls on stable types so will be insta-stable.
`@rustbot` label +T-libs-api
Remove asmjs
Fulfills [MCP 668](https://github.com/rust-lang/compiler-team/issues/668).
`asmjs-unknown-emscripten` does not work as-specified, and lacks essential upstream support for generating asm.js, so it should not exist at all.
Xous as an operating system is compiled with gcc-type personalities when
it comes to unwinding. This enables unwinding inside panics on Xous,
which enables Rust tests.
Signed-off-by: Sean Cross <sean@xobs.io>
Add `std:#️⃣:{DefaultHasher, RandomState}` exports (needs FCP)
This implements rust-lang/libs-team#267 to move the libstd hasher types to `std::hash` where they belong, instead of `std::collections::hash_map`.
<details><summary>The below no longer applies, but is kept for clarity.</summary>
This is a small refactor for #27242, which moves the definitions of `RandomState` and `DefaultHasher` into `std::hash`, but in a way that won't be noticed in the public API.
I've opened rust-lang/libs-team#267 as a formal ACP to move these directly into the root of `std::hash`, but for now, they're at least separated out from the collections code in a way that will make moving that around easier.
I decided to simply copy the rustdoc for `std::hash` from `core::hash` since I think it would be ideal for the two to diverge longer-term, especially if the ACP is accepted. However, I would be willing to factor them out into a common markdown document if that's preferred.
</details>
Removes the private type `std::sys::solid::net::FileDesc`, replacing its
only usage in `std::sys::solid::net::Socket` with `std::os::solid::io::
OwnedFd`.
The initial probe-for-empty-source by stack_buffer_copy only detected EOF
if the source was empty but not when it was merely small which lead to
additional calls to read() after Ok(0) had already been returned
in the stack copy routine
It now keeps track of initialized bytes to avoid reinitialization.
It also keeps track of read sizes to avoid initializing more bytes
than the reader needs. This is important when passing a huge vector to a
Read that only has a few bytes to offer and doesn't implement read_buf().
Time in UNIX system calls counts from the epoch, 1970-01-01. The timespec
struct used in various system calls represents this as a number of seconds and
a number of nanoseconds. Nanoseconds are required to be between 0 and
999_999_999, because the portion outside that range should be represented in
the seconds field; if nanoseconds were larger than 999_999_999, the seconds
field should go up instead.
Suppose you ask for the time 1969-12-31, what time is that? On UNIX systems
that support times before the epoch, that's seconds=-86400, one day before the
epoch. But now, suppose you ask for the time 1969-12-31 23:59:00.1. In other
words, a tenth of a second after one minute before the epoch. On most UNIX
systems, that's represented as seconds=-60, nanoseconds=100_000_000. The macOS
bug is that it returns seconds=-59, nanoseconds=-900_000_000.
While that's in some sense an accurate description of the time (59.9 seconds
before the epoch), that violates the invariant of the timespec data structure:
nanoseconds must be between 0 and 999999999. This causes this assertion in the
Rust standard library.
So, on macOS, if we get a Timespec value with seconds less than or equal to
zero, and nanoseconds between -999_999_999 and -1 (inclusive), we can add
1_000_000_000 to the nanoseconds and subtract 1 from the seconds, and then
convert. The resulting timespec value is still accepted by macOS, and when fed
back into the OS, produces the same results. (If you set a file's mtime with
that timestamp, then read it back, you get back the one with negative
nanoseconds again.)
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
Increase the reach of panic_immediate_abort
I wanted to use/abuse this recently as part of another project, and I was surprised how many panic-related things were left in my binaries if I built a large crate with the feature enabled along with LTO. These changes get all the panic-related symbols that I could find out of my set of locally installed Rust utilities.
Create `windows/api.rs` for safer FFI
FFI is inherently unsafe. For memory safety we need to assert that some contract is being upheld on both sides of the FFI, though of course we can only ever check our side. In Rust, `unsafe` blocks are used to assert safety and `// SAFETY` comments describing why it is safe. Currently in sys/windows we have a lot of this unsafety spread all over the place, with variations on the same unsafe patterns repeated. And because of the repitition and frequency, we're a bit lax with the safety comments.
This PR aims to fix this and to make FFI safety more auditable by creating an `api` module with the goal of centralising and consolidating this unsafety. It contains thin wrappers around the Windows API that make most functions safe to call or, if that's not possible, then at least safer. Note that its goal is *only* to address safety. It does not stray far from the Windows API and intentionally does not attempt to make higher lever wrappers around, for example, file handles. This is better left to the existing modules. The windows/api.rs file has a top level comment to help future contributors understand the intent of the module and the design decisions made.
I chose two functions as a first tentative step towards the above goal:
- [`GetLastError`](https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-getlasterror) is trivially safe. There's no reason to wrap it in an `unsafe` block every time. So I simply created a safe `get_last_error` wrapper.
- [`SetFileInformationByHandle`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfileinformationbyhandle) is more complex. It essentially takes a generic type but over a C API which necessitates some amount of ceremony. Rather than implementing similar unsafe patterns in multiple places, I provide a safe `set_file_information_by_handle` that takes a Rusty generic type and handles converting that to the form required by the C FFI.
r? libs
Hide internal methods from documentation
The two methods here are perma-unstable and only made public for technical reasons. There is no reason to show them in documentation.
`@rustbot` label +A-docs
Rollup of 6 pull requests
Successful merges:
- #114998 (feat(docs): add cargo-pgo to PGO documentation 📝)
- #116868 (Tweak suggestion span for outer attr and point at item following invalid inner attr)
- #117240 (Fix documentation typo in std::iter::Iterator::collect_into)
- #117241 (Stash and cancel cycle errors for auto trait leakage in opaques)
- #117262 (Create a new ConstantKind variant (ZeroSized) for StableMIR)
- #117266 (replace transmute by raw pointer cast)
r? `@ghost`
`@rustbot` modify labels: rollup
These methods are the pre-stabilized API for obtaining peer credentials
from an `AF_UNIX` socket, part of the `unix_socket_ancillary_data` feature.
Their current behavior is to get/set one of the `SO_PASSCRED` (Linux),
`LOCAL_CREDS_PERSISTENT` (FreeBSD), or `LOCAL_CREDS` (NetBSD) socket
options. On other targets the `{set_}passcred()` methods do not exist.
There are two problems with this approach:
1. Having public methods only exist for certain targets isn't permitted
in a stable `std` API.
2. These options have generally similar purposes, but they are non-POSIX
and their details can differ in subtle and surprising ways (such as
whether they continue to be set after the next call to `recvmsg()`).
Splitting into OS-specific extension traits is the preferred solution to
both problems.
Validate `feature` and `since` values inside `#[stable(…)]`
Previously the string passed to `#[unstable(feature = "...")]` would be validated as an identifier, but not `#[stable(feature = "...")]`. In the standard library there were `stable` attributes containing the empty string, and kebab-case string, neither of which should be allowed.
Pre-existing validation of `unstable`:
```rust
// src/lib.rs
#![allow(internal_features)]
#![feature(staged_api)]
#![unstable(feature = "kebab-case", issue = "none")]
#[unstable(feature = "kebab-case", issue = "none")]
pub struct Struct;
```
```console
error[E0546]: 'feature' is not an identifier
--> src/lib.rs:5:1
|
5 | #![unstable(feature = "kebab-case", issue = "none")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
For an `unstable` attribute, the need for an identifier is obvious because the downstream code needs to write a `#![feature(...)]` attribute containing that identifier. `#![feature(kebab-case)]` is not valid syntax and `#![feature(kebab_case)]` would not work if that is not the name of the feature.
Having a valid identifier even in `stable` is less essential but still useful because it allows for informative diagnostic about the stabilization of a feature. Compare:
```rust
// src/lib.rs
#![allow(internal_features)]
#![feature(staged_api)]
#![stable(feature = "kebab-case", since = "1.0.0")]
#[stable(feature = "kebab-case", since = "1.0.0")]
pub struct Struct;
```
```rust
// src/main.rs
#![feature(kebab_case)]
use repro::Struct;
fn main() {}
```
```console
error[E0635]: unknown feature `kebab_case`
--> src/main.rs:3:12
|
3 | #![feature(kebab_case)]
| ^^^^^^^^^^
```
vs the situation if we correctly use `feature = "snake_case"` and `#![feature(snake_case)]`, as enforced by this PR:
```console
warning: the feature `snake_case` has been stable since 1.0.0 and no longer requires an attribute to enable
--> src/main.rs:3:12
|
3 | #![feature(snake_case)]
| ^^^^^^^^^^
|
= note: `#[warn(stable_features)]` on by default
```
Windows: Support sub-millisecond sleep
Use `CreateWaitableTimerExW` with `CREATE_WAITABLE_TIMER_HIGH_RESOLUTION`. Does not work before Windows 10, version 1803 so in that case we fallback to using `Sleep`.
I've created a `WaitableTimer` type so it can one day be adapted to also support waiting to an absolute time (which has been talked about). Note though that it currently returns `Err(())` because we can't do anything with the errors other than fallback to the old `Sleep`. Feel free to tell me to do errors properly. It just didn't seem worth constructing an `io::Error` if we're never going to surface it to the user. And it *should* all be infallible anyway unless the OS is too old to support it.
Closes#43376
Remove Apple RNG fallbacks and simplify implementation
Now that we have [higher Apple platform requirements](https://github.com/rust-lang/rust/pull/104385), the RNG code can be simplified a lot. Since `getentropy` still doesn't look to be usable outside macOS this implementation:
- Removes any macOS fallback paths and unconditionally links to `getentropy`
- Minimizes the implementation for everything else (iOS, watchOS, etc).
`CCRandomGenerateBytes` was added in iOS 8 which means that we can use it now. It and `SecRandomCopyBytes` have the exact same functionality, but the former has a simpler API and no longer requires libstd to link to `Security.framework` for one function. Its also available in all the other target's SDKs.
Why care about `getentropy` then though on macOS? Well, its still much more performant. Benchmarking shows it runs at ~2x the speed of `CCRandomGenerateBytes`, which makes sense since it directly pulls from the kernel vs going through its own generator etc.
Semi-related to a previous, but reverted, attempt at improving this logic in https://github.com/rust-lang/rust/pull/101011
time: use clock_gettime on macos
Replace `gettimeofday` with `clock_gettime(CLOCK_REALTIME)` on:
```
all(target_os = "macos", not(target_arch = "aarch64")),
target_os = "ios",
target_os = "watchos",
target_os = "tvos"
))]
```
`gettimeofday` was first used in
cc367edd95
which predated the introduction of `clock_gettime` support in macOS
10.12 Sierra which became the minimum supported version in
58bbca958d.
Replace `mach_{absolute_time,timebase_info}` with
`clock_gettime(CLOCK_REALTIME)` on:
```
all(target_os = "macos", not(target_arch = "aarch64")),
target_os = "ios",
target_os = "watchos",
target_os = "tvos"
))]
```
`mach_{absolute_time,timebase_info}` were first used in
cc367edd95
which predated the introduction of `clock_gettime` support in macOS
10.12 Sierra which became the minimum supported version in
58bbca958d.
Note that this change was made for aarch64 in
5008a317ce which predated 10.12 becoming
the minimum supported version. The discussion took place in
https://github.com/rust-lang/rust/issues/91417 and in particular
https://github.com/rust-lang/rust/issues/91417#issuecomment-992151582
and
https://github.com/rust-lang/rust/issues/91417#issuecomment-1033048064
are relevant.
Rollup of 6 pull requests
Successful merges:
- #107159 (rand use getrandom for freebsd (available since 12.x))
- #116859 (Make `ty::print::Printer` take `&mut self` instead of `self`)
- #117046 (return unfixed len if pat has reported error)
- #117070 (rustdoc: wrap Type with Box instead of Generics)
- #117074 (Remove smir from triage and add me to stablemir)
- #117086 (Update .mailmap to promote my livename)
r? `@ghost`
`@rustbot` modify labels: rollup
report `unused_import` for empty reexports even it is pub
Fixes#116032
An easy fix. r? `@petrochenkov`
(Discovered this issue while reviewing #115993.)
On Windows make `read_dir` error on the empty path
This makes Windows consistent with other platforms. Note that this should not be taken to imply any decision on #114149 has been taken. However it was felt that while there is a lack of libs-api consensus, we should be consistent across platforms in the meantime.
This is a change in behaviour for Windows so will also need an fcp before merging.
r? libs-api
Specialize `Bytes<R>::next` when `R` is a `BufReader`.
This reduces the runtime for a simple program using `Bytes::next` to iterate through a file from 220ms to 70ms on my Linux box.
r? `@the8472`
Make TCP connect handle EINTR correctly
According to the [POSIX](https://pubs.opengroup.org/onlinepubs/009695399/functions/connect.html) standard, if connect() is interrupted by a signal that is caught while blocked waiting to establish a connection, connect() shall fail and set errno to EINTR, but the connection request shall not be aborted, and the connection shall be established asynchronously. When the connection has been established asynchronously, select() and poll() shall indicate that the file descriptor for the socket is ready for writing.
The previous implementation differs from the recomendation: in a case of the EINTR we tried to reconnect in a loop and sometimes get EISCONN error (this problem was originally detected on MacOS).
1. More details about the problem in an [article](http://www.madore.org/~david/computers/connect-intr.html).
2. The original [issue](https://git.picodata.io/picodata/picodata/tarantool-module/-/issues/157).
Panic when the global allocator tries to register a TLS destructor
Using a `RefCell` avoids the undefined behaviour encountered in #116390 and reduces the amount of `unsafe` code in the codebase.
The bug report #27970 has existed for 8 years, the actual bug dates back
to Rust pre-1.0. I documented it since it's in the interest of the user
to be aware of it. The note can be removed once #27970 is fixed.
Updated libc and doc for Vita target
Doc changes:
- Updated Vita target readme. The recommended approach to build artifacts for the platform now is [cargo-vita](https://crates.io/crates/cargo-vita) which wraps all the convoluted steps previously described in a yaml for `cargo-make`
- Updated maintainer list for Vita target. (`@ZetaNumbers` `@pheki` please agree to be added to the list, `@amg98` please let us know if you're still planning on actively maintaining target support)
Code changes:
- ~Updated libc for rust-lang/libc#3284 and rust-lang/libc#3366~ (Already merged in #116527)
- In dupfd changed the flag same as for esp target, there is no CLOEXEC on Vita
- Enabled `new_pair` since we've implemented `socketpair` in Vita newlib
Inline `Bytes::next` and `Bytes::size_hint`.
This greatly increases its speed. On one small test program using `Bytes::next` to iterate over a large file, execution time dropped from ~330ms to ~220ms.
r? `@the8472`
impl Default for ExitCode
As suggested here
https://github.com/rust-lang/rust/pull/106425#issuecomment-1382952598
Needs FCP since this is an insta-stable impl.
Ideally we would have `impl From<ExitCode> for ExitStatus` and implement the default `ExitStatus` using that. That is sadly not so easy because of the various strange confusions about `ExitCode` (unix: exit status) vs `ExitStatus` (unix: wait status) in the not-really-unix platforms in `library//src/sys/unix/process`. I'll try to follow that up.
Implement sys::args for UEFI
- Uses `EFI_LOADED_IMAGE_PROTOCOL`, which is implemented for all loaded images.
Tested on qemu with OVMF
cc ``@nicholasbishop``
cc ``@dvdhrm``
Broaden the consequences of recursive TLS initialization
This PR updates the documentation of `LocalKey` to clearly disallow the behaviour described in [this comment](https://github.com/rust-lang/rust/issues/110897#issuecomment-1525738849). This allows using `OnceCell` for the lazy initialization of TLS variables, which panics on reentrant initialization instead of updating the value like TLS variables currently do.
``@rustbot`` label +T-libs-api
r? ``@m-ou-se``
error[E0711]: feature `process-exitcode-default` is declared stable since 1.74.0-beta.1, but was previously declared stable since 1.73.0
--> library/std/src/process.rs:1964:1
|
1964 | #[stable(feature = "process-exitcode-default", since = "CURRENT_RUSTC_VERSION")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Previously it failed on Windows if the file had the `FILE_ATTRIBUTE_HIDDEN` attribute set. This was inconsistent with `OpenOptions::new().write(true).truncate(true)` which can truncate an existing hidden file.
Make `try_exists` return `Ok(true)` for Windows Unix Sockets
This is a follow up to #109106 but for[ `fs::try_exists`](https://doc.rust-lang.org/std/fs/fn.try_exists.html), which doesn't need to get the metadata of a file (which can fail even if a file exists).
`fs::try_exists` currently fails on Windows if encountering a Unix Domain Socket (UDS). This PR fixes it by checking for an error code that's returned when there's a failure to use a reparse point.
## Reparse points
A reparse point is a way to invoke a filesystem filter on a file instead of the file being opened normally. This is used to implement symbolic links (by redirecting to a different path) but also to implement other types of special files such as Unix domain sockets. If the reparse point is not a link type then opening it with `CreateFileW` may fail with `ERROR_CANT_ACCESS_FILE` because the filesystem filter does not implement that operation. This differs from resolving links which may fail with errors such as `ERROR_FILE_NOT_FOUND` or `ERROR_CANT_RESOLVE_FILENAME`.
So `ERROR_CANT_ACCESS_FILE` means that the file exists but that we can't open it normally. Still, the file does exist on the filesystem so `try_exists` should report that as `Ok(true)`.
r? libs
Fix exit status / wait status on non-Unix cfg(unix) platforms
Fixes#114593
Needs FCP due to behavioural changes (NB only on non-Unix `#[cfg(unix)]` platforms).
Also, I think this is likely to break in CI. I have not been yet able to compile the new bits of `process_unsupported.rs`, although I have compiled the new module. I'd like some help from people familiar with eg emscripten and fuchsia (which are going to be affected, I think).
According to the POSIX standard, if connect() is interrupted by a
signal that is caught while blocked waiting to establish a connection,
connect() shall fail and set errno to EINTR, but the connection
request shall not be aborted, and the connection shall be established
asynchronously.
If asynchronous connection was successfully established after EINTR
and before the next connection attempt, OS returns EISCONN that was
handled as an error before. This behavior is fixed now and we handle
it as success.
The problem affects MacOS users: Linux doesn't return EISCONN in this
case, Windows connect() can not be interrupted without an old-fashoin
WSACancelBlockingCall function that is not used in the library.
So current solution gives connect() as OS specific implementation.
`fs::try_exists` currently fails on Windows if encountering a Unix Domain Socket (UDS). Fix this by checking for an error code that's returned when there's a failure to use a reparse point.
A reparse point is a way to invoke a filesystem filter on a file instead of the file being opened normally. This is used to implement symbolic links (by redirecting to a different path) but also to implement other types of special files such as Unix domain sockets. If the reparse point is not a link type then opening it with `CreateFileW` may fail with `ERROR_CANT_ACCESS_FILE` because the filesystem filter does not implement that operation. This differs from resolving links which may fail with errors such as `ERROR_FILE_NOT_FOUND` or `ERROR_CANT_RESOLVE_FILENAME`.
So `ERROR_CANT_ACCESS_FILE` means that the file exists but that we can't open it normally. Still, the file does exist so `try_exists` should report that as `Ok(true)`.
Remove unnecessary tmp variable in default_read_exact
This `tmp` variable has existed since the original implementation (added in ff81920f03), but it's not necessary (maybe non-lexical lifetimes helped?).
It's common to read std source code to understand how things actually work, and this tripped me up on my first read.
* Entries in the callsite table now use a dedicated function for reading an offset rather than a pointer
* `read_encoded_pointer` uses that new function for reading offsets when the "application" part of the encoding indicates an offset (relative to some pointer)
* It now errors out on nonsensical "application" and "value encoding" combinations
Inspired by @eddyb's comment on zulip about this:
<https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/strict.20provenance.20in.20dwarf.3A.3Aeh/near/276197290>
Rollup of 4 pull requests
Successful merges:
- #116277 (dont call mir.post_mono_checks in codegen)
- #116400 (Detect missing `=>` after match guard during parsing)
- #116458 (Properly export function defined in test which uses global_asm!())
- #116500 (Add tvOS to target_os for register_dtor)
r? `@ghost`
`@rustbot` modify labels: rollup
Rollup of 6 pull requests
Successful merges:
- #115454 (Clarify example in docs of str::char_slice)
- #115522 (Clarify ManuallyDrop bit validity)
- #115588 (Fix a comment in std::iter::successors)
- #116198 (Add more diagnostic items for clippy)
- #116329 (update some comments around swap())
- #116475 (rustdoc-search: fix bug with multi-item impl trait)
r? `@ghost`
`@rustbot` modify labels: rollup
`waitqueue` clarifications for SGX platform
The documentation of `waitqueue` functions on the `x86_64-fortanix-unknown-sgx` platform is incorrect at some places and on others missing. This PR improves upon this.
cc: `@jethrogb`
Use `CreateWaitableTimerExW` with `CREATE_WAITABLE_TIMER_HIGH_RESOLUTION`. Does not work before Windows 10, version 1803 so in that case we fallback to using `Sleep`.
Works around #115199 by temporarily disabling CFI for core and std CFI
violations to allow the user rebuild and use both core and std with CFI
enabled using the Cargo build-std feature.
Replace 'mutex' with 'lock' in RwLock documentation
When copying the documentation for `clear_poison` from Mutex, not every occurence of 'mutex' was replaced with 'lock'.
Improve UdpSocket documentation
I tried working with `UdpSocket` and ran into `EINVAL` errors with no clear indication of what causes the error. Also, it was uncharacteristically hard to figure this module out, compared to other Rust `std` modules.
1. `send` and `send_to` return a `usize` This one is just clarity. Usually, returned `usize`s indicate that the buffer might have only been sent partially. This is not the case with UDP. Since that `usize` must always be `buffer.len()`, I have documented that.
2. `bind` limits `connect` and `send_to` When you bind to a limited address space like localhost, you can only `connect` to addresses in that same address space. Error kind: `AddrNotAvailable`.
3. `connect`ing to localhost locks you to localhost On Linux, if you first `connect` to localhost, subsequent `connect`s to
non-localhost addresses fail. Error kind: `InvalidInput`.
For debugging the third one, it was really hard to find someone else who already had that problem. I only managed to find this thread: https://www.mail-archive.com/netdev@vger.kernel.org/msg159519.html
Add missing #[inline] on AsFd impl for sys::unix::fs::File
This operation should be extremely cheap, at most the `mov` of the underlying file descriptor, but due to this missing `#[inline]` it is currently a function call.
Stdio support for UEFI
- Uses Simple Text Output Protocol and Simple Text Input Protocol
- Reading is done one character at a time
- Writing is done with max 4096 characters
# Quirks
## Output Newline
- UEFI uses CRLF for newline. So when running the application in UEFI shell (qemu VGA), the output of `println` looks weird.
- However, since the UEFI shell supports piping output, I am unsure if doing any output post-processing is a good idea. UEFI shell `cat` command seems to work fine with just LF.
## Input Newline
- `Stdin.read_line()` method is broken in UEFI shell. Pressing enter seems to be read as CR, which means LF is never encountered.
- Works fine with input redirection from file.
CC `@dvdhrm`
- Uses Simple Text Output Protocol and Simple Text Input Protocol
- Reading is done one character at a time
- Writing is done with max 4096 characters
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
Document that Instant may or may not include system-suspend time
Since people are still occasionally surprised by this let's make it more explicit. This doesn't add any new guarantees, only documents the status quo.
Related issues: #87906#79462
This operation should be extremely cheap, at most the mov of the underlying
file descriptor, but due to this missing #[inline] it is currently a function
call.
Replace `gettimeofday` with `clock_gettime(CLOCK_REALTIME)` on:
```
all(target_os = "macos", not(target_arch = "aarch64")),
target_os = "ios",
target_os = "watchos",
target_os = "tvos"
))]
```
`gettimeofday` was first used in
cc367edd95
which predated the introduction of `clock_gettime` support in macOS
10.12 Sierra which became the minimum supported version in
58bbca958d.
Update windows ffi bindings
Bump `windows-bindgen` to version 0.51.1. This brings with it some changes to the generated FFI bindings, but little that affects the code.
One change that does have more of an impact is `SOCKET` being `usize` instead of either `u64` or `u32` (as is used in std's public `SOCKET` type). However, it's now easy enough to abstract over that difference.
Finally I added a few new bindings that are likely to be used in pending PRs, mostly to make sure they're ok with the new metadata.
r? libs
Convert `Into<ExitStatus> for ExitStatusError` to `From<ExitStatusError> for ExitStatus` in `std::process`
Implementing suggestion from https://github.com/rust-lang/rust/issues/84908#issuecomment-912352902:
> I believe the impl on ExitStatusError should be
>
> ```rust
> impl From<ExitStatusError> for ExitStatus
> ```
>
> rather than
>
> ```rust
> impl Into<ExitStatus> for ExitStatusError
> ```
>
> (there is generally never anything implemented as `Into` first, because implementing `From` reflexively provides `Into`)
Implement From<OwnedFd/Handle> for ChildStdin/out/err object
## Summary
Comments in `library/std/src/process.rs` ( ab08639e59 ) indicates that `ChildStdin`, `ChildStdout`, `ChildStderr` implements some traits that are not actually implemented: `FromRawFd`, `FromRawHandle`, and the `From<OwnedFd>/From<OwnedHandle>` from the io_safety feature.
In this PR I implement `FromRawHandle` and `FromRawFd` for those 3 objects.
## Usecase
I have a usecase where those implementations are basically needed. I want to customize
in the `Command::spawn` API how the pipes for the parent/child communications are created (mainly to strengthen the security attributes on them). I can properly setup the pipes,
and the "child" handles can be provided to `Child::spawn` easily using `Stdio::from_raw_handle`. However, there is no way to generate the `ChildStd*` objects from the raw handle of the created name pipe, which would be very useful to still expose the same API
than in other OS (basically a `spawn(...) -> (Child, ChildStdin, ChildStdout, ChildSterr)`, where on windows this is customized), and to for example use `tokio::ChildStdin::from_std` afterwards.
## Questions
* Are those impls OK to add? I have searched to see if those impls were missing on purpose, or if it was just never implemented because never needed. I haven't found any indication on why they couldn't be added, although the user clearly has to be very careful that the handle provided makes sense (i think, mainly that it is in overlapped mode for windows).
* If this change is ok, adding the impls for the io_safety feature would probably be best, or should it be done in another PR?
* I just copy-pasted the `#[stable(...)]` attributes, but the `since` value has to be updated, I'm not sure to which value.
fix OS-specific I/O safety docs since the io_safety feature is stable
Looks like this text was forgotten to be updated when `io_safety` got stabilized: it still says "once the io_safety feature is stable".
Also adjust the wording a bit for how these docs relate to the general concept of I/O safety.
Add Minimal Std implementation for UEFI
# Implemented modules:
1. alloc
2. os_str
3. env
4. math
# Related Links
Tracking Issue: https://github.com/rust-lang/rust/issues/100499
API Change Proposal: https://github.com/rust-lang/libs-team/issues/87
# Additional Information
This was originally part of https://github.com/rust-lang/rust/pull/100316. Since that PR was becoming too unwieldy and cluttered, and with suggestion from `@dvdhrm,` I have extracted a minimal std implementation to this PR.
The example in `src/doc/rustc/src/platform-support/unknown-uefi.md` has been tested for `x86_64-unknown-uefi` and `i686-unknown-uefi` in OVMF. It would be great if someone more familiar with AARCH64 can help with testing for that target.
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
Add the `cfg_match!` macro
# Movitation
Adds a match-like version of the `cfg_if` crate without a RFC [for the same reasons that caused `matches!` to be included in the standard library](https://github.com/rust-lang/rust/pull/65479).
* General-purpose (not domain-specific)
* Simple (the implementation is short) and useful (things can become difficult with several `cfg`s)
* Very popular [on crates.io ](https://crates.io/crates/cfg-if) (currently 3th in all-time downloads)
* The two previous points combined make it number three in [left-pad index](https://twitter.com/bascule/status/1184523027888988160) score
```rust
match_cfg! {
cfg(unix) => {
fn foo() { /* unix specific functionality */ }
}
cfg(target_pointer_width = "32") => {
fn foo() { /* non-unix, 32-bit functionality */ }
}
_ => {
fn foo() { /* fallback implementation */ }
}
}
```
# Considerations
A match-like syntax feels more natural in the sense that each macro fragment resembles an arm but I personally don't mind switching to any other desired syntax.
The lack of `#[ ... ]` is intended to reduce typing, nevertheless, the same reasoning described above can also be applied to this aspect.
Since blocks are intended to only contain items, anything but `cfg` is not expected to be supported at the current or future time.
~~Credits goes to `@gnzlbg` because most of the code was shamelessly copied from https://github.com/gnzlbg/match_cfg.~~
Credits goes to `@alexcrichton` because most of the code was shamelessly copied from https://github.com/rust-lang/cfg-if.
Raise minimum supported Apple OS versions
This implements the proposal to raise the minimum supported Apple OS versions as laid out in the now-completed MCP (https://github.com/rust-lang/compiler-team/issues/556).
As of this PR, rustc and the stdlib now support these versions as the baseline:
- macOS: 10.12 Sierra
- iOS: 10
- tvOS: 10
- watchOS: 5 (Unchanged)
In addition to everything this breaks indirectly, these changes also erase the `armv7-apple-ios` target (currently tier 3) because the oldest supported iOS device now uses ARMv7s. Not sure what the policy around tier3 target removal is but shimming it is not an option due to the linker refusing.
[Per comment](https://github.com/rust-lang/compiler-team/issues/556#issuecomment-1297175073), this requires a FCP to merge. cc `@wesleywiser.`
- Some comment fixes.
- Make some functions unsafe.
- Make helpers module private.
- Rebase on master
- Update r-efi to v4.2.0
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
- Make BootServices unavailable if ExitBootServices event is signaled.
- Use thread locals for SystemTable and ImageHandle
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
Command: also print removed env vars
There is no real shell syntax for unsetting an env var so easily, so we have to make one up. But we already do that for showing the 'program' name so I hope that's okay here, too. No strong opinion on what that should look like, I went with `unset(VAR_NAME)` for now.
Rename BoxMeUp to PanicPayload.
"BoxMeUp" is not very clear. Let's rename that to a description of what it actually represents: a panic payload.
This PR also renames the structs that implement this trait to have more descriptive names.
Part of https://github.com/rust-lang/rust/issues/116005
r? `@oli-obk`
Simplify/Optimize FileEncoder
FileEncoder is basically a BufWriter except that it exposes access to the not-written-to-yet region of the buffer so that some users can write directly to the buffer. This strategy is awesome because it lets us avoid calling memcpy for small copies, but the previous strategy was based on the writer accessing a `&mut [MaybeUninit<u8>; N]` and returning a `&[u8]` which is an API which currently mandates the use of unsafe code, making that interface in general not that appealing.
So this PR cleans up the FileEncoder implementation and builds on that general idea of direct buffer access in order to prevent `memcpy` calls in a few key places when encoding the dep graph and rmeta tables. The interface used here is now 100% safe, but with the caveat that internally we need to avoid trusting the number of bytes that the provided function claims to have written.
The original primary objective of this PR was to clean up the FileEncoder implementation so that the fix for the following issues would be easy to implement. The fix for these issues is to correctly update self.buffered even when writes fail, which I think it's easy to verify manually is now done, because all the FileEncoder methods are small.
Fixes https://github.com/rust-lang/rust/issues/115298
Fixes https://github.com/rust-lang/rust/issues/114671
Fixes https://github.com/rust-lang/rust/issues/114045
Fixes https://github.com/rust-lang/rust/issues/108100
Fixes https://github.com/rust-lang/rust/issues/106787
Refactor `thread_info` to remove the `RefCell`
`thread_info` currently uses `RefCell`-based initialization. Refactor this to use `OnceCell` instead which is more performant and better suits the needs of one-time initialization.
This is nobody's bottleneck but OnceCell checks are a single `cmp` vs. `RefCell<Option>` needing runtime logic
Don't modify libstd to dump rustc ICEs
Do a much simpler thing and just dump a `std::backtrace::Backtrace` to file.
r? `@estebank` `@oli-obk`
Fixes#115610
