Incorrect non-exhaustive pattern error

[tmiasko]

enum Next<I> where I: Iterator {
    Item(I::Item),
}

fn e(item: Next<&mut dyn Iterator<Item=Option<()>>>) {
    match item {
        Next::Item(None) => {}
        Next::Item(Some(())) => {}
    }
}

fn main() {}

Produces non-exhaustive pattern error (even though all patterns are covered):

error[E0004]: non-exhaustive patterns: `Item(_)` not covered
 --> main.rs:6:11
  |
1 | / enum Next<I> where I: Iterator {
2 | |     Item(I::Item),
  | |     ---- not covered
3 | | }
  | |_- `Next<&mut dyn std::iter::Iterator<Item = std::option::Option<()>>>` defined here
...
6 |       match item {
  |             ^^^^ pattern `Item(_)` not covered
  |
  = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms
  = note: the matched value is of type `Next<&mut dyn std::iter::Iterator<Item = std::option::Option<()>>>`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0004`.

Meta

rustc --version --verbose:

rustc 1.45.0-nightly (9310e3bd4 2020-05-21)
binary: rustc
commit-hash: 9310e3bd4f425f84fc27878ebf2bda1f30935a63
commit-date: 2020-05-21
host: x86_64-unknown-linux-gnu
release: 1.45.0-nightly
LLVM version: 10.0

[cuviper]

It passes on the playground with 1.43.1 and 1.44.0-beta.3

[lcnr]

Seems to be a problem when pattern matching on projections.

trait A {
    type Projection;
}

impl A for () {
    type Projection = bool;
    // using () instead of bool here does compile though
}

struct Next<T: A>(T::Projection);

fn e(item: Next<()>) {
    match item {
        Next(true) => {}
        Next(false) => {}
    }
}

fn main() {}

[tmiasko]

Related to changes from #71930, cc @Nadrieril.

[Nadrieril]

Ok, the problem comes from the fact that we get a pattern with type <() as A>::Projection instead of bool, and the exhaustiveness code isn't prepared to handle one of those. This type comes from listing the fields of Next<()> and calling field.ty() here. I know nothing of how type resolution is supposed to work, is there a step that was missed somewhere that should have turned this into bool? @matthewjasper you seemed to have a grasp on that.

It's a regression because of e5a2cd5. This commit keeps revealing weird quirks with types...

[matthewjasper]

You can try adding a normalize_erasing_regions call after field.ty().

[Nadrieril]

@matthewjasper This works! It feels patchy though: should I always call this before inspecting a type? Is it normal to find a non-normalized type at this stage of compilation? Do you know if there is a principled way I can be sure not to run into a similar bug later?

[LeSeulArtichaut]

Assigning P-critical as discussed as part of the Prioritization Working Group process.

[Nadrieril]

I have an easy workaround, should I push that first and we can investigate further later?

[LeSeulArtichaut]

@Nadrieril I believe you should, the technical details can be discussed as part of code review I think, and if performance tests need to be done, then you'll need a PR anyway.

[Nadrieril]

Here: #72506