(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.

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

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

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;
};

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;

Created attachment 181630 [details] [review]
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.

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.

Thanks,

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.

Checked the examples and all looks OK now.