aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/analysis/BuildView.java
Commit message (Collapse)AuthorAge
* Refactor all ctor callsites of PathFragment to instead call a static ↵Gravatar nharmata2017-04-05
| | | | | | | | | | | | 'create' method. This paves the way for changing PathFragment to e.g. an abstract class with multiple subclasses. This way we can split out the windows-specific stuff into one of these concrete classes, making the code more readable and also saving memory (since the shallow heap size of the NonWindowsPathFragment subclass will hopefully be smaller than that of the current PathFragment). This also lets us pursue gc churn optimizations. We can now do interning in PathFragment#create and can also get rid of unnecessary intermediate PathFragment allocations. RELNOTES: None PiperOrigin-RevId: 152145768
* If --batch, --keep_going, --discard_analysis_cache, and the new ↵Gravatar janakr2017-03-31
| | | | | | | | | | | | | | | --noexperimental_enable_critical_path_profiling flags are all specified, then Bazel will delete Actions from ActionLookupValues as they are executed in order to save memory. Because an already-run action may output an artifact that is only requested later in the build, we need to maintain a way for the artifact to look up the action. But in most cases we don't need to keep the action itself, just its output metadata. Some actions unfortunately are needed post-execution, and so we special-case them. Also includes dependency change with description: Move action out of key. This keeps action references from polluting the graph -- actions are just stored in one SkyValue, instead of being present in SkyKeys. This does mean additional memory used: we have a separate ActionLookupData object per Action executed. That may reach ~24M for million-action builds. PiperOrigin-RevId: 151756383
* BuildView#getConfiguredTargetForTesting respects null transitions.Gravatar mstaib2017-03-31
| | | | | | | | RuleTransitionFactory#buildTransitionFor is @Nullable, but the SkyframeExecutor expects a non-null Transition. If the factory returns null, the SkyframeExecutor should be passed NONE, not null. PiperOrigin-RevId: 151615724
* Clear AspectValues when discarding analysis cache, along with ↵Gravatar janakr2017-03-29
| | | | | | | | ConfiguredTargetValues. Also clear transitive packages for both, even for top-level targets. This is not expected to save significant memory, but is expected to reduce the number of references to Packages, allowing them to be dropped more easily when discarding analysis cache and running in batch mode. PiperOrigin-RevId: 151508877
* Unit tests respect top-level rule-class transitions.Gravatar Cal Peyser2017-03-27
| | | | | | -- PiperOrigin-RevId: 151129669 MOS_MIGRATED_REVID=151129669
* Enable rules to transition based on their Rule objects.Gravatar Michael Staib2017-03-21
| | | | | | | | | | | | This begins to allow for cases where a rule sets configuration based on its attributes, such as where a rule attribute names flags and their values - sort of a reverse select. There are no such cases yet, but they're coming! -- PiperOrigin-RevId: 150648357 MOS_MIGRATED_REVID=150648357
* Provide more reporting options to SkyFunctions Gravatar Klaus Aehlig2017-02-27
| | | | | | | | | | | | | With more specific information to be reported by Skyfunctions, e.g., to inform the build-event protocol on missing files, the EventHandler interface is no longer enough. Therefore, provide an enriched context for reporting events. -- Change-Id: I2d06166fe4d5b9054e24ad8c752fafc039e3f9f8 Reviewed-on: https://cr.bazel.build/8794 PiperOrigin-RevId: 148463437 MOS_MIGRATED_REVID=148463437
* Report inconsistent aspect order error to the user.Gravatar Dmitry Lomov2017-02-24
| | | | | | -- PiperOrigin-RevId: 148342788 MOS_MIGRATED_REVID=148342788
* If dynamic configurations are turned on, ruleclass configuration transitionsGravatar Cal Peyser2017-02-22
| | | | | | | | apply on the top level. -- PiperOrigin-RevId: 148155171 MOS_MIGRATED_REVID=148155171
* Make the interface dynamic library builder a regular label instead of a ↵Gravatar Lukacs Berki2017-02-17
| | | | | | | | magic artifact. -- PiperOrigin-RevId: 147830857 MOS_MIGRATED_REVID=147830857
* Restrict aspects visible to other aspects according to their advertised ↵Gravatar Dmitry Lomov2017-02-15
| | | | | | | | providers. -- PiperOrigin-RevId: 147526961 MOS_MIGRATED_REVID=147526961
* Names of extra-action protos now take into account all aspect names.Gravatar Dmitry Lomov2016-12-16
| | | | | | | | | | | | | If an Aspect registered an action that an extra-action is shadowing, its name is used when creating the extra-action's ID and name. Since recently, an aspect can see other aspects applied to the same target. This CL record the names of other aspects applied to the target as well, disambiguating the action owners. -- PiperOrigin-RevId: 142264153 MOS_MIGRATED_REVID=142264153
* Fix test configured target creation code that was dropping split deps.Gravatar Greg Estren2016-12-06
| | | | | | | | | | | | | | | Short story: Dependency -> BuildConfiguration maps can have multiple values because of split transitions. This is unfortunately one of those instances where the test logic is forked from production. So this doesn't actually demonstrate bugs in production code. We already have tests in ConfigurationsForTargetsTest that directly check the production logic. So this cl's primary value is to unbreak tests that depend on the forked logic. -- PiperOrigin-RevId: 141094830 MOS_MIGRATED_REVID=141094830
* Adds support for multiple top-level dynamic configurationsGravatar Greg Estren2016-11-21
| | | | | | | (e.g. --experimental_multi_cpu). -- MOS_MIGRATED_REVID=139607063
* Extra-actions originating in Aspects are reported even if the rule we attach ↵Gravatar Carmi Grushko2016-11-21
| | | | | | | | | | | | | | | | | to also registers extra-actions. ExtraActionArtifactsProvider was using a set of ExtraArtifactSet, whose key was derived from the label of the owner of the extra-action. Since actions registered by Aspects have the same label as those registered by the base rule, the former ones would disappear from the set. An alternative to this CL would be to use an ArtifactOwner instead of a label as the key of the ExtraArtifactSet, but 1. BuildView only has access to ConfiguredTarget's, which lack the information to manipulate ArtifactOwner's; and 2. I don't see what ExtraArtifactSet gains us. In particular, ExtraArtifactSet.getLabel() is not used by anything outside of ExtraArtifactSet. The only disadvantage of this CL is that filtering (--experimental_extra_action_filter) can be slower if targets register a massive number of actions. Before this CL, we would match a single label per rule, while after this CL we match a single label per action. -- MOS_MIGRATED_REVID=139591862
* Allow labels in the '--aspects' parameter.Gravatar Dmitry Lomov2016-11-21
| | | | | -- MOS_MIGRATED_REVID=139573590
* Run the analysis phase with as many threads as the user wants. In order to ↵Gravatar Janak Ramakrishnan2016-11-18
| | | | | | | | | avoid memory blow-up intra-configured-target analysis, use a semaphore to ensure that CPU-bound work only occurs on #CPU-many threads. RELNOTES: Use --loading_phase_threads to control the number of threads used during the loading/analysis phase. -- MOS_MIGRATED_REVID=139477645
* Aspects-on-aspects implementation.Gravatar Dmitry Lomov2016-11-15
| | | | | -- MOS_MIGRATED_REVID=139189444
* Add an escape hatch to quickly disable ↵Gravatar Carmi Grushko2016-11-14
| | | | | | | --experimental_extra_action_top_level_only for Aspects. -- MOS_MIGRATED_REVID=139003012
* Expose aspect-related information in the extra-action proto that Bazel hands ↵Gravatar Carmi Grushko2016-11-11
| | | | | | | | | to action_listener() rules. RELNOTES: Extra actions now contain aspect-related information. -- MOS_MIGRATED_REVID=138832922
* When --experimental_extra_action_top_level_only, Bazel to report ↵Gravatar Carmi Grushko2016-11-09
| | | | | | | | | | | extra-actions for actions registered by Aspects injected by a top-level rule. Because we can't know whether an aspect was injected by a top-level target or one of its children, we approximate it by only reporting extra-actions from Aspects that the top-level target could have injected. RELNOTES: When --experimental_extra_action_top_level_only, Bazel reports extra-actions for actions registered by Aspects injected by a top-level rule (approximately). -- MOS_MIGRATED_REVID=138570606
* Split dynamic configurations mode into:Gravatar Greg Estren2016-09-22
| | | | | | | | | | | | | | | --experimental_dynamic_configs=off - don't use dynamic configs --experimental_dynamic_configs=on - use dynamic configs with trimmed fragments --experimental_dynamic_configs=notrim - use dynamic configs with all fragments This lets us decouple two independent dimensions of dynamic configurations: 1) being able to trigger new configurations and transitions anywhere and 2) only including the fragments needed by a target's transitive closure. 2) is likely to take much more time and effort to properly finesse (three notable challenges: late-bound attributes, aspects, and dynamic shedding of output path names). But 1) by itself already yields significant benefits. So in the name of starting to shift the config work from backend theory to stuff real builds actually use, this change lets us focus on productionizing 1) without blocking on getting all of 2) working first. tl;dr: iterable deployment and all that. -- MOS_MIGRATED_REVID=133874661
* Add an "is main repo" field to RootsGravatar Kristina Chodorow2016-09-09
| | | | | | | This is part of prepping for #1262. -- MOS_MIGRATED_REVID=132553178
* Make --experimental_interleave_loading_and_analysis a no-op.Gravatar Ulf Adams2016-09-06
| | | | | | | | | | | | This is now enabled by default, and this change removes the code path where it's disabled. Remove a few tests that were testing the removed code, and rewrite some others that still seem useful. We still drop configured targets on configuration changes, so we use that to check that things are dropped from Skyframe. -- MOS_MIGRATED_REVID=132226208
* Remove all references to (incorrect) BlazeDirectories.buildDataDirectory rootGravatar Kristina Chodorow2016-08-26
| | | | | | | | | The buildDataDirectory is calculated off of the incorrect execroot. More progress towards #1681. -- MOS_MIGRATED_REVID=131407798
* Remove ArtifactFactory dependency on incorrect exec rootGravatar Kristina Chodorow2016-08-25
| | | | | | | | | | | Somewhat trickily, this changes the execRoot field from referring to [output_base]/execroot/wsname (not really the exec root) to [output_base]/execroot (actually the execroot). Progress on #1681. -- MOS_MIGRATED_REVID=131286181
* Make retrieval of an already loaded target interruptible. There is no reason ↵Gravatar Janak Ramakrishnan2016-08-17
| | | | | | | now to forbid it, since Skyframe lookups are interruptible. -- MOS_MIGRATED_REVID=130429286
* Allow Skyframe graph lookups and value retrievals to throw InterruptedException.Gravatar Janak Ramakrishnan2016-08-16
| | | | | | | The only place we now don't handle InterruptedException is in the action graph created after analysis, since I'm not sure that will be around for that much longer. -- MOS_MIGRATED_REVID=130327770
* Changes DependencyResolver <Attribute, Dep> map from a ListMultimap to new classGravatar Greg Estren2016-08-12
| | | | | | | | | | | | | | | | | | | | | | OrderedSetMultimap. This maintains insertion order while eliminating duplicates. Certain rules, in particular, otherwise break this invariant: https://github.com/bazelbuild/bazel/blo[]e3e28274cca5b87f48abe33884edb84016dd3/src/main/java/com/google/devtools/build/lib/skyframe/ConfiguredTargetFunction.java#L403 There's no reason (to my knowledge) to need multiple instances of the same <Attribute, Dependency> pair. More context from Google code review: (Michael Staib): > There are many things which pass around a dependentNodeMap or help construct one or modify one. We want an interface which has the right guarantees. > ListMultimap is not the right interface because it has no guarantee of unique elements, which we want - we don't want the problem that this CL ran into, and there's no reason (that we know of, to be confirmed) that anyone would want multiple identical Dependencies. > SetMultimap is not the right interface because it has no guarantee of deterministic iteration order or efficient iteration, which we want - dependency order sometimes matters (e.g., Java classpath or C++ link order). > We agreed that the best way to get what we want is to define our own interface with its own simultaneous uniqueness and iterability guarantees. Unspoken in the discussion was why we wouldn't just use LinkedHashMultimap as the thing we pass around. IMO the reason for that is that we don't care that it be a LinkedHashMultimap specifically; if tomorrow Guava comes out with a faster cooler map that has deterministic and efficient iteration and guarantees element uniqueness, we want it. > In this case we're going to make the "interface" be a (final?) class: OrderedSetMultimap, an extension of ForwardingSetMultimap which delegates to LinkedHashMultimap, an implementation which does support both of those guarantees. > I had mentioned in the conversation that none of the Multimap implementations make guarantees about key iteration order, but this is not true - LinkedHashMultimap preserves key insertion order. We should perhaps declare this as part of the OrderedSetMultimap contract as well. -- MOS_MIGRATED_REVID=130037643
* Implements dynamic split transitions on latebound attributes.Gravatar Greg Estren2016-08-10
| | | | | | | | | With this change, dynamic configs are at full feature parity for split transitions (minus some small differences in composed transitions from BuildConfigurationCollection.configurationHook). -- MOS_MIGRATED_REVID=129802414
* Apply extra actions to top-level aspects.Gravatar Dmitry Lomov2016-08-10
| | | | | -- MOS_MIGRATED_REVID=129759632
* Error out if loading phase error encountered even if we skip analysis. Also ↵Gravatar Janak Ramakrishnan2016-08-09
| | | | | | | change error messages in these cases to not assume there was an execution phase. -- MOS_MIGRATED_REVID=129723717
* Bring PackageSpecification docs up-to-date, clean up its interfaceGravatar Mark Schaller2016-07-22
| | | | | | | | Focuses on documenting the Strings that PackageSpecifications can be translated from and to. -- MOS_MIGRATED_REVID=128195540
* Create a symlink with the right workspace name under the execrootGravatar Kristina Chodorow2016-07-22
| | | | | | | | | | | | | | | | | | The execution root currently uses the basename of the workspace directory for the workspace name, not the name in the WORKSPACE file. (For example, if our sources were in /path/to/foo and our WORKSPACE file had workspace(name = "bar"), our execution root would look like execroot/foo.) This creates a symlink bar -> foo, so that accessing ../repo_name actually works for the main repository. RELNOTES[INC]: The main repository's execution root is under the main repository's workspace name, not the source directory's basename. This shouldn't have any effect on most builds, but it's possible it could break someone doing weird things with paths in actions. -- MOS_MIGRATED_REVID=128175455
* For --aspects parameter, ignore top-level targets that are not rules.Gravatar Dmitry Lomov2016-06-29
| | | | | -- MOS_MIGRATED_REVID=126161513
* Trim configurations requested for a target in BuildViewTestCase.Gravatar Greg Estren2016-06-20
| | | | | -- MOS_MIGRATED_REVID=125171507
* Dynamic configurations: trim top-level targets, too.Gravatar Greg Estren2016-06-02
| | | | | | | | | | | | | | | | | | | | | | | Right now, configuration trimming happens in ConfiguredTargetFunction.computeDependencies. This means only the deps of other targets get trimmed. With this change, every ConfiguredTarget gets its configuration accurately trimmed, regardless of where it comes from or what it's used for. In practice, there could still be other code paths that instantiate ConfiguredTargetValue.key without pre-trimming. We'll have to tackle those as we hit them. Also cleaned up some symbol naming in BuildView.update to try to make the logic flow clearer. TESTED: BuildViewTest#testNewActionsAreDifferentAndDontConflict now passes with dynamic configs (among others) -- MOS_MIGRATED_REVID=123807892
* Enable interleaved loading & analysis by default.Gravatar Ulf Adams2016-05-25
| | | | | | | | | Fix a bunch of tests to assume interleaving instead of disrete phases. In our testing, this improves loading+analysis times by ~30%. -- MOS_MIGRATED_REVID=123203752
* Make ide_build_info work again with targets that have configurable attributes.Gravatar Lukacs Berki2016-05-19
| | | | | | | This fixed some fallout from commit 7894c18dbaf237a1c02d76beabe6ca54faf5039a. I also audited all the sites that change introduced ImmutableMap.Builder at. -- MOS_MIGRATED_REVID=122738945
* Add an "alias" rule.Gravatar Lukacs Berki2016-05-10
| | | | | | | This will be used to replace RedirectChaser so that we don't need to load packages during configuration creation anymore. -- MOS_MIGRATED_REVID=121935989
* Expose parameterized aspects to Skylark.Gravatar Googler2016-05-09
| | | | | | | | | | | | | | | There are no syntactic changes within Skylark; the only difference is that aspects may have non-implicit attributes, so long as they have type 'string' and use the 'values' restriction. Such aspects may only be requested by rules which have attributes with types and names matching the non-implicit, non-defaulted attributes of the aspect. This is not yet a complete match for native AspectParameters functionality since implicit attributes cannot yet be affected by attribute values, but that will be added later. Implicit aspects are still required to have default values. Non-implicit aspect attributes are considered "required" unless they have a default value. An error will occur if they are applied to a rule that does not "cover" all required attributes by having attributes of matching name and type. While non-implicit aspect attributes with a default are not required, they will still take on the value of a rule attribute with the same name and type if it is present. Aspects with non-implicit, non-defaulted ("required") attributes cannot be requested on the command line, only by a rule. RELNOTES: Expose parameterized aspects to Skylark. -- MOS_MIGRATED_REVID=121711715
* Delete the interface NativeAspectFactory and make native aspects extend from ↵Gravatar Luis Fernando Pino Duque2016-04-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NativeAspectClass. This a large refactoring of the aspects, currently we have the following: - AspectClasses: The interface AspectClass is a implemented by either SkylarkAspectClass or NativeAspectClass<NativeAspectFactory>. They are wrappers for the AspectFactories and they hold the information about the Class<> of the factory. - AspectFactories (FooAspect.java): Represented by the interfaces ConfiguredAspectFactory and NativeAspectFactory, also by the interface ConfiguredNativeAspectFactory which is the union of the two aforementioned interfaces. All aspects implement ConfiguredNativeAspectFactory except Skylark aspects which implement only ConfiguredAspectFactory. After this CL the distinction between NativeAspectFactories and NativeAspectClasses dissappear, namely aspect that extends NativeAspectClass is considered native and if it implements ConfiguredAspectFactory it is configured. Therefore the interfaces NativeAspectFactory and ConfiguredNativeAspectFactory both disappear. With this refactoring the aspectFactoryMap in the ConfiguredRuleClassProvider changes its type from (String -> Class<? extends NativeAspectClass>) to (String -> NativeAspectClass) which means it is now able to have an instance of the aspect instead of its Class only. By doing this, it is now possible to pass parameters when creating an aspect in the ConfiguredRuleClassProvider. -- MOS_MIGRATED_REVID=120819647
* Split ActionMetadata into ActionAnalysisMetadata and ActionExecutionMetadata.Gravatar Rumou Duan2016-04-26
| | | | | | | Except in action execution logic (ActionExecutionFunction, SkyframeActionExecutor, etc.), switch Action interface references to either ActionAnalysisMetadata if possible or ActionExecutionMetadata. -- MOS_MIGRATED_REVID=120723431
* Refactor the coverage report module to make it less stateful.Gravatar Ulf Adams2016-04-18
| | | | | -- MOS_MIGRATED_REVID=120112783
* Move FDO support to the analysis phase by wrapping FdoSupport in its own ↵Gravatar Lukacs Berki2016-04-07
| | | | | | | | | | | SkyFunction. This removes one of the two reasons for the existence of BuildConfiguration#prepareToBuild() which makes implementing dynamic configurations impossible and also makes FDO support halfway sane; now FDO is exactly as ugly as remote repositories, that is to say, reasonably okay. Ideally, we'd implement the zip extraction as an Action and make it a TreeArtifact, but support for TreeArtifacts is not mature yet enough, so it's not possible at the moment. -- MOS_MIGRATED_REVID=119150223
* Dig out the builtin include file from the filegroup of libc_top instead of ↵Gravatar Lukacs Berki2016-04-04
| | | | | | | | | | | special-casing it in CppConfiguration. This seems to be the most reasonable solution. I was toying with the idea of adding a field to CROSSTOOL but that would fail if you set libc_top to something other than what was specified in that file. If I had a infinite amount of time, I'd create a custom rule called cc_libc where libc_top would point so that this file can be referenced by an attribute, but since I don't, this seems to be workable compromise. Also note that contrary to what you'd glean from the code, we don't actually have "compile" and "link" filegroups for libc. -- MOS_MIGRATED_REVID=118921101
* Remove the unused loadingEnabled param from BuildView.update.Gravatar Ulf Adams2016-03-30
| | | | | -- MOS_MIGRATED_REVID=118560010
* Remove calls of CommandEnvironment.getView; remove ide-info from BuildView.Gravatar Ulf Adams2016-03-30
| | | | | | | This makes the late initialization of BuildView more obviously safe. -- MOS_MIGRATED_REVID=118469655
* Use two configurations for AspectKeys.Gravatar Michael Staib2016-03-01
| | | | | | | | | | | | In order for Aspects to support dynamic configuration, they need to have two configurations: one to instantiate the Aspect with, containing all the fragment dependencies of the Aspect itself, and one to create the ConfiguredTargetValue.key with, containing only the dependencies of the Rule. This expands AspectKey to have a second configuration, although it currently does not populate that key with anything different. -- MOS_MIGRATED_REVID=115997454
* Pass the source path -> Artifact mapping into FdoSupport from a provider ↵Gravatar Lukacs Berki2016-02-28
| | | | | | | | | instead of special-casing it. This removes the need to deserialize artifacts in FdoSupport, which in turn removes the need to support artifact deserialization at all, which makes our lives simpler and Thoreauvian programming is good. -- MOS_MIGRATED_REVID=115660698
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-05 20:42:26 +0000