Closed deech closed 3 years ago
The problem appears to be here: https://github.com/nim-lang/fusion/blob/master/src/fusion/matching.nim#L1495
If you print the path
argument inside the for-loop you get different output each time.
It seems like macro implementation behaves differently based on --gc:arc
vs regular GC option. Input ASTs are identical in both cases, so most likely there is some subtle difference in how macro works with different GCs - the only explanation that seems reasonable to me.
Yeah it seems the existing tests fail with gc:{orc,arc}
:
$ nim cpp --gc:arc tmatching.nim
/tmp/fusion/tests/tmatching.nim(47, 7) template/generic instantiation of `suite` from here
/tmp/fusion/tests/tmatching.nim(345, 13) template/generic instantiation of `multitest` from here
/tmp/fusion/tests/tmatching.nim(373, 5) template/generic instantiation of `case` from here
/tmp/fusion/src/fusion/matching.nim(1980, 19) Error: no `len` defined for tuple[c: array[0..2, int]] - needed to find number of elements for pattern [_, _, _]
Works fine without.
You're right, it looks like a Nim VM bug: https://github.com/nim-lang/Nim/issues/17294
https://github.com/nim-lang/Nim/pull/17348 fixes the issue.
@deech this needs a test case in fusion even though the underlying bug was fixed in stdlib; can you make a PR?
@haxscramper has already written tests for it: https://github.com/nim-lang/fusion/pull/77/files?file-filters%5B%5D=.nim#diff-33abcca7f03798f7fd369f34051711499dee90cea8d05859cd933d31ce115f09R46. It includes the example case I posted, once the changes to matching. nim
are backed out since that workaround is no longer necessary all the rest of the work (doc cleanup and tests) should be pulled into fusion.
https://github.com/nim-lang/fusion/pull/77 PR has a test case, although it triggers only when orc
is enabled, which is enabled by https://github.com/nim-lang/fusion/pull/79. This bug does not have an "edge case", but instead stems from broken behavior on current stable
https://github.com/nim-lang/fusion/pull/77 provides a simple fix that can be reverted (or implemented as no-op for version 1.4.6+
) when current level becomes the latest stable (which will certainly take some time). Until the new version of nim is release I think #77 provides sufficient fix.
The following matching example:
produces the error:
but only when compiled with
gc:orc
orgc:arc
.Nim version: