| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#141076 (fix Zip unsoundness (again))
- rust-lang/rust#142444 (adding run-make test to autodiff)
- rust-lang/rust#143704 (Be a bit more careful around exotic cycles in in the inliner)
- rust-lang/rust#144073 (Don't test panic=unwind in panic_main.rs on Fuchsia)
- rust-lang/rust#144083 (miri sleep tests: increase slack)
- rust-lang/rust#144092 (bootstrap: Detect musl hosts)
- rust-lang/rust#144098 (Do not lint private-in-public for RPITIT)
- rust-lang/rust#144103 (Rename `emit_unless` to `emit_unless_delay`)
- rust-lang/rust#144108 (Ignore tests/run-make/link-eh-frame-terminator/rmake.rs when cross-compiling)
- rust-lang/rust#144115 (fix outdated comment)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
fix Zip unsoundness (again)
Some history: The Zip TrustedRandomAccess specialization has tried to emulate the side-effects of the naive implementation for a long time, including backwards iteration. #82292 tried to fix unsoundness (#82291) in that side-effect-preservation code, but this introduced some panic-safety unsoundness (#86443), but the fix #86452 didn't fix it for nested Zip iterators (#137255).
Rather than piling yet another fix ontop of this heap of fixes this PR reduces the number of cases in which side-effects will be preserved; the necessary API guarantee change was approved in #83791 but we haven't made use of that so far.
fixes #137255
|
|
|
|
so that we get more parallelism out of cargo
|
|
|
|
|
|
`intrinsic-test`: combine C files for faster compilation
|
|
`stdarch-test`: various cleanups
|
|
|
|
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: 82310651b93a594a3fd69015e1562186a080d94c
Filtered ref: e13c0be8f13737c64082b89ce834546079767ac4
This merge was created using https://github.com/rust-lang/josh-sync.
|
|
This updates the rust-version file to 82310651b93a594a3fd69015e1562186a080d94c.
|
|
Fix the return type of `memcmp` and `bcmp` builtin functions on targets
with a `c_int` other than `i32`.
Linked issue: https://github.com/rust-lang/rust/issues/144076
|
|
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`.
|
|
stabilize `const_slice_reverse`
cc rust-lang/rust#135120, needs FCP.
|
|
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
|
|
loongarch: Mark partial intrinsics as safe
|
|
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.
|
|
|
|
|
|
|
|
madhav-madhusoodanan/intrinsic-test-box-removing-and-more
`intrinsic-test`: Implemented DerefMut for ArmIntrinsicTest
|
|
`intrinsic-test`: streamline c compilation
|
|
Check that the checked-in version of `stdarch-gen-{arm, loongarch}` is up-to-date
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Also make it *only* usable on nightly
|
|
|
|
|
|
Match the new CI-created PRs:
https://github.com/rust-lang/compiler-builtins/pull/974.
|
|
|
|
```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
|
|
Remove deprecated `Error::description` impl from `c_str::FromBytesWithNulError`
|
|
|
|
Update poison.rs
Typo in word "below" previously "bellow"
|
|
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#78485 rust-lang/rust#117693
|
|
Fixed a core crate compilation failure when enabling the `optimize_for_size` feature on some targets
This fixes rust-lang/rust#143804.
|
|
r=RalfJung,fee1-dead
add `const_make_global`; err for `const_allocate` ptrs if didn't call
Implements as discussed on Zulip: [#t-compiler/const-eval > const heap](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/const.20heap/with/527125421)
r? ```@rust-lang/wg-const-eval```
Fixes https://github.com/rust-lang/rust/issues/129233
|
|
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.
Closes rust-lang/rust#143530
|
|
|
|
|
