generics execute compile time code in wrong order

[timotheecour]

The generic prepass order seems buggy, resulting in incomprehensible semantics (eg #8924), see also below.

that means if you add a static: doAssert false or when false: seemsDisabledButIsNot the results are not what you'd expect and differ from what would happen inside a non-generic proc.

Example2

  import std/macros

  macro mfun7*(a: untyped): untyped =
    echo "ok7"
  macro mfun8*(a: static int): untyped =
    echo "ok8"

  template mfun5() =
    static: echo "ok5"
  template mfun2() =
    static: echo "ok2"
  template mfun4() =
    echo "ok4"

  proc fun[T]() = # no bug if non-generic
    static:
      echo "ok3"
      mfun4()
      static:
        echo "ok1"
      mfun2()
    mfun5()
    static: echo "ok6"
    mfun7(1)
    mfun8(1)

  fun[int]()

Current Output

mfun7 (with no static param) is evaluated too early

ok7
ok1
ok2
ok3
ok4
ok5
ok6
ok8

Expected Output

same as for when fun is not generic:

ok1
ok2
ok3
ok4
ok5
ok6
ok7
ok8

Additional Information

• Your Nim version (output of nim -v).
  recent devel c0d240b

• Was it working in the previous Nim releases?
  no

• root cause for this: when false doesn't work inside a generic #8924 (when false: doesn't work inside generics)

• related to this discussion: Generics proc + macros: identifier resolution happens before macros #6387 and [Meta] Generics/Static early symbol resolution #8677 (/cc @mratsim )
  I don't this this is a dup because I didn't find a mention of FieldError as in example1

[timotheecour]

see #11950 which fixes 1st part
the fact the 1st part exists only for generics is because a different code path is being used for generics vs regular procs for calling macros. The 2nd part is still there.

[Araq]

The "different code path" is a feature and this is your basic mistake:

Expected Output
same as for when fun is not generic

It's simply not like that in Nim with its semi-checked generics.