aaron.ballman added a reviewer: aaron.ballman. aaron.ballman added a comment.
In D63845#1559995 <https://reviews.llvm.org/D63845#1559995>, @lebedev.ri wrote: > What's the target use-case here? What can't be solved with normal attributes? > I wonder if this should go to cfe+llvm -dev lists first, it's kinda > intrusive. > I also wonder if all these should cause a clang diagnostic, at least under > `-Wall`. > How is versioning expected to be handled? New attribute vs old clang, and > vice versa. Also, we already have the `annotate` attribute for passing information through to LLVM. Why do we need four different ways to do this? ================ Comment at: clang/include/clang/Basic/Attr.td:1638 +def LLVMFN : InheritableAttr { + let Spellings = [GCC<"LLVMFN">]; + let Args = [StringArgument<"AttrName">]; ---------------- This is not a GCC attribute, so this needs a different spelling. Also, the all-caps names are a bit obnoxious, so we may want to pick a different name. Do you envision these being attributes users will write in production code? What kind of guarantees do they have about the stability of the attribute interfaces that LLVM provides? For instance, are we promising that LLVM attributes will remain backwards compatible (e.g., won't be removed or renamed)? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D63845/new/ https://reviews.llvm.org/D63845 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
