Reduce repeated Swift warnings and measure focused test build cost

[morluto]

Problem

A cold focused test produced approximately 11,000 warning emissions from about
451 distinct warning locations. The warnings contributed to a 97,209-line,
6.9 MB build log before nine selected tests ran.

The issue is both warning debt and missing measurement. We need to know which
warnings are unique, which are repeated, and how much focused build cost changes
after repository-owned warnings are fixed.

Observed run

Command:

./conductor test --filter WorkspaceSaveCoordinatorTests

Measured results:

• SwiftPM build: 315.49 seconds
• selected XCTest execution: 2.515 seconds
• build steps: 2,552
• root test target: 348 Swift files / approximately 201,000 lines
• build log: 6,880,015 bytes / 97,209 lines
• distinct warning locations: approximately 451
• raw warning emissions: approximately 11,000
• sampled swift-package physical-footprint peak: approximately 1.4 GB
• subsequent xctest RSS: approximately 794 MiB
• resulting worktree .build: approximately 8.1 GB

Some warning locations appeared about 25 times.

What is confirmed

• swift test --filter limited XCTest execution to nine tests but did not avoid
  building the root test target and its dependencies.
• The root test target depends on RepoPromptApp, RepoPromptMCP, and
  RepoPromptShared.
• The log contained far more warning emissions than distinct warning locations.
• Several warnings were Swift concurrency diagnostics in repository-owned code.
• Build time dominated the observed focused run: 315.49 seconds of build versus
  2.515 seconds of XCTest execution.

SwiftPM defines a target as a module or test suite; a test filter selects tests
to execute rather than creating a smaller compilation unit:

• https://docs.swift.org/swiftpm/documentation/packagedescription/target/
• https://docs.swift.org/swiftpm/documentation/packagemanagerdocs/swifttest/

What is not known

This sample does not show how much of the 315-second build or 1.4 GB peak was
caused by warnings. Cold dependency work and compilation of the broad target
graph were also present. The exact reason individual warnings were repeated has
not been isolated.

Required work

Add a read-only focused-build diagnostic that reports:

• total output bytes and lines;
• distinct warning locations and raw warning emissions;
• top repeated warnings and owning source files;
• build, link, and XCTest timing;
• peak child process-tree RSS;
• compiler job count;
• cold or warm cache state.

Use that report to classify repository-owned warnings and fix genuine Swift
concurrency/correctness warnings. Suppress a warning only when the toolchain or
dependency owns it and a source fix is not available.

After cleanup, repeat the same cold focused run and compare warning counts,
output size, time, and peak RSS. Keep target modularization (#416) as a separate
measurement so warning cleanup is not credited for unrelated cache or target
changes.

Expected behavior

Focused build output identifies each actionable warning without thousands of
unexplained repeats. Repository-owned concurrency warnings remain visible until
fixed.

Acceptance criteria

• A reproducible diagnostic separates distinct warnings from raw emissions.
• The diagnostic records output size, build/XCTest time, cache state, and peak child RSS.
• Repository-owned warnings are classified and fixed or tracked.
• Any suppression is narrow and documented.
• A comparable cold run records the before/after warning and resource measurements.
• Test behavior and contract-ledger IDs remain unchanged unless separately reviewed.

Related issues

• Modularize build targets so focused tests do not rebuild the monolithic RepoPrompt app target #416 — production-target modularization for focused tests
• Allow conductor Swift jobs to cap build parallelism #476 — optional Swift job-count limits
• Explore policy-gated local developer diagnostics for build and test failures #423 — local build/test diagnostics

[morluto]

Confirmed impact

The cold focused run spent 315.49 seconds building and 2.515 seconds executing
the selected tests. It emitted about 11,000 warnings from approximately 451
distinct locations, producing a 97,209-line log.

This establishes two problems:

1. the focused filter did not reduce cold compilation to the nine selected tests;
2. repeated warnings made the build output much larger than the underlying set
   of actionable warning locations.

The sample does not establish how much of the build time or 1.4 GB SwiftPM peak
came from warnings. The issue should measure warning cleanup separately from
target modularization and cache effects.

[morluto]

Investigation update: likely warning-amplification mechanism and measurement boundary

Repository inspection and upstream research narrow the leading hypothesis, but do not yet prove it for this run.

Swift batch compilation can launch multiple frontend jobs with different primary files. Each frontend still parses/type-checks secondary files, so a diagnostic associated with a secondary file can be encountered by multiple frontend jobs. Swift's DiagnosticHelper.cpp contains batch-mode handling specifically intended to avoid presenting duplicate diagnostics for non-primary files. That makes frontend-job amplification a credible explanation for the observed ratio of roughly 11,000 emissions to 451 locations (about 24x).

This should be attributed from build evidence rather than assumed. The diagnostic should record, for each warning:

• repository/dependency ownership;
• module and source:line:column;
• normalized diagnostic text;
• frontend process/job identity and primary-file grouping where available.

Use two groupings: exact diagnostic identity and source-location identity. Location-only grouping could incorrectly merge different diagnostics at one line; text-only grouping could merge unrelated files.

A separate driver attribution probe can capture verbose frontend command lines or use a dry-run command (swiftc -###) to map frontend invocations. Per-frontend serialized diagnostics or compiler stats may help, but should not be enabled in the timed baseline because instrumentation can change timing.

The key comparison remains:

1. fixed cold baseline;
2. warning fixes only, with identical toolchain, dependency state, scratch path, and Swift job count;
3. modularization measured later under Modularize build targets so focused tests do not rebuild the monolithic RepoPrompt app target #416.

This preserves the issue's important uncertainty: repeated warnings clearly damage signal and log size, but current evidence does not establish how much of the 315.49-second build they caused.

Sources:

• Swift compiler batch diagnostic handling
• Swift compiler driver/batch options
• SwiftPM test command documentation