This introduces the new swift_name attribute that allows annotating
interfaces with an alternate spelling for Swift. This is used as part
of the importing mechanism to allow interfaces to be imported with a new
name into Swift. It takes a parameter which is the Swift function name.
This parameter is validated to check if it matches the possible
transformed signature in Swift.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/include/clang/Basic/Attr.td | ||
---|---|---|
2170 | Note for @rjmccall and @doug.gregor - this version actually enumerates the subjects to which this attribute appertains unlike what was in the original swift version. Are there other subjects which this should list? |
clang/include/clang/Basic/Attr.td | ||
---|---|---|
2171 | I don't see anything adding ExpectedSwiftNameSubjects to the list of diagnostic enumerations, are you sure this is needed? | |
clang/include/clang/Basic/DiagnosticSemaKinds.td | ||
3985 | I think several of these can be consolidated into a single diagnostic with %select: %0 attribute has invalid identifier for %select{context name|base name|parameter name}1 | |
clang/include/clang/Sema/Sema.h | ||
1839 | The docs should probably mention what AL is used for. | |
clang/lib/Sema/SemaDeclAttr.cpp | ||
4282 | const auto * | |
4289 | I think it would be more helpful if the diagnostic said why the attribute is being ignored (because the arguments don't match). | |
5659 | FWIW, I'm not particularly qualified to review the logic here. Someone with more Swift experience should look at this bit. | |
5661 | Set IsSingleParamInit as well (nothing sets it before the early return on line 5673)? | |
5805–5806 | Do you have to worry about functions with ... variadic parameters and how those impact counts (for either ObjC or regular methods)? | |
clang/test/SemaObjC/attr-swift-name.m | ||
1 ↗ | (On Diff #291277) | The fblocks makes me wonder -- should this attribute be one you can write on a block? |
Thank you for doing this!
clang/include/clang/Basic/Attr.td | ||
---|---|---|
2170 | Hmm. If we enumerate the subjects, we're going to have to update Clang whenever Swift's Clang importer learns a new trick. For example, this is probably missing CXXMethod and FunctionTmpl based on work that's going on in Swift. I suspect we're also missing ObjCCompatibilityAlias. I'm inclined to treat this more like AsmLabelAttr and not try to enumerate subjects at all. |
clang/include/clang/Basic/Attr.td | ||
---|---|---|
2170 | That seems fair to me. I'll try to remove the subject list and try to clean up the fallout. | |
clang/test/SemaObjC/attr-swift-name.m | ||
1 ↗ | (On Diff #291277) | This is not something that can be applied to blocks. Removing the -fblocks is probably a good idea since it isn't actually used. copy-paste failure on my part :-(. |
clang/include/clang/Basic/Attr.td | ||
---|---|---|
104 | This change is no longer needed. | |
clang/include/clang/Basic/AttrDocs.td | ||
3584 | A code example showing proper usage would be appreciated. | |
clang/lib/Sema/SemaDeclAttr.cpp | ||
4289 | Not really, no. The warning diagnostic itself just says that the attribute is ignored, which is the effect but not the rationale. The note (which is easier for folks to ignore) says the attribute is conflicting, but conflicting with *what* (there could be a half dozen attributes on the same declaration, for instance). | |
5805–5806 | Should such function signatures be rejected here though? (If so, can you add a test for that case as well as a test using a K&R C declaration like void f()?) |
clang/lib/Sema/SemaDeclAttr.cpp | ||
---|---|---|
4289 | The existing diagnostic is actually more inline with the existing attribute handling for __attribute__((__optnone__)), __attribute__((__minsize__)), and __attribute__((__always_inline__)) which merge similarly. |
clang/include/clang/Basic/AttrDocs.td | ||
---|---|---|
3582 | The parameter takes -> The argument is | |
clang/include/clang/Basic/DiagnosticSemaKinds.td | ||
3977 | I want to make sure we're clear with the terminology used in the diagnostics, so there's a fair number of "take -> have" suggestions here, but I want to be sure I'm correct before you apply those suggestions. I'm used to function declarations having parameters which take arguments from a function call expression. Are the diagnostics about "taking a parameter" talking about "having a parameter" or about "taking an argument"? I believe the string arguments are function signatures rather than function names (perhaps?) and so we should be talking about having a parameter, but I wasn't 100% sure. | |
3979 | How about: %0 attribute argument must be a string literal specifying a Swift function name? | |
3988 | %0 attribute for 'subscript' must %select{be a getter or setter|have at least one parameter|have a 'self' parameter}1 ? | |
3994 | take -> have | |
3997 | take -> have elsewhere new value is spelled 'newValue:, should that be the same here? | |
4006 | take -> have | |
4009 | take -> have | |
4012 | take -> have | |
4015 | take -> have | |
4017 | I don't think you need this diagnostic -- you should be able to use warn_attribute_wrong_decl_type (it has a non-K&R-style functions option which is a bit more clear). |
LGTM, though you may want to get a second set of eyes on the swift name validation bits for a more thorough review of that part.
clang/include/clang/Basic/DiagnosticSemaKinds.td | ||
---|---|---|
3997 | That makes sense to me, thanks! |
This introduces the new swift_name attribute that allows annotating
interfaces with an alternate spelling for Swift. This is used as part
of the importing mechanism to allow interfaces to be imported with a new
s/interfaces/APIs/ (to not confuse with Objective-C @interface)
clang/include/clang/Basic/AttrDocs.td | ||
---|---|---|
3579–3580 | WDYT about: The `swift_name` attribute specifies the name of the declaration in Swift. If this attribute is absent, the name is transformed according to the algorithm built into the Swift compiler. | |
3582 | The argument is a string literal that contains the Swift name of the function, variable, or type. When renaming a function, the name may be a compound Swift name. | |
3593 | Could we try a more realistic example? @interface URL - (void) initWithString:(NSString*)s __attribute__((__swift_name__("URL.init(_:)"))) @end double __attribute__((__swift_name__("squareRoot()"))) sqrt(double) { } | |
clang/include/clang/Basic/DiagnosticSemaKinds.td | ||
3982 | for => for the | |
3988 | 80 columns. | |
clang/include/clang/Sema/Sema.h | ||
1837–1838 | "a legal argument for the swift_name attribute applied to decl \p D." | |
1843–1844 | WDYM by "the function will output"? Which function, DiagnoseSwiftName? I think this part of the comment is about validateSwiftFunctionName. | |
clang/lib/Sema/SemaDeclAttr.cpp | ||
4282 | Why is the variable called Inline? Unless there's a reason, I'd suggest something that has a stronger connection, like PreviousSNA. | |
5717 | Could you add an assert that the character being dropped is indeed ')'? There is an error above, but it is sort of far away and the connection between that line and this one is not obvious. |
clang/include/clang/Basic/AttrDocs.td | ||
---|---|---|
3579–3580 | I think that is more approachable and less technical. I'll take it. | |
3593 | I like that! | |
clang/include/clang/Sema/Sema.h | ||
1843–1844 | Ah, right, that is about validateSwiftFunctionName. I'll move the description. | |
clang/lib/Sema/SemaDeclAttr.cpp | ||
4282 | The previous one was declared inline in the declaration, but sure, I can rename it to PrevSNA. |
This change is no longer needed.