| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
|
|
we use `std::sync::LazyLock` now.
|
|
|
|
|
|
|
|
|
|
|
|
stdarch subtree update
Subtree update of `stdarch` to https://github.com/rust-lang/stdarch/commit/5531955678494ee28ec02130a6d94082ad4532da.
Created using https://github.com/rust-lang/josh-sync.
I saw that there were non-trivial changes made to `std_detect` in `stdarch` recently. So I want to get them merged here before we move forward with https://github.com/rust-lang/rust/pull/143412.
r? `@folkertdev`
|
|
|
|
flt2dec: replace for loop by iter_mut
Perf is explored in https://github.com/rust-lang/rust/issues/144118, which initially showed small losses, but then also showed significant gains. Both are real, but given the smallness of the losses, this seems a good change.
|
|
We are getting warnings in CI about unsupported features. There isn't
any reason to use stable rustfmt so switch the channel here.
|
|
Remove the ptr_unique lang item
Miri no longer uses it since https://github.com/rust-lang/miri/pull/4307.
|
|
Constify Try, From, TryFrom and relevant traits
|
|
compiler-builtins subtree update
Subtree update of `compiler-builtins` to https://github.com/rust-lang/compiler-builtins/commit/2cdde03950e8d10d37b8d13e1c1d3ce2e54f36c4.
Created using https://github.com/rust-lang/josh-sync.
Fixes: https://github.com/rust-lang/rust/issues/144076
r? `@ghost`
|
|
On the 32-bit win7 target, we use OS TLS instead of native TLS, due to
issues with how the OS handles alignment. Unfortunately, this caused
issues due to the TLS destructors not running, causing memory leaks
among other problems.
On Windows, to support OS TLS, the TlsAlloc family of function is used
by Rust. This function does not support TLS destructors at all. However,
rust has some code to emulate those destructors, by leveraging the TLS
support functionality found in the MSVC CRT (specifically, in tlssup.c
of the CRT). Specifically, the CRT provides the ability to register
callbacks that are called (among other things) on thread destruction. By
registering our own callback, we can run through a list of registered
destructors functions to execute.
To use this functionality, the user must do two things:
1. They must put the address to their callback in a section between
`.CRT$XLB` and `.CRT$XLY`.
2. They must add a reference to `_tls_used` (or `__tls_used` on x86) to
make sure the TLS support code in tlssup.c isn't garbage collected by
the linker.
Prior to this commit, this second bit wasn't being done properly by the
Rust TLS support code. Instead of adding a reference to _tls_used, it
instead had a reference to its own callback to prevent it from getting
GC'd by the linker. While this is _also_ necessary, not having a
reference on _tls_used made the entire support non-functional.
This commit reworks the code to:
1. Add an unconditional `#[used]` attribute on the CALLBACK, which
should be enough to prevent it from getting GC'd by the linker.
2. Add a reference to `_tls_used`, which should pull the TLS support
code into the Rust programs and not let it be GC'd by the linker.
|
|
|
|
|
|
|
|
|
|
address clippy formatting nits
- int_log10.rs: change top level doc comments to outer
- collect.rs: remove empty line after doc comment
- clippy fix: markdown indentation for indented items after line break: a markdown list item continued over multiples lines, but those following lines which are part of the same item are not indented
- clippy fix: bound in one place: when there is a bound in angle brackets and another bound on the same variable in a where clause
|
|
Add `uX::strict_sub_signed`
rust-lang/rust#116090 missed `strict_sub_signed`, adding it here.
Part of rust-lang/rust#118260.
r? ``@m-ou-se``
|
|
Miri no longer uses it.
|
|
interpret: fix TypeId pointers being considered data pointers
Fixes https://github.com/rust-lang/miri/issues/4477
r? ````@oli-obk````
|
|
Remove deprecated `MaybeUninit` slice methods
These were left in to make migration a bit easier, although they should be removed now since they were never stable.
|
|
Stabilize `const_float_round_methods`
Closes rust-lang/rust#141555, waiting for FCP.
|
|
Allow volatile access to non-Rust memory, including address 0
This PR relaxes the `ub_check` in the `read_volatile`/`write_volatile` pointer operations to allow passing null. This is needed to support processors which hard-code peripheral registers on address 0, like the AVR chip ATtiny1626. LLVM understands this as valid and handles it correctly, as tested in my [PR to add a note about it](https://github.com/llvm/llvm-project/pull/139803/commits/6387c82255c56d3035d249eb54110695e76b8030#diff-81bbb96298c32fa901beb82ab3b97add27a410c01d577c1f8c01000ed2055826) (rustc generates the same LLVM IR as expected there when this PR is applied, and consequently the same AVR assembly).
Follow-up and implementation of the discussions in:
- https://internals.rust-lang.org/t/pre-rfc-conditionally-supported-volatile-access-to-address-0/12881/7
- https://github.com/Rahix/avr-device/pull/185;
- [#t-lang > Adding the possibility of volatile access to address 0](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Adding.20the.20possibility.20of.20volatile.20access.20to.20address.200/with/513303502)
- https://discourse.llvm.org/t/rfc-volatile-access-to-non-dereferenceable-memory-may-be-well-defined/86303
r? ````@RalfJung````
Also fixes https://github.com/rust-lang/unsafe-code-guidelines/issues/29 (about as good as it'll get, null will likely never be a "normal" address in Rust)
|
|
|
|
|
|
intrinsics
|
|
|
|
|
|
This mostly documents the current behavior of `Mutex` and `RwLock` as
imperfect. It's unlikely that the situation improves significantly in
the future, and even if it does, the rules will probably be more
complicated than "poisoning is completely reliable", so this is a
conservative guarantee.
We also explicitly specify that `OnceLock` never poisons, even though it
has an API similar to mutexes.
|
|
|
|
|
|
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`.
|