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

[Baesken, Matthias]

Hello,  thanks for the review !

> I'd suggest to fix it in 13 as it is the test fix.

I'll push it then to 13 , fine with me !

Best regards, Matthias


> 
> Hi Matthias,
> 
> The fix is good.
> It worked before because both JVMTI_REFERENCE_ARRAY_ELEMENT
> and JVMTI_HEAP_REFERENCE_ARRAY_ELEMENT have the same value 3
> as Gary noticed.
> 
> I'd suggest to fix it in 13 as it is the test fix.
> I've added labels 'testbug' and 'noreg-self'.
> 
> Thanks,
> Serguei
> 
> On 6/28/19 12: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/u
> nit/FollowReferences/followref003/libfollowref003.cpp:33:
> >>
> /open_jdk/jdk_just_clone/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/u
> nit/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
> >>