aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/skyframe/ConfiguredTargetFunction.java
Commit message (Collapse)AuthorAge
* Batch all DependencyResolver#getTarget calls. This leads to some duplicate ↵Gravatar janakr2018-08-09
| | | | | | iteration, but that should be cheap, while requesting packages sequentially can hurt... PiperOrigin-RevId: 208126130
* Remove ToolchainContextException and make exception handling more robust.Gravatar John Cater2018-07-10
| | | | | Change-Id: Iefeab0de85541b963c6cc262339e73b79f630f8b PiperOrigin-RevId: 203952823
* Pull up calls to ToolchainContext.resolvedToolchainLabels and finishGravatar John Cater2018-07-09
| | | | | | | ToolchainContext configuration earlier. Change-Id: I034f56a8a181aac19ecb38e51558ccdc6c0c7a6a PiperOrigin-RevId: 203835978
* Make loading/analysis phase a lot faster.Gravatar Googler2018-07-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a fundamental bottleneck in the way targets are currently configured: The ConfiguredTargetFunction needs to load all dependent targets before it can configure its own target. Now, outgoing deps of a target can be in three states: 1. Package of dependency target not yet loaded 2. Dependency target not configured, but package already loaded 3. Dependency target configured State #3 is good, we don't need to do any more work before we can configure the current target. Now, most targets will have a combination of deps in states #1 and #2. The current behavior is to schedule the target configuration of deps in state #2 and the package loading in state #1 (to get to state #3 and #2, respectively). Only after *all* of these are computed will the corresponding ConfiguredTargetFunction be rescheduled upon which the remaining deps that were in state #1 before are now in state #2 and the corresponding target configuration can be started. This creates a substantial parallelization bottleneck by artifically sync'ing the state transitions (#1->#2 and #2->#3) for all deps. In turn, this makes the critical path artifically long. Instead, settle for just loading dependent packages as long as there are any. This is a fast single-step operation. Postpone the configuration of dependent targets to later as it can require long dependency chains to be configured. In theory, a better solution would be to split the target configuration in a way so that it is possible to ask for configured targets without yet knowing their package. However, that would require pulling config transitions apart (as some of them happen because of the origin target/config and some of them happen because of the destination target. Thus we'd need to change the ConfiguredTargetKey so that the configuration stands for the configuration that we request the target in, with target-caused transitions already applied. Now that itself leads to inefficiencies. E.g. we would start requestiong InputFiles in several configurations just to underneath always load them with a null configuration. RELNOTES: Faster analysis by improved parallelization. PiperOrigin-RevId: 203725209
* ToolchainContext directly implements SkylarkValue and SkylarkIndexable.Gravatar John Cater2018-06-22
| | | | | Change-Id: I355b138e143771fd826ab03951df821ea7d58ac5 PiperOrigin-RevId: 201740564
* Remove support for --discard_actions_after_execution.Gravatar tomlu2018-06-18
| | | | | | | The memory savings from this flag are not worth the complexity, and it interferes with action restarting. RELNOTES: Remove support for --discard_actions_after_execution. PiperOrigin-RevId: 201077905
* Remove "artifactOwnerConfiguration" now that LIPO is goneGravatar gregce2018-06-15
| | | | PiperOrigin-RevId: 200763653
* Allow rules and targets to specify extra execution platform constraints.Gravatar John Cater2018-06-05
| | | | | | | | | | | | | | | | | | | | | | RuleClass.Builder now allows authors to specify whether a rule's targets can add additional constraints on the execution platform, and to declare additional constraints for all targets of that rule. Targets which support this now have an attribute, "exec_compatible_with", which supports specifying additional constraints that the execution platform used must match. This attribute is non-configurable. It will only affect execution platforms used during toolchain resolution. Part of #5217. Change-Id: Id2400dbf869a00aa2be3e3d2f085c2850cd6dc00 Closes #5227. Change-Id: If7d55f08f7f44bc7d7f6dfec86a3e6bcd68574b9 PiperOrigin-RevId: 199326255
* Fix Bazel crash on bad config_setting labels.Gravatar gregce2018-05-30
| | | | | | | | | | | | | | | | This used to work more smoothly. But the introduction of ConfiguredTargetAndData adds a Precondition check: https://source.bazel.build/bazel/+/master:src/main/java/com/google/devtools/build/lib/skyframe/ConfiguredTargetAndData.java;l=68?q=ConfiguredTargetAndData that crashes if innerConfigurationKey is null. The only way that can happen is when reading a bad label, which Bazel assumes (incorrectly in this case) to be a null-configured source file. Good times. PiperOrigin-RevId: 198557148
* Refactor root cause reporting in ConfiguredTargetFunctionGravatar ulfjack2018-05-29
| | | | | | We now track Causes instead of plain Labels, which will allow us to do better reporting in the future. Add basic tests. PiperOrigin-RevId: 198380468
* Refactor analysis failure reporting, report loading failuresGravatar ulfjack2018-05-24
| | | | | | | | Split the AnalysisFailureEvent into a legacy and a new variant; always post an AnalysisFailureEvent, even if the legacy variant is not posted - this gives us some coverage for loading failures. PiperOrigin-RevId: 197862257
* Add the capability to register a trimming RuleTransitionFactory.Gravatar mstaib2018-04-19
| | | | | | | | | | This RuleTransitionFactory will be applied to all targets after other transitions, and is intended to be used to manually trim the configuration based on tagging of that target. This is a stopgap feature until automatic trimming of configuration can be implemented. RELNOTES: None. PiperOrigin-RevId: 193573013
* Allow ConfiguredTargetFunction to release its CPU-bound semaphore during dep ↵Gravatar janakr2018-03-28
| | | | | | requests if SkyframeExecutor has reason to believe that those requests may not be CPU-bound. PiperOrigin-RevId: 190844728
* Get rid of ConfiguredTarget#getConfiguration() call in ↵Gravatar janakr2018-03-27
| | | | | | ConfiguredTargetFunction. The dep always has the right configuration, even in the case of an AliasConfiguredTarget. PiperOrigin-RevId: 190642982
* @AutoCodec ConfiguredValueCreationException. Not a high priority, but while ↵Gravatar janakr2018-03-24
| | | | | | we're getting spurious analysis errors, helps to reduce noise. PiperOrigin-RevId: 190355369
* 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
* 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
* 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
* Expose an actions provider on RuleConfiguredTarget instances.Gravatar cparsons2018-03-06
| | | | | | | | | Given a target (for example from a skylark aspect), one will be able to access a list of actions that the target generated using "target.actions". This is without additional memory footprint. Actions themselves are not fully exposed to skylark (and thus there isn't much meaning to gather from them in skylark yet). Access methods will follow soon. RELNOTES: None. PiperOrigin-RevId: 188098079
* Update ToolchainUtil to properly load and use the available executionGravatar John Cater2018-02-28
| | | | | | | | | platforms, and correctly merge together the results from TRF. Part of #4442. Change-Id: I31d83fa73a93d39a0e18d05a43a1c8666ac5a2d2 PiperOrigin-RevId: 187324257
* Start slimming down ToolchainResolutionKey: get rid of BuildConfiguration. ↵Gravatar janakr2018-02-14
| | | | | | The real blocker is PlatformInfo, which is coming. PiperOrigin-RevId: 185742130
* BEP: report analysis failure eventsGravatar Klaus Aehlig2018-01-26
| | | | | | | | | | | | | | ...as completion of the respective top-level targets. In this way, a failure is associated to its root cause, even if the cause is at analysis phase; in particular, visibility errors are correctly associated. For the time beeing, we associate visibility root causes only with labels; it is planned to change that to the more accurate configured labels in a follow-up change. Change-Id: I04121a7cd2099fc65171eae0719fd77b98aef09b PiperOrigin-RevId: 183359798
* 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
* Stop including BuildConfiguration inside ConfiguredTargetKey: it's too ↵Gravatar janakr2018-01-11
| | | | | | heavyweight. For now, put a BuildConfigurationValue.Key in there. In the future, we may want to put some kind of "delta" key in. PiperOrigin-RevId: 181673805
* 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
* Get rid of LabelAndConfiguration class: ConfiguredTargetKey contains the ↵Gravatar janakr2017-12-20
| | | | | | same information and is more useful, since it's practically a SkyKey. PiperOrigin-RevId: 179727105
* Optionally allow loaded packages to not be tracked.Gravatar janakr2017-12-15
| | | | | | If we are running with a single source root and not going to set up the execroot (since we know how to resolve all packages), we can avoid tracking loaded packages, since they're only used to set up the execroot. PiperOrigin-RevId: 179234932
* 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
* Added new RuleClass flag to turn off platform support, to stop dependency ↵Gravatar John Cater2017-11-21
| | | | | | | | | cycles when loading platforms. Part of #4128. Change-Id: Ie55a91aaaec15d8eb537f59131fc2e69a8f9c251 PiperOrigin-RevId: 176509311
* 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
* Move TransitiveTargetKey to a dedicated top-level classGravatar ulfjack2017-10-30
| | | | PiperOrigin-RevId: 173873310
* Move aspect resolution out of ConfiguredTargetFunction.Gravatar gregce2017-09-21
| | | | | | Part of the effort to simplify ConfiguredTargetFunction. PiperOrigin-RevId: 169453435
* Move ConfiguredTargetFunction dynamic config selection to its own class.Gravatar gregce2017-09-20
| | | | | | | | Also clarify the interfaces *TransitionResolver* - which determines what transition to apply to an input configuration and *ConfigurationResolver* - which determines the output configuration from that transition. PiperOrigin-RevId: 169311986
* Project reorg: move *ConfiguredTarget to new configuredtargets/ pathGravatar gregce2017-09-18
| | | | | | | Exempt RuleConfiguredTarget in this change because that's liable to touch a billion files. PiperOrigin-RevId: 168929827
* Remove outdated references to static vs. dynamic configurations.Gravatar gregce2017-09-13
| | | | PiperOrigin-RevId: 168452997
* Remove outdated defaultsToSelf.Gravatar gregce2017-09-12
| | | | | | Part of the static config cleanup effort. PiperOrigin-RevId: 168270713
* Rule classes cannot request duplicate toolchains.Gravatar cpeyser2017-09-08
| | | | PiperOrigin-RevId: 167861778
* Error reporting for invalid dynamic configurationsGravatar cparsons2017-08-31
| | | | | | | also, AppleConfiguration no longer throws NPE with invalid cpu. RELNOTES: None. PiperOrigin-RevId: 167013760
* Remove BuildConfiguration.useDynamicConfigurations.Gravatar gregce2017-08-18
| | | | | | | | This is always true. Part of the static config cleanup effort. PiperOrigin-RevId: 165628823
* Ensure that invalid target errors are properly reported inGravatar John Cater2017-08-10
| | | | | | | | | ConfiguredTargetFunction. Fixes #3430. Change-Id: Iac1ab3fb4958dc6fb23e92a43a32b81461dcf0f3 PiperOrigin-RevId: 164754851
* Move RuleConfiguredTargetFactory to lib.analysisGravatar ulfjack2017-08-07
| | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. PiperOrigin-RevId: 164446955
* Adding further error messages for cases where invalid labels are used with ↵Gravatar John Cater2017-08-07
| | | | | | | | | register_toolchains. Fixes #3429. Change-Id: Iae5632c4b866994a849032bbc2757a6a5151cc6a PiperOrigin-RevId: 164304020
* Aspects that apply to files cannot apply to source files.Gravatar dslomov2017-08-07
| | | | | | | Make them not crash. RELNOTES: None. PiperOrigin-RevId: 164265379
* Use RequiredProviders to validate rule prerequisites in RuleContext.Gravatar dslomov2017-08-03
| | | | | | | | | We now use a unified way to check provider requirements everywhere. Reland of https://github.com/bazelbuild/bazel/commit/c32e1b1efcd703b3780de47fba62974123593d71. RELNOTES: None. PiperOrigin-RevId: 164038621
* Automated rollback of commit c32e1b1efcd703b3780de47fba62974123593d71.Gravatar dslomov2017-08-02
| | | | | | | | | | | | | | | *** Reason for rollback *** Breaks depot b/64250728 *** Original change description *** Use RequiredProviders to validate rule prerequisites in RuleContext. We now use a unified way to check provider requirements everywhere. RELNOTES: None. PiperOrigin-RevId: 163862067
* Improve error message when requesting an invalid toolchain type from the ↵Gravatar John Cater2017-08-01
| | | | | | | | | context. Fixes #3428. Change-Id: Ib3f45bc6856651cfb29d338d0b4480ba1dd77cea PiperOrigin-RevId: 163760940
* Use RequiredProviders to validate rule prerequisites in RuleContext.Gravatar dslomov2017-07-31
| | | | | | | We now use a unified way to check provider requirements everywhere. RELNOTES: None. PiperOrigin-RevId: 163710961
* Use toolchain resolution in rule creation.Gravatar John Cater2017-07-21
| | | | | | | Part of #2219. Change-Id: Id4929d5ddcd57b4635af5e513eb9a09f16a78e71 PiperOrigin-RevId: 162634398
* Aspects-on-aspects correctness fix.Gravatar dslomov2017-07-14
| | | | | | | | Fixes an issue where an aspect propagates over a target that depends on another target twice with different set of aspects applied. RELNOTES: None. PiperOrigin-RevId: 161931168
* Automated g4 rollforward of commit b71e99b1f3746103e5d6802eebc24096b3494959.Gravatar gregce2017-06-05
| | | | | | | | | | | | | | | | | | | | | | | | (Automated g4 rollback of commit de92f9d8ea093416fae999073bbfcf3cf501ab55). *** Reason for rollback *** The problems that forced commit de92f9d8ea093416fae999073bbfcf3cf501ab55 were fixed in commit e6392cd380fce14d719890c78d5eb2657e8a6cfc . *** Original change description being rolled forward *** Implement dynamically configured LIPO builds. Quick overview: - provide a dynamic interface for getting the artifact owner configuration - provide a (dynamic) RuleTransitionFactory LIPO_ON_DEMAND to replace the (static) RuleClass.Configurator LIPO_ON_DEMAND. Eventually we'll remove the rule class configurator interface entirely.... *** ROLLBACK_OF=156180015 PiperOrigin-RevId: 157865224
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-12 19:32:22 +0000