-
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: impossible to run mkbuiltin.go? #15835
Comments
Yes, I'm aware of the problem: To create the builtin export data, one needs a working compiler. That compiler relies on reading the existing builtin data. If the export format changed, the old format (used for the builtins) cannot be read. The problem always existed, even with the textual format, but the textual format was a bit more "elastic" in the sense that internal node changes didn't necessarily reflect themselves directly in the export data syntax. The new export format is more directly coupled to the node structure (which is why it's shorter and faster), but any node structure changes more immediately affect the export format. The work-around (for now) is to make the importer to read both a prior and a new export format, and the exporter to produce the new (changed) export format. The importer may be told what to do with a temporary flag, or a marker in the export data (version string can be used). The so adjusted compiler can then be used to create a new builtin.go. After that step, the work-around scaffolding can be removed again. Agreed that this is cumbersome. We probably cannot avoid the need to read both an old and a new export format in case of format changes, but it should be possible to provide some internal support to make that step easy. Will document for now. |
There's no reason the builtins have to be imported the way they are. Another option, now that the parser is a bit more sane, would be to just parse the original Go declarations that the export data is currently built from. It would require knowing that you're parsing on behalf of a different package and that "any" is a thing, but the complications should be fairly limited. |
Yes, I thought about that in the beginning as it would be much simpler. But there's still some "compilation" (type-checking, if minimal) involved and I didn't want to touch more than necessary for the switch to the new format. Worthwhile considering for 1.8. |
CL https://golang.org/cl/23443 mentions this issue. |
I tried deleting the OPARAM node type but then I get problems in the compiler reading the binary export data for the builtins. And I can't figure out how to get a working compiler at that point to generate the new binary export data. I will just skip over that value in the enumeration (replacing the name OPARAM with _ in the const listing), but it would be good to document how one does update the binary built-in export data.
The text was updated successfully, but these errors were encountered: