Feature request
Cellar currently provides no way to get diagnostic information when something goes wrong. Failures like "symbol not found" give no indication of what was attempted internally: which classpath entries were scanned, which tastyquery calls were made, which exceptions were swallowed.
Motivation
When diagnosing a resolution failure (e.g. SpanData$ not found despite existing in the JAR), the current workflow requires:
- Adding temporary
println statements to the source
- Or inspecting the JAR directly with external tools (
jar -xf, javap)
A --verbose (or -v) flag would print diagnostic steps to stderr, e.g.:
- Which JAR(s) are on the classpath
- Which top-level lookup strategies were tried (
findStaticClass, findStaticModuleClass, ...)
- Any exceptions caught by
tryOrNone
- Near-match candidates before filtering
Scope
- Add a
--verbose / -v flag to get, get-external, get-source, list, list-external, search, search-external
- When set, emit debug lines to stderr (not stdout, so pipeable output is unaffected)
- Thread the flag through
GetHandler, SymbolResolver, NearMatchFinder etc. — or wire it into the existing Tracer[IO] telemetry so span events double as debug output
Feature request
Cellar currently provides no way to get diagnostic information when something goes wrong. Failures like "symbol not found" give no indication of what was attempted internally: which classpath entries were scanned, which tastyquery calls were made, which exceptions were swallowed.
Motivation
When diagnosing a resolution failure (e.g.
SpanData$not found despite existing in the JAR), the current workflow requires:printlnstatements to the sourcejar -xf,javap)A
--verbose(or-v) flag would print diagnostic steps to stderr, e.g.:findStaticClass,findStaticModuleClass, ...)tryOrNoneScope
--verbose/-vflag toget,get-external,get-source,list,list-external,search,search-externalGetHandler,SymbolResolver,NearMatchFinderetc. — or wire it into the existingTracer[IO]telemetry so span events double as debug output