Closed etan-status closed 1 year ago
rebasing should help clear the CI failures here
is there an upstream bug for this?
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 Result
fixes?
Yep, just tried it again and it is still broken.
From nimbus-eth2
repo root:
echo 'import beacon_chain/conf, beacon_chain/sync/sync_manager' >x.nim
nim c -d:"libp2p_pki_schemes=secp256k1" -r x
/Users/etan/Documents/Repos/nimbus-eth2/vendor/nim-chronos/chronos/apps/http/httptable.nim:82:73: error: passing 'tyObject_Result__wclb9c9bJbd6rJAwn3uS2nPg' (aka 'struct tyObject_Result__wclb9c9bJbd6rJAwn3uS2nPg') to parameter of incompatible type 'tyObject_Result__v9aWRrNLc0mAO9a315N8TSpA' (aka 'struct tyObject_Result__v9aWRrNLc0mAO9a315N8TSpA')
result = value__vendorZnim45chronosZchronosZappsZhttpZhttpserver_1477(res); }
^~~
/Users/etan/Documents/Repos/nimbus-eth2/vendor/nim-results/results.nim:796:127: note: passing argument to parameter 'self' here
static N_INLINE(NU64, value__vendorZnim45chronosZchronosZappsZhttpZhttpserver_1477)(tyObject_Result__v9aWRrNLc0mAO9a315N8TSpA self) {
^
1 error generated.
And no, still couldn't find the time to minimize this example for upstream reporting.
Calling
Base10.decode
may lead to different structures being generated for use withuint64
.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
version gets consistently generated / used regardless of include order.Minimal POC to trigger the bug, from
nimbus-eth2
root:Swapping include order (
conf
aftersync_manager
) works.