bors [Tue, 18 Feb 2020 22:29:06 +0000 (22:29 +0000)]
Auto merge of #69271 - Centril:rollup-iupsol6, r=Centril
Rollup of 6 pull requests
Successful merges:
- #69146 (Always const qualify literals by type)
- #69159 (Select an appropriate unused lifetime name in suggestion)
- #69194 (parse: fuse associated and extern items up to defaultness)
- #69211 (parser: Simplify treatment of macro variables in `Parser::bump`)
- #69217 (Do not emit note suggesting to implement operation trait to foreign type)
- #69236 (parse: recover `mut (x @ y)` as `(mut x @ mut y)`.)
Rollup merge of #69236 - Centril:mut-parens-at-recovery, r=estebank
parse: recover `mut (x @ y)` as `(mut x @ mut y)`.
Follow up to https://github.com/rust-lang/rust/pull/68992#discussion_r376829749 and https://github.com/rust-lang/rust/pull/63945.
Specifically, when given `let mut (x @ y)` we recover with `let (mut x @ mut y)` as the suggestion:
```rust
error: `mut` must be attached to each individual binding
--> $DIR/mut-patterns.rs:12:9
|
LL | let mut (x @ y) = 0;
| ^^^^^^^^^^^ help: add `mut` to each binding: `(mut x @ mut y)`
|
= note: `mut` may be followed by `variable` and `variable @ pattern`
```
Rollup merge of #69217 - LeSeulArtichaut:remove-lint-impl-op, r=estebank
Do not emit note suggesting to implement operation trait to foreign type
When a binary operation isn't valid, you will get a lint proposing to add a trait implementation to make the operation possible. However, this cannot be done for foreign types, such as types from `core` or `std`.
For example:
```
= note: an implementation of `std::ops::Add` might be missing for `std::option::Option<i8>`
```
As mentioned in https://github.com/rust-lang/rust/issues/60497#issuecomment-562665539:
> The note suggesting implementing Add<i8> should only be emitted if Option<i8> were local to the current crate, which it isn't, so in this case it shouldn't be emitted.
(I will use the CI to check tests for me, or my computer will just burn... and running IDEs is not possible on a pile of ashes)
Rollup merge of #69211 - petrochenkov:prevtok, r=Centril
parser: Simplify treatment of macro variables in `Parser::bump`
Follow-up to https://github.com/rust-lang/rust/pull/69006.
Token normalization for `$ident` and `$lifetime` is merged directly into `bump`.
Special "unknown macro variable" diagnostic for unexpected `$`s is removed as preventing legal code from compiling (as a result `bump` also doesn't call itself recursively anymore and can't make `prev_token` inconsistent).
Rollup merge of #69194 - Centril:assoc-extern-fuse, r=petrochenkov
parse: fuse associated and extern items up to defaultness
Language changes:
- The grammar of extern `type` aliases is unified with associated ones, and becomes:
```rust
TypeItem = "type" ident generics {":" bounds}? where_clause {"=" type}? ";" ;
```
Semantic restrictions (`ast_validation`) are added to forbid any parameters in `generics`, any bounds in `bounds`, and any predicates in `where_clause`, as well as the presence of a type expression (`= u8`).
(Work still remains to fuse this with free `type` aliases, but this can be done later.)
- The grammar of constants and static items (free, associated, and extern) now permits the absence of an expression, and becomes:
- A semantic restriction is added to enforce the presence of the expression (the body).
- A semantic restriction is added to reject `const _` in associated contexts.
Together, these changes allow us to fuse the grammar of associated items and extern items up to `default`ness which is the main goal of the PR.
-----------------------
We are now very close to fully fusing the entirely of item parsing and their ASTs. To progress further, we must make a decision: should we parse e.g. `default use foo::bar;` and whatnot? Accepting that is likely easiest from a parsing perspective, as it does not require using look-ahead, but it is perhaps not too onerous to only accept it for `fn`s (and all their various qualifiers), `const`s, `static`s, and `type`s.
bors [Tue, 18 Feb 2020 17:51:29 +0000 (17:51 +0000)]
Auto merge of #69262 - Dylan-DPC:rollup-m6dt9cn, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #69181 (Change const eval to just return the value )
- #69192 (Add more regression tests)
- #69200 (Fix printing of `Yield` terminator)
- #69205 (Allow whitespaces in revision flags)
- #69233 (Clean up E0310 explanation)
Yuki Okushi [Tue, 18 Feb 2020 11:09:11 +0000 (20:09 +0900)]
Rollup merge of #69252 - Mark-Simulacrum:disk-try, r=pietroalbini
Clean out unused directories for extra disk space
This cleans out some of the unused (but large) directories on our linux builders to hopefully allow them to complete without running out of disk space.
Yuki Okushi [Tue, 18 Feb 2020 11:09:08 +0000 (20:09 +0900)]
Rollup merge of #69244 - cuviper:llvm-flags, r=Mark-Simulacrum
configure: set LLVM flags with a value
Rather than a boolean `--enable-cflags` etc., these options should
reflect that they are for LLVM, and that they need a value. You would
now use `./configure --llvm-cflags="..."`.
Yuki Okushi [Tue, 18 Feb 2020 11:08:59 +0000 (20:08 +0900)]
Rollup merge of #67272 - fisherdarling:master, r=varkor,hellow554
recursion_limit parsing handles overflows
This PR adds overflow handling to `#![recursion_limit]` attribute parsing. If parsing the given value results in an `IntErrorKind::Overflow`, then the recursion_limit is set to `usize::max_value()`.
Mark Rousskov [Tue, 18 Feb 2020 00:39:38 +0000 (19:39 -0500)]
Clean out some default-installed directories
This helps us have enough disk space for our builders to be able to complete
successfully. For now, the choices are ad-hoc and 'definitely not needed'. This
should never fail the build, as everything our build needs should be inside
Docker.
Token normalization is merged directly into `bump`.
Special "unknown macro variable" diagnostic for unexpected `$`s is removed as preventing legal code from compiling.
Josh Stone [Mon, 17 Feb 2020 19:01:52 +0000 (11:01 -0800)]
configure: set LLVM flags with a value
Rather than a boolean `--enable-cflags` etc., these options should
reflect that they are for LLVM, and that they need a value. You would
now use `./configure --llvm-cflags="..."`.
bors [Mon, 17 Feb 2020 06:44:35 +0000 (06:44 +0000)]
Auto merge of #69226 - JohnTitor:rollup-syn03oj, r=JohnTitor
Rollup of 6 pull requests
Successful merges:
- #68495 (Updating str.chars docs to mention crates.io.)
- #68701 (Improve #Safety of various methods in core::ptr)
- #69158 (Don't print block exit state in dataflow graphviz if unchanged)
- #69179 (Rename `FunctionRetTy` to `FnRetTy`)
- #69186 ([tiny] parser: `macro_rules` is a weak keyword)
- #69188 (Clean up E0309 explanation)
Yuki Okushi [Mon, 17 Feb 2020 04:46:54 +0000 (13:46 +0900)]
Rollup merge of #69158 - ecstatic-morse:graphviz-diff, r=matthewjasper
Don't print block exit state in dataflow graphviz if unchanged
A small quality-of-life improvement I was using while working on #68528. It's pretty common to have a lot of zero-statement basic blocks, especially before a `SimplifyCfg` pass is run. When the dataflow state was dense, these blocks could take up a lot of vertical space since the full flow state was printed on both entry and exit. After this PR, we only print a block's exit state if it differs from that block's entry state. Take a look at the two basic blocks on the left.
bors [Sun, 16 Feb 2020 22:24:54 +0000 (22:24 +0000)]
Auto merge of #67953 - cjgillot:split_infer, r=Zoxc
Split librustc::{traits,infer} to a separate crate rustc_infer
This is still very much work in progress.
Three functions are between dimensions (at the end of `rustc::traits`), waiting for some dependency breaking scheme.
Please tell me if the approach seems sound, and how you would like to split this PR up.
The formatting is deliberately off, to ease rebasing.
bors [Sun, 16 Feb 2020 15:28:41 +0000 (15:28 +0000)]
Auto merge of #67885 - tobithiel:fix_group_lint_allow_override, r=Mark-Simulacrum
rustc_session: allow overriding lint level of individual lints from a group
Fixes #58211 and fixes rust-lang/rust-clippy#4778 and fixes rust-lang/rust-clippy#4091
Instead of hard-coding the lint level preferences (from lowest to highest precedence: `lint::Allow -> lint::Warn -> lint::Deny -> lint::Forbid`), the position of the argument in the command line gets taken into account.
Examples:
1. Passing `-D unused -A unused-variables` denies everything in the lint group `unused` **except** `unused-variables` which is explicitly allowed.
1. Passing `-A unused-variables -D unused` denies everything in the lint group `unused` **including** `unused-variables` since the allow is specified before the deny (and therefore overridden by the deny).
This matches the behavior that is already being used when specifying `allow`/`deny` in the source code.
bors [Sun, 16 Feb 2020 01:46:05 +0000 (01:46 +0000)]
Auto merge of #68814 - Aaron1011:fix/proc-macro-order-two, r=petrochenkov
Record proc macro harness order for use during metadata deserialization
Fixes #68690
When we generate the proc macro harness, we now explicitly recorder the
order in which we generate entries. We then use this ordering data to
deserialize the correct proc-macro-data from the crate metadata.
Aaron Hill [Mon, 3 Feb 2020 23:34:36 +0000 (18:34 -0500)]
Record proc macro harness order for use during metadata deserialization
Fixes #68690
When we generate the proc macro harness, we now explicitly recorder the
order in which we generate entries. We then use this ordering data to
deserialize the correct proc-macro-data from the crate metadata.