| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the interleaved case, loading errors can now also be discovered during the
analysis phase. Add a boolean flag to the SkyframeAnalysisResult to indicate
that such an error happened, and pass it through in BuildView.
Also refactor BuildView to simplify the code a bit - simply pass the
SkyframeAnalysisResult to the createResult method.
There is already an integration test for this - I'm adding a faster unit test
in BuildViewTest, as this is part of the BuildView contract.
--
MOS_MIGRATED_REVID=113716870
|
|
|
|
|
|
|
|
| |
Add test coverage by re-running BuildViewTest with the new Skyframe loading
phase runner.
--
MOS_MIGRATED_REVID=113517509
|
|
|
|
|
|
|
|
|
| |
This should never be triggered in production, where we always run a loading
phase first and only analyze targets that load successfully. I.e., this is
just plumbing which will be hooked up in a subsequent change.
--
MOS_MIGRATED_REVID=113258593
|
|
|
|
|
|
|
|
|
|
|
| |
- if there are failed top-level aspects
- if there are conflicting actions
I ended up rewriting how errors are signaled from the SkyframeBuildView. I
think this is safe, but please review carefully.
--
MOS_MIGRATED_REVID=113150100
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dependencies are the data structure which needs to propagate the configuration for each
aspect as created by trimConfigurations down to the point where it's actually used. We
need this to store different configurations for different aspects in a world where aspects
have their own configurations, which may have more fragments than the target they're
attached to.
That world is on its way.
Also in this CL:
* Refactor Dependency to be an abstract parent class with separate implementations for
Attribute.Transitions and BuildConfigurations, as well as null configurations, to avoid
having to check nullness in various places. Users of the API will not see this, but get
factory methods instead of constructors. As a consequence of this, refactor Dependency
to be its own top-level class instead of a nested class in DependencyResolver.
--
MOS_MIGRATED_REVID=113109615
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=112952552
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If an aspect has specified its configuration fragment dependencies,
use these in place of the rule's.
Note that the dynamic configuration support for this is yet to come.
Also in this CL:
* RuleContext is constructed with a ruleClassNameForLogging, which allows
error messages involving aspects to be clearer.
RELNOTES[NEW]: Skylark aspects can now specify configuration fragment
dependencies with fragments and host_fragments like rules can.
--
MOS_MIGRATED_REVID=112614357
|
|
|
|
|
|
|
|
|
|
| |
In particular, don't immediately call into the ForTesting functions; I need to
refactor some code that is called from here, and the semantics when called
from ide info should not change. Changes to semantics when called from tests
are much less problematic - we can simply run all the tests.
--
MOS_MIGRATED_REVID=111846384
|
|
|
|
|
|
|
| |
Reduces garbage.
--
MOS_MIGRATED_REVID=109914243
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=108243881
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
configurations contain regardless of whether their rules explicitly
require it.
This is used to ensure all rules have BazelConfiguration. That
fragment supplies the path to the shell, which powers
BuildConfiguration.getShExecutable(), which powers any rule that
generates a SpawnAction.
Since SpawnActions are such a ubiquitous pattern we only want to
accelerate going forward, there's no point not to make this
automatically available to every rule.
--
MOS_MIGRATED_REVID=107786879
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
internally. The load location for a Skylark Aspect is specified via a PathFragment, for consistency with current non-Aspect Skylark loads.
This should be a semantics-preserving change for users. In a subsequent CL, I'll change the Skylark syntax to allow load statements to use labels as well as paths, with the goal of eventually deprecating the latter.
Also:
- Removed the hack for handling relative loads in the prelude file.
- Refactored some redundant functionality in PackageFunction and SkylarkImportLookupFunction for handling loads.
- Removed the ability to put the BUILD file for the package containing a Skylark file under a different package root than the Skylark file itself. This functionality isn't currently used and is inconsistent with Blaze's handling of the package path elsewhere.
- Added BUILD files to a number of tests that load Skylark files; this is consistent with the requirement that all Skylark files need to be part of some package.
- Changed the constants used to set the location of the prelude file from paths to labels.
--
MOS_MIGRATED_REVID=107741568
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=106848269
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=106838787
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=106694515
|
|
|
|
|
|
|
| |
For native aspects, AspectClass is a facade for Class<AspectFactory<...>>.
--
MOS_MIGRATED_REVID=105986390
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=105844221
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Uses tests that don't run on Bazel
*** Original change description ***
Implement aspect(...) Skylark function.
--
MOS_MIGRATED_REVID=105808850
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=105596479
|
|
|
|
|
|
|
|
| |
Now that we have an EventHandler everywhere, we can just use the bridge code
to call into the usual PackageManager.
--
MOS_MIGRATED_REVID=104098660
|
|
|
|
|
|
|
|
| |
Production API at the top, then ide_build_info, and testing at the bottom.
This is separate from the refactoring to make both easier to review.
--
MOS_MIGRATED_REVID=104095498
|
|
|
|
|
|
|
| |
Also inject the EventHandler all the way through to the SkyframeExecutor.
--
MOS_MIGRATED_REVID=104094731
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=104009600
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was mainly used for testing during the transition phase to Skyframe. The
only reason I can see to keep it would be to have test coverage that changing
the configuration drops the configured targets. However, do we even want that?
I tried to find out whether it's safe to remove that check (the corresponding
comment is outdated), but couldn't find where (if anywhere) we're doing
garbage collection of old configured targets.
--
MOS_MIGRATED_REVID=104009210
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=104008237
|
|
|
|
|
|
|
|
| |
This is another case of uninterruptible evaluation, which directly accesses
SkyframeExecutor.errorEventListener.
--
MOS_MIGRATED_REVID=103946310
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This limits the exposure of LoadedPackageProvider, such that there will be
no regressions in the use of getLoadedTarget. Unfortunately, fully removing
LoadedPackageProvider is more work than I'm willing to take on right now, and
this is the cleanest intermediate solution I could come up with.
This unblocks my other work (removing SkyframeExecutor.errorEventHandler).
Someone else will have to shave this yak.
--
MOS_MIGRATED_REVID=103943375
|
|
|
|
|
|
|
|
|
|
|
| |
The headers were modified with
`find . -type f -exec 'sed' '-Ei' 's|Copyright 201([45]) Google|Copyright 201\1 The Bazel Authors|' '{}' ';'`
And manual edit for not Google owned copyright. Because of the nature of ijar, I did not modified the header of file owned by Alan Donovan.
The list of authors were extracted from the git log. It is missing older Google contributors that can be added on-demand.
--
MOS_MIGRATED_REVID=103938715
|
|
|
|
|
|
|
|
|
| |
Instead, pass an appropriate EventHandler instance in. This is in preparation
for creating a per-command EventHandler, in preparation for allowing multiple
commands to run in parallel. This is removal of shared global state.
--
MOS_MIGRATED_REVID=103828963
|
|
|
|
|
|
|
| |
Also change some calls to getLoadedTarget to getTarget instead.
--
MOS_MIGRATED_REVID=103755023
|
|
|
|
|
|
|
|
| |
Also move ownership of ArtifactFactory to SkyframeBuildView; simplify the
code.
--
MOS_MIGRATED_REVID=103722228
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=103544466
|
|
|
|
|
|
|
|
|
|
| |
- Label parsing can be simplified
- lib.syntax is only contains the code for Skylark and is reasonably independent from the problem domain of building things
This change is mostly only changes to imports declarations. The rest is reversing the dependency between :cmdline and :syntax and moving a tiny amount of code between Printer and FilesetEntry and the addition of SkylarkPrintableValue that I couldn't be bothered to separate out into its own change.
--
MOS_MIGRATED_REVID=103527877
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=103380547
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=103374106
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I was persuing the idea that BuildView could become stateless. While that
should be possible, we're currently still relying on minimal state in
BuildView (from tests at least) in a way that makes it tricky to remove.
Instead, I'm now trying to move the BuildView into CommandEnvironment, and
create a new one as needed (only for build commands); that makes it safe in the
presence of concurrently running commands, as long as they don't use the same
BuildView instace. (Of course, allowing commands to run concurrently will need
more changes outside of BuildView.)
--
MOS_MIGRATED_REVID=103279370
|
|
|
|
|
|
|
| |
evaluation, test_suite expansion and configuration creation is still there). Also remove some unused code.
--
MOS_MIGRATED_REVID=103177839
|
|
|
|
|
|
|
| |
BaseFunction.
--
MOS_MIGRATED_REVID=102988766
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=102332437
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=102134151
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=102126786
|
|
|
|
|
|
|
|
|
|
| |
The baseline artifacts are part of the instrumented files provider now, and
are strongly tied to the collect_code_coverage flag. It seems to be simpler
to collect them explicitly in the BuildView (which already collects them for
post-processing), than to rely on the output group selection.
--
MOS_MIGRATED_REVID=101926341
|
|
|
|
|
|
|
|
| |
This is necessary to have TargetResolver depend on it without making it depend
on the packages target. First step of #389.
--
MOS_MIGRATED_REVID=101790345
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a big change, so let me walk you through the key pieces:
1) This cl provides an alternative mechanism for creating configurations and doing configuration transitions that's "dynamic" in that the configurations can be created on the fly and the transitions are arbitrary mappings from BuildOptions --> BuildOptions that can also be created on the fly. It also integrates this with ConfiguredTargetFunction, so the configured target graph automatically uses this framework.
2) It does *not* replace old-style (which we'll call "static") configurations. For a number of important reasons: It's not yet at feature parity (particularly: no LIPO). It's not remotely tested across real projects enough to have confidence that it's battle-ready. It doesn't yet handle certain "special" functions like BuildConfiguration.prepareToBuild() and BuildConfiguration.getRoots(). It still relies on the old static transition logic to determine what transitions to apply (eventually we'll distribute that logic out, but that's too much for a single cl). We need the option to toggle it on and off until we have enough confidence in it. So with this cl, builds can be done in either mode.
3) The new flag --experimental_dynamic_configs toggles use of dynamic configurations.
4) Dynamic configurations are created with the Skyframe function BuildConfigurationFunction (this was already created in an earlier change). This consumes a BuildOptions and a set of configuration fragments to produce a BuildConfiguration.
5) Dynamic transitions are instances of the new class PatchTransition, which simply maps an input BuildOptions to an output BuildOptions.
6) Since static and dynamic configurations have to co-exist (for now), this cl tries hard to keep today's transition logic defined in a single place (vs. forking a dedicated copy for each configuration style). This is done via the new interface BuildConfiguration.TransitionApplier. BuildConfiguration.evaluateTransition is modified to feed its transition logic into TransitionApplier's common API. Both dynamic and static configurations have their own implementations that "do the right thing" with the results.
7) The transition applier for dynamic configurations basically stores the Transition, then allows DependencyResolver (which calls BuildConfiguration.evaluateTransition) to return Dependency instances containing that Transition (vs. a BuildConfiguration, which they traditionally contain).
7.5) An earlier variation of the dynamic transition applier retained BuildOptions (e.g. when it got a Transition it immediately applied it to get its output BuildOptions, then stored that). This had the advantage of making composing of transitions easier, especially within BuildConfiguration.evaluateTransition (which can theoretically apply multiple transitions to the input configuration). But it turns out that applying transitions has a cost, and it's simply more performant to pass them through until they're really needed.
8) In dynamic configuration mode, after ConfiguredTargetFunction gets its deps (e.g. an <Attribute, Dependency> multimap), it "trims" the configurations for its dependencies by a) only including config fragments required by the deps' subtrees and b) applying the transitions that came from 7). This all happens in the new method ConfiguredTargetFunction.trimConfigurations.
9) trimConfigurations is heavily performance-optimized based on a lot of experience running this through a large project within Google. As it turns out, the cost of host transitions can be atrocious (because there are a lot of them). Also, BuildOptions.clone() is expensive. And just creating BuildConfiguration SkyKeys also has a cost (largely because of BuildOptions cloning), so that shouldn't be done except when really necessary. My experience with this convinced me it's worth making this method complicated for the sake of making it fast. Since it basically visits every edge in the configured target graph (at least), it really needs to be slick.
10) Since host transitions in particular are problematic w.r.t. speed, I compute the host *once* in ConfigurationCollectionFunction.getHostConfiguration() and expose that reference to ConfiguredTargetFunction and other Skyframe functions. This limits recomputation to just when the fragments are trimmed.
11) Since options cloning is expensive, I'm doing something scary: exposing a BuildConfiguration.getOptions() method that returns a direct reference. Since BuildOptions is mutable, this is dangerous in the wrong hands. I can experiment with going back to cloning (with the caching of host transitions it may not matter as much), but we may ultimately have to put up with this risk for the sake of performant analysis time. What would be *really* awesome would be to make BuildOptions immutable. But that's not going to happen in this cl.
So in short, the key abstractions in this cl are:
- PatchTransition
- BuildConfiguration.TransitionApplier
- ConfiguredTargetFunction.trimConfigurations
The current implementation imposes no analysis time penalty
--
MOS_MIGRATED_REVID=101474620
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=101457236
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=101033236
|
|
|
|
|
|
|
| |
Instead we can just recreate artifact in ArtifactFactory if source root has changed. Additional optimization is to save with Artifact's some unique id of build when they have been created. If the build is the same we should not check source root changes.
--
MOS_MIGRATED_REVID=100104312
|
|
|
|
|
|
|
| |
efficient if we need to do many ActionGraph looups.
--
MOS_MIGRATED_REVID=100060090
|
|
|
|
|
|
|
|
| |
This change should essentially be a no-op for callers of getDirectPrerequisites,
but opens the opportunity to use the Dependency iterable directly.
--
MOS_MIGRATED_REVID=98383758
|
|
|
|
|
|
|
|
|
| |
Dynamic configuration transitions require access to Skyframe (since they instantiate BuildConfigurations as Skyframe nodes). There are various places in Bazel where static transitions are done with no convenient Skyframe access. This cl shuffles host transitions, in particular, to places that are more amenable.
This change also assumes one host configuration per invocation. While this isn't strictly true (each target configuration can have its own host, and multiple target configurations are possible per build), we don't leverage that functionality in any meaningful way today. So until we have a proper interface for multiple host configurations, let's not block dynamic config progress on it.
--
MOS_MIGRATED_REVID=97008479
|