Fortran Parser -- last call

[Janne Blomqvist]

On Wed, Dec 3, 2008 at 18:47, Philippe Marguinaud
<philippe.marguinaud@meteo.fr> wrote:
> I would like to have an answer about whether it is OK or not to work on the
> gfortran parser. If the answer is yes, please tell how I should proceed.

Not having looked into your project in detail, but generally speaking
I think projects like these are potentially very useful. Fortran is
not entirely trivial to parse, and being able to reuse a full-featured
parser like gfortran for non-traditional uses like static analysis (an
'enhanced ftnchek' was already mentioned), refactoring, IDE
integration, etc., would be a huge help for such projects.

The general problem itself is of course not Fortran-specific. E.g.
mozilla has been working on doing automatic rewriting of their C++
codebase using (among others) g++-derived static analyzers (see
https://wiki.mozilla.org/DeHydra and https://wiki.mozilla.org/Pork ).
There's also the GCC-XML project which apparently does something
similar to your project, but for C++
(http://www.gccxml.org/HTML/Index.html). And, even more off-topic,
better usability for non-traditional uses is an explicit goal of the
clang llvm frontend ( http://clang.llvm.org/index.html ).

But, as you might know, there has been considerable opposition to
making gcc internals easier to use by outside code, mainly due to fear
of proprietary vendors reusing parts of gcc for their own uses without
contributing back. Whatever yours or mine opinion about whether this
fear is justified or not, dumping frontend output in XML definitely
counts as making internal compiler data usable by outside programs. So
even if we wanted, I don't think gfortran maintainers could accept
this without explicit approval by the GCC steering committee. The good
news is that this issue is apparently under review under the general
topic of 'GCC plugins' and will at some point result in a decision by
the SC. See http://gcc.gnu.org/wiki/GCC_Plugins for a summary of the
(endless) flamewars on the issue. So at the moment, I think the best
option is to wait for the SC decision about plugins.

That being said, if you want to hack on gfortran right away, there's
certainly a lot that could be done in the general area of static
analysis like diagnostics for stuff we miss today (e.g. something like
the -gen-interfaces + -warn interfaces etc. stuff in ifort). Or if you
want to do some major surgery on the parsing side, look into replacing
the current ad-hoc matching parser with a 'proper' lexer using Sale's
algorithm followed by recursive descent parsing (yes, this is probably
more trouble than it's worth..).

-- 
Janne Blomqvist