Skip to content
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

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

Open
foxtran opened this issue Jan 10, 2020 · 4 comments
Open

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

foxtran opened this issue Jan 10, 2020 · 4 comments

Comments

@foxtran
Copy link

foxtran commented Jan 10, 2020

I have tried to reprint the following code:

      program main
      integer val, val
      integer val, val
      end

And lexer is not failed :-(

@madgen
Copy link
Member

madgen commented Jan 10, 2020

Why should the lexer fail?

@foxtran
Copy link
Author

foxtran commented Jan 10, 2020

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
Copy link
Member

madgen commented Jan 10, 2020

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
Copy link
Collaborator

mrd commented Jan 10, 2020

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.

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

No branches or pull requests

3 participants