RFR [XS] : 8226943: compile error in libfollowref003.cpp with XCode 10.2 on macosx

[Baesken, Matthias]

Hi Gary and David, yes it is value 3 in both cases, I noticed that in the jvmti XML .

Best regards, Matthias 

Von meinem iPhone gesendet

> Am 28.06.2019 um 21:17 schrieb "gary.adams at oracle.com" <gary.adams at oracle.com>:
> 
> I believe you will find in the generate jvmti.h header file
> that both enumerations had assigned value of 3.
> That could explain why a less type strict version of the
> compiler would not have complained.
> 
>> On 6/28/19 3:04 PM, David Holmes wrote:
>> Hi Matthias,
>> 
>> Dropped build-dev and added serviceability-dev as this is a servicability test.
>> 
>>> On 28/06/2019 7:43 am, Baesken, Matthias wrote:
>>> Hello please review this  small fix for a compile issue  on OSX .
>>> Today I  compiled   jdk/jdk   on a machine  with   XCode 10.2  . It worked pretty well .
>>> However this small issue showed up .
>>> 
>>> 
>>> In file included from /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/libfollowref003.cpp:33:
>>> /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp:813:14: error:
>>> comparison of two values with different enumeration types in switch statement ('jvmtiHeapReferenceKind' and 'jvmtiObjectReferenceKind') [-Werror,-Wenum-compare-switch]
>>> 
>>> 
>>> And here XCode 10 is correct , JVMTI_REFERENCE_ARRAY_ELEMENT   is from a different  enumeration type  and should be replaced  with the value  from the correct enumeration type   .
>>> 
>>> Bug / webrev :
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8226943
>>> 
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8226943.0/
>> 
>> The fix seems reasonable but the issue indicates a further problem with the test. If it expected JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT but was checking for JVMTI_REFERENCE_ARRAY_ELEMENT then we should have hit the default clause and failed the test. That suggests the test doesn't actually expect JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT in the first place.
>> 
>> Cheers,
>> David
>> 
>>> 
>>> Thanks, Matthias
>>> 
>