Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

Do we have the ability to configure filters via pants.ini now?

And does warnings-as-fatal get checked by zinc (and therefore respect the filters) or by scalac?

```    # This is intentionally in the default args section: never warn for generated files.
    '-file-filter', '/\.pants\.d/gen/',
    # Ditto: Suppress the warning for annotations with no processor.
    '-msg-filter', '^(warning: )?No processor claimed any of these annotations: .*'```

Nice, though for full effect we really want to fail the compile if the post-filtered list of warnings is non-empty

but adding a filter to explode on a particular message would be straightforwardish

...but, doing it in scalac would be less hacky prolly

Unfortunately upgrading scalac isn't quite the same scope as a pants release

<@U053HNE90>: sidenote: enabling GC logs for ng/zinc seems to "just work"... they all go to `.pants.d/ng/ZincCompile/stdout`

looking at profiles at the moment. gc next

...hprof still only highlights the IO though. switching to GC for now.

hm... looks like analysis loading _is_ lazy in sbt, but zinc isn't using that.

getting ahead of myself, as i'm still trying to reproduce an oom due to analysis, but

We're now chasing down what seems to be a much more disturbing bug

Where the build finishes successfully, but an immediate "noop" rerun of the same command results in a bunch of targets being rebuilt

Based on traces, it seems like an upstream target is not actually being built the first time

(as opposed to its fingerprint being unstable)

For reference we're using 0.0.46 unpatched

In case there have been any major bugfixes since then