-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
cmd/compile: "invalid recursive type" should abort #21273
Comments
I'm not sure I understand this report. The second paste has the usual Can you post a reproducer that actually triggers the behaviour that you found "harder to debug"? |
The full output was: ▶ go build
# github.com/gohugoio/hugo/hugolib
hugolib/menu.go:45: invalid map key type string
hugolib/multilingual.go:34: invalid map key type string
hugolib/page.go:97: invalid map key type string
hugolib/shortcode.go:184: invalid map key type scKey
hugolib/shortcode.go:188: invalid map key type scKey
hugolib/shortcode.go:193: invalid map key type string
hugolib/shortcode.go:196: invalid map key type string
hugolib/shortcode.go:199: invalid map key type string
hugolib/taxonomy.go:23: invalid map key type string
hugolib/taxonomy.go:33: invalid map key type string
hugolib/taxonomy.go:23: too many errors I can update my original description to make it clearer if you want (I chose not to, as that would make your reply look out of place). I can add to this that if this was a type definition deep down in some vendored lib, I would probably never have found it ... |
Thanks for clarifying. It's clear that the current output is not ideal because the fact that the |
Here's a one-file reproducer:
Output:
If you comment one of the
Choosing which errors to print (or to abort in specific places) is not easy, I'm not sure if it's even possible to choose a general policy that will work well in every case. |
Better repro case:
There's no need to tell me T is an invalid map key after telling me it's an invalid anything. |
Likely related, this variation leads to a compiler stack overflow:
(which happens to be #21657) |
Change https://golang.org/cl/75310 mentions this issue: |
https://play.golang.org/p/F3pxiyBuIL
The above fails with
Which is easy to understand and fix. When I recently did a bad "search and replace" in a large code base I ended up with
Which is harder to debug without seeing the origin of the error. It will be easier for me to find the culprit the next time I experience something like this, but I had one hour of scratching my head feeling stupid.
The text was updated successfully, but these errors were encountered: