FORTRAN: marking non private subroutine as private (Origin: bugzilla #625731)

[doxygen]

status VERIFIED severity normal in component general for ---
Reported in version 1.7.1 on platform Other
Assigned to: Dimitri van Heesch

Original attachment names and IDs:

• priv.zip (ID 166897)
• patch_625731.res (ID 181630)

On 2010-07-31 20:44:40 +0000, albert wrote:

Created attachment 166897
Source code and html output

When having the following source code:
module priv
private

contains
subroutine p_fie1
end
subroutine p_fie2
end
end

The function p_fie2 is marked as private, this should not be the case p_fie1 and p_fie2 are public (see also attachment with source code and resulting html output)

On 2010-11-14 21:39:13 +0000, Daniel Franke wrote:

(In reply to comment # 0)

The function p_fie2 is marked as private, this should not be the case p_fie1
and p_fie2 are public (see also attachment with source code and resulting html
output)

I think this is incorrect. The PRIVATE statement in example in # 0 resets the default and sets the default accessibility in the module to PRIVATE. Hence, both procedures in MODULE priv are private and should not be documented unless EXTRACT_PRIVATE is set.

However, for

MODULE priv
PRIVATE
PUBLIC :: p_fie1
[...]

procedure p_fie1 is public while p_fie2 is private.
For

MODULE priv
PRIVATE :: p_fie2
[...]

only p_fie2 is hidden and all other elements of the module remain PUBLIC.

Another example:

MODULE
INTEGER :: foo, bar

PRIVATE
PUBLIC :: foo
END MODULE

Here, FOO is public and should be documented, BAR not. Currently (r746), both are publicly visible as the PRIVATE statement does not reset the default accessibility rules of variables already seen.

On 2010-11-15 09:58:44 +0000, Keith Refson wrote:

I agree with Daniel that the original case reported was incorrect. However
there are still cases where the public/private aspects are incorrectly handled.

In the following code, type MYTYPE is public by the explicit modifier although
the default is PRIVATE. However the type is treated as private and not
documented.

---

!> \brief doxygen module test
!!
!! Test for malfunction on PRIVATE
!<
module private_test
implicit none

! Type "mytype is NOT detected if PRIVATE statement here
private

!> @brief Description of type
type, public :: mytype
integer :: cpt !< Description of member
end type mytype

! Type "mytype is detected if PRIVATE statement here
! private

end module private_test

On 2010-11-15 10:05:06 +0000, albert wrote:

I've checked it and indeed my original case is incorrect. The both members should be private.

On 2010-12-14 13:39:07 +0000, Daniel Franke wrote:

When comparing a Fortran MODULE with a private variable and a C++ class with a private member, the difference in documentation boils down to the respective section: the MODULE has a section "Variables", while the class has a section "Private Attributes".

Changing the Fortran MODULE to list Private|Public Attributes instead of variables could be the first step to fix this - besides a significant update of the relevant parsing code.

Testcase:

MODULE access
PRIVATE
INTEGER :: a
END MODULE

class access {
private:
int a;
};

On 2010-12-19 19:05:59 +0000, Daniel Franke wrote:

This already helps a bit, but parsing of accessibility attributes and statements meeds to be improved as well.

Index: src/fortranscanner.l

--- src/fortranscanner.l (revision 749)
+++ src/fortranscanner.l (working copy)
@@ -1527,7 +1527,7 @@
//fprintf(stderr, "0=========> got module %s\n", name);

if (isModule)

• current->section = Entry::NAMESPACE_SEC;

• current->section = Entry::CLASS_SEC;
  else
  current->section = Entry::FUNCTION_SEC;

On 2011-02-22 20:02:05 +0000, albert wrote:

Created attachment 181630
Patch so variables should have the correct public / private attribute

Patch so variables should have the correct public / private attribute.
Don't have enough test material to test all, so extra examples (with problems) are welcome.

On 2011-02-24 21:38:48 +0000, albert wrote:

The patch as proposed by Daniel (included in my patch file) looks like to have a positive effect on the search function too. Variables in a module can be searched now as well, not only variables in types.

On 2011-05-15 09:44:45 +0000, Dimitri van Heesch wrote:

Thanks,

I'll include this patch in the next subversion update.

On 2011-08-14 14:05:17 +0000, Dimitri van Heesch wrote:

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.

On 2013-08-24 13:30:20 +0000, albert wrote:

Checked the examples and all looks OK now.