better error message when ? is applied to collect()

[nikomatsakis]

This code:

fn main() -> Result<(), ()> {
    vec![Ok(2)].into_iter().collect()?;
    Ok(())
}

gives a terrible error:

error[E0284]: type annotations required: cannot resolve `<_ as std::ops::Try>::Ok == _`
 --> src/main.rs:4:5
  |
4 |     vec![Ok(2)].into_iter().collect()?;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

The solution is to do .collect::<Result<Vec<_>,_>>()? (playground)

[nikomatsakis]

I think that the way to fix this is -- first and foremost -- to remove E0284, which is basically the same as E0282 but with "less good" error reporting. To do that, we want to redirect this code:

rust/src/librustc/traits/error_reporting.rs

Lines 1264 to 1273 in 097efa9

	_ => {
	if !self.tcx.sess.has_errors() {
	let mut err = struct_span_err!(self.tcx.sess,
	obligation.cause.span, E0284,
	"type annotations required: \
	cannot resolve `{}`",
	predicate);
	self.note_obligation_cause(&mut err, obligation);
	err.emit();
	}

so that it invokes the need_type_info fn:

rust/src/librustc/infer/error_reporting/need_type_info.rs

Line 89 in 097efa9

pub fn need_type_info(&self, body_id: Option<hir::BodyId>, span: Span, ty: Ty<'tcx>) {

as it happens, other code from trait error reporting file already invokes need_type_info. For example, this arm lies just a small bit of code above:

rust/src/librustc/traits/error_reporting.rs

Lines 1243 to 1249 in 097efa9

	ty::Predicate::WellFormed(ty) => {
	// Same hacky approach as above to avoid deluging user
	// with error messages.
	if !ty.references_error() && !self.tcx.sess.has_errors() {
	self.need_type_info(body_id, span, ty);
	}
	}

so I think we just need to change this hunk to work the same way.

[nikomatsakis]

That said, my guess is that this won't fix the original example. To do that, we have to extend need_type_info to also make suggestions to use turbofish where appropriate. But it's a first step, and then we can go further!

[balajisivaraman]

@nikomatsakis, Following from IRC, I'll pick this one up and begin working on this. Thank you for the helpful tips. :-)

[ytausky]

It's been a while now; @balajisivaraman, are you still interested in this issue? Otherwise I'd like to pick it up.

[balajisivaraman]

@ytausky, Unfortunately, I've not made much progress on this. (I'm still slowly working my way through the Rustc Guide.) You can pick it up if you'd like.

[fcofdez]

@ytausky are you still interested in this issue? If not, I would like to pick it up.

[ytausky]

Sure, life got in between, I'm not working on this.

[phungleson]

Hey guys I can help to look into this if no one picks this up yet.

[saleemjaffer]

@ytausky I would like to give this a shot. I'm new to rust.

[Mark-Simulacrum]

Going to proactively close, Niko can reopen if needed.

[estebank]

The case still repros, I was checking the wrong code.

[estebank]

Output with #65951:

error[E0284]: type annotations needed
 --> file12.rs:2:29
  |
2 |     vec![Ok(2)].into_iter().collect()?;
  |                             ^^^^^^^
  |                             |
  |                             cannot infer type
  |                             help: consider specifying the type argument in the method call: `collect::<B>`
  |
  = note: cannot resolve `<_ as std::ops::Try>::Ok == _`

[hwalinga]

Don't know if the compiler can be a bit more smarter about the error message on this case, but I stumbled upon here when I wrote (with rdr a buffered reader):

let lines: Vec<_> = rdr.lines().collect()?;

Giving the strange:

error[E0277]: the size for values of type `str` cannot be known at compilation time

From: https://stackoverflow.com/questions/67644464/why-can-you-not-use-question-mark-directly-on-collect-in-rust

[estebank]

@hwalinga could you file a new ticket with a link to a reproduction care on the playground? A quick attempt at reproducing the StackOverflow case yielded a "type annotations needed" error and following the suggestions for it leads you in the right direction, but I might be sinning of being overly familiar with what the compiler is trying to say.