[clang] [clang/AST] Make it possible to use SwiftAttr in type context (PR #108631)
Gábor Horváth via cfe-commits
cfe-commits at lists.llvm.org
Mon Sep 16 04:14:53 PDT 2024
================
@@ -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__((...)) ^)`.
----------------
Xazax-hun wrote:
I don't see a test case covering this scenario, should we add one?
https://github.com/llvm/llvm-project/pull/108631
More information about the cfe-commits
mailing list