rsandifo-arm added a comment. Thanks @aaron.ballman for the feedback about spellings. I've gone with the lower-case names like `__arm_streaming` in what follows, as a plausible strawman.
My main concern with keywords is: > This approach means there's plenty of flexibility available to parse the > keyword where you think it makes sense. If everyone parses keywords where it makes sense to them personally, for their specific use case, I'm worried that we'll end up with a lot of slightly different rules. (This tended to happen for pre-standard features, and like you say, is still the case for GNU attribute handling between Clang and GCC, given GCC's poorly-defined rules.) For example, a type property like `__arm_streaming` only applies to functions, so it wouldn't make sense for bespoke rules to allow the keyword in tagged types or in array types. If a property only applies to object types then it wouldn't make sense for bespoke rules to allow the keyword after a parameter list. So I think it makes sense to try to make the SME attributes an instance of a (new) generic solution. I think we want something “like standard attributes, but for semantic information”. That might sound like wanting something “like ice, but not cold”. But a lot of valuable work went into defining the parsing rules for standard attributes, and defining what they appertain to. It seems like a good idea to reuse those parts rather than reinvent the wheel. https://reviews.llvm.org/D139028 is an RFC for adding “attribute-like keywords”: keywords that can appear exactly where a standard attribute can appear. This means that the keywords are syntactically valid in far more places than necessary for this initial use case, but it provides a simple and mechanical rule. And the keywords would have to be rejected in those additional places anyway, even if we don't parse them as attributes. The covering note has a lot more justification (too much, sorry!). Does this look like a possible way forward? Previously I was arguing in favour of the decl-to-type sliding rule, because: > From discussions I've had with people who will write/are writing SME code, > the distinction between arm_locally_streamng being a property of the > definition and arm_streaming being a property of the type seems contrived to > them, especially when the usage of SME is private to a single translation > unit. Taking the RFC approach involves abandoning that and sticking strictly to the standard appurtenance rules. But hopefully it's a reasonable trade-off. The sliding rule is clearly going against the direction of travel anyway, so I'm probably being too Luddite there. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D127762/new/ https://reviews.llvm.org/D127762 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
