(Or more precisely, a pair of such traits: one for `derive(PartialEq)` and one
for `derive(Eq)`.)
((The addition of the second marker trait, `StructuralEq`, is largely a hack to
work-around `fn (&T)` not implementing `PartialEq` and `Eq`; see also issue
rust-lang/rust#46989; otherwise I would just check if `Eq` is implemented.))
Note: this does not use trait fulfillment error-reporting machinery; it just
uses the trait system to determine if the ADT was tagged or not. (Nonetheless, I
have kept an `on_unimplemented` message on the new trait for structural_match
check, even though it is currently not used.)
Note also: this does *not* resolve the ICE from rust-lang/rust#65466, as noted
in a comment added in this commit. Further work is necessary to resolve that and
other problems with the structural match checking, especially to do so without
breaking stable code (adapted from test fn-ptr-is-structurally-matchable.rs):
```rust
fn r_sm_to(_: &SM) {}
fn main() {
const CFN6: Wrap<fn(&SM)> = Wrap(r_sm_to);
let input: Wrap<fn(&SM)> = Wrap(r_sm_to);
match Wrap(input) {
Wrap(CFN6) => {}
Wrap(_) => {}
};
}
```
where we would hit a problem with the strategy of unconditionally checking for
`PartialEq` because the type `for <'a> fn(&'a SM)` does not currently even
*implement* `PartialEq`.
----
added review feedback:
* use an or-pattern
* eschew `return` when tail position will do.
* don't need fresh_expansion; just add `structural_match` to appropriate `allow_internal_unstable` attributes.
also fixed example in doc comment so that it actually compiles.
ignore uninhabited non-exhaustive variant fields
Fixes#65157.
This PR 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.
r? @arielb1
cc @varkor
Add by-value iterator for arrays
This adds an iterator that can iterate over arrays by value, yielding all elements by value. However, **this PR does _not_ add a corresponding `IntoIterator` impl for arrays**. The `IntoIterator` impl needs some discussion about backwards-compatibility that should take place in a separate PR. With this patch, this code should work (but there is currently still a bug):
```rust
#![feature(array_value_iter)]
use std::array::IntoIter;
let arr = [1, 2, 3];
for x in IntoIter::new(arr) {
println!("{}", x);
}
```
**TODO**:
- [x] Get initial feedback
- [x] Add tests
- [x] Figure out why stage1 produces weird bugs ([comment](https://github.com/rust-lang/rust/pull/62959#issuecomment-516016524))
- [x] Add UI tests as mentioned [here](https://github.com/rust-lang/rust/pull/62959#discussion_r307061894) (will do that soon-ish)
- [x] Fix [this new bug](https://github.com/rust-lang/rust/pull/62959#issuecomment-544732159)
**Notes for reviewers**
- Is the use of `MaybeUninit` correct here? I think it has to be used due to the `Clone` impl which has to fill the dead array elements with something, but cannot fill it with a correct instance.
- Are the unit tests sufficient?
CC #25725
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.
