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 9 pull requests #69144

Merged
merged 36 commits into from
Feb 14, 2020
Merged

Rollup of 9 pull requests #69144

merged 36 commits into from
Feb 14, 2020

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost

basil-cow and others added 30 commits February 8, 2020 01:12
Implementation of 08a1c56 for the new
LLVM pass manager, support for which landed in the meantime.
as a consequence, `trait X { #![attr] }` becomes legal.
…enkov

parse: merge `fn` syntax + cleanup item parsing

Here we continue the work in rust-lang#67131 in particular to merge the grammars of `fn` items in various positions.

A list of *language level* changes (as sanctioned by the language team in rust-lang#65041 (comment) and rust-lang#67131):

- `self` parameters are now *syntactically* allowed as the first parameter irrespective of item context (and in function pointers). Instead, semantic validation (`ast_validation`) is used.

- Syntactically, `fn` items in `extern { ... }` blocks can now have bodies (`fn foo() { ... }` as opposed to `fn foo();`). As above, we use semantic restrictions instead.

- Syntactically, `fn` items in free contexts (directly in a file or a module) can now be without bodies (`fn foo();` as opposed to `fn foo() { ... }`. As above, we use semantic restrictions instead, including for non-ident parameter patterns.

- `const extern fn` feature gating is now done post-expansion such that we do not have conditional compatibilities of function qualifiers *in parsing*.

- The `FnFrontMatter` grammar becomes:
   ```rust
   Extern = "extern" StringLit ;
   FnQual = "const"? "async"? "unsafe"? Extern? ;
   FnFrontMatter = FnQual "fn" ;
   ```

   That is, all item contexts now *syntactically* allow `const async unsafe extern "C" fn` and use semantic restrictions to rule out combinations previously prevented syntactically. The semantic restrictions include in particular:

   - `fn`s in `extern { ... }` can have no qualifiers.
   - `const` and `async` cannot be combined.

- To fuse the list-of-items parsing in the 4 contexts that items are allowed, we now must permit inner attributes (`#![attr]`) inside `trait Foo { ... }` definitions. That is, we now allow e.g. `trait Foo { #![attr] }`. This was probably an oversight due to not using a uniform parsing mechanism, which we now do have (`fn parse_item_list`). The semantic support (including e.g. for linting) falls out directly from the attributes infrastructure. To ensure this, we include a test for lints.

Put together, these grammar changes allow us to substantially reduce the complexity of item parsing and its grammar. There are however some other non-language improvements that allow the compression to take place.

A list of *compiler-internal* changes (in particular noting the parser-external data-structure changes):

- We use `enum AllowPlus/RecoverQPath/AllowCVariadic { Yes, No }` in `parser/ty.rs` instead of passing around 3 different `bool`s. I felt this was necessary as it was becoming mentally taxing to track which-is-which.

- `fn visit_trait_item` and `fn visit_impl_item` are merged into `fn visit_assoc_item` which now is passed an `AssocCtxt` to check which one it is.

- We change `FnKind` to:

  ```rust
  pub enum FnKind<'a> {
      Fn(FnCtxt, Ident, &'a FnSig, &'a Visibility, Option<&'a Block>),
      Closure(&'a FnDecl, &'a Expr),
  }
  ```

  with:

  ```rust
  pub enum FnCtxt {
      Free,
      Foreign,
      Assoc(AssocCtxt),
  }
  ```

  This is then taken advantage of in tweaking the various semantic restrictions as well as in pretty printing.

- In `ItemKind::Fn`, we change `P<Block>` to `Option<P<Block>>`.

- In `ForeignItemKind::Fn`, we change `P<FnDecl>` to `FnSig` and `P<Block>` to `Option<P<Block>>`.

- We change `ast::{Unsafety, Spanned<Constness>}>` into `enum ast::{Unsafe, Const} { Yes(Span), No }` respectively. This change in formulation allow us to exclude `Span` in the case of `No`, which facilitates parsing. Moreover, we also add a `Span` to `IsAsync` which is renamed to `Async`. The new `Span`s in `Unsafety` and `Async` are then taken advantage of for better diagnostics. A reason this change was made is to have a more uniform and clear naming scheme.

  The HIR keeps the structures in AST (with those definitions moved into HIR) for now to avoid regressing perf.

- Various cleanups, bug fixes, and diagnostics improvements are made along the way. It is probably best to understand those via the diffs.

I would recommend reviewing this commit-by-commit with whitespace changes hidden.

r? @estebank @petrochenkov
…=estebank

fix lifetime shadowing check in GATs

closes rust-lang#67512
expand: misc cleanups and simplifications

Some work I did while trying to understand expand for the purposes of rust-lang#64197.

r? @petrochenkov
Use HirId in TraitCandidate.

I had to duplicate the `TraitMap` type to hold `NodeId`s until AST->HIR lowering is done.

r? @Zoxc
…lan-DPC

Add comment to SGX entry code

Meant to force push this to be included in rust-lang#69040, but forgot

r? @nagisa
miri: fix exact_div

Turns out `exact_div` was relying on the broken behavior of `Rem` for `int_min % -1` that was fixed in rust-lang#69002. This PR fixes `exact_div`.

Inside rustc, `exact_div` is only used in a single place where the divisor is always positive (in `ptr_offset_from`), so we cannot test the fix in rustc. The Miri test suite covers this through the `exact_div` intrinsic, though (and it is how I found out).

One step to rust-lang#69117 (then we also need to address build failures introduced by rust-lang#68969)

r? @oli-obk
…scope, r=nikic

Enable use after scope detection in the new LLVM pass manager

Implementation of 08a1c56 for the new LLVM pass manager, support for which landed in the meantime.
…chievink

Spelling error "represening" to "representing"

Small spelling mistake I noticed when looking through the Rust lexer.
…n-DPC

Don't error on network failures

This should further reduce spurious failures.

r? @JohnTitor and/or @ehuss
@Dylan-DPC-zz
Copy link
Author

@bors r+ p=9 rollup=never

@bors
Copy link
Contributor

bors commented Feb 13, 2020

📌 Commit 7704e59 has been approved by Dylan-DPC

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Feb 13, 2020
@Dylan-DPC-zz Dylan-DPC-zz added the rollup A PR which is a rollup label Feb 13, 2020
@bors
Copy link
Contributor

bors commented Feb 13, 2020

⌛ Testing commit 7704e59 with merge 1010408...

bors added a commit that referenced this pull request Feb 13, 2020
Rollup of 9 pull requests

Successful merges:

 - #68728 (parse: merge `fn` syntax + cleanup item parsing)
 - #68938 (fix lifetime shadowing check in GATs)
 - #69057 (expand: misc cleanups and simplifications)
 - #69108 (Use HirId in TraitCandidate.)
 - #69125 (Add comment to SGX entry code)
 - #69126 (miri: fix exact_div)
 - #69127 (Enable use after scope detection in the new LLVM pass manager)
 - #69135 (Spelling error "represening" to "representing")
 - #69141 (Don't error on network failures)

Failed merges:

r? @ghost
@bors
Copy link
Contributor

bors commented Feb 14, 2020

☀️ Test successful - checks-azure
Approved by: Dylan-DPC
Pushing 1010408 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Feb 14, 2020
@bors bors merged commit 7704e59 into rust-lang:master Feb 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants