fix(LC0092): skip platform-named action areas, system actions and layout areas

[Arthurvdv]

Fixes #537

Root cause

Every node inside an actions { } block is a single SymbolKind.Action symbol; IActionSymbol.ActionKind is the only thing that tells area apart from group, action, separator, actionref, customaction, systemaction and fileuploadaction. SymbolKind.Control is shaped the same way, with IControlSymbol.ControlKind separating the layout area from groups, fields and parts.

AnalyzeAction and AnalyzeControl never read those kinds, so a custom NamingPatterns.Action pattern such as act[A-Za-z0-9] was applied to area(Processing) — a name the platform fixes — and the Control pattern to area(Content). With the built-in defaults the same bug fires whenever an area is written lowercase (area(processing)), because ^[A-Z] fails.

Change

AnalyzeAction now skips:

• ActionKind.Area — the name selects an ActionAreaKind member.
• ActionKind.SystemAction — the name selects a SystemActionKind member.
• ActionKind.Group whose name is a predefined promoted category (Category_New, Category_Process, Category_Report, Category_Category4 .. Category_Category20) — the name binds the group to that platform category slot. This is the same skip AC0011 already applies; the names come from SyntaxFacts.PromotedCategoriesSynthesizedSymbolNames, which the SDK builds with SemanticFacts.NameEqualityComparer.

AnalyzeControl skips ControlKind.Area.

Everything else stays as it was: ordinary groups, separators, action references, custom and file-upload actions remain checked under Action, and every control kind other than the layout area under Control. No new naming targets, so alcops.json and alcops.schema.json are unchanged.

EnumProvider.ActionKind gains SystemAction. The member is absent from the oldest supported SDK, so it is resolved through the string overload with an explicit out-of-range sentinel — default(ActionKind) is Area, and falling back to it would make every action area read as a system action on the netstandard2.1 build.

Tests

New fixtures under src/ALCops.LinterCop.Test/Rules/NamingPattern/, all of which failed before the analyzer change:

Fixture	What it locks in
NoDiagnostic/ActionAreaLowerCase.al	area(processing) is not flagged by the default pattern
NoDiagnostic/ControlAreaLowerCase.al	area(content) is not flagged by the default pattern
NoDiagnostic/ActionAreaCustomPattern.al	the issue's repro, with the issue's alcops.json
NoDiagnostic/ControlAreaCustomPattern.al	layout area under a custom Control pattern
NoDiagnostic/PromotedCategoryGroupCustomPattern.al	area(Promoted) { group(Category_Process) }
NoDiagnostic/SystemActionCustomPattern.al	systemaction(OK) on a ConfigurationDialog page (gated at SDK 16.2.31: earlier SDKs reject the page type as a feature under development, AL0574)
HasDiagnostic/ActionGroupCustomPattern.al	ordinary groups and actions are still checked with the custom pattern

The custom-settings fixtures share one alcops.json that carries the issue's Action pattern, a Control pattern and the pre-existing EnumValue pattern.

Verification

• dotnet test src/ALCops.LinterCop.Test/ — 359 passed, 2 skipped, 0 failed.
• dotnet build ALCops.sln — succeeded, 0 errors.
• dotnet format ALCops.sln --verify-no-changes — clean.
• dotnet build src/ALCops.Common and src/ALCops.LinterCop with -c Release -p:ContinuousIntegrationBuild=true — netstandard2.1, net8.0 and net10.0 all succeed with 0 warnings.
• pwsh .claude/scripts/Validate-Rules.ps1 — OK.

Documentation for alcops.dev: ALCops/alcops.dev#181

🤖 Generated with Claude Code