Skip to content

Fix the InvocationExpression.findCallable() implementation #464

Description

@ggleyzer

This issue was reported by Dima on Discord:

In a presence of multiple methods with exact matching of argument types, but different return types, the compiler chooses a "random" one to call.

Claude's analysis of "collectMatchingMethods()" is quite precise:

Ecstasy deliberately allows return-type overloading (return type is part of the full method signature) — so the class declaration itself is legal by design, unlike Java. But the selection behavior when no return type context is available is broken.

The fExact short-circuit was designed for the case where argument types exactly match a method's parameter types — a meaningful tiebreaker. With zero parameters, fExact is vacuously true
for every candidate simultaneously. The early return fires on whichever method the HashSet happens to serve up first, silently bypassing chooseBest's ambiguity detection entirely.

The correct behavior when there's no return type context to disambiguate between return-type overloads is to report SIGNATURE_AMBIGUOUS — forcing the caller to provide context (e.g., Int
x := b.test()). Instead, the compiler picks one silently based on hash order, which is both non-deterministic across JVM runs (hash randomization) and semantically wrong.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions