Compile error on questionable library with version-1-6 branch
#22897
Comments
|
I'm trying to reduce this a bit. It's not 100% clear to me yet, but 1.6.16 may be exposing a previous bug in the library that was ignored before. |
|
Indeed, it's a regression between 1.6.14 and 1.6.16. I think it's might be helpful to do bisect in order to find the cause. |
|
Okay, I will do a bisect. |
|
The bisect says b7a1210 might be the cause. |
|
Weird issue with typed templates, previously it would still fail if one of the template arguments was typed, now it also fails when return is typed. This example was broken in the past and is still broken template tempA(x: int): untyped =
let value {.inject.} = 2
proc procA[T](x: T) =
tempA(x)
echo valueThis example seems to be newly broken template tempA(x: untyped): int =
let value {.inject.} = 2
proc procA[T](x: T) =
tempA(x)
echo valueFully untyped templates expand immediately, once you introduce types it waits until generic instantiation, guess these checks happen before? I assume the core of the issue lies with this being required for overload resolution because you may try to pass a generic value to the template. This for example works template tempA(x: int) =
let value {.inject.} = 2
proc procA[T](x: T) =
tempA(x)
mixin value
echo value
procA(2)Simplest solution may be to simply mark generic procs that use templates as dirty, but that makes IDE tooling even worse. |
|
With this info it looks like a language design issue to me, pinging @Araq |
template tempA(x: untyped): int =
let value {.inject.} = 2is not valid code as it does not produce an |
|
Yah, I think the more correct / closer example would be: template tempA(x: untyped) =
let value {.inject.} = x
proc procA[T](x: T) =
tempA(x)
mixin value
echo value
procA(2)Though I don't have 1.6.16 setup to test currently. I pinged the author of the library and he was going to explore it a bit more. I suspect it might be a compiler regression for injected variables and the compiler exposing an existing bug in the library. |
|
That would be fully untyped and work no problem. The examples I used are all correct but it is true that the one pointed out should only be valid with an expression (library has one, but the issue is the same, broken evaluation order) |
Workaround for nim-lang/Nim#22897
|
Looks like the
It seems the core of this issue is that template with typed returns now fail. Here's some cleaned up templates based on @SirOlaf 's example: # works
template tempA(x: untyped): untyped =
let value {.inject.} = 2
value
proc procA[T](x: T) =
discard tempA(x)
echo value
procA(10)
# works
template tempC(x: untyped): int =
let value {.inject.} = 2
value
proc procC[T](x: T) =
discard tempC(x)
mixin value
echo value
procC(10)
# fails on 1.6.16, works on 1.6.14
template tempB(x: untyped): int =
let value {.inject.} = 2
value
proc procB[T](x: T) =
discard tempB(x)
echo value
procB(10)
|
Workaround for nim-lang/Nim#22897
Description
Testing out release
1.6.16(orversion-1-6) causes compilation failures forquestionable. The library does has a macro=?that that creates a new variable, but now there's a compilation failure saying the variable cannot be found. This only seems to occur when calling the=?macro inside a generic proc. Note that addingexpandMacrofixes the first compilation failure but fails on the next.Nim Version
Nim Compiler Version 1.6.16 [MacOSX: arm64]
Compiled at 2023-10-10
Copyright (c) 2006-2023 by Andreas Rumpf
git hash: 3c9b68d
active boot switches: -d:release -d:danger
Current Output
Expected Output
Possible Solution
No response
Additional Information
Adding this change to
testmodules/options/test.nimto print out the expanded code:Gives:
The generated code looks fine. It also works properly in the previous test where the main different is the
=?macro/template being called from a generic scope:The text was updated successfully, but these errors were encountered: