rustc: remove ty::MethodOrigin and replace its uses with equivalent logic.

[eddyb]

MethodCallee now has no information about the method, other than its DefId.
The previous bits of information can be recovered as follows:

let method_item = tcx.impl_or_trait_item(callee.def_id);
let container = method_item.container();

The method is inherent if container is a ty::ImplContainer:

• the impl the method comes from is container.id()

The method is a trait method if container is a ty::TraitContainer:

• the trait the method is part of is container.id()
• a ty::TraitRef can be constructed by putting together:
  • container.id() as the trait ID
  • callee.substs.clone().method_to_trait() as the trait substs (including Self)
• the above trait_ref is a valid T: Trait<A, B, C> predicate
• selecting trait_ref could result in one of the following:
  • traits::VtableImpl(data): static dispatch to data.impl_def_id
  • traits::VtableObject(data): dynamic dispatch, with the vtable index:
    traits::get_vtable_index_of_object_method(tcx, data, callee.def_id)
  • other variants of traits::Vtable: various other impl sources

[rust-highfive]

r? @Aatch

(rust_highfive has picked a reviewer for you, use r? to override)

[eddyb]

Your "lints" are only unconditional_recursion, and you can get the impl relatively easily (by selecting on the trait - you can copy trans::common::fulfill_obligation).

@arielb1 Right, by "lints" I meant librustc_lint.
I didn't want to jump the gun because it wasn't an obvious cost (all changes that I can think of in this PR have a constant amortized cost difference associated with them).
It's probably not as bad as vtable_index, which can be reused for multiple monomorphizations (but trans could still cache vtable layouts in a more general fashion).

[arielb1]

unconditional_recursion is only called once per method call - this is amortized O(1).

[arielb1]

r+ modulo not storing the vtable + passing tests.

[bors]

☔ The latest upstream changes (presumably #26677) made this pull request unmergeable. Please resolve the merge conflicts.

[eddyb]

I ended up making all the changes anyway. Original PR description was:

MethodOrigin now only holds the optional impl_def_id, for trait methods, and vtable_index, for object methods.

They could be both removed, at the cost of offloading computation to lints and trans, respectively.
In the case of impl_def_id, using traits::select in lints will provide a more accurate result.
As for vtable_index, it's possible we don't want middle or typeck to deal with vtable layout - or at least, it could be stored outside of MethodOrigin.

MethodOrigin::Inherent could be distinguished from the other cases by checking that the container of the method is an impl.
MethodOrigin::Object can be replaced by an optimization for VtableObject in trans::meth - so that object.method() and Trait::method(object) produce the same IR (currently the latter always goes through the <Trait as Trait>::method shim).

I haven't attempted to implement any of those potential refactors as they might not be entirely beneficial, though they should all be possible (with all of them, MethodOrigin would be gone).

[eddyb]

cc @huonw The commit named "rustc_lint: use traits::select for methods in unconditional_recursion." produces warnings for overloaded operators (and probably other things I haven't thought of):

struct Foo;
impl std::ops::Deref for Foo {
    type Target = Foo;
    // warning: function cannot return without recurring
    fn deref(&self) -> &Foo { &**self }
}
impl std::ops::Index<usize> for Foo {
    type Output = Foo;
    // warning: function cannot return without recurring
    fn index(&self, x: usize) -> &Foo { &self[x] }
}

We might want some tests for these.

[arielb1]

@bors r+

[bors]

📌 Commit d877cfd has been approved by arielb1

[bors]

⌛ Testing commit d877cfd with merge 411a5bf...

[bors]

💔 Test failed - auto-linux-64-nopt-t

[eddyb]

@bors r=arielb1

[bors]

📌 Commit d256eb1 has been approved by arielb1

[bluss]

Since this fixes a memory safety bug, can we backport it?

[eddyb]

@bluss the refactoring parts are pretty huge, though maybe just the vtable upcasting logic could be... I'm not sure.

[bors]

⌛ Testing commit d256eb1 with merge a993275...

[bors]

💔 Test failed - auto-mac-64-opt

[eddyb]

@bors retry

[bors]

⌛ Testing commit d256eb1 with merge 42e545f...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt