Potential Bug in StmtFSM for-loop parsing

[yannickl96]

Potential Bug in StmtFSM for-loop parsing

[quark17]

I don't see a reason why that shouldn't be accepted. Thank you for reporting the issue!

As you saw, one workaround is to replace the vector selection with a variable name. Another is to wrap the selection with asReg or asIfc.

I suspect that fixing this might be as simple as adding the following clause to the flags used for parsing the init and increment parts of the for-loop control triple:

allowSubscriptAssign = (ctxt == ISCSequence)

This is in the function pImperativeForControl (here) which parses the triple. It's used in pImperativeFor, defined above it, that parses the for loop.

The question is whether this would allow something incorrect to parse -- probably not? Note that it would also allow assignment to a range, not just a single index:

Reg#(Bit#(32)) baz <- mkReg('1);
...
    for(baz[7:0] <= 0; baz[7:0] < 10; baz[7:0] <= baz[7:0] + 1) action
      $display("baz[7:0] is %h", baz[7:0]);
      $display("baz is %h", baz);
    endaction

[quark17]

Having a look at the other fields in the type ImperativeFlags, I see that we might also want to assert allowFieldAssign, to allow code like this:

for(rg_s.f1 <= 0; rg_s.f1 < 10; rg_s.f1 <= rg_s.f1 + 1) action
  $display("rg_s.f1 is %h", rg_s.f1);
endaction

[quark17]

I've merged a PR that fixes this and adds test cases. Thanks again!