fix(toolchain): rename TToolKind.tkAs to tkGnuAs to remove enum ambiguity

`tkAs` was a member of two enums: TToolKind (uToolchain, ordinal 1) and
uLexer.TTokenKind (the lexer token enum, ordinal 40).  In ResolveAssembler,
the bare assignment `Result.Kind := tkAs` should bind to TToolKind, but
bare-member resolution is cross-unit order-fragile and could bind it to
TTokenKind.tkAs (ordinal 40) instead.  40 is out of range for the 4-member
TToolKind, so any downstream code that switches or indexes on the resolved
Kind runs off the end into a wild pointer — a layout-sensitive crash that
manifested intermittently in the test runner (a metaclass typeinfo symbol
truncation surfacing as a SIGSEGV during teardown).

Renaming the member to tkGnuAs removes the ambiguity entirely: `tkAs` now
exists only in uLexer.TTokenKind.  This is bootstrap-safe (no qualified-enum
syntax, which the release binary does not yet support).  Verified the
ResolveAssembler codegen now bakes Ord(tkGnuAs)=1 (was 40).
This commit is contained in:
Graeme Geldenhuys 2026-06-30 01:44:17 +01:00
parent c3ed2c89d6
commit 93596d135c

View file

@ -36,7 +36,13 @@ type
{ Variant of a tool, determining the CLI syntax callers emit. }
TToolKind = (
tkUnknown, { resolver couldn't classify }
tkAs, { as -o OUT IN.s — GNU assembler }
tkGnuAs, { as -o OUT IN.s — GNU assembler. Named tkGnuAs (not the
bare tkAs) so it does not collide with uLexer's
TTokenKind.tkAs: a bare `tkAs` here is ambiguous and
bare-member resolution is cross-unit order-fragile,
which could bind it to TTokenKind.tkAs (ordinal 40) —
out of range for this 4-member enum, sending downstream
Kind-indexing off the end into a layout-sensitive crash. }
tkCCDriver, { cc / gcc / clang-as-driver — GNU link line }
tkQBE { qbe -o OUT IN.ssa }
);
@ -307,7 +313,7 @@ end;
function ResolveAssembler: TTool;
begin
Result.Path := ResolveToolPath('BLAISE_AS', 'as', '');
Result.Kind := tkAs;
Result.Kind := tkGnuAs;
end;
function ResolveLinker(const ATarget: TTargetDesc): TTool;