Kill syntax error debugger

[privat]

Compilation errors happen, it's not a big deal.
Compilation clients are numerous, including highlighters and many source code related tools.

What is annoying is when an unrelated compilation error exception is fired (and not caught) by a random tool, and the human user is bothered by a buggy window asking them to fix something without context or anything.

Give me a real debugger!

So this PR remove all the useless SyntaxErrorDebugger code. Uncaught (or unexpected) SyntaxErrors will raise a classic debugger window, will all the context and information needed by users to fix (or report) the bug.

[Ducasse]

Yes :)

[privat]

Maybe move SyntaxErrorNotification to be a subclass of Error instead of Notification? And rename it as SyntaxErrorError or simply SyntaxError?

[MarcusDenker]

yes, after we get rid of the syntaxErrorDebugger, we can do that.

It is a Notification as we might get the syntaxErrorDebugger, fix the code, and continue.

[MarcusDenker]

Yes, removing the #syntaxErrorDebugger is nice.

What is a bit sad is that we want to release Pharo11 quite soon... I wonder if this is the right time to untangle that mess.

[MarcusDenker]

ZnHTTPSTest>>testGmailEncrypted times out on Mac and Linux

Did we not out a higher timeout for these at some point?

[svenvc]

There is some mix-up: there are two identical classes: ZnHttpsTest and ZnHttpsTests.

Only the last one has a default time limit of 10 seconds.

This must have happened in the last merge.

[MarcusDenker]

thanks, I added that to #12917

[MarcusDenker]

One thing that now does not work anymore is loading code with syntax errors.

e.g. imagine a .st or .cs file, maybe from some other dialect or very old (e.g. with _ as assignments).

The idea was that with the syntax error debugger, one could, one by one, fix the error and load the code.

The removal now just opens a debugger, making it very hard to load the code.

One idea that I always wanted to do: load this kind of bad code with faulty mode. We could just enable
code gen for code with syntax errors for non-interactive compilations:

see:

• [Compiler][Meta] Steps to allow compiling of syntactically wrong code when loading code [Compiler][Meta] Steps to allow compiling of syntactically wrong code when loading code #11944

[MarcusDenker]

To experiment with faulty compilation, here for evaluate:

Go to OpalCompiler>>#evaluate and add the optionParseErrors line before compiling:

    ...
    self options:  #(+ optionParseErrors).
    doItMethod := self compile.
    ...

If you now run

Smalltalk compiler evaluate: '1+'

it opens the normal debugger, but on the wrong doit

What does not yet work

• edit-and-continue, the debugger does not allow it (but that can be fixed)
• not the best visualisation of the error position, but for this case I think it is good enough

[privat]

One thing that now does not work anymore is loading code with syntax errors.
e.g. imagine a .st or .cs file, maybe from some other dialect or very old (e.g. with _ as assignments).
The idea was that with the syntax error debugger, one could, one by one, fix the error and load the code.

I think this is a design issue. Error recovery when loading random source code if a neat feature, but maybe it should be done by the loader tool. Not as an intrinsic feature of the image.

Crippling the UI because some experimental code highlighter or another tool throws a syntax error make little sense. I had once a syntax error thrown at me after saving the image: because the AST cache was cleaned, and a background Calypso window was open with a method with faulty experimental code, so Calypso naturally wanted to get a source code to present, and for some reason the decompiler was called, and after the decompiler did its decompilation it went for some semantic analysis on it, that thrown a error. It was weird.

Moreover, the original design is just BAD: recovering errors ONE by ONE in the order decided by the loader seems insane, as the user is let without context nor understanding nor even a precisely defined state (what is already loaded?). For instance, a better loader could do a plan of the change, check that the plan and the data is consistent, try to improve the plan if not consistent (asking the user on the whole thing with all information within a consistent state), then apply the plan. Asking the loader to trust the image for 'syntax error recovery' remove the control on the tool.

Note that an alternative (aggressive) loader design could be to just install faulty code, then present to the user a list of all things to fix as a somewhat post-loading task (or let the user YOLO and execute the code anyway, no need to fix something you do not plan to use but was loaded anyway in the package).

[privat]

To experiment with faulty compilation, here for evaluate: [...]

I obviously did experiment a lot with faulty compilation, since it's basically the point of the whole "improve faulty compilation" series of PR. RBCodeSnippet have a testExecute whose main point was to deal with faulty methods and expressions. https://github.com/pharo-project/pharo/blob/Pharo11/src/OpalCompiler-Tests/RBCodeSnippetTest.extension.st#L76

However, I did not really try to use it and try to recover from errors in day-to-day tasks. Maybe I should just activate it globally :)

GitHub

pharo/RBCodeSnippetTest.extension.st at Pharo11 · pharo-project/pharo

Pharo is a dynamic reflective pure object-oriented language supporting live programming inspired by Smalltalk. - pharo/RBCodeSnippetTest.extension.st at Pharo11 · pharo-project/pharo

[privat]

What is a bit sad is that we want to release Pharo11 quite soon... I wonder if this is the right time to untangle that mess.

You guys should try yo communicate better about release dates and process. Maybe having some kind of feature freeze date so devs can plan things acordingly?

[MarcusDenker]

I was thinking about this a bit and I now think that yes, we should do it.

• loading broken .st and .cs files will be easily possible with making faulty parsing the default in non-interactive mode
• the only thing we have to do is to guard git commits, and that is not hard to do

[MarcusDenker]

Maybe better for the Pharo 12 branch (this way we can really clean up and break things for a while..)

[privat]

Let's merge all the things \o/

[jecisc]

Currently the P12 branch is not building but I'm hoping to fix that with: #13004