Skip to content
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 5 pull requests #63602

Closed
wants to merge 24 commits into from
Closed

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Aug 15, 2019

Successful merges:

Failed merges:

r? @ghost

matthewjasper and others added 24 commits August 12, 2019 19:22
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.
We now store it in the `Span` of the expression or item.
The implementations were wrong and unused.
…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
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
… 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
@Centril Centril closed this Aug 15, 2019
@Centril Centril deleted the rollup-h4qc854 branch August 15, 2019 16:35
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants