- 20 8月, 2019 1 次提交
-
-
由 Giles Cope 提交于
-
- 16 8月, 2019 29 次提交
-
-
由 bors 提交于
submodules: Update miri Closes #63581 r? @RalfJung
-
由 bors 提交于
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
-
由 Mazdak Farrokhzad 提交于
Fix typo in DoubleEndedIterator::nth_back doc
-
由 Mazdak Farrokhzad 提交于
Do not suggest `try_into` for base types inside of macro expansions
-
由 Mazdak Farrokhzad 提交于
libcore: more cleanups using `#![feature(associated_type_bounds)]` Turns out this was indeed a bootstrapping issue from a test with `./x.py check` locally after https://github.com/rust-lang/rust/pull/63534 merged. Closes https://github.com/rust-lang/rust/issues/63393 r? @alexreg cc @iluuu1994 cc https://github.com/rust-lang/rust/issues/52662
-
由 Mazdak Farrokhzad 提交于
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
-
由 Mazdak Farrokhzad 提交于
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
-
由 Mazdak Farrokhzad 提交于
Use libunwind from llvm-project submodule for musl targets This avoid downloading libunwind by using the scheme introduced in https://github.com/rust-lang/rust/pull/61544
-
由 Mazdak Farrokhzad 提交于
Group all ABI tests. r? @EddyB Closes #62401
-
由 Jens Hausdorf 提交于
-
由 Esteban Küber 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
For naming consistency with everything else in this area
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
It was introduced to avoid going through `hygiene_data`, but now it's read only once, when `ParseSess` is created, so going through a lock is ok.
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
By allocating its derive paths on the resolver arena.
-
由 Vadim Petrochenkov 提交于
It was very similar to `ParentScope` and mostly could be replaced by it.
-
由 Vadim Petrochenkov 提交于
Remove some unnecessary parameters from functions
-
由 Vadim Petrochenkov 提交于
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.
-
由 Vadim Petrochenkov 提交于
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.
-
由 Vadim Petrochenkov 提交于
The expansion info is not optional and should always exist
-
由 Vadim Petrochenkov 提交于
`Ident` has had a full span rather than just a `SyntaxContext` for a long time now.
-
由 Vadim Petrochenkov 提交于
For consistency with `ExpnId::root`. Also introduce a helper `Span::with_root_ctxt` for creating spans with `SyntaxContext::root()` context
-
由 Vadim Petrochenkov 提交于
-
由 Kevin Per 提交于
-
由 Lzu Tao 提交于
-
- 15 8月, 2019 10 次提交
-
-
由 Kevin Per 提交于
-
由 Kevin Per 提交于
-
由 Kevin Per 提交于
-
由 bors 提交于
Rollup of 9 pull requests Successful merges: - #63155 (Add UWP MSVC targets) - #63165 (Add builtin targets for mips64(el)-unknown-linux-muslabi64) - #63306 (Adapt AddRetag for shallow retagging) - #63467 (Add Catalyst (iOS apps running on macOS) target) - #63546 (Remove uses of `mem::uninitialized()` from cloudabi) - #63572 (remove unused Level::PhaseFatal) - #63577 (Test HRTB issue accepted by compiler) - #63582 (Fix ICE #63226) - #63586 (cleanup: Remove `Spanned` where possible) Failed merges: r? @ghost
-
由 Mazdak Farrokhzad 提交于
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.
-
由 Mazdak Farrokhzad 提交于
Fix ICE #63226 Fixes #63226 r? @oli-obk
-
由 Mazdak Farrokhzad 提交于
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
-
由 Mazdak Farrokhzad 提交于
remove unused Level::PhaseFatal r? @estebank
-
由 Mazdak Farrokhzad 提交于
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
-
由 Mazdak Farrokhzad 提交于
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](https://github.com/apple/swift-llvm/commit/3f1fd4f46a8e82cee6fffb284ee46daf8ddf66ae) 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)
-