The new rules are straightforward. The main rules to keep in mind
are:
- NAME is an implicit template argument of class and multiclass, and will be substituted by the name of the instantiating def/defm.
- The name of a def/defm in a multiclass must contain a reference to NAME. If such a reference is not present, it is automatically prepended.
And for some additional subtleties, consider these:
- defm with no name generates a unique name but has no special behavior otherwise.
- def with no name generates an anonymous record, whose name is unique but undefined. In particular, the name won't contain a reference to NAME.
Keeping rules 1&2 in mind should allow a predictable behavior of
name resolution that is simple to follow.
The old "rules" were rather surprising: sometimes (but not always),
NAME would correspond to the name of the toplevel defm. They were
also plain bonkers in the edge cases, as the old version of the
name-resolution-consistency.td test case shows.
Having NAME correspond to the name of the toplevel defm introduces
"spooky action at a distance" and breaks composability:
refactoring the upper layers of a hierarchy of nested multiclass
instantiations can cause unexpected breakage by changing the value
of NAME at a lower level of the hierarchy. The new rules don't
suffer from this problem.
Some existing .td files have to be adjusted because they ended up
depending on the undocumented quirks of the old implementation.
Change-Id: I694095231565b30f563e6fd0417b41ee01a12589
I haven't fully got my head round all of this, but this new description of NAME doesn't quite seem to match the text in index.rst:
The general intention seems to be the same (if you refer to NAME in some expression in a class declaration, then each def that inherits that expression gets it evaluated in terms of that def's own name). But the old text says that NAME is also a property of the final def, whereas the new text seems to suggest that it's a more transient entity that never _really_ exists in the def but is just something classes can refer to while everything's being set up.
In my JSON backend (D46054) I manually filled in the NAME field in the JSON dict for every output def, because that text in index.rst said it should be there. But if that's not a reflection of reality any more, perhaps I should rename that field to !name to mark it as one of the extra pieces of JSON-level metadata?