-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
x/mod/modfile: IsDirectoryPath produces a false negative on some short clean directory paths #60572
Comments
Change https://go.dev/cl/500335 mentions this issue: |
Change https://go.dev/cl/500355 mentions this issue: |
Change https://go.dev/cl/501016 mentions this issue: |
Writing down the compatibility notes for this bug fix. There are known callers of IsDirectoryPath in x/mod itself and in cmd/go in the main repo, which is what I considered in scope below. For other possible callers, this is fixing a small edge case in the intended behavior (and documenting the actual behavior more accurately than before). CompatibilityFixing this bug doesn't change the meaning of any existing go.mod or go.work files. It makes it possible to explicitly start using relative paths as directory paths that were previously rejected, both in replace directives (in go.mod and go.work files) and in use directives (in go.work files). Doing that can only work in a Go toolchain that has the bug fix. So modules that wish to keep supporting older Go versions would need to wait before they start using the new directory paths. (CI testing with supported toolchains, e.g., see this change failing on Go 1.20.x and 1.19.x, is one of the ways users can know to avoid unintentionally breaking compatibility.) The The There's no effect on dependency modules because replace directives in go.mod files are ignored when a module is not main module. So even if a new version of a dependency module chooses to start using new directory paths sooner, all existing Go toolchains will not be affected when using that module as a dependency. (This is similar to how currently checking in a replace directive containing a Windows-style So to me this seems like a backward compatible minor bug fix that doesn't need special treatment (i.e., teaching all supported Go versions to understand but not yet permit the new directory paths) to be rolled out. |
An error text suggests a directory path needs to start with ./ or ../ if it's a relative path, but in reality relative paths with .\ and ..\ prefix (such as those that are used on Windows) are also accepted. Furthermore, a relative path like ./ or ../ is fine, as are ./. and ../., but the cleaner and shorter equivalent relative paths . and .. are reported as if they're not directory paths (even though a module path cannot consist of nothing but dots). Fix those inconsistencies and make IsDirectoryPath report true on "." and ".." paths as expected, and make its documentation clear that a path like "sub/dir", despite being a relative path, is interpreted as a module path. For golang/go#60572. Change-Id: I8fa4a2c66bc83a1ccafc453b96f3bb33dc222cd1 Reviewed-on: https://go-review.googlesource.com/c/mod/+/500335 Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Bryan Mills <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]> Run-TryBot: Dmitri Shuralyov <[email protected]> TryBot-Result: Gopher Robot <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
In #51448 (comment), Bryan wrote:
The Go 1.18 condition change happened in CL 389298. This is the tracking issue for the bug in
modfile.IsDirectoryPath
that we can still fix in Go 1.22 or later. (Or even in Go 1.21 if this bug fix is considered okay in the current pre-RC1 phase of the release freeze.)I'll send a CL.
CC @bcmills, @matloob.
The text was updated successfully, but these errors were encountered: