-
Notifications
You must be signed in to change notification settings - Fork 18
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
workaround codegen error for Base10.decode
#111
Conversation
04e8f1a
to
c016512
Compare
Calling `Base10.decode` may lead to different structures being generated for use with `uint64`. The one normally generated is: ``` struct tyObject_Result__559ckyoL0ZZBsNFIYXjaoeg {NIM_BOOL o; union{ struct {NCSTRING e; } _o_1; struct {unsigned long long v; } _o_2; }; ``` But sometimes, it may be generated as: ``` struct tyObject_Result__xZhi1m1g75ioXsKjx9bN5bg {NIM_BOOL o; union{ struct {NCSTRING e; } _o_1; struct {NU64 v; } _o_2; }; ``` When the latter is generated, the compiler throws with: ``` error: passing 'tyObject_Result__xZhi1m1g75ioXsKjx9bN5bg' (aka 'struct tyObject_Result__xZhi1m1g75ioXsKjx9bN5bg') to parameter of incompatible type 'tyObject_Result__559ckyoL0ZZBsNFIYXjaoeg' (aka 'struct tyObject_Result__559ckyoL0ZZBsNFIYXjaoeg') ``` for ``` proc getInt*(ht: HttpTables, key: string): uint64 = let res = Base10.decode(uint64, ht.getString(key)) if res.isOk(): res.get() # This line may lead to the compiler error above else: 0'u64 ``` By passing the type as a generic param, the `unsigned long long` version gets consistently generated / used regardless of include order. Minimal POC to trigger the bug, from `nimbus-eth2` root: ``` echo 'import beacon_chain/conf, beacon_chain/sync/sync_manager' >x.nim nim c -d:"libp2p_pki_schemes=secp256k1" -r x ``` Swapping include order (`conf` after `sync_manager`) works.
c016512
to
7ae39f9
Compare
Base10.decode
Base10.decode
rebasing should help clear the CI failures here |
is there an upstream bug for this? |
Not yet, I have not found the time to minimize this to a reproducible example. |
@etan-status is this still relevant after the latest |
Yep, just tried it again and it is still broken. From
And no, still couldn't find the time to minimize this example for upstream reporting. |
Calling
Base10.decode
may lead to different structures being generatedfor use with
uint64
.The one normally generated is:
But sometimes, it may be generated as:
When the latter is generated, the compiler throws with:
for
By passing the type as a generic param, the
unsigned long long
versiongets consistently generated / used regardless of include order.
Minimal POC to trigger the bug, from
nimbus-eth2
root:Swapping include order (
conf
aftersync_manager
) works.