CG Backends should validate Call types more strictly #105487
Labels
A-codegen
Area: Code generation
A-testsuite
Area: The testsuite used to check the correctness of rustc
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
In #104321, I bent the compilers rules a bit, both intentionally and not, in particular:
Up until #105250, the function generated for
Future::poll
was usingResumeTy
instead of&mut Context<'_>
for its argument. This was fine asResumeTy
was just a newtype wrapper around*const Context
, so both are just pointers. Though @bjorn3 pointed out, this could have started randomly failing when using-Zrandomize-layout
. Driveby question: Would#[repr(transparent)]
have provided stronger guarantees here?The second case, fixed by #105082, was a mismatched return type. The change in #104321 correctly changed the generated MIR to output (and write to)
Poll
. Though theFnAbi
was unchanged and still referring to aGeneratorState
.This was seemingly fine as both happened to have the same size and alignment.
Callers were assuming a
Poll
, MIR was outputting aPoll
. But theFnAbi
was advertising aGeneratorState
erronously.As discovered by @bjorn3 in #104321 (comment),
cg_clif
does a more stricter validation of the call arguments and return values in the codegen backend, which the other backends evidently did not do.They probably should.
CC @compiler-errors @oli-obk
The text was updated successfully, but these errors were encountered: