[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [photran] Definition#findAllReferences(…) seem broken across multiple files
|
Hi Nick,
Part of this is a bug, and part of it isn't.
3) Try to invoke any of the refactorings that work on subroutines, e.g., "Add Subroutine Parameter" or "Permute Subroutine Parameters".
4) Notice that it will not change the call sites in the main.f90 file.
...
I tried the Fortran search feature. And when I searched for "calc" (one of the names of the subroutines in subroutines.f90) it only returns the definition and not any of the references across the files.
These are definitely bugs. Please file a bug report.
find the references to the Definition does not.
Actually, the problem with your example is that our API isn't very
consistent: external subroutines are handled differently than other
identifiers.
#findAllReferences finds references to variables, subprograms imported
from modules, declarations in INTERFACE blocks -- more or less, things
where a compiler could definitely figure out a unique binding even when
doing separate compilation.
Your sample program uses external subroutines. Unfortunately, you have
to use some other methods to figure out where else the "same" subroutine
is declared in a program. See
PhotranVPG#findAllExternalSubprogramsNamed and
PhotranVPG#findAllDeclarationsInInterfacesForExternalSubprogram. I
think the Rename refactoring uses this to rename subprograms across files.
The theory was that, since Photran doesn't know what the linker does, it
can only guess that a particular call site "may" bind to a particular
definition -- whereas, with a variable or a module subprogram, it can
determine that a particular call site "must" bind to a particular
definition. So, #findAllReferences only provides "must" binding
information.
That's the theory. As for practice, the API could be a lot more
consistent and a lot less confusing, I agree... what we have was thrown
together fairly quickly...
Jeff
