Skip to content
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

go/internal/gcimporter: single source of truth for decoder logic #34564

Open
mdempsky opened this issue Sep 27, 2019 · 3 comments
Open

go/internal/gcimporter: single source of truth for decoder logic #34564

mdempsky opened this issue Sep 27, 2019 · 3 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@mdempsky
Copy link
Member

It's somewhat tedious to have to maintain go/internal/gcimporter in both the standard repo and in x/tools. Can we find a better solution here?

E.g., we vendor a bunch of other x/ repos into the main build. Could we do that for x/tools/go/internal/gcimporter too?

I know go/internal/gcimporter is more aggressive about pruning backwards compatibility code than x/tools/go/internal/gcimporter, but I'd think we could still use the same code base and just either use different entry points into it, or build it in different ways.

/cc @griesemer @alandonovan

@mdempsky mdempsky added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 27, 2019
@mdempsky mdempsky added this to the Unplanned milestone Sep 27, 2019
@mdempsky
Copy link
Member Author

mdempsky commented Sep 27, 2019

Related issue: I submitted 95b8cbf and golang/tools@db0687c, which then broke the x/exp builders because they were using the latest golang/go repo (i.e., which generated iexport v1 data), but an older version of golang/tools (i.e., which only understood iexport v0 data).

/cc @bcmills @ianthehat

@bcmills
Copy link
Contributor

bcmills commented Oct 2, 2019

we vendor a bunch of other x/ repos into the main build. Could we do that for x/tools/go/internal/gcimporter too?

It would need a new import path: the standard library cannot import an internal package from another module.

That said, if the dependencies of gcimporter are self-contained, it seems fine to factor out a module somewhere that the std module could vendor in.

CC @matloob, since I suspect this touches a bit on go/packages.

@ianthehat
Copy link

vendoring does not help with versioning issues though, for instance it does not help with running old tools against newer export data, and also means that it always has to understand all versions that have ever existed.
If we shipped a tool with the distribution that understood the export data, we would not need to maintain compatibility within that tool, it only ever has to understand the current version and translate it to the API format, which would presumably use a less efficient but easier to maintain compatibility form (like JSON)
We could then rewrite the x/tools/go/internal/gcimporter to use the output of that tool instead of reading the file directly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

3 participants