Skip to content

CG Backends should validate Call types more strictly #105487

Open
@Swatinem

Description

@Swatinem

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 using ResumeTy instead of &mut Context<'_> for its argument. This was fine as ResumeTy 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 the FnAbi was unchanged and still referring to a GeneratorState.
This was seemingly fine as both happened to have the same size and alignment.
Callers were assuming a Poll, MIR was outputting a Poll. But the FnAbi was advertising a GeneratorState 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-codegenArea: Code generationA-testsuiteArea: The testsuite used to check the correctness of rustcC-enhancementCategory: An issue proposing an enhancement or a PR with one.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions