-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 8 pull requests #63603
Rollup of 8 pull requests #63603
Conversation
Most `Ident`s are serialized as `InternedString`s the exceptions are: * Reexports * Attributes * Idents in macro definitions Using gensyms helped reexports emulate hygiene. However, the actual item wouldn't have a gensymmed name so would be usable cross-crate. So removing this case until we have proper cross-crate hygiene seems sensible. Codegen attributes (`inline`, `export_name`) are resolved by their `Symbol`. This meant that opaque macro-expanded codegen attributes could cause linker errors. This prevented making built-in derives hygienic.
Also make them generally more hygienic with name resolution.
For some reason type checking did this. Further it didn't consider hygiene.
This will help reproducible builds, as the sysroot depends on the working directory.
We now store it in the `Span` of the expression or item.
As suggested by @alexcrichton, the sysroot only loads libraries that are themselves tracked.
The implementations were wrong and unused.
…hton Use libunwind from llvm-project submodule for musl targets This avoid downloading libunwind by using the scheme introduced in rust-lang#61544
…ves, r=petrochenkov Opaque builtin derive macros * Buiilt-in derives are now opaque macros * This required limiting the visibility of some previously unexposed functions in `core`. * This also required the change to `Ident` serialization. * All gensyms are replaced with hygienic identifiers * Use hygiene to avoid most other name-resolution issues with buiilt-in derives. * As far as I know the only remaining case that breaks is an ADT that has the same name as one of its parameters. Fixing this completely seemed to be more effort than it's worth. * Remove gensym in `Ident::decode`, which lead to linker errors due to `inline` being gensymmed. * `Ident`now panics if incremental compilation tries to serialize it (it currently doesn't). * `Ident` no longer uses `gensym` to emulate cross-crate hygiene. It only applied to reexports. * `SyntaxContext` is no longer serializable. * The long-term fix for this is to properly implement cross-crate hygiene, but this seemed to be acceptable for now. * Move type/const parameter shadowing checks to `resolve` * This was previously split between resolve and type checking. The type checking pass compared `InternedString`s, not Identifiers. * Removed the `SyntaxContext` from `{ast, hir}::{InlineAsm, GlobalAsm}` cc rust-lang#60869 r? @petrochenkov
…xcrichton Utilize -Zbinary-dep-depinfo in rustbuild The last commit moves us over to using binary-dep-depinfo while the first two permit us to bootstrap from what will become future beta, to be released in the next week (it's the `cfg(bootstrap)` processing). We no longer utilize stamp-file mtimes at all inside rustbuild, and a future PR may be able to entirely eliminate them by eagerly copying to the appropriate sysroot. The only mtime-based dependency tracking left is for documentation because we lie to Cargo about the rustdoc binary, so Cargo does not track changes to the real binary, and codegen-backends because binary-dep-depinfo does not emit that information into the depfiles. Both of these are fixable in the longer term but this existing patch gives us the following benefits: * We no longer delete Cargo target directories manually within a stage. Cross-stage, changes to codegen backends will still clear out target directories. This means that incremental state persists across individual steps (e.g., rebuilding libstd does not clear out librustc incremental state). Fixes rust-lang#54712. * Dependency tracking across steps within a given stage is now fully precise. We will not clear out all codegen backend dependencies due to changes in librustc_driver, for example, only deleting the final librustc_codegen_llvm crate. Fixes rust-lang#54008, fixes rust-lang#50481. * We properly track codegen backends as a dependency (equivalent to rustc) across changes. Fixes rust-lang#53284, and fixes rust-lang#52719. * Cross-stage dependency tracking of crates is also much more accurate and reliable. Most likely fixes rust-lang#49979 (but no reproduction steps in that issue). Fixes rust-lang#59105. cc rust-lang#63012
Hash the remapped sysroot instead of the original. One of the reasons that rustc builds are not reproducible is because the --sysroot path is dependent on the current directory. We can fix this by hashing the remapped sysroot instead of the original when applicable. Note that with this patch, the hash will stay the same if both the sysroot and the remapped path change. However, given that if the contents of the sysroot change the hash will also stay the same, this might be acceptable. I would appreciate feedback on the best way to do this. This helps rust-lang#34902, although it does not fix it by itself.
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 rust-lang#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
Feature gate 'yield $expr?' pre-expansion Also improve the overall ergonomics of pre-expansion gating in general. r? @Zoxc
…chton Update rustc-demangle to 0.1.16. Includes rust-lang/rustc-demangle#29 and rust-lang/rustc-demangle#30. You can see the effects of the former in the testcase changes. r? @alexcrichton cc @davidtwco @michaelwoerister
… r=alexreg 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 rust-lang#63534 merged. Closes rust-lang#63393 r? @alexreg cc @iluuu1994 cc rust-lang#52662
@bors r+ p=8 rollup=never |
📌 Commit 69a3206 has been approved by |
⌛ Testing commit 69a3206 with merge 8fcc0fd9bef4c655e841dbf0e4d442757d31cc79... |
💔 Test failed - checks-azure |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Successful merges:
<expr>.await
with no such field #63539 (Suggest Rust 2018 on<expr>.await
with no such field)#![feature(associated_type_bounds)]
#63584 (libcore: more cleanups using#![feature(associated_type_bounds)]
)Failed merges:
r? @ghost