Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Kotlin: a memberless stub the Java side makes for a missing kotlin.* type is used by K2 (Function1.invoke unresolved)

Aperta
  • Qualcosa non va?
#76 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
28/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
java, kotlin
Ambito
compilers

Direzione di ricerca

Reproduce with a Java source set that lacks kotlin-stdlib and mentions kotlin.jvm.functions.Function1, plus Kotlin that calls through Function1; the Java side logs ClassSymbolScanner stub creation. Existing kotlin-package tests in maddi-modification-prepwork and maddi-modification-link put the stdlib on both sides and will not catch this. Done is K2 preferring its own library model over a Java-created stub, or the mixed inspector refusing that classpath mismatch.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

front-end:kotlin

Corrected 2026-09-28, the same day it was filed. The first version said that any Java mention of Function1 breaks Kotlin calls. It does not. It happens only when the Java source set does not have kotlin-stdlib on its class path. Then the Java front end creates a memberless stub for kotlin.jvm.functions.Function1, and K2 resolves against that stub. With the stdlib jar as a dependency of the Java source set, the same fixture parses cleanly. The original trigger came from a test harness that put the stdlib on K2's path only.

What remains is a robustness issue, not a correctness one on a buildable project: a stub made by one front end is used by the other.

package k
class X { fun apply(f: (String) -> Unit, s: String) { f(s) } }
Java source beside it, Java source set WITHOUT kotlin-stdlib Kotlin apply
class X { } {f.invoke(s);}
class X { void unrelated(kotlin.jvm.functions.Function1<String, String> g) { } } k2-unresolved-call:f at 2:55
class X { void unrelated(kotlin.jvm.functions.Function0<String> g) { } } fine

The Java side logs WARN ClassSymbolScanner -- Creating stub type for …, and a Java file that calls a stubbed type is dropped (Dropping compilation unit … (unresolved symbol)). Both are visible. What is not visible is that the Kotlin half then silently loses every call through the stubbed type.

When it matters. It matters when a configuration is incomplete, for example a hand-assembled source-set configuration (as coil needs) that forgets the stdlib on the Java side. The failure lands in Kotlin code that is correct, far from the missing class-path entry.

Options. K2 could prefer its own library model over a stub the Java side created (a stub is marked as such), or the mixed inspector could refuse to run when a Java source set lacks the stdlib while a Kotlin source set in the same project has it.

Not pinned by a test: the tiers in maddi-modification-prepwork and maddi-modification-link (package kotlin) put the stdlib on both sides, as a real build does.

Lingua principale
Java
Stelle
1
Fork
1
Merge medio
2h 51m
PR unite (30g)
3

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di CodeLaser/maddi

Tutte le issue di CodeLaser/maddi

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.