-
Notifications
You must be signed in to change notification settings - Fork 114
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
Cannot instantiate Future got: <T> but expected: <T> after bumping nim-chronos
#963
Comments
Hey, stumbled onto this issue I'll look around to see if status-im/nim-chronos#243 caused it |
You can workaround it by rebuilding the untyped AST. Example for proc replaceNodes*(ast: NimNode): NimNode =
# Replace NimIdent and NimSym by a fresh ident node
proc inspect(node: NimNode): NimNode =
case node.kind:
of {nnkIdent, nnkSym}:
return ident($node)
of nnkEmpty:
return node
of nnkLiterals:
return node
else:
var rTree = node.kind.newTree()
for child in node:
rTree.add inspect(child)
return rTree
result = inspect(ast) |
Fixed here: status-im/nim-chronos#261 Not clear why it worked at some point, will investigate later |
Great, thanks! I can confirm the fluffy build works again with that chronos branch. |
Memory fixes, http fixes, fix for issue #963, etc.
Memory fixes, http fixes, fix for issue #963, etc
Memory fixes, http fixes, fix for issue #963, etc
After bumping nim-chronos to latest version when trying to run
make fluffy
following error manifests:Imo this error is composed of two parts:
seq[Record]
should be:but what really is there during compilation is:
Which makes me think we hit issue: nim-lang/Nim#11091
Future[T]
.New version:
iterator nameIter(chronosInternalRetFuture: Future[T]): FutureBase
Old version:
iterator nameIter(): FutureBase {.closure.}
and we hit some type of the issue : nim-lang/Nim#19358
So even the issue
1
existed from what I can tell always, the old version of chronos macro was not affected, but after the updatecorrect type cannot be instantiated.
One workaround this is to introduce type alias:
then everything builds successfully, of course it does not solve root cause.
I still do not have enough knowledge of the compiler to propose the fix to the root cause, but imo it would be nice if proper
BracketExpr
was generated in our rpc macro. Wdyt @zah @kdeme ?The text was updated successfully, but these errors were encountered: