rsandifo-arm added a comment. Thanks @aaron.ballman and @erichkeane for the comments. I'll split it into stages and use tablegen more, like you say.
In D139028#4150761 <https://reviews.llvm.org/D139028#4150761>, @aaron.ballman wrote: > One thing that might also help is to split this into a few stages. 1) Add the > new general functionality, 2) Replacing the existing implementation of > keyword attributes with the new functionality where possible, 3) Add new > attributes using the new functionality. It seems to me that we should be able > to replace a bunch of our existing keyword attributes with the newer > generalized approach (I'm thinking about ones like the calling convention > attributes specifically, but we've got others as well), and that will help us > prove the design as well as simplify the compiler implementation. WDYT? I've tried to go through the existing keyword attributes, but unfortunately, I don't think any of them match the new scheme exactly: __declspec ---------- I don't think anyone was suggesting we try to convert this :-) but for completeness: int __declspec(align(16)) a1; // OK, but standard attribute rules would say this appertains to the type int a2 __declspec(); // Not valid, unlike for standard decl attributes __forceinline ------------- int __forceinline a1() { return 1; } // OK, but standard attribute rules would say this appertains to the type int a2 __forceinline() { return 1; } // Not valid, but would be for standard decl attributes Calling convention keywords --------------------------- These are generally DeclOrType attributes, with attributes sliding from the decl to the type where necessary. __stdcall int a1(); // OK, but appertains to the decl and relies on sliding behaviour int a2 __stdcall(); // Not valid, but is another place to put standard decl attributes int a3() __stdcall; // Not valid, but is another place to put standard type attributes int (__stdcall a4)(); // OK, but standard attributes aren't allowed in this position extern int (*const __stdcall volatile a5) (); // OK, but standard attributes wouldn't be allowed here Nullability keywords -------------------- Like the calling-convention keywords, the nullability keywords appertain to types but are allowed in some (but not all) positions that would normally appertain to decls: using ptr = int *; _Nullable ptr a1; // OK, but appertains to the decl and relies on sliding behaviour ptr a2 _Nullable; // Not valid, but is another place to put standard decl attributes extern int *const _Nullable volatile a3; // OK, but a standard attribute wouldn't be allowed here The same distinction applies to Microsoft pointer attributes. Would it be OK just to use the new scheme for new attributes? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D139028/new/ https://reviews.llvm.org/D139028 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
