Provide type information to rules

[jfmengels]

It would be really nice if we could provide type information to rules, so that they provide more useful analysises.

Just like elm-review-scope and the module name lookup table, we could start by having some visitors we could add, and when we're happy with the result, we could make turn this into a native functionality using something like a .

What I'm looking for

Use-cases where this would be useful

If we don't find enough interesting use-cases, it's probably not worth implementing.

• Knowing what the type of a function is would allow NoMissingTypeAnnotation and NoMissingTypeAnnotationInLetIn to provide an automatic fix. That said, it will probably not provide the exact type annotation you'd want (when dealing with records mostly) as I have experienced with IDE features that do this, but it will definitely be a helpful boost.

Advice on how to implement it

I know nothing of how type inference is done, and how it can be made efficient. I imagine that we can somehow take shortcuts, as we are not trying to validate types, since we already let the compiler handle that for us.

I know Evan said that the type inference algorithm used by Elm cannot be done in a performant manner without mutation, but I have no clue whether that applies to figuring out types and/or for validating them.

A note on compiler integration

I mentioned in jfmengels/elm-review#40 that it would be possible to fork the compiler and use the type inference information (and even AST) it provides and pass it directly to the rules. While that sounds attractive, it does bring a lot of lock-in which would have a lot of impact on how tests would be written and where elm-review could be used.

My current thoughts are: Get this working natively well, and later on we could potentially fork the compiler and re-use its information but only for performance concerns. That would allow elm-review to still be able to write the tests like it does and to be run wherever Elm can be run.

[jfmengels]

I started adding type inference logic to one of the NoMissingTypeAnnotation rules where I can polish it more and more until I'm happy with the results it gives. I am still unsure how useful this information could be for other rules, but I imagine I will make it work natively once I consider it to work well. Please comment if you see a use-case for type inference, and if you want me to make it accessible to you in a non-native way (just like elm-review-scope was before it became native).