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

fortran-src builtin type checker doesn't report declaration type errors #144

Open
dorchard opened this issue Apr 12, 2021 · 4 comments
Open

Comments

@dorchard
Copy link
Member

Consider:

 program ty
   implicit none

   character :: x
   x = 42

 end program ty

The -t pass doesn't report anything fishy but I think it should (if would complain if I did x = 42 + "Hello" though. Why it this? Is this a case of a mismatch between user expectations and what is going on internally?

@raehik
Copy link
Collaborator

raehik commented Apr 13, 2021

I can't find evidence of Analysis.Types checking expression types for validity after gathering those types. -t,--typecheck calls Analysis.Types.analyseTypesWithEnv', which gathers variable types and annotates expressions in the AST.

The type error on x = 42 + "Hello" occurs when the expression doesn't have an IDType associated. It's not a "binop/assign type mismatch". For some reason, using a variable instead of a constant:

program ty
  implicit none

  integer :: x, y
  character(*) :: str
  str = x // y

end program ty

checks with no errors.

My understanding is that we don't do typechecking per se. We could add another pass that uses the generated TypeEnv and intrinsic function defs to typecheck expressions like in your example. We talked about yesterday this but I forgot -- did you do anything like that in CamFort?

Edit: Wonder if a typecheck pass would fit better in CamFort so we can treat it as another analysis.

@dorchard
Copy link
Member Author

Sounds like we may just need to rename this analysis in fortran-src then so it's not misleading. Adding a proper type checking pass could fit will with CamFor yes.

@mrd
Copy link
Collaborator

mrd commented Apr 14, 2021

See analyseAndCheckTypesWithEnv

@raehik
Copy link
Collaborator

raehik commented Apr 14, 2021

I was wrong -- we do check for issues such as calling non-functions and bad array indexing. It doesn't extend to full consistency/mismatch checking.

analyseAndCheckTypesWithEnv is what --typecheck uses. It calls analyseTypesWithEnv' and returns any TypeErrors together with the other returns. The issue is that we're catching only a subset of (simple) type errors.

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

No branches or pull requests

3 participants