aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/analysis/BuildView.java
Commit message (Collapse)AuthorAge
* Move shell executable to its own configuration fragment.Gravatar lberki2018-04-06
| | | | | RELNOTES: None. PiperOrigin-RevId: 191861074
* Remove categories from Bazel options.Gravatar ccalvarin2018-03-28
| | | | | | | | | 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
* Get rid of all remaining non-test non-internal uses of ↵Gravatar janakr2018-03-27
| | | | | | 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
* Deprecate TransitiveInfoCollection#getConfiguration(), adding two new ↵Gravatar janakr2018-03-26
| | | | | | | | 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
* Add a DefaultBuildOptions specifying default build flags that may differ ↵Gravatar mjhalupka2018-03-22
| | | | | | 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
* Add some testing methods to get ConfiguredTargetAndData more easily, and ↵Gravatar janakr2018-03-19
| | | | | | rename some methods that were still called ConfiguredTargetAndTarget. Move some tests over to using ConfiguredTargetAndData instead of calling ConfiguredTarget#getConfiguration() directly. PiperOrigin-RevId: 189642264
* Refactor DependencyResolver#dependentNodeMap to take in a set of toolchain ↵Gravatar juliexxia2018-03-16
| | | | | | 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
* Dedupes aspects in BuildViewGravatar Googler2018-03-14
| | | | | | | This change ensures that there is no duplicate aspect in AnalysisResult. RELNOTES: None PiperOrigin-RevId: 189086095
* Add BuildConfiguration to ConfiguredTargetAndTarget and rename it to ↵Gravatar janakr2018-03-10
| | | | | | ConfiguredTargetAndData. We want to get BuildConfiguration out of ConfiguredTarget because it uses >800K when serialized. PiperOrigin-RevId: 188600002
* Remove --incompatible_load_argument_is_label flagGravatar laurentlb2018-03-01
| | | | | | RELNOTES: Removed flag `--incompatible_load_argument_is_label`. PiperOrigin-RevId: 187479614
* Refactor to get rid of some getConfiguredTarget() calls in tests and replaceGravatar mjhalupka2018-02-07
| | | | | | | them with getConfiguredTargetAndTarget() so we can get rid of ConfiguredTarget.getTarget() callers. This should be a test only change. PiperOrigin-RevId: 184877255
* Rename Transition to ConfigurationTransition.Gravatar gregce2018-01-30
| | | | PiperOrigin-RevId: 183859414
* Remove DynamicTransitionMapper, ConfigurationTransitionProxy.Gravatar gregce2018-01-30
| | | | PiperOrigin-RevId: 183826311
* Add alternative interface for LIPO data transitions, opt in native rules.Gravatar gregce2018-01-29
| | | | | | | | | | | 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
* Remove ConfiguredTarget.getTarget() calls from Build View. Replace them with ↵Gravatar mjhalupka2018-01-29
| | | | | | getting Target from the SkyframeExecutor's PackageManager. PiperOrigin-RevId: 183710251
* Delete documentation for --analysis_warnings_as_errors.Gravatar Benjamin Peterson2018-01-25
| | | | | | | This option has no effect, so don't give documentation readers false hope. Change-Id: Ibbc0d2f62375fd146fedaa113a39027bd7d65d6c PiperOrigin-RevId: 183240947
* Introduce a wrapper around the ImmutableSortedSet<Class<? extends ↵Gravatar janakr2018-01-24
| | | | | | | | 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
* Explicitly make fragments option to BuildConfigurationValue#key an ↵Gravatar janakr2018-01-23
| | | | | | | | 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
* Remove ConfigurationTransitionProxy.NONE and ↵Gravatar gregce2018-01-18
| | | | | | | | BaseRuleClasses.DYNAMIC_TRANSITION_MAP. This leaves DATA as the last remaining legacy transition. PiperOrigin-RevId: 182422552
* Start the process of getting Target out of ConfiguredTarget: add a new ↵Gravatar janakr2018-01-18
| | | | | | | | | | | | 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
* Convert ActionLookupKey implementations to directly implement SkyKey, ↵Gravatar janakr2018-01-11
| | | | | | removing the layer of indirection of getting SkyKey out of ActionLookupKey, which uses more memory for no reason. PiperOrigin-RevId: 181658615
* Move PatchTransition and kin to analysis.config.transitions.Gravatar gregce2018-01-04
| | | | | | | HostTransition can't be migrated yet because it depends on BuildConfiguration. PiperOrigin-RevId: 180842784
* Consolidate calls to AnalysisUtils.getTopLevelTargetsWithConfigs which ↵Gravatar juliexxia2018-01-03
| | | | | | conveniently also makes it unnecessary to pass the entire LoadingResult when doing configured queries post analysis. PiperOrigin-RevId: 180676481
* Replace Attribute.ConfigurationTransition with ↵Gravatar gregce2017-12-28
| | | | | | | | | | | | | | | | 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
* Replace Attribute.Transition with config.transitions.Transition.Gravatar gregce2017-12-22
| | | | PiperOrigin-RevId: 179936355
* Consolidate instances of the --loading_phase_threads flag.Gravatar juliexxia2017-12-21
| | | | | RELNOTES: None. PiperOrigin-RevId: 179838936
* Aspects-on-aspect see and propagate over aspect attributes.Gravatar dslomov2017-12-20
| | | | | | | | | | | 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
* Consolidate instances of the --keep_going flag.Gravatar juliexxia2017-12-18
| | | | | RELNOTES: None. PiperOrigin-RevId: 179468685
* Rename OutputGroupProvider -> OutputGroupInfo.Gravatar dslomov2017-12-14
| | | | | RELNOTES: None PiperOrigin-RevId: 179046403
* Upgrade --target_environment, --auto_cpu_environment_group.Gravatar gregce2017-12-05
| | | | | | | 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
* Add ActionKeyContext to Action#getKey.Gravatar tomlu2017-11-29
| | | | | | | 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
* Refactor the representation of a collection of package specificationsGravatar cushon2017-11-15
| | | | PiperOrigin-RevId: 175832159
* Replace all usages of Blaze's Preconditions class with guava.Gravatar tomlu2017-11-09
| | | | | | | | 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
* Loop in top-level transition logic to configurable query to give more ↵Gravatar juliexxia2017-10-20
| | | | | | accurate results. Some refactoring done to get custom query code out of BuildView and into resolvers. PiperOrigin-RevId: 172647838
* Allow NodeEntry implementations to keep just deps, as opposed to all edges ↵Gravatar janakr2017-10-10
| | | | | | 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
* Don't symlink into the execroot if possible in SymlinkAction: instead, ↵Gravatar janakr2017-10-02
| | | | | | 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
* Automatic code cleanup.Gravatar cushon2017-09-29
| | | | PiperOrigin-RevId: 170503143
* Stop injecting WorkspaceStatusAction into the Skyframe graph as a ↵Gravatar janakr2017-09-26
| | | | | | | | | | | | 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
* Document the options in smaller commands.Gravatar ccalvarin2017-09-20
| | | | | RELNOTES: None. PiperOrigin-RevId: 169258065
* Lots more cleanup of "dynamic configurations" comments and test code.Gravatar gregce2017-09-14
| | | | PiperOrigin-RevId: 168607439
* Cleanup todo from static config removalGravatar gregce2017-09-14
| | | | PiperOrigin-RevId: 168583913
* Toolchain providers are propagated in the ToolchainContext instance madeGravatar cpeyser2017-09-12
| | | | | | available from BuildViewTestCase#getRuleContext PiperOrigin-RevId: 168231020
* Rule classes cannot request duplicate toolchains.Gravatar cpeyser2017-09-08
| | | | PiperOrigin-RevId: 167861778
* RuleContext instances obtained through BuildViewTestCase#getRuleContext have aGravatar cpeyser2017-09-07
| | | | | | ToolchainContext. PiperOrigin-RevId: 167729868
* Now really rename all logger instances to "logger".Gravatar lberki2017-09-05
| | | | | | | 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
* BEP: Add TargetConfigured events also for aspectsGravatar Klaus Aehlig2017-09-01
| | | | | | | | | 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
* Replace TransitionApplier interface with a dedicated class.Gravatar gregce2017-08-21
| | | | | | | | | | | | | | | 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
* Remove BuildConfiguration.useDynamicConfigurations.Gravatar gregce2017-08-18
| | | | | | | | This is always true. Part of the static config cleanup effort. PiperOrigin-RevId: 165628823
* Remove ConfigurationCollection{Function,Value}, ↵Gravatar gregce2017-08-18
| | | | | | | | BuildConfigurationCollection.Transitions. Part of the static config cleanup effort. PiperOrigin-RevId: 165607492
* BEP: move configuration-independent information to TargetConfigured eventGravatar Klaus Aehlig2017-08-11
| | | | | | | | | | 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