ast: Optimize list and value extraction primitives for attributes
It's not necessary to convert the whole attribute into a meta item to extract something specific.
Suggest `{var:?}` when finding `{?:var}` in inline format strings
Link to issue: https://github.com/rust-lang/rust/issues/106572
This is my first PR to this project, so hopefully I can get some good pointers with me from the first PR.
Currently my idea was to test out whether or not this is the correct solution to this issue and then hopefully expand upon the idea to not only work for Debug formatting but for all of them. If this is a valid solution, I will create a new issue to give a better error message to a broader range of wrong-order formatting.
Erase regions before doing uninhabited check in borrowck
~Also, fingerprint query keys/values when debug assertions are enabled. This should make it easier to check for issues like this without `-Cincremental`, and make UI tests a bit cleaner.~ edit: moving that to a separate PR
Fixes#107505
Remove both StorageLive and StorageDead in CopyProp.
Fixes https://github.com/rust-lang/rust/issues/107511https://github.com/rust-lang/rust/pull/106908 removed StorageDead without the accompanying StorageLive. In loops, execution would see repeated StorageLive, without any StorageDead, which is UB.
So when removing storage statements, we have to remove both StorageLive and StorageDead.
~I also added a MIR validation pass for StorageLive. It may be a bit overzealous.~
Improve pretty-printing of `HirIdValidator` errors
This now uses `node_to_string` for both missing and seen Ids, which includes the snippet of code for which the Id was allocated. Also removes the duplicated printing of `HirId`, as `node_to_string` also includes that.
Improve diagnostic for missing space in range pattern
Improves the diagnostic in #107425 by turning it into a note explaining the parsing issue.
r? `@compiler-errors`
Revert "Teach parser to understand fake anonymous enum syntax" and related commits
anonymous enum types are currently ambiguous in positions like:
* `|` operator: `a as fn() -> B | C`
* closure args: `|_: as fn() -> A | B`
I first tried to thread around `RecoverAnonEnum` into all these positions, but the resulting complexity in the compiler is IMO not worth it, or at least worth a bit more thinking time. In the mean time, let's revert this syntax for now, so we can go back to the drawing board.
Fixes#107461
cc: `@estebank` `@cjgillot` #106960
---
### Squashed revert commits:
Revert "review comment: Remove AST AnonTy"
This reverts commit 020cca8d36.
Revert "Ensure macros are not affected"
This reverts commit 12d18e4031.
Revert "Emit fewer errors on patterns with possible type ascription"
This reverts commit c847a01a3b.
Revert "Teach parser to understand fake anonymous enum syntax"
This reverts commit 2d82420665.
Revert "review comment: Remove AST AnonTy"
This reverts commit 020cca8d36.
Revert "Ensure macros are not affected"
This reverts commit 12d18e4031.
Revert "Emit fewer errors on patterns with possible type ascription"
This reverts commit c847a01a3b.
Revert "Teach parser to understand fake anonymous enum syntax"
This reverts commit 2d82420665.
Fix syntax in `-Zunpretty-expanded` output for derived `PartialEq`.
If you do `derive(PartialEq)` on a packed struct, the output shown by `-Zunpretty=expanded` includes expressions like this:
```
{ self.x } == { other.x }
```
This is invalid syntax. This doesn't break compilation, because the AST nodes are constructed within the compiler. But it does mean anyone using `-Zunpretty=expanded` output as a guide for hand-written impls could get a nasty surprise.
This commit fixes things by instead using this form:
```
({ self.x }) == ({ other.x })
```
r? ``@RalfJung``
Remove confusing 'while checking' note from opaque future type mismatches
Maybe I'm just misinterpreting the wording of the note. The only value I can see in this note is that it points out where the async's opaque future is coming from, but the way it's doing it is misleading IMO.
For example:
```rust
note: while checking the return type of the `async fn`
--> $DIR/dont-suggest-missing-await.rs:7:24
|
LL | async fn make_u32() -> u32 {
| ^^^ checked the `Output` of this `async fn`, found opaque type
```
We point at the type `u32` in the HIR, but then say "found opaque type". We also say "while checking"... but we're typechecking a totally different function when we get this type mismatch!
r? ``@estebank`` but feel free to reassign and/or take your time reviewing this. I'd be inclined to also discuss reworking the presentation of this type mismatch to restore some of these labels in a way that makes it more clear what it's trying to point out.
Remove hardcoded iOS version of clang target for Mac Catalyst
## Background
From `clang` 13.x, `-target x86_64-apple-ios13.0-macabi` fails while linking:
```
= note: clang: error: invalid version number in '-target x86_64-apple-ios13.0-macabi'
```
<details>
<summary>Verbose output</summary>
```
error: linking with `cc` failed: exit status: 1
|
= note: LC_ALL="C" PATH="[removed]" VSLANG="1033" ZERO_AR_DATE="1" "cc" "-Wl,-exported_symbols_list,/var/folders/p8/qpmzbsdn07g5gxykwfxxw7y40000gn/T/rustci8tkvp/list" "-target" "x86_64-apple-ios13.0-macabi" "/var/folders/p8/qpmzbsdn07g5gxykwfxxw7y40000gn/T/rustci8tkvp/symbols.o" "/path/to/my/[project]/[user]/target/x86_64-apple-ios-macabi/release/deps/[user].[user].a2ccc648-cgu.0.rcgu.o" "-L" "/path/to/my/[project]/[user]/target/x86_64-apple-ios-macabi/release/deps" "-L" "/path/to/my/[project]/[user]/target/release/deps" "-L" "/path/to/my/[project]/[user]/target/x86_64-apple-ios-macabi/release/build/blake3-74e6ba91506ce712/out" "-L" "/path/to/my/[project]/[user]/target/x86_64-apple-ios-macabi/release/build/blake3-74e6ba91506ce712/out" "-L" "/Users/[user]/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/x86_64-apple-ios-macabi/lib" "/var/folders/p8/qpmzbsdn07g5gxykwfxxw7y40000gn/T/rustci8tkvp/libblake3-343c1616c8f62c66.rlib" "/path/to/my/[project]/[user]/target/x86_64-apple-ios-macabi/release/deps/libcompiler_builtins-15d4f20b641cf9ef.rlib" "-framework" "Security" "-framework" "CoreFoundation" "-framework" "Security" "-liconv" "-lSystem" "-lobjc" "-framework" "Security" "-framework" "Foundation" "-lc" "-lm" "-isysroot" "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk" "-Wl,-syslibroot" "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk" "-L" "/Users/[user]/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/x86_64-apple-ios-macabi/lib" "-o" "/path/to/my/[project]/[user]/target/x86_64-apple-ios-macabi/release/deps/lib[user].dylib" "-Wl,-dead_strip" "-dynamiclib" "-Wl,-dylib" "-nodefaultlibs"
= note: clang: error: invalid version number in '-target x86_64-apple-ios13.0-macabi'
warning: `[user]` (lib) generated 6 warnings
error: could not compile `[user]` due to previous error; 6 warnings emitted
```
</details>
### Minimal example
C code:
```c
#include <stdio.h>
void main() {
int a = 1;
int b = 2;
int c = a + b;
printf("%d", c);
}
```
`clang` command sample:
```
➜ 202301 clang -target x86_64-apple-ios13.0-macabi main.c
clang: error: invalid version number in '-target x86_64-apple-ios13.0-macabi'
➜ 202301 clang -target x86_64-apple-ios14.0-macabi main.c
main.c:2:1: warning: return type of 'main' is not 'int' [-Wmain-return-type]
void main() {
^
main.c:2:1: note: change return type to 'int'
void main() {
^~~~
int
1 warning generated.
➜ 202301 clang -target x86_64-apple-ios15.0-macabi main.c
main.c:2:1: warning: return type of 'main' is not 'int' [-Wmain-return-type]
void main() {
^
main.c:2:1: note: change return type to 'int'
void main() {
^~~~
int
1 warning generated.
➜ 202301 clang -target x86_64-apple-ios-macabi main.c
main.c:2:1: warning: return type of 'main' is not 'int' [-Wmain-return-type]
void main() {
^
main.c:2:1: note: change return type to 'int'
void main() {
^~~~
int
1 warning generated.
➜ 202301 clang --version
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin22.2.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
```
This PR is a simplified version of #96392, inspired by https://github.com/rust-lang/cc-rs/pull/727
The check previously matched this, and suggested adding a missing
`struct`:
pub Foo(...):
It was probably intended to match this instead (semicolon instead of
colon):
pub Foo(...);
This now uses `node_to_string` for both missing and seen Ids, which includes
the snippet of code for which the Id was allocated.
Also removes the duplicated printing of `HirId`, as `node_to_string` includes that already.
Similarly, changes all other users of `node_to_string` that do so, and changes the output of `node_to_string`, which is now "$hirid ($what `$span` in $path)".
Strengthen validation of FFI attributes
Previously, `codegen_attrs` validated the attributes `#[ffi_pure]`, `#[ffi_const]`, and `#[ffi_returns_twice]` to make sure that they were only used on foreign functions. However, this validation was insufficient in two ways:
1. `codegen_attrs` only sees items for which code must be generated, so it was unable to raise errors when the attribute was incorrectly applied to macros and the like.
2. the validation code only checked that the item with the attr was foreign, but not that it was a foreign function, allowing these attributes to be applied to foreign statics as well.
This PR moves the validation to `check_attr`, which sees all items. It additionally changes the validation to ensure that the attribute's target is `Target::ForeignFunction`, only allowing the attributes on foreign functions and not foreign statics. Because these attributes are unstable, there is no risk for backwards compatibility. The changes also ending up making the code much easier to read.
This PR is best reviewed commit by commit. Additionally, I was considering moving the tests to the `attribute` subdirectory, to get them out of the general UI directory. I could do that as part of this PR or a follow-up, as the reviewer prefers.
CC: #58328, #58329
Do not depend on Generator trait when deducing closure signature
1. Do not depend on `Generator` trait when deducing closure signature.
2. Compare the name of the `Generator::Return` associated item, rather than its order in the trait. Seems more stable this way.
Fixing confusion between mod and remainder
Like many programming languages, rust too confuses remainder and modulus. The `%` operator and the associated `Rem` trait is (as the trait name suggests) the remainder, but since most people are linguistically more familiar with the modulus the documentation sometimes claims otherwise. This PR tries to fix this problem in rustc.
If you do `derive(PartialEq)` on a packed struct, the output shown by
`-Zunpretty=expanded` includes expressions like this:
```
{ self.x } == { other.x }
```
This is invalid syntax. This doesn't break compilation, because the AST
nodes are constructed within the compiler. But it does mean anyone using
`-Zunpretty=expanded` output as a guide for hand-written impls could get
a nasty surprise.
This commit fixes things by instead using this form:
```
({ self.x }) == ({ other.x })
```
PointeeInfo is advisory only
https://github.com/rust-lang/rust/pull/107248 fixed PointeeInfo being used in ways that don't actually work. Hopefully this comments helps avoid such issues in the future.
Cc ``@eddyb``
Track bound types like bound regions
When we instantiate bound types into placeholder types, we throw away the names for some reason. These names are particularly useful for error reporting once we have `for<T>` binders.
r? types
small refactor to new projection code
extract `eq_term_and_make_canonical_response` into a helper function which also is another guarantee that the expected term does not influence candidate selection for projections.
also change `evaluate_all(vec![single_goal])` to use `evaluate_goal`.
the second commit now also adds a `debug_assert!` to `evaluate_goal`.
