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

Render bug: explicit generic param in call is omitted #10580

Open
cooldome opened this issue Feb 6, 2019 · 5 comments
Open

Render bug: explicit generic param in call is omitted #10580

cooldome opened this issue Feb 6, 2019 · 5 comments

Comments

@cooldome
Copy link
Member

cooldome commented Feb 6, 2019

Example :

import macros

proc test(): seq[bool] =
  result = newSeq[bool](2)

macro dumpSym(fn: typed{nkSym}): untyped =
  let fn_impl = fn.getImpl
  echo fn_impl.repr
  echo fn_impl.tree_repr

dumpSym(test)

test proc is rendered in the following way:

proc test(): seq[bool] =
  result = newSeq(2)

The required generic type argument [bool] is omitted from the newSeq call and rendered code does not compile.

@cooldome
Copy link
Member Author

cooldome commented Feb 6, 2019

I don't have a clean and simple solution.

Possible solutions:

  • Renderer only changes (all most):
    Renderer will detect that called symbol is with sfFromGeneric flag and will render [type list] from
    instantiation info.
    downsides: all generics arguments will be rendered even if they were inferred.
    Possible mitigation: save info which of the generic types were provided by user during symbol
    instantiation and render only them. Still instantiation is done once and reused many types, if user made
    2 calls to one generic proc once providing generic type explicitly and second time it was inferred, both
    these calls will be rendered identically (minor issue in my opinion as long as rendered code compiles).

  • Introduce new PNode call kind that will have generic param list stored as one of the arguments of special kind. Rendering becomes super easy, but you can't just add new call kind to nnkCallKinds. This extra special generic argument will cause problems for existing code and it needs to be skipped by codegen and friends.

@Araq:
Let me know what is the preferred solution.

@Araq
Copy link
Member

Araq commented Feb 6, 2019

I'm working on a spec for typed ASTs. And this would be a "won't fix, works as by the spec" for me. We must be allowed to reduce call ASTs to only the required information.

@cooldome
Copy link
Member Author

cooldome commented Feb 6, 2019

Ok, if we don't want to change AST then renderer only solution from the above should be ok. Renderer will add [args] to every generic sym call.

It will be verbose, but correct. Any issues with this approach?

@Araq
Copy link
Member

Araq commented Feb 6, 2019

Well I don't understand how you will accomplish "* Renderer will detect that called symbol is with sfFromGeneric flag and will render [type list] from instantiation info." :-)

@mratsim
Copy link
Collaborator

mratsim commented Feb 6, 2019

This seems similar to: #7737 (getTypeInst for generics does not gives the full instantiation info in certain cases) and another case of the meta issue with generics + macros (nim-lang/RFCs#44)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants