================
@@ -7147,6 +7147,60 @@ static bool
HandleWebAssemblyFuncrefAttr(TypeProcessingState &State,
return false;
}
+static void HandleSwiftAttr(TypeProcessingState &State, TypeAttrLocation TAL,
+ QualType &QT, ParsedAttr &PAttr) {
+ if (TAL == TAL_DeclName)
+ return;
+
+ Sema &S = State.getSema();
+ auto &D = State.getDeclarator();
+
+ // If the attribute appears in declaration specifiers
+ // 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()) {
+ if (!(D.isPrototypeContext() ||
+ D.getContext() == DeclaratorContext::TypeName))
+ return;
+
+ if (auto *chunk = D.getInnermostNonParenChunk()) {
+ moveAttrFromListToList(PAttr, State.getCurrentAttributes(),
+ const_cast<DeclaratorChunk *>(chunk)->getAttrs());
+ return;
+ }
+ }
+
+ StringRef Str;
+ if (!S.checkStringLiteralArgumentAttr(PAttr, 0, Str)) {
+ PAttr.setInvalid();
+ return;
+ }
+
+ // If the attribute as attached to a paren move it closer to
+ // the declarator. This can happen in block declarations when
+ // an attribute is placed before `^` i.e. `(__attribute__((...)) ^)`.
----------------
xedin wrote:
This actually applies more on the Swift side, I have multiple tests for this in
ClangImporter but I'm not sure how to test this here since it doesn't really
matter for clang AST where the attribute ends up being located.
https://github.com/llvm/llvm-project/pull/108631
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
