Fix #945 — clean up build warnings (Lite 190→0, Dashboard 3→0)#948
Merged
erikdarlingdata merged 1 commit intodevfrom May 8, 2026
Merged
Fix #945 — clean up build warnings (Lite 190→0, Dashboard 3→0)#948erikdarlingdata merged 1 commit intodevfrom
erikdarlingdata merged 1 commit intodevfrom
Conversation
Lite went from 190 warnings to 0, Dashboard from 3 to 0, Installer was
already clean. Total fixes:
- Add repo-root .editorconfig suppressing CA1873 ("potentially expensive
logging") with rationale. This rule fires on every non-literal
argument to a logging method including trivial field accesses, which
accounts for ~97% of Lite's warning count and is pure noise — the
cost the rule warns about is consistently negligible. Proper fix is
migrating to LoggerMessage source generators, tracked separately.
- Lite/Controls/CorrelatedTimelineLanesControl.xaml.cs: guard against
null .Result on completed comparison-data tasks before passing to
.Select() (CS8604 ×2). The author already wrote `?.Count ?? 0` for
the same fields elsewhere, so null was anticipated; the .Select calls
just missed the guard.
- Lite/Mcp/McpAnalysisTools.cs: tighten FormatBaselineContext return
type from object? to Dictionary<string, object>?, removing the
unnecessary boxing (CA1859).
- Dashboard/ServerTab.Plans.cs: discard the bool returns from three
int.TryParse calls with `_ =`, making the "ignore failure, use
default 0" intent explicit (CA1806 ×3). Behavior unchanged —
TryParse already sets the out param to default on failure.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Reduces full-rebuild warning counts to 0 across all three projects.
Files
.editorconfig(new, repo root)Suppresses CA1873 ("Avoid potentially expensive logging") globally with a justifying comment. This rule fires on any non-literal argument to a logging method — including trivial field accesses like
_logger.LogInformation(""X: {Path}"", _path)— and accounted for ~97% of Lite's warning count. The cost the rule warns about is consistently negligible in this codebase. Real fix would be migrating toLoggerMessagesource generators across the codebase, which is a separate effort.Lite/Controls/CorrelatedTimelineLanesControl.xaml.cs(CS8604 ×2)The comparison-data fetch path passed possibly-null
Task<T>.Resultdirectly to.Select(...)after only checkingIsCompletedSuccessfully. The same file does?.Count ?? 0for these exact fields elsewhere, so null was anticipated — the.Selectlines just missed the guard. Added&& Result != nullto the conditions on both lines.Lite/Mcp/McpAnalysisTools.cs(CA1859 ×1)FormatBaselineContextalready builds and returns aDictionary<string, object>, but the declared return type wasobject?, forcing boxing. Tightened toDictionary<string, object>?.Dashboard/ServerTab.Plans.cs(CA1806 ×3)Three sites called
int.TryParse(..., out X)and discarded the bool return, relying on TryParse setting the out param to default on failure. Behavior is correct, but the analyzer can't see the intent. Replaced with_ = int.TryParse(...)to make the discard explicit. Behavior unchanged.Notes
Static analyzers fire on the WPF temp-project compilation step, so each warning shows up twice in the raw output. The 187 / 3 unique counts above match the deduplicated tallies.
CS8019 / CS8933 (redundant
usingdirectives covered by global usings) appear in IDE diagnostics but are not surfaced bydotnet build, so they don't affect the build warning count and aren't addressed here.🤖 Generated with Claude Code