[clang/AST] Make it possible to use SwiftAttr in type context #7918
Conversation
|
Cannot merge this without changes on the Swift side because it introduces new |
|
@swift-ci please test |
Expands allowed use of SwiftAttr to type context from declarations only, this enables use of the attribute on generic parameters, in Objective-C blocks, typedefs etc.
…it can now appear on types
xedin
force-pushed
the
attributedtype-with-optional-attr
branch
from
617dbef to
32e5bdd
Compare
…ion attribute Adjust `SwiftAttr` handling to determine when attribute should be handled as a type or declaration attribute i.e. if attribute is attached to a declarator or declaration name, it should be handled as a declaration attribute.
| // it should be handled as a declaration attribute, | ||
| // unless it's associated with a type or a function | ||
| // prototype (i.e. appears on a parameter or result type). | ||
| if (State.isProcessingDeclSpec()) { |
There was a problem hiding this comment.
This is a change in the current interpretation, right? Isn't swift_attr currently allowed in the decl-specifiers and always applied to the declaration, even on function declarations?
There was a problem hiding this comment.
Yes, I expected that switching from InheritedAttr to DeclOrTypeAttr would preserve the behavior and attributes that appear on the outer decl-spec of a parameter would be handled by SemaDeclAttr but that is not the case. I couldn't figure out a robust way to determine the position because there appears to be no way to walk up declarators so I opted for a simpler approach where anything that appears in "prototype" context is handled as a type attribute and adjusted that on the Swift side too.
There was a problem hiding this comment.
Okay, Pavel explained to me offline that the Swift importer already has to walk into the type-as-written to look for AttributedTypes that might have been written at the top level of a declarator (where they syntactically apply to the outermost declarator; this is common with e.g. function declarators, where people often write attributes after the prototype). In that case, making the rule always prefer to apply attributes to the type, and then making the importer also look for "declaration" attributes in nested positions seems reasonable. (As ever, the real problem here is that the C grammar is poorly designed for interpreting this sort of thing with universal rules.)
|
swiftlang/swift#70693 |
|
swiftlang/swift#70693 |
|
swiftlang/swift#70693 |
|
swiftlang/swift#70693 |
3 similar comments
|
swiftlang/swift#70693 |
|
swiftlang/swift#70693 |
|
swiftlang/swift#70693 |
SwiftAttris switched fromInheritableAttrwhich is a declaration attribute toDeclOrTypeAttr.To support this attribute in type context we need access to its "Attribute" argument which requires
AttributedTypeto be extended to includeAttr *when available instead of justattr::Kind.