GNOME Bugzilla – Bug 637099
Fortran: Collaboration diagram
Last modified: 2012-11-18 11:13:03 UTC
Created attachment 176306 [details] Input and result described bug When creating a collaboration diagram for the type typ1: module prec_mod integer, parameter :: prec = kind(1.d0) end module tst1 use prec_mod, only: prec type typ1 integer :: Press1 real(prec) :: Mass1 end type typ1 end module tst1 The collaboration diagram states that Mass1 is of type prec and not of real(prec). When changing the use statement into "use prec_mod" the collaboration diagram is OK. Note that in the data fields list the type is correct, looks like somewhere in the generating of th dot file a replacement is made.
Created attachment 176312 [details] Input and results for second part of bug message
Extension to the above bug (comment 1): - when using: "integer, pointer :: Press1(:)" the collaboration diagram for this variable is OK but the description is missing the (:) / dimension(:) - when using: "integer, pointer,dimension(:) :: Press2" the description is OK but the collaboration diagram contains as data type: "),pointer" See also 2nd attachment
Confirmed. Should the standard data types should show up in the collaboration diagram to begin with? For C it seems to be struct/class, i.e. derived type, only?! Further, should the attributes be kept in the collaboration diagram? E.g. TYPE :: aa END TYPE TYPE :: bb TYPE(aa), DIMESION(:), POINTER :: a END TYPE Here, bb should only show a link to aa, nothing else (attributes are not relevant), no?
With the latest update (r751), this seems to be fixed?! Albert, can you confirm?
Unfortunately, the bug is not fixed in r751. I still see just the word prec in the collaboration diagram and not real(prec).
(In reply to comment #5) > Unfortunately, the bug is not fixed in r751. I still see just the word prec in > the collaboration diagram and not real(prec). Here, I don't see any REAL any more, only TYPEs? Is this configurable?
The problem is that I don't see the REAL, this should be there and not just the word prec.. The type of the variable is REAL(prec) where prec signals the KIND type of the variable.
Ok, I doule checked again. Now, I again got all members of the TYPE in the graph, including intrinsic types (REAL, INTEGER, ...)?! Errr ... However, I'd prefer it if we could omit intrinsic types and their variants (w/o dimension, w/o allocatable, ...) and only show the TYPEs. I believe, that's how it is done for C/C++.
I think the KIND information is basic information required in the collaboration diagram. Same accounts more or less for the dimension information (in a condensed form like INTEGER(:,:) or for C **int). I agree that the modifiers should appear in the collaboration diagram.
(In reply to comment #8) > I'd prefer it if we could omit intrinsic types and their variants (w/o > dimension, w/o allocatable, ...) and only show the TYPEs. (In reply to comment #9) > I agree that the modifiers should appear in the collaboration diagram. You agree to disagree? Please clarify ;)
Oops word not disappeared in the last sentence. I think the KIND information is basic information required in the collaboration diagram. Same accounts more or less for the dimension information (in a condensed form like INTEGER(:,:) or for C **int). I agree that the modifiers (words like allocatable, pointer) should not appear in the collaboration diagram.
(In reply to comment #6) > Here, I don't see any REAL any more, only TYPEs? > Is this configurable? HIDE_UNDOC_RELATIONS = YES|NO If set to YES, the intrinsic types are omitted. With this I agree, one should have the whole (intrinsic) type available. Back to square one. With above config option enabled, the types are still partially wrong.
Created attachment 181409 [details] [review] Patch file for collaboration diagram This file contains a patch for the problems with the Fortran collaboration diagrams. - fixing problem with substitution names in use statements - fixing single colon (:) problem - fixing having variable names in bottom part (function part) of collaboration diagrams
Thanks Albert, I'll include this patch in the next subversion update.
This bug was previously marked ASSIGNED, which means it should be fixed in doxygen version 1.7.5. Please verify if this is indeed the case. Reopen the bug if you think it is not fixed and please include any additional information that you think can be relevant.