New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FORTRAN: recognition free versus fixed formatted code (Origin: bugzilla #625601) #3879

Closed
doxygen opened this Issue Jul 2, 2018 · 0 comments

Comments

Projects
None yet
1 participant
@doxygen
Owner

doxygen commented Jul 2, 2018

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

Original attachment names and IDs:

On 2010-07-29 17:19:58 +0000, albert wrote:

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.

On 2010-11-07 19:04:31 +0000, albert wrote:

Created attachment 174008
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).

On 2010-11-08 21:05:02 +0000, Dimitri van Heesch wrote:

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?

On 2010-11-08 21:08:00 +0000, Dimitri van Heesch wrote:

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!

On 2010-11-08 21:15:02 +0000, albert wrote:

(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.

On 2010-11-08 21:17:46 +0000, albert wrote:

(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.

On 2010-12-22 19:30:33 +0000, Daniel Franke wrote:

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

On 2010-12-22 19:35:00 +0000, Daniel Franke wrote:

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.

On 2010-12-22 19:46:00 +0000, Daniel Franke wrote:

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

On 2011-01-19 23:46:03 +0000, Daniel Franke wrote:

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


On 2011-07-17 13:02:43 +0000, Dimitri van Heesch wrote:

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

On 2011-11-20 15:15:02 +0000, Dimitri van Heesch wrote:

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

On 2012-02-19 21:07:24 +0000, Dimitri van Heesch wrote:

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

On 2013-03-16 19:51:24 +0000, albert wrote:

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

On 2013-04-14 12:32:29 +0000, albert wrote:

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

On 2014-03-09 18:00:25 +0000, albert wrote:

I've pushed the solution with EXTENSION_MAPPING to github (pull request 134)

On 2014-03-15 19:25:06 +0000, Dimitri van Heesch wrote:

Thanks, I've pull it in.

On 2014-04-21 10:09:32 +0000, Dimitri van Heesch wrote:

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).

On 2014-06-19 15:54:40 +0000, albert wrote:

dnm found a typo i the documentation. Pull request 185 has been submitted for this.

On 2014-11-22 11:50:39 +0000, Dimitri van Heesch wrote:

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

@doxygen doxygen closed this Jul 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment