Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using generic static[int] as parameter in another static[...] parameter #4990

Closed
flyx opened this issue Nov 2, 2016 · 3 comments · Fixed by #24005
Closed

Using generic static[int] as parameter in another static[...] parameter #4990

flyx opened this issue Nov 2, 2016 · 3 comments · Fixed by #24005
Assignees
Labels
stale Staled PR/issues; remove the label after fixing them Static[T]

Comments

@flyx
Copy link
Contributor

flyx commented Nov 2, 2016

type Foo*[I: static[int], A: static[array[I, int]]] = object
  curIndex: int

proc next*[I: static[int], A: static[array[I, int]]](f: Foo[I, A]): string =
  discard

This yields:

test1.nim(1, 43) Error: cannot generate code for: I

Is this a bug or is it impossible to get working?

@Araq
Copy link
Member

Araq commented Nov 2, 2016

Seems just another static[T] bug.

@flyx
Copy link
Contributor Author

flyx commented Nov 3, 2016

Possibly the same bug, maybe a different one:

type
  Foo*[A: static[int], B: static[int], TokenType: enum, EofToken: static[TokenType]] = object
    curIndex: int

  MyEnum = enum
    meA, meB

  Bar = Foo[2, 3, MyEnum, meA]


proc next*[A: static[int], B: static[int], TokenType: enum,
           EofToken: static[TokenType]](f: Foo[A, B, TokenType, EofToken],
    a: static[(array[A, int], array[B, int])]): TokenType =
  TokenType(a[0][f.curIndex])

const
  a = [1, 2]
  b = [3, 4, 5]

template next*(bar: Bar): MyEnum =
  next(Foo[2, 3, MyEnum, meA](bar), (a, b))

let bar = Bar(curIndex: 0)

echo bar.next()

Yields:

test1.nim(23, 9) template/generic instantiation from here                                                                                                                             
test1.nim(11, 142) Error: cannot generate code for: A

The interesting thing is that this only happens if EofToken is present. If I remove that, the code will happily compile and run.

@Araq Araq added the Static[T] label Nov 3, 2016
@zah zah self-assigned this Mar 10, 2017
@stale
Copy link

stale bot commented Aug 4, 2020

This issue has been automatically marked as stale because it has not had recent activity. If you think it is still a valid issue, write a comment below; otherwise it will be closed. Thank you for your contributions.

@stale stale bot added the stale Staled PR/issues; remove the label after fixing them label Aug 4, 2020
metagn added a commit to metagn/Nim that referenced this issue Aug 25, 2024
metagn added a commit to metagn/Nim that referenced this issue Aug 25, 2024
@Araq Araq closed this as completed in 69ea133 Aug 26, 2024
narimiran pushed a commit that referenced this issue Dec 12, 2024
…n fixes (#24005)

fixes #4228, fixes #4990, fixes #7006, fixes #7008, fixes #8406, fixes
(remaining issue fixed), refs #8545 (works properly now with
`cast[static[bool]]` changed to `cast[bool]`), refs #22342 and #22607
(disabled tests added), succeeds #23194

Parameter and return type nodes in generic procs now undergo the same
`inGenericContext` treatment that nodes in generic type bodies do. This
allows many of the fixes in #22029 and followups to also apply to
generic proc signatures. Like #23983 however this needs some more
compiler fixes, but this time mostly in `sigmatch` and type
instantiations.

1. `tryReadingGenericParam` no longer treats `tyCompositeTypeClass` like
a concrete type anymore, so expressions like `Foo.T` where `Foo` is a
generic type don't look for a parameter of `Foo` in non-generic code
anymore. It also doesn't generate `tyFromExpr` in non-generic code for
any generic LHS. This is to handle a very specific case in `asyncmacro`
which used `FutureVar.astToStr` where `FutureVar` is generic.
2. The `tryResolvingStaticExpr` call when matching `tyFromExpr` in
sigmatch now doesn't consider call nodes in general unresolved, only
nodes with `tyFromExpr` type, which is emitted on unresolved expressions
by increasing `c.inGenericContext`. `c.inGenericContext == 0` is also
now required to attempt instantiating `tyFromExpr`. So matching against
`tyFromExpr` in proc signatures works in general now, but I'm
speculating it depends on constant folding in `semExpr` for statics to
match against it properly.
3. `paramTypesMatch` now doesn't try to change nodes with `tyFromExpr`
type into `tyStatic` type when fitting to a static type, because it
doesn't need to, they'll be handled the same way (this was a workaround
in place of the static type instantiation changes, only one of the
fields in the #22647 test doesn't work with it).
4. `tyStatic` matching now uses `inferStaticParam` instead of just range
type matching, so `Foo[N div 2]` can infer `N` in the same way `array[N
div 2, int]` can. `inferStaticParam` also disabled itself if the
inferred static param type already had a node, but `makeStaticExpr`
generates static types with unresolved nodes, so we only disable it if
it also doesn't have a binding. This might not work very well but the
static type instantiation changes should really lower the amount of
cases where it's encountered.
5. Static types now undergo type instantiation. Previously the branch
for `tyStatic` in `semtypinst` was a no-op, now it acts similarly to
instantiating any other type with the following differences:
- Other types only need instantiation if `containsGenericType` is true,
static types also get instantiated if their value node isn't a literal
node. Ideally any value node that is "already evaluated" should be
ignored, but I'm not sure of a better way to check this, maybe if
`evalConstExpr` emitted a flag. This is purely for optimization though.
- After instantiation, `semConstExpr` is called on the value node if
`not cl.allowMetaTypes` and the type isn't literally a `static` type.
Then the type of the node is set to the base type of the static type to
deal with `semConstExpr` stripping abstract types.
We need to do this because calls like `foo(N)` where `N` is `static int`
and `foo`'s first parameter is just `int` do not generate `tyFromExpr`,
they are fully typed and so `makeStaticExpr` is called on them, giving a
static type with an unresolved node.

(cherry picked from commit 69ea133)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Staled PR/issues; remove the label after fixing them Static[T]
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants