ignore higher-ranked object bound conditions created by WF
In the `issue-53548` test added in this PR, the `Box<dyn Trait>` type is expanded to `Box<dyn Trait + 'static>`, but the generator "witness" that results is `for<'r> { Box<dyn Trait + 'r> }`. The WF code was encountering an ICE (when debug-assertions were enabled) and an unexpected compilation error (without debug-asserions) when trying to process this `'r` region bound. In particular, to be WF, the region bound must meet the requirements of the trait, and hence we got `for<'r> { 'r: 'static }`. This would ICE because the `Binder` constructor we were using was assering that no higher-ranked regions were involved (because the WF code is supposed to skip those). The error (if debug-asserions were disabled) came because we obviously cannot prove that `'r: 'static` for any region `'r`. Pursuant with
our "lazy WF" strategy for higher-ranked regions, the fix is not to require that `for<'r> { 'r: 'static }` holds (this is also analogous to what we would do for higher-ranked regions appearing within the trait in other positions).
Fixes#53548
r? @pnkfelix
Reduces Code Repetitions like `!n >> amt`
Fixes#49937 .
This PR contains defining a function which operates bit inversion and reducing bit operation like `!0u128 >> (128 - size.bits())`.
Fix#54822 and associated faulty tests
Type checking associated constants can require trait bounds, but an empty
parameter environment was provided to the trait solver. Providing an
appropriate parameter environment seems to fix#54822 and also make one of the
cases in src/test/ui/nll/trait-associated-constant.rs that should compile
successfully do so. It also (slightly) improves the error message in
src/test/ui/associated-const/associated-const-generic-obligations.rs
Standardize `Range*` documentation
This updates the final example in the documentation for the types
`Range`, `RangeFrom`, `RangeFull`, `RangeInclusive`, `RangeTo`,
`RangeToInclusive`.
Use lifetime contravariance to elide more lifetimes in core+alloc+std
Sample:
```diff
- impl<'a, 'b, A: ?Sized, B: ?Sized> PartialEq<&'b mut B> for &'a mut A where A: PartialEq<B> {
+ impl<A: ?Sized, B: ?Sized> PartialEq<&mut B> for &mut A where A: PartialEq<B> {
#[inline]
- fn eq(&self, other: &&'b mut B) -> bool { PartialEq::eq(*self, *other) }
+ fn eq(&self, other: &&mut B) -> bool { PartialEq::eq(*self, *other) }
#[inline]
- fn ne(&self, other: &&'b mut B) -> bool { PartialEq::ne(*self, *other) }
+ fn ne(&self, other: &&mut B) -> bool { PartialEq::ne(*self, *other) }
}
```
[I didn't know this worked](https://internals.rust-lang.org/t/why-can-you-use-different-unconstrained-lifetimes-to-implement-traits/9544/2?u=scottmcm) until recently, but since defining methods contravariantly in their lifetimes this way has worked back to Rust 1.0, we might as well take advantage of combining it with IHLE.
Fix documentation of from_ne_bytes and from_le_bytes
Copypasta mistake, the documentation of `from_ne_bytes` and `from_le_bytes` used the big-endian variant in the example snippets.
Expand docs for `TryFrom` and `TryInto`.
The examples are still lacking for now, both for module docs and for methods/impl's. Will be adding those in further pushes.
Should hopefully resolve the doc concern in #33417 when finished?
In the `issue-53548` test added in this commit, the `Box<dyn Trait>`
type is expanded to `Box<dyn Trait + 'static>`, but the generator
"witness" that results is `for<'r> { Box<dyn Trait + 'r> }`. The WF
code was encountering an ICE (when debug-assertions were enabled) and
an unexpected compilation error (without debug-asserions) when trying
to process this `'r` region bound. In particular, to be WF, the region
bound must meet the requirements of the trait, and hence we got
`for<'r> { 'r: 'static }`. This would ICE because the `Binder`
constructor we were using was assering that no higher-ranked regions
were involved (because the WF code is supposed to skip those). The
error (if debug-asserions were disabled) came because we obviously
cannot prove that `'r: 'static` for any region `'r`. Pursuant with
our "lazy WF" strategy for higher-ranked regions, the fix is not to
require that `for<'r> { 'r: 'static }` holds (this is also analogous
to what we would do for higher-ranked regions appearing within the
trait in other positions).
Warning period for detecting nested impl trait
Here is some proposed code for making a warning period for the new checking of nested impl trait.
It undoes some of the corrective effects of PR #57730, by using boolean flags to track parts of the analysis that were previously skipped prior to PRs #57730 and #57981 landing.
Cc #57979
Filter away test annotations from UI test output
If you worked with UI tests for some time you could notice one issue affecting their readability and also readability of diffs when the tests change.
Look at the output of this test.
```rust
fn main() {
let 1 = 2; //~ ERROR refutable pattern in local binding
}
```
```
error[E0005]: refutable pattern in local binding: `-2147483648i32..=0i32` not covered
--> src/main.rs:2:9
|
2 | let 1 = 2; //~ ERROR refutable pattern in local binding
| ^ pattern `-2147483648i32..=0i32` not covered
error: aborting due to previous error
For more information about this error, try `rustc --explain E0005`.
```
You can see that the "refutable pattern in local binding" is duplicated.
One instance is the actual error, and the second instance is the expected error annotation.
This annotation is useful in the test input, but in the output it clutters the text and makes it harder to see what text refers to actual errors and what is just comments, especially if there are many errors in a single test file.
@estebank [reported](https://github.com/rust-lang/rust/pull/57379#discussion_r245523361) using the next trick to avoid the clutter
```rust
fn main() {
let 1 = 2;
//~^ ERROR refutable pattern in local binding
}
```
```
error[E0005]: refutable pattern in local binding: `-2147483648i32..=0i32` not covered
--> src/main.rs:2:9
|
2 | let 1 = 2;
| ^ pattern `-2147483648i32..=0i32` not covered
error: aborting due to previous error
For more information about this error, try `rustc --explain E0005`.
```
, i.e. using `//~^` and placing the annotation one line below will remove the annotation from the output.
However, this doesn't always works (consider errors with multi-line spans), and shouldn't be necessary in general!
`compiletest` could automatically filter away its own annotations from the output instead.
This is exactly what this PR does.
r? @davidtwco
