fix(generators): ContainsOrdinal to satisfy MA0074 after Meziantou 3.0.114 bump#182
Merged
Merged
Conversation
…u 3.0.114 bump Meziantou.Analyzer 3.0.98 -> 3.0.114 (#181) newly enforces MA0074 on the five `string.Contains(string)` call sites in ErrorOrX.Generators, which under TreatWarningsAsErrors broke `main` (AOT Publish Smoke, run 28442562600). The netstandard2.0 BCL lacks `Contains(string, StringComparison)`; the ANcpLua.Roslyn.Utilities.Sources polyfill supplies it (that overload's existence is precisely what made MA0074 start firing). Rather than the BCL overload, switch to the package's `ContainsOrdinal` helper — the same ordinal-explicit idiom already used alongside (`StartsWithOrdinal`, `EndsWithOrdinal`). Behavior is identical (default string.Contains is already ordinal); the rule is satisfied by construction. Verified: `dotnet build -c Release` of the generator project and full slnx both 0 warnings / 0 errors; 156 generator tests pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
Cache: Disabled due to data retention organization setting Knowledge base: Disabled due to data retention organization setting Summary by CodeRabbit
WalkthroughFive string-comparison calls across analyzer, generator, and validator source files are changed from culture-sensitive Contains() to ordinal ContainsOrdinal() equivalents. The changes affect empty route-parameter detection, ErrorOrEndpoint attribute-name matching, and DbContext type-name matching. No public API signatures are altered. ChangesOrdinal Comparison Fix
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Comment |
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
2 participants
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.
Root cause
mainis red on AOT Publish Smoke (run 28442562600). PR #181 bumped Meziantou.Analyzer 3.0.98 → 3.0.114, and the newer analyzer enforces MA0074 (Use an overload of 'Contains' that has a StringComparison parameter) on the five barestring.Contains(string)call sites inErrorOrX.Generators. Under the repo-wideTreatWarningsAsErrors, that fails the build (5 Error(s)), skipping the AOT publish steps.Why MA0074 only started firing now:
ErrorOrX.Generatorstargets netstandard2.0, whose BCLstringhas noContains(string, StringComparison). TheANcpLua.Roslyn.Utilities.Sourcespolyfill supplies that overload as an extension — and MA0074 reports precisely because aStringComparisonoverload is now reachable.Fix
Switch the 5 sites to the package's
ContainsOrdinalhelper — the same ordinal-explicit idiom already used right alongside them (StartsWithOrdinal,EndsWithOrdinal,EqualsOrdinal), in global-usings scope. Behavior is unchanged: the defaultstring.Contains(string)is already ordinal, so this is a pure rule-satisfying rename, not a semantic change.Core/ErrorOrEndpointGenerator.ParameterBinding.TypeAnalysis.csValidation/RouteValidator.csAnalyzers/ErrorOrEndpointAnalyzer.csAnalyzers/ErrorOrEndpointAnalyzer.RouteValidation.csCore/ErrorOrEndpointGenerator.Initialize.EndpointFlow.csTests already use the net10.0 BCL
Contains(x, StringComparison.Ordinal)overload and were unaffected.Verification — complete & verified
dotnet build src/ErrorOrX.Generators -c Release→ 0 Warning(s), 0 Error(s) (MA0074 cleared, restores Meziantou 3.0.114)dotnet build ErrorOrX.slnx -c Release→ 0 / 0dotnet test tests/ErrorOrX.Generators.Tests→ 156 passed, 0 failed🤖 Generated with Claude Code