Update cargo
9 commits in 3c53211c3d7fee4f430f170115af5baad17a3da9..e02974078a692d7484f510eaec0e88d1b6cc0203
2020-02-07 15:35:03 +0000 to 2020-02-18 15:24:43 +0000
- Set an environment variable for tests to find executables. (rust-lang/cargo#7697)
- Rework internal errors. (rust-lang/cargo#7896)
- Improvements to StringList config handling. (rust-lang/cargo#7891)
- Add new/old rustflags to fingerprint log. (rust-lang/cargo#7890)
- Fix inaccurate doc comment on `env_args`. (rust-lang/cargo#7889)
- Add some extra fingerprint debug information. (rust-lang/cargo#7888)
- Link the licenses into crates/cargo-platform (rust-lang/cargo#7886)
- Modify test to make `rustc` PR mergeable (rust-lang/cargo#7883)
- Keep environment variables in a BTreeMap to preserve sort order (rust-lang/cargo#7877)
Combine `HaveBeenBorrowedLocals` and `IndirectlyMutableLocals` into one dataflow analysis
This PR began as an attempt to port `HaveBeenBorrowedLocals` to the new dataflow framework (see #68241 for prior art). Along the way, I noticed that it could share most of its code with `IndirectlyMutableLocals` and then found a few bugs in the two analyses:
- Neither one marked locals as borrowed after an `Rvalue::AddressOf`.
- `IndirectlyMutableLocals` was missing a minor fix that `HaveBeenBorrowedLocals` got in #61069. This is not a problem today since it is only used during const-checking, where custom drop glue is forbidden. However, this may change some day.
I decided to combine the two analyses so that they wouldn't diverge in the future while ensuring that they remain distinct types (called `MaybeBorrowedLocals` and `MaybeMutBorrowedLocals` to be consistent with the `Maybe{Un,}InitializedPlaces` naming scheme). I fixed the bugs and switched to exhaustive matching where possible to make them less likely in the future. Finally, I added comments explaining some of the finer points of the transfer function for these analyses (see #61069 and #65006).
Changes:
````
Rustup to rust-lang/rust#69194
Rustup to rust-lang/rust#69181
Add `LOG2_10` and `LOG10_2` to `approx_const` lint
Clean up imports
Use `Vec::with_capacity()` as possible
needless_doctest_main: False positive for async fn
Remove use of `TyKind`.
Use `if_chain`.
Fix ICE.
Add tests and improve checks.
Add `Future` detection for `missing_errors_doc`.
````
Fixes#69269
Revert "Remove `checked_add` in `Layout::repeat`"
This fixes a a segfault in safe code, a stable regression. Reported in #69225.
This reverts commit a983e0590a.
This fixes a a segfault in safe code, a stable regression. Reported in
\#69225.
This reverts commit a983e0590a.
Also adds a test for the expected behaviour.
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)`.)
Failed merges:
r? @ghost
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`
```
r? @matthewjasper @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)
r? @estebank
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).
r? @Centril
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:
```rust
GlobalItem = {"const" {ident | "_"} | "static" "mut"? ident} {"=" expr}? ";" ;
```
- 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.
r? @petrochenkov
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.
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="..."`.
