Alternative message reporting modes

[kLabz]

Adds alternative message reporting modes with -D message-reporting=[mode]

Reporting mode: "classic"

Current output, still default reporting mode

Reporting mode: "pretty"

Adds more contextual information to errors (sources) for example like that:

Additionally, -D no-color can be used if your terminal doesn't support ANSI escape codes:

[ERROR] Main.hx:8: characters 9-18

 8 |         C.f("hi");
   |         ^^^^^^^^^
   | Could not find a suitable overload, reasons follow

      | Overload resolution failed for () -> Void

       8 |         C.f("hi");
         |             ^^^^
         | Too many arguments

      | Overload resolution failed for (t : f.T) -> Void

       8 |         C.f("hi");
         |             ^^^^
         | Constraint check failure for f.T
         | String should be Int
         | For function argument 't'

(from actual test output for 6065)

Reporting mode: "indent"

New mode that uses nesting level data in messages to provide more context to tools exploiting compiler output (vscode tasks, for example). This format is experimental and subject to many changes until the whole feature is done on both sides.

Example:

$ haxe compile-fail.hxml -D message-reporting=indent
Main.hx:8: characters 3-12 : Could not find a suitable overload, reasons follow
  Main.hx:8: characters 3-12 : Overload resolution failed for () -> Void
    Main.hx:8: characters 7-11 : Too many arguments
  Main.hx:8: characters 3-12 : Overload resolution failed for (t : f.T) -> Void
    Main.hx:8: characters 7-11 : Constraint check failure for f.T
      Main.hx:8: characters 7-11 : String should be Int
      Main.hx:8: characters 7-11 : For function argument 't'

Additional logging to file

Also adds -D messages-log-file=[path] (and -D messages-log-format=[format], default being "indent") to make compiler output to a file in addition to terminal output, so that for example you can get user-readable output in terminal and computer-readable output in the log file (to be consumed by tools).

Next steps after merge

• Update vshaxe to make use of new reporting modes
• Handle interp errors in pretty mode (displayed as "classic" for now)
• Merge successive identical (message + pos) messages, for example Called from here (x10)

Review

I guess Files changed 110 / +1,085 -317 won't exactly help getting review 😅

Main changes:

• server.ml holds the actual message reporting modes code
• compiler errors have been modified with added (optional, defaults to 0 which is top level) depth
• compiler errors are now handled as string * pos at most places instead of string with separate pos. This was mostly necessary for stacks
• misc tests have been updated for rare changes and new ones have been added for new outputs; can check those to get an idea what this PR does

---

Grab nightlies to try it out: 58ee66d nightlies

[Aurel300]

I like this. Small nitpick: I think this feature is about pretty-printing errors, not about verbose errors. From the latter I would expect more error information, which is not the case here, it is the same information presented in a more readable way. So maybe the define could be pretty-errors or similar?

[kLabz]

Good point. Maybe it could become both to some extent but I'm not sure it's something we want there nor if it would be practical..

[Aurel300]

By the way, this might be out of scope here, but: I find the "hint" which says for function argument x really useless most of the time, because it does not give any indication which function has the argument x. This is made worse by the fact that argument names in the standard library are generally not descriptive. If this kind of hint (in "pretty" mode) could point to the declaration of the function or closure variable, that would be great!

[kLabz]

Yeah, trying to do something about it; should be possible if I find a nice way to handle Stack errors. There are similar cases where I want to make some improvements too, like https://github.com/HaxeFoundation/haxe/blob/development/src/typing/typeloadCheck.ml#L503 which is just repeating the function name it's pointing to (redundant with pretty errors)

[kLabz]

@Simn if you happen to be bored, I think this PR is ready for review

[Simn]

I like the depth approach, that seems quite pragmatic and easy to handle.

I kinda wish we didn't do this stupid tuple stuff so much because it's so awkward to extend. It feels like half of the changes are additional ,_ which is quite silly. I do understand if you don't want to address this as part of the PR though.

The diff here would also benefit quite a bit from a separate "whitespace cleanup" PR, but it's fine if you can't be arsed to factor that out.