-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 9 pull requests #107578
Rollup of 9 pull requests #107578
Conversation
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 }) ```
…lated commits Revert "review comment: Remove AST AnonTy" This reverts commit 020cca8. Revert "Ensure macros are not affected" This reverts commit 12d18e4. Revert "Emit fewer errors on patterns with possible type ascription" This reverts commit c847a01. Revert "Teach parser to understand fake anonymous enum syntax" This reverts commit 2d82420.
…-field-pat, r=jackh726 Recover `_` as `..` in field pattern
…ed-ios-macbi-target-version, r=wesleywiser 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 rust-lang#96392, inspired by rust-lang/cc-rs#727
…-note, r=estebank 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.
…ambiguous, r=estebank 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 rust-lang#107461 cc: `@estebank` `@cjgillot` rust-lang#106960 --- ### Squashed revert commits: Revert "review comment: Remove AST AnonTy" This reverts commit 020cca8. Revert "Ensure macros are not affected" This reverts commit 12d18e4. Revert "Emit fewer errors on patterns with possible type ascription" This reverts commit c847a01. Revert "Teach parser to understand fake anonymous enum syntax" This reverts commit 2d82420.
…r=RalfJung 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`
…, r=estebank Improve diagnostic for missing space in range pattern Improves the diagnostic in rust-lang#107425 by turning it into a note explaining the parsing issue. r? `@compiler-errors`
…s, r=notriddle Inline CSS background images directly into the CSS A nice advantage of this is that it removes a few entries in the list of static files. r? `@notriddle`
Rename `rust_2015` → `is_rust_2015` r? `@compiler-errors` rust-lang#107508 (comment)
Add proc-macro boilerplate to crt-static test I was seeing this failure when running ui tests with with a `-Cpanic=abort` stdlib targeting fuchsia: ``` ---- [ui] tests/ui/proc-macro/crt-static.rs stdout ---- normalized stderr: warning: building proc macro crate with `panic=abort` may crash the compiler should the proc-macro panic warning: 1 warning emitted The actual stderr differed from the expected stderr. ``` `force-host` was enough to stop it from running/failing, not sure if I should also add `needs-unwind`?
@bors r+ rollup=never p=9 |
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message
|
☔ The latest upstream changes (presumably #105670) made this pull request unmergeable. Please resolve the merge conflicts. |
Successful merges:
_
as..
in field pattern #106919 (Recover_
as..
in field pattern)-Zunpretty-expanded
output for derivedPartialEq
. #107488 (Fix syntax in-Zunpretty-expanded
output for derivedPartialEq
.)rust_2015
→is_rust_2015
#107559 (Renamerust_2015
→is_rust_2015
)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup