Sema: Intro experimental @cdecl and basic C compatibility check #80744
Conversation
xymus
requested review from
hborla,
slavapestov,
xedin,
ahoppen,
bnbarham,
CodaFi,
DougGregor,
hamishknight and
rintaro
as code owners
|
@swift-ci Please smoke test |
|
🥳 |
This implements basic checks on the validity of the @cdecl attribute and ensures the parameters and result types are representable in C. Many more diagnostics will need to be updated to verify full representability in C.
xymus
force-pushed
the
cdecl-global-function-checking
branch
from
498055c to
c6b2821
Compare
|
@swift-ci Please smoke test |
|
@swift-ci Please smoke test |
|
@swift-ci Please smoke test Linux |
| const AbstractFunctionDecl *AFD, ObjCReason Reason, | ||
| std::optional<ForeignAsyncConvention> &asyncConvention, | ||
| std::optional<ForeignErrorConvention> &errorConvention) { | ||
| std::optional<ForeignErrorConvention> &errorConvention, | ||
| ForeignLanguage Language) { |
There was a problem hiding this comment.
A lot of the places you're adding a ForeignLanguage parameter already have an ObjCReason, and if I'm understanding correctly, the only reason we'd pass ForeignLanguage::C is if the reason is ObjCReason::ExplicitlyCDecl. So would it make sense to add an ObjCReason::getForeignLanguage() method and call that instead of adding a new parameter?
(And if we do still want a new parameter, should it come before the two out parameters instead of after them? That would seem like a better match for the convention here.)
There was a problem hiding this comment.
That makes perfect sense, I'll look into implementing this. If it's not in this PR it will be in the next one completing the remaining work on type-checking.
|
@swift-ci Please smoke test Linux |
Apply review comments from swiftlang#80744.
Introduce a new experimental
@cdeclattribute gated behind theCDeclfeature flag. This is part of the initial work to make@_cdeclan official attribute with some improvements mostly for C compatibility.For the time being I'm planning on using the new
@cdeclfor C compatibility and preserving the existing behavior of@_cdeclfor Objective-C compatibilty until we settle on a final syntax. Considering the syntax and exact behavior is likely to change this PR introduces a few abstracted services to make future changes hopefully easier.This PR implements basic checks on the validity of the
@cdeclattribute and ensures the parameters and result types are representable in C. More work is required for this attribute to be usable in practice. More diagnostics will need to be updated to verify full representability in C, proper C compatible enums would need work, and printing for C clients in the compatibility header still needs to be implemented.