camfort / fortran-src

Fortran parsing and static analysis infrastructure
https://hackage.haskell.org/package/fortran-src
Other
48 stars 20 forks source link

Lexer is not failed, if variable with equal names is declared #113

Open foxtran opened 4 years ago

foxtran commented 4 years ago

I have tried to reprint the following code:

      program main
      integer val, val
      integer val, val
      end

And lexer is not failed :-(

madgen commented 4 years ago

Why should the lexer fail?

foxtran commented 4 years ago

The following code is also correct:

      program main
      integer :: val
      double precision :: val
      end

And type-checker says that val is double-precisioned:

main_val1               DoublePrecision Variable
madgen commented 4 years ago

The lexer is fine because name resolution is not a lexer or a parser level problem.

The type checking bit is not though. There seems to be unintended shadowing. @mrd?

mrd commented 4 years ago

Sorry, just catching up with the flurry.

In most languages the natural thing to do is lexical scope here, which means that the second declaration takes precedence. That's how our scope analysis was programmed.

Fortran 2003 says 'C508 An entity shall not be explicitly given any attribute more than once in a scoping unit.'

However, as explained in the other report, we sometimes accept non-conforming programs because strict conformance was not a goal of the fortran-src project.

If you want to change this, check Renamer.hs where it establishes new names, to ensure that the same name was not already established in the current environment (rather than surrounding ones). I suspect there will be a subtlety in some corner cases where this change might backfire, however, so beware. If I ever get a chance, I'll take a look more closely.