Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
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') ``` By passing the type as a generic param, the `unsigned long long` version gets consistently generated / used. Observed this in Chronos httptable.nim during nimbus light client work. ``` 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 ``` Maybe it depends on include order, because in the nimbus_beacon_chain binary there is no issue, only in nimbus_light_client.
- Loading branch information