analyze() breaks when called twice on the same variable about f2py HOT 11 CLOSED

I think it would be much better to not reanalyze existing entities in the parse 
tree(s), because that would be 
much more efficient...

Yes, modules should be analyzed only once.
Could you provide an example code that illustrates this issue?

oh.. hold on... i figured it out.. the assertion error happens actually not 
because of multiple USEs but only 
because the array is defined in a derived type defintion.
Here is a little example:

-----
MODULE test

TYPE t
    integer, dimension(:,:), pointer :: a
END TYPE t

END MODULE test
-----

I have fixed the bug, see the diff in the block_statements.py file. The 
original code calls first 
BeginStatement.analyze(self) on the Type instance, which will call in turn the 
analyze function on all elements 
of content in this instance. But after analyzing the elements of spec the code 
iterates again over content, 
which causes the assertion failure. This assertion is only checked when the 
field in the derived type is an array 
(i.e. has the dimension keyword) So we either have to remove this assertion or 
move it to another place in the 
update routine where it would be checked for all variables, not only arrays.

I atteched a diff with a couple more changes, I caught 1 or 2 other things that 
I think are bugs.

After applying those patches I still see one possible problem. Even though the 
parser seems to be handling it 
correctly, I still think that if a module A in used in modules B and C, and 
both B and C are included in D, then 
A is loaded twice.. that could be avoided, right? I've attached an example.. if 
you read, parse and analyze 
testd.f90 you'll see what I mean..

Thanks!

The attached test.zip file seems to be empty.
I have applied your patch to svn, except the readfortran.py that probably
contained only debugging code.

Previous comment is mine, not my wifes:)

Ok :) I assumed so..

the diff in readfortran.py is actually strange.. what I did is add source_only 
= None in the base class 
(FortranReaderBase) (in the init function) because find_module_source_file uses 
source_only, without that I got an 
exception when this function was called.
yepp.. the test.zip was broken.. I tried to pack those files again.. 

When parsing testd.f90, I get warnings that entities a (defined in testa)
and x (defined in testb) are already defined in module c.

This happens when processing statement `use testc`.
After analyzing the code, here is how is I understand the situation:
The entities a and x are added to testd as a result of processing
the statement `use testb`. Note that at the same time testc provides
y (irrelevant here) in addition to a and x. So, when processing
`use testc`, the analyzer tries to add the content of testc to
testd, that is, add a,x,t to testd. Now a,x are already there
due to `use testb` and that triggers the warnings.

I am looking at the fix momentarily. The fix should not to give
a warning when adding equivalent entities from different modules
and warn only if different modules defines different entities with
the same name.

I just committed a fix to svn. 

Though there was a warning indicating
duplicate loading of a, it was not actually loaded twise.
The warning code just did not take into account that the
same entity could be loaded via several use paths.

Great!
One more thing..
One change I did that you did not include in the patch is adding '.f' into the 
list of module_file_extensions. Would 
it be a bug to have the .f in that list? the reason I added it, was that when 
the reader searched for module files 
(get_module_file) it didn't consider files ending with .f - however the fortran 
project I am working on is in F90 but 
still uses .f extensions for all fortran files. So, adding the .f was a quick 
fix for that, but if that would cause 
problems elsewhere then we maybe need a better solution...
Thanks!

It seems that using the Fortran file name extensions is
not so reliable way to determine the used standard and the 
format of Fortran source code, unless it explicitely is
.f90, .f95,  f03, .f08, or .f77. As it seems, .f
is becoming more popular for f90 and newer codes though
many programs still consider .f files as Fortran 77 files.

I think it is safe to add .f to module_file_extensions,
I must forgot it.

Done!

I will close this issue..