No longer require that we prove that the predicates of aliases hold when
checking the well-formedness of the alias. This permits more uses of GATs
and changes the output of yet more tests.
For sizedness, default and auto trait predicates, now prefer non-param
candidates if any exist. As these traits do not have generic parameters,
it never makes sense to prefer an non-alias candidate, as there can
never be a more permissive candidate.
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.
Based on
https://github.com/rust-lang/rust-clippy/pull/15520#discussion_r2372599748,
with the following changes/additions:
- No longer use the `Trait` enum for quickly filtering out irrelevant
impls -- instead, check the `trait_of` basically right away:
1. pre-fetch `DefId`s of the relevant traits into the lint pass
2. reuse `cx.tcx.impl_trait_ref`'s output for the the `DefId` of the
trait being implemented
3. compare those `DefId`s, which should be very cheap
- Next, check whether `self_ty` implements the other relevant trait.
- Pre-filter impl items in the same (lazy) iterator, but delay the
proc-macro check as much as possible
changelog: none
Not auto-assigning since @blyxyas and/or @Jarcho will be the ones
reviewing it:
r? ghost
Resolvesrust-lang/rust-clippy#15780.
I didn't get any feedback on that issue. So I hope it is okay that I
charged ahead and addressed it.
changelog: Allow `explicit_write` in tests
The way clippy checked for SAFETY comments above attributes was wrong:
- It wasn't considered for items
- It cause an ICE with some attributes
- When considering comments above attributes, it didn't considered
comments below them, causing some unlintable situations.
This PR tries to fix this by delegating the skipping of attributes to
the function analyzing the source code itself.
changelog: [`unnecessary_safety_comment`]: Taking into account comments
above attributes for items
Fixesrust-lang/rust-clippy#14555Fixesrust-lang/rust-clippy#15684Fixesrust-lang/rust-clippy#15754
improve coverage
Considering comments above attributes for items
Fixed the ICE and safety comments between attributes
- No longer using attr.span()
- ignoring attributes manually
Improve error messages on unsafe fns
This lint aims at detecting unusual names used in Clippy source code,
such as `appl` or `application` for a `rustc_errors::Applicability`
variable, instead of `app` and `applicability` which are commonly used
throughout Clippy.
This helps maintaining the consistency of the Clippy source code.
It is currently implemented for:
- `Applicability`: `app` or `applicability`
- `EarlyContext`/`LateContext`: `cx`
- `TyCtxt`: `tcx`
changelog: none
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
