internal compiler error when inferring `_` type for Associated Type bound

[woodsmur]

Rust compiler error for simple code like this:

Code

playaround

trait Database: Restriction<Inner = u32> {}

trait Restriction {
    type Inner;
}

struct Test {}

impl Database for Test {}
impl Restriction for Test {
    type Inner = u32;
}

fn main() {
    let t = Test {};
    let x: &Database<Inner = _> = &t;
}

Meta

rustc --version --verbose:

rustc 1.48.0 (7eac88abb 2020-11-16)
binary: rustc
commit-hash: 7eac88abb2e57e752f3302f02be5f3ce3d7adfb4
commit-date: 2020-11-16
host: x86_64-apple-darwin
release: 1.48.0
LLVM version: 11.0

Error output

   Compiling aaaa v0.1.0 (/Users/dudu/tmp/aaaa)
warning: trait objects without an explicit `dyn` are deprecated
  --> src/main.rs:16:13
   |
16 |     let x: &Database<Inner = _> = &t;
   |             ^^^^^^^^^^^^^^^^^^^ help: use `dyn`: `dyn Database<Inner = _>`
   |
   = note: `#[warn(bare_trait_objects)]` on by default

warning: unused variable: `x`
  --> src/main.rs:16:9
   |
16 |     let x: &Database<Inner = _> = &t;
   |         ^ help: if this is intentional, prefix it with an underscore: `_x`
   |
   = note: `#[warn(unused_variables)]` on by default

warning: Error finalizing incremental compilation session directory `/Users/dudu/tmp/aaaa/target/debug/incremental/aaaa-3t9641te2lvvd/s-ftkew3bbem-6oinlz-working`: No such file or directory (os error 2)

warning: 3 warnings emitted

error: internal compiler error: broken MIR in DefId(0:10 ~ aaaa[fab6]::main) (CanonicalUserTypeAnnotation { user_ty: Canonical { max_universe: U0, variables: [CanonicalVarInfo { kind: Region(U0) }, CanonicalVarInfo { kind: Ty(General(U0)) }, CanonicalVarInfo { kind: Region(U0) }], value: Ty(&dyn Database<Inner = ^1_1, Inner = u32>) }, span: src/main.rs:16:12: 16:32 (#0), inferred_ty: &dyn Database<Inner = u32, Inner = u32> }): bad user type (&dyn Database<Inner = _, Inner = u32> = &dyn Database<Inner = u32, Inner = u32>): NoSolution
  |
  = note: delayed at compiler/rustc_mir/src/borrow_check/type_check/mod.rs:258:27

thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', compiler/rustc_errors/src/lib.rs:961:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.48.0 (7eac88abb 2020-11-16) running on x86_64-apple-darwin

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type bin

note: some of the compiler flags provided by cargo are hidden

error: could not compile `aaaa`

To learn more, run the command again with --verbose.

Backtrace

``` ```

[matthiaskrgr]

@rustbot prioritize

[matthiaskrgr]

Reproduces on stable 1.48.0 beta 1.49.0-beta.2 nightly 1.50.0 (1c389ffef 2020-11-24)

[matthiaskrgr]

The ICE triggers since 1.45

[matthiaskrgr]

@rustbot label +regression-from-stable-to-stable

[camelid]

Assigning P-high and removing I-prioritize as discussed in the prioritization working group.

[camelid]

@rustbot glacier "https://gist.github.com/rust-play/27c280d0e5bba7174cf90a120019a279"

[osa1]

I'm trying to debug this and have a question on Zulip (also copied to internals). If anyone have any pointers that would be helpful.

[osa1]

I found the code where we add the duplicate Inner = _ predicate mentioned in the Zulip and internals links above, and confirmed that if I don't add the duplicate the program compiles fine. I'm not 100% sure this is the root cause but I think having two predicates for the same associated type doesn't make sense so I'm hopeful.

If I remove the code block that adds the duplicate predicate I get 8 UI test failures. I'll try to figure out why that code exists by looking at failing tests now.

[lcnr]

@rustbot claim

[pnkfelix]

Visiting for P-high review

@lcnr is there a roadmap for resolving this? Should we open it up for other people to claim?

(The error does seem like it remains P-high worthy, since I can imagine this to be pretty frustrating to someone since it doesn't print any diagnostic info guiding them towards even the obvious workaround of plugging in u32 for the _ type)

[lcnr]

The issue here is that the associated type bound is redundant, we're specifying Inner on Database even though that one is already fully constrained by the trait definition of Database itself.

I don't think it necessarily needs a roadmap, I expect it to be a fairly self-contained - if complex - fix.

[compiler-errors]

I've taken a look at this in the past but I can again 👀