Rollup of 8 pull requests
Successful merges:
- #65625 (Turn crate store into a resolver output)
- #65627 (Forbid non-`structural_match` types in const generics)
- #65710 (Update cargo)
- #65729 (Update test cases for vxWorks)
- #65746 (Tweak format string error to point at arguments always)
- #65753 (Don't assert for different instance on impl trait alias)
- #65755 (Avoid ICE when adjusting bad self ty)
- #65766 (Update hashbrown to 0.6.2)
Failed merges:
r? @ghost
Tweak format string error to point at arguments always
Add secondary span labels with no text to make it clear when there's a
mismatch bewteen the positional arguments in a format string and the
arguments to the macro. This shouldn't affect experienced users, but it
should make it easier for newcomers to more clearly understand how
`format!()` and `println!()` are supposed to be used.
```
error: 2 positional arguments in format string, but there is 1 argument
--> file8.rs:2:14
|
2 | format!("{} {}", 1);
| ^^ ^^ -
```
instead of
```
error: 2 positional arguments in format string, but there is 1 argument
--> file8.rs:2:14
|
2 | format!("{} {}", 1);
| ^^ ^^
```
r? @Centril
Update cargo
6 commits in 3a9abe3f065554a7fbc59f440df2baba4a6e47ee..3ba5f27170db10af7a92f2b682e049397197b8fa
2019-10-15 15:55:35 +0000 to 2019-10-22 15:05:18 +0000
- Fix typo in `cargo install --profile` help (rust-lang/cargo#7532)
- Use stricter -Z flag parsing. (rust-lang/cargo#7531)
- Set timestamp on generated files in archive to now (rust-lang/cargo#7523)
- Support rustc's `-Z panic-abort-tests` in Cargo (rust-lang/cargo#7460)
- rustfmt for nightly changes. (rust-lang/cargo#7526)
- Allow --all-features in root of virtual workspace. (rust-lang/cargo#7525)
Turn crate store into a resolver output
Crate store (`CStore`) is a vector of data (`CrateMetadata`) associated with extern crates loaded during the current compilation session.
All crates are loaded in the resolver when resolving either paths pointing to extern prelude or `extern crate` items. (There are also a couple of crates like panic runtime that are loaded kind of like implicit `extern crate`s, but that also happens in resolve.)
The use of `CStore` from `rustc_plugin` (which is outside of the resolver) was unnecessary because legacy plugins are not added to the crate store and don't use `CrateNum`s.
So, `CStore` can be produced by the resolver instead of being kept in some really global data (`rustc_interface::Compiler`) like now.
As a result of crate store being more "local" we can now remove some locks and `Lrc`s.
Split the rustc target libraries into separate rustc-dev component
This is re-applies a squashed version of #64823 as well as including #65337 to fix bugs noted after merging the first PR.
The second PR is confirmed as fixing windows-gnu, and presumably also fixes other platforms, such as musl (i.e. #65335 should be fixed); `RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup toolchain install nightly-2019-10-16` can be installed to confirm that this is indeed the case.
Add secondary span labels with no text to make it clear when there's a
mismatch bewteen the positional arguments in a format string and the
arguments to the macro. This shouldn't affect experienced users, but it
should make it easier for newcomers to more clearly understand how
`format!()` and `println!()` are supposed to be used.
```
error: 2 positional arguments in format string, but there is 1 argument
--> file8.rs:2:14
|
2 | format!("{} {}", 1);
| ^^ ^^ -
```
instead of
```
error: 2 positional arguments in format string, but there is 1 argument
--> file8.rs:2:14
|
2 | format!("{} {}", 1);
| ^^ ^^
```
Remove `InternedString`
This PR removes `InternedString` by converting all occurrences to `Symbol`. There are a handful of places that need to use the symbol chars instead of the symbol index, e.g. for stable sorting; local conversions `LocalInternedString` is used in those places.
r? @eddyb
Eliminate `intersect_opt`.
Its fourth argument is always `Some(pred)`, so the pattern matching is
unnecessary. This commit inlines and removes it.
r? @nikomatsakis
Derive `Rustc{En,De}codable` for `TokenStream`.
`TokenStream` used to be a complex type, but it is now just a newtype
around a `Lrc<Vec<TreeAndJoint>>`. Currently it uses custom encoding
that discards the `IsJoint` and custom decoding that adds `NonJoint`
back in for every token tree. This requires building intermediate
`Vec<TokenTree>`s.
This commit makes `TokenStream` derive `Rustc{En,De}codable`. This
simplifies the code, and avoids the creation of the intermediate
vectors, saving up to 3% on various benchmarks. It also changes the AST
JSON output in one test.
r? @petrochenkov
rustc_metadata: use a table for super_predicates, fn_sig, impl_trait_ref.
This is an attempt at a part of #65407, i.e. moving parts of cross-crate "metadata" into tables that match queries more closely.
Three new tables should be enough to see some perf/metadata size changes.
(need to do something similar to https://github.com/rust-lang/rust/pull/59953#issuecomment-542521919)
There are other bits of data that could be made into tables, but they can be more compact so the impact would likely be not as bad, and they're also more work to set up.
Avoid ICE when checking `Destination` of `break` inside a closure
Fix#65383, fix#62480. This is a `[regression-from-stable-to-stable]` and a fairly small change to avoid the ICE by properly handling this case.
Add the `matches!( $expr, $pat ) -> bool` macro
# Motivation
This macro is:
* General-purpose (not domain-specific)
* Simple (the implementation is short)
* Very popular [on crates.io](https://crates.io/crates/matches) (currently 37th in all-time downloads)
* The two previous points combined make it number one in [left-pad index](https://twitter.com/bascule/status/1184523027888988160) score
As such, I feel it is a good candidate for inclusion in the standard library.
In fact I already felt that way five years ago: https://github.com/rust-lang/rust/pull/14685 (Although the proof of popularity was not as strong at the time.)
# API
<details>
<del>
Back then, the main concern was that this macro may not be quite universally-enough useful to belong in the prelude.
Therefore, this PR adds the macro such that using it requires one of:
```rust
use core::macros::matches;
use std::macros::matches;
```
</del>
</details>
Like arms of a `match` expression, the macro supports multiple patterns separated by `|` and optionally followed by `if` and a guard expression:
```rust
let foo = 'f';
assert!(matches!(foo, 'A'..='Z' | 'a'..='z'));
let bar = Some(4);
assert!(matches!(bar, Some(x) if x > 2));
```
<details>
<del>
# Implementation constraints
A combination of reasons make it tricky for a standard library macro not to be in the prelude.
Currently, all public `macro_rules` macros in the standard library macros end up “in the prelude” of every crate not through `use std::prelude::v1::*;` like for other kinds of items, but through `#[macro_use]` on `extern crate std;`. (Both are injected by `src/libsyntax_ext/standard_library_imports.rs`.)
`#[macro_use]` seems to import every macro that is available at the top-level of a crate, even if through a `pub use` re-export.
Therefore, for `matches!` not to be in the prelude, we need it to be inside of a module rather than at the root of `core` or `std`.
However, the only way to make a `macro_rules` macro public outside of the crate where it is defined appears to be `#[macro_export]`. This exports the macro at the root of the crate regardless of which module defines it. See [macro scoping](https://doc.rust-lang.org/reference/macros-by-example.html#scoping-exporting-and-importing) in the reference.
Therefore, the macro needs to be defined in a crate that is not `core` or `std`.
# Implementation
This PR adds a new `matches_macro` crate as a private implementation detail of the standard library. This crate is `#![no_core]` so that libcore can depend on it. It contains a `macro_rules` definition with `#[macro_export]`.
libcore and libstd each have a new public `macros` module that contains a `pub use` re-export of the macro. Both the module and the macro are unstable, for now.
The existing private `macros` modules are renamed `prelude_macros`, though their respective source remains in `macros.rs` files.
</del>
</details>
Lockless LintStore
This removes mutability from the lint store after registration. Each commit stands alone, for the most part, though they don't make sense out of sequence.
The intent here is to move LintStore to a more parallel-friendly architecture, although also just a cleaner one from an implementation perspective. Specifically, this has the following changes:
* We no longer implicitly register lints when registering lint passes
* For the most part this means that registration calls now likely want to call something like:
`lint_store.register_lints(&Pass::get_lints())` as well as `register_*_pass`.
* In theory this is a simplification as it's much easier for folks to just register lints and then have passes that implement whichever lint however they want, rather than necessarily tying passes to lints.
* Lint passes still have a list of associated lints, but a followup PR could plausibly change that
* This list must be known for a given pass type, not instance, i.e., `fn get_lints()` is the signature instead of `fn get_lints(&self)` as before.
* We do not store pass objects, instead storing constructor functions. This means we always get new passes when running lints (this happens approximately once though for a given compiler session, so no behavior change is expected).
* Registration API is _much_ simpler: generally all functions are just taking `Fn() -> PassObject` rather than several different `bool`s.
# Motivation
This macro is:
* General-purpose (not domain-specific)
* Simple (the implementation is short)
* Very popular [on crates.io](https://crates.io/crates/matches)
(currently 37th in all-time downloads)
* The two previous points combined make it number one in
[left-pad index](https://twitter.com/bascule/status/1184523027888988160)
score
As such, I feel it is a good candidate for inclusion in the standard library.
In fact I already felt that way five years ago:
https://github.com/rust-lang/rust/pull/14685
(Although the proof of popularity was not as strong at the time.)
Back then, the main concern was that this macro may not be quite
universally-enough useful to belong in the prelude.
# API
Therefore, this PR adds the macro such that using it requires one of:
```
use core::macros::matches;
use std::macros::matches;
```
Like arms of a `match` expression,
the macro supports multiple patterns separated by `|`
and optionally followed by `if` and a guard expression:
```
let foo = 'f';
assert!(matches!(foo, 'A'..='Z' | 'a'..='z'));
let bar = Some(4);
assert!(matches!(bar, Some(x) if x > 2));
```
# Implementation constraints
A combination of reasons make it tricky
for a standard library macro not to be in the prelude.
Currently, all public `macro_rules` macros in the standard library macros
end up “in the prelude” of every crate not through `use std::prelude::v1::*;`
like for other kinds of items,
but through `#[macro_use]` on `extern crate std;`.
(Both are injected by `src/libsyntax_ext/standard_library_imports.rs`.)
`#[macro_use]` seems to import every macro that is available
at the top-level of a crate, even if through a `pub use` re-export.
Therefore, for `matches!` not to be in the prelude, we need it to be
inside of a module rather than at the root of `core` or `std`.
However, the only way to make a `macro_rules` macro public
outside of the crate where it is defined
appears to be `#[macro_export]`.
This exports the macro at the root of the crate
regardless of which module defines it.
See [macro scoping](
https://doc.rust-lang.org/reference/macros-by-example.html#scoping-exporting-and-importing)
in the reference.
Therefore, the macro needs to be defined in a crate
that is not `core` or `std`.
# Implementation
This PR adds a new `matches_macro` crate as a private implementation detail
of the standard library.
This crate is `#![no_core]` so that libcore can depend on it.
It contains a `macro_rules` definition with `#[macro_export]`.
libcore and libstd each have a new public `macros` module
that contains a `pub use` re-export of the macro.
Both the module and the macro are unstable, for now.
The existing private `macros` modules are renamed `prelude_macros`,
though their respective source remains in `macros.rs` files.
