GNOME Bugzilla – Bug 626476
FORTRAN label before end statement
Last modified: 2011-11-01 11:49:44 UTC
In case a label appears in front of an end statement of a subroutine (and probably also function and module) Doxygen will give an error message: Preprocessing C:/Users/user/AppData/Local/Temp/Excite/lab1.f90... Parsing file C:/Users/user/AppData/Local/Temp/Excite/lab1.f90... ******************************************************************** Error in file C:/Users/user/AppData/Local/Temp/Excite/lab1.f90 line: 5, state: 4 ******************************************************************** This occurs for fixed formatted code and for free formatted code. Source code: ! Subroutine tst() 9999 end
Created attachment 174018 [details] [review] Allow label before end statement Allow label before end statement of a program unit.
Hi Albert, Something seems to have gone wrong with this patch. The attachment only contains the command to make the patch not the patch itself.
Created attachment 174099 [details] [review] Allow label before end statement Oops was indeed the script to generate the patch. I hope this attachment is better.
Review of attachment 174099 [details] [review]: wouldn't it be better to do ^{BS}([0-9]*{BS_})?"end"... i.e. should a number always be following by a blank, or is it also valid Fortran to write 10end
Just tried it with a compiler but 10end is accepted in free formatted code by this compiler. In the standard I could not find anything further, but I did find that the label can contain a maximum of 5 digits and that at the label 00000 is not allowed. I think the code should be compilable, so Doxygen does not have to bother with the fact if the code is valid or not. The rules in Doxygen can be a bit less stringent. Personally I would never write 10end in a program, but always use a space in between.
If it is allowed, then doxygen should support it, so I'll include your patch as is.
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.
Label recognized properly