[23] FoldingStructureComputationContext should respect the project compliance level for parsing

[stephan-herrmann]

Since https://bugs.eclipse.org/73400 folding tries to use a shared scanner (for performance reasons). But that shared scanner may be inappropriately configured.

To minimize interference with https://bugs.eclipse.org/73400 I created a separate field FoldingStructureComputationContext.fScannerForProject which is used if a difference between project compliance and workspace defaults is detected.

fixes #1634

[stephan-herrmann]

I admit I didn't fully explore the the interactions between fUpdatingCount and fSharedScanner, but this mechanism seems to be required only when re-using a scanner across contexts, which doesn't happen for the new fScannerForProject, so we should be on the safe side, possibly for the price of a little performance degradation.

[stephan-herrmann]

@iloveeclipse @jjohnstn @jarthana I could use some help getting a build without complaints on "new warnings" in files I haven't touched. I guess some merge from master must have stirred up some dust ... already needing to bump up versions in lots of plug-ins just in this PR was unexpected.

Also the need to update MarkdownCommentsTest should have been caught earlier (was caused by a change in JDT/Core from 5 Sept).

The clock is ticking for Java 23 ...

[jarthana]

@iloveeclipse @jjohnstn @jarthana I could use some help getting a build without complaints on "new warnings" in files I haven't touched. I guess some merge from master must have stirred up some dust ... already needing to bump up versions in lots of plug-ins just in this PR was unexpected.

Also the need to update MarkdownCommentsTest should have been caught earlier (was caused by a change in JDT/Core from 5 Sept).

I don't understand how changes from master (post release) can have an impact here. I see that we are using the Y build as eclipse-p2-repo.url in the POM file.

[stephan-herrmann]

New error:

[2024-09-11T17:03:44.962Z] [ERROR] Cannot resolve dependencies of project org.eclipse.jdt:org.eclipse.jdt.core.manipulation:eclipse-plugin:1.21.250-SNAPSHOT
[2024-09-11T17:03:44.962Z] [ERROR]  with context {osgi.os=linux, org.eclipse.update.install.features=true, osgi.arch=x86_64, org.eclipse.update.install.sources=true, osgi.ws=gtk, org.eclipse.jdt.buildtime=true}
[2024-09-11T17:03:44.962Z] [ERROR]   Software being installed: org.eclipse.jdt.core.manipulation 1.21.250.qualifier
[2024-09-11T17:03:44.962Z] [ERROR]   Missing requirement: org.eclipse.jdt.core.manipulation 1.21.250.qualifier requires 'osgi.bundle; org.eclipse.core.runtime [3.31.0,4.0.0)' but it could not be found: See log for details

The build pulls artifacts from

• http://download.eclipse.org/eclipse/updates/Y-builds
• which redirects to
  https://download.eclipse.org/eclipse/updates/4.34-Y-builds (why 4.34???)
• which claims 6 children but has only one:
  https://download.eclipse.org/eclipse/updates/4.34-Y-builds/categories
• which has no artifacts

[stephan-herrmann]

[...]

• which redirects to
  https://download.eclipse.org/eclipse/updates/4.34-Y-builds (why 4.34???)

I assume that this was a bug introduced in the context of releasing 4.33 and preparing for 4.34.

For now I'm trying to bypass the broken redirect by directly referring to https://download.eclipse.org/eclipse/updates/4.33-Y-builds

[stephan-herrmann]

I chose to ignore existing warnings, because

• the job claimed that new deprecation warnings occurred, where in reality only master had resolved some such warnings, while BETA_JAVA23 hasn't yet adopted those changes (and the beta branch should probably not merge master changes post 4.33 R, right).
• the better baseline for comparison, https://ci.eclipse.org/jdt/job/eclipse.jdt.ui-github/job/R4_33_maintenance/ hasn't yet produced any useful results