GNOME Bugzilla – Bug 565715
Fortran: Missing characters in definition
Last modified: 2011-11-01 13:17:03 UTC
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 )
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
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=*)'.
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.
*** Bug 572736 has been marked as a duplicate of this bug. ***
Created attachment 173946 [details] [review] 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
oops, patch refers at the end to bug 622985, this has to be bug 633985, sorry.
*** Bug 633985 has been marked as a duplicate of this bug. ***
Created attachment 173954 [details] [review] 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.
*** Bug 593680 has been marked as a duplicate of this bug. ***
Thanks Albert, I'll include your latest patch in the next subversion update.
Thanks Albert, works like a charm!
Could this PR be closed?
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
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.
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
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.
Problem fixed, works like Daniels specifies OK.