The thumbv6m target does not support atomics. Historically, LLVM
had a bug where atomic load/stores for this target were emitted
as plain load/stores rather than as libatomic calls. This was
fixed in https://reviews.llvm.org/D120026, which will be part of
LLVM 15. As we require that "atomic support" does not use libatomic,
we need to indicate that this target does not have native atomics.
Improve suggestions for returning binding
Fixes#99525
Also reworks the cause codes for match and if a bit, I think cleaning them up in a positive way.
We no longer need to call `could_remove_semicolon` in successful code, which might save a few cycles?
Fix unreachable coverage generation for inlined functions
To generate a function coverage we need at least one coverage counter,
so a coverage from unreachable blocks is retained only when some live
counters remain.
The previous implementation incorrectly retained unreachable coverage,
because it didn't account for the fact that those live counters can
belong to another function due to inlining.
Fixes#98833.
Rename `<*{mut,const} T>::as_{const,mut}` to `cast_`
This renames the methods to use the `cast_` prefix instead of `as_` to
make it more readable and avoid confusion with `<*mut T>::as_mut()`
which is `unsafe` and returns a reference.
Sorry, didn't notice ACP process exists, opened https://github.com/rust-lang/libs-team/issues/51
See #92675
make vtable pointers entirely opaque
This implements the scheme discussed in https://github.com/rust-lang/unsafe-code-guidelines/issues/338: vtable pointers should be considered entirely opaque and not even readable by Rust code, similar to function pointers.
- We have a new kind of `GlobalAlloc` that symbolically refers to a vtable.
- Miri uses that kind of allocation when generating a vtable.
- The codegen backends, upon encountering such an allocation, call `vtable_allocation` to obtain an actually dataful allocation for this vtable.
- We need new intrinsics to obtain the size and align from a vtable (for some `ptr::metadata` APIs), since direct accesses are UB now.
I had to touch quite a bit of code that I am not very familiar with, so some of this might not make much sense...
r? `@oli-obk`
move `considering_regions` to the infcx
it seems weird to prove some obligations which constrain inference vars while ignoring regions in a context which considers regions. This is especially weird because even for a fulfillment context with ignored regions, we still added region outlives bounds when directly relating regions.
tbh our handling of regions is still very weird, but at least this is a step in the right direction imo.
r? rust-lang/types
Rollup of 11 pull requests
Successful merges:
- #98707 (std: use futex-based locks on Fuchsia)
- #99413 (Add `PhantomData` marker for dropck to `BTreeMap`)
- #99454 (Add map_continue and continue_value combinators to ControlFlow)
- #99523 (Fix the stable version of `AsFd for Arc<T>` and `Box<T>`)
- #99526 (Normalize the arg spans to be within the call span)
- #99528 (couple of clippy::perf fixes)
- #99549 (Add regression test for #52304)
- #99552 (Rewrite `orphan_check_trait_ref` to use a `TypeVisitor`)
- #99557 (Edit `rustc_index::vec::IndexVec::pick3_mut` docs)
- #99558 (Fix `remap_constness`)
- #99559 (Remove unused field in ItemKind::KeywordItem)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove unused field in ItemKind::KeywordItem
For the keyword name, we use `Item::name` directly everywhere so there is no point into keeping it.
r? ``@notriddle``
Fix the stable version of `AsFd for Arc<T>` and `Box<T>`
These merged in #97437 for 1.64.0, apart from the main `io_safety`
feature that stabilized in 1.63.0.
std: use futex-based locks on Fuchsia
This switches `Condvar` and `RwLock` to the futex-based implementation currently used on Linux and some BSDs. Additionally, `Mutex` now has its own, priority-inheriting implementation based on the mutex in Fuchsia's `libsync`. It differs from the original in that it panics instead of aborting when reentrant locking is detected.
````@rustbot```` ping fuchsia
r? ````@m-ou-se````
This renames the methods to use the `cast_` prefix instead of `as_` to
make it more readable and avoid confusion with `<*mut T>::as_mut()`
which is `unsafe` and returns a reference.
See #92675
Otherwise, fall back to the multi ABI scheme, except in testing, where
it becomes a hard error.
This should make it possible to use a rustup-provided rust-analyzer with
proc macro dylibs compiled by older rustcs, and it'll also catch changes
to the format of `rustc --version` or the `.rustc` section that would
make them impossible to compare for equality.
