According to
https://discourse.llvm.org/t/rfc-volatile-access-to-non-dereferenceable-memory-may-be-well-defined/86303/4,
LLVM allows volatile operations on null and handles it correctly. This
should be allowed in Rust as well, because I/O memory may be hard-coded
to address 0 in some cases, like the AVR chip ATtiny1626.
A test case that ensured a failure when passing null to volatile was
removed, since it's now valid.
Due to the addition of `maybe_is_aligned` to `ub_checks`,
`maybe_is_aligned_and_not_null` was refactored to use it.
docs: revise restrictions on volatile operations
A distinction between usage on Rust memory vs. non-Rust memory was
introduced. Documentation was reworded to explain what that means, and
make explicit that:
- No trapping can occur from volatile operations;
- On Rust memory, all safety rules must be respected;
- On Rust memory, the primary difference from regular access is that
volatile always involves a memory dereference;
- On Rust memory, the only data affected by an operation is the one
pointed to in the argument(s) of the function;
- On Rust memory, provenance follows the same rules as non-volatile
access;
- On non-Rust memory, any address known to not contain Rust memory is
valid (including 0 and usize::MAX);
- On non-Rust memory, no Rust memory may be affected (it is implicit
that any other non-Rust memory may be affected, though, even if not
referenced by the pointer). This should be relevant when, for example,
reading register A causes a flag to change in register B, or writing
to A causes B to change in some way. Everything affected mustn't be
inside an allocation.
- On non-Rust memory, provenance is irrelevant and a pointer with none
can be used in a valid way.
fix: don't lint null as UB for volatile
Also remove a now-unneeded `allow` line.
fix: additional wording nits
Make slice comparisons const
This needed a fix for `derive_const`, too, as it wasn't usable in libcore anymore as trait impls need const stability attributes. I think we can't use the same system as normal trait impls while `const_trait_impl` is still unstable.
r? ```@fee1-dead```
cc rust-lang/rust#143800
constify `Option` methods
r? ```````@fee1-dead```````
tracking issue: rust-lang/rust#143956
these unblock making `PartialOrd` and `Ord` const without resorting to inlining some of these at call sites.
Trim `BorrowedCursor` API
This PR removes some method from the unstable `BorrowedCursor` type. A rational for each change can be found in the message of each commit.
I don't think that an ACP is required for this, please tell me if it is not the case.
Cc rust-lang/rust#78485rust-lang/rust#117693
Constify `Index` traits
tracking issue: rust-lang/rust#143775
the `SliceIndex` trait cannot be implemented by users as it is sealed. While it would be useful for the `get` method on slices, it seems weird to have a feature gate for that that isn't also gating index syntax at the same time, so I put them under the same feature gate.
r? ```````@fee1-dead```````
wrapping shift: remove first bitmask and table
```rust
#[inline(always)]
pub const fn wrapping_shl(self, rhs: u32) -> Self {
// SAFETY: the masking by the bitsize of the type ensures that we do not shift
// out of bounds
unsafe {
self.unchecked_shl(rhs & (Self::BITS - 1))
}
}
```
already does the bitmask, so it seems unnecessary here.
More context: internals.rust-lang.org/t/wrapping-shift-operator-code-doing-bitmasking-twice/23167
update `cfg_select!` documentation
tracking issue: https://github.com/rust-lang/rust/issues/115585
After rust-lang/rust#143461, and with an eye on a soon(ish) stabilization, I think the docs need some work.
The existing text read more like a motivation for the feature existing to me, so I've tried to now be a bit more descriptive. Still, suggestions are very welcome.
I also added a test for an empty `select! {}` because it's just the sort of thing that might break.
r? ``@traviscross``
core: Add `BorrowedCursor::with_unfilled_buf`
Implementation of https://github.com/rust-lang/libs-team/issues/367.
This mainly adds `BorrowedCursor::with_unfilled_buf`, with enables using the unfilled part of a cursor as a `BorrowedBuf`.
Note that unlike the ACP, `BorrowedCursor::unfilled_buf` was moved to a `From` conversion. This is more consistent with other ways of creating a `BorrowedBuf` and hides a bit this conversion that requires unsafe code to be used correctly.
Cc rust-lang/rust#78485rust-lang/rust#117693
Updates to random number generation APIs
Updates based on discussions about random number generation.
- Add comment on `RandomSource::fill_bytes` about multiple calls, to allow
efficient implementations for random sources that generate a word at a time.
- Drop the `Random` trait in favor of `Distribution<T>`, which will let people
make calls like random(1..=6), and which allows for future expansion to
non-uniform distributions, as well as floating-point. (For now, this is only
implemented for `RangeFull`, to get the interface in place. Subsequent PRs
will implement it for other range types.)
make `cfg_select` a builtin macro
tracking issue: https://github.com/rust-lang/rust/issues/115585
This parses mostly the same as the `macro cfg_select` version, except:
1. wrapping in double brackets is no longer supported (or needed): `cfg_select {{ /* ... */ }}` is now rejected.
2. in an expression context, the rhs is no longer wrapped in a block, so that this now works:
```rust
fn main() {
println!(cfg_select! {
unix => { "foo" }
_ => { "bar" }
});
}
```
3. a single wildcard rule is now supported: `cfg_select { _ => 1 }` now works
I've also added an error if none of the rules evaluate to true, and warnings for any arms that follow the `_` wildcard rule.
cc `@traviscross` if I'm missing any feature that should/should not be included
r? `@petrochenkov` for the macro logic details
constify `From` and `Into`
tracking issue rust-lang/rust#143773
r? ``````@fee1-dead``````
I did not mark any impls elsewhere as `const`, those can happen on their own timeframe and don't need to be part of this MVP. But if there are some core ones you think should be in there I'll happily add them, just couldn't think of any
New tracking issues for const_ops and const_cmp
Let's do a clean start with new tracking issues to avoid mixing things up with the previous constification.
I assume the fact that the `PartialEq` *trait* and *impls* used different feature names was a mistake (the feature name on the impl is entirely irrelevant anyway).
Part of https://github.com/rust-lang/rust/issues/143800, https://github.com/rust-lang/rust/issues/143802
r? ``@oli-obk``
This will let people make calls like random(1..=6), and allows for
future expansion to non-uniform distributions, as well as
floating-point.
For now, this is only implemented for `RangeFull`, to get the interface
in place. Subsequent commits will implement it for other range types.
Constify `Fn*` traits
r? `@compiler-errors` `@fee1-dead`
this should unlock a few things. A few `const_closures` tests have broken even more than before, but that feature is marked as incomplete anyway
cc rust-lang/rust#67792
docs: document trait upcasting rules in `Unsize` trait
The trait upcasting feature stabilized in 1.86 added new `Unsize` implementation, but this wasn't reflected in the trait's documentation.
