Unfortunately, this does come with a ~4x slowdown to Wire, as it is
now pulling source for all transitively depended packages, but not
trimming comments or function bodies. This is due to limitations with
the ParseFile callback in go/packages.
This comes with a single semantic change: when performing analysis, Wire
will now evaluate everything with the wireinject build tag. I updated
the build tags tests accordingly. Prior to this PR, only the packages
directly named by the package patterns would be evaluated with the
wireinject build tag. Dependencies would not have the wireinject build
tag applied. There isn't a way to selectively apply build tags in go/packages,
and there isn't a clear benefit to applying it selectively. Being consistent with
other Go tooling provides greater benefit.
I deleted the vendoring test, as non-top-level vendoring
becomes obsolete with modules.
go/packages now parses comments by default, so now the generated code
includes comments for non-injector declarations.
Fixesgoogle/go-cloud#78
The primary motivation is to permit a move to using go/packages instead
of go/loader. go/packages runs exclusively by shelling out to the go
tool, which precludes use of the in-memory "magic" GOPATH being used
up to this point.
This has a secondary effect of removing a lot of code to support "magic"
GOPATH from the test infrastructure. This is on the whole good, but
necessitated a change in the error scrubbing: since the filenames are
no longer fixed, error scrubbing also must remove the leading
$GOPATH/src lines.
Another related change: since all callers of Generate needed to know the
package path in order to write out wire_gen.go (necessitating a
find-only import search) and Generate already has this information,
Generate now returns this information to the caller. This should further
reduce callers' coupling to Wire's load internals. It also eliminates
code duplication.
This should hopefully shake out any difference in path separators for
running on Windows, but I have not tested that yet.
Updates google/go-cloud#78
Updates google/go-cloud#323
Update Provider.Out to be a slice of provided types, and keep track
of the provided concrete type in ProviderSet.providerMap, to more
clearly model-named struct providers (which provide both the struct
type and a pointer to the struct type).
Fixesgoogle/go-cloud#325.
* Add wire.InterfaceValue, required instead of wire.Value if the value is an interface value.
* Update guestbook sample to use InterfaceValue where appropriate.
* Remove unnecessary ok := true
* Addressing comments from code review.
In the internal package, this expands the wire.Load function to run
the same solver as wire.Generate would on any injector function. For
completeness, I also print the injector functions in the gowire show
command.
A subsequent PR will add this as a step to Go Cloud CI.
Updates google/go-cloud#30
This changes both Generate and Load to try to advance as far as possible
while collecting errors. A small helper type, errorCollector, is used to
make control flow easier to read.
Fixesgoogle/go-cloud#5
This represents no functional change, it purely changes the signature
used for functions that can possibly return multiple errors. A
follow-up commit will change the control flow to proceed in the face
of errors.
5cfd0141dd95acd1a98a1b7f6de5b8b304077634 worked correctly with
absolute import paths, but would fail with relative import paths
(most commonly when passing "." in the default invocation of
gowire). This commit introduces test infrastructure to allow
relative import paths to be given as test inputs, along with a test
case that addresses the regression.
This was introduced in 7d83fb8532c1455d4e81b587f31d090320f5eb9f and is
surprisingly not caught by the race detector. I suspect that the testing
package makes it not a strict data race, but the result is still
undefined.
out.txts that start with "ERROR" can now include substrings to assert
exist in the error messages, one per line. This gives a very
coarse-grained way of testing for error message quality. It is not a
substitute for manual verification, but gives a "good enough" sanity
check that relevant details are reported.
Updates google/go-cloud#5
Primary reason is to make it easier to allow the process to continue and
collect errors. This has the side-effect of allowing larger depth graphs
since the solver no longer pushes Go stack frames.
Updates google/go-cloud#5
