TableGen: Avoid using resolveListElementReference in TGParser

[nhaehnle]

Summary

A subsequent change intends to remove resolveListElementReference
entirely. This part of the removal can be split out for better
bisectability.

[tra]

Please add more details. Description says what the patch does, but not why. There must be the reason for this change, but I can only guess what it is.
The major difference appears to be that now we do call resolveReferences() for each element, while resolveElementReferences() in the old code effectively just returns getElement(i). If resolving references is the purpose of the change, then patch description should reflect that. Also, if that's the case, perhaps it would be better to fix the problem in the List->resolveListElementReference() and make it actually do the reference resolution the name implies.

[tra]

Upon review of D43562 I think this patch should be folded into it -- it's just a small part of removing resolveListElementReference().

[nhaehnle]

Better summary.

[nhaehnle]

Are you sure? The whole point of splitting it out is that it can be changed separately, and if it breaks something a bisect result will be more helpful. I've tested this quite thoroughly so I don't think it does break anything, but still... seems like a waste to merge it back in. Maybe I'm just too used to the old-school Git way of doing things.

[tra]

In D43561#1016560, @nhaehnle wrote:

Are you sure? The whole point of splitting it out is that it can be changed separately, and if it breaks something a bisect result will be more helpful. I've tested this quite thoroughly so I don't think it does break anything, but still... seems like a waste to merge it back in. Maybe I'm just too used to the old-school Git way of doing things.

On its own this change is rather non-obvious. It makes whole lot more sense (to me at least) in the context of removing resolveListElementReference().

I'm fine keeping the patches separate, as long as this patch comes with an adequate description of what's going on.

In D43561#1016557, @nhaehnle wrote:

Better summary.

I don't see any changes. The summary is still empty and there are no changes to the files.

[nhaehnle]

In D43561#1016565, @tra wrote:

In D43561#1016560, @nhaehnle wrote:

Are you sure? The whole point of splitting it out is that it can be changed separately, and if it breaks something a bisect result will be more helpful. I've tested this quite thoroughly so I don't think it does break anything, but still... seems like a waste to merge it back in. Maybe I'm just too used to the old-school Git way of doing things.

On its own this change is rather non-obvious. It makes whole lot more sense (to me at least) in the context of removing resolveListElementReference().

I'm fine keeping the patches separate, as long as this patch comes with an adequate description of what's going on.

In D43561#1016557, @nhaehnle wrote:

Better summary.

I don't see any changes. The summary is still empty and there are no changes to the files.

Sorry about that. I changed this locally, but Arcanist on Git clearly doesn't pick up changes to the commit message :( Should be fixed now.

llvm/trunk/lib/TableGen/TGParser.cpp

if (IterVals.size() != Loops.size()) {
     ListInit *List = dyn_cast<ListInit>(CurLoop.ListValue);
     if (!List) {
       Error(Loc, "Loop list is not a list");
       return true;
     }
 
     // Process each value.
     for (unsigned i = 0; i < List->size(); ++i) {
-      Init *ItemVal = List->resolveListElementReference(*CurRec, nullptr, i);
+      Init *ItemVal = List->getElement(i)->resolveReferences(*CurRec, nullptr);
       IterVals.push_back(IterRecord(CurLoop.IterVar, ItemVal));
       if (ProcessForeachDefs(CurRec, Loc, IterVals))
         return true;
       IterVals.pop_back();
     }
     return false;
   }