GNOME Bugzilla – Bug 625601
FORTRAN: recognition free versus fixed formatted code
Last modified: 2014-11-22 11:50:39 UTC
When fixed formatted code has as a first line a line starting with an exclamation mark it is "recognized" as free formatted. There will be probably more examples (Character function in free formatted code, thus starting with a C in position 1). Possible solutions: - correct / improve recognition of type formatted code in routine recognizeFixedForm - generate possibility to specify type of code by means of extension (i.e. through the available EXTENSION_MAPPING possibilities.
Created attachment 174008 [details] [review] EXTENSION_MAPPING for Fortran free and fixed format This patch extends the EXTENSION_MAPPING in respect to Fortran code. It is now possible to specify by means of EXTENSION_MAPPING whether files with a certain extension are fixed or free formatted Fortran files (Fortran_Fixed, Fortran_Free. The default remains Fortran, the scanner makes a guess).
Hi Albert, This patch is a dangerous one, as it undoes a number of changes I made! I can manually edit the patch before applying it, but please check next time if the patch only contains the changes you made and nothing more. As for the implementation: I would prefer an automatic detection of the format if possible. A general design goal of doxygen is to put the complexity in the tool when possible, instead of bothering the user with it. Do you think this is possible by improving the format recognition?
One more thing: in config.xml the trailing spaces are (ab)used in the wizard for the online help. Removing them will concatenate the last word with the first word on the next line!
(In reply to comment #2) > Hi Albert, > > This patch is a dangerous one, as it undoes a number of changes I made! > I can manually edit the patch before applying it, but please check next time if > the patch only contains the changes you made and nothing more. > > As for the implementation: I would prefer an automatic detection of the format > if possible. A general design goal of doxygen is to put the complexity in the > tool when possible, instead of bothering the user with it. Do you think this is > possible by improving the format recognition? Hi Dimitri, I thought I checked if the patch was only incorporating my changes, but I see that I undo at least one of your changes. Sorry for that. I would also prefer an automatic detection, but I think it is quite complicated and require possible scanning of the input to a bigger extent.
(In reply to comment #3) > One more thing: in config.xml the trailing spaces are (ab)used in the wizard > for the online help. Removing them will concatenate the last word with the > first word on the next line! Sorry, this was unknown to me, but it makes sense in this file. I general I don't like spaces at the end of lines.
*** Bug 617190 has been marked as a duplicate of this bug. ***
To mention it: other tools use the extension as an indicator: fixed form: .f .for .ftn free form: .f90 .f95 .f03 f.08 Capital letters for preprocessing. I.e .FOR a preprocessed fixed-form source, .f90 free-form without preprocessing. Simple and widely recognized.
*** Bug 623299 has been marked as a duplicate of this bug. ***
Here's another bad case where free form is "recognized" as fixed form: !> !> @brief COMPLEX function. !> COMPLEX FUNCTION f(z) COMPLEX, INTENT(in) :: z f = CONJG(z) END FUNCTION In particular (note the replaced 'C' of the function return type COMPLEX): --accepting rule at line 288 ("!OMPLEX FUNCTION f(z) ") This ends with: ******************************************************************** Error in file [...].f90 line: 10, state: 10 ********************************************************************
*** Bug 653356 has been marked as a duplicate of this bug. ***
*** Bug 664277 has been marked as a duplicate of this bug. ***
*** Bug 510983 has been marked as a duplicate of this bug. ***
*** Bug 657568 has been marked as a duplicate of this bug. ***
*** Bug 659173 has been marked as a duplicate of this bug. ***
I've pushed the solution with EXTENSION_MAPPING to github (pull request 134)
Thanks, I've pull it in.
This bug was previously marked ASSIGNED, which means it should be fixed in doxygen version 1.8.7. 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 (preferrably in the form of a self-contained example).
dnm found a typo i the documentation. Pull request 185 has been submitted for this.
*** Bug 740366 has been marked as a duplicate of this bug. ***