nim-lang / RFCs

A repository for your Nim proposals.
135 stars 26 forks source link

Type mismatch errors #325

Open haxscramper opened 3 years ago

haxscramper commented 3 years ago

Current error outputs just dumps all possible overloads, without determining their validity in given context. When working on some high-level code, seeing 40+ overloads for add, when you just tried to append to let variable is insanely annoying.

By default, some mismatches are hidden, but particular logic is not entirely clear - it is possible to have one out of four overloads hidden in one case, but for mismatch on + you can get several screens worth of text.

Scored type mismatch listing

Possible solution would be to introduce score-based system for determining validity of each overload. Possible rules might include:

Any other score rules - I just listed more obvious ones.

If all overload alternatives have very low score, enable additional heuristics for error suggestion.

Better formatting

Current way of formatting output AST also leaves a lot of room form improvement - providing optional colored suggestion, aligning function calls, arguments. This is partially related to https://github.com/nim-lang/RFCs/issues/324 (as users might create own pretty-printers with extended heuristics), but the default implementation needs to be addressed too.

This is especially notable in case of callback type mismatches - differing noSideEffect, gcsafe annotations are not easily spotted. Providing tree-based diffing for types and emphasizing only mismatching parts would certainly help a lot.

In short - I think that errors like this are completely unacceptable, no matter how complex code is. Good formatting and basic AST coloring are the way to go for easy-to-understand error messages.

image

haxscramper commented 3 years ago

Split into separate RFC from https://github.com/nim-lang/RFCs/issues/322

haxscramper commented 3 years ago

I haven't mentioned tetrahedron of pain - static/generics/concept/types-in-macros - mainly because I don't have any concrete input on this topic, but I thing some other people do, so I decided to not introduce more noise in the discussion.