New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

doxygen opened this Issue Jul 2, 2018 · 0 comments


None yet
1 participant

doxygen commented Jul 2, 2018

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:

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

subroutine p_fie1
subroutine p_fie2

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

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

PUBLIC :: p_fie1

procedure p_fie1 is public while p_fie2 is private.

PRIVATE :: p_fie2

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

Another example:

INTEGER :: foo, bar

PUBLIC :: foo

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

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

! Type "mytype is NOT detected if PRIVATE statement here

!> @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.


MODULE access

class access {
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;
    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:


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.

@doxygen doxygen closed this Jul 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment