suggest removing & when iterating over &<some iterator type>

[spastorino]

504 | /         for (_idx, _constraint) in &self.constraints.iter().enumerate() {
505 | |         }
    | |_________^ `&std::iter::Enumerate<std::slice::Iter<'_, borrow_check::nll::region_infer::Constraint>>` 

I started going for constraint in &self.constraints { then move to use enumerate and forgot to remove the &.

I figuref that the error could say maybe remove the &, calling iter and having & doesn't make sense.

[nikomatsakis]

cc @estebank

[ysiraichi]

@nikomatsakis Can I give it a shot?

[estebank]

@ysiraichi feel free to do so! Also feel free to reach out either on gitter or on this issue for help.

You'll have to look at librustc/traits/error_reporting.rs:report_selection_error (which is where the error E0277 is being emitted). There you have to verify wether self_ty is a &-ref, and wether the referenced ty does implement the trait being that failed to be found, std::iter::IntoIterator::into_iter in this case. Doing that second part is the hard part and I would have to dig a bit in order to be able to help you with it, others in the compiler team might have more context around it.

[nikomatsakis]

There you have to verify whether self_ty is a &-ref

That doesn't quite seem like enough -- the type might be an & without the expression itself being a borrow expression. e.g., something like this:

let x = &(1..2);
for y in x { ... }

But indeed that is one of the tricky bits here: the place where the error is reported is rather 'divorced' from the original source code. We might be able to consult the cause information to find out where the error came from, I suppose, and hack something in that way?

[estebank]

The further removed the borrow is from the use location the less likely you're to be able to change it without breaking something else. If the type is copy or clone, I'd instead suggest using * instead. Also, I thought that even if it is a binding a ref or what have you, you can follow the Tys until you get to a TyAdt.

[nikomatsakis]

@estebank I think we should literally look for the case where the & appears in the for, and only that, specifically because of the danger of going wrong when doing this:

for x in &vec

to

for x in vec.iter().filter(...)

Also, adding a * will not help :( -- you can't move an iterator out from behind a borrowed reference

[estebank]

Repro case for test.