Audit CodeFixes that fabricate SemicolonToken for issue #395-class bugs

[Arthurvdv]

Background

Issue #395 revealed that the PC0037 CodeFix fabricated a SemicolonToken via SyntaxFactory.Token(EnumProvider.SyntaxKind.SemicolonToken) when rewriting a statement. In AL, a statement directly before else must not have a semicolon, so the fabricated token produced non-compiling code. The fix was to reuse the original statement's SemicolonToken (a missing token when absent).

Task

Audit the remaining CodeFixes that construct semicolon tokens and verify none of them can replace an existing statement whose semicolon is optional/absent (e.g., then-branch before else):

• src/ALCops.PlatformCop/CodeFixes/UseSetAutoCalcFieldsForLoopsCodeFixProvider.cs:155
• src/ALCops.ApplicationCop/CodeFixes/RunPageImplementPageManagement.cs:360 and :400
• src/ALCops.PlatformCop/CodeFixes/UsePartialRecordsOnRead.cs:195
• src/ALCops.PlatformCop/CodeFixes/MandatoryFieldMissingOnApiPage.cs:148
• src/ALCops.ApplicationCop/CodeFixes/GlobalLanguageImplementTranslationHelper.cs:346

CodeFixes that insert new statements into a block legitimately need a fabricated semicolon; the risky pattern is replacing an existing statement in place. For each location, determine which case applies and add regression fixtures (if-then before else, nested in repeat..until) where the replace-in-place pattern is used.

Correct reference pattern: GlobalLanguageImplementTranslationHelper.cs:141 and the PC0037 fix for #395.

Related

• [Bug] PC0037 - CodeFix for workspace generate semicolon for non semicolon lines #395

[Arthurvdv]

Audit results

All fabricated-SemicolonToken sites in src/ were audited (grep confirmed the list in this issue is exhaustive; no additional sites exist).

Site	Pattern	Verdict
UseSetAutoCalcFieldsForLoopsCodeFixProvider.cs:155 (PC0035)	Insert-new statement via InsertNodesBefore	Fabricated ; legitimate
RunPageImplementPageManagement.cs:360 (AC0006)	Var-section variable declaration	; always required — safe
RunPageImplementPageManagement.cs:400 (AC0006)	Using directive	; always required — safe
UsePartialRecordsOnRead.cs:195 (PC0030)	Insert-new; FindContainingStatement requires Parent is BlockSyntax	Safe
MandatoryFieldMissingOnApiPage.cs:148	field(Name; Expr) separator token, not a statement terminator	Safe
GlobalLanguageImplementTranslationHelper.cs:346	Var-section variable declaration	Safe
GlobalLanguageImplementTranslationHelper.cs:141	Replace-in-place assignment	Already reuses original token — correct

The statement-replacement paths in RunPageImplementPageManagement.cs:123 and GlobalLanguageImplementTranslationHelper.cs:124 replace only the invocation expression inside the statement, preserving the original semicolon — safe.

No #395-class bugs remain. The only replace-in-place ExpressionStatement construction site already follows the correct reference pattern.

Reference pattern verified against SDK source

• LanguageParser.cs (ParseIfStatement): else is only consumed when the then-statement has no semicolon; SemicolonOrNothing() returns null when absent → the public-API token kind is None. (Nuance: the issue text says 'missing token'; it is actually a None/default token, not a missing token.)
• SyntaxFactory.cs (ExpressionStatement(expression, semicolonToken)): explicitly validates the token is None or SemicolonToken, so reusing the original statement's token round-trips both cases. The pattern from fix: PC0037 CodeFix no longer fabricates semicolon before else #399 is confirmed correct.
• Microsoft's own CodeFixes fabricate a semicolon only in insert-new scenarios (Fix0235AddOnCompanyInitializeSubscriptionCodeFixProvider).

Reverse-bug check: no single-argument SyntaxFactory.ExpressionStatement(expr) uses exist (which would insert a statement without a semicolon) — no action needed.

Adjacent bug found: PC0035 CodeFix crash

The audit surfaced a different bug at the PC0035 site: the CodeFix crashes with InvalidOperationException: The item specified is not the element of a list when the insertion target (if Rec.FindSet() then repeat..until) is itself an unblocked then-branch of an outer if — there is no statement list to insert into. Verified with and without a trailing else. The structural pattern occurs 0 times in the BaseApp, but a single occurrence in a customer workspace would crash a FixAll batch.

Fixed in #400 (bail-out guard + NoFix regression fixtures).