[internal] Generate _go_internal_package
targets
#13139
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #13049. This greatly reduces boilerplate and also allows us to make some fields required like
import_path
andsubpath
, so that we don't have to calculate those in consuming rules likebuild_go_pkg.py
.The address format
The generated address looks like
project#./dir
. @tdyas offered that this is intuitive for Go developers because they have to saygo build ./dir
already with the leading./
.This solves how to represent when the
_go_internal_package
is in the same dir as thego_mod
:project#./
.This also makes very clear the difference from external packages like
project#rsc.io/quote
vs. internal packages likeproject#./dir
.Improves dependency inference
Now that the
import_path
field is required for both_go_internal_package
and_go_external_package
, we can create a global mapping ofimport_path -> pkg_target
. This is necessary for #13114.This also improves performance. We don't need to call
ResolvedGoPackage
on all the candidate targets a package might depend on to calculate their import paths. We do still need it when resolving the deps of a particular_go_internal_package
, but we can be lazier when we call that codepath in not evaluating all candidate targets.dependencies
benchmarkAs expected, there is no difference because we are finding the dependencies of everything, so we still have to call
ResolvedGoPackage
. The perf gains are only in things sometimes being less eager, which isn't the case here.Before:
After:
package
benchmarkBefore:
After:
TODO: fix
go_binary
inference ofmain
field#13117 added inference of the
main
field forgo_binary
, that it defaults to thego_package
defined in that directory.But target generation no longer generates targets actually in each directory. All generated targets are "located" in the BUILD file of the
go_mod
, i.e. theirspec_path
is set to that. So it no longer looks toAddressSpecs
like there are any targets in each subdirectory, and there are >1_go_internal_package
targets in thego_mod
dir.Instead, we should use the
subpath
field to determine what directory the targets correspond to.[ci skip-rust]
[ci skip-build-wheels]