Fortran Parser -- last call

[Philippe Marguinaud]

Hi Janne,


Janne Blomqvist a écrit :
> 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.
> 

I am happy that you like the idea.

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

Very interesting, I was not aware of that.

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

I understand this point of view.

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

I have not time for doing that. I want to do something which serves my 
own purposes.
If someday it is agreed that gfortran should include the capability of 
making the parser results available to the outside world, I would be 
happy to participate.

Regards,

Philippe