In general having all these different structs for "origins" is not
great, since equating types can cause obligations and vice-versa. I
think we should gradually collapse these things. We almost certainly
also need to invest a big more energy into the `error_reporting` code to
rationalize it: this PR does kind of the minimal effort in that
direction.
[8/n] rustc: clean up lookup_item_type and remove TypeScheme.
_This is part of a series ([prev](https://github.com/rust-lang/rust/pull/37676) | [next]()) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https://github.com/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well.
If any motivation is unclear, please ask for additional PR description clarifications or code comments._
<hr>
* `tcx.tcache` -> `tcx.item_types`
* `TypeScheme` (grouping `Ty` and `ty::Generics`) is removed
* `tcx.item_types` entries no longer duplicated in `tcx.tables.node_types`
* `tcx.lookup_item_type(def_id).ty` -> `tcx.item_type(def_id)`
* `tcx.lookup_item_type(def_id).generics` -> `tcx.item_generics(def_id)`
* `tcx.lookup_generics(def_id)` -> `tcx.item_generics(def_id)`
* `tcx.lookup_{super_,}predicates(def_id)` -> `tcx.item_{super_,}predicates(def_id)`
Don't provide hint to add lifetime on impl items that implement a trait.
```rust
use std::str::FromStr;
pub struct Foo<'a> {
field: &'a str,
}
impl<'a> FromStr for Foo<'a> {
type Err = ();
fn from_str(path: &str) -> Result<Self, ()> {
Ok(Foo { field: path })
}
}
```
would give the following hint:
```nocode
help: consider using an explicit lifetime parameter as shown: fn from_str(path: &'a str) -> Result<Self, ()>
--> <anon>:9:5
|
9 | fn from_str(path: &str) -> Result<Self, ()> {
| ^
```
which is never correct, since then there will be a lifetime mismatch
between the impl and the trait.
Remove this hint for impl items that implement a trait.
Most of the Rust community agrees that the vec! macro is clearer when
called using square brackets [] instead of regular brackets (). Most of
these ocurrences are from before macros allowed using different types of
brackets.
There is one left unchanged in a pretty-print test, as the pretty
printer still wants it to have regular brackets.
`#[may_dangle]` attribute
`#[may_dangle]` attribute
Second step of #34761. Last big hurdle before we can work in earnest towards Allocator integration (#32838)
Note: I am not clear if this is *also* a syntax-breaking change that needs to be part of a breaking-batch.
Introduce the possibility of assigning distinct error codes to the various origin types of E0308. Start by assigning E0317 for the "IfExpressionWithNoElse" case, and write a long diagnostic specific to this case.
Fixes#36596
When a type parameter shadows a primitive type, the error message
was non obvious. For example, given the file `file.rs`:
```rust
trait Parser<T> {
fn parse(text: &str) -> Option<T>;
}
impl<bool> Parser<bool> for bool {
fn parse(text: &str) -> Option<bool> {
Some(true)
}
}
fn main() {
println!("{}", bool::parse("ok").unwrap_or(false));
}
```
The output was:
```bash
% rustc file.rs
error[E0308]: mismatched types
--> file.rs:7:14
|
7 | Some(true)
| ^^^^ expected type parameter, found bool
|
= note: expected type `bool`
= note: found type `bool`
error: aborting due to previous error
```
We now show extra information about the type:
```bash
% rustc file.rs
error[E0308]: mismatched types
--> file.rs:7:14
|
7 | Some(true)
| ^^^^ expected type parameter, found bool
|
= note: expected type `bool` (type parameter)
= note: found type `bool` (bool)
error: aborting due to previous error
```
Fixes#35030
Unfortunately, projection errors do not come with a nice set of
mismatched types. This is because the type equality check occurs
within a higher-ranked context. Therefore, only the type error
is reported. This is ugly but was always the situation.
I will introduce better errors for the lower-ranked case in
another commit.
Fixes the last known occurence of #31173
Casual grepping revealed some places in the codebase (some of which
antedated `if let`'s December 2014 stabilization in c200ae5a) where we
were using a match with a `None => ()` arm where (in the present
author's opinion) an `if let` conditional would be more readable. (Other
places where matching to the unit value did seem to better express the
intent were left alone.)
It's likely that we don't care about making such trivial,
non-functional, sheerly æsthetic changes.
But if we do, this is a patch.
When we do a "HR subtype" check, we replace all late-bound regions (LBR)
in the subtype with fresh variables, and skolemize the late-bound
regions in the supertype. If those skolemized regions from the supertype
wind up being super-regions (directly or indirectly) of either
- another skolemized region; or,
- some region that pre-exists the HR subtype check
- e.g., a region variable that is not one of those created
to represent bound regions in the subtype
then the subtype check fails.
What will change when we fix#32330 is that some of the LBR in the
subtype may become early-bound. In that case, they would no longer be in
the "permitted set" of variables that can be related to a skolemized
type.
So the foundation for this warning is to collect variables that we found
to be related to a skolemized type. For each of them, we have a
`BoundRegion` which carries a `Issue32330` flag. We check whether any of
those flags indicate that this variable was created from a lifetime
that will change from late- to early-bound. If so, we issue a warning
indicating that the results of compilation may change.
This is imperfect, since there are other kinds of code that will not
compile once #32330 is fixed. However, it fixes the errors observed in
practice on crater runs.
This indicates whether this `BoundRegion` will change from late to early
bound when issue 32330 is fixed. It also indicates the function on
which the lifetime is declared.
Currently, we consider region subtyping a failure
if a skolemized lifetime is relatable to any
other lifetime in any way at all. But a more precise
formulation is to say that a skolemized lifetime:
- must not have any *incoming* edges in the region graph
- only has *outgoing* edges to nodes that are `'static`
To enforce the latter requirement, we add edges from `'static -> 'x` for
each lifetime '`x' reachable from a skolemized region.
We now have to add a new `pop_skolemized` routine to do cleanup.
Whereas before if there were *any* edges relating to a skolemized
region, we would return `Err` and hence rollback the transaction, we now
tolerate some edges and return `Ok`. Therefore, the `pop_skolemized`
routine runs and cleans up those edges.
Fix for old school error issues, improvements to new school
This PR:
* Fixes some old school error issues, specifically #33559, #33543, #33366
* Improves wording borrowck errors with match patterns
* De-emphasize multi-line spans, so we don't color the single source character when we're trying to say "span starts here"
* Rollup of #33392 (which should help fix#33390)
r? @nikomatsakis
