aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/test/java
Commit message (Collapse)AuthorAge
...
* Automated rollback of commit 5a9befc5602e71f7512074c303afbdcff5617cca.Gravatar twerth2018-06-22
| | | | | | | | RELNOTES: None *** Reason for rollback *** PiperOrigin-RevId: 201686843
* Move HashFunction out of FileSystem, and turn it into a class, instead of an ↵Gravatar ccalvarin2018-06-21
| | | | | | | | | enum. Now that we aren't using enum names for the hash functions, we also accept the standard names, such as SHA-256. RELNOTES: None. PiperOrigin-RevId: 201624286
* Audit usages of Label.getRelative and update to Label.getRelativeWithRemappingGravatar dannark2018-06-21
| | | | | RELNOTES: None PiperOrigin-RevId: 201617188
* Remove unused vfs deps.Gravatar dannark2018-06-21
| | | | | RELNOTES: None PiperOrigin-RevId: 201594295
* Remap labels that include a repository name that appear in $(location x).Gravatar dannark2018-06-21
| | | | | RELNOTES: None. PiperOrigin-RevId: 201588988
* Create a method for initializing build API libraries using object instances ↵Gravatar cparsons2018-06-21
| | | | | | | | | instead of object classes. This allows the caller to, for example, initialize the global library before adding it to a global frame. The skylark interpreter will no longer require that global libraries have a zero-arg constructor. RELNOTES: None. PiperOrigin-RevId: 201563608
* Take into account repository mapping when processing labels inside BUILD ↵Gravatar dannark2018-06-21
| | | | | | | | | | | | | | | | | | | | | | | | | files within external repositories. For example: a/BUILD genrule( name = "a", srcs = ["@x//:x.txt"], outs = ["result.txt"], cmd = "echo hello > \$(location result.txt)" ) If the main workspace file references that repository with a rule: local_repository( name = "other_repo", path = "../a", repo_mapping = {"@x" : "@y"} ) Then when a/BUILD is evaluated, the string "@x//:x.txt" will be turned into a Label "@y//:x.txt" RELNOTES: None PiperOrigin-RevId: 201562148
* Migrate DefaultInfo and its provider to skylarkbuildapiGravatar cparsons2018-06-21
| | | | | RELNOTES: None. PiperOrigin-RevId: 201544076
* Skylark debugging protocol: only track paused or stepping threads.Gravatar brendandouglas2018-06-21
| | | | | | | | | | | | | | | | | | | | | | | | - remove blaze-side thread creation/destruction hooks - remove ListThreads, ThreadStarted, ThreadEnded events from protocol - don't track unpaused, not stepping threads in ThreadHandler The threading model didn't provide useful information -- in practice, users never want to list currently-running threads, and the debug client doesn't need to list currently-paused threads, since it receives each ThreadPaused and ThreadContinued event, so its model is always up to date. Not tracking thread creation/destruction greatly simplifies the API, and reduces the blaze-side hooks -- it was also only semi-implemented, as plenty (/most?) skylark threads were never registered. The biggest cost to removing this is lack of nice thread names. In practice, I think the benefits greatly outweigh this cost. If it ever becomes a problem, there are other lighter-weight ways of communicating thread names. TAG_CHANGE_OK=This proto has never yet been used TYPE_CHANGE_OK=This proto has never yet been used PiperOrigin-RevId: 201532462
* Fix NoSuchElementException when BuildEventArtifactUploaderMap has no elements.Gravatar lpino2018-06-21
| | | | | | When there are no uploaders in BuildEventArtifactUploaderMap then we should use the BuildEventArtifactUploader.LOCAL_FILES_UPLOADER as a fallback. Added some unit tests as regression tests for the underlying issue. PiperOrigin-RevId: 201529578
* Extract logic from CROSSTOOL in CrosstoolInfo providerGravatar rosica2018-06-21
| | | | | | | | | CrosstoolInfo carries the necessary information from the CROSSTOOL text proto. Later on, instead from the CROSSTOOL file and the corresponding CToolchain, CrosstoolInfo will be derived from a skylark_crosstool rule implemented in Skylark. Therefore CToolchain involvement in CppConfiguration and CcToolchain creation needs to be eliminated. Work towards issue #5380 RELNOTES: None. PiperOrigin-RevId: 201491207
* Automated rollback of commit 2b015c53c89815472923d8ea0c94640b7db2fa20.Gravatar twerth2018-06-21
| | | | | | RELNOTES[NEW]: Allow @ in package names. PiperOrigin-RevId: 201487916
* Automated rollback of commit 45b308a62f42c2c0bcfe79dcd4046c4025a31059.Gravatar janakr2018-06-20
| | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Breaks Javascript compilation. There's currently no way to iterate over a depset of Artifacts and deduplicate by identical paths in Skylark. This means that actions that want to do something once per Artifact in a depset (add a flag to the command line with the path of the Artifact for instance) will have duplicate entries if there are multiple Artifacts with the same path. This is not a true automated rollback, since I tried to make this as minimal as possible, to avoid merge conflicts and keep some of the benefits of the rolled back CL. In particular, the tests that were changed in the original CL to give artifacts their correct owners did not need to be changed back, since the owners are still correct. Moreover, this effectively contains rollbacks of unknown commit and https://github.com/bazelbuild/bazel/commit/39d6f89644107a8f7c080c4f4aec8527c1a73954, but keeps test coverage from those CLs as well. Comments added to CL thread where not a clean rollback (there are plenty of files not changed at all: ActionArtifactCycleReporter is the main wart, since it can still handle SkyKeys with Artifact as the argument, but Artifact is no longer the argument to any SkyKey). RELNOTES: None *** Original change description *** Make Artifact#equals take the owner into account for derived artifacts. Derived artifacts' owners are important because they are used to determine the artifact's generating action. Source artifacts' owners are not used in this way, so I left them alone. This allows us to get rid of most uses of ArtifactSkyKey. We may be able to delete it entirely in a follow-up. PiperOrigin-RevId: 201464780
* Add a minimum_os_version flag that is platform agnostic.Gravatar Googler2018-06-20
| | | | | | | | | | | | | | This corresponds to the os version in the clang target triple, though clang does have corresponding os_version_min flags for Apple platforms. Currently, Bazel has --XX_minimum_os flags for XX values corresponding to Apple platforms. This flag is the generic version of that (and can and will be set after the Apple split transition, and will eventually be set in the Android split as well) to support various Android API level improvements for native code. PiperOrigin-RevId: 201453961
* Clean up after ↵Gravatar cushon2018-06-20
| | | | | | | | https://github.com/bazelbuild/bazel/commit/2a9e125499c8fadb731420a1a9dfe7adc8f08792 Bazel now supports @bazel_tools//tools/jdk:current_host_java_runtime. PiperOrigin-RevId: 201441513
* Be more generous with user time and sys time bounds in execution statistics ↵Gravatar ruperts2018-06-20
| | | | | | | tests. RELNOTES: None. PiperOrigin-RevId: 201432990
* Remove all uses of RuleDefinitionEnvironment#getLabel, replacing them with ↵Gravatar janakr2018-06-20
| | | | | | | | | | Label.parseAbsoluteUnchecked. Label already interns all labels, so the additional interning being done in every ConfiguredRuleClass.Builder was pointless memory and CPU. Keeping the RuleDefinitionEnvironment around makes things harder to serialize. Done using IntelliJ structural replace and then a super-painful adding of imports to every file that didn't compile (have to learn a better way to do this). PiperOrigin-RevId: 201427027
* Allow structField callables to specify useSkylarkSemantics, useLocation, and ↵Gravatar cparsons2018-06-20
| | | | | | | | | | useEnvironment Unfortunately this doesn't work for all callers, namely NativeInfo objects, as they may have structField callables invoked from contexts that have no environment available. RELNOTES[INC]: Skylark structs (using struct()) may no longer have to_json and to_proto overridden. PiperOrigin-RevId: 201376969
* Migrate Actions provider to skylarkbuildapiGravatar cparsons2018-06-20
| | | | | RELNOTES: None. PiperOrigin-RevId: 201367075
* Don't instrument files generated by cc_proto_library for coverageGravatar Googler2018-06-20
| | | | | RELNOTES=None PiperOrigin-RevId: 201365986
* C++: Re-writes cc_import in Skylark.Gravatar plf2018-06-20
| | | | | | | I will put cc_import.bzl in Bazel in a follow up CL. RELNOTES:none PiperOrigin-RevId: 201332133
* Be more generous with user time and system time bounds for execution ↵Gravatar ruperts2018-06-19
| | | | | | | statistics tests, and increase granularity of the waits. RELNOTES: None. PiperOrigin-RevId: 201254824
* Add new BuildMetrics event to BEP.Gravatar tomlu2018-06-19
| | | | | | | To start we add just a single metric, the number of actions constructed in the current build. RELNOTES: None PiperOrigin-RevId: 201248490
* Be more permissive when dealing with rules which haveGravatar jcater2018-06-19
| | | | | | | ExecutionPlatformConstraintsAllowed set to PER_TARGET and also have an alread-existing exec_compatible_with attribute. PiperOrigin-RevId: 201238805
* Expand the abilities of codecs. Let ImmutableMultimapCodec actually handle ↵Gravatar janakr2018-06-19
| | | | | | | | LinkedHashMultimap as well. Let ImmutableSetRuntimeCodec handle some other sets. We squash these extra types into the same codec because we want them to become immutable anyway, and they can be dealt with easily by the existing codecs. Add some more non-Bazel classes that should be DynamicCodec'ed. Also, when a disallowed value is serialized, throw a SerializationException instead of crashing. This makes it easier to recover in tests. PiperOrigin-RevId: 201237631
* Add --materialize_param_files option.Gravatar tomlu2018-06-19
| | | | | | | | | When set, any action parameter files are written locally upon action execution, even when the action is executed remotely. This is mainly useful for debugging. This option is effectively implied by --subcommands and --verbose_failures, as it is likely that the user is debugging actions when using these flags. RELNOTES: Add --materialize_param_files flag to write parameter files even when actions are executed remotely. PiperOrigin-RevId: 201225566
* Add more logging when executionPlatformConstraintsAllowed is set to PER_TARGETGravatar jcater2018-06-19
| | | | | | but the "exec_compatible_with" attribute is present. PiperOrigin-RevId: 201219412
* Delete switch for nested set serialization. It's fast enough to be on by ↵Gravatar janakr2018-06-19
| | | | | | default. PiperOrigin-RevId: 201218341
* Add an option to show verbose debugging logs.Gravatar brendandouglas2018-06-19
| | | | | | | | | | Turns out the event handler (BlazeCommandEventHandler) prints almost all event types, and I don't believe there's a way to tune it. We certainly don't want these messages printed to the console unless we're debugging the debugger, so turn them off by default. PiperOrigin-RevId: 201211355
* Put a trail into every SerializationException, not just NoCodecException, ↵Gravatar janakr2018-06-19
| | | | | | and have DynamicCodec add to it. It's very useful to have this trail available when debugging or whitelisting. PiperOrigin-RevId: 201205884
* 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
* Let ConfiguredRuleClassProvider decide whether to drop the analysis cache.Gravatar mstaib2018-06-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ConfiguredRuleClassProvider can specify a predicate which accepts an OptionsDiff and the new BuildOptions in order to make a decision on whether the given diff requires the analysis cache to be dropped. This predicate is only called if all of the following hold: * there was an old configuration collection (if not, the cache is not dropped because there wasn't one yet) * the old configuration collection is not exactly equal to the new configuration collection (if it is, the cache is not dropped because it definitely hasn't changed) * the old configuration collection has the same number of configurations as the new collection (if not, the cache is always dropped because experimental_multi_cpu has changed, definitely not a flag which should cause old analysis cache to stick around!) If all of these hold, the old target configurations are paired up with the new target configurations by index in the configuration collection, and each pair is diffed. The predicate is called with each diff and the corresponding new configuration's build options. If any of these invocations returns true, the cache is dropped. Otherwise, the cache is kept for the next build. No implementation of this predicate is actually supplied for this change, so the old behavior (always drop the cache if the configuration changes at all) holds. RELNOTES: None. PiperOrigin-RevId: 201050049
* Permit marking dirty/changed a node more than onceGravatar mschaller2018-06-18
| | | | | | | | | | | | This functionality will be useful for node restarting. More than one parent node may request the restart of a shared child node, and this should not fail. Instead, the returned MarkedDirtyResult indicates whether the dirtying was redundant, and the calling code can assert on that. RELNOTES: None. PiperOrigin-RevId: 201005663
* Consider runfiles symlinks when computing Runfiles.getEmptyFilenames().Gravatar Benjamin Peterson2018-06-18
| | | | | | | | | | | | | | Runfiles.getEmptyFilenames() only considered the unconditional and pruning manifest artifacts for empty-file insertion. Actual manifest creation asks the empty files supplier for empty files over symlinks (but not root symlinks!), too. Change-Id: Ice69bbaa9e6169bff7ec5833ee7ef1b73049a4a7 Closes #5334. Change-Id: Ice69bbaa9e6169bff7ec5833ee7ef1b73049a4a7 PiperOrigin-RevId: 201002604
* Refactoring: uses OutputService for ActionFileSystem injectionGravatar shahan2018-06-18
| | | | | | Moves more Action-oriented from skyframe package, which has become very unwieldy, to action package. This is needed to avoid circular dependencies caused when build-base is needed for skyframe. PiperOrigin-RevId: 200996982
* Fix bug in NestedSetStore where racing deserializations could create ↵Gravatar janakr2018-06-16
| | | | | | multiple futures for the same fingerprint and add a test showing that racing serializations can result in duplicate writes. PiperOrigin-RevId: 200860099
* Remove topLevelConfigurationHook now that LIPO is goneGravatar gregce2018-06-15
| | | | PiperOrigin-RevId: 200801973
* Fail when resources use invalid java identifiers.Gravatar corysmith2018-06-15
| | | | | RELNOTES:None PiperOrigin-RevId: 200766836
* ActionFS supports fast digests. Add test coverage for this and some file ↵Gravatar felly2018-06-15
| | | | | | | metadata operations. RELNOTES: None PiperOrigin-RevId: 200765925
* Support ActionFS opening files with append. Also, fix ActionFS notifying its ↵Gravatar felly2018-06-15
| | | | | | | metadata consumer multiple times per inline output. RELNOTES: None PiperOrigin-RevId: 200730252
* Remove LIPO supportGravatar hlopko2018-06-15
| | | | | RELNOTES: Support for LIPO has been fully removed. PiperOrigin-RevId: 200724578
* Move remaining BazelLibrary skylark functions to MethodLibraryGravatar cparsons2018-06-15
| | | | | | | | | Ultimately, we'll need to make the call on whether these functions belong as part of the build API or as part of skylark builtins. For now, we keep them as skylark builtins. (In either case, we'll want to migrate to @SkylarkCallable, but that's for a later change) RELNOTES: None. PiperOrigin-RevId: 200723605
* Reimplement AsynchronousFileOutputStream to use a writer threadGravatar ulfjack2018-06-15
| | | | | | | | | | | | | | | | | | | | | Background: the original code is implementing the OutputStream interface. Given a sequence of write calls, the code puts each of these writes into a queue. On the other side of the queue is an unbounded thread pool, which takes the writes off the queue one by one, and then does individual blocking writes with a fixed file offset. There are three problems with the original code: 1. Writes are sent to the Kernel one-by-one. Imagine if the incoming writes a single-byte writes, then we do one kernel call for every single byte. This is the worst case. 2. Due to multithreading, the writes can get reordered. In the worst case, the order is reversed, and the kernel flushes each write to disk individually. Since the writes are not aligned to disk block boundaries, each write has to first *read* the block from disk, overwrite a few bytes, and then flush the block back to disk. On a spinning platter, this is the worst possible sequence of operations: write a block, read the same block back, write the same block again, read the same block back, etc., with each operation having to wait for a full disk rotation. Note that this gets worse if there's high thread and / or disk contention, e.g., when running a build system in the background. 3. Due to the unbounded thread pool, it may end up creating a new thread for every single write (possibly as many as one per byte written). This is also the worst case, although it's probably negligible compared to 1+2. Compared to that, this change uses an in-memory buffer before sending writes to the kernel so non-block sized writes are batched, it writes sequentially, and it uses a single thread created at the start. A single thread should be more than able to fully saturate local disk I/O, so multi-threading should ~never be a improvement here. This might look different if we had perfectly aligned writes of an integer multiple of the disk block size to a distributed network file system or a local SSD raid. If you look at the clients of this class, that's definitely not the case: this code is primarily used for local file BEP transports - we wouldn't use local file BEP transports to write to a network file system, we'd use the BES instead. It's also used to write a couple of log files, also all local - otherwise we'd add the data to BEP. These are all unaligned, ~random-sized writes. If we created a lot of these files, then using a thread pool with fewer threads than files and using non-blocking I/O might be an improvement due to the reduction in thread count, but I think it's very unlikely that we'll ever need that complexity. PiperOrigin-RevId: 200694423
* Add a mechanism for build event protocol events to upload filesGravatar ulfjack2018-06-15
| | | | | | | | This should be a no-op, mostly replacing PathConverter with BuildEventArtifactUploader, since none of the implementations perform any upload yet. PiperOrigin-RevId: 200685325
* Enable automatic trimming of test configuration when entering non-test rules.Gravatar mstaib2018-06-14
| | | | | | | | | | | | | | Note that this is not sufficient to see caching between builds on its own; currently when any flag changes, the analysis cache is reset. A follow-up will turn off this behavior when only test flags change while trim_test_configuration is on. config_settings which examine test options are treated the same as test rules; that is, they can only be successfully analyzed at the top level or when connected to the top level by an unbroken chain of test rules. RELNOTES: None. PiperOrigin-RevId: 200614584
* Automated rollback of commit 1615da781db78b7a910daf89720189c2b2e73dbe.Gravatar Googler2018-06-14
| | | | | | *** Reason for rollback *** PiperOrigin-RevId: 200605975
* SerializationCheckingGraph checks all ConfiguredTargetValues.Gravatar cpeyser2018-06-14
| | | | PiperOrigin-RevId: 200593618
* Remove fixed point config expansion.Gravatar ccalvarin2018-06-14
| | | | | | | Deprecates the flag, though it continues to exist as a no-op so that users get a warning before errors. RELNOTES: --noexpand_configs_in_place is deprecated. PiperOrigin-RevId: 200572053
* Create an ImmutableTableCodec.Gravatar mjhalupka2018-06-14
| | | | PiperOrigin-RevId: 200561008
* Expose new methods in CcToolchainProvider to eventually replace skylark ↵Gravatar juliexxia2018-06-14
| | | | | | callables that depend on CToolchain in CppConfiguration. PiperOrigin-RevId: 200559893
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-07 01:29:29 +0000