feat(CM0001): warn when alcops.json cannot be fully loaded - #512
Merged
Conversation
ALCopsSettingsProvider now records why a found alcops.json was not applied - unreadable file, malformed JSON, or unknown top-level settings - in an ALCopsSettingsLoadResult, and the new CM0001 analyzer hosted in ALCops.Common.dll reports each failure per compilation at Location.None. Malformed/unreadable files still fall back to defaults; unknown keys warn while all recognized settings keep applying. Behavior change: an app-folder alcops.json that exists but cannot be read no longer falls through to a parent-directory configuration. Closes #328 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Provider tests exercise malformed JSON, unknown keys (incl. $schema allowlist and case-insensitivity), unreadable virtual files via a ThrowingFileSystem double, and failure caching. Analyzer tests use a manual Compilation + CompilationWithAnalyzers harness because RoslynTestKit's marker asserts cannot match Location.None. The shared Conventions tests are re-enabled now that Common ships an analyzer. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Comments now explain the loader mechanism instead of citing issue numbers, and GetVirtualSource loses the catch(ArgumentException) around Path.Combine, which stopped validating path characters in .NET Core 2.1. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…ule doc Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Arthurvdv
added a commit
to ALCops/alcops.dev
that referenced
this pull request
Sep 4, 2026
Adds the Common analyzers section for the cross-cutting diagnostics hosted in ALCops.Common.dll, with the CM0001 rule page (failure modes, what still applies, Location.None note, $schema allowlist). Companion to ALCops/Analyzers#512 (issue #328). Co-authored-by: Claude Fable 5 <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.
Closes #328
What
A found-but-broken
alcops.jsonno longer fails silently. A new diagnostic CM0001 (Warning, enabled by default) reports:$schemaallowlisted)No file at all still means silent defaults. The malformed→defaults fallback contract is unchanged — the diagnostic is purely additive.
How
ALCopsSettingsProvidernow caches anALCopsSettingsLoadResult(settings +SettingsLoadFailures).GetSettingsis a thin wrapper, so the seven existing call sites are untouched. The failure taxonomy (Unreadable/Invalid/UnknownSetting+ free-text detail) leaves room for the remote-configuration failure modes deferred here by feat: support remote ALCops configuration #500.ALCops.Common.dllitself — one diagnostic instead of six per-cop duplicates. This is loader-safe: every documented install path already listsALCops.Common.dllas an analyzer reference,alcdiscovers analyzers purely by the[DiagnosticAnalyzer]attribute, and the v1.0.0 breaks under alc (AL compiler): AL1003 — cops can't instantiate because ALCops.Common is not resolved from the Analyzers folder #389 AL1003 trap only applies to types whose base class lives in a sibling DLL — this analyzer derives directly from the SDKDiagnosticAnalyzer. (Microsoft ships the same pattern inMicrosoft.Dynamics.Nav.Analyzers.Common.dll.)RegisterCompilationActionatLocation.None(alcops.json is not part of the compilation; VS Code surfaces it against app.json). Cached failures re-report every compilation; no accumulator, no instance state.ALCopsSettingsproperties, so new settings extend it automatically. Nested typos remain covered by the JSON schema in editors.IFileSystem.Exists(verified present at the AL 12 interface floor) distinguishes not-found from unreadable;GetAbsolutePathis deliberately avoided (absent at that floor). The previously unwrapped physicalFile.ReadAllText(an AD0001 path) is now handled.Behavior change
An app-folder
alcops.jsonthat exists but cannot be read no longer silently falls through to a parent-directory configuration — the app-level file was intended to win, so ALCops uses defaults and reports CM0001 instead.Verification
dotnet test ALCops.sln— 1,670 passed (16 new: 10 provider-level, 6 analyzer-level via a manualCompilationWithAnalyzersharness, since RoslynTestKit's marker asserts can't matchLocation.None)netstandard2.1;net8.0;net10.0with-p:ContinuousIntegrationBuild=truedotnet format --verify-no-changescleancommonsection are in a companion alcops.dev PR🤖 Generated with Claude Code