Open antoine-morvan opened 1 year ago
Thanks for the report and reproducer. We've just hit this problem in a different context so I'm keen to take a look. Just struggling for time at the moment as it's the summer holidays.
The problem is in the BlockBase.match
method which consumes any preceding comments, includes and directives before moving on to process the loop (https://github.com/stfc/fparser/blob/3ede17259e8854e9fd3976b80324a95bf60ca107/src/fparser/two/utils.py#L590-L595). Do @rupertford or @reuterbal know whether this is because we want to associate directives with the loop? Or is it something that was there originally?
To answer my own question, git blame shows me that it was like that 4 years ago (albeit, it only handled comments back then). The question is, if I change this, am I going to break the directives support?
If I remember correctly, #358 fixes this.
FWIW: I don't think it is because of directives but just an artifact of the way it was implemented? In fact, we explicitly deal with this association of comments when we convert to our IR and don't mind seeing the need for that being gone;-)
Hello,
I am walking an AST, looking for specific comments in the tree. I encountered some unexpected behavior regarding the hierarchy of the comments. This impacts the printer too.
My sample program looks like this, with 3 comments outside the do loop, and one comment inside the loop.
I applied the following script to expose the unexpected behavior:
and got the following output:
We can observe that the
comment_out 2
is considered as a children of the do loop, whereas I expect it to be at the same level ascomment_out 3
, that is as part of the execution part.I've run this with fparser2 version 0.0.16.
We can also observe that the fparser2 script
fparser2 --std=f2008 test_fail.f90
prints a wrong indentation when parsing this sample program:Best.