I20250305-0330 build is unstable

[iloveeclipse]

See https://download.eclipse.org/eclipse/downloads/drops4/I20250305-0330/

Comparator differences from current build
	/home/jenkins/agent/workspace/Builds/I-build-4.36/cje-production/siteDir/eclipse/downloads/drops4/I20250305-0330
compared to reference repo at 
	https://download.eclipse.org/eclipse/updates/4.36-I-builds/

1.  eclipse.pde/ui/org.eclipse.pde.core/.polyglot.META-INF
   no-classifier: different
      org/eclipse/pde/internal/core/target/IUBundleContainer$UnitDeclaration.class: different
    The main artifact has been replaced with the baseline version.
    The following attached artifacts have been replaced with the baseline version: [sources]

Most likely expected result of records implementation refactoring in compiler via eclipse-jdt/eclipse.jdt.core#3728

I will check that & touch affected bundle.

[iloveeclipse]

The last argument of the record constructor in question (IUBundleContainer$UnitDeclaration) was originally set first, now it is set last which is what I also would expect (natural order of arguments).

@srikanth-sankaran: if you want double check that, here is the link to all data: https://download.eclipse.org/eclipse/downloads/drops4/I20250305-0330/buildlogs/comparatorlogs/

Meanwhile I will touch the bundle in question, the change seem to be expected.

[srikanth-sankaran]

JLS 8.10.4.2 Compact Canonical Constructors

...

After the last statement, if any, in the body of the compact constructor has completed normally (§14.1), all component fields of the record class are implicitly initialized to the values of the corresponding formal parameters. The component fields are initialized in the order that the corresponding record components are declared in the record header.

(Emphasis mine)

So the behavior in baseline is wrong and is corrected by the fix made for eclipse-jdt/eclipse.jdt.core#3727 via PR eclipse-jdt/eclipse.jdt.core#3728

That said, this is a bonus fix! It was not intended - The idea behind eclipse-jdt/eclipse.jdt.core#3727 was code simplification. Rather than a very round about way of implementing this wording of spec, we now implement a direct and simple way.

I will shortly inspect the code prior and now - I suspect there is some collection insertion order that was at play earlier.

[srikanth-sankaran]

I can confirm that the now deleted method org.eclipse.jdt.internal.compiler.ast.CompactConstructorDeclaration.checkAndGenerateFieldAssignment(FlowContext, FlowInfo, FieldBinding[]) receives fields in the wrong order.

So I don't see a real problem with the comparator differences. We can go ahead and update the baseline with the new class file.

[srikanth-sankaran]

Test runs have finished in two configurations so far and don't indicate any problems with the records refactoring work

[laeubi]

It seems we are missing a compiler deployment as now all PDE verification builds complain about baseline difference!

[iloveeclipse]

It seems we are missing a compiler deployment as now all PDE verification builds complain about baseline difference!

https://ci.eclipse.org/jdt/job/copyAndDeployJDTCompiler/184 triggered.
AFAIK this should be enough?
Or it should be updated in the SDK parent pom?

[akurtakov]

This job was not run since November as things have been automated by @HannesWell . Unfortunately, this seems to have failed with the switch to new stream or maybe it will work once all items from #2849 are completed.