Non-constant tuple diagnostic when impl method signature doesn't match

[danakj]

Description of the bug:

We should get a diagnostic about the signatures not matching, not an obscure error about tuple indexing.

https://carbon.godbolt.org/z/Wc5Eh7ecz

<source>:6:3: error: tuple index must be a constant
  fn F[self: Self]() {}
  ^~~~~~~~~~~~~~~~~~~~
<source>:2:3: note: while building thunk to match the signature of this function
  fn F[self: Self]() -> Self;
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~

It happens in here:

carbon-lang/toolchain/check/thunk.cpp

Lines 326 to 332 in 81c2b3b

	// If we have a self parameter, form `self.<callee_id>`.
	if (function.self_param_id.has_value()) {
	callee_id = PerformCompoundMemberAccess(
	context, loc_id,
	BuildPatternRef(context, call_arg_ids, function.self_param_id),
	callee_id);
	}

What did you do, or what's a simple way to reproduce the bug?

No response

What did you expect to happen?

No response

What actually happened?

No response

Any other information, logs, or outputs that you want to share?

No response

[geoffromer]

I think that may be a manifestation of this TODO

[zygoloid]

I think this is a bug in compound member access for tuples. When building the thunk we form self.(thunk target) and it looks like the special csse for tuple.(integer constant expression) is incorrectly being used when the normal case building a bound member function would work.

I think this would fail in the same way if the signature in the impl did match sufficiently (but a thunk were still used) -- I think any thunk where self is a tuple would hit this.