Make bad "rust-call" arguments no longer ICE

[CraftSpider]

The simplest of bad rust-call definitions will no longer cause an ICE. There is a FIXME added for future work, as I wanted to get this easy fix in before trying to either add a hack or mess with the whole obligation system

fixes #22565

[rust-highfive]

r? @oli-obk

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

[CraftSpider]

Note: overloaded-calls-nontuple is failing due to checking a case that is now being explicitly forbidden at the implementation location instead of later on. How should that be handled?

[oli-obk]

overloaded-calls-nontuple is failing due to checking a case that is now being explicitly forbidden at the implementation location instead of later on.

I'm not sure I understand, can you elaborate? I would have thought the failure is because you call let item = tcx.hir().expect_item(id); and methods are impl-items and not items.

[CraftSpider]

Nevermind, you're right, I misread the error. I'll fix that, and have a go at moving it into check_fn.

[CraftSpider]

Having fixed the ICE, now I'm getting the issue I mentioned, where the expected error is emitted, but so are 2 other errors saying A function with the "rust-call" ABI must take a single non-self argument that is a tuple. Is this valid to bless, as this is in fact an error as it stands? (Prior this commit, if you change the code to S::call_once(s, 3), you get the error this is meant to fix, so it is a valid emission of this new error)

[oli-obk]

Is this valid to bless, as this is in fact an error as it stands? (Prior this commit, if you change the code to S::call_once(s, 3), you get the error this is meant to fix, so it is a valid emission of this new error)

Yes, feel free to just bless all error changes. Especially after fixing an ICE this is very normal that more errors occur.

[oli-obk]

@bors r+

[bors]

📌 Commit e8426a6 has been approved by oli-obk