Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parse DO blocks block-based during parsing step #161

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

raehik
Copy link
Collaborator

@raehik raehik commented Jul 26, 2021

Instead of parsing as statements and rebuilding the block as a post-parse transformation.

@raehik raehik changed the title Parser tests Parse DO blocks block-based during parsing step Jul 26, 2021
@raehik
Copy link
Collaborator Author

raehik commented Jul 26, 2021

Manually cherry-picked from @RaoulHC 's commit at 04fd6f8 !

And disable relevant transformation GroupDo -- GroupLabelledDo is still
important for the "nonblock" DO construct.

Original code by RaoulHC.
@raehik
Copy link
Collaborator Author

raehik commented Jul 26, 2021

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 enddo token.

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)

do-various.f90.txt

@raehik raehik added stalled area:parser Related to Fortran source code parsers. labels May 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:parser Related to Fortran source code parsers. stalled
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant