refactor ProjectionTy to store def-id of associated item + substs

[nikomatsakis]

In preparation for ATC, we should refactor ProjectionTy to store the DefId of the trait associated item along with a set of substs for that item. (Currently, it stores a trait-ref (trait def-id + substs) and item name.) Currently, these substs will always be the same as the substs for the trait, but once ATC lands they will include additional items.

cc @tschottdorf, who has started in on this
cc @eddyb, who has a vague interest in this :)

[tbg]

Quick question - for storing substs, would a ProjectionTy start out with a copy of the substs of the corresponding TraitRef at creation time, or is it sharing the substs with it in general?

[eddyb]

@tschottdorf How would the two options differ? What do you mean by "sharing"?

[tbg]

@eddyb Niko mentioned above that for now, the substs in the TraitRef and those in ProjectionTy will be identical, so making a copy isn't strictly necessary. He also mentioned that they're bound to diverge with ATC, so it seems reasonable not to tie the two together.

[eddyb]

Maybe he wasn't clear on the fact that TraitRef in ProjectionTy would be replaced, so the end result only has DefId for the associated type and Substs for it (which currently would be the same that you would find in the TraitRef).

[tbg]

Sorry, didn't phrase that well - I'm aware that trait_ref will be dropped, what I'm really asking is: is the intended behavior instead of storing the trait_ref, it will store a copy of the substs that are in the trait_ref at the time the ProjectionTy is constructed. Your last sentence answers it though, so my question has been addressed. Thanks @eddyb!