Super errors broke vscode tasks problem matchers

[jchavarri]

The project themes included in bsb contain some VSCode tasks with problem matchers. For example, in basic-reason theme:

https://github.com/BuckleScript/bucklescript/blob/3cf3133a4978df05e0b5fb351a1d2d18dce16c32/jscomp/bsb/templates/basic-reason/.vscode/tasks.json#L24-L39

These matchers used to work fine in the past, when bsb was showing OCaml-like errors like:

File "lib/Util.re", line 4, characters 25-26:
Error: This expression has type int but an expression was expected of type
         string

but they break with super error format. This format is nicer for console errors, but really hard to parse from another program through regexps (see ocaml-lang-server handling as an example).

Would there be a way to pass an extra flag to bsb (even if it's only in watch mode) that would skip super errors and output the errors in the old format?

Adding this flag would be really useful to simplify the logic and responsibilities that Reason / OCaml vscode extensions need to do right now.
Also, going back to the OCaml format would be a big step to come up with problem matchers that can be shared between BuckleScript and Dune (for native projects). While in Dune the users have much more control (just don't use refmterr) in BuckleScript that's not the case.

Note: There is a separate issue in vscode, where problem matchers can't parse error messages in multiple lines (see microsoft/vscode#9635). This is another problem that is unrelated to the fact that super errors broke all errors parsed by the problem matcher provided by bsb themes, multiline or not.

cc @chenglou

[bobzhang]

The current super_errors setup is very imperative. I think this is a valid feature request, I will add an environment variable support to avoid super_errors

[jchavarri]

Thanks @bobzhang ! I was going to propose to add the File "lib/Util.re", line 4, characters 25-26: format to super errors which might be easier, but saw you already added an env variable ⚡️

[chenglou]

I really don’t think we should add more env vars for these things, especially since we own the task matcher. Also, it’s pretty backward to disable super errors just because a regex didn’t pass.

[bobzhang]

In general, we need a way to turn super-error on and off, I planned to add a flag -bs-no-super-error, but it seems non-trivial to have it done.
BS_VSCODE is generally useful in the future to adapt more to vscode when it is set.
The problem matcher is hard to make it work with multiple line error message, in general, you need to have different modes for error message

[bobzhang]

The problem matcher is limited (it still can not handle multiple line properly). We recommend editor plugins dome some program API based on .compiler.log.
See this: https://forum.rescript-lang.org/t/reliable-error-diagnostics-for-any-editor/288/10