resolve: Always resolve visibilities on impl items
Fixes https://github.com/rust-lang/rust/issues/64705.
Similarly to https://github.com/rust-lang/rust/pull/67106 this was an issue with visitor discipline.
Impl items were visited as a part of visiting `ast::ItemKind::Impl`, but they should be visit-able in isolation from their parents as well, because that's how they are visited when they are expanded from macros.
I've checked that all the remaining `resolve_visibility` calls are used correctly.
r? @matthewjasper
Fix `-Z print-type-sizes`'s handling of zero-sized fields.
Currently, the type `struct S { x: u32, y: u32, tag: () }` is
incorrectly described like this:
```
print-type-size type: `S`: 8 bytes, alignment: 4 bytes
print-type-size field `.x`: 4 bytes
print-type-size field `.tag`: 0 bytes, offset: 0 bytes, alignment: 1 bytes
print-type-size padding: 4 bytes
print-type-size field `.y`: 4 bytes, alignment: 4 bytes
```
Specifically:
- The `padding` line is wrong. (There is no padding.)
- The `offset` and `alignment` on the `.tag` line shouldn't be printed.
The problem is that multiple fields can end up with the same offset, and
the printing code doesn't handle this correctly.
This commit fixes it by adjusting the field sorting so that zero-sized fields
are dealt with before non-zero-sized fields. With that in place, the
printing code works correctly.
The commit also corrects the "something is very wrong" comment.
The new output looks like this:
```
print-type-size type: `S`: 8 bytes, alignment: 4 bytes
print-type-size field `.tag`: 0 bytes
print-type-size field `.x`: 4 bytes
print-type-size field `.y`: 4 bytes
```
r? @pnkfelix
Fix `unused_parens` triggers on macro by example code
Fix#66295
Unfortunately this does also break [an existing test](4787e97475/src/test/ui/lint/issue-47775-nested-macro-unnecessary-parens-arg.rs (L22)). I'm not sure how to handle that, because that seems to be quite similar to the allowed cases
If this gets accepted it would be great to backport this fix to beta.
Remove uniform array move MIR passes
This PR fixes a number of bugs caused by limitations of this pass
* Projections from constant indexes weren't being canonicalized
* Constant indexes from the start weren't being canonicalized (they could have different min_lengths)
* It didn't apply to non-moves
This PR makes the following changes to support removing this pass:
* ConstantIndex of arrays are now generated in a canonical form (from the start, min_length is the actual length).
* Subslices are now split when generating move paths and when checking subslices have been moved.
Additionally
* The parent move path of a projection from an array element is now calculated correctly
closes#66502
async/await: improve not-send errors, part 2
Part of #64130. Fixes#65667.
This PR improves the errors introduced in #64895 so that they have specialized messages for `Send` and `Sync`.
r? @nikomatsakis
rustc: allow non-empty ParamEnv's in global trait select/eval caches.
*Based on #66963*
This appears to alleviate the symptoms of #65510 locally (without fixing WF directly), and is potentially easier to validate as sound (since it's a more ad-hoc version of queries we already have).
I'm opening this PR primarily to test the effects on perf.
r? @nikomatsakis cc @rust-lang/wg-traits
Add options to --extern flag.
This changes the `--extern` flag so that it can take a series of options that changes its behavior. The general syntax is `[opts ':'] name ['=' path]` where `opts` is a comma separated list of options. Two options are supported, `priv` which replaces `--extern-private` and `noprelude` which avoids adding the crate to the extern prelude.
```text
--extern priv:mylib=/path/to/libmylib.rlib
--extern noprelude:alloc=/path/to/liballoc.rlib
```
`noprelude` is to be used by Cargo's build-std feature in order to use `--extern` to reference standard library crates.
This also includes a second commit which adds the `aux-crate` directive to compiletest. I can split this off into a separate PR if desired, but it helps with defining these kinds of tests. It is based on #54020, and can be used in the future to replace and simplify some of the Makefile tests.
Fix constant propagation for scalar pairs
We now only propagate a scalar pair if the Rvalue is a tuple with two scalars. This for example avoids propagating a (u8, u8) value when Rvalue has type `((), u8, u8)` (see the regression test). While this is a correct thing to do, implementation is tricky and will be done later.
Fixes#66971Fixes#66339Fixes#67019
Optimize Ord trait implementation for bool
Casting the booleans to `i8`s and converting their difference into `Ordering` generates better assembly than casting them to `u8`s and comparing them.
Fixes#66780
#### Comparison([Godbolt link](https://rust.godbolt.org/z/PjBpvF))
##### Old assembly:
```asm
example::boolean_cmp:
mov ecx, edi
xor ecx, esi
test esi, esi
mov eax, 255
cmove eax, ecx
test edi, edi
cmovne eax, ecx
ret
```
##### New assembly:
```asm
example::boolean_cmp:
mov eax, edi
sub al, sil
ret
```
##### Old LLVM-MCA statistics:
```
Iterations: 100
Instructions: 800
Total Cycles: 234
Total uOps: 1000
Dispatch Width: 6
uOps Per Cycle: 4.27
IPC: 3.42
Block RThroughput: 1.7
```
##### New LLVM-MCA statistics:
```
Iterations: 100
Instructions: 300
Total Cycles: 110
Total uOps: 500
Dispatch Width: 6
uOps Per Cycle: 4.55
IPC: 2.73
Block RThroughput: 1.0
```
Currently, the type `struct S { x: u32, y: u32, tag: () }` is
incorrectly described like this:
```
print-type-size type: `S`: 8 bytes, alignment: 4 bytes
print-type-size field `.x`: 4 bytes
print-type-size field `.tag`: 0 bytes, offset: 0 bytes, alignment: 1 bytes
print-type-size padding: 4 bytes
print-type-size field `.y`: 4 bytes, alignment: 4 bytes
```
Specifically:
- The `padding` line is wrong. (There is no padding.)
- The `offset` and `alignment` on the `.tag` line shouldn't be printed.
The problem is that multiple fields can end up with the same offset, and
the printing code doesn't handle this correctly.
This commit fixes it by adjusting the field sorting so that zero-sized fields
are dealt with before non-zero-sized fields. With that in place, the
printing code works correctly.
The commit also corrects the "something is very wrong" comment.
The new output looks like this:
```
print-type-size type: `S`: 8 bytes, alignment: 4 bytes
print-type-size field `.tag`: 0 bytes
print-type-size field `.x`: 4 bytes
print-type-size field `.y`: 4 bytes
```
Ensure that we get a hard error on generic ZST constants if their bod…
…y causes an error during evaluation
cc #67083 (does not fix because we still need the beta backport)
r? @wesleywiser
cc @RalfJung
Use deref target in Pin trait implementations
Using deref target instead of pointer itself avoids providing access to `&Rc<T>` for malicious implementations, which would allow calling `Rc::get_mut`.
This is a breaking change necessary due to unsoundness, however the impact of it should be minimal.
This only fixes the issue with malicious `PartialEq` implementations, other `Pin` soundness issues are still here.
See <https://internals.rust-lang.org/t/unsoundness-in-pin/11311/73> for more details.
These passes were buggy, MIR building is now responsible for
canonicalizing `ConstantIndex` projections and `MoveData` is responsible
for splitting `Subslice` projections.
