This alias was added in 9897bfb8a ("Fix memset arguments for MSP430
target"), which predates `core::ffi`. Now that it exists we can just use
`core::ffi::c_int`.
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
docs(alloc::fmt): Make type optional, instead of matching empty string
Think this is clearer.
Noticed as I was implementing [`tree-sitter-rust-format-args`](https://github.com/nik-rev/tree-sitter-rust-format-args), and attempting to match the empty string results in an error.
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.
```text
warning: function `f32_to_bits` is never used
--> libm/src/math/support/float_traits.rs:367:14
|
367 | pub const fn f32_to_bits(x: f32) -> u32 {
| ^^^^^^^^^^^
|
= note: `#[warn(dead_code)]` on by default
warning: function `f64_to_bits` is never used
--> libm/src/math/support/float_traits.rs:381:14
|
381 | pub const fn f64_to_bits(x: f64) -> u64 {
| ^^^^^^^^^^^
warning: `libm` (lib) generated 2 warnings
```
This is a false positive, see RUST-144060.
update to literal-escaper-0.0.5
Quoting from the changelog, this version brings:
- Use `NonZero<char/u8>` in `unescape_c_str` and `check_raw_c_str` to statically exclude nuls
- Add `#[inline]` to small functions for improved performance
Linting public reexport of private dependencies
Part of public/private dependencies rust-lang/rust#44663
Partially addresses rust-lang/rust#71043
I'm adding a warning for reexports of private dependencies into `rustc_resolve`. I get that this should not be a warning, but should instead be a lint to be controlled by the feature gate, but I did not figure out how exactly to do that at that point. I tried doing the same thing as is done in `rustc_privacy`, but the linting system is not ready yet as far as I understand the error I got, so I made a warning for now instead. Some guidance on how to emit lints with `dcx` would be appreciated.
This also sets the `std_detect` crate as a public dependency of `std` because some macros are reexported from there. I did not check closer, but the other option may be to allow the specific reexports instead.
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
UWP: link ntdll functions using raw-dylib
Lazy loading isn't necessary so there's no need for the added complexity and overhead. However, it may be that people using UWP rust libraries don't have the necessary import libraries linked by Visual Studio so this uses raw-dylib, which allows linking to DLL functions without having an import library. This is a somewhat temporary situation as raw-dylib is intended to eventually be the default for all imports. When that happens, this special case can be removed.
Closesrust-lang/rust#143530
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```````
Move several float tests to floats/mod.rs
This PR moves several tests to `floats/mod.rs`, as discussed in https://github.com/rust-lang/rust/issues/141726. The tests moved are:
- `test_num_f*`
- `test_infinity`
- `test_neg_infinity`
- `test_zero`
- `test_neg_zero`
- `test_one`
- `test_is_nan`
- `test_is_infinite`
- `test_is_finite`
- `test_is_normal`
- `test_classify`
Each test is its own commit, so it may be easiest to review each commit individually.
r? tgross35
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
