Fix SOE from ResourceKey#compareTo

[MrHell228]

No description provided.

[aromaa]

We should redirect it to the vanilla one so we don't accidentally return different results from different APIs.

[MrHell228]

What is someone implements Key? Should it use -o.compareTo((Key) this) or convert given Key to ResourceLocation?

[MrHell228]

Moreover, vanilla comparison doesn't look reachable from API, currently it will always use adventure comparator

[aromaa]

What is someone implements Key?

Thinking about this, I think we want to defer vanilla calls to adventure to be consistent.

Moreover, vanilla comparison doesn't look reachable from API

The ResourceLocation#compareTo is reachable when casted to Comparable. The Key#compareTo is only reachable when explicitly called by user code.

[MrHell228]

Thinking about this, I think we want to defer vanilla calls to adventure to be consistent.

With @Overwrite?

[aromaa]

That should be fine, yes.

[Yeregorix]

Suggested change

	public int compareTo(final ResourceLocation location) {
	return ((Key) this).compareTo((Key) (Object) location);
	public int compareTo(final Object obj) {
	return ((Key) this).compareTo((Key) obj);

After looking at the implementations of ResourceLocation#compareTo(ResourceLocation) and Key#compareTo(Key), they seem completely equivalent to me. I don't think we need to overwrite one or the other. What I'm more worried about is the synthetic method ResourceLocation#compareTo(Object) which is casting and delegating to ResourceLocation#compareTo(ResourceLocation). I think this one should be overwritten to delegate to Key#compareTo(Key) instead.

[MrHell228]

Makes sense. Didn't know it works via synthetic method. I guess now ResourceLocation#compareTo(ResourceLocation) should not be reachable from the API and no CCE should be thrown if anyone implements Key on their own (or if KeyMixin is removed which would result in Adventure KeyImpl being used).

[aromaa]

Thank you!