This commit modifies the uninhabitedness checking so that the fields of
a non-exhaustive variant (which is not local) are ignored if they are
uninhabited. This is an improvement over the previous behaviour which
considered all non-local non-exhaustive variants useful because
unreachable patterns are now detected.
Signed-off-by: David Wood <david@davidtw.co>
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.
It was allocating a new OsString that was immediately dropped after
using it with set_file_name. Now it directly changes the extension in
the original buffer, without touching the rest of the file name or
allocating a temporary string.
# 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.
Rollup of 14 pull requests
Successful merges:
- #64145 (Target-feature documented as unsafe)
- #65007 (Mention keyword closing policy)
- #65417 (Add more coherence tests)
- #65507 (Fix test style in unused parentheses lint test)
- #65591 (Add long error explanation for E0588)
- #65617 (Fix WASI sleep impl)
- #65656 (Add option to disable keyboard shortcuts in docs)
- #65678 (Add long error explanation for E0728)
- #65681 (Code cleanups following up on #65576.)
- #65686 (refactor and move `maybe_append` )
- #65688 (Add some tests for fixed ICEs)
- #65689 (bring back some Debug instances for Miri)
- #65695 (self-profiling: Remove module names from some event-ids in codegen backend.)
- #65706 (Add missing space in librustdoc)
Failed merges:
r? @ghost
self-profiling: Remove module names from some event-ids in codegen backend.
Event-IDs are not supposed to contain argument values. Event-IDs are the equivalent of function names. Proper support for parameters will be added to self-profiling down the line.
This PR fixes an oversight from https://github.com/rust-lang/rust/pull/64840.
r? @wesleywiser
bring back some Debug instances for Miri
These were erroneously removed in https://github.com/rust-lang/rust/pull/65647, but Miri needs them.
r? @Centril Cc @nnethercote @oli-obk
Add some tests for fixed ICEs
Fixes#41366 from 1.35.0
Fixes#51431 from 1.31.0-nightly (77af31408 2018-10-11) (on my local)
Fixes#52437 from nightly
Fixes#63496 from nightly
r? @Centril
Fix test style in unused parentheses lint test
I think this fixes#63237
I'm not sure if I had to add text after the `//~ ERROR` comments.
This is my first pull request, so I'm open to feedback.
This issues already received one pull request [here](https://github.com/rust-lang/rust/pull/63257) but it was marked as closed for inactivity.
r? @nikomatsakis
Add more coherence tests
I've wrote the missing test cases listed in [this google doc](https://docs.google.com/spreadsheets/d/1WlroTEXE6qxxGvEOhICkUpqguYZP9YOZEvnmEtSNtM0/edit#gid=0)
> The other thing that might be useful is to rename the existing tests so they all fit the new naming scheme we were using.
I'm not entirely sure how to do this. If everything from the google sheet is covered could I just remove the remaining tests in `src/test/ui/coherence` or is there something in there that should remain?
cc #63599
r? @nikomatsakis
Mention keyword closing policy
closes#59233 / https://github.com/rust-lang/rust/issues/59233#issuecomment-478362693
rewording suggestions welcome
> Also in the referenced issue, the commit number of the new commit
> that could close that issue is not really informative. The PR number itself appeared in the issue
> is more informative and concise.
@lzutao what do you mean with that? Is this fixed by the new "May be fixed by #XXXXX"?
