After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 796621 - @cond does not stop at @endcond Fortran
@cond does not stop at @endcond Fortran
Status: RESOLVED OBSOLETE
Product: doxygen
Classification: Other
Component: general
1.8.14
Other Windows
: Normal major
: ---
Assigned To: Dimitri van Heesch
Dimitri van Heesch
[moved_to_github]
Depends on:
Blocks:
 
 
Reported: 2018-06-18 17:22 UTC by marandus
Modified: 2018-07-30 10:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Self-contained test (28.58 KB, application/x-zip-compressed)
2018-06-19 11:24 UTC, marandus
Details

Description marandus 2018-06-18 17:22:55 UTC
!<@cond scan
    function ModelPath(AuxString, Level)    
        ...    
    end function ModelPath
!<@endcond

produces 

error: Conditional section with label  scan does not have a corresponding \endcond command within this file. (warning treated as error, aborting now)
*** Doxygen has finished

Have tried variations of the syntax to no avail. inside the function is a fortran intrinsic 'scan' that Doxygen can't handle and simply exits when reached during parsing.
Comment 1 albert 2018-06-18 18:03:29 UTC
I tried to reproduce the problem, but didn't succeed.

Can you please attach a, small, self contained example (source+config file in a tar or zip) that allows us to reproduce the problem?
Comment 2 marandus 2018-06-19 11:24:30 UTC
Created attachment 372721 [details]
Self-contained test

So, the problem is more complex in behavior than I previously exposed.

In the example you can see two uses of 'scan' in the same function. If the second use, inside the conditional statement, is commented out Doxy runs and @cond works as expected I believe. Otherwise the error occurs.
Comment 3 albert 2018-06-19 11:38:15 UTC
The problem here is that doxygen has some problems with the backslash in Fortran.

When I use a backslash I use the parameter:
  CHARACTER(LEN=1), PARAMETER :: backSlash = char(92) !< the back slash (\\) character

and concatenate this into the string.
Comment 4 marandus 2018-06-19 13:07:16 UTC
(In reply to albert from comment #3)
> The problem here is that doxygen has some problems with the backslash in
> Fortran.
> 
> When I use a backslash I use the parameter:
>   CHARACTER(LEN=1), PARAMETER :: backSlash = char(92) !< the back slash (\\)
> character
> 
> and concatenate this into the string.

Thank you very much.

Can you think of any other way to force the doxygen parser to simply not read the '\'? I'm not at the liberty to change the source at this moment...
Comment 5 albert 2018-06-19 13:09:37 UTC
No I didn't find a solution, therefore I used the parameter as indicated.
Comment 6 marandus 2018-06-19 13:42:48 UTC
Thank you!
Comment 7 albert 2018-06-19 13:56:58 UTC
Looks like I found a workaround, don't use " (double quotes) but ' (single quotes)
Comment 8 albert 2018-06-19 17:50:00 UTC
The previous comment was not completely correct but a bit luck (due to the ' in doesn't.

I checked the code and I've just pushed a proposed patch to github (pull request 773, https://github.com/doxygen/doxygen/pull/773).
Comment 9 André Klapper 2018-07-30 10:58:48 UTC
As discussed in https://github.com/doxygen/doxygen/pull/734 , Doxygen has moved its issue tracking to 

   https://github.com/doxygen/doxygen/issues

All Doxygen tickets in GNOME Bugzilla have been migrated to Github. You can subscribe and participate in the new ticket in Github. You can find the corresponding Github ticket by searching for its Bugzilla ID (number) in Github.

Hence I am closing this GNOME Bugzilla ticket.
Please use the corresponding ticket in Github instead. Thanks a lot!