"Error: internal error: genRecordFieldAux" - in the "version-1-4" branch #16069
Comments
|
@stefantalpalaru please minimize, ideally should not contain any imports since it's a compiler bug. (and try on latest devel + show its hash) it's more work for you but less work for everyone else reading this bug :-) |
|
I don't know if it can be minimised. The problem might appear only when some internal compiler buffer is filled. This, for example, does not exhibit the bug: |
|
Here's Nim devel: |
of course it can, this is how most bugs are approached; but it sometimes takes a bit of effort, whether from you or for the N people who will look at it, but you known your code better than the person looking at it. Think about it from perspective of the person looking at your bug report, wondering whether running some large test from a repo is gonna potentially create havoc on his system, overwrite some files etc. Your repo has monster dependencies, and your bug report comes with almost no install/repro instructions.
=> at very least this should be a simiplified to a nim command
I don't think this is the problem: proc genRecordFieldAux(p: BProc, e: PNode, d, a: var TLoc) =
initLocExpr(p, e[0], a)
if e[1].kind != nkSym: internalError(p.config, e.info, "genRecordFieldAux")
d.inheritLocation(a)
discard getTypeDesc(p.module, a.t) # fill the record's fields.lochere are ways to improve this bug report:
import astalgo
...
debug(e)
echo e[1].kind
func fromHex*[N](A: type array[N, byte], hexStr: string): A
{.raises: [ValueError, Defect], noInit, inline.}=
## Read an hex string and store it in a byte array. No "endianness" reordering is done.
hexToByteArray(hexStr, result) |
Not on my watch. Everything stays inside the project directory.
Is the largest Nim codebase such a mystery to you?
All confined to the project's "vendor" directory. And do yourself a favour by running
Maybe you missed the part where running the relevant test suite ("tests/test_byteutils.nim") in the "nim-stew" repo does not exhibit the bug? Why would anything smaller than that be buggy? Anyway, the bug also appears in the "version-1-2" branch, where I had to do the ugliest manual bisection ever, because most commits were failing somewhere else and needed 7bba0de reverted to get past that. Here's the culprit: 9599d95ca Can you guys manage from here? |
I already have And with both Nim 1.4.1 and devel all the test suites and tests run successfully, without any error reported. |
Now run |
|
Upon further investigation, the original https://github.com/status-im/nimbus (which is set up as remote on my machine) now points to https://github.com/status-im/nimbus-eth1, but you have tested with https://github.com/status-im/nimbus-eth2 (notice the |
* fixes #16069; refs nim-lang/RFCs#257 [backport:1.2] [backport:1.4] * make tests green again (cherry picked from commit d306a04)
* fixes nim-lang#16069; refs nim-lang/RFCs#257 [backport:1.2] [backport:1.4] * make tests green again
* fixes #16069; refs nim-lang/RFCs#257 [backport:1.2] [backport:1.4] * make tests green again (cherry picked from commit d306a04)
* fixes nim-lang#16069; refs nim-lang/RFCs#257 [backport:1.2] [backport:1.4] * make tests green again
* fixes nim-lang#16069; refs nim-lang/RFCs#257 [backport:1.2] [backport:1.4] * make tests green again
setup
https://github.com/status-im/nimbus-eth2/tree/1d7fb2ed0c78debc3f9c49ae962e627d115d55fc
https://github.com/nim-lang/Nim/tree/577b4f795cfb5dcc387dbb5a3751b4c1eec42a66
problem
The text was updated successfully, but these errors were encountered: