finer control over error vs. warnings
commitcb14de58097d97e467dbb97079bebb6ac70038a1
authorLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
Wed, 5 Apr 2017 15:38:08 +0000 (5 17:38 +0200)
committerLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
Sat, 10 Jun 2017 14:10:44 +0000 (10 16:10 +0200)
tree79ccfef0c6107ec0d715f44b382f53e4f639a4b4
parentac0636468531f36d47708e121a5c94b6b9d142f7
finer control over error vs. warnings

Currently, once an error is issued, warnings are no more
issued, only others errors are.

It make sense as once an error is encountered things can
be left in an incoherent state and could cause lots of
useless warnings because of this incoherence.
However, it's also quite annoying as even unrelated warnings
are so silenced and potential bugs stay thus hidden.

Fix this by:
- use a specific flag for this: 'has_error'
- make the distinction between the current phase and some previous
  phases (but for now we only care about parsing vs evaluation)
- if an error has been issued in a previous phase (at parsing)
  warnings are suppressed for the current phase and all future
  phases
- if an error is issued in the current phase (evaluation) the
  flag is reset after each functions/symbols

For example, with this patch, a typing error in function fa()
will not suppress warnings for function fb(), while a parsing
error will still inhibit all further warnings.

Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
evaluate.c
lib.c
lib.h