Related: #27999.
cc: @stamblerre

Assuming we can do this, setting milestone to 1.15 so we can do this in sync with the std/lib change.

I assume we're not in a hurry to do this before the freeze, given that the code is in another repository? The early-in-cycle label is confusing me a bit, since the corresponding standard library change was merged some weeks ago.

It should be safe to remove since the code is presumably not in use anymore, but I defer to @stamblerre who knows better which code is is use now. There's no rush, but at the same time we've been schlepping this code around for a few years now. It would be nice to get rid of it.

Change https://golang.org/cl/229987 mentions this issue: go/internal/gcimporter: remove support for binary export data

I agree, it should be safe to delete. Just mailed a CL to do it.

@heschik notes that this will break any tool relying on export data for older versions of Go. We only maintain tools for the current and previous versions of Go (1.14 and 1.13, right now), so we wouldn't be breaking any guarantees. However, we may still get some complaints. I will merge this CL, but if enough people file issues, we may have to roll it back.