Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
cmd/go/internal/modload: use (*loadPkg).mod only to indicate the modu…
…le from which the package was loaded The (*loadPkg).mod field normally indicates the module from which the package was loaded. However, if the package was missing, we previously used the mod field to instead store the module from which we intend to load the package next time around. That sort of dual use makes the semantics (and synchronization) of the mod field much more complex to reason about. For example, it would be nice to have the invariant that the mod field is always one of the modules in the overall build list, or one of the modules selected in the overall module graph. Similarly, it would be nice to have the invariant that the version indicated by the mod field can coexist with (without upgrading) all of the other versions indicated in the mod fields of other packages. This repurposing of the mod field appears to be solely in the service of storing the module when resolving missing imports. To keep conceptually-separate fields separate, I have changed resolveMissingImports to store a slice of package–module pairs, instead of just packages that need to be revisited. This may increase allocation pressure slightly if we have many unresolved packages, but most packages are not unresolved, and it seems worth the cost to use a little extra memory if it means we can reason more clearly about the (quite complex) behaviors of the module loader. For #36460 Change-Id: Ic434df0f38185c6e9e892c5e9ba9ff53b3efe01f Reviewed-on: https://go-review.googlesource.com/c/go/+/312930 Trust: Bryan C. Mills <[email protected]> Run-TryBot: Bryan C. Mills <[email protected]> Reviewed-by: Michael Matloob <[email protected]>
- Loading branch information