Add compiler warnings

[ghallak]

Currently added warnings:

• shadowing
• negative spends
• division by zero
• unused functions
• unused includes
• unused stateful annotations
• unused variables
• unused parameters
• unused user-defined type
• dead return value
• non-exhaustive patterns (this will be tricky and should better be done in a separate PR)

Currently supported options:

• Turn options off/on separately.
• Warnings packages (Wall). pedantic package can easily be added later.
• Turn warnings into type errors.

Things that still need to be done:

• Properly report the warnings on compilation. (Currently they are just stored but not reported)

Testing:

• Tests for all added warnings
• Test for turning warnings into type errors

[ghallak]

@hanssv @radrow I'm looking for a way to properly report the warnings. Right now, the warnings are all stored in an ets_table called warnings in the aeso_ast_infer_types.erl file.

Do you think I should keep forwarding the warnings as strings upwards until they get to the aeso_compiler:from_string function and then I can return them along with the compilation result? or is there another way to do that?

[radrow]

I think that warnings should be returned as renderable structures as a result of the compilation/infer function

[hanssv]

Yes, keeping them in some warning structure (similar to the errors) and passing them upwards sounds like the best alternative. Then we can present them, or return them (or ignore them) according to options I guess.

[ghallak]

For negative spends and division by zero, the warning will only show when using a literal.

function f() =
  let x = 1 / 0  // this is a warning
  
  let zero = 0
  let y = 1 / zero  // no warning will show here

  let z = 1 / (1 - 1)  // no warning will show here

I think it won't be very difficult to add warning for the second case 1 / zero since this will only need to lookup the value of the variables zero, but the third case will requires evaluating the expression 1 - 1, which will make things more complicated and I'm not sure if I should try to add that.

[dincho]

but the third case will requires evaluating the expression 1 - 1, which will make things more complicated and I'm not sure if I should try to add that.

I guess if the compiler have a optimization phase to evaluate that and you run the warning check in a step/phase after it it would be covered by case 1

[radrow]

there could be a second pass of warning check after additional constant propagation

[hanssv]

👍 Looks good!

[radrow]

Would be nice to reflect it in the cli and http interface too

[radrow]

@nikita-fuchs would be great to see it working in aestudio :)

[nikita-fuchs]

@nikita-fuchs would be great to see it working in aestudio :)

dayumn, thanks for bringing this up.