On 6/22/21 3:30 AM, Matthias Kretz wrote:
On Wednesday, 16 June 2021 02:48:09 CEST Jason Merrill wrote:
IIUC, your main concern is that my proposed diagnose_as *can* be used to
make diagnostics worse, by replacing names with strings that are not
valid identifiers. Of course, whoever uses the attribute to that effect
should have a good reason to do so. Is your other concern that using the
attribute in a "good" way is repetitive? Would you be happier if I make
the string argument to the attribute optional for type aliases?
Yes, and namespace aliases.
I'll look into making the attribute argument optional for aliases. Would you
accept the patch with this change?
Yes (after resolving any technical details, of course).
Questions:
1. If a type alias applies the attribute after a type was completed /
implicitly instantiated (and possibly already used in diagnostics) should /
can I still modify the type and add the attribute?
Yes, because it has no semantic effect.
For alias templates, you probably want the attribute only on the
templated class, not on the instantiations.
2. About the namespace aliases: IIUC an attribute would currently be rejected
because of the C++ grammar. Do you want to make it valid before WG21
officially decides how to proceed? And if you have a pointer for me where I'd
have to adjust the grammar rules, that'd help. :)
You will want to adjust cp_parser_namespace_alias_definition to handle
attributes like cp_parser_namespace_definition. The latter currently
accepts attributes both before and after the name, which seems like a
good pattern to follow so it doesn't matter which WG21 chooses.
Probably best to pedwarn about C++11 attributes in both locations for
now, not just after.
Jason
