Specifically, this part of resolving associated fn/consts:
|
// Since this is a trait item, we need to see if the item is either a trait default item |
|
// or a specialization because we can't resolve those unless we can `Reveal::All`. |
|
// NOTE: This should be kept in sync with the similar code in |
|
// `rustc::traits::project::assemble_candidates_from_impls()`. |
|
let eligible = if !resolved_item.defaultness.is_default() { |
|
true |
|
} else if param_env.reveal == traits::Reveal::All { |
|
!trait_ref.needs_subst() |
|
} else { |
|
false |
|
}; |
Is missing this logic deciding whether an associated item is default:
|
let is_default = if node_item.node.is_from_trait() { |
|
// If true, the impl inherited a `type Foo = Bar` |
|
// given in the trait, which is implicitly default. |
|
// Otherwise, the impl did not specify `type` and |
|
// neither did the trait: |
|
// |
|
// ```rust |
|
// trait Foo { type T; } |
|
// impl Foo for Bar { } |
|
// ``` |
|
// |
|
// This is an error, but it will be |
|
// reported in `check_impl_items_against_trait`. |
|
// We accept it here but will flag it as |
|
// an error when we confirm the candidate |
|
// (which will ultimately lead to `normalize_to_error` |
|
// being invoked). |
|
false |
|
} else { |
|
// If we're looking at a trait *impl*, the item is |
|
// specializable if the impl or the item are marked |
|
// `default`. |
|
node_item.item.defaultness.is_default() |
|
|| super::util::impl_is_default(selcx.tcx(), node_item.node.def_id()) |
|
}; |
Just from looking at the code (as I can't get the MIR of this example to constant-fold that associated const into the function, so I can't test any of this), this would likely mishandle default impl (instead of default on the associated item inside the impl).
cc @wesleywiser @nikomatsakis
