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

[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
>>