Fortran-FOSS-Programmers / ford

Automatically generates FORtran Documentation from comments within the code.
https://forddocs.readthedocs.io
GNU General Public License v3.0
405 stars 131 forks source link

Types declared within subroutines #70

Closed jacobwilliams closed 9 years ago

jacobwilliams commented 9 years ago

I'm getting a ford crash with this file. The error is:

Traceback (most recent call last):
  File "/Users/anaconda/bin/ford", line 9, in <module>
    load_entry_point('FORD==4.1.0', 'console_scripts', 'ford')()
  File "/Users/anaconda/lib/python2.7/site-packages/ford/__init__.py", line 269, in main
    process()
  File "/Users/anaconda/lib/python2.7/site-packages/ford/__init__.py", line 233, in process
    project.correlate()
  File "/Users/anaconda/lib/python2.7/site-packages/ford/fortran_project.py", line 167, in correlate
    if type(container) != str: container.correlate(self)
  File "/Users/anaconda/lib/python2.7/site-packages/ford/sourceform.py", line 683, in correlate
    subrtn.correlate(project)
  File "/Users/anaconda/lib/python2.7/site-packages/ford/sourceform.py", line 685, in correlate
    if dtype in self.types: dtype.correlate(project)
  File "/Users/anaconda/lib/python2.7/site-packages/ford/sourceform.py", line 1168, in correlate
    self.all_boundprocs.extend(self.extends.all_boundprocs)
AttributeError: 'FortranType' object has no attribute 'all_boundprocs'

It seems to be caused by this type declaration:

    type,extends(brent_class) :: myfunc_type
        integer :: i = 0    !! function counter
    end type myfunc_type   

which occurs within a subroutine.

cmacmackin commented 9 years ago

Sorry about that; that was a regression caused in the last release. It's fixed now. You can get the corrected version from GitHub. It will also be in the next release (hopefully coming soon--I'm just adding the ability to make dependency diagrams).

hornekyle commented 9 years ago

The ability to make dependency diagrams will be really great. Will it be at the module level, or by routine?

cmacmackin commented 9 years ago

I'm still figuring that out. So far I've been building the basic infrastructure which can be used at any level, but I haven't decided exactly when and where to generate them yet.

On 17/08/15 12:06 PM, Kyle Horne wrote:

The ability to make dependency diagrams will be really great. Will it be at the module level, or by routine?

— Reply to this email directly or view it on GitHub https://github.com/cmacmackin/ford/issues/70#issuecomment-131855954.

Chris MacMackin Saint Mary's University Curriculum Vitae http://ap.smu.ca/%7Ecmacmack/CV.pdf

hornekyle commented 9 years ago

At the very least, I would like a module-level dependency graph, showing which modules depend on which modules, as well as a routine-level graph, showing which routines depend on which routines. Each routine should also be annotated with the module in which it resides, so that the second graph can be used to reorganize modules as they grow larger and need more refined scopes.

cmacmackin commented 9 years ago

Module dependency is easy and will definitely be there. Subroutine dependency would also be easy, but I don't want to implement that unless and until I have the ability to account for function calls too. Those, unfortunately, are much more difficult.

hornekyle commented 9 years ago

I see your point about function calls being much more difficult. I suppose that FORD would need to compile a list of all known functions and then check expressions for those which are currently in scope. That is much harder than module dependencies.

What about a short-term cheat to make the graphs with a little help from the developer, like a list of called functions in the routine documentation until a better system is implemented?