Give ntConstant and ntVariable end positions

[partouf]

Disclosure: written with Claude Code (Claude Opus 5), which is also recorded in each commit's Co-Authored-By trailer. Everything claimed below was actually run, and the steps are reproducible from the branch.

Constant and variable declarations produce nodes with no end position at all, so a consumer working in line ranges cannot tell how far a declaration reaches. That silently truncates any declaration that spans lines:

const
  Banner = 'first part ' +
           'second part';
var
  Grid: array[0..1] of
    Integer;

Both report only their first line, so a tool slicing that range drops the continuation. ntTypeDecl already records an end; this brings constants and variables in line with it.

I hit this writing a refactoring tool that moves declarations between units by slicing source text — a multi-line constant came out truncated in the destination and orphaned in the source, leaving both files unparseable, with nothing in the AST to indicate why.

Two commits, one per node type, each independently buildable and testable.

Why each fix is two changes

The node a caller finally sees is not the node that was parsed, so fixing the declaration handler alone has no effect (my first attempt, and the test still failed):

• ConstantDeclaration / VarDeclaration now push compound nodes and record their end, the way TypeDeclaration already does. This gives the intermediate ConstList / VarList an accurate extent.
• ConstSection / RearrangeVarSection rebuild each declaration from that intermediate, so they also push compound nodes and inherit the end from it. The start still comes from the name — which is what a caller looking for the declaration expects — and only the end is new.

TCompoundSyntaxNode.AssignEndPositionFrom is added as the counterpart to the existing AssignPositionFrom, for exactly this rebuild case; both fixes use it. The is TCompoundSyntaxNode guards keep things safe if a declaration ever arrives by another path.

Names sharing one line (A, B: Integer;) each get the extent of the declaration they share.

Output footprint

Only the per-declaration node gains position attributes. The section nodes that reach the tree are untouched, because the compound ntConstants / ntVariables nodes created above are the throwaway intermediates that ConstSection and VarSection free:

<CONSTANT   begin_line=… end_line=…    gained
<VARIABLE   begin_line=… end_line=…    gained
<CONSTANTS  line=… col=…               unchanged
<VARIABLES  line=… col=…               unchanged

Verification

Test/UnitTests on Delphi 13 Win32, at each commit:

	tests	passed	failed
before	42	41	1
after commit 1 (const)	43	42	1
after commit 2 (const + var)	44	43	1

The one failure is unchanged and pre-existing — Serialization.BinaryRoundTrip, where line_seq holds a pointer value that does not survive a round trip. Unrelated to these changes.

FPC via the repo's own FPC tests workflow, on the branch tip: 43 tests, 43 passed, 0 failed.

The two new tests each assert both directions:

• a declaration spanning two lines reaches the second one, and
• a single-line declaration still ends on its own line rather than running on to whatever follows.

The second assertion matters as much as the first: an end position that overran into the next declaration would be no more useful than one that stopped short.

Checked against a real file rather than only synthetic strings:

before:  CONST MultiLineConst   start=35  end=NONE (not a compound node)
after:   CONST MultiLineConst   start=35  end=36
         CONST SingleLineConst  start=34  end=34

I also rebuilt the tool that prompted this against the patched parser and ran its full golden-file suite at each commit — every command's output and every lint rule byte-identical. So this does not disturb an existing consumer that reads constants or variables today.

Deliberately not included

ntMethod.EndLine is a different problem and I have left it alone. It is populated, but with the lexer position after the construct, so for a bodyless declaration it points at the next declaration's first token:

ntMethod begin_line=20  end_line=21   (line 20 is a one-line forward declaration)
ntMethod begin_line=21  end_line=25   (line 21 is a one-line forward declaration)

A routine with a body can be measured from its ntStatements child, which is exact. Unlike constants and variables — which had no value at all, so there was nothing to break — changing what ntMethod.EndLine means would be a behavioural break for any consumer already relying on it. Happy to look at it separately if you think it is worth changing.