aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/test/java/com/google
Commit message (Collapse)AuthorAge
* For --checkHashMismatch=ERROR, emit all errors instead of stopping at the ↵Gravatar cushon2018-04-26
| | | | | | first one PiperOrigin-RevId: 194491274
* Allow class prefix names to be blacklisted from DynamicCodec use.Gravatar janakr2018-04-26
| | | | PiperOrigin-RevId: 194487570
* Replace ConfigurationTransition with PatchTransition in a few places.Gravatar mstaib2018-04-26
| | | | | RELNOTES: None. PiperOrigin-RevId: 194459347
* RuleTransitionFactory returns NoTransition instead of null.Gravatar mstaib2018-04-26
| | | | | RELNOTES: None. PiperOrigin-RevId: 194433721
* Abstract away the param file write action from tests.Gravatar tomlu2018-04-26
| | | | | | | | | | | Rule authors frequently wants to make assertions on the parameter files their rule implementations have created. However, if they do not explicitly create parameter file write actions, or if indeed _there aren't_ any parameter file write actions inserted into the action graph, the tests will fail. This CL puts an abstraction between the tests and obtaining their parameter files, allowing us to change the implementation without updating hundreds of lines of test code in the same CL. Note that we can no longer sanely assert that the parameter file argument is inserted into the main command line, because the parameter file system controls both whether it is inserted and the name used. Those assertions have been removed where found. RELNOTES: None PiperOrigin-RevId: 194430947
* Adds support for remote files.Gravatar shahan2018-04-26
| | | | PiperOrigin-RevId: 194413337
* Abstract away the param file write action from tests.Gravatar tomlu2018-04-26
| | | | | | | | | | | Rule authors frequently wants to make assertions on the parameter files their rule implementations have created. However, if they do not explicitly create parameter file write actions, or if indeed _there aren't_ any parameter file write actions inserted into the action graph, the tests will fail. This CL puts an abstraction between the tests and obtaining their parameter files, allowing us to change the implementation without updating hundreds of lines of test code in the same CL. Note that we can no longer sanely assert that the parameter file argument is inserted into the main command line, because the parameter file system controls both whether it is inserted and the name used. Those assertions have been removed where found. RELNOTES: None PiperOrigin-RevId: 194411047
* Abstract away the param file write action from tests.Gravatar tomlu2018-04-26
| | | | | | | | | | | Rule authors frequently wants to make assertions on the parameter files their rule implementations have created. However, if they do not explicitly create parameter file write actions, or if indeed _there aren't_ any parameter file write actions inserted into the action graph, the tests will fail. This CL puts an abstraction between the tests and obtaining their parameter files, allowing us to change the implementation without updating hundreds of lines of test code in the same CL. Note that we can no longer sanely assert that the parameter file argument is inserted into the main command line, because the parameter file system controls both whether it is inserted and the name used. Those assertions have been removed where found. RELNOTES: None PiperOrigin-RevId: 194400303
* Abstract away the param file write action from tests.Gravatar tomlu2018-04-26
| | | | | | | | | | | Rule authors frequently wants to make assertions on the parameter files their rule implementations have created. However, if they do not explicitly create parameter file write actions, or if indeed _there aren't_ any parameter file write actions inserted into the action graph, the tests will fail. This CL puts an abstraction between the tests and obtaining their parameter files, allowing us to change the implementation without updating hundreds of lines of test code in the same CL. Note that we can no longer sanely assert that the parameter file argument is inserted into the main command line, because the parameter file system controls both whether it is inserted and the name used. Those assertions have been removed where found. RELNOTES: None PiperOrigin-RevId: 194400070
* Add execution information to standalone test results.Gravatar Benjamin Peterson2018-04-26
| | | | | | | | | | | | | | | In StandaloneTestStrategy, copy as much information as SpawnResult makes available to us through to both the TestResultData and BEP's TestResult.ExecutionInfo protos. One immediate consequence is that the UI and BEP can tell you whether a test result was cached remotely. I changed Executor.getEventHandler to return an ExtendedEventHandler because it makes this change easier to test. Closes #5081. Change-Id: I94fefdcd2e029c81085076736ad13a4bdf1bae8f PiperOrigin-RevId: 194383009
* Prepare to abstract away the param file write action from tests.Gravatar tomlu2018-04-26
| | | | | | | | | Rule authors frequently wants to make assertions on the parameter files their rule implementations have created. However, if they do not explicitly create parameter file write actions, or if indeed _there aren't_ any parameter file write actions inserted into the action graph, the tests will fail. This CL adds necessary methods for the migration. RELNOTES: None PiperOrigin-RevId: 194379748
* Support deferred param files.Gravatar tomlu2018-04-25
| | | | | | | | | | | | | Design doc: https://docs.google.com/document/d/1JXqwwVHYosZOgmjN8xrfTalyhiUYJ99Qe2D0qBcqZ1c The behaviour is gated on --defer_param_files (default off) and is controlled by --min_param_file_size. This CL adds support for VirtualActionInputs to LocalSpawnRunner, and all remote runners already supports them. The sandboxed runners are not yet supported, but that can be added in a future CL. This CL does not add support for spawn runner using different param file limits. This will require refactoring of the spawn strategies and runners to be viable. RELNOTES: None PiperOrigin-RevId: 194265291
* Prevent Skylark actions from setting arbitrary execution infoGravatar ulfjack2018-04-25
| | | | PiperOrigin-RevId: 194236287
* Serialize singleton NestedSets directly in NestedSetCodecWithStore.Gravatar cpeyser2018-04-25
| | | | PiperOrigin-RevId: 194232982
* Make output name case-insensitive while calculating output names for object ↵Gravatar pcloudy2018-04-25
| | | | | | | | | files This change is due to Windows and macOS, where file paths are case-insensitive RELNOTES: PiperOrigin-RevId: 194223755
* Refactor generated objc sources compilation in ProtobufSupport.javaGravatar pcloudy2018-04-25
| | | | | | | Moving CompilationSupport out of for loop. All generated object-c files will be compiled in one CompilationHelper, which avoids object file path conflicts. RELNOTES: None PiperOrigin-RevId: 194215804
* Make the static_link_cpp_runtimes feature settableGravatar Googler2018-04-24
| | | | | | | | | | | as a normal feature. Prior to this cl, it was always set by examining supports_embedded_runtimes. DELTA_BY_EXTENSION=java=100,py=15 RELNOTES: None PiperOrigin-RevId: 194172053
* Fix profiler slow task limitingGravatar michajlo2018-04-24
| | | | | | | | Looks like a typo resulted in getSlowestTasks accumulating way more than it should have and we were missing the test coverage to catch it. RELNOTES: None PiperOrigin-RevId: 194169355
* Remove JavaConstraintsProvider, allow specifying constraints when ↵Gravatar kmb2018-04-24
| | | | | | constructing JavaInfo providers instead PiperOrigin-RevId: 194123199
* Add new-style JavaInfo provider constructor.Gravatar tomlu2018-04-24
| | | | | | | | | | | | Design: https://docs.google.com/document/d/1ubah6phuvWnugShtVgSQnaopQ1BtKtNxQASVwGZA7k0/ * Moves action construction out into java_common.run_ijar, java_common.pack_sources * Deprecates corresponding arguments in JavaInfo An incompatible flag will be added in another CL since it is not possible to add incompatible flags at the same time as new functionality is added. RELNOTES: Adds new-style JavaInfo provider constructor. PiperOrigin-RevId: 194111925
* Ensure make variables from the CcToolchainProvider end up in theGravatar jcater2018-04-24
| | | | | | TemplateVariableInfo. PiperOrigin-RevId: 194088329
* Introduce @SkylarkCallable.selfCall, to signify the containing class should ↵Gravatar cparsons2018-04-24
| | | | | | | | | | | | be treated as a callable skylark object. This will allow Skylark Provider objects to be better specified. For example, "JavaInfo" can have a fully-documented, fully-specified @SkylarkCallable method with selfCall=true to represent the method JavaInfo(), instead of being a subclass of BaseFunction and requiring a @SkylarkSignature annotation. There are no usages of this pattern introduced in this CL, and also no updates to docgen to support the new pattern. These will be introduced in another CL. RELNOTES: None. PiperOrigin-RevId: 194088227
* SourceArtifacts are interned on deserialization using an ArtifactFactory. ↵Gravatar cpeyser2018-04-24
| | | | | | This should reduce memory consumption in NestedSet deserialization, which currently does not recycle Artifact instances. PiperOrigin-RevId: 194083901
* Make the constructor of TemplateVariableInfo available in Skylark.Gravatar lberki2018-04-24
| | | | | | RELNOTES[NEW]: TemplateVariableInfo can now be constructed from Skylark. PiperOrigin-RevId: 194072452
* Properly report completion of shared actions with input discoveryGravatar hlopko2018-04-24
| | | | | | | | | | | | | | Currently we report "Analyzing" when include scanning runs. But since we can have shared C++ compile actions, only one of the group will be executed and only one will be reported completed. Remaining shared actions currently stay with "analyzing" forever. This cl makes sure that these actions are properly handled when finished. This is an encore of https://github.com/bazelbuild/bazel/commit/24f19ec2679dd93b1ac5b06e46f3b35807d6e217. In this incarnation I make sure that all actions that discover inputs are consistent in reporting their Analyzing status. Originally only CppCompileAction was doing that. Apparently we have more actions that discover inputs (e.g. LtoBackendAction) but these were not reporting Analyzing and therefore crashing on preconditions. This cl makes sure that all actions discovering inputs report their analyzing status. RELNOTES: None PiperOrigin-RevId: 194066513
* Add getters to JavaCompilationArgsProviderGravatar cushon2018-04-24
| | | | | | | | | | for direct, transitive, and full compile-time jars; runtime jars; and instrumentation metadata. These are trivial wrappers around the corresponding getters on the recursive and non-recursive JavaCompilationArgs objects. This is a no-op refactoring in preparation for flatting JavaCompilationArgs into JavaCompilationArgsProvider. PiperOrigin-RevId: 194047064
* Cleanup LibraryToLinkCollector to properly distinguish C++ runtimes from ↵Gravatar hlopko2018-04-24
| | | | | | | | | | | | | | | | dynamic libraries Term runtime input had 2 meanings in CppLinkAction: 1) input needed at runtime - dynamic library 2) input corresponding to the C++ runtime (libstdc++ or libc++) This confused me and therefore the code :) This cl cleans this up to some extent by: * renaming runtimeInput to runtimesInput, to at least give the reader a chance to catch the difference :) * treating runtimesInputs as normal linker inputs, also downstream in CppLinkAction and LinkCommandLine * Simplifying LibrariesToLinkCollector by removing explicit runtimesHandling. RELNOTES: None PiperOrigin-RevId: 194046439
* Accept included headers which are provided by tree artifacts.Gravatar carmi2018-04-23
| | | | | | | This allows a C++ file to include headers from a tree artifact, and pass header inclusion checks. RELNOTES: None. PiperOrigin-RevId: 193967617
* Add the additional options to support manual trimming of feature flags.Gravatar mstaib2018-04-23
| | | | | | | | | | | | | | | | | | | There are effectively three different states a flag's value could be in: 1. Value is known to be non-default 2. Value is known to be default 3. Value is unknown (has been trimmed) In addition to flagValues (which covers the first state), there are now two additional sets covering the other two states. Neither of these sets are used when manual trimming is disabled or when the entire set of flags is known, in which case state 1 is represented by labels in the map, state 2 is represented by labels not in the map, and state 3 doesn't exist. This also adds the flag which controls whether manual trimming is active, but it currently has no effect. RELNOTES: None. PiperOrigin-RevId: 193964624
* Add a new "STRICT_ERROR" for the flag "--experimental_import_deps_checking" ↵Gravatar cnsun2018-04-23
| | | | | | | | | to check the direct dependencies for aar_import targets. Currently the default value of this flag is not changed. And it will be enabled in a separate cl. RELNOTES: None PiperOrigin-RevId: 193959866
* This change adds timestamps (call start and end time) to the remote grpc log.Gravatar Googler2018-04-23
| | | | PiperOrigin-RevId: 193937177
* Repository cache: add a put method determining the key itselfGravatar Klaus Aehlig2018-04-23
| | | | | | | | | | Add a new put method to the repository cache, that computes the cache key itself. The key is returned, so it can be reused without having to recompute it. This is a convenient interface for caching a file that was downloaded without prior knowledge of its hash. Change-Id: I6ac844f4166bf64498b87e483896d155df35475e PiperOrigin-RevId: 193889444
* Optionally suppress ThinLTO indexing for all linkstatic targetsGravatar Googler2018-04-20
| | | | | | | | | | | | | | | This extends the scalability fix in https://github.com/bazelbuild/bazel/commit/8c5e290dfab3cab378a9ca107ecdd6267403cd4b to optionally apply to all statically linked targets. Some test invocations end up building non-testonly cc_binary that are in the transitive data deps of a test, and can lead to huge numbers of LTO backend jobs for those test invocations. With this change, the global blazerc can enable this feature for "blaze test". This can end up subsuming the thin_lto_linkstatic_tests_use_shared_nonlto_backends feature. However, it might be useful to keep that one as it can be the default for all blaze builds (in case anyone wants to just build and not run their tests). RELNOTES: None PiperOrigin-RevId: 193667161
* Make action_config.tools include crosstool top path by defaultGravatar hlopko2018-04-20
| | | | | | | | | | | We always prepend crosstool top path anyway, so let's create Tool instances with the already prepared path. I don't expect this affects memory usage since we don't have many cc_toolchain targets in the graph. RELNOTES: None PiperOrigin-RevId: 193660445
* C++: Wraps CcExecutionDynamicLibrariesInfo inside CcLinkingInfo.Gravatar plf2018-04-20
| | | | | RELNOTES:none PiperOrigin-RevId: 193657227
* Bring back --copts to linkstamp compile actionsGravatar hlopko2018-04-20
| | | | | | | | Unintentional sideeffect of https://github.com/bazelbuild/bazel/commit/119d8ecfba898799a9ad39eb756fa0247739a4a6 was that linkstamp compile action stopped receiving flags from --copt (blaze option). This cl fixes that. RELNOTES: None. PiperOrigin-RevId: 193655939
* Remove use of bare Immutable{List,Map,Set} Builder classes.Gravatar jcater2018-04-20
| | | | | | Always use the more-qualified class name for clarity at the site of use. There are too many classes named Builder. PiperOrigin-RevId: 193649193
* Extract CcCommon.configureFeaturesOrThrowEvalExceptionGravatar hlopko2018-04-20
| | | | | | | | | This method will be available to Skylark. Native rules will use the wrapped version in CcCommon.configureFeaturesOrReportRuleError. The error message shown in case of conflicting features was modified slightly. RELNOTES: None. PiperOrigin-RevId: 193639182
* Thread more information through CcToolchainProvider for ↵Gravatar hlopko2018-04-20
| | | | | | | | | | CcCommon.configureFeatures The goal is to enable creation of feature configuration without the rule context. This will enable us to have cleaner API for this in Skylark. RELNOTES: None PiperOrigin-RevId: 193630386
* 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
* Introduce PackageErrorMessageValueGravatar mschaller2018-04-19
| | | | | | | | | | This CL introduces a new intermediate SkyValue type, PackageErrorMessageValue, to be used by RecursivePkgFunction. RecursivePkgValue will now have a direct dep on PackageErrorMessageValue rather than PackageValue. RELNOTES: None PiperOrigin-RevId: 193549158
* Logging the spawn graph on demand. First step on #4891.Gravatar olaola2018-04-19
| | | | | | | | This is a very heavy and slow option by design. It will be enabled only when a user wants to debug their build, most frequently to compare the step-by-step results of two builds. TESTED: manually on various rules, including directories. RELNOTES: None PiperOrigin-RevId: 193539034
* Introduce NestedSetStore, which persists information used for NestedSet ↵Gravatar cpeyser2018-04-19
| | | | | | serialization. PiperOrigin-RevId: 193536486
* Rename SpawnExecutionPolicy -> SpawnExecutionContext.Gravatar tomlu2018-04-19
| | | | | | | | This class will be used to tie a Spawn to a SpawnRunner, and isn't really a policy object. It will carry state such as the expanded inputs and expanded command line. Currently a context can be passed between different SpawnRunners. This will be addressed independently, so a context is tied to a particular spawn runner. PiperOrigin-RevId: 193501918
* Automated rollback of commit 559ffb7dd6578c961e775ba4901917ab8bffcb9d.Gravatar janakr2018-04-18
| | | | | | | | | | | | *** Reason for rollback *** Looks like this is using more cpu than I realized. Doesn't seem fixable short-term. This may need to be cherrypicked into the next canary if it shows up in profiling. See bug for details. *** Original change description *** Add ValueConstants helper to handle the increasingly complex logic for value-equality-tested constants. Main hurdle is efficiently testing to see if a Collection is a value constant without trying to do work on Collections that can't possibly be value constants. PiperOrigin-RevId: 193403226
* Add deploy jar to android_local_test.Gravatar Googler2018-04-18
| | | | PiperOrigin-RevId: 193390754
* PiperOrigin-RevId: 193371485Gravatar carmi2018-04-18
|
* Setup for wiring up decoupled data processing in top-level targetsGravatar asteinb2018-04-18
| | | | | | | | | | | | - Expose manifest merging logic from ApplicationManifest - Use it to reimplement manifest merging in new AndroidManifest class - Track merged resources zip in ResourceContainer - we shouldn't be forced to use hacks to get it - Clean up return type of ProcessedAndroidData.generateRClass - a ResourceApk is the general type used to wrap fully processed data. RELNOTES: none PiperOrigin-RevId: 193367162
* Clean up IterablesChain.Gravatar tomlu2018-04-18
| | | | | | | | | | | * Change builder return type to Iterable<T> instead of IterableChain<T>. It is over-specified and unnecessary to state the return type so precisely. * Optimize builder for cases where we add 0 or 1 iterables to the chain. In this case, we can simply return the underlying iterables without adding wrappers. * Extract DedupingIterable, it doesn't have anything to do with IterablesChain and is only used in one place RELNOTES: None PiperOrigin-RevId: 193363048
* Create pipeline for monolithic data processing with decoupled classesGravatar asteinb2018-04-18
| | | | | | | | | | | The AndroidResourceProcessingAction does all of asset parsing and merging and all of resource parsing, merging, and validation except for R class generation, all in one action. Add class to wrap the intermediate output of this action. It can trigger R class generation to create a full ValidatedAndroidResources object. RELNOTES: none PiperOrigin-RevId: 193350591