* ensuring that offset_of!(Self, ...) works iff inside an impl block
* ensuring that the output type is usize and doesn't coerce. this can be
changed in the future, but if it is done, it should be a conscious descision
* improving the privacy checking test
* ensuring that generics don't let you escape the unsized check
add examples of port 0 binding behavior
Was trying to find the method to specify the IP address but not the port, and there wasn't information easily accessible about it in the `TcpListener` or `SocketAddr`. Adding examples to `TcpListener` and `UdpSocket` for clarity.
Specialize ToString implementation for fmt::Arguments
Generates far fewer instructions by formatting into a String with `fmt::format` directly instead of going through the `fmt::Display` impl. This change is insta-stable.
Add a conversion from `&mut T` to `&mut UnsafeCell<T>`
Provides a safe way of downgrading an exclusive reference into an alias-able `&UnsafeCell<T>` reference.
ACP: https://github.com/rust-lang/libs-team/issues/198.
Change Vec examples to not assert exact capacity except where it is guaranteed
It was [brought up on discord](https://discord.com/channels/273534239310479360/818964227783262209/1107633959329878077) that the `Vec::into_boxed_slice` example contradicted the `Vec::with_capacity` docs in that the returned `Vec` might have _more_ capacity than requested.
So, to reduce confusion change all the `assert_eq!(vec.capacity(), _)` to `assert!(vec.capacity() >= _)`, except in 4 examples that have guaranteed capacities: `Vec::from_raw_parts`, `Vec::from_raw_parts_in`, `Vec::<()>::with_capacity`,`Vec::<(), _>::with_capacity_in`.
The recent LLVM 16 update changes code-gen to be not branchless anymore, in the
slice::sort implementation merge function. This improves performance by 30% for
random patterns, restoring the performance to the state with LLVM 15.
Don't claim `LocalKey::with` prevents a reference to be sent across threads
The documentation for `LocalKey` claims that `with` yields a reference that cannot be sent across threads, but this is false since you can easily do that with scoped threads. What it actually prevents is the reference from outliving the current thread.
(docs) Change "wanting" to "want"
Changing " If you’re wanting" to "If you want".
Wanting is not wrong, of course, but I think that "If you want" feels more natural to most readers.
Fix some misleading and copy-pasted `Pattern` examples
These examples were listed twice and also were confusable with doing a substring match instead of a any-of-set match.
Update doc for `PhantomData` to match code example
After https://github.com/rust-lang/rust/pull/106621, there is no longer a `T: 'a` annotation in the doc example, so update the text to match the code.
Stabilize const slice::split_at
This stabilizes the use of the following method in const context:
```rust
impl<T> [T] {
pub const fn split_at(&self, mid: usize) -> (&[T], &[T]);
}
```
cc tracking issue #101158
Implement `AsHandle`/`AsSocket` for `Arc`/`Rc`/`Box` on Windows
Implement the Windows counterpart to #97437 and #107317: Implement `AsHandle` and `AsSocket` for `Arc<T>`, `Rc<T>`, and `Box<T>`.
Add midpoint function for all integers and floating numbers
This pull-request adds the `midpoint` function to `{u,i}{8,16,32,64,128,size}`, `NonZeroU{8,16,32,64,size}` and `f{32,64}`.
This new function is analog to the [C++ midpoint](https://en.cppreference.com/w/cpp/numeric/midpoint) function, and basically compute `(a + b) / 2` with a rounding towards ~~`a`~~ negative infinity in the case of integers. Or simply said: `midpoint(a, b)` is `(a + b) >> 1` as if it were performed in a sufficiently-large signed integral type.
Note that unlike the C++ function this pull-request does not implement this function on pointers (`*const T` or `*mut T`). This could be implemented in a future pull-request if desire.
### Implementation
For `f32` and `f64` the implementation in based on the `libcxx` [one](18ab892ff7/libcxx/include/__numeric/midpoint.h (L65-L77)). I originally tried many different approach but all of them failed or lead me with a poor version of the `libcxx`. Note that `libstdc++` has a very similar one; Microsoft STL implementation is also basically the same as `libcxx`. It unfortunately doesn't seems like a better way exist.
For unsigned integers I created the macro `midpoint_impl!`, this macro has two branches:
- The first one take `$SelfT` and is used when there is no unsigned integer with at least the double of bits. The code simply use this formula `a + (b - a) / 2` with the arguments in the correct order and signs to have the good rounding.
- The second branch is used when a `$WideT` (at least double of bits as `$SelfT`) is provided, using a wider number means that no overflow can occur, this greatly improve the codegen (no branch and less instructions).
For signed integers the code basically forwards the signed numbers to the unsigned version of midpoint by mapping the signed numbers to their unsigned numbers (`ex: i8 [-128; 127] to [0; 255]`) and vice versa.
I originally created a version that worked directly on the signed numbers but the code was "ugly" and not understandable. Despite this mapping "overhead" the codegen is better than my most optimized version on signed integers.
~~Note that in the case of unsigned numbers I tried to be smart and used `#[cfg(target_pointer_width = "64")]` to determine if using the wide version was better or not by looking at the assembly on godbolt. This was applied to `u32`, `u64` and `usize` and doesn't change the behavior only the assembly code generated.~~
This means that `EscapeIterInner::as_str` no longer needs unsafe code, because the type system ensures the internal buffer is only ASCII, and thus valid UTF-8.
PhantomData: fix documentation wrt interaction with dropck
As far as I could find out, the `PhantomData`-dropck interaction *only* affects code using `may_dangle`. The documentation in the standard library has not been updated for 8 years and thus stems from a time when Rust still used "parametric dropck", before [RFC 1238](https://rust-lang.github.io/rfcs/1238-nonparametric-dropck.html). Back then what the docs said was correct, but with `may_dangle` dropck it stopped being entirely accurate and these days, with NLL, it is actively misleading.
Fixes https://github.com/rust-lang/rust/issues/102810
Fixes https://github.com/rust-lang/rust/issues/70841
Cc `@nikomatsakis` I hope what I am saying here is right.^^
Uplift `clippy::{drop,forget}_{ref,copy}` lints
This PR aims at uplifting the `clippy::drop_ref`, `clippy::drop_copy`, `clippy::forget_ref` and `clippy::forget_copy` lints.
Those lints are/were declared in the correctness category of clippy because they lint on useless and most probably is not what the developer wanted.
## `drop_ref` and `forget_ref`
The `drop_ref` and `forget_ref` lint checks for calls to `std::mem::drop` or `std::mem::forget` with a reference instead of an owned value.
### Example
```rust
let mut lock_guard = mutex.lock();
std::mem::drop(&lock_guard) // Should have been drop(lock_guard), mutex
// still locked
operation_that_requires_mutex_to_be_unlocked();
```
### Explanation
Calling `drop` or `forget` on a reference will only drop the reference itself, which is a no-op. It will not call the `drop` or `forget` method on the underlying referenced value, which is likely what was intended.
## `drop_copy` and `forget_copy`
The `drop_copy` and `forget_copy` lint checks for calls to `std::mem::forget` or `std::mem::drop` with a value that derives the Copy trait.
### Example
```rust
let x: i32 = 42; // i32 implements Copy
std::mem::forget(x) // A copy of x is passed to the function, leaving the
// original unaffected
```
### Explanation
Calling `std::mem::forget` [does nothing for types that implement Copy](https://doc.rust-lang.org/std/mem/fn.drop.html) since the value will be copied and moved into the function on invocation.
-----
Followed the instructions for uplift a clippy describe here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
cc `@m-ou-se` (as T-libs-api leader because the uplifting was discussed in a recent meeting)
Simplify the implementation of iterators over slices of ZSTs
Currently, slice iterators over ZSTs store `end = start.wrapping_byte_add(len)`.
That's slightly convenient for `is_empty`, but kinda annoying for pretty much everything else -- see bugs like #42789, for example.
This PR instead changes it to just `end = ptr::invalid(len)` instead.
That's easier to think about (IMHO, at least) as well as easier to represent.
`next` is still to big to get inlined into the mir-opt/pre-codegen/ tests, but if I bump the inline threshold to force it to show the whole thing, this implementation is also less MIR:
```
> git diff --numstat
241 370 tests/mir-opt/pre-codegen/slice_iter.forward_loop.PreCodegen.after.mir
255 329 tests/mir-opt/pre-codegen/slice_iter.reverse_loop.PreCodegen.after.mir
184 216 tests/mir-opt/pre-codegen/slice_iter.slice_iter_mut_next_back.PreCodegen.after.mir
182 254 tests/mir-opt/pre-codegen/slice_iter.slice_iter_next.PreCodegen.after.mir
```
(That's ≈70 lines less for `Iter::next`, for example.)
r? `@ghost`
~~Built atop #111282, so draft until that lands.~~
You will need to add the following as replacement for the old __rust_*
definitions when not using the alloc shim.
#[no_mangle]
static __rust_no_alloc_shim_is_unstable: u8 = 0;
Currently, slice iterators over ZSTs store `end = start.wrapping_byte_add(len)`.
That's slightly convenient for `is_empty`, but kinda annoying for pretty much everything else -- see bugs like 42789, for example.
This PR instead changes it to just `end = ptr::invalid(len)` instead.
That's easier to think about (IMHO, at least) as well as easier to represent.
Don't force include Windows goop when documenting
Why do we need to include all the windows bits on non-windows platforms? Let's try not doing that.
Possible alternative to #111394, if it works.
Fix incorrect implication of transmuting slices
transmute<&[u8]> would be useful and as a beginner it is confusing to see documents casually confuse the types of &[u8] and [u8; SZ]
Remove some `assume`s from slice iterators that don't do anything
Because the start pointer is iterators is already a `NonNull`, we emit the appropriate `!nonnull` metadata when loading the pointer to tell LLVM that it's non-null.
Probably the best way to see that it's the metadata that's important (and not the `assume`) is to observe that LLVM actually *removes* the `assume` from the optimized IR: <https://rust.godbolt.org/z/KhE6G963n>.
(I also checked that, yes, the if-not-ZST `assume` on `end` is still doing something: it's how there's a `!nonnull` metadata on its load, even though it's an ordinary raw pointer. The codegen test added in this PR fails if the other `assume` is removed.)
Revert "Populate effective visibilities in `rustc_privacy`"
This reverts commit cff85f22f5, cc #110907. It needs to be fixed, but there are too many issues being reported that I wanted to put up a revert until a proper fix can be committed.
Fixes a ton of issues where private but still reachable impls were missing during codegen:
Fixes#111320Fixes#111321Fixes#111334Fixes#111357Fixes#111368Fixes#111373Fixes#111377Fixes#111386Fixes#111387
`@bors` p=1
r? `@petrochenkov`
Implement builtin # syntax and use it for offset_of!(...)
Add `builtin #` syntax to the parser, as well as a generic infrastructure to support both item and expression position builtin syntaxes. The PR also uses this infrastructure for the implementation of the `offset_of!` macro, added by #106934.
cc `@petrochenkov` `@DrMeepster`
cc #110680 `builtin #` tracking issue
cc #106655 `offset_of!` tracking issue
Start using `windows sys` for Windows FFI bindings in std
Switch to using windows-sys for FFI. In order to avoid some currently contentious issues, this uses windows-bindgen to generate a smaller set of bindings instead of using the full crate.
Unlike the windows-sys crate, the generated bindings uses `*mut c_void` for handle types instead of `isize`. This to sidestep opsem concerns about mixing pointer types and integers between languages. Note that `SOCKET` remains defined as an integer but instead of being a usize, it's changed to fit the [standard library definition](a41fc00eaf/library/std/src/os/windows/raw.rs (L12-L16)):
```rust
#[cfg(target_pointer_width = "32")]
pub type SOCKET = u32;
#[cfg(target_pointer_width = "64")]
pub type SOCKET = u64;
```
The generated bindings also customizes the `#[link]` imports. I hope to switch to using raw-dylib but I don't want to tie that too closely with the switch to windows-sys.
---
Changes outside of the bindings are, for the most part, fairly minimal (e.g. some differences in `*mut` vs. `*const` or a few types differ). One issue is that our own bindings sometimes mix in higher level types, like `BorrowedHandle`. This is pretty adhoc though.
Add `#[inline]` to functions that are never called
This makes libcore binary size reduce by ~300 bytes. Not much, but these functions are never called so it doesn't make sense for them to get into the binary anyway.
Always const-evaluate the GCD in `slice::align_to_offsets`
Use an inline `const`-block to force the compiler to calculate the GCD at compile time, even in debug mode. This shouldn't affect the behavior of the program at all, but it drastically cuts down on the number of instructions emitted with optimizations disabled.
With the current implementation, a single `slice::align_to` instantiation (specifically `<[u8]>::align_to::<u128>()`) generates 676 instructions (on x86-64). Forcing the GCD computation to be const cuts it down to 327 instructions, so just over 50% less. This is obviously not representative of actual runtime gains, but I still see it as a significant win as long as it doesn't degrade compile times.
Not having to worry about LLVM const-evaluating the GCD function also allows it to use the textbook recursive euclidean algorithm instead of a much more complicated iterative implementation with multiple `unsafe`-blocks.
Remove `identity_future` from stdlib
This function/lang_item was introduced in #104321 as a temporary workaround of future lowering. The usage and need for it went away in #104833.
After a bootstrap update, the function itself can be removed from `std`.
STD support for PSVita
This PR adds std support for `armv7-sony-vita-newlibeabihf` target.
The work here is fairly similar to #95897, just for a different target platform.
This depends on the following pull requests:
rust-lang/backtrace-rs#523rust-lang/libc#3209
enable `rust_2018_idioms` lint group for doctests
With this change, `rust_2018_idioms` lint group will be enabled for compiler/libstd doctests.
Resolves#106086Resolves#99144
Signed-off-by: ozkanonur <work@onurozkan.dev>
Constify `[u8]::is_ascii` (unstably)
UTF-8 checking in `const fn`-stabilized back in 1.63 (#97367), but apparently somehow ASCII checking was never const-ified, despite being simpler.
New constness-tracking issue for `is_ascii`: #111090
I noticed this working on `ascii::Char`: #110998
This function/lang_item was introduced in #104321 as a temporary workaround of future lowering.
The usage and need for it went away in #104833.
After a bootstrap update, the function itself can be removed from `std`.
Remove calls to `mem::forget` and `mem::replace` in `Option::get_or_insert_with`.
This removes the unneeded calls to `mem::forget` and `mem::replace` in `Option::get_or_insert_with`.
clean up `transmute`s in `core`
* Use `transmute_unchecked` instead of `transmute_copy` for `MaybeUninit::transpose`.
* Use manual transmute for `Option<Ordering>` → `i8`.
Fix MXCSR configuration dependent timing
Dependent on the (potentially secret) data some vector instructions operate on, and the content in MXCSR, instruction retirement may be delayed by one cycle. This is a potential side channel.
This PR fixes this vulnerability for the `x86_64-fortanix-unknown-sgx` platform by loading MXCSR with `0x1fbf` through an `xrstor` instruction when the enclave is entered and executing an `lfence` immediately after. Other changes of the MXCSR happen only when the enclave is about to be exited and no vector instructions will be executed before it will actually do so. Users of EDP who change the MXCSR and do wish to defend against this side channel, will need to implement the software mitigation described [here](https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/mxcsr-configuration-dependent-timing.html).
cc: `@jethrogb` `@monokles`
Add FreeBSD cpuset support to `std:🧵:available_concurrency`
Use libc::cpuset_getaffinity to determine the CPUs available to the current process.
The existing sysconf and sysctl paths are left as fallback.
btree_map: `Cursor{,Mut}::peek_prev` must agree
Our `Cursor::peek_prev` and `CursorMut::peek_prev` must agree on how to behave when they are called on the "null element". This will fix rust-lang#111228.
r? `@Amanieu`
Fix `checked_{add,sub}_duration` incorrectly returning `None` when `other` has more than `i64::MAX` seconds
Use `checked_{add,sub}_unsigned` in `checked_{add,sub}_duration` so that the correct result is returned when adding/subtracting durations with more than `i64::MAX` seconds.
avoid duplicating TLS state between test std and realstd
This basically re-lands https://github.com/rust-lang/rust/pull/100201 and https://github.com/rust-lang/rust/pull/106638, which got reverted by https://github.com/rust-lang/rust/pull/110861. This works around 2 Miri limitations:
- Miri doesn't support the magic linker section that our Windows TLS support relies on, and instead knows where in std to find the symbol that stores the thread callback.
- For macOS, Miri only supports at most one destructor to be registered per thread.
The 2nd would not be very hard to fix (though the intended destructor order is unclear); the first would be a lot of work to fix. Neither of these is a problem for regular Rust code, but in the std test suite we have essentially 2 copies of the std code and then these both become issues. To avoid that we have the std test crate import the TLS code from the real std instead of having its own copy.
r? ``````@m-ou-se``````
Add a `sysroot` crate to represent the standard library crates
This adds a dummy crate named `sysroot` to represent the standard library target instead of using the `test` crate. This allows the removal of `proc_macro` as a dependency of `test` allowing these 2 crates to build in parallel saving around 9 seconds locally.
Replace generic thread parker with explicit no-op parker
With #98391 merged, all platforms supporting threads now have their own parking implementations. Therefore, the generic implementation can be removed. On the remaining platforms (really just WASM without atomics), parking is not supported, so calls to `thread::park` now return instantly, which is [allowed by their API](https://doc.rust-lang.org/nightly/std/thread/fn.park.html). This is a change in behaviour, as spurious wakeups do not currently occur since all platforms guard against them. It is invalid to depend on this, but I'm still going to tag this as libs-api for confirmation.
````@rustbot```` label +T-libs +T-libs-api +A-atomic
r? rust-lang/libs
Add cross-language LLVM CFI support to the Rust compiler
This PR adds cross-language LLVM Control Flow Integrity (CFI) support to the Rust compiler by adding the `-Zsanitizer-cfi-normalize-integers` option to be used with Clang `-fsanitize-cfi-icall-normalize-integers` for normalizing integer types (see https://reviews.llvm.org/D139395).
It provides forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space). For more information about LLVM CFI and cross-language LLVM CFI support for the Rust compiler, see design document in the tracking issue #89653.
Cross-language LLVM CFI can be enabled with -Zsanitizer=cfi and -Zsanitizer-cfi-normalize-integers, and requires proper (i.e., non-rustc) LTO (i.e., -Clinker-plugin-lto).
Thank you again, ``@bjorn3,`` ``@nikic,`` ``@samitolvanen,`` and the Rust community for all the help!
Implement tuple<->array convertions via `From`
This PR adds the following impls that convert between homogeneous tuples and arrays of the corresponding lengths:
```rust
impl<T> From<[T; 1]> for (T,) { ... }
impl<T> From<[T; 2]> for (T, T) { ... }
/* ... */
impl<T> From<[T; 12]> for (T, T, T, T, T, T, T, T, T, T, T, T) { ... }
impl<T> From<(T,)> for [T; 1] { ... }
impl<T> From<(T, T)> for [T; 2] { ... }
/* ... */
impl<T> From<(T, T, T, T, T, T, T, T, T, T, T, T)> for [T; 12] { ... }
```
IMO these are quite uncontroversial but note that they are, just like any other trait impls, insta-stable.
This commit adds cross-language LLVM Control Flow Integrity (CFI)
support to the Rust compiler by adding the
`-Zsanitizer-cfi-normalize-integers` option to be used with Clang
`-fsanitize-cfi-icall-normalize-integers` for normalizing integer types
(see https://reviews.llvm.org/D139395).
It provides forward-edge control flow protection for C or C++ and Rust
-compiled code "mixed binaries" (i.e., for when C or C++ and Rust
-compiled code share the same virtual address space). For more
information about LLVM CFI and cross-language LLVM CFI support for the
Rust compiler, see design document in the tracking issue #89653.
Cross-language LLVM CFI can be enabled with -Zsanitizer=cfi and
-Zsanitizer-cfi-normalize-integers, and requires proper (i.e.,
non-rustc) LTO (i.e., -Clinker-plugin-lto).
Some data-independent timing vector instructions may have subtle data-dependent
timing due to MXCSR configuration; dependent on (potentially secret) data
instruction retirement may be delayed by one cycle.
This can be done by simply changing the `\??\` prefix to `\\?\` and then attempting to convert to a user path.
Currently it simply strips off the prefix which could lead to the wrong path being returned (e.g. if it's not a drive path or if the path contains trailing spaces, etc).
Ensure test library issues json string line-by-line
#108659 introduces a custom test display implementation. It does so by using libtest to output json. The stdout is read line by line and parsed. The code trims the line read and checks whether it starts with a `{` and ends with a `}`.
Unfortunately, there is a race condition in how json data is written to stdout. The `write_message` function calls `self.out.write_all` repeatedly to write a buffer that contains (partial) json data, or a new line. There is no lock around the `self.out.write_all` functions. Similarly, the `write_message` function itself is called with only partial json data. As these functions are called from concurrent threads, this may result in json data ending up on the same stdout line. This PR avoids this by buffering the complete json data before issuing a single `self.out.write_all`.
(#109484 implemented a partial fix for this issue; it only avoids that failed json parsing would result in a panic.)
cc: `@jethrogb,` `@pietroalbini`
Remove `all` in target_thread_local cfg
I think it was left there by mistake after the previous refactoring. I just came across it while rebasing to master.
Add `ConstParamTy` trait
This is a bit sketch, but idk.
r? `@BoxyUwU`
Yet to be done:
- [x] ~~Figure out if it's okay to implement `StructuralEq` for primitives / possibly remove their special casing~~ (it should be okay, but maybe not in this PR...)
- [ ] Maybe refactor the code a little bit
- [x] Use a macro to make impls a bit nicer
Future work:
- [ ] Actually™ use the trait when checking if a `const` generic type is allowed
- [ ] _Really_ refactor the surrounding code
- [ ] Refactor `marker.rs` into multiple modules for each "theme" of markers
Refactor core::char::EscapeDefault and co. structures
Change core::char::{EscapeUnicode, EscapeDefault and EscapeDebug}
structures from using a state machine to computing escaped sequence
upfront and during iteration just going through the characters.
This is arguably simpler since it’s easier to think about having
a buffer and start..end range to iterate over rather than thinking
about a state machine.
This also harmonises implementation of aforementioned iterators and
core::ascii::EscapeDefault struct. This is done by introducing a new
helper EscapeIterInner struct which holds the buffer and offers simple
methods for iterating over range.
As a side effect, this probably optimises Display implementation for
those types since rather than calling write_char repeatedly, write_str
is invoked once. On 64-bit platforms, it also reduces size of some of
the structs:
| Struct | Before | After |
|----------------------------+--------+-------+
| core::char::EscapeUnicode | 16 | 12 |
| core::char::EscapeDefault | 16 | 12 |
| core::char::EscapeDebug | 16 | 16 |
My ulterior motive and reason why I started looking into this is
addition of as_str method to the iterators. With this change this
will became trivial. It’s also going to be trivial to implement
DoubleEndedIterator if that’s ever desired.
Make sure the implementation of TcpStream::as_raw_fd is fully inlined
Currently the following function:
```rust
use std::os::fd::{AsRawFd, RawFd};
use std::net::TcpStream;
pub fn as_raw_fd(socket: &TcpStream) -> RawFd {
socket.as_raw_fd()
}
```
Is optimized to the following:
```asm
example::as_raw_fd:
push rax
call qword ptr [rip + <std::net::tcp::TcpStream as std::sys_common::AsInner<std::sys_common::net::TcpStream>>::as_inner@GOTPCREL]
mov rdi, rax
call qword ptr [rip + std::sys_common::net::TcpStream::socket@GOTPCREL]
mov rdi, rax
pop rax
jmp qword ptr [rip + _ZN73_$LT$std..sys..unix..net..Socket$u20$as$u20$std..os..fd..raw..AsRawFd$GT$9as_raw_fd17h633bcf7e481df8bbE@GOTPCREL]
```
I think it would make more sense to inline trivial functions used within `TcpStream::AsRawFd`.
update wasi_clock_time_api ref.
Closes#110809
>Preview0 corresponded to the import module name wasi_unstable. It was also called snapshot_0 in some places. It was short-lived, and the changes to preview1 were minor, so the focus here is on preview1.
we use the `preview1` doc according to the above quote form [WASI legacy Readme](https://github.com/WebAssembly/WASI/blob/main/legacy/README.md) .
Add 64-bit `time_t` support on 32-bit glibc Linux to `set_times`
Add support to `set_times` for 64-bit `time_t` on 32-bit glibc Linux platforms which have a 32-bit `time_t`. Split from #109773.
Tracking issue: #98245
std docs: edit `PathBuf::set_file_name` example
To make explicit that `set_file_name` might replace or remove the
extension, not just the file stem.
Also edit docs for `Path::with_file_name`, which calls `set_file_name`.
Some of these relations were already mentioned in the text, but that
Send is implemented for &mut impl Send was not mentioned,
neither did the docs list when &T is Sync.
Make `mem::replace` simpler in codegen
Since they'd mentioned more intrinsics for simplifying stuff recently,
r? `@WaffleLapkin`
This is a continuation of me looking at foundational stuff that ends up with more instructions than it really needs. Specifically I noticed this one because `Range::next` isn't MIR-inlining, and one of the largest parts of it is a `replace::<usize>` that's a good dozen instructions instead of the two it could be.
So this means that `ptr::write` with a `Copy` type no longer generates worse IR than manually dereferencing (well, at least in LLVM -- MIR still has bonus pointer casts), and in doing so means that we're finally down to just the two essential `memcpy`s when emitting `mem::replace` for a large type, rather than the bonus-`alloca` and three `memcpy`s we emitted before this ([or the 6 we currently emit in 1.69 stable](https://rust.godbolt.org/z/67W8on6nP)). That said, LLVM does _usually_ manage to optimize the extra code away. But it's still nice for it not to have to do as much, thanks to (for example) not going through an `alloca` when `replace`ing a primitive like a `usize`.
(This is a new intrinsic, but one that's immediately lowered to existing MIR constructs, so not anything that MIRI or the codegen backends or MIR semantics needs to do work to handle.)
Tweak await span to not contain dot
Fixes a discrepancy between method calls and await expressions where the latter are desugared to have a span that *contains* the dot (i.e. `.await`) but method call identifiers don't contain the dot. This leads to weird suggestions suggestions in borrowck -- see linked issue.
Fixes#110761
This mostly touches a bunch of tests to tighten their `await` span.
`inline(always)` for `lt`/`le`/`ge`/`gt` on integers and floats
I happened to notice one of these not getting inlined as part of `Range::next` in <https://rust.godbolt.org/z/4WKWWxj1G>
```rust
bb1: {
StorageLive(_5);
_6 = &mut _4;
StorageLive(_21);
StorageLive(_14);
StorageLive(_15);
_15 = &((*_6).0: usize);
StorageLive(_16);
_16 = &((*_6).1: usize);
_14 = <usize as PartialOrd>::lt(move _15, move _16) -> bb7;
}
```
So since a call for something that's just one instruction is never the right choice, `#[inline(always)]` seems appropriate, like we have it on things like the rotate methods on integers.
Improve internal field comments on `slice::Iter(Mut)`
I wrote these in a previous PR that I ended up withdrawing, so might as well submit them separately.
`@bors` rollup=always
Make sure that some stdlib method signatures aren't accidental refinements
In the process of implementing https://rust-lang.github.io/rfcs/3245-refined-impls.html, I found a bunch of stdlib implementations that accidentally "refined" their method signatures by dropping (unnecessary) bounds.
This isn't currently a problem, but may become one if/when method signature refining is stabilized in the future. Shouldn't hurt to make these signatures a bit more accurate anyways.
NOTE (just to be clear lol): This does not affect behavior at all, since we don't actually take advantage of refined implementations yet!
Use MIR's `Offset` for pointer `add` too
~~Status: draft while waiting for #110822 to land, since this is built atop that.~~
~~r? `@ghost~~`
Canonical Rust code has mostly moved to `add`/`sub` on pointers, which take `usize`, instead of `offset` which takes `isize`. (And, relatedly, when `sub_ptr` was added it turned out it replaced every single in-tree use of `offset_from`, because `usize` is just so much more useful than `isize` in Rust.)
Unfortunately, `intrinsics::offset` could only accept `*const` and `isize`, so there's a *huge* amount of type conversions back and forth being done. They're identity conversions in the backend, but still end up producing quite a lot of unhelpful MIR.
This PR changes `intrinsics::offset` to accept `*const` *and* `*mut` along with `isize` *and* `usize`. Conveniently, the backends and CTFE already handle this, since MIR's `BinOp::Offset` [already supports all four combinations](adaac6b166/compiler/rustc_const_eval/src/transform/validate.rs (L523-L528)).
To demonstrate the difference, I added some `mir-opt/pre-codegen/` tests around slice indexing. Here's the difference to `[T]::get_mut`, since it uses `<*mut _>::add` internally:
```diff
`@@` -79,30 +70,21 `@@` fn slice_get_mut_usize(_1: &mut [u32], _2: usize) -> Option<&mut u32> {
StorageLive(_12); // scope 3 at $SRC_DIR/core/src/slice/index.rs:LL:COL
StorageLive(_9); // scope 6 at $SRC_DIR/core/src/slice/index.rs:LL:COL
_9 = _8 as *mut u32 (PtrToPtr); // scope 11 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- StorageLive(_13); // scope 13 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- _13 = _2 as isize (IntToInt); // scope 13 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- StorageLive(_14); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- StorageLive(_15); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- _15 = _9 as *const u32 (Pointer(MutToConstPointer)); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- _14 = Offset(move _15, _13); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- StorageDead(_15); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- _7 = move _14 as *mut u32 (PtrToPtr); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- StorageDead(_14); // scope 15 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
- StorageDead(_13); // scope 13 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
+ _7 = Offset(_9, _2); // scope 13 at $SRC_DIR/core/src/ptr/mut_ptr.rs:LL:COL
StorageDead(_9); // scope 6 at $SRC_DIR/core/src/slice/index.rs:LL:COL
StorageDead(_12); // scope 3 at $SRC_DIR/core/src/slice/index.rs:LL:COL
StorageDead(_11); // scope 3 at $SRC_DIR/core/src/slice/index.rs:LL:COL
```
1c1c8e442a (diff-a841b6a4538657add3f39bc895744331453d0625e7aace128b1f604f0b63c8fdR80)
I happened to notice one of these not getting inlined as part of `Range::next` in <https://rust.godbolt.org/z/4WKWWxj1G>
```rust
bb1: {
StorageLive(_5);
_6 = &mut _4;
StorageLive(_21);
StorageLive(_14);
StorageLive(_15);
_15 = &((*_6).0: usize);
StorageLive(_16);
_16 = &((*_6).1: usize);
_14 = <usize as PartialOrd>::lt(move _15, move _16) -> bb7;
}
```
So since a call for something this trivial is never the right choice, `#[inline(always)]` seems appropriate.
`remove_dir_all`: try deleting the directory even if `FILE_LIST_DIRECTORY` access is denied
If opening a directory with `FILE_LIST_DIRECTORY` access fails then we should try opening without requesting that access. We may still be able to delete it if it's empty or a link.
Fixes https://github.com/rust-lang/cargo/issues/12042
More core::fmt::rt cleanup.
- Removes the `V1` suffix from the `Argument` and `Flag` types.
- Moves more of the format_args lang items into the `core::fmt::rt` module. (The only remaining lang item in `core::fmt` is `Arguments` itself, which is a public type.)
Part of https://github.com/rust-lang/rust/issues/99012
Follow-up to https://github.com/rust-lang/rust/pull/110616
Document `const {}` syntax for `std::thread_local`.
It exists and is pretty cool. More people should use it.
It was added in #83416 and stabilized in #91355 with the tracking issue #84223.
If opening a directory with `FILE_LIST_DIRECTORY` access fails then we should try opening without requesting that access. We may still be able to delete it if it's empty or a link.
Change memory ordering in System wrapper example
Currently, the `SeqCst` ordering is used, which seems unnecessary:
+ Even `Relaxed` ordering guarantees that all updates are atomic and are executed in total order
+ User code only reads atomic for monitoring purposes, no "happens-before" relationships with actual allocations and deallocations are needed for this
If argumentation above is correct, I propose changing ordering to `Relaxed` to clarify that no synchronization is required here, and improve performance (if somebody copy-pastes this example into their code).
Correct `std::prelude` comment
(Read the changed file first for context.)
First, `alloc` has no prelude.
Second, the docs for `v1` don't matter since the [prelude module] already has all the doc links. The `rust_2021` module for instance also doesnt have a convenient doc page. However as I understand glob imports still cant be used because the items dont have the same stabilisation versions.
[prelude module]: https://doc.rust-lang.org/std/prelude/index.html
docs(std): clarify remove_dir_all errors
When using `remove_dir_all`, I assumed that the function was idempotent and that I could always call it to remove a directory if it existed. That's not the case and it bit me in production, so I figured I'd submit this to clarify the docs.
Restructure and rename std thread_local internals to make it less of a maze
Every time I try to work on std's thread local internals, it feels like I'm trying to navigate a confusing maze made of macros, deeply nested modules, and types with multiple names/aliases. Time to clean it up a bit.
This PR:
- Exports `Key` with its own name (`Key`), instead of `__LocalKeyInner`
- Uses `pub macro` to put `__thread_local_inner` into a (unstable, hidden) module, removing `#[macro_export]`, removing it from the crate root.
- Removes the `__` from `__thread_local_inner`.
- Removes a few unnecessary `allow_internal_unstable` features from the macros
- Removes the `libstd_thread_internals` feature. (Merged with `thread_local_internals`.)
- And removes it from the unstable book
- Gets rid of the deeply nested modules for the `Key` definitions (`mod fast` / `mod os` / `mod statik`).
- Turns a `#[cfg]` mess into a single `cfg_if`, now that there's no `#[macro_export]` anymore that breaks with `cfg_if`.
- Simplifies the `cfg_if` conditions to not repeat the conditions.
- Removes useless `normalize-stderr-test`, which were left over from when the `Key` types had different names on different platforms.
- Removes a seemingly unnecessary `realstd` re-export on `cfg(test)`.
This PR changes nothing about the thread local implementation. That's for a later PR. (Which should hopefully be easier once all this stuff is a bit cleaned up.)
Spelling library
Split per https://github.com/rust-lang/rust/pull/110392
I can squash once people are happy w/ the changes. It's really uncommon for large sets of changes to be perfectly acceptable w/o at least some changes.
I probably won't have time to respond until tomorrow or the next day
Fix `std` compilation error for wasi+atomics
Fix https://github.com/rust-lang/rust/issues/109727
It seems that the `unsupported/once.rs` module isn't meant to exist at the same time as the `futex` module, as they have conflicting definitions.
I've solved this by defining the `once` module only if `not(target_feature = "atomics")`.
The `wasm32-unknown-unknown` target [similarly only defines the `once` module if `not(target_feature = "atomics")`](01c4f31927/library/std/src/sys/wasm/mod.rs (L69-L70)).
As show in [this block of code](01c4f31927/library/std/src/sys_common/once/mod.rs (L10-L34)), the `sys::once` module doesn't need to exist if `all(target_arch = "wasm32", target_feature = "atomics")`.
Update documentation wording on path 'try_exists' functions
Just eliminate the quadruple negation in `doesn't silently ignore errors unrelated to ... not existing.`
black_box doc corrections for clarification - Issue #107957
Made a complete pass through the docs to help resolve https://github.com/rust-lang/rust/issues/107957
No code changes, just documentation
`@rustbot` label +T-libs-api -T-libs
Updating Wake example to use new 'pin!' macro
Closes: https://github.com/rust-lang/rust/issues/109965
I have already had this reviewed and approved here: https://github.com/rust-lang/rust/pull/110026 . But because I had some git issues and chose the "nuke it" option as my solution it didn't get merged. I nuked it too quickly. I am sorry for trouble of reviewing twice.
Fix no_global_oom_handling build
`provide_sorted_batch` in core is incorrectly marked with `#[cfg(not(no_global_oom_handling))]` which prevents core from building with the cfg enabled.
Nothing in `core` allocates memory (including this function). The `cfg` gate is incorrect.
cc ``@dpaoliello``
r? ``@wesleywiser``
The cfg was added by #107191
Add shortcut for Grisu3 algorithm.
While Grisu3 is way more faster for most numbers compare to Dragon4, the fall back to Dragon4 procedure for certain numbers could cause some performance regressions compare to use Dragon4 directly. Mitigating the regression caused by falling back is important for a largely used core library.
In Grisu3 algorithm implementation, there's a shortcut to jump out earlier when the fractional or integrals cannot meet the requirement of requested digits. This could significantly improve the performance of converting floating number to string as it falls back even without starting trying the algorithm.
The original idea is from the [.NET implementation](https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Number.Grisu3.cs#L602-L615) and the code was originally added in [this PR](https://github.com/dotnet/coreclr/pull/14646#issuecomment-350942050). This shortcut has been shipped long time ago and has been proved working.
Fix#110129
