Rust beta: "cannot infer type" when compiling `bottom` crate

[kamulos]

Not sure who is correct here, or if this is expected: I just compiled the bottom crate version 0.6.8. This worked with the stable compiler, but failed with the current beta. The error message is the following:

error[E0283]: type annotations needed
   --> src/canvas/dialogs/dd_dialog.rs:385:22
    |
380 | /                     if app_state.dd_err.is_some() {
381 | |                         vec![Constraint::Percentage(100)]
382 | |                     } else {
383 | |                         vec![Constraint::Min(3), Constraint::Length(btn_height)]
384 | |                     }
385 | |                     .as_ref(),
    | |______________________^^^^^^_- this method call resolves to `&T`
    |                        |
    |                        cannot infer type for type parameter `T` declared on the trait `AsRef`
    |
    = note: multiple `impl`s satisfying `Vec<Constraint>: AsRef<_>` found in the `alloc` crate:
            - impl<T, A> AsRef<Vec<T, A>> for Vec<T, A>
              where A: Allocator;
            - impl<T, A> AsRef<[T]> for Vec<T, A>
              where A: Allocator;

error[E0283]: type annotations needed
   --> src/canvas.rs:630:59
    |
630 |                         .constraints(self.row_constraints.as_ref())
    |                                      ---------------------^^^^^^--
    |                                      |                    |
    |                                      |                    cannot infer type for type parameter `T` declared on the trait `AsRef`
    |                                      this method call resolves to `&T`
    |
    = note: multiple `impl`s satisfying `Vec<Constraint>: AsRef<_>` found in the `alloc` crate:
            - impl<T, A> AsRef<Vec<T, A>> for Vec<T, A>
              where A: Allocator;
            - impl<T, A> AsRef<[T]> for Vec<T, A>
              where A: Allocator;

For more information about this error, try `rustc --explain E0283`.
error: could not compile `bottom` due to 2 previous errors

Meta

rustc --version --verbose:

rustc 1.61.0-beta.2 (7c13df853 2022-04-09)
binary: rustc
commit-hash: 7c13df853721b60a03e7c0bb084d2eb1e27a9caa
commit-date: 2022-04-09
host: x86_64-unknown-linux-gnu
release: 1.61.0-beta.2
LLVM version: 14.0.0

[ehuss]

This is almost certainly caused by #95098. cc @shepmaster

A smaller repro:

#[derive(Clone)]
struct Constraint;

fn constraints<C>(constraints: C)
where C: Into<Vec<Constraint>>
{
    let _: Vec<Constraint> = constraints.into();
}

fn main() {
    constraints(vec![Constraint].as_ref());
}

[dtolnay]

This bisects to 93313d1, so indeed #95098.

[apiraino]

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

@rustbot label -I-prioritize +P-high

[pnkfelix]

based on the injection point being #95098, isn't this a T-libs-api issue, not a T-compiler issue?

Switching tags under that assumption.

@rustbot label: -T-compiler +T-libs-api

[dtolnay]

For T-libs-api: I don't expect that we would choose to revert this. @rust-lang/libs-api

However it's not clear to me what type inference limitation makes the type unable to be inferred. Using the minimal repro from @ehuss, we have:

constraints(vec.as_ref());

Rustc can see that .as_ref() refers to core::convert::AsRef<T>::as_ref because there is no as_ref inherent method on Vec or any of the types it transitively derefs to, and AsRef is the only trait in scope with an as_ref method. The signature of AsRef::as_ref is fn as_ref(&self) -> &T and therefore the type of vec.as_ref() is &T for some T, as long as Vec<Constraint>: AsRef<T>.

The possibilities for Vec<Constraint>: AsRef<T> are T = [Constraint] and T = Vec<Constraint>.

Then it sees calling constraints::<&T> requires &T: Into<Vec<Constraint>> due to the where-clause. Previously this was satisfiable only by T = [Constraint] whereas after #95098 it's also satisfiable by T = [Constraint; N].

Is it computationally hard to deduce from this that T = [Constraint]? As someone who doesn't know the type inference implementation in detail, my impression is this seems in line with inference that rustc is able to do successfully in other situations.

[yaahc]

However it's not clear to me what type inference limitation makes the type unable to be inferred. Using the minimal repro from @ehuss, we have:

I recall some special cases in candidate assembly for allowing inference to continue when there is only one unambiguous impl, if I had to guess I'd say this is the same issue as #90904.

I'm trying to find the special case, I think this might be it but I'm not sure:

rust/compiler/rustc_trait_selection/src/traits/select/candidate_assembly.rs

Lines 140 to 156 in b04c532

	// If there is more than one candidate, first winnow them down
	// by considering extra conditions (nested obligations and so
	// forth). We don't winnow if there is exactly one
	// candidate. This is a relatively minor distinction but it
	// can lead to better inference and error-reporting. An
	// example would be if there was an impl:
	//
	// impl<T:Clone> Vec<T> { fn push_clone(...) { ... } }
	//
	// and we were to see some code `foo.push_clone()` where `boo`
	// is a `Vec<Bar>` and `Bar` does not implement `Clone`. If
	// we were to winnow, we'd wind up with zero candidates.
	// Instead, we select the right impl now but report "`Bar` does
	// not implement `Clone`".
	if candidates.len() == 1 {
	return self.filter_reservation_impls(candidates.pop().unwrap(), stack.obligation);
	}

Sadly I don't understand this well enough either to really understand whats going on. I think there's some rule in the compiler (maybe the bit above) that lets the ambiguous type parameter for AsRef to be inferred off of the type of the single candidate for From when there's only one, but as soon as you have two, even if only one of them is actually applicable, it ends up erroring out earlier and never uses the From impls to attempt to select an AsRef impl.