5 jdt.ui and jdt.refactoring tests fail since I20240801-1800

[iloveeclipse]

Regression from eclipse-jdt/eclipse.jdt.core#2776

• https://download.eclipse.org/eclipse/downloads/drops4/I20240801-1800/testResults.php

• https://download.eclipse.org/eclipse/downloads/drops4/I20240801-1800/testresults/html/org.eclipse.jdt.ui.tests_ep433I-unit-cen64-gtk3-java17_linux.gtk.x86_64_17.html

• https://download.eclipse.org/eclipse/downloads/drops4/I20240801-1800/testresults/html/org.eclipse.jdt.ui.tests.refactoring_ep433I-unit-cen64-gtk3-java17_linux.gtk.x86_64_17.html

• AdvancedQuickAssistTest1d7.testReplaceReturnIfWithCondition4

• InlineConstantTests.test29

• InlineTempTests.test32

• InlineTempTests.test37

• InlineTempTests.test38

I assume test expectations should be adopted, I will look into that.

[iloveeclipse]

@jjohnstn. @stephan-herrmann : IMO current expectations of AdvancedQuickAssistTest1d7, InlineTempTests and InlineConstantTests are correct, so the change eclipse-jdt/eclipse.jdt.core#2776 caused a regression.
I don't know whether that should be fixed in UI or core, please check.

[stephan-herrmann]

@jjohnstn. @stephan-herrmann : IMO current expectations of AdvancedQuickAssistTest1d7, InlineTempTests and InlineConstantTests are correct, so the change eclipse-jdt/eclipse.jdt.core#2776 caused a regression. I don't know whether that should be fixed in UI or core, please check.

Regarding InlineTempTests please see eclipse-jdt/eclipse.jdt.core#2776 (comment)

I haven't analyzed why those tests succeeded before (at which compliance?), but @jjohnstn and myself concluded that more is needed in JDT/UI, because inspecting the code prior to the refactoring simply doesn't provide sufficient information at compliance 1.8+.

[iloveeclipse]

Compliance is 1.8.

[stephan-herrmann]

Compliance is 1.8.

I was asking about compliance before eclipse-jdt/eclipse.jdt.core#2551

[iloveeclipse]

Compliance is 1.8.

I was asking about compliance before eclipse-jdt/eclipse.jdt.core#2551

Why is this important? The test was green after eclipse-jdt/eclipse.jdt.core#2551 and broken after eclipse-jdt/eclipse.jdt.core#2776.

[stephan-herrmann]

Why is this important?

Refactoring used a mechanism from 1.7, which is not useful in 1.8. When it passed at 1.8 it was by accident.

[jjohnstn]

Hi @iloveeclipse The code in JDT UI needs to be altered. The code was using a flag that wasn't being set 1.8 +. This caused an error in one test that you disabled. @stephan-herrmann fixed the flag but the code in UI still isn't correct in that it isn't able to calculate whether the cast is really needed or not. I propose that the code leave out the cast and then when it tests for errors with the new code, go back and cast any occurrences where noted by the compilation failures. As mentioned, the simplest hack for the present is to not do the cast until the logic gets changed. I intend to try and do that next week. I'll post a PR shortly (disablement) until I have time next week (it is a long weekend here in Canada).