feat(kotlin): extract annotations into decorators on functions and classes - #1596

Follows #1596, which added `decorators`. The same `modifiers` node also
carries visibility (public/private/internal/protected) and the class
kind (data/sealed/value/annotation), plus abstract/open/override and
suspend/inline -- none of which reached the graph.

Adds two properties on Function and Class, and completes the two columns
#1596 deferred on Interface and Object:

  Function/Class      visibility STRING, modifiers STRING[]
  Interface/Object    visibility STRING, modifiers STRING[], decorators STRING[]

Each in all three required places -- node-table declaration, SCHEMA_MAP
allow-list, and simple_migrations so pre-existing databases get them via
ALTER TABLE. Without the last, CREATE NODE TABLE throws "already exists"
on an existing database and is swallowed, so the columns never arrive.

Two grammar details worth knowing:

`enum` is not a modifier. `enum class C` produces no `modifiers` node at
all -- the keyword is a direct child of class_declaration, exactly like
`interface`. It is derived with the pattern _parse_classes already uses
for interface detection, so `modifiers` is the single place to ask what
kind of class this is.

visibility defaults to the string "public" rather than null, matching
Kotlin's own default, so consumers need no null handling.

Since #1596 gated `decorators` behind `category == "classes"` only
because Interface/Object had no column, that gate is removed here.

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Shashank Shekhar Singh <Shashankshekharsingh1205@gmail.com>

…codebases (#1622)

* feat(kotlin): extract visibility, modifiers and enum kind

Follows #1596, which added `decorators`. The same `modifiers` node also
carries visibility (public/private/internal/protected) and the class
kind (data/sealed/value/annotation), plus abstract/open/override and
suspend/inline -- none of which reached the graph.

Adds two properties on Function and Class, and completes the two columns
#1596 deferred on Interface and Object:

  Function/Class      visibility STRING, modifiers STRING[]
  Interface/Object    visibility STRING, modifiers STRING[], decorators STRING[]

Each in all three required places -- node-table declaration, SCHEMA_MAP
allow-list, and simple_migrations so pre-existing databases get them via
ALTER TABLE. Without the last, CREATE NODE TABLE throws "already exists"
on an existing database and is swallowed, so the columns never arrive.

Two grammar details worth knowing:

`enum` is not a modifier. `enum class C` produces no `modifiers` node at
all -- the keyword is a direct child of class_declaration, exactly like
`interface`. It is derived with the pattern _parse_classes already uses
for interface detection, so `modifiers` is the single place to ask what
kind of class this is.

visibility defaults to the string "public" rather than null, matching
Kotlin's own default, so consumers need no null handling.

Since #1596 gated `decorators` behind `category == "classes"` only
because Interface/Object had no column, that gate is removed here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* feat(dead-code): make find_dead_code usable on Android codebases

Almost nothing in an Android app is called by another Kotlin function:
the framework invokes lifecycle methods, the manifest declares
components, Hilt supplies dependencies, the Compose runtime calls
composables, annotation processors generate Room implementations, test
runners call @test, and `override fun` is reached through its supertype.
So the tool reports thousands of false positives.

Three changes:

- `override` functions are treated as live, using the `modifiers`
  property added in the parent commit. Guarded with IS NOT NULL, because
  'override' IN NULL is NULL rather than false in Cypher -- unguarded it
  would silently drop every function lacking the property from results.
- Android/JVM lifecycle names (onCreate, onBind, doWork, ...) are treated
  as entry points, scoped to func.lang IN ['kotlin','java'] so other
  languages keep the original global list untouched.
- ANDROID_DECORATOR_PRESET: a documented tuple of annotations meaning
  "something other than project code calls this" -- Compose, test
  runners, Hilt, Room, and @TypeConverter.

Measured on a real 2,861-file Android codebase: 7,141 findings without
the preset, 1,055 with it -- an 85% reduction, dominated by @test methods
and Hilt providers.

Two honest limits, both documented:

The override exemption is inert for Java, because only kotlin.py emits
`modifiers`; the lifecycle-name half does work for Java. And four preset
entries (Dao, HiltViewModel, AndroidEntryPoint, Serializable) annotate
classes rather than functions, so they cannot match a query that does
MATCH (func:Function) -- kept, with a comment, because the data exists
and it is the query's scope that makes them inert.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Shashank Shekhar Singh <Shashankshekharsingh1205@gmail.com>

* feat(kotlin): extract visibility, modifiers and enum kind

Follows #1596, which added `decorators`. The same `modifiers` node also
carries visibility (public/private/internal/protected) and the class
kind (data/sealed/value/annotation), plus abstract/open/override and
suspend/inline -- none of which reached the graph.

Adds two properties on Function and Class, and completes the two columns
#1596 deferred on Interface and Object:

  Function/Class      visibility STRING, modifiers STRING[]
  Interface/Object    visibility STRING, modifiers STRING[], decorators STRING[]

Each in all three required places -- node-table declaration, SCHEMA_MAP
allow-list, and simple_migrations so pre-existing databases get them via
ALTER TABLE. Without the last, CREATE NODE TABLE throws "already exists"
on an existing database and is swallowed, so the columns never arrive.

Two grammar details worth knowing:

`enum` is not a modifier. `enum class C` produces no `modifiers` node at
all -- the keyword is a direct child of class_declaration, exactly like
`interface`. It is derived with the pattern _parse_classes already uses
for interface detection, so `modifiers` is the single place to ask what
kind of class this is.

visibility defaults to the string "public" rather than null, matching
Kotlin's own default, so consumers need no null handling.

Since #1596 gated `decorators` behind `category == "classes"` only
because Interface/Object had no column, that gate is removed here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* feat(dead-code): make find_dead_code usable on Android codebases

Almost nothing in an Android app is called by another Kotlin function:
the framework invokes lifecycle methods, the manifest declares
components, Hilt supplies dependencies, the Compose runtime calls
composables, annotation processors generate Room implementations, test
runners call @test, and `override fun` is reached through its supertype.
So the tool reports thousands of false positives.

Three changes:

- `override` functions are treated as live, using the `modifiers`
  property added in the parent commit. Guarded with IS NOT NULL, because
  'override' IN NULL is NULL rather than false in Cypher -- unguarded it
  would silently drop every function lacking the property from results.
- Android/JVM lifecycle names (onCreate, onBind, doWork, ...) are treated
  as entry points, scoped to func.lang IN ['kotlin','java'] so other
  languages keep the original global list untouched.
- ANDROID_DECORATOR_PRESET: a documented tuple of annotations meaning
  "something other than project code calls this" -- Compose, test
  runners, Hilt, Room, and @TypeConverter.

Measured on a real 2,861-file Android codebase: 7,141 findings without
the preset, 1,055 with it -- an 85% reduction, dominated by @test methods
and Hilt providers.

Two honest limits, both documented:

The override exemption is inert for Java, because only kotlin.py emits
`modifiers`; the lifecycle-name half does work for Java. And four preset
entries (Dao, HiltViewModel, AndroidEntryPoint, Serializable) annotate
classes rather than functions, so they cannot match a query that does
MATCH (func:Function) -- kept, with a comment, because the data exists
and it is the query's scope that makes them inert.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* feat(hilt): resolve @BINDS and @provides into BINDS edges

In a Hilt codebase, `@Binds abstract fun bindRepo(impl: UserRepositoryImpl):
UserRepository` is the only link between an interface and its
implementation. Without it every call resolves to the interface, so
`analyze callers` on the impl returns nothing, the impl looks like dead
code, and impact analysis dead-ends at every DI boundary -- which in a
clean-architecture Android app is every layer boundary.

Adds a BINDS relationship and resolves both Hilt mechanisms into it:

- @BINDS: source is the declared return type, target the single
  parameter type. Skipped if the arity is not exactly one.
- @provides: source is the return type, target the type constructed in
  the body, read from the function's recorded calls.

BINDS is declared as a REL TABLE GROUP rather than reusing INJECTS,
which is a single-binding REL TABLE (FROM Class TO Class). Hilt binds an
Interface to a Class, so reusing it would mean converting an existing
table to a group -- a migration hazard on databases already built.

Honest limits, stated in full because this is text-level resolution with
no type checker:

- Ambiguity is skipped rather than guessed. A @provides body with more
  than one type-resolvable call emits no row: neither first-call nor
  last-call is correct in general, since sequential construction wants
  the last and nested construction puts the wanted call first. A missing
  edge is visibly missing; a wrong one silently misdirects the very
  queries this exists to answer.
- Qualifiers (@nAmed) are not distinguished, generics resolve on erased
  names, multibindings are not modelled, and @provides bodies that
  delegate to a factory resolve to the factory call rather than the
  produced type.
- Where two label pairs both match, priority order decides, because a
  row carries names and paths but no labels.

Measured on a real 2,861-file Android codebase: 77 of 77 @BINDS
declarations resolved. @provides yields less (46 of 210) and legitimately
so -- those bodies are dominated by Room DAO accessors and static
factories, which have no first-party implementation node to point at.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Shashank Shekhar Singh <Shashankshekharsingh1205@gmail.com>