Polonius liveness has to contain boring locals, and we ignore them in
diagnostics to match NLL diagnostics, since they doesn't contain boring locals.
We ignored these when explaining why a loan contained a point due to
a use of a live var, but not when it contained a point due to a drop of
a live var.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#146841 (Stabilise `rotate_left` and `rotate_right` in `[_]` as `const fn` items.)
- rust-lang/rust#146949 (Add vsx register support for ppc inline asm, and implement preserves_flag option)
- rust-lang/rust#147539 (resolve: Use primitives for conditional mutability more consistently)
- rust-lang/rust#147685 (remove span calls from deprecated attribute checking)
- rust-lang/rust#147699 (Clairify docs for `AttributeKind::DocComment`)
- rust-lang/rust#147706 (Add myself to review rotation)
- rust-lang/rust#147711 (Clarify that UB will occur, not can/may in GlobalAlloc docs)
r? `@ghost`
`@rustbot` modify labels: rollup
Clarify that UB will occur, not can/may in GlobalAlloc docs
These doc comments start out very clear by saying the caller "must" or "has to" ensure something, but the end with some form of "otherwise undefined behavior may result" which sounds like it is implementation-defined and seems to conflict with the way the paragraph starts. Consistent phrasing makes it clearer that when the safety precondition is violated, UB is encountered.
Some of the phrasing here is a bit awkward to me, I don't think we usually say "the behavior is undefined" `@RalfJung` right? But in either case I'm trying to be surgical in my edit here.
r? Amanieu
Clairify docs for `AttributeKind::DocComment`
Makes it clear that this represents `#[doc = "content"]`, but not `#[doc(hidden)]` (or other uses of the `#[doc(...)]` attribute).
r? `@jdonszelmann`
resolve: Use primitives for conditional mutability more consistently
No bare `(Ref)Cell`s remain in `rustc_resolve`, only `Cm(Ref)Cell`s checking that nothing is modified during speculative resolution, and `Cache(Ref)Cell` aliases for cells that need to be migrated to mutexes/atomics.
cc `@LorrensP-2158466`
Add vsx register support for ppc inline asm, and implement preserves_flag option
This should address the last(?) missing pieces of inline asm for ppc:
* Explicit VSX register support. ISA 2.06 (POWER7) added a 64x128b register overlay extending the fpr's to 128b, and unifies them with the vmx (altivec) registers. Implementations details within gcc/llvm percolate up, and require using the `x` template modifier. I have updated the inline asm to implicitly include this for vsx arguments which do not specify it. ~~Support for the gcc codegen backend is still a todo.~~
* Implement the `preserves_flags` option. All ABI's, and all ISAs store their flags in `cr`, and the carry bit lives inside `xer`. The other status registers hold sticky bits or control bits which do not affect branch instructions.
There is some interest in the e500 (powerpcspe) port. Architecturally, it has a very different FP ISA, and includes a simd extension called SPR (which is not IBM's cell SPE). Notably, it does not have altivec/fpr/vsx registers. It also has an SPE accumulator register which its ABI marks as volatile, but I am not sure if the compiler uses it.
only check duplicates on old/unparsed attributes
r? ``@JonathanBrouwer``
This was effectively already what we were doing, but this was implicit because `.name()` etc were just returning None when dealing with a parsed attribute.... this makes it explicit
Move computation of allocator shim contents to cg_ssa
In the future this should make it easier to use weak symbols for the allocator shim on platforms that properly support weak symbols. And it would allow reusing the allocator shim code for handling default implementations of the upcoming externally implementable items feature on platforms that don't properly support weak symbols.
In addition to make this possible, the alloc error handler is now handled in a way such that it is possible to avoid using the allocator shim when liballoc is compiled without `no_global_oom_handling` if you use `#[alloc_error_handler]`. Previously this was only possible if you avoided liballoc entirely or compiled it with `no_global_oom_handling`. You still need to avoid libstd and to define the symbol that indicates that avoiding the allocator shim is unstable.
std: improve handling of timed condition variable waits on macOS
Fixesrust-lang/rust#37440 (for good).
This fixes two issues with `Condvar::wait_timeout` on macOS:
Apple's implementation of `pthread_cond_timedwait` internally converts the absolute timeout to a relative one, measured in nanoseconds, but fails to consider overflow when doing so. This results in `wait_timeout` returning much earlier than anticipated when passed a duration that is slightly longer than `u64::MAX` nanoseconds (around 584 years). The existing clamping introduced by rust-lang/rust#42604 to address rust-lang/rust#37440 unfortunately used a maximum duration of 1000 years and thus still runs into the bug when run on older macOS versions (or with `PTHREAD_MUTEX_USE_ULOCK` set to a value other than "1"). See https://github.com/rust-lang/rust/issues/37440#issuecomment-3285958326 for context.
Reducing the maximum duration alone however would not be enough to make the implementation completely correct. As macOS does not support `pthread_condattr_setclock`, the deadline passed to `pthread_cond_timedwait` is measured against the wall-time clock. `std` currently calculates the deadline by retrieving the current time and adding the duration to that, only for macOS to convert the deadline back to a relative duration by [retrieving the current time itself](1ebf56b3a7/src/pthread_cond.c (L802-L819)) (this conversion is performed before the aforementioned problematic one). Thus, if the wall-time clock is adjusted between the `std` lookup and the system lookup, the relative duration could have changed, possibly even to a value larger than $2^{64}\ \textrm{ns}$. Luckily however, macOS supports the non-standard, tongue-twisting `pthread_cond_timedwait_relative_np` function which avoids the wall-clock-time roundtrip by taking a relative timeout. Even apart from that, this function is perfectly suited for `std`'s purposes: it is public (albeit badly-documented) API, [available since macOS 10.4](1ebf56b3a7/include/pthread/pthread.h (L555-L559)) (that's way below our minimum of 10.12) and completely resilient against wall-time changes as all timeouts are [measured against the monotonic clock](e3723e1f17/bsd/kern/sys_ulock.c (L741)) inside the kernel.
Thus, this PR switches `Condvar::wait_timeout` to `pthread_cond_timedwait_relative_np`, making sure to clamp the duration to a maximum of $2^{64} - 1 \ \textrm{ns}$. I've added a miri shim as well, so the only thing missing is a definition of `pthread_cond_timedwait_relative_np` inside `libc`.
Implemented preserves_flags on powerpc by making it do
nothing. This prevents having two different ways to mark
`cr0` as clobbered. clang and gcc alias `cr0` to `cc`.
The gcc inline documentation does not state what this does
on powerpc* targets, but inspection of the source shows
it is equivalent to condition register field `cr0`, so it
should not be added.
Where supported, VSX is a 64x128b register set which encompasses
both the floating point and vector registers.
In the type tests, xvsqrtdp is used as it is the only two-argument
vsx opcode supported by all targets on llvm. If you need to copy
a vsx register, the preferred way is "xxlor xt, xa, xa".
