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
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.
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.
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
Idea originally mentioned in google/go-cloud#29. This means that any provider set
loaded must not have cycles, which is stricter than before. The cycle
error message now gives full detail on what caused the cycle.
One small breaking change: a provider set can no longer include an
interface binding to a concrete type that is not being provided
(directly or indirectly) by the provider set. I can't imagine a
reasonable use case for the previous behavior, so this likely will
catch more errors
In terms of operation, binding conflict error messages will now give
much more specific line numbers, since they will be reported closer to
where the problem occurred.
Now that provider sets gather this information, it can be exposed in
the package API. gowire now uses this information instead of
trying to build it itself.
Fixesgoogle/go-cloud#29
