Make the "main" constructors of NonZero/Shared/Unique return Option
Per discussion in https://github.com/rust-lang/rust/issues/27730#issuecomment-303939441.
This is a breaking change to unstable APIs.
The old behavior is still available under the name `new_unchecked`. Note that only that one can be `const fn`, since `if` is currently not allowed in constant contexts.
In the case of `NonZero` this requires adding a new `is_zero` method to the `Zeroable` trait. I mildly dislike this, but it’s not much worse than having a `Zeroable` trait in the first place. `Zeroable` and `NonZero` are both unstable, this can be reworked later.
Point at `:` when using it instead of `;`
When triggering type ascription in such a way that we can infer a
statement end was intended, add a suggestion for the change. Always
point out the reason for the expectation of a type is due to type
ascription.
Fix#42057, #41928.
Less verbose output for unused arguments
Closes#37718
This is my first contribution to rust, so sorry if I'm missing anything!
The output now looks like this:
<img width="831" alt="screen shot 2017-07-18 at 5 01 32 pm" src="https://user-images.githubusercontent.com/12972285/28347566-dbfa9962-6c05-11e7-8730-c2e8062a04cc.png">
It's not the prettiest, but whenever #41850 gets resolved, this should be able to be improved.
**EDIT:** This also does not seem
r? @Mark-Simulacrum
Now there's a way to add suggestions that hide the suggested code when
presented inline, to avoid weird wording when short code snippets are
added at the end.
The produced paths aren't stable between builds, since
reporting paths inside resolve, before resolve is finished
might produce paths resolved to type aliases instead of
the concrete type.
Compile-fail tests can match just parts of messages, so they
don't "suffer" from this issue.
This is just a workaround, the instability should be fixed
in the future.
When triggering type ascription in such a way that we can infer a
statement end was intended, add a suggestion for the change. Always
point out the reason for the expectation of a type is due to type
ascription.
We want the suggested replacement (which IDE tooling and such might offer to
automatically swap in) to, like, actually be correct: suggesting `MyVariant(x)`
when the actual fix is `MyEnum::MyVariant(x)` might be better than nothing, but
Rust is supposed to be the future of computing: we're better than better than
nothing.
As an exceptional case, we excise the prelude path, preferring to suggest
`Some` or `Ok` rather than `std::prelude::v1::Some` and
`std::prelude::v2::Ok`. (It's not worth the effort to future-proof against
hypothetical preludes v2, v3, &c.: we trust our successors to grep—excuse me,
ripgrep—for that.)
Also, don't make this preëmpt the existing probe-for-return-type suggestions,
despite their being looked unfavorably upon, at least in this situation
(https://github.com/rust-lang/rust/issues/42764#issuecomment-311388958): Cody
Schafer pointed out that that's a separate issue
(https://github.com/rust-lang/rust/pull/43178#issuecomment-314953229).
This is in the matter of #42764.
`rustc_on_unimplemented` supports referring to trait
Add support to `rustc_on_unimplemented` to reference the full path of
the annotated trait. For the following code:
```rust
pub mod Bar {
#[rustc_on_unimplemented = "test error `{Self}` with `{Bar}` `{Baz}` `{Quux}` in `{Foo}`"]
pub trait Foo<Bar, Baz, Quux> {}
}
```
the error message will be:
```
test error `std::string::String` with `u8` `_` `u32` in `Bar::Foo`
```
Fold E0612, E0613 into E0609
As discussed in #42945, with PR 1506 tuple indices are no longer considered a separate case from normal field. This PR folds E06012 ("tuple index out of bounds") and E0613 ("type is not a tuple") into E0609 ("type does not have field with that name")
Resolves#42945
When there're more than one suggestions in the same diagnostic, they are
displayed in their own block, instead of inline. In order to reduce
confusion, those blocks now display the line number.
Add support to `rustc_on_unimplemented` to reference the full path of
the annotated trait. For the following code:
```rust
pub mod Bar {
#[rustc_on_unimplemented = "test error `{Self}` with `{Bar}` `{Baz}` `{Quux}` in `{Foo}`"]
pub trait Foo<Bar, Baz, Quux> {}
}
```
the error message will be:
```
test error `std::string::String` with `u8` `_` `u32` in `Bar::Foo`
```
Prior to this PR, when we aborted because a "critical pass" failed, we
displayed the number of errors from that critical pass. While that's the
number of errors that caused compilation to abort in *that place*,
that's not what people really want to know. Instead, always report the
total number of errors, and don't bother to track the number of errors
from the last pass that failed.
This changes the compiler driver API to handle errors more smoothly,
and therefore is a compiler-api-[breaking-change].
Fixes#42793.
Adding diagnostic code 0611 for lifetime errors with one named, one anonymous lifetime parameter
This is a fix for #42517
Note that this only handles the above case for **function declarations** and **traits**.
`impl items` and `closures` will be handled in a later PR.
Example
```
fn foo<'a>(x: &i32, y: &'a i32) -> &'a i32 {
if x > y { x } else { y }
}
```
now displays the following error message. ui tests have been added for the same.
```
error[E0611]: explicit lifetime required in the type of `x`
11 | fn foo<'a>(x: &i32, y: &'a i32) -> &'a i32 {
| ^ consider changing the type of `x` to `&'a i32`
12 | if x > y { x } else { y }
| - lifetime `'a` required
```
#42516
r? @nikomatsakis
Coerce fields to the expected field type
Fully fixes#31260.
This needs a crater run. I was supposed to do this last month but it slipped. Let's get this done.
