Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --rust version: (tried in the playground) This compiles successfully on the stable and beta channels. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
prioritize nightly-to-beta regression
ICE bisected to searched nightlies: from nightly-2021-12-12 to nightly-2022-02-01 regressed nightly: nightly-2022-01-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
I'll take a stab at fixing this, unless (cc: ) wants to! claim feel free to steal this issue from me.
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 not sure if that makes sense goin forward?
So this is two bugs: 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... because 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.)
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
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. 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 (or at least gate its changes to path resolution behind the feature it introduces).
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
Cool! If you're gonna look into it, then I'll give the task to you. release-assignment
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

Related discussion:
text: // We have already adjusted the item name above, so compare with `ident.normalize_to_macros_2_0()` instead // of calling `filter_by_name_and_kind`. <del> let assoc_item = tcx .associated_items(candidate.def_id()) .filter_by_name_unhygienic(assoc_ident.name) .find(|i| { (i.kind == ty::AssocKind::Type || i.kind == ty::AssocKind::Const) && i.ident(tcx).normalize_to_macros_2_0() == assoc_ident }) </del> <ins> let find_item_of_kind = |kind| { tcx.associated_items(candidate.def_id()) .filter_by_name_unhygienic(assoc_ident.name) .find(|i| i.kind == kind && i.ident(tcx).normalize_to_macros_2_0() == assoc_ident) }; let assoc_item = find_item_of_kind(ty::AssocKind::Type) .or_else(|| find_item_of_kind(ty::AssocKind::Const)) </ins> .expect("missing associated type"); if !assoc_item.vis.is_accessible_from(def_scope, tcx) {