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

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

@shepmaster

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());
}

This bisects to 93313d1, so indeed #95098.

@rustbot

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

@rustbot label -I-prioritize +P-high

@rustbot

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

@ehuss

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.

@ehuss

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.

bug: change as_ref calls so rust beta 1.61 builds

bug: change as_ref() to build in Rust beta 1.61.0 (#711)

I think making inference even 'smarter' is just going to lead to more code that implicitly relies on certain impls not existing, which will ultimately prohibit more impls from being added because some ambiguities just cannot be resolved cleanly.

I would much rather see existing code that relies on there's-only-one-impl-for cleverness start raising future-incompat errors. Maybe we could even have impl Add<char> for String and friends at some point then.

@rustbot

Visiting this issue during T-compiler triage meeting.

We believe the beta backport of PR #96489 addresses the issue this was nominated for.

@rustbot label: -I-nominated-compiler

@rustbot

:)

@rustbot label -I-compiler-nominated

Clearing milestone as we have landed #96489 on master (1.62+) and backported it to 1.61, so this is no longer a regression.

Triage: The revert is done and consensus seems to be to not change inference. Closing.

Navigation Menu

Repository navigation

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

Meta

20 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	// 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);
	}

Rust beta: "cannot infer type" when compiling bottom crate #96074

Description

Meta

Activity

ehuss commented on Apr 15, 2022

dtolnay commented on Apr 16, 2022

apiraino commented on Apr 20, 2022

pnkfelix commented on Apr 21, 2022

dtolnay commented on Apr 21, 2022

yaahc commented on Apr 21, 2022

20 remaining items

jplatte commented on Apr 28, 2022

pnkfelix commented on May 5, 2022

apiraino commented on May 5, 2022

Mark-Simulacrum commented on May 15, 2022

Enselic commented on Mar 16, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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