A nested function or procedure is lexically scoped to the routine that
contains it, so two sibling routines may each declare a nested helper of
the same name without conflict. Two independent gaps broke this:
* Nested-in-METHOD decls were still entered in the global overload index
(FProcIndex / FProcGroups). The registration guard in
AnalyseStandaloneDecls only excluded nested-in-standalone-proc decls
(FCurrentEnclosingDecl set); AnalyseMethodDecl never sets that field, so
a nested helper in a method body leaked into the global index and two
same-named siblings collided as "Ambiguous overload".
* Nested-in-PROC functions called as an expression could not be resolved.
AnalyseFuncCallExpr's tail consulted only FProcIndex.IndexOf and errored
with "Cannot find declaration for function 'X'" without ever checking the
scoped symbol it had already looked up. (The statement-position path,
AnalyseProcCall, already handled scoped nested procs, which is why only
the function-as-expression form failed.)
Fixes: also exclude a decl from global registration when FCurrentMethodOwner
is set (inside a method body); and in AnalyseFuncCallExpr, when the global
index misses but the scoped symbol carries a backing TMethodDecl, resolve the
call directly against that single decl.
Adds IR and e2e regression tests for both the proc and method enclosing forms,
and removes the MovRaxImm4b/4c rename workaround in cp.test.linker.pas — three
sibling test methods now legitimately share a nested MovRaxImm helper.
Verified: QBE, native, internal-asm and warm-cache fixpoints all green; full
suite passes under both the QBE-built and native-built test runner (4020 tests).
a1ba257da7