Skip to content

Extract ErrorCode.Create() recognition into ErrorCodeFacts utility#38

Merged
Reefact merged 1 commit into
mainfrom
claude/roslyn-analyzer-inconsistencies-0iknqz
Jul 6, 2026
Merged

Extract ErrorCode.Create() recognition into ErrorCodeFacts utility#38
Reefact merged 1 commit into
mainfrom
claude/roslyn-analyzer-inconsistencies-0iknqz

Conversation

@Reefact

@Reefact Reefact commented Jul 6, 2026

Copy link
Copy Markdown
Owner

Summary

Centralizes the logic for recognizing ErrorCode.Create("...") invocations and extracting literal codes into a new ErrorCodeFacts utility class. This eliminates code duplication across four error-code analyzers (FCE001, FCE002, FCE004, FCE005) and improves maintainability.

Type of change

  • Bug fix
  • New feature
  • Breaking change
  • Refactoring
  • Analyzer / diagnostic change
  • Tests
  • Documentation
  • Build / CI / tooling

Changes

  • Added ErrorCodeFacts.cs: New utility class with three public methods:

    • GetCreateArgument(): Recognizes ErrorCode.Create(x) invocations and returns the argument operation, or null if not a valid call
    • TryGetNonEmptyLiteralCode(): Extracts the code when the argument is a non-empty literal string constant
    • IsBlankLiteralCode(): Checks if the argument is a literal constant with null, empty, or whitespace value
    • Centralizes the ErrorCodeMetadataName constant previously duplicated across analyzers
  • Refactored four analyzers to use ErrorCodeFacts:

    • DuplicateErrorCodeAnalyzer
    • EmptyErrorCodeAnalyzer
    • InvalidErrorCodeFormatAnalyzer
    • TooGenericErrorCodeAnalyzer

    Each now delegates ErrorCode.Create() recognition and literal code extraction to the utility, reducing boilerplate and improving consistency.

  • Enhanced UnusedToExceptionResultAnalyzer: Now detects when ToException() result is explicitly discarded with _ = assignment, in addition to standalone statements.

  • Added test case for FCE016: Reports_when_result_is_assigned_to_a_discard() verifies the analyzer catches explicit discard patterns.

  • Updated FCE016 documentation (English and French): Clarified that the rule now covers both standalone statements and explicit discards with _ =.

Testing

  • dotnet build FirstClassErrors.sln
  • dotnet test FirstClassErrors.sln
  • Analyzer tests pass (FirstClassErrors.Analyzers.UnitTests)

Documentation

  • Public API / error documentation updated
  • README / doc/ updated
  • French translation (doc/README.fr.md) updated if user-facing behavior changed

(b) Factor the ErrorCode.Create("literal") recognition and the
Optional<object?>.ConstantValue handling shared by FCE001, FCE002, FCE004
and FCE005 into a single ErrorCodeFacts helper. FCE004/FCE005 previously
relied on Optional<object?>.Value defaulting to null when HasValue is
false; the semantics are now centralized and made explicit, and each
analyzer no longer repeats the static-Create / arity / constant checks.
Behavior is unchanged for all four rules.

(a) FCE016 now also reports `_ = error.ToException();`. The explicit
discard wraps the invocation in an ISimpleAssignmentOperation whose target
is an IDiscardOperation, so the previous "bare expression statement" guard
missed it even though the result is thrown away just the same. ToException()
is a pure builder, so an explicit discard is as pointless as a standalone
call. Added a unit test and kept the FCE016 documentation (EN + FR) in sync.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019NBsUT3XFzH86c8L9iSDmn
@Reefact Reefact merged commit a7ca121 into main Jul 6, 2026
2 checks passed
@Reefact Reefact deleted the claude/roslyn-analyzer-inconsistencies-0iknqz branch July 6, 2026 22:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants