test/langtools/tools/javac/sym/ElementStructureTest fails: what does it mean?

[Raffaello Giulietti]

Hi Jan,

thanks for looking at the problem.

A way to be more resilient is to use hex notation for float/double 
literals, as they are not affected by my patch.

To avoid misunderstandings, the patch is not meant to be back-ported to 
JDK 7 or 8, both because it is associated with a CSR and because it 
makes use of feature that are not present in JDK 7 or 8, in particular 
Math.multiplyHigh().

Please let me know if you discover doubles that are represented 
differently, so I can add them to my tests.


Greetings
Raffaello



On 2021-04-12 18:22, Jan Lahoda wrote:
> Hi Raffaello,
> 
> 
> The test is printing the whole stored/recorded JDK 7 and 8 API, computes 
> a digest from it, and checkes if it matches the expected value. And, 
> there are some double constants in the API, (e.g. in java.lang.Double), 
> and these presumably may be printed in a different way after your patch. 
> I'll check manually if the results make sense, and we can then update 
> the hashes (we could also use a more resilient way to print doubles, 
> together with updating the hashes).
> 
> 
> Jan
> 
> 
> On 12. 04. 21 16:17, Raffaello Giulietti wrote:
>> Hello,
>>
>> (hope this is the right mailing list for such questions: otherwise 
>> please redirect me.)
>>
>> I recently posted a PR [1] on the core-libs-dev mailing list that 
>> fails to pass one of the automatic GitHub action tests on all 
>> supported platforms.
>>
>> The test that fails is
>> test/langtools/tools/javac/sym/ElementStructureTest.java
>>
>> The same test also fails on my local repo when I run
>> make test 
>> TEST="jtreg:test/langtools/tools/javac/sym/ElementStructureTest.java"
>>
>> I have no clue what in my changes in the PR can lead to the failure.
>>
>> Any suggestions?
>>
>>
>> Thanks
>> Raffaello
>>
>> ----
>>
>> [1] https://github.com/openjdk/jdk/pull/3402