search

stfc / fparser

This project maintains and develops a Fortran parser called fparser2 written purely in Python which supports Fortran 2003 and some Fortran 2008. A legacy parser fparser1 is also available but is not supported. The parsers were originally part of the f2py project by Pearu Peterson.
https://fparser.readthedocs.io
Other
64 stars 29 forks source link

Allow deepcopy of fparser tree #453

Closed schreiberx closed 2 days ago

schreiberx commented 1 week ago

Does what's in the title.

codecov[bot] commented 1 week ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 92.14%. Comparing base (84a4b1d) to head (4b7e555). Report is 10 commits behind head on master.

Additional details and impacted files ```diff @@ Coverage Diff @@ ## master #453 +/- ## ======================================= Coverage 92.14% 92.14% ======================================= Files 86 86 Lines 13834 13840 +6 ======================================= + Hits 12747 12753 +6 Misses 1087 1087 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

🚨 Try these New Features:

schreiberx commented 1 week ago

Back to @arporter

arporter commented 1 week ago

Hi @schreiberx, please could you address the Black error(s) and missing coverage? Thanks :-)

schreiberx commented 1 week ago

Back to @arporter

schreiberx commented 1 week ago

Back to @arporter

schreiberx commented 5 days ago

Thanks Martin, I like the new/extended tests. Probably worth putting in a bit more Fortran into the example code in both just to exercise things a bit more.

However, @sergisiso raises a good point about the symbol table. Currently, there is a single, global fparser.two.symbol_table.SYMBOL_TABLES object that holds information on all scoping regions encountered during a parse. We made it like this so that it is easily available whenever needed during fparser's complex, recursive execution. We need to think about whether we pickle it separately or whether we can somehow attach it to the parse tree.

fparser.two.symbol_table.SYMBOL_TABLES is a separate thing and I don't see this to be related to this deepcopy issue. Maybe open another one?

schreiberx commented 5 days ago

Back to @arporter

sergisiso commented 5 days ago

@arporter @schreiberx Yes I am happy. I forgot that in fparser the symbol_table is only a supporting state to recurse down the tree, but not part of the output (all declaration info is in the parsetree). So I agree should not be part of the cache, sorry for the confusion.

arporter commented 2 days ago

@arporter @schreiberx Yes I am happy. I forgot that in fparser the symbol_table is only a supporting state to recurse down the tree, but not part of the output (all declaration info is in the parsetree). So I agree should not be part of the cache, sorry for the confusion.

Thanks @sergisiso, I'll proceed to merge.