Associated const with supertrait associated type (named the same) causes ICE

[rodrimati1992]

Code

trait Foo {
    type Bar;
}

trait Baz: Foo {
    const Bar: Self::Bar;
}

Meta

rust version:

1.60.0-nightly (2022-01-31 498eeb72f590e518e197)

(tried in the play.rust-lang.org playground)

This compiles successfully on the stable and beta channels.

Error output

error[E0221]: ambiguous associated type `Bar` in bounds of `Self`
 --> src/lib.rs:6:16
  |
2 |     type Bar;
  |     --------- ambiguous `Bar` from `Foo`
...
6 |     const Bar: Self::Bar;
  |                ^^^^^^^^^ ambiguous associated type `Bar`
  |
  = note: associated type `Self` could derive from `Baz`
help: use fully qualified syntax to disambiguate
  |
6 |     const Bar: <Self as Foo>::Bar;
  |                ~~~~~~~~~~~~~~~

thread 'rustc' panicked at 'missing associated type', compiler/rustc_typeck/src/astconv/mod.rs:1886:14
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.60.0-nightly (498eeb72f 2022-01-31) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C codegen-units=1 -C debuginfo=2 --crate-type lib

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

query stack during panic:
#0 [type_of] computing type of `Baz::Bar`
#1 [collect_mod_item_types] collecting item types in top-level module
end of query stack
For more information about this error, try `rustc --explain E0221`.
error: could not compile `playground` due to previous error

Backtrace

thread 'rustc' panicked at 'missing associated type', compiler/rustc_typeck/src/astconv/mod.rs:1886:14
stack backtrace:
   0: rust_begin_unwind
             at /rustc/498eeb72f590e518e19746b346be53713689e207/library/std/src/panicking.rs:577:5
   1: core::panicking::panic_fmt
             at /rustc/498eeb72f590e518e19746b346be53713689e207/library/core/src/panicking.rs:135:14
   2: core::panicking::panic_display
             at /rustc/498eeb72f590e518e19746b346be53713689e207/library/core/src/panicking.rs:65:5
   3: core::panicking::panic_str
             at /rustc/498eeb72f590e518e19746b346be53713689e207/library/core/src/panicking.rs:56:5
   4: core::option::expect_failed
             at /rustc/498eeb72f590e518e19746b346be53713689e207/library/core/src/option.rs:1840:5
   5: <dyn rustc_typeck::astconv::AstConv>::associated_path_to_ty
   6: <dyn rustc_typeck::astconv::AstConv>::ast_ty_to_ty_inner
   7: rustc_typeck::collect::type_of::type_of
   8: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::type_of
   9: <rustc_typeck::collect::CollectItemTypesVisitor as rustc_hir::intravisit::Visitor>::visit_trait_item
  10: <rustc_middle::hir::map::Map>::visit_item_likes_in_module::<rustc_hir::intravisit::DeepVisitor<rustc_typeck::collect::CollectItemTypesVisitor>>
  11: rustc_typeck::collect::collect_mod_item_types
  12: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::plumbing::QueryCtxt, rustc_query_system::query::caches::DefaultCache<rustc_span::def_id::LocalDefId, ()>>
  13: rustc_query_system::query::plumbing::get_query::<rustc_query_impl::queries::collect_mod_item_types, rustc_query_impl::plumbing::QueryCtxt>
  14: <rustc_middle::hir::map::Map>::for_each_module::<rustc_typeck::check_crate::{closure#0}::{closure#0}::{closure#0}>
  15: <rustc_session::session::Session>::track_errors::<rustc_typeck::check_crate::{closure#0}, ()>
  16: rustc_typeck::check_crate
  17: rustc_interface::passes::analysis
  18: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::plumbing::QueryCtxt, rustc_query_system::query::caches::DefaultCache<(), core::result::Result<(), rustc_errors::ErrorReported>>>
  19: rustc_query_system::query::plumbing::get_query::<rustc_query_impl::queries::analysis, rustc_query_impl::plumbing::QueryCtxt>
  20: <rustc_interface::passes::QueryContext>::enter::<rustc_driver::run_compiler::{closure#1}::{closure#2}::{closure#3}, core::result::Result<(), rustc_errors::ErrorReported>>
  21: <rustc_interface::interface::Compiler>::enter::<rustc_driver::run_compiler::{closure#1}::{closure#2}, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_errors::ErrorReported>>
  22: rustc_span::with_source_map::<core::result::Result<(), rustc_errors::ErrorReported>, rustc_interface::interface::create_compiler_and_run<core::result::Result<(), rustc_errors::ErrorReported>, rustc_driver::run_compiler::{closure#1}>::{closure#1}>
  23: rustc_interface::interface::create_compiler_and_run::<core::result::Result<(), rustc_errors::ErrorReported>, rustc_driver::run_compiler::{closure#1}>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[matthiaskrgr]

@rustbot prioritize nightly-to-beta regression

[apiraino]

ICE bisected to

searched nightlies: from nightly-2021-12-12 to nightly-2022-02-01
regressed nightly: nightly-2022-01-19
searched commit range: ee5d8d3...9ad5d82
regressed commit: 7bc7be8

bisected with cargo-bisect-rustc v0.6.1

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --start=2021-12-12 

[compiler-errors]

I'll take a stab at fixing this, unless @JulianKnodt (cc: #87648) wants to!

@rustbot claim
feel free to steal this issue from me.

[JulianKnodt]

Hmmm actually this might make sense to be a miscompilation now, since it is kind of ambiguous. We probably should default to the old behavior, but @oli-obk not sure if that makes sense goin forward?

[compiler-errors]

So this is two bugs:

1. The associated type resolution is ambiguous, because of the conflict between the associated const and the associated type. Probably needs reworking path resolution to prefer types in type position...
2. ICE because associated_path_to_ty only looks for associated types instead of types and consts.

I know how to fix (2.), but I'll try to see if I can include something for (1.) as well... Otherwise I'll just put up the one-liner for (2.)

[JulianKnodt]

mmm ok this is fair enough,

edit: I guess I was just more worried that we'd have to introduce preference for types/consts here which may not have been defined previously

[compiler-errors]

Yeah, my understanding is that types and consts occupy mutually-exclusive positions in well-formed code, but we might not currently have the right information piped into path resolution to prefer resolving one over the other in cases like this.

To demonstrate the issue, here is another regression in path resolution, which passes on Stable and fails on Nightly. Not an ICE, but not sure if we should be breaking existing code that compiles.

trait Foo {
    type Bar;
}

trait Baz: Foo {
    const Bar: u32;
    
    fn foo() -> Self::Bar;
}

Happy to help work out a fix-forward, or defer that work to you if you're interested in whipping up a fix. Otherwise we might need to roll back #87648 (or at least gate its changes to path resolution behind the feature it introduces).

[JulianKnodt]

since this only affects nightly, as long as we put in a fix, it should be ok to not rollback, I can try to look into that

[compiler-errors]

Cool! If you're gonna look into it, then I'll give the task to you.

@rustbot release-assignment

[JulianKnodt]

@rustbot claim

[apiraino]

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-medium