Big Kotlin Work List

[sschr15]

A bunch of things to get Kotlin to be (mostly) decompiling Kotlin and not a Kotlin-Java hybrid, split into a few main categories.

Technical Backend

• Publish Kotlin metadata to Kotlin-targeting code (partially in 4891bff)
• Kotlin exprent equivalents
• Other special Kotlin construct handling code

Non-method fixes

• Field declarations (Kotlin property decompilation #275)
• data class support (flag indicated via 8b8c86d)
• annotation class support (6ca6edb)
• Primary constructors (Class, method, and constructor declarations #307)
• Other constructors (Class, method, and constructor declarations #307)
• extends / implements clauses (8b8c86d)
• Anonymous classes
• Annotation arrays should use [] (6ca6edb)
• Other explicit arrays should use arrayOf or the equivalent primitive type
• All known-to-have-generic types must specify generics
• Higher level functions not based on SAM interfaces
• Top-level declarations (8e2283e)
• Type aliases
• Nullable types in generics (type creation via 0a4b157)

Method fixes

• Remove unnecessary semicolons (Delegate semicolons to plugins when possible #471)
• Remove new from constructor calls
• Destructuring declarations
• String interpolation
• Smart Casts
• Receiver types (should decompile as this or as this@...)
• SAM lambda decompilation
• Non-SAM lambda decompilation
• for loops and if conditions on ranges (Most backing work on this done in Handle Kotlin's statements and their frequent sugar #472)
  • repeat (Handle Kotlin's statements and their frequent sugar #472)
  • rangeTo (Handle Kotlin's statements and their frequent sugar #472)
  • until and later Kotlin rangeUntil (Handle Kotlin's statements and their frequent sugar #472, recognized but not decompiled to this)
  • downTo (Handle Kotlin's statements and their frequent sugar #472)
  • step
• Infix functions
• Operator functions
• tailrec functions
• when statements (Handle Kotlin's statements and their frequent sugar #472, partial)
• Inline uninlining

[Kroppeb]

lateinit var

[LlamaLad7]

Inline function call decompilation would be cool. It should be possible from the source map.

[sschr15]

Inline function call decompilation would be cool. It should be possible from the source map.

SMAP is not capable enough to indicate individual names of inlined functions, just the files and locations within those files for source information. Kotlin local variables do tend to include local variable entries that could be helpful, but I need to look more into it