summaryrefslogtreecommitdiff
path: root/lib
diff options
context:
space:
mode:
Diffstat (limited to 'lib')
-rw-r--r--lib/TableGen/TGParser.cpp32
1 files changed, 21 insertions, 11 deletions
diff --git a/lib/TableGen/TGParser.cpp b/lib/TableGen/TGParser.cpp
index 9424677800..b9c7ff694d 100644
--- a/lib/TableGen/TGParser.cpp
+++ b/lib/TableGen/TGParser.cpp
@@ -2284,23 +2284,33 @@ InstantiateMulticlassDef(MultiClass &MC,
Ref.Rec = DefProto;
AddSubClass(CurRec, Ref);
- if (DefNameString == 0) {
- // We must resolve references to NAME.
- if (SetValue(CurRec, Ref.RefLoc, "NAME", std::vector<unsigned>(),
- DefmPrefix)) {
- Error(DefmPrefixLoc, "Could not resolve "
- + CurRec->getNameInitAsString() + ":NAME to '"
- + DefmPrefix->getAsUnquotedString() + "'");
- return 0;
- }
+ // Set the value for NAME. We don't resolve references to it 'til later,
+ // though, so that uses in nested multiclass names don't get
+ // confused.
+ if (SetValue(CurRec, Ref.RefLoc, "NAME", std::vector<unsigned>(),
+ DefmPrefix)) {
+ Error(DefmPrefixLoc, "Could not resolve "
+ + CurRec->getNameInitAsString() + ":NAME to '"
+ + DefmPrefix->getAsUnquotedString() + "'");
+ return 0;
+ }
+ // If the DefNameString didn't resolve, we probably have a reference to
+ // NAME and need to replace it. We need to do at least this much greedily,
+ // otherwise nested multiclasses will end up with incorrect NAME expansions.
+ if (DefNameString == 0) {
RecordVal *DefNameRV = CurRec->getValue("NAME");
CurRec->resolveReferencesTo(DefNameRV);
}
if (!CurMultiClass) {
- // We do this after resolving NAME because before resolution, many
- // multiclass defs will have the same name expression. If we are
+ // Now that we're at the top level, resolve all NAME references
+ // in the resultant defs that weren't in the def names themselves.
+ RecordVal *DefNameRV = CurRec->getValue("NAME");
+ CurRec->resolveReferencesTo(DefNameRV);
+
+ // Now that NAME references are resolved and we're at the top level of
+ // any multiclass expansions, add the record to the RecordKeeper. If we are
// currently in a multiclass, it means this defm appears inside a
// multiclass and its name won't be fully resolvable until we see
// the top-level defm. Therefore, we don't add this to the