Object types should use adjustments, include mutability

[nikomatsakis]

Object types are currently quite hacky in method lookup and in the compiler. They don't include mutability information, for example, and they are not transformed like other pointer types during method lookup etc. This should be rectified so that they are basically treated like ty_evec. There are various FIXMEs for this (or there will be in the code that lands to fix #5656).

cc #5527

[nikomatsakis]

As part of this work, we should be using adjustments to deal with borrowing objects and so forth. From a recent IRC conversation with @Sodel-the-Vociferous:

[17:26:42] <nmatsakis> anyway, so yeah, the idea would be to (1) add a new kind of adjustment for objects
[17:26:54] <nmatsakis> (2) modify code-generation (what we call `trans`) to deal with that
[17:27:10] <nmatsakis> (3) modify the method code to borrow in search_for_autosliced_method()
[17:27:24] <nmatsakis> and (4) modify the method code to handle the @self etc coercions
[17:27:34] <nmatsakis> if that all works out, then the end result is that whenever we call a method that expects &self

A simple test case (which works today, but not via the intended paths) would be:

trait MyTrait {
    fn get_by_ref(&self) -> uint;
}

struct MyStruct {
    f: uint
}

impl MyTrait for MyStruct {
    fn get_by_ref(&self) -> uint {
        self.f
    }
}

fn main() {
    let s: @MyTrait = (@MyStruct {f: 22}) as @MyTrait;
    assert!(s.get_by_ref() == 22);
}

[nikomatsakis]

Modified title to be more pithy.

[Sodel-the-Vociferous]

Is @pcwalton's old pull request #5597 relevant to coercing ~/@traits to &Traits? From the look of those commits, this could be more involved than I had hoped.

Would it be worthwhile to get that patch set working with the latest incoming, and building atop that? Though, as I'm still getting acquainted with the compiler's innards, that task seems a bit daunting.

Also, note that my above commits have borked something in compile-time checking of objects' methods. I'll try to set aside some time to debug that sometime in the next few days.

[nikomatsakis]

@Sodel-the-Vociferous that PR is not all that relevant, actually, it addresses a different issue.

[nikomatsakis]

@Sodel-the-Vociferous I'll try to find some time to checkout your patch and build it...

[Sodel-the-Vociferous]

@nikomatsakis Ah, good. On I go debugging, then!

[graydon]

FIXMEs in question are still alive, this looks legit still.

[nikomatsakis]

Status update: I got a version of this building, bsaed on Sodel-the-V's branch, but encountered a problem with how method lookup is defined. I embarked to rewrite method lookup to fix this problem but haven't finished that work. The problem is a quesiton of how we prioritize methods: I believe we have to prioritize inherent methods over trait methods. Bonus is that I would expect this to improve compilation time.