Rollup of 7 pull requests
Successful merges:
- #62593 (Group all ABI tests.)
- #63173 (Use libunwind from llvm-project submodule for musl targets)
- #63535 (Continue refactoring resolve and hygiene)
- #63539 (Suggest Rust 2018 on `<expr>.await` with no such field)
- #63584 (libcore: more cleanups using `#![feature(associated_type_bounds)]`)
- #63612 (Do not suggest `try_into` for base types inside of macro expansions)
- #63615 (Fix typo in DoubleEndedIterator::nth_back doc)
Failed merges:
r? @ghost
Suggest Rust 2018 on `<expr>.await` with no such field
When type checking a field projection (`fn check_field`) to `<expr>.await` where `<expr>: τ` and `τ` is not a primitive type, suggest switching to Rust 2018. E.g.
```
error[E0609]: no field `await` on type `std::pin::Pin<&mut dyn std::future::Future<Output = ()>>`
--> $DIR/suggest-switching-edition-on-await.rs:31:7
|
LL | x.await;
| ^^^^^ unknown field
|
= note: to `.await` a `Future`, switch to Rust 2018
= help: set `edition = "2018"` in `Cargo.toml`
= note: for more on editions, read https://doc.rust-lang.org/edition-guide
```
Fixes https://github.com/rust-lang/rust/issues/63533
This PR also performs some preparatory cleanups in `fn check_field`; the last 2 commits are where the suggestion is introduced and tested respectively.
r? @varkor
Continue refactoring resolve and hygiene
The general goal is addressing FIXMEs from the previous PRs.
Merging similar data structures (+ prerequisites for such merging), accounting for the fact that all `ExpnId`s have associated data in `HygieneData` now (less `Option`s).
Also, some renaming.
This should be the last renaming session in this area, I think.
r? @matthewjasper
Currently, librustc_llvm builds are not reproducible because the LLVM
files it compiles use the debug version of llvm_unreachable, which
uses __FILE__. To fix this, we propagate NDEBUG from bootstrap if
applicable and use it when compiling librustc_llvm.
The previous approach was brittle - what would happen if `ParentScope` wasn't created by `invoc_parent_scope`?
That's exactly the case for various uses of `ParentScope` in diagnostics and in built-in attribute validation.
Traces already contain module info without that.
It's easy to forget to call `finalize_*` on a module.
In particular, macros enum and trait modules weren't finalized.
By happy accident macros weren't placed into those modules until now.
on OpenBSD, some architectures relies on libc++ (from LLVM) and some
others on libestdc++ (particular version of libstdc++ from GCC).
sparc64-unknown-openbsd needs libestdc++ and libgcc (as x86_64 some
years ago). Reintroduce the support of them for openbsd, only for
sparc64 arch. Some others architectures on OpenBSD could use them too.
cleanup: Remove `Spanned` where possible
It generally only makes sense on enums, otherwise it's more convenient to "flatten" it by adding a span field to the struct it wraps.
Test HRTB issue accepted by compiler
Hi! First Rust PR, so if anything needs changing just let me know and I'll take care of it right away.
Closes#50301 which was marked E-needstest
Remove uses of `mem::uninitialized()` from cloudabi
This PR removes uses of `mem::uninitialized` from `cloudabi` module,
excluding the layout test in `src/libstd/sys/cloudabi/abi/cloudabi.rs`.
r? @RalfJung
cc @EdSchouten
cc #62397
Add Catalyst (iOS apps running on macOS) target
This is a first attempt of adding support for the new [Apple Catalyst](https://developer.apple.com/ipad-apps-for-mac/) target (i.e. running iOS apps on macOS). Currently, `rustc` supports the iOS and iOS simulator targets for iOS:
- iOS: ARM cpu, iOS SDK, linked agains the iOS ABI
- Simulator: X86_64 cpu, iOS SDK, linked against the iOS ABI
Apple Catalyst will add an additional target:
- Macabi: X86_64 CPU, iOS SDK, linked again the macOS ABI.
Note, it the actual SDK is the also the macOS 10.15 SDK, but the symbols are the iOS SDK symbols as they were added to macOS with 10.15.
I've collected additional information via links in the open question sections below. This is way out of my comfort zone so please excuse whatever errors I may have made.
# Open Questions:
## Clang Version
It seems to me that `macabi` has not been merged into `clang` yet, I don't know whether that is a requirement rustc to compile, or if it is sufficient if the Clang that is used on a developers system is the correct one supporting macabi (that comes with current Xcode)
## Hardcoded iOS version
`swift-llvm` actually used [x86_64-apple-ios13.0-macabi](3f1fd4f46a) as the target triple which hard-codes the current iOS version. A post on stackoverflow [points out that `MIN_IOS_VERSION` and `MIN_OSX_VERSION` should be used when compiling C code for clang (`-target x86_64-apple-ios${MIN_IOS_VERSION}-macabi`)](https://stackoverflow.com/questions/56487645/how-to-compile-a-3rd-party-library-to-be-used-with-uikit-for-mac-catalyst). However, I wasn't entirely sure how to do that in this PR. Pointers welcome.
## Data Layout
I'm probably using the wrong data-layout. I don't know whether it should be the macOS version or the iOS version. This is probably easier to answer for somebody who understands these things much better than me. I just copied the iOS Simulator X86_64 version as it seems to be (based on what I understand) that Catalyst is just the simulator target build against a different SDK.
# Current State
1. I got it to compile
2. I could successfully compile a `macabi` `libcore` via `cargo build --target x86_64-apple-ios-macabi`
I'm not sure what needs to be done next. Supposedly I need to compile everything into a toolchain somehow that I can then test via `rustup` to make sure that a binary compiled against the toolchain also works with Catalyst. [I read this article, but I'm still lost](https://www.reddit.com/r/rust/comments/5ag60z/how_do_i_bootstrap_rust_to_crosscompile_for_a_new/d9gicr2/) and would love pointers what to do next here.
# Additional Information
- [Commit adding Catalyst support to the Swift Clang Fork](https://github.com/CocoaPods/CocoaPods/issues/8877)
- [Compiling C to Catalyst Discussion](https://github.com/CocoaPods/CocoaPods/issues/8877)
- [CocoaPods Discussion on Adding Catalyst support](https://github.com/CocoaPods/CocoaPods/issues/8877)
