commit | c8a731972177c6ce4073699c705e55918ee7be09 | [log] [tgz] |
---|---|---|
author | Sam Thanawalla <samthanawalla@google.com> | Wed Oct 09 20:29:36 2024 +0000 |
committer | Sam Thanawalla <samthanawalla@google.com> | Thu Oct 10 17:04:46 2024 +0000 |
tree | bbfae843ae4de2bdc8d04e87679d2d5d6fcfbe59 | |
parent | 9cd0e4c9f675aeac595a4cbb5ba1b46798ce0fdf [diff] |
x/mod: fix handling of vendored packages with '/vendor' in non-top-level paths This CL address a bug in the handling of vendored packages where the '/vendor' element appears in non-top level import paths within a module zip file. This issue arose from an incorrect offset calculation that caused non-vendored packages to be incorrectly identified as vendored. This CL corrects the offset calculation for Go 1.24 and beyond. Fixes golang/go#37397 Change-Id: Ibf1751057e8383c7b82f1622674204597e735b7c Reviewed-on: https://go-review.googlesource.com/c/mod/+/619175 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Matloob <matloob@golang.org>
This repository holds packages for writing tools that work directly with Go module mechanics. That is, it is for direct manipulation of Go modules themselves.
It is NOT about supporting general development tools that need to do things like load packages in module mode. That use case, where modules are incidental rather than the focus, should remain in x/tools, specifically x/tools/go/packages.
The specific case of loading packages should still be done by invoking the go command, which remains the single point of truth for package loading algorithms.