Diagnostics

[drslump]

Just for initial review, not ready for merge yet.

These changes follow my previous proposal.

While the current system to handle errors in the compiler is pretty good I think we could benefit from adopting the one used by clang. The basic idea is to keep all the diagnostics under an unified interface, delaying their resolution until the moment we want to notify them to the consumer, be it the command line compiler or an IDE addon.

I've tried to keep the previous API (Context.Errors and Context.Warnings) working, as well as flagging as obsolete the modified parameter and command line options. This should ensure that other software building upon the Boo compiler infrastructure keeps working without modifications. This approach of allowing both kinds of error reporting to co-exists should make it possible to include this soon in the master branch and keep iterating to improve more and more errors over time.

Note that now errors, warnings and notes are all modelled as a diagnostic. They all share the same code namespace. I'm numbering errors from 1-1000, warnings from 1001-2000 and notes from 2001-3000. The idea is that when extending the compiler, extenders can take an unused range for their custom diagnostics. Besides that, they are not visible (unless verbosity is enabled), humans don't usually remember well so many different numbers 🐘

I will need some feedback about the overall direction of the change, no sense in pushing this forward if it's not going to be included at the end. Also some guidance on where to define the diagnostics, separating the message format, from the factory and the application point has its merits but seems a bit tedious IMHO. I would like to try defining them in place with some small helpers for code reuse.

Here is an example of the new reporting (with colors is really much better):

tests/testcases/errors/BCE0051-1.boo(4,11): error: operator '^' cannot be used between <double> and <double>
  print 3.0 ^ 1.1
        ~~~ ^ ~~~

This one shows a "fix-it" hint (which could be automated when integrated in an editor addin):

tests/testcases/warnings/BCW0007-1.boo(6,5): warning: assignment inside a conditional
  if a=b:
       ^
       =

And this is how it applies to errors not yet ported:

tests/testcases/errors/BCE0035-1.boo(9,9): error: 'A.Foo()' conflicts with inherited member 'Base.Foo()'.
   def Foo() as object:
       ^

[bamboo]

I think this is a very good idea. I'll be reviewing the code soon.