-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Invalid code not rejected by compiler (Duplicate of #367) #859
Comments
First The snippet without errors (that can be compiled) is:
Reduced snippet that breaks the parser:
Its not exactly the nested lambda that breaks the parser, but the nested lambda followed by This commit seems oddly matching the problem here: 6a1671a It adds this code:
The
After Removing the https://bugs.eclipse.org/bugs/show_bug.cgi?id=383046 was merged with the beta branch for Java 8 support (oddly into 3.8), which should explain why I didn't find a working As written in the comment, recovery takes place after the
If the recovered statement itself has errors, those errors are reported (e.g. So the |
I don't really understand the comment above in the fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=383046 ...
For this snippet:
Here the Also is text like this expected in an error message from a compiler? And is the error above much different to the one from the comment? See also the starting comment in
Opened #903. |
WIP, DONT MERGE Test for: eclipse-jdt#859 Signed-off-by: Simeon Andreev <simeon.danailov.andreev@gmail.com>
@srikanth-sankaran , first and foremost, great to see you are working again on JDT! If you have time in future, it would be great if you can take a look here, as well as #125, #367 and #904. I believe those issues are all closely related, if not one and the same bug. |
Yes, @trancexpress, I will take a look at these in due course. Thanks for the pointers |
@trancexpress, some explanations: (1) "we should never ever report the diagnostic, "Syntax error, insert ElidedSemicolonAndRightBrace to complete LambdaBody"" There are two reasons for this comment: (i) ElidedSemicolonAndRightBrace is an internal synthetic token. A programmer can do NOTHING on his/her accord to insert these tokens at the indicated place. So including such tokens in messages addressed to the users is wasteful, confusing, not actionable and needlessly exposing internal implementation details. (2) The above is also entirely true of the synthetic tokens handled by ProblemReporter.replaceIfSynthetic(String) but ElidedSemicolonAndRightBrace is special for one crucial difference: ElidedSemicolonAndRightBrace is synthesized and inserted right after a non-block lambda, on the fly by the Parser in normal parsing itself - OIOW, normal parsing itself does some amount of "repair" of the input stream to reduce a lambda expression. The other synthetic tokens are inserted into the stream by the scanner but ElidedSemicolonAndRightBrace is not returned by the scanner (See point 4 in https://bugs.eclipse.org/bugs/show_bug.cgi?id=380194#c15) When the DiagnoseParser is coming up with a recommendation to " insert ElidedSemicolonAndRightBrace to complete LambdaBody" - it is likely mimicking the Parser's own repair of the input stream done at org.eclipse.jdt.internal.compiler.parser.Parser.consumeElidedLeftBraceAndReturn() and If that is all there is to it (the assumption when I short circuited that error emission with a break), things would be fine. I think what I overlooked is that DiagnoseParser has its own complicated repair mechanism which can sometimes skip ahead past several tokens until it reaches a certain point of predictability. This skipping past subsequent tokens results in subsequent errors to be not reported and with my code short circuiting the initial error ( insert ElidedSemicolonAndRightBrace to ...) no error shows up leading to the impression that the code is compiled fine. I am testing a candidate fix that would (a) not expose internal non-actionable synthetic tokens but (b) will still surface a generic/bland error message that is "quite correct" First order business being to reject invalid programs correctly, quality of diagnostics being secondary to correctness. I'll wait until #1045 to make any improvements to quality of diagnostics. |
[...]
That ElidedSemicolonAndRightBrace shows up in diagnostics emitted by a different path is an oversight/bug. Whether it is SUBSTITUTION_CODE path or SCOPE_CODE path, saying ElidedSemicolonAndRightBrace is expected or to be inserted etc in a message is not actionable by the user and will be confusing. |
So in summary, injection of ElidedSemicolonAndRightBrace to reduce a lambda expression is normal part of business. So it makes sense to not show that in an error message. What was a complete surprise (and hence resulted in this cluster of bugs) was that after thus repairing the input stream, the DiagnoseParser would have been expected to report "some" additional error as it chewed the input stream further. That it skipped further input was something (I and my) the code was not prepared for. |
Alright, thank you for the explanations. |
Here is an experiment that sheds light on how insertion of ElidedSemicolonAndRightBrace is "normal" part of business of parsing lambda expressions, be it by Parser or DiagnoseParser. (1) Comment out the code:
(2) Now compiling this code:
results in the perfectly (syntactically) valid lambda being rejected:
(It is worth investigating why the DiagnoseParser skips past several tokens resulting in no further error at all in the test cases for this cluster of duplicate defects) |
Closes eclipse-jdt#859 Signed-off-by: David Thompson <davthomp@redhat.com>
eg. try completion at the `|` for the following cases: ```java public Foo { | } ``` ```java public Foo { toStr| } ``` Closes eclipse-jdt#859 Signed-off-by: David Thompson <davthomp@redhat.com>
eg. try completion at the `|` for the following cases: ```java public Foo { | } ``` ```java public Foo { toStr| } ``` Closes eclipse-jdt#859 Signed-off-by: David Thompson <davthomp@redhat.com>
eg. try completion at the `|` for the following cases: ```java public Foo { | } ``` ```java public Foo { toStr| } ``` Closes eclipse-jdt#859 Signed-off-by: David Thompson <davthomp@redhat.com>
eg. try completion at the `|` for the following cases: ```java public Foo { | } ``` ```java public Foo { toStr| } ``` Closes eclipse-jdt#859 Signed-off-by: David Thompson <davthomp@redhat.com>
eg. try completion at the `|` for the following cases: ```java public Foo { | } ``` ```java public Foo { toStr| } ``` Closes eclipse-jdt#859 Signed-off-by: David Thompson <davthomp@redhat.com>
eg. try completion at the `|` for the following cases: ```java public Foo { | } ``` ```java public Foo { toStr| } ``` Closes eclipse-jdt#859 Signed-off-by: David Thompson <davthomp@redhat.com>
eg. try completion at the `|` for the following cases: ```java public Foo { | } ``` ```java public Foo { toStr| } ``` Closes eclipse-jdt#859 Signed-off-by: David Thompson <davthomp@redhat.com>
eg. try completion at the `|` for the following cases: ```java public Foo { | } ``` ```java public Foo { toStr| } ``` Closes eclipse-jdt#859 Signed-off-by: David Thompson <davthomp@redhat.com>
eg. try completion at the `|` for the following cases: ```java public Foo { | } ``` ```java public Foo { toStr| } ``` Closes eclipse-jdt#859 Signed-off-by: David Thompson <davthomp@redhat.com>
See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=481133
Snippet:
This code should not compile, but does with Eclipse. E.g.
javac
reports errors:The text was updated successfully, but these errors were encountered: