-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
cmd/go: support overlays in the go command #39958
Comments
/cc @matloob @jayconrod @bcmills per owners. |
I'd really like for this to happen. We'll have to find out not only how to propagate the overlaid file contents through cmd/go, but also to the compiler... |
@matloob: should this be added to the 1.16 milestone now? |
yes. done. |
Change https://golang.org/cl/253747 mentions this issue: |
Change https://golang.org/cl/257198 mentions this issue: |
This CL adds basic support for listing packages with overlays. The new cmd/go/internal/fs package adds an abstraction for communicating with the file system that will open files according to their overlaid paths, and provides functions to override those in the build context to open overlaid files. There is also some support for executing builds on packages with overlays. In cmd/go/internal/work.(*Builder).build, paths are mapped to their overlaid paths before they are given as arguments to tools. For #39958 Change-Id: I5ec0eb9ebbca303e2f1e7dbe22ec32613bc1fd17 Reviewed-on: https://go-review.googlesource.com/c/go/+/253747 Trust: Michael Matloob <matloob@golang.org> Trust: Jay Conrod <jayconrod@google.com> Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
To provide some more detail on how this will show up in the cmd/go interface, we'll add a
All entries in the replace map correspond to a single file that is specified to exist in the filesystem with the path of the file given by the key and and the contents of the file given by the contents of the file with the path given by the value. The case where a value for a given key is empty means that If the directory of a file path in the key doesn't exist then the cmd/go will implicitly consider that directory and its (potentially nonexistent) parent directories to exist in the overlay filesystem. If |
Change https://golang.org/cl/262617 mentions this issue: |
Change https://golang.org/cl/262618 mentions this issue: |
Pass the trimpath flag to cmd/compile to use the correct file paths for files that are overlaid: that is, the "destination" path in the overlay's Replace mapping rather than the "source" path. Also fix paths to go source files provided to the gccgo compiler. For #39958 Change-Id: I3741aeb2272bd0d5aa32cb28133b61e58264fd39 Reviewed-on: https://go-review.googlesource.com/c/go/+/257198 Trust: Michael Matloob <matloob@golang.org> Trust: Bryan C. Mills <bcmills@google.com> Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Change https://golang.org/cl/263737 mentions this issue: |
The main missing piece here was supporting Stat in the overlay filesystem, in the parts of the package code that determines whether an command line argument is a file on disk or a directory. so this change adds a Stat function to the fsys package. It's implemented the same way as the already existing fsys.lstat function, but instead of os.Lstat, it calls os.Stat on disk files. Then, the change changes parts of the package code to use the overlay Stat instead of the os package's Stat. For #39958 Change-Id: I8e478ae386f05b48d7dd71bd7e47584f090623df Reviewed-on: https://go-review.googlesource.com/c/go/+/262617 Trust: Michael Matloob <matloob@golang.org> Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
Change https://golang.org/cl/264478 mentions this issue: |
To support overlays For #39958 Change-Id: I5ffd72aeb7f5f30f6c60f6334a01a0a1383c7945 Reviewed-on: https://go-review.googlesource.com/c/go/+/264478 Trust: Michael Matloob <matloob@golang.org> Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
Change https://golang.org/cl/265758 mentions this issue: |
Change https://golang.org/cl/266358 mentions this issue: |
Change https://golang.org/cl/266376 mentions this issue: |
Change https://golang.org/cl/266417 mentions this issue: |
Change https://golang.org/cl/266720 mentions this issue: |
Change https://golang.org/cl/266797 mentions this issue: |
cmd/cgo now has a -trimpath flag that behaves the same as the -trimpath flag to cmd/compile. This will be used to correct paths to cgo files that are overlaid. The code that processes trimpath in internal/objapi has been slightly refactored because it's currently only accessible via AbsFile, which does some additional processing to the path names. Now an ApplyRewrites function is exported that just applies the trimpath rewrites. Also remove unused srcfile argument to cmd/cgo.(*Package).godefs. For #39958 Change-Id: I497d48d0bc2fe1f6ab2b5835cbe79f15b839ee59 Reviewed-on: https://go-review.googlesource.com/c/go/+/266358 Trust: Michael Matloob <matloob@golang.org> Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
This requires rewriting the paths of the files passed to the cgo tool toolchain to use the overlaid paths instead of the disk paths of files. Because the directories of the overlaid paths don't exist in general, the cgo tool have been updated to run in base.Cwd instead of the package directory. For #39958 Change-Id: I8986de889f56ecc2e64fa69f5f6f29fa907408f9 Reviewed-on: https://go-review.googlesource.com/c/go/+/262618 Trust: Michael Matloob <matloob@golang.org> Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Change https://golang.org/cl/267197 mentions this issue: |
This is a roll-forward of golang.org/cl/262618, which was reverted in golang.org/cl/267037. The only differences between this CL and the original are the three calls to fflush from the C files in build_overlay.txt, to guarantee that the string we're expecting is actually written out. This requires rewriting the paths of the files passed to the cgo tool toolchain to use the overlaid paths instead of the disk paths of files. Because the directories of the overlaid paths don't exist in general, the cgo tool have been updated to run in base.Cwd instead of the package directory. For #39958 Change-Id: If7e5e057c62c0c22ddb724f9fe650902fc5f4832 Reviewed-on: https://go-review.googlesource.com/c/go/+/267197 Reviewed-by: Bryan C. Mills <bcmills@google.com> Trust: Michael Matloob <matloob@golang.org>
Change https://golang.org/cl/267797 mentions this issue: |
Change https://golang.org/cl/267877 mentions this issue: |
Test script expects the regexp argument for stdout, stderr, and cmp to be the first argument after the command, but that might not be the case if the -q or -count flags are provided. Treat the first argument after a flag as a regexp instead. For #39958 Change-Id: I369926109ec10cca8b2c3baca27e7a3f7baf364b Reviewed-on: https://go-review.googlesource.com/c/go/+/267877 Trust: Michael Matloob <matloob@golang.org> Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
This is a roll-forward of golang.org/cl/267197, which was reverted in golang.org/cl/267357. It makes the following changes in addition to the ones in the next paragraph: It avoids outputting trimpath arguments for an overlay unless the overlay affects the package being compiled (to avoid hitting windows command line argument limits), and it fixes processing of regexps in the script test framework to treat the first *non flag* argument to grep, stdout, and stderr as a regexp, not just the first argument. golang.org/cl/267917 was a roll-forward of golang.org/cl/262618, which was reverted in golang.org/cl/267037. The only differences between this CL and the original were the three calls to fflush from the C files in build_overlay.txt, to guarantee that the string we were expecting was actually written out. The CL requires rewriting the paths of the files passed to the cgo tool toolchain to use the overlaid paths instead of the disk paths of files. Because the directories of the overlaid paths don't exist in general, the cgo tool have been updated to run in base.Cwd instead of the package directory. For #39958 Change-Id: I1bd96db257564bcfd95b3502aeca14d04bd28618 Reviewed-on: https://go-review.googlesource.com/c/go/+/267797 Trust: Michael Matloob <matloob@golang.org> Trust: Bryan C. Mills <bcmills@google.com> Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
The previous cl (golang.org/cl/262618) copied non-overlaid cgo files to objdir, mostly to get around the issue that otherwise cgo-generated files were written out with the wrong names (they'd get the base path of the overlay file containing the replaced contents, instead of the base path of the path whose contents are being replaced). So that CL it would copy the files to objdir with the base path of the file being replaced to circumvent that. This CL changes cmd/go and cmd/cgo so that instead of copying files, it passes the actual path of the file on disk either of the original file (if it is not overlaid) or its replacement file (if it is) as well as a flag --path_rewrite, newly added to cmd/cgo, that specifies the actual original file path that corresponds to the replaced files. Updates #39958 Change-Id: Ic4aae5ef77fe405011fcdce7f6c162488d13daa2 Reviewed-on: https://go-review.googlesource.com/c/go/+/265758 Trust: Michael Matloob <matloob@golang.org> Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Change https://golang.org/cl/269017 mentions this issue: |
This cl is a roll-forward of golang.org/cl/265758, which was rolled back in golang.org/cl/268900. The changes made are removing cgofiles from the list of files that are copied to objdir (because the cgofiles themselves aren't actually provided to the compiler) and fixing test cases to properly provide the overlay flag and to allow for paths with backslashes (as in Windows). The previous cl (golang.org/cl/262618) copied non-overlaid cgo files to objdir, mostly to get around the issue that otherwise cgo-generated files were written out with the wrong names (they'd get the base path of the overlay file containing the replaced contents, instead of the base path of the path whose contents are being replaced). So that CL it would copy the files to objdir with the base path of the file being replaced to circumvent that. This CL changes cmd/go and cmd/cgo so that instead of copying files, it passes the actual path of the file on disk either of the original file (if it is not overlaid) or its replacement file (if it is) as well as a flag --path_rewrite, newly added to cmd/cgo, that specifies the actual original file path that corresponds to the replaced files. Updates #39958 Change-Id: Ia45b022f9d27cfce0f9ec6da5f3a9f53654c67b8 Reviewed-on: https://go-review.googlesource.com/c/go/+/269017 Trust: Michael Matloob <matloob@golang.org> Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
This change moves the code in work.(*Builder).cgo that, when there is an overlay, copies non-Go files to objdir into work.(*Builder).Build, and creates an overlay structure mapping from the nominal file paths into the copies in objdir. That's propagated through to work.(*Builder).ccompile, which will use it to pass in the path to the overlaid contents in objdir when calling the compiler. This allows for overlays of C/C++/Fortran files. For #39958 Change-Id: I9a2e3d3ba6afdf7ce19be1dbf4eee34805cdc05f Reviewed-on: https://go-review.googlesource.com/c/go/+/266376 Trust: Michael Matloob <matloob@golang.org> Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
This change adds support for adding overlays on assembly files. For #39958 Change-Id: I1a328656199cc836f48e16de1ffd944fdd07fb39 Reviewed-on: https://go-review.googlesource.com/c/go/+/266417 Trust: Michael Matloob <matloob@golang.org> Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
When caching actions, use the overlaid file contents, because those are the ones actually used to produce the outputs. For #39958 Change-Id: Ia1f85b2fcf1f26e3b5be82f4d35c2726b134a36b Reviewed-on: https://go-review.googlesource.com/c/go/+/266720 Trust: Michael Matloob <matloob@golang.org> Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
This change updates the lockedfile package to open files using the new fsys.OpenFile function. The logic of fsys.Open has been moved into fsys.OpenFile, and fsys.Open is now just a light wrapper around it. For #39958 Change-Id: I552f1a45ac00ac06b5812008d17a61e610b4b113 Reviewed-on: https://go-review.googlesource.com/c/go/+/266797 Trust: Michael Matloob <matloob@golang.org> Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Change https://golang.org/cl/272126 mentions this issue: |
Move the declaration of the -overlay flag to base.AddModCommonFlags, where other flags that are needed for go mod commands and for builds are declared. The flag's already initialized in modload.Init so there's no additional work needed to be done to support it in the go mod commands. For #39958 Change-Id: I70725d620cc69cb820f6ed923d626f4fe041b1c5 Reviewed-on: https://go-review.googlesource.com/c/go/+/272126 Trust: Michael Matloob <matloob@golang.org> Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
Change https://golang.org/cl/274714 mentions this issue: |
I hope that this feature will not be released in its current state with Go 1.16. |
The documentation for the
It isn't clear to me what means "overlays will not appear". And is it only related to cgo files? |
I'll try to update the docs, but essentially, when using go run and go test, if the running binary tries to open files, the overlay will not affect the presence of files or their contents. |
Change https://golang.org/cl/292710 mentions this issue: |
This has been discussed fairly often, but I figured it was worth filing an issue for tracking purposes.
Many tools,
gopls
in particular, work on unsaved files. As a result, tools like go/packages support overlays, which can replace file contents or represent entirely new files. The overlay logic forgo list
in go/packages is complex and error-prone, as it effectively needs to recreate the behavior ofgo list
. It is a constant source ofgopls
bugs, many of which (#39646 for a recent example) manifest in seemingly unrelated ways. Supporting overlays natively in thego
command would eliminate all of this complicated logic and this source of errors.The text was updated successfully, but these errors were encountered: