Parser bug on character constants

[fingolfin]

I was looking at our old private tracker (we really should go through all issues there, and migrate any sensible issues to this tracker).

One of them was by @markuspf (see http://tracker.gap-system.org/issues/470) and reported the following buggy behavior: Enter a single quote, then press return twice and you get this:

gap> '
Syntax error: Newline not allowed in character literal
'
^
gap>
Syntax error: Missing single quote in character constant

So it look as if GAP did never finish parsing that character constant, despite already showing a syntax error (that first syntax error was not present in Markus' original report, so it has been added since then).

Apparently Markus even managed to get it to crash.

[markuspf]

I thought we had fixed it back then. I will check this again, maybe we didn't fix it properly or merges between HPC-GAP and GAP re-broke it.

[markuspf]

A similar problem occurs here:

gap> s := "abc
Syntax error: String must not include <newline>
s := "abc
        ^
> 
> ";

[markuspf]

There are more instances of when we don't abandon the parse early when a syntax error occurs, like this here:

gap> f := function(abc);
> local x
Syntax error: end expected
local x

I will have a closer look at this this week.

[ChrisJefferson]

@markuspf : There are many, many places where we don't abandon parsing when a syntax error occurs, that is I think "standard behaviour".

If we wanted to fix that, we should introduce some kind of general method of cleaning that up -- some kind of "empty out the input stream" (that needs planning better before we start it)

[fingolfin]

This has been mostly resolved, except for that last instance @markuspf reported in December 2016.

@markuspf whatever happened to this?

[fingolfin]

I think the fact that parsing goes on here is in general meant as a feature: we try to keep parsing through files, even if they contain a syntax error; this is useful if e.g. you change the library, and your change has a typo; then you only break the method you modified, but not everything else in that file.

But for interactive input, perhaps we should abort parsing immediately when there is a syntax error... OTOH, if one copy&pastes a longer function into a terminal, it might end up being pretty confusing if it contains a syntax error...

[olexandr-konovalov]

@fingolfin said

I was looking at our old private tracker (we really should go through all issues there, and migrate any sensible issues to this tracker).

+10. To prevent flooding the tracker with mass issue migration, would be good if those who had created them would go through them themselves and either close or migrate them...

[fingolfin]

@alex-konovalov note that the comment you are quoting is from Dec 7, 2016 ;-)

[olexandr-konovalov]

@fingolfin figured that out 5 minutes ago ;-)

[fingolfin]

Personally, I consider this fixed, now that PR #2445 is merged. People may still dislike aspects of the current behaviour, but I am not aware of anything actively buggy or misleading. If somebody is, please open a new issue.