Skip to content

Refactor improper_ctypes to separate "UCG questions" from linting decisions #72774

Open
@hanna-kruppe

Description

@hanna-kruppe

(Elaborating on #66220 (comment))

I think that the current state of improper_ctypes is difficult to maintain and extend -- especially once we add more lints that are similar but distinct -- because it's a big pile of mud that interleaving several different concerns: UCG-ish questions about ABI and layout guarantees, plus value judgements about how these interact with "proper" FFI, plus diagnostics code and suggestions. I imagine (but have not worked out the details) that we could improve this by separating this code into two "layers":

  • A module (some queries?) answering clean-cut spec questions such as: does this type have a defined memory layout? Defined ABI? If not, why not? etc.
  • Several lints that use the facts from that module as basis for emitting warnings, depending on what the lint is targeted at.

I think such an organization would make it clearer what are the language-level guarantees are (including making it easier to audit and evolve) vs what's just a choice or limitation of some lint. More importantly, it would also enable us to implement (without lots of duplication and without making the visitor even more of a big ball of mud) a broader variety of lints that need similar information. For example:

Metadata

Metadata

Labels

A-FFIArea: Foreign function interface (FFI)A-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.C-enhancementCategory: An issue proposing an enhancement or a PR with one.L-improper_ctypesLint: improper_ctypesT-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