Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CG Backends should validate Call types more strictly #105487

Open
Swatinem opened this issue Dec 9, 2022 · 0 comments
Open

CG Backends should validate Call types more strictly #105487

Swatinem opened this issue Dec 9, 2022 · 0 comments
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.

Comments

@Swatinem
Copy link
Contributor

Swatinem commented Dec 9, 2022

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

@jyn514 jyn514 added 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. A-codegen Area: Code generation T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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.
Projects
None yet
Development

No branches or pull requests

2 participants