Templates: Method call prefers injected proc to outside, normal call doesn't

[metagn]

Example

proc bar(x: int): int = 10
template foo =
  proc bar(x: int): int = x + 2
  echo bar(3)
  echo 3.bar
block:
  foo()

Current Output

10
5

Expected Output

5
5

Possible Solution

The issue is here:

Nim/compiler/semtempl.nim

Lines 63 to 72 in fb5fbf1

	if i <= 1 and r != scForceOpen:
	# XXX this makes more sense but breaks bootstrapping for now:
	# (s.kind notin routineKinds or s.magic != mNone):
	# for instance 'nextTry' is both in tables.nim and astalgo.nim ...
	if not isField or sfGenSym notin s.flags:
	result = newSymNode(s, info)
	markUsed(c, info, s)
	onUse(info, s)
	else:
	result = n

sfGenSym notin s.flags is always true and not isField alternates between true and false between normal call syntax and method call syntax. The XXX part seems to have the solution, considering the s.kind notin routineKinds invariant. It could also fix #13515.

Additional Information

• {.dirty.} is a workaround
• mixin bar is also a workaround
• Exists since 1.0 at the latest.
• Related: Routines defined in a template are inaccessible in this template #12012

$ nim -v
Nim Compiler Version 1.7.1 [Windows: amd64]
Compiled at 2022-07-11
Copyright (c) 2006-2022 by Andreas Rumpf

git hash: 8bfc396a4dfa722239818f399a119452a53fe07f

[metagn]

????

proc bar(x: int): int = 10
template foo =
  proc bar(x: int): int {.gensym.} = x + 2
  echo bar(3)
block:
  foo()

Output:

5

proc bar(x: int): int = 10
template foo =
  proc bar(x: int): int {.gensym.} = x + 2
  echo 3.bar
block:
  foo()

Output:

.........................................................fatal.nim(53)            sysFatal
Error: unhandled exception: index out of bounds, the container is empty [IndexDefect]

Full stacktrace:

compiler\nim.nim(143) nim
compiler\nim.nim(98) handleCmdLine
compiler\main.nim(284) mainCommand
compiler\main.nim(254) compileToBackend
compiler\main.nim(110) commandCompileToC
compiler\modules.nim(181) compileProject
compiler\modules.nim(101) compileModule
compiler\passes.nim(184) processModule
compiler\passes.nim(76) processTopLevelStmt
compiler\sem.nim(653) myProcess
compiler\sem.nim(621) semStmtAndGenerateGenerics
compiler\semstmts.nim(2429) semStmt
compiler\semexprs.nim(1066) semExprNoType
compiler\semexprs.nim(3026) semExpr
compiler\semstmts.nim(2371) semStmtList
compiler\semexprs.nim(3025) semExpr
compiler\semexprs.nim(2602) semBlock
compiler\semexprs.nim(3026) semExpr
compiler\semstmts.nim(2371) semStmtList
compiler\semexprs.nim(2908) semExpr
compiler\semexprs.nim(1048) semDirectOp
compiler\semexprs.nim(931) afterCallActions
compiler\semexprs.nim(39) semTemplateExpr
compiler\sem.nim(430) semAfterMacroCall
compiler\semstmts.nim(2429) semStmt
compiler\semexprs.nim(1066) semExprNoType
compiler\semexprs.nim(3026) semExpr
compiler\semstmts.nim(2371) semStmtList
compiler\semexprs.nim(2922) semExpr
compiler\semexprs.nim(2397) semMagic
compiler\semexprs.nim(1047) semDirectOp
compiler\semexprs.nim(878) semOverloadedCallAnalyseEffects
compiler\semcall.nim(588) semOverloadedCall
compiler\semcall.nim(371) resolveOverloads
compiler\semcall.nim(95) pickBestCandidate
compiler\sigmatch.nim(2574) matches
compiler\sigmatch.nim(2507) matchesAux
compiler\sigmatch.nim(2303) prepareOperand
compiler\semexprs.nim(54) semOperand
compiler\semexprs.nim(2876) semExpr
compiler\semexprs.nim(1491) semFieldAccess
compiler\semexprs.nim(1407) builtinFieldAccess
compiler\lookups.nim(55) considerQuotedIdent
lib\system\fatal.nim(53) sysFatal
Error: unhandled exception: index out of bounds, the container is empty [IndexDefect]

Edit: Moved to #20002

[metagn]

tests/template/template_various.nim has this part:

Nim/tests/template/template_various.nim

Lines 274 to 283 in d0bae98

	block gensym1:
	template x: untyped = -1
	template t1() =
	template x: untyped {.gensym.} = 1
	echo x() # 1
	template t2() =
	template x: untyped = 1 # defaults to {.inject.}
	echo x() # -1 injected x not available during template definition
	t1()
	t2()

-1 injected x not available during template definition

Does this imply the behavior for the normal call is intended? If so, is the inconsistency with method calls also fine since the behavior of method calls are intended? Blame gives this PR

[metagn]

The solution in #20003 (treating the proc symbol as {.inject.}) would be correct but since this is a routine, we need to capture secondary overload symbols as well (which I think caused CI to fail but it's too old to check).

Cannot reproduce mixin being a workaround on any version, it gives an "ambiguous call" error since the outside bar is captured in an nkOpenSymChoice and the injected one does not "override" it and is treated equally. Kind of related to #22605 but an annoying edge case.

At the very least we can make it so explicitly injected procs actually inject. Currently injecting just behaves the same as not injecting.