Address inconsistency in using "is" with "declared here"
"is" was generally used for NLL diagnostics, but not other diagnostics. Using "is" makes the diagnostics sound more natural and readable, so it seems sensible to commit to them throughout.
r? @Centril
`TooGeneric` is encountered during WF checking when we cannot determine that a constant involving a generic parameter will always be evaluated successfully (rather than resulting in an error). In these cases, the burden of proof should be with the caller, so that we can avoid post-monomorphisation tim errors (which was the previous previous behaviour). This commit ensures that this situation produces a proper compiler error, rather than silently ignoring it or ICEing.
No functional changes are made, and all APIs are moved to strictly less
restrictive bounds.
These APIs changed from the old bound listed to the new bound:
T: Hash + Eq -> T
* new
* with_capacity
T: Eq + Hash, S: BuildHasher -> T
* with_hasher
* with_capacity_and_hasher
* hasher
T: Eq + Hash + Debug -> T: Debug
S: BuildHasher -> S
<HashSet as Debug>
T: Eq + Hash -> T
S: BuildHasher + Default -> S: Default
<HashSet as Default>
Add regression tests for fixed ICEs
Closes#61747 (fixed from 1.41.0-nightly (4007d4ef2 2019-12-01))
Closes#66205 (fixed from 1.41.0-nightly (4007d4ef2 2019-12-01))
Closes#66270 (fixed by #66246)
Closes#67424 (fixed by #67160)
Also picking a minor nit up from #67071 with 101dd7bad9
r? @Centril
This purges uses of uninitialized where possible from test cases. Some
are merely moved over to the equally bad pattern of
MaybeUninit::uninit().assume_init() but with an annotation that this is
"the best we can do".
Validate error patterns and error annotation in ui tests when present
Previously, when compilation succeeded, neither error patterns nor error
annotation would be validated. Additionally, when compilation failed,
only error patterns would be validated if both error patterns and error
annotation were present.
Now both error patterns and error annotation are validated when present,
regardless of compilation status. Furthermore, for test that should run,
the error patterns are matched against executable output, which is what
some of tests already expect to happen, and when #65506 is merged even
more ui tests will.
Fixes#56277
Those annotation are silently ignored rather than begin validated
against compiler output. Update them before validation is enabled,
to avoid test failures.
Point at the span for the definition of ADTs internal to the current
crate.
Look at the leading char of the ident to determine whether we're
expecting a likely fn or any of a fn, a tuple struct or a tuple variant.
Turn fn `add_typo_suggestion` into a `Resolver` method.
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
