aboutsummaryrefslogtreecommitdiffhomepage
path: root/src
Commit message (Collapse)AuthorAge
* Automated rollback of commit 6f1915114ec7af104a2649a454cc1519ce7806bf.Gravatar laurentlb2018-07-24
| | | | | | | | | | | | | | | | *** Reason for rollback *** Crash with NullPointerException *** Original change description *** C++: Remove AbstractCcLinkParamsStore from providers. 3 providers had AbstractCcLinkParamsStore as a class field, now they wrap CcLinkingInfo instead. RELNOTES:none PiperOrigin-RevId: 205885939
* Configured targets register created source artifacts with Skyframe.Gravatar shahan2018-07-24
| | | | PiperOrigin-RevId: 205876673
* update to embedded jdk to jdk10Gravatar buchgr2018-07-24
| | | | | RELNOTES: The JDK shipped with Bazel was updated to JDK10. PiperOrigin-RevId: 205865966
* Automated rollback of commit f309ad3be36363070e87eef0ee04b12f4956d601.Gravatar janakr2018-07-24
| | | | | | | | | | *** Reason for rollback *** Fixed duplicate derived inputs bug. Test is in diffbase. RELNOTES[INC]: If the same artifact is generated by two distinct but identical actions, and a downstream action has both those actions' outputs in its inputs, the artifact will now appear twice in the downstream action's inputs. If this causes problems in Skylark actions, you can use the uniquify=True argument in Args.add_args. PiperOrigin-RevId: 205863806
* ProtoSourcesProvider docs: Add link to FileDescriptorSet definitionGravatar Googler2018-07-24
| | | | | RELNOTES: None. PiperOrigin-RevId: 205850479
* Update commentsGravatar laurentlb2018-07-24
| | | | | | | Comments are misleading, as discussed on https://github.com/bazelbuild/bazel/pull/5305#issuecomment-396288826 RELNOTES: None. PiperOrigin-RevId: 205841782
* Delete --show_package_location, which has been deprecated / no-op for years.Gravatar felly2018-07-24
| | | | | | | Fixes #5592. RELNOTES: Deleting deprecated no-op flag --show_package_location PiperOrigin-RevId: 205834069
* Create the native headers jar in java_common.compile.Gravatar Irina Iancu2018-07-24
| | | | | | | | RELNOTES: java_common.compile creates the native headers jar accesible via JavaInfo.outputs.native_headers. Closes #5662. PiperOrigin-RevId: 205832180
* Minor readability cleanup.Gravatar twerth2018-07-24
| | | | | RELNOTES: None PiperOrigin-RevId: 205825362
* C++: Remove AbstractCcLinkParamsStore from providers.Gravatar plf2018-07-24
| | | | | | | | 3 providers had AbstractCcLinkParamsStore as a class field, now they wrap CcLinkingInfo instead. RELNOTES:none PiperOrigin-RevId: 205821081
* Open source SpawnExecutedEventGravatar ulfjack2018-07-24
| | | | | | | This will be used to compute the critical path using Spawns instead of Actions, which should be more accurate. PiperOrigin-RevId: 205817400
* Move LoadingPhaseCompleteEvent posting to TargetPatternPhaseFunctionGravatar ulfjack2018-07-24
| | | | | | | | | | | Also simplify LoadingPhaseCompleteEvent, and SkyframeExecutor, and remove LoadingCallback, which is unnecessary now that we only have a single implementation (previously LoadingPhaseRunner). This also removes some of the excessive Skyframe calls introduced by https://github.com/bazelbuild/bazel/commit/1067310e18cb9ac203110726de0be53bdc403cea, and prepares for interleaving target pattern eval and loading. PiperOrigin-RevId: 205813197
* Treat java_lite_proto_library and java_mutable_proto_library the same as weGravatar twerth2018-07-24
| | | | | | | treat java_proto_library. RELNOTES: None PiperOrigin-RevId: 205812269
* Windows,JNI: more tolerance for errorsGravatar Laszlo Csomor2018-07-24
| | | | | | | | | | | | | | | | | | | | | DeletePath and CreateJunction are now even more tolerant with errors, particularly the class of errors where access is denied. Also in this change: - remove DeletePathResult::kParentMissing, as this case is handled by CreateFileW's error handling later - do not error-check CreateDirectoryW; if failed, just proceed as if the directory already existed - print more debugging info where possible Change-Id: I1162dae2c6b7524f14d8892047f9eb51831470dd Closes #5611. Change-Id: I78fe6aed6d0b120815339c0923c8a903990921d9 PiperOrigin-RevId: 205796307
* Use an interface to convert from nanos to millis since epochGravatar ulfjack2018-07-24
| | | | | | | | | | | The conversion approach we were previously using is not stable - the resulting offsets can differ based on what other things are going on on the same machine at the same time. By using an interface and passing it to the relevant places (and only computing the offset once), we ensure that all conversions are consistent with each other. PiperOrigin-RevId: 205787309
* Remove redundancy in DigestHashFunction use in FileSystem.Gravatar ccalvarin2018-07-23
| | | | | | | Each FileSystem instance has a digest function, but the getDigest and getHashDigest functions also accepted their own custom parameter functions. We only support 1 hash per filesystem instance, these parameters are redundant. RELNOTES: None. PiperOrigin-RevId: 205758571
* GenClass: Assume that prefixes that don't correspond to a known ↵Gravatar cushon2018-07-23
| | | | | | non-generated source are generated. PiperOrigin-RevId: 205756917
* ArtifactFactory.getSourceArtifact returns SourceArtifact.Gravatar shahan2018-07-23
| | | | PiperOrigin-RevId: 205751282
* Clarified documentation of remote_execution_properties attribute.Gravatar jcater2018-07-23
| | | | PiperOrigin-RevId: 205729963
* Fix crash bug in AbstractExceptionalParallelEvaluator#doMutatingEvaluation ↵Gravatar nharmata2018-07-23
| | | | | | | in a very specific window of time inbetween enqueueing one top-level node for evaluation and checking if another top-level node is done. See the added unit test for details. RELNOTES: None PiperOrigin-RevId: 205718683
* Only expand dynamic_library_linker_tool feature when ↵Gravatar hlopko2018-07-23
| | | | | | | | | generate_interface_library is available This way users of the Skylark API don't see this feature expanded. RELNOTES: None. PiperOrigin-RevId: 205704719
* Annotate conditional edges with corresponding conditions in `queryGravatar dhananjayn2018-07-23
| | | | | | | | | | | --output graph`. Implementation: AIUI, currently the "edges' conditions" are lost [1] when the larger graph is initially constructed. It now does a second pass over dependency subgraph to find all the conditional edges and annotates them in dot output. This can be easily extended in other forms of output, but for now it only annotates edges in dot output. [1]: https://github.com/bazelbuild/bazel/blob/32e9fee4e2192a340d0b1823538bf8e9fdf92b65/src/main/java/com/google/devtools/build/lib/query2/output/OutputFormatter.java#L745-L770 PiperOrigin-RevId: 205685823
* Fileset manifests now propagate Artifact metadata.Gravatar felly2018-07-23
| | | | PiperOrigin-RevId: 205682761
* Fix block_for_lock.Gravatar ccalvarin2018-07-23
| | | | | | | | | | | | | | | | | | | | | | | | | | On two fronts: First, it should follow standard command line semantics. Second, it should work as intended: --noblock_for_lock means the client will not wait for another command to finish, but will exit eagerly. It can be useful for preventing hanging in applications that are non-interactively calling bazel. It should have standard startup-option semantics: the default value is accepted as a no-op or can be provided to override a previous value. The next issue involves 2 different locks - the client lock, and the server-side command lock. This duality exists because we would like, one day, to be able to run certain commands, like info or help, at the same time, so multiple commands would need specialized locks that allow some duality but blocks others. This can only be done at the server level, so as soon as the client gets the "we're connected" grpc message from the server, it releases the client lock and lets the server manage multiple requests. There are basically 3 possible states that are relevant to this option: 1) no other client is active, so no one holds the client lock or the command lock - the server can be used, shutdown or started as needed. - no blocking, but no need to block, either, so we're safe 2) another client (client1) holds the lock, but it is currently using a server that we want to reuse. If client1 still holds the client lock, we fail fast. Same thing if client1 is holding the server-side lock: we will exit gracefully when the BlazeCommandDispatcher responds with a failure. 3) client1 holds the lock but its server cannot be reused. (batch clients also fall into this category, as there is no server to reuse - but in this case, the client lock is still in play). However, for server mode, this is broken - the following happens: - Server is occupied with client1's request, holds the command lock - client2 wants to restart the server, so sends the old server a "shutdown" command - the BlazeCommandDispatcher says - nuh-uh, this is busy, and you said you didn't want to wait for the lock - client2 absorbs this response - waits (blocks...) - for a minute - then force shuts-down the old server. So we had 2 problems - we block, and we shutdown a server that we truly intended to keep going. Now, if the server responds saying another action is using it, the client will exit correctly, and leave the old server to do its thing. RELNOTES: None. PiperOrigin-RevId: 205671817
* Transition --defer_param_files into host options.Gravatar Googler2018-07-23
| | | | | RELNOTES: None. PiperOrigin-RevId: 205665675
* Windows,tests: port singlejar bash testsGravatar Loo Rong Jie2018-07-23
| | | | | | | | | | Make these tests run on Windows, but currently does not pass. /cc @laszlocsomor Closes #5652. PiperOrigin-RevId: 205658932
* Collect code coverage for binaries invoked via sh_test.Gravatar Irina Iancu2018-07-23
| | | | | | | | | Fixes #5331. Change-Id: Idb01a3f206ed37992f200f7e0e51ed9831262613 RELNOTES: Code coverage is collected for Java binaries invoked from sh_test. PiperOrigin-RevId: 205654442
* blaze.cc: add missing fflush(3) before execve(2)Gravatar Klaus Aehlig2018-07-23
| | | | | | | | | | When calling `bazel run` the command itself is executed by the client. As an execve(2) replaces the program image, including all buffered IO, flush all streams first. This will ensure that the "Running command line" message is actually printed. Change-Id: Ie18185bac4ed82a2725c75f97d3c64bd3003690b PiperOrigin-RevId: 205652760
* Remove "warn" setting for hdrs_check. This has not proven useful.Gravatar Googler2018-07-23
| | | | | | | For now, implicitly convert "warn" to "loose". RELNOTES: None. PiperOrigin-RevId: 205652060
* Add --experimental_enable_cc_toolchain_label_from_crosstool_proto flag for ↵Gravatar rosica2018-07-23
| | | | | | | | | disabling relying on CROSSTOOL file in order to select the cc_toolchain label CROSSTOOL file should not have any influence over selection of the cc_toolchain label. Ultimately the information that CROSSTOOL offers will be rerouted through an attribute of cc_toolchain. RELNOTES: None. PiperOrigin-RevId: 205651369
* jdk: use parallel old gc and disable compact stringsGravatar buchgr2018-07-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When switching to JDK9 we regressed on java build performance by about ~30%. We found that when using parallel gc instead of G1 and disabling compact strings for JavaBuilder, the java build performance is "only" 10% slower. We additionally found JDK9 to have a significantly higher startup time. This impacts the performance of tools like javac and tubine and we believe that this accounts for most of the remaining overhead that can't be explained by disabling G1 and compact strings. java8 -version: 80ms java9 -version: 140ms java10 -version: 110ms Additionally, we found that the number of modules shipped with the JDK have a direct effect on the startup time. When building Java 10 with only the 9 modules required by Bazel we find that the startup time reduces to 80ms (from 110ms) which is on par with Java 8. We thus expect the regression to be fixed by a future migration to Java 10, which should be done in one of the next Bazel releases. == Some benchmark results == https://github.com/google/protobuf $ bazel build :protobuf_java Bazel 0.15.2: 4.2s Bazel 0.16.0-rc2: 5.2s This Change: 4.2s https://github.com/jin/android-projects/tree/master/java_only $ bazel build :module0 Bazel 0.15.2: 8.2s Bazel 0.16.0-rc2: 11.5s This Change: 9.1s RELNOTES: None PiperOrigin-RevId: 205647957
* Remove special casing for --incremental-changed and --incremental-unchanged.Gravatar lberki2018-07-23
| | | | | RELNOTES: None. PiperOrigin-RevId: 205646506
* Introduce option flag experimental_enable_tools_defaults_package.Gravatar dbabkin2018-07-23
| | | | | | | | Default value is true, and behavior related to //tools/defaults package is not changed. If set it to false, then in-memory Dfaultpacked will not be created. RELNOTES:none PiperOrigin-RevId: 205643628
* Remove load() from the list of build functionsGravatar laurentlb2018-07-23
| | | | | | | | load() is not a function, but a keyword. It's already documented in other places (https://docs.bazel.build/versions/master/skylark/concepts.html#loading-an-extension). RELNOTES: None. PiperOrigin-RevId: 205636295
* Remove gender specific prononuns from Bazel codebaseGravatar hlopko2018-07-23
| | | | | RELNOTES: None. PiperOrigin-RevId: 205635805
* Suppress RepositoryCache IOException on downloadGravatar George Gensure2018-07-23
| | | | | | | | | | | | | | With invalid contents in the repository cache, silence the IOException on RepositoryCache::get and re-download an artifact when attempting to short-circuit that operation. The repository cache can easily get into this state when a build is interrupted while downloading into the non- atomic repository cache destination. Possible solution to #5390 Closes #5392. PiperOrigin-RevId: 205634761
* resolved file: include the hash of the output treeGravatar Klaus Aehlig2018-07-23
| | | | | | | | | | | | | | When reporting about the repository rules that were called, also report a hash of the tree the rule generated. This allows, at least after the fact, to verify that a repository rule actually produced the correct code. Note that equality of the output hash is not a guarantee for reproducible builds, as certain properties of the output tree, in particular owner, are ignored. Still it is a good check to detect wrong use of a repository rule. Change-Id: Ic56509f8e0d0b4be9ce3335ade280f983fe77e6d PiperOrigin-RevId: 205631855
* C++: Refactors every provider wrapping CcLinkParamsStoreGravatar plf2018-07-23
| | | | | | | | Providers that were wrapping CcLinkParamsStore now wrap CcLinkingInfo instead. CcLinkParamsStore will be deleted in a future CL. RELNOTES:none PiperOrigin-RevId: 205629924
* Remove PerActionFileCacheGravatar ulfjack2018-07-23
| | | | | | | | | | | | | Instead, make ActionMetadataHandler implement the MetadataProvider interface. This fixes an issue where an action that runs two spawns where one depends on an output of the other was unable to get the metadata for the intermediate output. We don't currently have actions that do this, but we will have in a future change (which will also implicitly act as a regression test). PiperOrigin-RevId: 205629237
* Implement a way to do include validation as a part of input discovery. ThisGravatar Googler2018-07-23
| | | | | | | | | | | | | | | | | makes it possible to disable .d file scanning when input discovery is used without allowing the usage of undeclared headers. The way this is implemented relies on having a sand-boxed or remote execution environment and simply removes undeclared files from discovered inputs. As a result, the compiler cannot see them and can diagnose missing headers. The input discovery itself cannot (usually) diagnose undeclared headers as it is often implemented to be an over-approximation. It needs to find all used headers, but it is allowed to find more. Diagnosing these additional headers would not be useful. RELNOTES: None. PiperOrigin-RevId: 205628312
* Fix TargetCompleteEvent.referencedLocalFilesGravatar ulfjack2018-07-23
| | | | | | | | It was missing the baseline coverage files, if any. This is safe even if unknown commit is rolled back. PiperOrigin-RevId: 205626149
* Use the host javac for bootstrappingGravatar cushon2018-07-22
| | | | | | | | | | | now that the bootstrap build uses the VanillaJavaBuilder it is compatible with the host JDK's javac, and avoiding -Xbootclasspath/p makes the bootstrap build more compatible with JDK 9. See #5521 RELNOTES: N/A PiperOrigin-RevId: 205605294
* bes: don't retry all status codesGravatar buchgr2018-07-22
| | | | | | | | don't retry precondition_failed and invalid_argument status codes. RELNOTES: None PiperOrigin-RevId: 205566423
* bes: make error handling saneGravatar buchgr2018-07-22
| | | | | | | | | | | | | | - refactor the BuildEventServiceClient interface to report errors via StatusException and InterruptException. - do the groundwork necessary to do retries based on rpc status codes. - improve the execution speed of the BuildEventServiceStubbyClientTest from 1m5s to 5s. RELNOTES: None PiperOrigin-RevId: 205563431
* Close the query environment after running a query.Gravatar shreyax2018-07-20
| | | | | RELNOTES: None. PiperOrigin-RevId: 205447838
* Tweak GUID for WriteBuildInfoHeaderAction to force it to be rebuiltGravatar Googler2018-07-20
| | | | | | | for this upgrade. RELNOTES=None. PiperOrigin-RevId: 205437116
* Automated rollback of commit 64ea3cd90e1ead5ece533ee5a3cb4ee3520527fb.Gravatar Googler2018-07-20
| | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Update the Flutter rules AndroidSdkInfo provider to FlutterAndroidSdkInfo. AndroidSdkInfo should be unique in the repo now. *** Original change description *** Automated rollback of commit 4d10250291a813302de64151be3b22d57e94749d. *** Reason for rollback *** AndroidSdkInfo is already being used by the Flutter rules. *** Original change description *** Expose AndroidSdkProvider to Skylark (as AndroidSdkInfo). RELNOTES: None. PiperOrigin-RevId: 205431461
* Add a new target for Stubby proto library runtime, which will eventually ↵Gravatar Googler2018-07-20
| | | | | | | | contain a subset of the current :rpc3 dependencies. This will allow the rpc3 server implementation to depend on real java_proto_libraries without a circular dependency. PiperOrigin-RevId: 205420268
* As a slight optimization in PackageFunction, treat as PERSISTENT any io ↵Gravatar nharmata2018-07-20
| | | | | | | errors encountered during the Skyframe part of hybrid globbing. The underlying transience of these is already handled by the Skyframe transience mechanism. RELNOTES: None PiperOrigin-RevId: 205403673
* Do not check if features named include_paths or preprocessor_definesGravatar Googler2018-07-20
| | | | | | | | are enabled before setting the corresponding build variables for the crosstool. Such a conditional is unnecessary. RELNOTES: None. PiperOrigin-RevId: 205397072
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-07 07:03:45 +0000