Hint on type error on int literal

[Julow]

Add an hint on type error on int literal where expecting int32, int64 or nativeint.

Example:

let a = 2l
let _ = Int32.add a 3

Will give:

Line 2, characters 20-21:
2 | let _ = Int32.add a 3
                        ^
Error: This expression has type int but an expression was expected of type
         int32
       Hint: Did you mean `3l'?

[nojb]

Nice! What about float?

[Julow]

float is a nice idea ! I added it.

[trefis]

Do I understand correctly that if I typed 3L instead of 3 then the hint wouldn't trigger?

[Julow]

Yes. Because 3L instead of 3 seems intentional where 3 instead of 3L may not.

[Octachron]

I think it would better if the hints were symmetric.

[Julow]

I implemented symmetry, except in two cases: to int and from float.

[Octachron]

I agree that for the float → integer direction, there is no clear hint to give in general. I am not so convinced for the {int32, int64, nativeint} → int one. For instance, I could have been refactoring code from int32 to int and just missed a l at some stage. In this case, the hint would be useful.

[gasche]

@Octachron: yes, but think about fun n -> pred n = 0l. With the symmetry, you would get an advice to downgrade 0l into 0, while it's likely that you meant Int32.pred instead.

[Julow]

@Octachron: yes, but think about fun n -> pred n = 0l. With the symmetry, you would get an advice to downgrade 0l into 0, while it's likely that you meant Int32.pred instead.

I had the simpler 2l + 2l in mind.

[Octachron]

In other words, we are expecting the uncommon literal to be more likely to carry genuine intent compared to the context in this case. This sounds like a reasonable heuristic. It could be nice to document this design choice in a comment (along with the float → * case ).

[Octachron]

[explain f trace] → [explain trace f]

[gasche]

I had the simpler 2l + 2l in mind.

For the record, in that case @Julow, @Armael and myself discussed extending the "type forcing context" to remember "under a binary operator + at this location"; when we find a "precision downgrade" error (a float or int constant downgraded into int), we can look in the context if we find an operator, and say instead: "this + should be a +. (Int32.add, etc.)". We also suggested doing this in a later PR if there is interest, not this one -- I think the current feature support (just literals in patterns or expressions) is a good, well-defined scope.

[gasche]

The current state is fine. Please fix the small issue noticed by @Octachron ( [explain f trace] → [explain trace f]) and add a Changes entry, and this should be good to merge.

[gasche]

The current state is fine. Please fix the small issue noticed by @Octachron ( [explain f trace] → [explain trace f]) and add a Changes entry, and this should be good to merge.

[Julow]

Done.

[Julow]

I've rewritten the history.

[gasche]

@Julow: check-typo reports the following errors (see the Travis logs), you need to fix them before this can be merged:

./typing/ctype.mli:76.81: [long-line] line is over 80 columns
./typing/typecore.ml:60.81: [long-line] line is over 80 columns
./typing/typecore.ml:2289.81: [long-line] line is over 80 columns
./typing/typecore.ml:4785.81: [long-line] line is over 80 columns
./typing/typecore.ml:4877.81: [long-line] line is over 80 columns
./typing/typecore.mli:122.81: [long-line] line is over 80 columns
./typing/typecore.mli:127.81: [long-line] line is over 80 columns

[Julow]

It's fixed.