bors [Tue, 3 Nov 2020 18:58:06 +0000 (18:58 +0000)]
Auto merge of #78711 - m-ou-se:rollup-pxqnny7, r=m-ou-se
Rollup of 7 pull requests
Successful merges:
- #77950 (Add support for SHA256 source file hashing)
- #78624 (Sync rustc_codegen_cranelift)
- #78626 (Improve errors about #[deprecated] attribute)
- #78659 (Corrected suggestion for generic parameters in `function_item_references` lint)
- #78687 (Suggest library/std when running all stage 0 tests)
- #78699 (Show more error information in lldb_batchmode)
- #78709 (Fix panic in bootstrap for non-workspace path dependencies.)
Mara Bos [Tue, 3 Nov 2020 18:32:44 +0000 (19:32 +0100)]
Rollup merge of #78709 - ehuss:fix-in_tree_crates-non-member, r=Mark-Simulacrum
Fix panic in bootstrap for non-workspace path dependencies.
If you add a `path` dependency to a `Cargo.toml` that is located outside of the workspace, then the `in_tree_crates` function can panic because it finds a path dependency that is not defined (since it uses `cargo metadata --no-deps`). This fixes it by skipping over those entries, which are usually not things you select on the command-line.
Mara Bos [Tue, 3 Nov 2020 18:32:40 +0000 (19:32 +0100)]
Rollup merge of #78687 - jyn514:bootstrap-help, r=Mark-Simulacrum
Suggest library/std when running all stage 0 tests
r? ``@Mark-Simulacrum``
cc ``@ijackson``
For context, this came out of a discord conversation where ``@ijackson`` was running `test --stage 1` when they were only adding doc-tests to the standard library.
Mara Bos [Tue, 3 Nov 2020 18:32:38 +0000 (19:32 +0100)]
Rollup merge of #78659 - ayrtonm:fn-ref-lint-fix, r=oli-obk
Corrected suggestion for generic parameters in `function_item_references` lint
This commit handles functions with generic type parameters like you pointed out as well as const generics. Also this is probably a minor thing, but the type alias you used in the example doesn't show up so the suggestion right now would be `size_of::<[u8; 16]> as fn() ->`. This is because the lint checker works with MIR instead of HIR. I don't think we can get the alias at that point, but let me know if I'm wrong and there's a way to fix this. Also I put you as the reviewer, but I'm not sure if you want to review it or if it makes more sense to ask one of the original reviewers of this lint.
closes #78571
Mara Bos [Tue, 3 Nov 2020 18:32:36 +0000 (19:32 +0100)]
Rollup merge of #78626 - fusion-engineering-forks:deprecated-trait-impl, r=estebank
Improve errors about #[deprecated] attribute
This change:
1. Turns `#[deprecated]` on a trait impl block into an error, which fixes #78625;
2. Changes these and other errors about `#[deprecated]` to use the span of the attribute instead of the item; and
3. Turns this error into a lint, to make sure it can be capped with `--cap-lints` and doesn't break any existing dependencies.
Can be reviewed per commit.
---
Example:
```rust
struct X;
#[deprecated = "a"]
impl Default for X {
#[deprecated = "b"]
fn default() -> Self {
X
}
}
```
Before:
```
error: This deprecation annotation is useless
--> src/main.rs:6:5
|
6 | / fn default() -> Self {
7 | | X
8 | | }
| |_____^
```
After:
```
error: this `#[deprecated]' annotation has no effect
--> src/main.rs:3:1
|
3 | #[deprecated = "a"]
| ^^^^^^^^^^^^^^^^^^^ help: try removing the deprecation attribute
|
= note: `#[deny(useless_deprecated)]` on by default
error: this `#[deprecated]' annotation has no effect
--> src/main.rs:5:5
|
5 | #[deprecated = "b"]
| ^^^^^^^^^^^^^^^^^^^ help: try removing the deprecation attribute
```
Yuki Okushi [Tue, 3 Nov 2020 06:27:21 +0000 (15:27 +0900)]
Rollup merge of #78676 - kiffie:embedded-bare-mipsr2, r=jonas-schievink
add mipsel-unknown-none target
This adds a target for bare MIPS32r2, little endian, softfloat. This target can be used for PIC32 microcontrollers (or possibly for other devices that have a MIPS MCU core such as the M4K core).
Tried to find a name for the target that is in line with the naming scheme apparently used for the other MIPS targets.
Yuki Okushi [Tue, 3 Nov 2020 06:27:16 +0000 (15:27 +0900)]
Rollup merge of #78663 - Aaron1011:fix/cap-future-compat, r=tmandry
Fix ICE when a future-incompat-report has its command-line level capped
Fixes #78660
With PR https://github.com/rust-lang/rust/pull/75534 merged, we now run
more lint-related code for future-incompat-report, even when their final
level is Allow. Some lint-related code was not expecting `Level::Allow`,
and had an explicit panic.
This PR explicitly tracks the lint level set on the command line before
`--cap-lints` is applied. This is used to emit a more precise error
note (e.g. we don't say that `-W lint-name` was specified on the
command line just because a lint was capped to Warn). As a result, we
can now correctly emit a note that `-A` was used if we got
`Level::Allow` from the command line (before the cap is applied).
Yuki Okushi [Tue, 3 Nov 2020 06:27:03 +0000 (15:27 +0900)]
Rollup merge of #78376 - Aaron1011:feature/consistent-empty-expr, r=petrochenkov
Treat trailing semicolon as a statement in macro call
See #61733 (comment)
We now preserve the trailing semicolon in a macro invocation, even if
the macro expands to nothing. As a result, the following code no longer
compiles:
bors [Tue, 3 Nov 2020 04:27:27 +0000 (04:27 +0000)]
Auto merge of #78448 - rylev:cache-foreign_modules, r=wesleywiser
foreign_modules query hash table lookups
When compiling a large monolithic crate we're seeing huge times in the `foreign_modules` query due to repeated iteration over foreign modules (in order to find a module by its id). This implements hash table lookups so that which massively reduces time spent in that query in this particular case. We'll need to see if the overhead of creating the hash table has a negative impact on performance in more normal compilation scenarios.
bors [Tue, 3 Nov 2020 00:58:24 +0000 (00:58 +0000)]
Auto merge of #77271 - petrochenkov:notokenexp, r=Aaron1011
Expand `NtExpr` tokens only in key-value attributes
Implement the experiment described in https://github.com/rust-lang/rust/issues/55414#issuecomment-554005412
This PR also removes some customization points and token visiting functionality from AST visitors.
Read-only visitor no longer visits tokens, mutable visitor visits tokens only when specifically enabled, mutable token visiting is restricted to its single intended use case.
I haven't changed the representation of `MacArgs::Eq` yet, but it potentially can use a `TokenTree` or a `Token` instead of `TokenStream`.
It's hard to get rid of `Nonterminal::NtExpr` there (and e.g. replace it with `ast::Expr`) due to the dual nature of key-value attributes (the value is both an expression and a token stream, depending on context), and `Nonterminal` has all the machinery for maintaining both representations in sync.
Aaron Hill [Sun, 25 Oct 2020 21:14:19 +0000 (17:14 -0400)]
Treat trailing semicolon as a statement in macro call
See https://github.com/rust-lang/rust/issues/61733#issuecomment-716188981
We now preserve the trailing semicolon in a macro invocation, even if
the macro expands to nothing. As a result, the following code no longer
compiles:
bors [Mon, 2 Nov 2020 16:01:10 +0000 (16:01 +0000)]
Auto merge of #78607 - HeroicKatora:post-order-walk-iter, r=davidtwco
Transform post order walk to an iterative approach
The previous recursive approach might overflow the stack when walking a
particularly deep, list-like, graph. In particular, dominator
calculation for borrow checking does such a traversal and very long
functions might lead to a region dependency graph with in this
problematic structure.
This addresses what appears to be the cause of #78567 (`@SunHao-0` thanks for the stack trace).
bors [Mon, 2 Nov 2020 13:07:01 +0000 (13:07 +0000)]
Auto merge of #78667 - pietroalbini:lldb-unbuffered, r=Mark-Simulacrum
Try running lldb_batchmode.py with PYTHONUNBUFFERED
When reporting fatal errors, LLVM calls abort() to exit the program. There is a chance that might interfere with Python printing stuff to stdout, as by default it relies on buffering to increase performance.
This commit tries to disable Python buffering, to hopefully get useful logs while debugging #78665.
Pietro Albini [Mon, 2 Nov 2020 12:20:16 +0000 (13:20 +0100)]
compiletest: try running lldb_batchmode.py with PYTHONUNBUFFERED
When reporting fatal errors, LLVM calls abort() to exit the program.
There is a chance that might interfere with Python printing stuff to
stdout, as by default it relies on buffering to increase performance.
This commit tries to disable Python buffering, to hopefully get useful
logs while debugging #78665.
bors [Mon, 2 Nov 2020 10:42:45 +0000 (10:42 +0000)]
Auto merge of #78661 - JohnTitor:rollup-er2isja, r=JohnTitor
Rollup of 5 pull requests
Successful merges:
- #78606 (Clarify handling of final line ending in str::lines())
- #78610 (Do not remove tokens before AST json serialization)
- #78620 (Trivial fixes to bitwise operator documentation)
- #78627 (Point out that total_cmp is no strict superset of partial comparison)
- #78637 (Add fetch_update methods to AtomicBool and AtomicPtr)
Aaron Hill [Mon, 2 Nov 2020 06:37:26 +0000 (01:37 -0500)]
Fix ICE when a future-incompat-report has its command-line level capped
Fixes #78660
With PR https://github.com/rust-lang/rust/pull/75534 merged, we now run
more lint-related code for future-incompat-report, even when their final
level is Allow. Some lint-related code was not expecting `Level::Allow`,
and had an explicit panic.
This PR explicitly tracks the lint level set on the command line before
`--cap-lints` is applied. This is used to emit a more precise error
note (e.g. we don't say that `-W lint-name` was specified on the
command line just because a lint was capped to Warn). As a result, we
can now correctly emit a note that `-A` was used if we got
`Level::Allow` from the command line (before the cap is applied).
Yuki Okushi [Mon, 2 Nov 2020 05:14:41 +0000 (14:14 +0900)]
Rollup merge of #78637 - mystor:atomic_ptr_bool, r=m-ou-se
Add fetch_update methods to AtomicBool and AtomicPtr
These methods were stabilized for the integer atomics in #71843, but the methods were not added for the non-integer atomics `AtomicBool` and `AtomicPtr`.
Yuki Okushi [Mon, 2 Nov 2020 05:14:38 +0000 (14:14 +0900)]
Rollup merge of #78627 - est31:total_cmp_no_superset, r=m-ou-se
Point out that total_cmp is no strict superset of partial comparison
Partial comparison and total_cmp are not equal. This helps
preventing the mistake of creating float wrappers that
base their Ord impl on total_cmp and their PartialOrd impl on
the PartialOrd impl of the float type. PartialOrd and Ord
[are required to agree with each other](https://doc.rust-lang.org/std/cmp/trait.Ord.html#how-can-i-implement-ord).
Yuki Okushi [Mon, 2 Nov 2020 05:14:36 +0000 (14:14 +0900)]
Rollup merge of #78620 - gabhijit:bitops_doc_fix, r=m-ou-se
Trivial fixes to bitwise operator documentation
Added fixes to documentation of `BitAnd`, `BitOr`, `BitXor` and
`BitAndAssign`, where the documentation for implementation on
`Vector<bool>` was using logical operators in place of the bitwise
operators.
Yuki Okushi [Mon, 2 Nov 2020 05:14:34 +0000 (14:14 +0900)]
Rollup merge of #78610 - petrochenkov:nostriptok, r=Aaron1011
Do not remove tokens before AST json serialization
`TokenStripper` is error-prone and introduces one more use of `MutVisitor`.
It's much simpler to treat serialization as just one more place that wants lazy token stream to turn into a real token stream.
Also, no code is better than more code, in general.
r? @Aaron1011
(I also merged tests for `TokenStripper` ICEs into one.)
Yuki Okushi [Mon, 2 Nov 2020 05:14:33 +0000 (14:14 +0900)]
Rollup merge of #78606 - autarch:patch-1, r=m-ou-se
Clarify handling of final line ending in str::lines()
I found the description as it stands a bit confusing. I've added a bit more explanation to make it clear that a trailing line ending does not produce a final empty line.
bors [Mon, 2 Nov 2020 04:39:05 +0000 (04:39 +0000)]
Auto merge of #78592 - fpoli:nll-facts-dir, r=matthewjasper
Add option to customize the nll-facts' folder location
This PR adds a `nll-facts-dir` option to specify the location of the directory in which NLL facts are dumped into. It works the same way `dump-mir-dir` controls the location used by the `dump-mir` option.
Ayrton [Mon, 2 Nov 2020 03:14:21 +0000 (23:14 -0400)]
Corrected suggestion for generic parameters in `function_item_references` lint
This lint was incorrectly suggesting casting a function to a pointer without
specifying generic type parameters or const generics. This would cause a
compiler error since the missing parameters couldn't be inferred. This commit
fixed the suggestion and added a few tests with generics.
Nika Layzell [Sun, 1 Nov 2020 18:24:22 +0000 (13:24 -0500)]
Add fetch_update methods to AtomicBool and AtomicPtr
These methods were stabilized for the integer atomics in #71843, but the methods
were not added for the non-integer atomics `AtomicBool` and `AtomicPtr`.
est31 [Sun, 1 Nov 2020 13:27:36 +0000 (14:27 +0100)]
Point out that total_cmp is no strict superset of partial comparison
Partial comparison and total_cmp are not equal. This helps
preventing the mistake of creating float wrappers that
base their Ord impl on total_cmp and their PartialOrd impl on
the PartialOrd impl of the float type. PartialOrd and Ord
are required to agree with each other.
bors [Sun, 1 Nov 2020 16:52:28 +0000 (16:52 +0000)]
Auto merge of #75534 - Aaron1011:feature/new-future-breakage, r=pnkfelix
Implement rustc side of report-future-incompat
cc https://github.com/rust-lang/rust/issues/71249
This is an alternative to `@pnkfelix's` initial implementation in https://github.com/pnkfelix/rust/commits/prototype-rustc-side-of-report-future-incompat (mainly because I started working before seeing that branch :smile: ).
My approach outputs the entire original `Diagnostic`, in a way that is compatible with incremental compilation. This is not yet integrated with compiletest, but can be used manually by passing `-Z emit-future-incompat-report` to `rustc`.
Several changes are made to support this feature:
* The `librustc_session/lint` module is moved to a new crate `librustc_lint_defs` (name bikesheddable). This allows accessing lint definitions from `librustc_errors`.
* The `Lint` struct is extended with an `Option<FutureBreakage>`. When present, it indicates that we should display a lint in the future-compat report. `FutureBreakage` contains additional information that we may want to display in the report (currently, a `date` field indicating when the crate will stop compiling).
* A new variant `rustc_error::Level::Allow` is added. This is used when constructing a diagnostic for a future-breakage lint that is marked as allowed (via `#[allow]` or `--cap-lints`). This allows us to capture any future-breakage diagnostics in one place, while still discarding them before they are passed to the `Emitter`.
* `DiagnosticId::Lint` is extended with a `has_future_breakage` field, indicating whether or not the `Lint` has future breakage information (and should therefore show up in the report).
* `Session` is given access to the `LintStore` via a new `SessionLintStore` trait (since `librustc_session` cannot directly reference `LintStore` without a cyclic dependency). We use this to turn a string `DiagnosticId::Lint` back into a `Lint`, to retrieve the `FutureBreakage` data.
Currently, `FutureBreakage.date` is always set to `None`. However, this could potentially be interpreted by Cargo in the future.
I've enabled the future-breakage report for the `ARRAY_INTO_ITER` lint, which can be used to test out this PR. The intent is to use the field to allow Cargo to determine the date of future breakage (as described in [RFC 2834](https://github.com/rust-lang/rfcs/blob/master/text/2834-cargo-report-future-incompat.md)) without needing to parse the diagnostic itself.
bors [Sun, 1 Nov 2020 14:37:50 +0000 (14:37 +0000)]
Auto merge of #78553 - Nadrieril:fix-78549, r=varkor
Fix #78549
Before #78430, this worked because `specialize_constructor` didn't actually care too much which constructor was passed to it unless needed. That PR however handles `&str` as a special case, and I did not anticipate patterns for the `&str` type other than string literals.
I am not very confident there are not other similar oversights left, but hopefully only `&str` was different enough to break my assumptions.