Conversation
And disable relevant transformation GroupDo -- GroupLabelledDo is still important for the "nonblock" DO construct. Original code by RaoulHC.
|
I now understand the problem Raoul and I both encountered before in a bit more detail, so I'll describe it here for posterity. END DOs were introduced in F90 for the new block DO construct. This construct is safe and easy to parse as a block in the parser, since they always start and end with a DO and END DO respectively. However, END DOs can also terminate the old-style nonblock labelled DO. Writing this naively creates an ambiguity in the parser, since it doesn't know whether to apply the block or nonblock rule when it sees the We need to be able to resolve the ambiguity in Happy, but I don't know how to do that. If I was writing a parser by hand I'd make a choice depending on state ("am I in a block DO?" flag), but I don't think Happy's approach allows such decisions. Attached a test file with various DO constructs that compiles in gfortran, but fails in our old parser, the current one and this PR. (edit: but it worked before I broke it due to changing transformation order -- fix coming up in a separate PR) |
1 participant
Instead of parsing as statements and rebuilding the block as a post-parse transformation.