| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 157446717
|
| |
|
|
| |
PiperOrigin-RevId: 155223580
|
| |
|
|
|
|
|
| |
This fixes a bug that put them out of sync from how all other
attributes manage the host configuration.
PiperOrigin-RevId: 154992583
|
| |
|
|
|
|
|
|
|
|
|
|
| |
'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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is intended to be used for "flags" which should never appear on the
command line - things like configuration distinguishers, which are used
internally and must be part of the build options, but should always be set
to their default value at the top level.
This is already a convention within Bazel, but doesn't actually work the way
Bazel expects - flags with spaces can be set by simply escaping or quoting
the spaces so that word splitting will not break on them. This means they
can also be matched by config_settings, which pass a single string.
Forbidding the parser from matching these flags solves both of these
unintended cases.
Existing cases like this have also been converted to internal.
--
PiperOrigin-RevId: 150497246
MOS_MIGRATED_REVID=150497246
|
| |
|
|
|
|
|
|
| |
providers.
--
PiperOrigin-RevId: 147526961
MOS_MIGRATED_REVID=147526961
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove many calls from tests to SkyframeLabelVisitor.sync, which is generally
no longer necessary. In particular, BuildViewTestCase.ensureTarget(s)Visited
was calling it, so removing that, as well as simulateLoadingPhase.
I moved some tests for TransitiveTargetFunction to the corresponding test
class, where they belong. I also made sure that we have test coverage in the
BuildViewTest for some cases that were previously only tested with TTF. I
dropped some tests which no longer seem applicable / for which we have coverage
elsewhere.
Also, as a drive-by change, I fixed some warnings in BuildViewTestCase.
Note that TTF is only used for genquery and in an experimental code path, but
generally superseded by ConfiguredTargetFunction, which has taken over the
responsibility for loading in all other cases (and interleaves loading and
analysis).
Some of the tests are not externally visible yet.
--
PiperOrigin-RevId: 144813237
MOS_MIGRATED_REVID=144813237
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
not untrimmed ones.
--
MOS_MIGRATED_REVID=139376735
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=137266505
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Bazel's dep configuration creation logic.
This essentially implements the following TODOs:
https://github.com/bazelbuild/bazel/blob/bc6045dcc8fa33d4241d231138020ac4bdecc14f/src/main/java/com/google/devtools/build/lib/skyframe/ConfiguredTargetFunction.java#L599
https://github.com/bazelbuild/bazel/blob/bc6045dcc8fa33d4241d231138020ac4bdecc14f/src/test/java/com/google/devtools/build/lib/skyframe/ConfigurationsForTargetsTest.java#L42
--
MOS_MIGRATED_REVID=134607049
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--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
|
| |
|
|
|
|
|
|
|
|
| |
Especially avoid the expectation that we compile with PIC by default.
A follow-up change changes the default target CPU used in the tests to be
the host CPU, which would otherwise break the tests.
--
MOS_MIGRATED_REVID=132533255
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
This makes the sanity check dependent on the configuration fragments returning proper roots, but it's not that bad because it already depends on them returning the proper set of implicit labels and #getImplicitLabels() will go away soon anyway.
--
MOS_MIGRATED_REVID=131705535
|
| |
|
|
|
|
|
| |
test what it's supposed to test, as pointed out by gregce.
--
MOS_MIGRATED_REVID=130661645
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This doesn't do anything yet, it's in preparation for the execroot rearranging
change. The execroot will have one bazel-out per repo, so it'll look like:
execroot/
repo1/
bazel-out/
local-fastbuild/
bin/
repo2/
bazel-out/
local-fastbuild/
bin/
genfiles/
repo3/
bazel-out/
local-fastbuild/
testlogs/
and so on. Thus, any output path (getBinDirectory() & friends) needs to know
what the repo name is. This changes so many places in the code I thought it
would be good to do separately, then just flip the functionality in the
execroot-rearranging commit.
While I was poking around, I changed all of the refs I could from getPackageRelativeArtifact() to getBin/GenfilesArtifact(), so that 1) rule implementation don't have to know as much about roots and 2) they'll be more isolated from other output dir changes.
`bazel info` and similar just return roots for the main repository.
The only "change" is passing around a target label in the Java rules.
Continues work on #1262.
--
MOS_MIGRATED_REVID=129985336
|
| |
|
|
|
|
|
|
| |
- Adds a helper routine to get all configured targets with a given label
- Enhances latebound split test to check that deps actually take expected configurations
--
MOS_MIGRATED_REVID=129906477
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
change error messages in these cases to not assume there was an execution phase.
--
MOS_MIGRATED_REVID=129723717
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
config is missing required fragments.
Before this change, Bazel crashes with the mysterious error: "Fragment
foo can't load missing options BarOptions" with no details on which target or dep
needed Foo. So figuring out the source of the error is painful.
With this change, we instead get:
//foo:foo: dependency //bar:bar from attribute "deps" is missing required config fragments: JavaConfiguration
--
MOS_MIGRATED_REVID=129143764
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=128682147
|
| |
|
|
|
|
|
| |
interfaces, in preparation for further changes.
--
MOS_MIGRATED_REVID=126924789
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=126797730
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=126673732
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
configuration creation fails because transitive fragment
visitation hits these cycles.
This makes CircularDependencyTest pass with dynamic
configurations.
It's a little bit unfortunate that BuildViewTestCase
follows a different code path to create configured targets
than production (BuildView.getConfiguredTargetForTesting
vs. BuildView.update). As a result, doing an actual build over
the rules defined in CircularDependencyTest#testTwoCycles
correctly reports the cycle, while the test itself doesn't.
That means the test isn't 100% faithfully testing production
logic.
But I'm not interested in fixing the gap between
BuildView.update and BuildView.getConfiguredTargetForTesting
in this change. That's part of a larger refactoring effort
on the various forked ways of acccessing configured targets
and dependencies in BuildView.
--
MOS_MIGRATED_REVID=125118553
|
| |
|
|
|
|
|
|
|
| |
This involved refactoring BuildViewTestCase a bit so that its behavior is closer to that of Bazel with --experimental_interleave_loading_and_analysis.
RELNOTES:
--
MOS_MIGRATED_REVID=124816624
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, analysis-time cycle detection expects all cycles to come from ConfiguredTargetFunction.
With dynamic configurations, ConfiguredTargetFunction calls out to TransitiveTargetFunction to figure out which configuration fragments its deps need.
If there's a cycle between the current target and a dep, the dep's TransitiveTargetFunction fails, which the current cycle detection code can't handle.
But even if it could handle it, since the failure occurs in the dep we'd get error messages like:
"in cc_library rule //the:dep: cycle in dependency graph"
instead of the expected:
"in cc_library rule //the:top_level_rule: cycle in dependency graph"
This used to not be a problem because loading-phase cycle detection caught the cycle before all this triggered. But interleaved loading and analysis removes that gate.
Tested: BuildViewTest cycle detection tests with dynamic configurations turned on
--
MOS_MIGRATED_REVID=124391277
|
| |
|
|
|
|
|
|
|
|
| |
don't yet support fragments from late-bound attributes.
This is intended to extend to any other class of errors that can't
already be centrally encoded somewhere in the production logic.
--
MOS_MIGRATED_REVID=124384937
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
helpers to enforce concurrency synchronization points and determinism even if they are not using an InMemoryGraph-backed evaluator.
--
MOS_MIGRATED_REVID=121977783
|
| |
|
|
|
|
|
| |
target. We also no longer say that the target will not be built because it may well happen during a query, when no building is happening anyway.
--
MOS_MIGRATED_REVID=120130554
|
| |
|
|
|
|
|
|
|
|
| |
Aspect becomes a triple (AspectClass, AspectDefinition,
AspectParameters) and loses its equals() method.
After this CL, SkylarkAspectClass.getDefintion still exists and is
deprecated.
--
MOS_MIGRATED_REVID=119159653
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=114304151
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This only applies to interleaved loading and analysis - the production code
is fine.
Add tests for the RedirectChaser, the fdoOptimize code path, the XcodeConfig,
and the Jvm loader. Unfortunately, the configuration factory we internally
create by default contains a mock Jvm loader implementation. Since that is one
Yak too many right now, I'm adding a temporary method to the AnalysisMock.
I added the tests to BuildViewTest for now; technically, they ought to go
into the language-specific test cases, but that would require more refactoring
as those don't currently run with interleaved loading and analysis.
--
MOS_MIGRATED_REVID=114221476
|
| |
|
|
|
|
|
|
| |
In the interleaved case, loading errors can occur during configuration creation
and we need to correctly report such errors in that case.
--
MOS_MIGRATED_REVID=113826273
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=113649677
|
| |
|
|
|
|
|
|
| |
Add test coverage by re-running BuildViewTest with the new Skyframe loading
phase runner.
--
MOS_MIGRATED_REVID=113517509
|
| |
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
|
| |
Apparently, there's at least one case where errors are printed, but we exit
with a zero exit code. How's that.
--
MOS_MIGRATED_REVID=112950105
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=112780859
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=108862983
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=108794598
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=108533147
|
|
|
--
MOS_MIGRATED_REVID=108501464
|
lberki
gregce
nharmata
Michael Staib
Dmitry Lomov
Ulf Adams
Carmi Grushko
Janak Ramakrishnan
Kristina Chodorow
Florian Weikert