| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 191861074
|
|
|
|
|
|
|
|
|
| |
These have all had a chance to be categorized with the OptionDocumentationCategory enum, and the help output already uses the enum-grouped format.
The "incompatible changes" category has meaning for --all_incompatible_changes and will be removed separately.
RELNOTES: None.
PiperOrigin-RevId: 190773778
|
|
|
|
|
|
| |
ConfiguredTarget#getConfiguration(). Add convenience methods in four Java test classes for use by refactoring tools to do this#getConfiguration(ConfiguredTarget) instead of ConfiguredTarget#getConfiguration.
PiperOrigin-RevId: 190684008
|
|
|
|
|
|
|
|
| |
methods, TransitiveInfoCollection#getConfigurationKey() and ConfiguredTarget#getConfigurationChecksum(). These methods currently delegate to #getConfiguration(), but in the future they won't. I hope to get rid of #getConfigurationChecksum(), but I may have to fold the checksum into BuildConfigurationValue.Key or leave it as a separate field in ConfiguredTarget.
Transform a representative (random?) selection of #getConfiguration calls, to show that it's pretty much possible everywhere.
PiperOrigin-RevId: 190474978
|
|
|
|
|
|
| |
from the provided defaults in Options classes. These are used to create BuildOptionsDiffForReconstruction, which lets us store only the diffs in our BuildConfigurationValue.Keys.
PiperOrigin-RevId: 190117455
|
|
|
|
|
|
| |
rename some methods that were still called ConfiguredTargetAndTarget. Move some tests over to using ConfiguredTargetAndData instead of calling ConfiguredTarget#getConfiguration() directly.
PiperOrigin-RevId: 189642264
|
|
|
|
|
|
| |
labels instead of the entire toolchain context since that's all the dependency resolver really needs. This will help make cquery transitions outputter easier to implement.
PiperOrigin-RevId: 189342812
|
|
|
|
|
|
|
| |
This change ensures that there is no duplicate aspect in AnalysisResult.
RELNOTES: None
PiperOrigin-RevId: 189086095
|
|
|
|
|
|
| |
ConfiguredTargetAndData. We want to get BuildConfiguration out of ConfiguredTarget because it uses >800K when serialized.
PiperOrigin-RevId: 188600002
|
|
|
|
|
|
| |
RELNOTES:
Removed flag `--incompatible_load_argument_is_label`.
PiperOrigin-RevId: 187479614
|
|
|
|
|
|
|
| |
them with getConfiguredTargetAndTarget() so we can get rid of
ConfiguredTarget.getTarget() callers. This should be a test only change.
PiperOrigin-RevId: 184877255
|
|
|
|
| |
PiperOrigin-RevId: 183859414
|
|
|
|
| |
PiperOrigin-RevId: 183826311
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the need for ConfigurationTransitionProxy.DATA by providing a
way for the C++ rule defs to directly inject the transition for all rules
to use.
Skylark attributes work differently, so they'll be addressed in another
change.
PiperOrigin-RevId: 183721293
|
|
|
|
|
|
| |
getting Target from the SkyframeExecutor's PackageManager.
PiperOrigin-RevId: 183710251
|
|
|
|
|
|
|
| |
This option has no effect, so don't give documentation readers false hope.
Change-Id: Ibbc0d2f62375fd146fedaa113a39027bd7d65d6c
PiperOrigin-RevId: 183240947
|
|
|
|
|
|
|
|
| |
BuildConfiguration.Fragment>> set of Fragment classes that is part of the BuildConfigurationValue.Key. This class allows us to compute a fingerprint of the wrapped ImmutableSortedSet, making equality comparisons fast. The number of additional wrapper objects is the number of distinct sets of fragment classes, so 1. (In fact, we don't even need to compute a fingerprint, since reference equality does the job for us here, but we do it just to be conservative.)
This CL has a performance benefit for Bazel currently, but has a bigger performance benefit in the following changes, where there are more BuildConfigurationValue.Key objects to compare.
PiperOrigin-RevId: 183090122
|
|
|
|
|
|
|
|
| |
ImmutableSortedSet wherever possible, and use a known explicit ImmutableSortedSet in the case of two sets being equal. This is mainly a cosmetic cleanup for the sequel changes.
Also rename test-only methods in SkyframeExecutor to indicate that, and do a drive-by clean-up of a test that reported hard crashes confusingly because it wrapped RuntimeExceptions.
PiperOrigin-RevId: 182984572
|
|
|
|
|
|
|
|
| |
BaseRuleClasses.DYNAMIC_TRANSITION_MAP.
This leaves DATA as the last remaining legacy transition.
PiperOrigin-RevId: 182422552
|
|
|
|
|
|
|
|
|
|
|
|
| |
container, ConfiguredTargetAndTarget, that can be used to access Targets, and deprecate ConfiguredTarget#getTarget. ConfiguredAndTargetObjects are intended to be limited in scope, not being persisted to Skyframe.
The eventual plan is to remove the target field from ConfiguredTarget.
This CL is mostly straightforward, except for dealing with AliasConfiguredTargets, which cause some complications.
A significant cleanup is still needed before #getTarget can be removed, but I don't see any impossible blockers. We will may still need to store a Target-like object in ConfiguredTarget (that has the RuleClass, or at least a string representation of it, for instance), but that will let us avoid storing a full Target together with its associated Package.
PiperOrigin-RevId: 182371566
|
|
|
|
|
|
| |
removing the layer of indirection of getting SkyKey out of ActionLookupKey, which uses more memory for no reason.
PiperOrigin-RevId: 181658615
|
|
|
|
|
|
|
| |
HostTransition can't be migrated yet because it depends on
BuildConfiguration.
PiperOrigin-RevId: 180842784
|
|
|
|
|
|
| |
conveniently also makes it unnecessary to pass the entire LoadingResult when doing configured queries post analysis.
PiperOrigin-RevId: 180676481
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
config.transitions.ConfigurationTransitionProxy.
The "proxy" part is to dissuade people from writing:
void myfunc(ConfigurationTransition transition)
signatures casually.
Maybe that's actually a better name than "Transition". But I'd rather
rename Transition to ConfigurationTransition in its own change if we
want to do that.
PiperOrigin-RevId: 180285321
|
|
|
|
| |
PiperOrigin-RevId: 179936355
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 179838936
|
|
|
|
|
|
|
|
|
|
|
| |
If an aspect is applied to a rule+aspect node, all attributes are merged
into ctx.rule.attr collection, and the first one with the same name wins
(in particular, rule attribute will always win over aspect attribute).
This is backwards-compatible, and unlikely to cause problems in
practice.
RELNOTES: Aspects-on-aspect see and propagate over aspect attributes.
PiperOrigin-RevId: 179675660
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 179468685
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 179046403
|
|
|
|
|
|
|
| |
1: Allow both in the same build (before, just one would trigger)
2: Don't check environment defaults from other groups, since neither
flag asserts any expectations on those groups
PiperOrigin-RevId: 178026699
|
|
|
|
|
|
|
| |
This key context can be used by actions to share partial key computations, for instance when computing MD5s for nested sets.
RELNOTES: None
PiperOrigin-RevId: 177359607
|
|
|
|
| |
PiperOrigin-RevId: 175832159
|
|
|
|
|
|
|
|
| |
Blaze had its own class to avoid GC from varargs array creation for the precondition happy path. Guava now (mostly) implements these, making it unnecessary to maintain our own.
This change was almost entirely automated by search-and-replace. A few BUILD files needed fixing up since I removed an export of preconditions from lib:util, which was all done by add_deps. There was one incorrect usage of Preconditions that was caught by error prone (which checks Guava's version of Preconditions) that I had to change manually.
PiperOrigin-RevId: 175033526
|
|
|
|
|
|
| |
accurate results. Some refactoring done to get custom query code out of BuildView and into resolvers.
PiperOrigin-RevId: 172647838
|
|
|
|
|
|
| |
or no edges. Also add option to disable checks in MemoizingEvaluatorTest that don't make sense for implementations that don't keep track of dirty nodes. Also extract RecordingDifferencer to an interface. And add a test for the situation that a node changes during a build that it's not requested, and which fails, necessitating cleanup.
PiperOrigin-RevId: 171616817
|
|
|
|
|
|
| |
symlink directly to the target artifact. Also offer the option to not provide the package roots to create the execroot: we would like to avoid the execroot if possible.
PiperOrigin-RevId: 170515263
|
|
|
|
| |
PiperOrigin-RevId: 170503143
|
|
|
|
|
|
|
|
|
|
|
|
| |
precomputed value. Instead, manually check if the value has changed, and if it has, invalidate its consuming WorkspaceStatusValue node, forcing its re-evaluation, where it will pick up the new value.
This seems more awkward than the original code, but it is more correct in spirit: injecting a precomputed value which can change even while the source state does not is a smell. Long-term, the key for the WorkspaceStatusValue should incorporate a hash of the action, and that hash should be in the configuration, just as other configuration flags are. That isn't possible right now just because we don't have configuration trimming, and we drop all nodes on configuration changes, so putting workspace status options into the configuration would lose change pruning whenever we changed workspace status options.
If/when those problems are fixed, we can extend this change to have WorkspaceStatusFunction continue to request the action out-of-band, but keyed by the hash. Then we can stop invalidating stale nodes.
See also https://github.com/bazelbuild/bazel/issues/3785.
PiperOrigin-RevId: 169947071
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 169258065
|
|
|
|
| |
PiperOrigin-RevId: 168607439
|
|
|
|
| |
PiperOrigin-RevId: 168583913
|
|
|
|
|
|
| |
available from BuildViewTestCase#getRuleContext
PiperOrigin-RevId: 168231020
|
|
|
|
| |
PiperOrigin-RevId: 167861778
|
|
|
|
|
|
| |
ToolchainContext.
PiperOrigin-RevId: 167729868
|
|
|
|
|
|
|
| |
Turns out, my previous search expression didn't find the ones that were not "final LOG" or "final log" and a surprising number of places were missing the "final" tag.
RELNOTES: None.
PiperOrigin-RevId: 167547507
|
|
|
|
|
|
|
|
|
| |
Adding an event about which completed aspects to expect allows for earlier
feedback of what the aspect is doing. It also allows consumers of the build
event stream to prepare for the TargetCompleted events of the aspect.
Change-Id: I29ef15472867a7169222e0394c7fe061fd1d2994
PiperOrigin-RevId: 167248206
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This accomplishes a few goals:
1. Removes the outdated BuildConfiguration.StaticConfigurationApplier code.
2. Removes the TransitionApplier abstraction completely. This was an awkward
bridge meant to support both static and dynamic implementations.
3. Moves transition logic to its own dedicated class: ConfigurationResolver.
This no longer belongs in BuildConfiguration, which we ultimately want to
become a simple <key, value> map.
Part of the static config cleanup effort.
PiperOrigin-RevId: 165736955
|
|
|
|
|
|
|
|
| |
This is always true.
Part of the static config cleanup effort.
PiperOrigin-RevId: 165628823
|
|
|
|
|
|
|
|
| |
BuildConfigurationCollection.Transitions.
Part of the static config cleanup effort.
PiperOrigin-RevId: 165607492
|
|
|
|
|
|
|
|
|
|
| |
Some information about a target is configuration independent and therefore can
already be provided at a target level (i.e., in the TargetConfigured event). Do
so, to have that information available earlier and, once the deprecation period
is over, avoid redundant information in the stream.
Change-Id: I8021ce3dd2a8168d409ea513190c4e3a349dbc2f
PiperOrigin-RevId: 164967059
|