Fortran: Missing characters in definition (Origin: bugzilla #565715)

[doxygen]

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

Original attachment names and IDs:

• patch_565715.res (ID 173946)
• patch_565715_1.res (ID 173954)

On 2008-12-26 19:51:25 +0000, albert wrote:

Missing characters with character string definitions in documentation.
In this case the last R of PARMETER and last ) in function definition

Examle code:

MODULE bug_str
CHARACTER( * ), PRIVATE, PARAMETER :: LOWER_CASE = 'abcde'

  CONTAINS
     FUNCTION StrUpCase ( Input_String ) RESULT ( Output_String )
       CHARACTER( * ), INTENT( IN ) :: Input_String
       CHARACTER( LEN( Input_String ) ) :: Output_String
       Output_String = ''
     END FUNCTION StrUpCase

END MODULE bug_str

Resulting documentation:

Namespaces
namespace bug_str

Functions
CHARACTER(LEN(Input_String) bug_str::StrUpCase (Input_String)

Variables
CHARACTER(*), paramete bug_str::LOWER_CASE )

On 2008-12-26 20:06:26 +0000, albert wrote:

With the variable there is also an extra ) at the end of the line
The value is not show in the documentation
The specifier PRIVATE is not taken int account

On 2008-12-28 09:57:34 +0000, albert wrote:

Some further investigations lead to that the possible cause of the problem is the '' in the length definition of the character string (just as '()' as well as '(len=*)'.

On 2010-02-26 21:43:27 +0000, Daniel Franke wrote:

Not sure about the '*' yet, but in fortranscanner.l on finds:

ARGS {BS}("("[^)]")")
CHAR (CHARACTER{ARGS}?|CHARACTER{BS}""({BS}[0-9]+|{ARGS}))

which, applied to

CHARACTER( LEN( Input_String ) ) :: Output_String

stops at the first closing ')'; thus matching as type definition

CHARACTER( LEN( Input_String )

only.

On 2010-02-26 21:44:15 +0000, Daniel Franke wrote:

*** Bug 572736 has been marked as a duplicate of this bug. ***

On 2010-11-06 14:00:59 +0000, albert wrote:

Created attachment 173946
Patch for problems reported in this bug report

This bug contains the description of a number of bugs which are all handled in this patch as well as the bug reported in bug 633985.
I'll try to list the patches and references to the files (in the patch) that are modified for this problem:

All patches are against the svn version of October 10 2010 (1.7.2)

• public, private not recognized:
  example: CHARACTER( * ), PRIVATE, PARAMETER :: LOWER_CASE = 'abcde'
  problem was that the words public and private were not handled
  patched in fortranscanner.l line 1327

• round brackets inside length definition of character string
  example: CHARACTER( LEN( Input_String ) ) :: Output_String and also bug 572736
  problem new definition of part betwen brackets required (currently one extra level of round brackets)
  patched in fortranscanner.l line 211 and fortrancode.l line 645

• character() not properly recognized as variable, removing ) and placing it with the name.
  example: CHARACTER( * ),PARAMETER :: LOWER_CASE = 'abcde'
  problem character() was recognized as C function pointer and handled as such. Set language in Entry item and corrected routine that checks if it is a function pointer.
  patched in fortranscanner.l lines 377, 391, 1485, 1706 and doxygen.cpp lines 2197, 2381, 6164

• character() not recognized as function (bug 622985)
  example: character(*) function a()
  end function
  problem similar to the above part but now for functions. Fix requires and extra item in EntrNav
  patched in entry.h lines 413, 432, entry.cpp line 366 and doxygen.cpp line 2593

On 2010-11-06 14:04:11 +0000, albert wrote:

oops, patch refers at the end to bug 622985, this has to be bug 633985, sorry.

On 2010-11-06 16:07:45 +0000, Dimitri van Heesch wrote:

*** Bug 633985 has been marked as a duplicate of this bug. ***

On 2010-11-06 16:08:14 +0000, albert wrote:

Created attachment 173954
Corrected patch file

Found bug 593680 also describing problems with round brackets (also filed by me).
Made bug fix more general and added one extra level of nesting of round brackets.
This bug fix includes all described in the previous patch.

On 2010-11-06 16:11:42 +0000, albert wrote:

*** Bug 593680 has been marked as a duplicate of this bug. ***

On 2010-11-06 18:35:51 +0000, Dimitri van Heesch wrote:

Thanks Albert,

I'll include your latest patch in the next subversion update.

On 2010-11-06 22:31:47 +0000, Daniel Franke wrote:

Thanks Albert, works like a charm!

On 2010-11-14 21:56:50 +0000, Daniel Franke wrote:

Could this PR be closed?

On 2010-11-14 22:45:15 +0000, albert wrote:

Daniel,

I've asked the same question to Dimitri and the answer was: when a bug
is solved in Dimitri's local build he sets the status to ASSIGNED.
When creating a release all ASSIGNED bugs are set to RESOLVED with the
request to the submitter to check if the BUG is really resolved.

Albert

On 2010-11-14 22:56:42 +0000, Daniel Franke wrote:

Hu? I'm used to RESOLVE FIXED if a fix went to svn and is available for testing, REOPEN if not fixed after all?!

Different project, different rules. So be it.

On 2010-11-15 08:39:01 +0000, albert wrote:

Hi Daniel,

Isn't this exactly what is happening. When Dimitri sends the patches to svn he sets the status to resolved. As soon as he receives a patch and incorporates it in his own version he sets the status to assigned.
There is no write access for us to the repository, I think this is OK, some quality checking before committing a patch is always good. Some more frequent updates of the repository would also be nice, but we have to keep in mind that all the work done is voluntary (and much appreciated)!!

I don't think we should continue this discussion in this bug but when necessary in the Doxygen-development forum.

Albert

On 2011-01-03 19:01:22 +0000, Dimitri van Heesch wrote:

This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.7.3. 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 2011-11-01 13:17:03 +0000, albert wrote:

Problem fixed, works like Daniels specifies OK.