Reporting diagnostics in non-strict mode

[radeusgd]

When adding a test in #8245, I wanted to check that even in non-strict mode, the errors for duplicate from conversion are reported to the user. Unfortunately, I was unable to do so - because in general - in non-strict mode - the errors seme to not be reported at all.

I propose to change the logic slightly, to report the diagnostics to the console, even in non strict mode.

Of course, the ideal solution is to ensure that the GUI can read the errors somehow from the IR / nodes, and we definitely want to get this implemented at some point. However, until that is implemented (which will require coordination between engine and GUI), we can very easily improve our debugging experience, by ensuring that the compiler errors (which in non-strict mode are supposed to be non-fatal) are still reported to the console / logs. Changing that is a matter of changing a few usages of config.isStrictErrors, but it should make it easier to debug when we can see the errors printed.

Edit: I see that the engine part of that 'ideal solution' may already be implemented, as the backend is indeed sending some diagnostics as messages, as seen in the tests https://github.com/enso-org/enso/blob/develop/engine/runtime-with-instruments/src/test/scala/org/enso/interpreter/test/instrument/RuntimeErrorsTest.scala#L679-L695
Still, until that is integrated with the GUI, it is not that easy to rely on that (having to decode the websocket messages). Plus having diagnostics in logs makes it easier to debug user-reported issues when they attach the logs.

Is there any reason to not enable that?

As rationale, let's inspect this test:

  @Test
  public void testBadImport() {
    String src = """
       import That.Does.Not.Exist
       
       main = 2+2
       """;
    Value res = evalModule(nonStrictCtx, src);
    System.out.println(res);
    String output = getStdOut();
    System.out.println("Stdout: |"+output+"|");
    assertEquals(4, res.asInt());
    assertEquals(output, "");
  }

It passes just fine, printing

4
Stdout: ||

We can see that when running this program in non-strict mode there is no way to tell that the import is wrong and it actually has been ignored.

Of course, as noted above, the proper solution will be to display this somehow graphically in the IDE. But before that is implemented, it seems helpful to at least print such diagnostics in the console - aiding with debugging any issues with the non-strict interactive workflows.

[radeusgd]

I've created a PR experimenting with enabling to print the diagnostics regardless of the 'strict'ness setting.

Let me know what you think.

• In strict mode, the behaviour is as previous.
• In non-strict mode, the diagnostics are now logged at WARNING level.

[JaroslavTulach]

There is a difference between various kinds of errors. Errors described here-in are user errors in the user code. The Enso engine/LS code should be ready for them and handle them. However mixing them with other infrastructure errors and warnings in console isn't appropriate in my opinion. It's like mixing apples and bananas.

[JaroslavTulach]

Should the user code, or errors in the user code, be helpful in analyzing failures, then we shall capture them. However I prefer to capture them as part of snaphotting as proposed by

• Simplify taking a snapshot/sampling with an IDE shortcut #6775

CCing @hubertp and @4e6.