Replace `self.end() == usize::MAX` and `self.end() + 1 > slice.len()`
with `self.end() >= slice.len()`. Same reasoning as previous commit.
Also consolidate the str panicking functions into function.
The checks for `self.end() == usize::MAX` and `self.end() + 1 > slice.len()`
can be replaced with `self.end() >= slice.len()`, since
`self.end() < slice.len()` implies both
`self.end() <= slice.len()` and
`self.end() < usize::MAX`.
std: introduce path normalize methods at top of `std::path`
Closesrust-lang/rust#142931
Mention other methods that call `conponents` and `canonicalize` that fully normalize path. And fix two typo.
r? libs
Align `ArrayWindows` trait impls with `Windows`
With `slice::ArrayWindows` getting ready to stabilize in 1.94, I noticed that it currently has some differences in trait implementations compared to `slice::Windows`, and I think we should align these.
- Remove `derive(Copy)` -- we generally don't want `Copy` for iterators at all, as this is seen as a footgun (e.g. rust-lang/rust#21809). This is obviously a breaking change though, so we should only remove this if we also backport the removal before it's stable. Otherwise, it should at least be replaced by a manual impl without requiring `T: Copy`.
- Manually `impl Clone`, simply to avoid requiring `T: Clone`.
- `impl FusedIterator`, because it is trivially so. The `since = "1.94.0"` assumes we'll backport this, otherwise we should change that to the "current" placeholder.
- `impl TrustedLen`, because we can trust our implementation.
- `impl TrustedRandomAccess`, because the required `__iterator_get_unchecked` method is straightforward.
r? libs-api
@rustbot label beta-nominated
(at least for the `Copy` removal, but we could be more selective about the rest).
std: Don't panic when removing a nonexistent UEFI var
`std::env::remove_var` does not say that deleting a nonexistent variable is an error (and at least on Linux, it indeed does not cause an error).
The UEFI Shell Protocol spec also doesn't say it's an error, but the edk2 implementation delegates to the UEFI runtime `SetVariable` function, which returns `EFI_NOT_FOUND` when trying to delete a nonexistent variable.
Change the UEFI implementation to check for a `NotFound` error and treat it as success.
CC @Ayush1325
Port `rustc_insignificant_dtor`
r? @JonathanBrouwer
Second commit removes it from an impl in std. I looked, and I really think it had no effect in the past. We only look for this attr on ADTs...
Stop having two different alignment constants
Now that there's a `<T as SizedTypeProperties>::ALIGNMENT` constant, `Alignment::of` can use that instead of an inline constant, like how `Layout::new` uses the constant from `SizedTypeProperties`.
Reword the caveats on `array::map`
Thanks to #107634 and some improvements in LLVM (particularly [`dead_on_unwind`](https://llvm.org/docs/LangRef.html#parameter-attributes)), the method actually optimizes reasonably well now.
So focus the discussion on the fundamental ordering differences where the optimizer might never be able to fix it because of the different behaviour, and keep encouraging `Iterator::map` where an array wasn't actually ever needed.
`std::env::remove_var` does not say that deleting a nonexistent variable
is an error (and at least on Linux, it indeed does not cause an
error).
The UEFI Shell Protocol spec also doesn't say it's an error, but the
edk2 implementation delegates to the UEFI runtime `SetVariable`
function, which returns `EFI_NOT_FOUND` when trying to delete a
nonexistent variable.
Change the UEFI implementation to check for a `NotFound` error and treat
it as success.
RwLock: refine documentation to emphasize non-reentrancy guarantees
This addresses the need for clarification brought up in rust-lang/rust#149693. Specifically, it notes that some implementations may choose to panic if they detect deadlock situations during recursive locking attempts for both `read()` and `write()` calls.
* Provide an example highlighting that multiple read locks can be held across different threads simultaneously.
* Remove the example that shows a situation that can potentially deadlock. (as demonstrated in the very same documentation a few paragraphs above)
* Improve documentation regarding the possibility of panics during recursive read or write lock attempts.
Issues: https://github.com/rust-lang/rust/issues/149693
Stabilize `core::hint::cold_path`
`cold_path` has been around unstably for a while and is a rather useful tool to have. It does what it is supposed to and there are no known remaining issues, so stabilize it here (including const).
Newly stable API:
```rust
// in core::hint
pub const fn cold_path();
```
I have opted to exclude `likely` and `unlikely` for now since they have had some concerns about ease of use that `cold_path` doesn't suffer from. `cold_path` is also significantly more flexible; in addition to working with boolean `if` conditions, it can be used in `match` arms, `if let`, closures, and other control flow blocks. `likely` and `unlikely` are also possible to implement in user code via `cold_path`, if desired.
Closes: https://github.com/rust-lang/rust/issues/136873 (tracking issue)
---
There has been some design and implementation work for making `#[cold]` function in more places, such as `if` arms, `match` arms, and closure bodies. Considering a stable `cold_path` will cover all of these usecases, it does not seem worth pursuing a more powerful `#[cold]` as an alternative way to do the same thing. If the lang team agrees, then:
Closes: https://github.com/rust-lang/rust/issues/26179
Closes: https://github.com/rust-lang/rust/pull/120193
feat: Implement `int_from_ascii` for `NonZero<T>`
- Tracking issue: rust-lang/rust#134821
This pull request adds `from_ascii` and `from_ascii_radix` methods to `NonZero<T>` that parses a non-zero integer from an ASCII-byte slice (`&[u8]`) with decimal digits or digits in a given base.
When using the combination of `int::from_ascii` or `int::from_ascii_radix` and `NonZero::<T>::new`, [`IntErrorKind::Zero`](https://doc.rust-lang.org/core/num/enum.IntErrorKind.html#variant.Zero) cannot be returned as an error.
`NonZero::<T>::from_str_radix` and `NonZero::<T>::from_str` require a string (`&str`) as a parameter.
```rust
// Cannot return `IntErrorKind::Zero` as an error.
assert_eq!(NonZero::new(u8::from_ascii(b"0").unwrap()), None);
// Can return `IntErrorKind::Zero` as an error.
let err = NonZero::<u8>::from_ascii(b"0").unwrap_err();
assert_eq!(err.kind(), &IntErrorKind::Zero);
```
See also rust-lang/rust#152193
Stabilize new inclusive range type and iterator type
Part 1 of stabilizing the new range types for rust-lang/rust#125687
stabilizes `core::range::RangeInclusive` and `core::range::RangeInclusiveIter`. Newly stable API:
```rust
// in core and std
pub mod range;
// in core::range
pub struct RangeInclusive<Idx> {
pub start: Idx,
pub last: Idx,
}
impl<Idx: fmt::Debug> fmt::Debug for RangeInclusive<Idx> { /* ... */ }
impl<Idx: PartialOrd<Idx>> RangeInclusive<Idx> {
pub const fn contains<U>(&self, item: &U) -> bool
where
Idx: [const] PartialOrd<U>,
U: ?Sized + [const] PartialOrd<Idx>;
pub const fn is_empty(&self) -> bool
where
Idx: [const] PartialOrd;
}
impl<Idx: Step> RangeInclusive<Idx> {
pub fn iter(&self) -> RangeInclusiveIter<Idx>;
}
impl<T> const RangeBounds<T> for RangeInclusive<T> { /* ... */ }
impl<T> const RangeBounds<T> for RangeInclusive<&T> { /* ... */ }
impl<T> const From<RangeInclusive<T>> for legacy::RangeInclusive<T> { /* ... */ }
impl<T> const From<legacy::RangeInclusive<T>> for RangeInclusive<T> { /* ... */ }
pub struct RangeInclusiveIter<A>(/* ... */);
impl<A: Step> RangeInclusiveIter<A> {
pub fn remainder(self) -> Option<RangeInclusive<A>>;
}
impl<A: Step> Iterator for RangeInclusiveIter<A> {
type Item = A;
/* ... */
}
impl<A: Step> DoubleEndedIterator for RangeInclusiveIter<A> { /* ... */ }
impl<A: Step> FusedIterator for RangeInclusiveIter<A> { }
impl<A: Step> IntoIterator for RangeInclusive<A> {
type Item = A;
type IntoIter = RangeInclusiveIter<A>;
/* ... */
}
impl ExactSizeIterator for RangeInclusiveIter<u8> { }
impl ExactSizeIterator for RangeInclusiveIter<i8> { }
unsafe impl<T> const SliceIndex<[T]> for range::RangeInclusive<usize> {
type Output = [T];
/* ... */
}
unsafe impl const SliceIndex<str> for range::RangeInclusive<usize> {
type Output = str;
/* ... */
}
```
I've removed the re-exports temporarily because from what I can tell, there's no way to make re-exports of stable items unstable. They will be added back and stabilized in a separate PR.
Update wasi-sdk used in CI/releases
This is similar to prior updates such as rust-lang/rust#149037 in that this is just updating a URL. This update though has some technical updates accompanying it as well, however:
* The `wasm32-wasip2` target no longer uses APIs from WASIp1 on this target, even for startup. This means that the final binary no longer has an "adapter" which can help making instantiation of a component a bit more lean.
* In rust-lang/rust#147572 libstd was updated to use wasi-libc more often on the `wasm32-wasip2` target. This uncovered a number of bugs in wasi-libc such as rust-lang/rust#149864, rust-lang/rust#150291, and rust-lang/rust#151016. These are all fixed in wasi-sdk-30 so the workarounds in the standard library are all removed.
Overall this is not expected to have any sort of major impact on users of WASI targets. Instead it's expected to be a normal routine update to keep the wheels greased and oiled.
This is similar to prior updates such as 149037 in that this is just
updating a URL. This update though has some technical updates
accompanying it as well, however:
* The `wasm32-wasip2` target no longer uses APIs from WASIp1 on this
target, even for startup. This means that the final binary no longer
has an "adapter" which can help making instantiation of a component a
bit more lean.
* In 147572 libstd was updated to use wasi-libc more often on the
`wasm32-wasip2` target. This uncovered a number of bugs in
wasi-libc such as 149864, 150291, and 151016. These are all fixed in
wasi-sdk-30 so the workarounds in the standard library are all
removed.
Overall this is not expected to have any sort of major impact on users
of WASI targets. Instead it's expected to be a normal routine update to
keep the wheels greased and oiled.
we will add an explicit incompatibility of softfloat and vector feature
in rutsc s390x-unknown-none-softfloat target specification.
Therefore we need to disable vector intrinsics here to be able to compile
core for this target.
library/std: Rename `ON_BROKEN_PIPE_FLAG_USED` to `ON_BROKEN_PIPE_USED`
This commit is a pure internal rename and does not change any functionality.
The `FLAG_` part of `ON_BROKEN_PIPE_FLAG_USED` comes from that the compiler flag `-Zon-broken-pipe=...` is used to enable the feature.
Remove the `FLAG_` part so the name works both for the current compiler flag `-Zon-broken-pipe=...` and for the upcoming [Externally Implementable Item `#[std::io::on_broken_pipe]`](https://github.com/rust-lang/rust/pull/150591) PR. This makes the diff of that PR smaller.
The local variable name `sigpipe_attr_specified` comes from way back when the feature was controlled with an `fn main()` attribute called `#[unix_sigpipe = "..."]`. Rename that too.
This commmit is a pure rename and does not change any functionality.
The `FLAG_` part of `ON_BROKEN_PIPE_FLAG_USED` comes from that the
compiler flag `-Zon-broken-pipe=...` is used to enable the feature.
Remove the `FLAG_` part so the name works both for the flag
`-Zon-broken-pipe=...` and for the upcoming Externally Implementable
Item `#[std::io::on_broken_pipe]`. This makes the diff of that PR
smaller.
The local variable name `sigpipe_attr_specified` comes from way back
when the feature was controlled with an `fn main()` attribute called
`#[unix_sigpipe = "..."]`. Rename that too.
Fix set_times_nofollow for directory on windows
Fix issue from:
https://github.com/rust-lang/rust/issues/147455#issuecomment-3841311858
old code `opts.write(true)` on Windows requests `GENERIC_WRITE` access, replace with `opts.access_mode(c::FILE_WRITE_ATTRIBUTES)` to get minimal permission.
r? @joshtriplett
This addresses the need for clarification brought up in an issue.
Specifically, it notes that some implementations may choose to panic if
they detect deadlock situations during recursive locking attempts for
both `read()` and `write()` calls.
* Provide an example highlighting that multiple read locks can be
held across different threads simultaneously.
* Remove the example that shows a situation that can potentially deadlock.
(as demonstrated in the very same documentation a few paragraphs
above)
* Improve documentation regarding the possibility of panics during
recursive read or write lock attempts.
Issues: Ambiguity in RwLock documentation about multiple read() calls...
Signed-off-by: Henner Zeller <h.zeller@acm.org>
fN::BITS constants for feature float_bits_const
Also enables the feature for compiler_builtins as otherwise this causes a warning and conflicts with the Float extension trait.
---
Implementation for rust-lang/rust#151073
Feature flag: `#![feature(float_bits_const)]`
Note that this is likely to conflict with some extension traits, as it has with compiler builtins. However, assuming correct values for the constants, they are either `u32`, the same type, which should not cause a problem (as shown by enabling the feature for compiler_builtins), or a different type (e.g. `usize`), which should cause a compiler error. Either way this should never change behaviour unless the extension trait implemented an incorrect value.
Also note that it doesn't seem to be possible to put multiple unstable attributes on an item, so `f128::BITS` and `f16::BITS` are gated behind the feature flags for those primitives, rather than `#![feature(float_bits_const)]`
