Community
Participate
Working Groups
Test QuickFixTest14.testGetNeedHigherComplianceProposalsAndEnablePreviewsProposal currently fails, saying: java.lang.AssertionError: Wrong number of problems, is: 2, expected: 1 Pb(204) Syntax error on token "record", @ expected[21 ,26] Pb(240) Syntax error, insert "enum Identifier" to complete EnumHeader[33 ,33] I assume this to be caused by the intermediate fix for bug 562057. Gerrit doesn't yet show the failure, but perhaps it doesn't yet see a version of jdt.core with that fix?
Now gerrit shows the error, and yes, bug 562057 change is directly related. Also test fails on all builds from I20200413-1800 on. https://download.eclipse.org/eclipse/downloads/drops4/I20200413-1800/testresults/html/org.eclipse.jdt.ui.tests_ep416I-unit-cen64-gtk3-java8_linux.gtk.x86_64_8.0.html https://ci.eclipse.org/jdt/job/eclipse.jdt.ui-Gerrit/4965/testReport/org.eclipse.jdt.ui.tests.quickfix/QuickFixTest14/testGetNeedHigherComplianceProposalsAndEnablePreviewsProposal/ @Stephan: is this a test or code problem?
(In reply to Andrey Loskutov from comment #1) > @Stephan: is this a test or code problem? I believe JDT should do better in detecting that the illegal 'record' *could become* legal by applying the quick fix. Not sure, how much JDT/Core can do to help (while strictly avoiding to consider 'record' as a keyword below 14), or if JDT/UI must inspect the syntax error or source code to detect this situation.
(In reply to Stephan Herrmann from comment #2) > (In reply to Andrey Loskutov from comment #1) > > @Stephan: is this a test or code problem? > > I believe JDT should do better in detecting that the illegal 'record' *could > become* legal by applying the quick fix. Not sure, how much JDT/Core can do > to help (while strictly avoiding to consider 'record' as a keyword below > 14), or if JDT/UI must inspect the syntax error or source code to detect > this situation. So I read it that we would like to have some improvements in JDT core, but as long as they aren't implemented, test can be updated to not block Gerrits?
(In reply to Andrey Loskutov from comment #3) > > So I read it that we would like to have some improvements in JDT core, but > as long as they aren't implemented, test can be updated to not block Gerrits? OK, tried to manually reproduce this in the IDE - no chance to fix the test, without proper JDT core support the test is meaningless. I would "@Ignore" this test for now, otherwise we will block Gerrits. The code reports following problems for this source (& project setting set to use Java 13 compliance level): package test; public record Rec1() { } Description Resource Path Location Type Syntax error, insert "enum Identifier" to complete EnumHeader Rec1.java /Java14/src/test line 3 Java Problem Syntax error on token "record", @ expected Rec1.java /Java14/src/test line 3 Java Problem /Java14/src/test line 3 Java Problem Syntax error on token "record", @ expected Rec1.java /Java14/src/test line 3 Java Problem
New Gerrit change created: https://git.eclipse.org/r/160989
(In reply to Andrey Loskutov from comment #3) > (In reply to Stephan Herrmann from comment #2) > > (In reply to Andrey Loskutov from comment #1) > > > @Stephan: is this a test or code problem? > > > > I believe JDT should do better in detecting that the illegal 'record' *could > > become* legal by applying the quick fix. Not sure, how much JDT/Core can do > > to help (while strictly avoiding to consider 'record' as a keyword below > > 14), or if JDT/UI must inspect the syntax error or source code to detect > > this situation. > > So I read it that we would like to have some improvements in JDT core, I said "Not sure, how much JDT/Core can do to help" > but > as long as they aren't implemented, test can be updated to not block Gerrits? agreed
Gerrit change https://git.eclipse.org/r/160989 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=f63eedef918b66abbb80a3494ecd2dc50e6aa1e5
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.