go/internal/gcimporter: detect and gracefully fail on old versions #16881
Comments
|
The new export format does recognize old versions and does try to work gracefully around them. Many of the prior issues had to do with the transition from textual to binary format. The textual format had no versioning, and the binary format was in development, with people using mixes of the two, and sometimes even mixes of two different binary formats. The "gracefully working around issues" was done only partially (in x/tools/gcimporter) as I (wrongly) assumed that people would always re-build when working at tip (we don't guarantee anything across different compilers). That's obviously not the case. The trivial solution is to bail with an explicit error requesting recompiles - at least when working at tip. It's a bit more complicated than that because x/tools/gcimporter15 also needs to work on tip but also legacy installed packages. On it. |
|
CL https://golang.org/cl/27814 mentions this issue. |
Import errors due to unexpected format are virtually always due to version skew. Don't panic but report a good error message (incl. hint that the imported package needs to be reinstalled) if not in debugFormat mode. Recognize export data format version and store it so it can be used to automatically handle minor version differences. We did this before, but not very well. No export data format changes. Manually tested with corrupted export data. For #16881. Change-Id: I53ba98ef747b1c81033a914bb61ee52991f35a90 Reviewed-on: https://go-review.googlesource.com/27814 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
CL https://golang.org/cl/27816 mentions this issue. |
|
CL https://golang.org/cl/27912 mentions this issue. |
The Go1.7 export format didn't encode the field package for blank struct fields (#15514). Re-introduce support for that format so we can read it w/o error. For #16881. Change-Id: Ib131d41aac56dbf970aab15ae7e75ef3944b412d Reviewed-on: https://go-review.googlesource.com/27912 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
gcimporter does not fail gracefully when it encounters old versions. This trips up a lot of people--they think it's a bug, and do not think to re-install the relevant packages (why would they?). Related bugs: #16879 and #16859 and #16112 and #15728 and #16826 and #16781 and lots more. I think at this point some kind of fix, even a kludgy one, is called for.
The best case scenario, to my mind, is that importers just work (#10276). Failing that, gcimporter should treat the input package as potentially hostile (i.e. as user input) and on error, suggest a package re-install. Failing that, gcimporter should explicitly check for and recognize known prior versions and suggest a package re-install.
The text was updated successfully, but these errors were encountered: