Open zevv opened 1 year ago
ringabout
commented
1 year ago !nim c
import macros
macro foo(n: untyped): untyped =
discard
# Remove this macro to fix the problem
macro foo(n, n2: untyped): untyped =
discard
# This one is fine
proc test1(v: string) =
foo >"test1"
# This one fails to compile
proc test2[T](v: T) =
foo >"test2"
test1("hello")
test2("hello") 
github-actions[bot]
commented
1 year ago @ringabout (member)devel :-1: FAIL
Output
Error: Command failed: nim c --run -d:nimDebugDlOpen -d:ssl -d:nimDisableCertificateValidation --forceBuild:on --colors:off --verbosity:0 --hints:off --warnings:off --lineTrace:off --nimcache:/home/runner/work/Nim/Nim --out:/home/runner/work/Nim/Nim/temp /home/runner/work/Nim/Nim/temp.nim
/home/runner/work/Nim/Nim/temp.nim(12, 7) Error: wrong number of arguments2023-09-22T03:41:59
2023-09-22T03:41:59
0 bytes (0 bytes)
```cpp
```
2023-09-22T03:42:00
2023-09-22T03:42:00
0 bytes (0 bytes)
```cpp
```
2023-09-22T03:42:01
2023-09-22T03:42:01
0 bytes (0 bytes)
```cpp
```
2023-09-22T03:42:05
2023-09-22T03:42:05
0 bytes (0 bytes)
```cpp
```
2023-09-22T03:42:08
2023-09-22T03:42:08
0 bytes (0 bytes)
```cpp
```
2023-09-22T03:42:11
2023-09-22T03:42:11
0 bytes (0 bytes)
```cpp
```
2023-09-22T03:42:15
2023-09-22T03:42:15
0 bytes (0 bytes)
```cpp
```
11.4.0
2.35
3.18.1
17.1
6.2.0
2023-09-22T03:40:55Z
1
nim c --run -d:nimDebugDlOpen -d:ssl -d:nimDisableCertificateValidation --forceBuild:on --colors:off --verbosity:0 --hints:off --warnings:off --lineTrace:off --nimcache:/home/runner/work/Nim/Nim --out:/home/runner/work/Nim/Nim/temp /home/runner/work/Nim/Nim/temp.nim20 minutes bisecting 7 commits at 0 commits per second. 
metagn
commented
1 year ago Since foo is ambiguous, it is not immediately expanded like normal untyped macros, but > isn't ambiguous and is a fully untyped macro and so is immediately expanded despite the different parameter count.
We can make specifically > work (and != and >=) by changing its signature to add a non-untyped type anywhere (like template `>`(x, y: typed): bool = y < x). This could break either code using > etc. with untyped arguments or not returning bool, and also code depending on > etc.'s immediate expansion in generic procs, if any such code exists.
zevv
commented
1 year ago In the mean time, would there be a viable workaround for this?
metagn
commented
1 year ago You can define your own template `>`*(a, b: typed): bool anywhere as long as it's in scope, and it won't be evaluated early.
zevv
commented
1 year ago You can define your own
template `>`*(a, b: typed): boolanywhere as long as it's in scope, and it won't be evaluated early.
Of course, that should do the trick, thanks!
Description
I have a hard time coming up with a proper title for this issue, please correct me if you know a better one.
The code below fails to compile, there is some funny interaction going on between macros getting expanded from within a generic proc, causing the
>operator to be resolved to the "system/comperators/>()" proc, causing the error message.The snippet is minimized from a real-world problem where Npeg fails to compile when called from generic context (https://github.com/zevv/npeg/issues/68)
Notes:
foo()macro and things work>operator; any other operator compiles just fineNim Version
any
Current Output
Possible Solution
No response
Additional Information
No response