-
-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The behavior when resolving bindings is different from javac
#42
Comments
I have checked The Java® Language Specification Java SE 11 Edition and found that the Specification is not clear, they said:
They did not mentioned what to do if a qualified name is ambiguous. |
Okay, let's clarify a few bits here - just to make sure I'm understanding you correctly. What class is Mercury failing to remap? Beyond that you've provided a helpful analysis, thank you :) |
It's Paper's
The main problem is that |
No reply? |
I'm not sure there's anything we could do to resolve this, it appears to be an upstream bug. |
The inner class
Entry
is defined init.unimi.dsi.fastutil.longs.Long2ObjectMap
andjava.util.Map.Entry
, butit.unimi.dsi.fastutil.longs.Long2ObjectLinkedOpenHashMap
extendsit.unimi.dsi.fastutil.longs.Long2ObjectMap
.So someone wrote the following code.
This lead to crash because mercury can't resolve
Long2ObjectLinkedOpenHashMap.Entry
. However,javac
resolves this asit.unimi.dsi.fastutil.longs.Long2ObjectMap$Entry
.The text was updated successfully, but these errors were encountered: