kotlin(OVERLOAD_RESOLUTION_AMBIGUITY) Java superclass ambiguity int/Integer

[rapus95]

class StackCount: Object2IntOpenCustomHashMap<IntArray>(IntArrays.HASH_STRATEGY) {

    fun change(stack: IntArray, count: Int): Int {
        val newAmount = getOrDefault(stack, 0) + count
        if (count == 0) return newAmount
        if (newAmount == 0) removeInt(stack)
        else put(stack, newAmount)
        return newAmount
    }

}

Screenshot

Class 'StackCount' must override public open fun get(key: IntArray!): Int? defined in it.unimi.dsi.fastutil.objects.Object2IntMap because it inherits multiple interface methods of itkotlin(MANY_INTERFACES_MEMBER_NOT_IMPLEMENTED)
Class 'StackCount' must override public open fun remove(key: IntArray!): Int? defined in it.unimi.dsi.fastutil.objects.Object2IntMap because it inherits multiple interface methods of itkotlin(MANY_INTERFACES_MEMBER_NOT_IMPLEMENTED)

Screenshot

Overload resolution ambiguity: 
public open fun getOrDefault(p0: Any!, p1: Int): Int defined in io.github.powercraft.item.StackCount
public open fun getOrDefault(p0: Any!, p1: Int!): Int! defined in io.github.powercraft.item.StackCount
public open fun getOrDefault(key: IntArray!, defaultValue: Int!): Int! defined in io.github.powercraft.item.StackCountkotlin(OVERLOAD_RESOLUTION_AMBIGUITY)

Screenshot

Regarding getOrDefault: Educated guess: Integer/int merging into the same type in Kotlin.

This image from IntelliJ shows that it also struggles to resolve when I try to override as one takes and returns Integer (->Int!) and the other takes and returns int (->Int). But IntelliJ doesn't have an issue with it in the first place, though. So it just eats it without redefining getOrDefault. Would love if this LSP would also handle it that way.

Regarding why I need to override get and remove, I have no clue. Both are deprecated.

But I could imagine it to be related to the same problem if multiple interfaces define slightly different methods (int vs Integer) and thus aren't fused automatically because the linter doesn't know which to assume. (again, IntelliJ doesn't even complain and the compiler compiles)

[rapus95]

And, as I totally have no clue of the code of the language server, vs code extensions and modding and building LSPs but still want to be helpful, I shamelessly copy an AI analysis into here. Since you know the code base, it'll take you probably at most 5–10 mins to find out if it was a shot in the dark. But in the best case, it saves you a lot of time by pointing straight to the right place:

Here's a refined analysis based on the fact that compilation succeeds:

1. Analysis vs. Compilation: The analysis KLS performs for providing IDE features (using TopDownAnalyzerFacadeForJVM and querying the BindingContext) might be less complete or happen at an earlier stage than the full compilation pipeline. The compiler might resolve the ambiguity in later stages not fully reflected in the BindingContext KLS primarily uses for these features.

2. BindingContext Snapshot: The BindingContext that KLS gets from the compiler analysis might indeed contain multiple potential candidates for the call at that specific point. The compiler itself might resolve this later, but the context snapshot KLS has access to still shows the ambiguity.

3. KLS Interpretation Logic (Most Likely Culprit):

   • Signature Help: As identified previously, the SignatureHelp.kt likely fetches all potentially matching function descriptors (candidates function) based on the name and scope. It then tries to determine the activeSignature. If the compiler's analysis (BindingContext) hasn't uniquely resolved the call at the point KLS queries it, KLS might present all potentially viable candidates, leading to the ambiguity message in the UI (like the hover screenshot showing multiple definitions). The activeSignature logic might just pick the first compatible one without reflecting the compiler's final choice.
   • Hover: Similarly, when hovering over the function call, Hovers.kt likely looks up the reference target in the BindingContext. If the context still holds multiple potential targets (because the specific analysis phase KLS ran didn't fully resolve it yet), KLS might display information based on all of them or show an ambiguity error.
   • Diagnostics: The "OVERLOAD_RESOLUTION_AMBIGUITY" diagnostic itself comes directly from the BindingContext. If KLS reports this diagnostic, it means the analysis phase it ran did find ambiguity. The fact that the full compilation succeeds suggests later compiler phases resolve it, but KLS might not be running or interpreting those phases for diagnostics/hover/signature help.

How to Fix in KLS (Revisited):

Since the compiler can resolve it eventually, the KLS needs to try harder to extract that final resolution information from the analysis it does perform.

1. Prioritize BindingContext.RESOLVED_CALL:

   • Where: Modify SignatureHelp.kt (specifically getSignatureTriplet or related functions like activeSignature/candidates) and Hovers.kt (hoverAt).
   • How: Before falling back to finding all candidates by name/scope, explicitly query the BindingContext for the specific ResolvedCall associated with the KtCallExpression the user is interacting with.
     • Use callExpression.getResolvedCall(bindingContext) which might return the winning call descriptor.
     • If this returns a unique, non-ambiguous resolved call, prioritize displaying only that signature/hover information.
     • If getResolvedCall itself indicates ambiguity or returns null/multiple results, then KLS might have to fall back to showing multiple candidates (or the diagnostic).
   • Code Example (Conceptual in SignatureHelp.kt):

     import org.jetbrains.kotlin.resolve.calls.util.getResolvedCall // Ensure this import
     
     // Inside getSignatureTriplet or a helper function:
     val call = file.parseAtPoint(cursor)?.findParent<KtCallExpression>() ?: return null
     val bindingContext = file.compile // Or the relevant context if re-analyzing
     
     val resolvedCall = call.getResolvedCall(bindingContext)
     val resolvedDescriptor = resolvedCall?.resultingDescriptor
     
     val candidates: List<CallableDescriptor> = if (resolvedDescriptor != null /* && resolvedCall.isReallySuccess() - check for ambiguity flags if available */) {
         // Successfully resolved to a single candidate by the compiler analysis KLS ran
         listOf(resolvedDescriptor)
     } else {
         // Fallback: Compiler analysis didn't resolve it uniquely, find all potentials
         candidates(call, file) // Existing function to find candidates by scope/name
     }
     
     if (candidates.isEmpty()) {
         return null
     }
     
     // Determine activeSignature based on the (potentially unique) candidates list
     val activeSignature = if (resolvedDescriptor != null && candidates.size == 1) 0 else activeSignature(call, candidates)
     val activeParameter = activeParameter(call, cursor)
     val signatures = candidates.map(::toSignature)
     
     return Triple(signatures, activeSignature, activeParameter)

2. Refine Signature Rendering: As mentioned before, making the displayed signatures clearer (e.g., Int vs Int!) using renderer options like platformTypesSpecificAnnotations = true is still valuable for the user, even if KLS presents multiple options. This helps the user see the subtle differences the compiler likely uses for resolution. Find DECL_RENDERER in RenderCompletionItem.kt and TYPE_RENDERER in Hovers.kt and adjust their options.

In summary: The most promising approach is to modify KLS to more directly query and prioritize the compiler's resolved call information (BindingContext.RESOLVED_CALL) for the specific call site, rather than just listing all potential candidates found in the scope. This better reflects the state the full compiler eventually reaches. Improving the visual presentation of signatures complements this.