Instance::resolve doesn't have the exact same checks as associated type projection.

[eddyb]

Specifically, this part of resolving associated fn/consts:

rust/src/librustc_ty/instance.rs

Lines 90 to 100 in a17dd36

	// 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:

rust/src/librustc_trait_selection/traits/project.rs

Lines 1018 to 1042 in a17dd36

	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