Implement automatic overloaded deref.

[eddyb]

Enables the dereference overloads introduced by #12491 to be applied wherever automatic dereferences would be used (field accesses, method calls and indexing).

[alexcrichton]

There's a few travis failures you may be interested in, and I would like to see more description added before merging.

[huonw]

Does this mean the &1 + 2 bug is fixed?

(If so, needstest)

[eddyb]

I've only changed x OP y with x &T instead of T where T is a generic type param with the operator overload in its trait bounds, and it wasn't to fix that bug, but prevent nasty recursion in autoderef.

I guess I should fiddle with the lookup code some more to deny more forms, as this is likely to also affect autoderef.

[eddyb]

@brson this means I need some kind of writeup...

We currently do "autoderef" for expressions like x.foo and x.bar(), causing them to be potentially equivalent to (******x).foo and (********x).bar() (depending on the type of x).

This PR enables the deref overloads introduced by #12491 to be applied in those contexts, allowing one to write v.borrow_mut().push(x) instead of v.borrow().borrow_mut().get().push(x) that is done today for a v of type Rc<RefCell<Vec<T>>>.

[nikomatsakis]

cc me, I will review

[nikomatsakis]

@eddyb I tried to open a PR with my nits / refactorings / comments that I wrote as I went through, but I was not able to base it against your branch (github didn't give me that option for some reason). Here is a patch: https://gist.github.com/nikomatsakis/9414596

[nikomatsakis]

Oh, I just thought of a wrinkle while writing out the set of tests. The current field rules autoderef if the outer type does not define the field. But what if the field is private? This seems bad. We have to figure out the right rules for this!

[nikomatsakis]

As I wrote on IRC, we're going to need more tests. At minimum, I would like to see basically the same suite of tests that are present for explicit deref, but with autoderef instead. But autoderef opens up some new fun so it'd also be good to have tests like:

• Test a field reference that must autoderef to find the field
• Test indexing that must autoderef to find the array
• Test the case where the smart pointer defines a public field that is reached first
• Test the case where the smart pointer defines a private field that is reached first (hmm)
• Test the case where there are multiple methods to see which gets priority

Also, there is some discussion amongst the group about what the right semantics are in the face of method resolution ambiguity (ie, if both *x and **x define a method), but I think we'll land the patch now with your "take the first thing you find" approach and maybe as part of the method lookup rewrite that I'm working worry about alternative semantics.

[bill-myers]

This is probably already obvious, but if a private field is reached first, and there is a public field later, it would be a bug to return the private field, since that effectively makes the private field name visible in the API.

[nikomatsakis]

Based on discussion with the group, current plan is to ignore private fields that are not visible during autoderef. But if the autoderef never finds a public field, I'd like to report an error to the effect that the field f is private rather than reporting something misleading like "no field found". (I haven't had a chance to read @eddyb's latest commits, this may well be the semantics he implemented.)

[oblitum]

is this matter for another PR or is it not desired?

use std::rc::Rc;structBar{x:int}fnfoo(p:&int){println!("{}", p);}fnbaz(p:&Bar){println!("{}", p.x);}fnmain(){let pi = box 10;let pb = Rc::new(Bar{x:3});foo(pi);// this still doesn't auto borrow://baz(pb);// although this works:println!("{}", pb.x);}

[eddyb]

@oblitum That should be discussed. It's part of the larger auto-ref issue (calling a function taking T with &T).
What you see there is hard coded for ~T -> &T/&mut T and &mut T -> &T (AFAIK).