gccrs: Fix compilation of trait-items which map to impl items

When we have paths such as Try::from_error the Try references the Trait
and then from_error references the from_error trait item. So this resolves
directly to a trait implementation which has the type:

  fn <Self> (v: placeholder) -> Self

Remember that a path such as: Try::from_error gets handled by doing a
clever substitution: <T? as Try>::from_error

The main piece here is that we resolve this function type and for
monomoprhization we know this is a trait call but we know that all trait's
have an implicit Self type param which in this case is Result<i32, i32>
so when it comes to knowing which impl block this is we got rid of the old
bad insert/lookup receiver hack and use the specified type to know which
impl block we are talking about to generate the function.

The hard part here is inside rust-compil-item.cc, where we have the
'concete' type which is the trait item fntype of:

  fn <Result<i32, i32>> (v : i32) -> Result<i32,i32>

This does not really match the signiture of the impl item for Result
which is:

  fn <T, E> (v: i32) -> Result<T, E>

So what we need to do is actually infer this by inputing inference
variables on the impl fntype then unify'ing the trait object to this to
compute the types of this to monomorphize this.

Fixes Rust-GCC#3381

gcc/rust/ChangeLog:

	* backend/rust-compile-expr.cc (CompileExpr::visit): remove receiver interface
	* backend/rust-compile-item.cc (CompileItem::visit): monomorphize trait to impl item
	* backend/rust-compile-resolve-path.cc (HIRCompileBase::query_compile): use trait item Self
	* typecheck/rust-hir-type-check-expr.cc (TypeCheckExpr::visit): remove receiver interface
	(TypeCheckExpr::resolve_fn_trait_call): likewise
	* typecheck/rust-hir-type-check-path.cc (TypeCheckExpr::visit): likewise
	(TypeCheckExpr::resolve_segments): likewise
	* typecheck/rust-hir-type-check-type.cc (TypeCheckType::visit): likewise
	* typecheck/rust-hir-type-check.h: likewise
	* typecheck/rust-typecheck-context.cc (TypeCheckContext::insert_receiver): remove
	(TypeCheckContext::lookup_receiver): remove

gcc/testsuite/ChangeLog:

	* rust/execute/torture/issue-3381.rs: New test.

Signed-off-by: Philip Herron <herron.philip@googlemail.com>

1 files changed, 10 insertions, 6 deletions

diff --git a/gcc/rust/backend/rust-compile-resolve-path.cc b/gcc/rust/backend/rust-compile-resolve-path.cc
index c862a81..1b9dee6 100644
--- a/gcc/rust/backend/rust-compile-resolve-path.cc
+++ b/gcc/rust/backend/rust-compile-resolve-path.cc
@@ -297,16 +297,20 @@ HIRCompileBase::query_compile (HirId ref, TyTy::BaseType *lookup,
 	    trait->get_mappings ().get_defid (), &trait_ref);
 	  rust_assert (ok);
 
-	  TyTy::BaseType *receiver = nullptr;
-	  ok = ctx->get_tyctx ()->lookup_receiver (mappings.get_hirid (),
-						   &receiver);
-	  rust_assert (ok);
-	  receiver = receiver->destructure ();
-
 	  // the type resolver can only resolve type bounds to their trait
 	  // item so its up to us to figure out if this path should resolve
 	  // to an trait-impl-block-item or if it can be defaulted to the
 	  // trait-impl-item's definition
+	  //
+	  // because we know this is resolved to a trait item we can actually
+	  // just grab the Self type parameter here for the receiver to match
+	  // the appropriate impl block
+
+	  rust_assert (lookup->is<TyTy::FnType> ());
+	  auto fn = lookup->as<TyTy::FnType> ();
+	  rust_assert (fn->get_num_type_params () > 0);
+	  auto &self = fn->get_substs ().at (0);
+	  auto receiver = self.get_param_ty ();
 	  auto candidates
 	    = Resolver::PathProbeImplTrait::Probe (receiver, final_segment,
 						   trait_ref);