Graveflo
commented
1 month ago !nim c
template inner(i: static int) {.dirty.} =
let thing = 1
template outer() =
proc p[T](x: T) =
inner(5)
echo thing
outer()
p(0)Open Graveflo opened 1 month ago
Graveflo
commented
1 month ago !nim c
template inner(i: static int) {.dirty.} =
let thing = 1
template outer() =
proc p[T](x: T) =
inner(5)
echo thing
outer()
p(0)
github-actions[bot]
commented
1 month ago 0 (0 bytes)
```cpp
```
2024-07-24T23:03:50
2024-07-24T23:03:50
0 (0 bytes)
```cpp
```
2024-07-24T23:03:54
2024-07-24T23:03:54
0 (0 bytes)
```cpp
```
2024-07-24T23:03:57
2024-07-24T23:03:57
0 (0 bytes)
```cpp
```
2024-07-24T23:04:00
2024-07-24T23:04:00
0 (0 bytes)
```cpp
```
2024-07-24T23:04:03
2024-07-24T23:04:03
0 (0 bytes)
```cpp
```
2024-07-24T23:04:07
2024-07-24T23:04:07
0 (0 bytes)
```cpp
```
2024-07-24T23:04:09
2024-07-24T23:04:09
0 (0 bytes)
```cpp
```
2024-07-24T23:04:11
2024-07-24T23:04:11
11.4.0
14.0.0
20.4
2024-07-24T23:03:24Z
1
nim c --run -d:nimDebug -d:nimDebugDlOpen -d:ssl -d:nimDisableCertificateValidation --forceBuild:on --colors:off --verbosity:0 --hints:off --lineTrace:off --nimcache:/home/runner/work/Nim/Nim --out:/home/runner/work/Nim/Nim/temp /home/runner/work/Nim/Nim/temp.nim:robot: Bug found in 24 minutes bisecting 8 commits at 0 commits per second
Graveflo
commented
1 month ago yea has nothing to do with statics actually
SirOlaf
commented
1 month ago The failure probably happens because typed templates are deferred for too long (or maybe it would be unsafe to expand), so it's not expanded by the time the generic body is checked. Works with untyped.
SirOlaf
commented
1 month ago Take a look around this location https://github.com/nim-lang/Nim/blob/c1f91c26a5136b2ad00f7da93b19c2da9b85dd16/compiler/semgnrc.nim#L284
And potentially here, maybe allUntyped should only be false when a param contains typed/generic parameters, currently it does a negative check against tyUntyped https://github.com/nim-lang/Nim/blob/c1f91c26a5136b2ad00f7da93b19c2da9b85dd16/compiler/semtempl.nim#L640
Graveflo
commented
1 month ago Take a look around this location
Thanks for looking into this. As I said here https://github.com/nim-lang/Nim/pull/23890#issuecomment-2249361096 I'm not too sure if early expansion is going to to be the right call, but it's certainly something to try. Intuitively it makes sense, but I wonder why this expansion was conditional in the first place.
metagn
commented
1 month ago This is an issue with generics more than templates and there are other issues that cover the exact same problem which I will edit this comment to link later. (Edit: #21376, #21249, #22084, #15693) This is a simpler example:
template inner(i: int) {.dirty.} = # or just a normal template with {.inject.}
let thing = 1
proc p[T](x: T) =
inner(5)
echo thing
p(0)The undeclared identifier error isn't actually fatal but as discovered in #23890 not erroring early can lead to some quirky behavior. The existing attitude to this issue has been "will be fixed with proper generic expression typechecking" in the comments of the other issues but maybe in the meantime we can find ways to signal to the compiler that there shouldn't be an error, these might prove useful even when we get generic typechecking. Or they might not be useful at all.
Some ways I can think of right off the bat:
proc p[T](x: T) =
inner(5)
{.inject: thing.} # generic proc is told that a symbol `thing` has been injected
echo thingtemplate inner(i: int) {.injects: [thing].} =
let thing {.inject.} = 1
proc p[T](x: T) =
inner(5) # compiler knows `thing` was injected
echo thing@metagn
Thanks for explaining that. I've been messing with simpler examples too. I don't like this duct tape syntax because it'll just force a refactor later, or worse. It could end up being something that sticks around longer then it needs to. If there is a problem why not just go for the throat and look into this "proper generic expression type checking" problem?
If the solution to that problem is anything like what we currently have, there is still a problem with when to do the template expansion.
edit: posted a bad example. I'll try and come up with a better one
Graveflo
commented
1 month ago ah nvm maybe it is just the type checking. I'm assuming the operands to the template and macro are the problem according to SirOlaf's sfAllUntyped in s.flags and sc.safeLen <= 1 reference
metagn
commented
1 month ago I edited my comment to link the other issues but it seems like you found them already, yes this only triggers when the template has a typed argument or is overloaded, fully untyped single templates get evaluated early at a syntax level in generic procs.
If there is a problem why not just go for the throat and look into this "proper generic expression type checking" problem?
It's mentioned here: https://github.com/nim-lang/RFCs/issues/168, Araq can probably explain it better. It's also in the roadmap under Upcoming Versions -> Language. I would encourage asking Araq about it, it's really his plan and he might have ideas about how to speed it up.
It needs (for new functionality) a stronger type system, especially more fleshed out concepts, hence the RFC it was brought up in. The PRs that focus on sigmatch handling typeclasses like concrete types are also related. #22029 was a microcosm of it for type sections, it wasn't perfect and we're still dealing with the fallout.
Araq
commented
1 month ago It needs (for new functionality) a stronger type system, especially more fleshed out concepts, hence the RFC it was brought up in.
FWIW I had it working in a prototype and it didn't need concept at all.
Description
This might be mentioned elsewhere in another form, but this is a self contained example
this does not work:
but this does:
Nim Version
Nim Compiler Version 2.1.9 [Linux: amd64] Compiled at 2024-07-24 Copyright (c) 2006-2024 by Andreas Rumpf
git hash: c1f91c26a5136b2ad00f7da93b19c2da9b85dd16 active boot switches: -d:releas
Current Output
Expected Output
Possible Solution
No response
Additional Information
No response