some fixes #2
Draft
some fixes #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently, repos like `@bazel_tools` are treated with special status in Bzlmod because they're shipped with Bazel and always visible to every other repo. This makes it harder for us to make sure repo references within `@bazel_tools` work correctly, since it doesn't go through repo mapping like everything else (example: `@rules_cc` needs to be written as `@rules_cc.0.0.1`) This CL converts such repos into special built-in modules, which are always visible to other modules (i.e. treated as implicit dependencies of every other module), and are loaded specially (i.e. as if there is always an implicit non-registry override on them). Additionally, we change the default value of --xcode_version_config to be an alias in @bazel_tools. This means that we won't need to deal with weird repo names like https://github.com/bazelbuild/bazel/blob/921d79e9d419508f60cc8a96181f38176ff6be03/.bazelrc#L34 Fixes bazelbuild#14279. PiperOrigin-RevId: 447963753
PiperOrigin-RevId: 447969104
…if the request is cancelled. Following bazelbuild@280ef69, this change fixes the issue that partial downloaded files are not deleted. The root cause is, even we cancel the download futures inside AbstractActionInputPrefetcher and then delete the files, the actual downloads inside GrpcCacheClient are not cancelled so it is still writing to the path. PiperOrigin-RevId: 447970542
- no longer need override --crosstool_top and --xcode_version_config since bazelbuild#14279 is fixed - update abseil-cpp version to fix build on latest macOS. PiperOrigin-RevId: 447976139
…_proto_library I've also done some changes that improve readability: removed/modified/added comments. PiperOrigin-RevId: 447977856
This is a temporary fix, the underlying issue is still present and needs to be addressed, but this stops failing builds. PiperOrigin-RevId: 447985361
The extra local spawn is only created when we are running locally and as such must be possible to run there. Skip creating and checking the spawn when choosing the execution strategy. PiperOrigin-RevId: 447988826
…rmation. This makes it easier to debug action conflicts because the error message shows what inputs went into computing the key for the conflicting actions. PiperOrigin-RevId: 448005997
PiperOrigin-RevId: 448011031
PiperOrigin-RevId: 448013907
PiperOrigin-RevId: 448023669
- `originalDeps` map added to `Module` to keep track of the original dependencies when doing **external dependency graph inspection**, without having to call `SkyFrame` for the `ModuleFileValues` - `ModuleBuilder` added to simplify creating `Module` object for `UnitTests` bazelbuild#15365 PiperOrigin-RevId: 448026884
- `BazelModuleResolutionValue` also stores the `unprunedDepGraph` which will be used for inspection - unit tests added to `SelectionTest` for the un-pruned dep graph bazelbuild#15365 PiperOrigin-RevId: 448028351
- `BazelModuleInspectorValue` - `SkyValue` which stores: - an unpruned dep graph with `ModuleAugment` wrapper nodes which give information about dependants and resolution rules applied - a `modulesIndex` map from *module name* to the corresponding set of `ModuleKeys` - `BazelModuleInspectorFunction` - `SkyFunction` computes the above based on the information inside `BazelModuleResolutionValue` - `BazelModuleInspectorFunctionTest` - UnitTests for the `computeAugmentedGraph` core method of the inspector function bazelbuild#15365 PiperOrigin-RevId: 448029252
e.g.
```
java_library(
...
add_exports = [
"--add-exports=jdk.compiler/com.sun.tools.javac.api",
],
)
```
At compile-time the attributes correspond to javac's `--add-exports=` and
`--add-opens=` flags, to allow code in the unnamed module to access the given
packages.
At runtime the the attributes correspond to the similar runtime flags. They
are set in the stub script, and recorded as `Add-Exports:` and `Add-Opens:`
entries in the deploy jar's `MANIFEST.MF`.
PiperOrigin-RevId: 448039045
PiperOrigin-RevId: 448079808
The new RunEnvironmentInfo provider allows any executable or test Starlark rule to specify the environment for when it is executed, either as part of a test action or via the run command. Refactors testing.TestEnvironment to construct a RunEnvironmentInfo and adds a warning (but not an error) if the provider constructed in this way is returned from a non-executable non-test rule. If a RunEnvironmentInfo is constructed directly via the Starlark constructor, this warning becomes an error. Fixes bazelbuild#7364 Fixes bazelbuild#15224 Fixes bazelbuild#15225 Closes bazelbuild#15232. PiperOrigin-RevId: 448185352
PiperOrigin-RevId: 448201784
Chunkers hold open files and memory. Normally, they are closed when the input is fully read. However, we want to make sure resources are freed in error cases, too. Closes bazelbuild#15416. PiperOrigin-RevId: 448212195
…ocalTestBaseRule. This bug was likely a copy'n'paste error in bazelbuild@cbdb2c7. It had the unfortunate consequence that `enable_data_binding` in both android_binary and android_library ended up with the incorrect documentation text in some cases (see b/232375762 for more context). PiperOrigin-RevId: 448226920
Fix bazelbuild#7982 Currently, on Windows, `ar` command can fail when using Android NDK and the arguments length is too long. This PR resolves it by enabling `--features=compiler_param_file` option for Android NDK, but I'm not sure if all commands in all versions of NDK that should be supported are compatible with this. Closes bazelbuild#14457. PiperOrigin-RevId: 448334050
Empirically, this works, and some rulesets (e.g. `rules_nodejs`) explicitly create packages whose names contain `@` characters. We should document this reality (or forbid it, but that would be a massively breaking change to the ecosystem). Additional context: https://bazelbuild.slack.com/archives/CEZUUKQ6P/p1651850227929389?thread_ts=1651832164.144609&cid=CEZUUKQ6P Closes bazelbuild#15428. PiperOrigin-RevId: 448469769
PiperOrigin-RevId: 448469795
…ether the chunker is closed. PiperOrigin-RevId: 448473842
Finalizers are on the long path to deprecation in Java. Now that we are careful to always close ZstdCompressingInputStream (bazelbuild@f923a5b), we can stop relying on the finalizer. Closes bazelbuild#15489. PiperOrigin-RevId: 448474698
PiperOrigin-RevId: 448477771
PiperOrigin-RevId: 448490237
…is unset This is used as an optimisation for Java proto libraries. PiperOrigin-RevId: 448490700
The optimisation is needed for Java proto_libraries. PiperOrigin-RevId: 448491814
PiperOrigin-RevId: 448492476
PiperOrigin-RevId: 454938886 Change-Id: I4d54128206b0144a41aac89a2cf362ae98d20715
PiperOrigin-RevId: 454955800 Change-Id: I2f447ea82175699a364f8299fde956c42769a05a
…ernResolver#bulkGetTargetsInPackage by checking if they are in error first. PiperOrigin-RevId: 454984020 Change-Id: I8b74ca76dfe8c48583f0dd3b30e98f7c4067843b
Open files to upload only when the network is ready to accept data. Empirically, this greatly reduces the need to set `--bep_maximum_open_remote_upload_files` because the small-to-medium-sized files that are common in real-world builds can be opened, dumped onto the network, and closed in one shot. Closes bazelbuild#15670. PiperOrigin-RevId: 455074457 Change-Id: I243c7e6c51b2d415cdc0a00e7e71d06aefadbd2c
Adds a flag for always printing messages returned by remotely executed actions. Closes bazelbuild#15557. PiperOrigin-RevId: 455079196 Change-Id: Iae8f150c7b28b881861ae99191dedbce50540153
The `WriteRequest.write_offset` field has bizarre semantics during compressed uploads as documented in the remote API protos: https://github.com/bazelbuild/remote-apis/blob/3b4b6402103539d66fcdd1a4d945f660742665ca/build/bazel/remote/execution/v2/remote_execution.proto#L241-L248 In particular, the write offset of the first `WriteRequest` refers to the offset in the uncompressed source. This change ensures we always seek the uncompressed stream to the correct offset when starting an upload call. The old code could fail to resume compressed uploads under some conditions. The `progressiveCompressedUploadShouldWork` test purported to exercise this situation. The test, however, contained the same logic error as the code under test. Closes bazelbuild#15669. PiperOrigin-RevId: 455083727 Change-Id: Ie22dacf31f15644c7a83f49776e7a633d8bb4bca
Actually select the options for the command and apply the command-specific invocation policy. Previously everything was considered "build" and the command passed to the invocation policy was "null", which is not what happens in production code. Making this work also required registering commands so that the invocation policy's command-inheritance logic actually worked. The list of commands isn't exhaustive, but should do the trick, easy enough to add more as we need them (I don't think we need _all_ the commands for now at least). There's still plenty to clean up around options handling in RuntimeWrapper et al - for example we should be able to pluck options classes from the registered modules instead of explicitly providing them, but that's for another change. PiperOrigin-RevId: 455110823 Change-Id: I6223f7508c785e52a160ff41739b704da5354b12
This requires moving the required information from ObjcConfiguration to CppConfiguration. CppConfiuration.objccopts now has the same information as ObjcConfiguration.copts, and we can eventually delete the latter. There are a couple slight changes in behavior: - C/C++ sources in objc_library will no longer get the options from --objccopt. This matches the behavior of other copts variants which are all done based on file extensions. - Objective-C parse header actions will no longer get the options from --objccopt. This is not likely to matter, as they are just validation actions. PiperOrigin-RevId: 455112668 Change-Id: I9dc8857fb6f2ae58dd7e33d450c1101e9e938c52
… that are applied to packages that don't exist, for example if one test_suite refers to a test in a non-existent package. This isn't expected to occur in standard usages of blaze. PiperOrigin-RevId: 455117831 Change-Id: Idc56359ce7854a41079f00f305104367add85575
…ault Downstream tests: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/2494 PiperOrigin-RevId: 455138159 Change-Id: I20a8244d3d5acff390f6e1e8fd408f999150cb1d
In the latest JDK versions, the string `allow` is not the name of a security manager, and instead indicates that the code is allowed to install a security manager of its own. PiperOrigin-RevId: 455150087 Change-Id: Iac26ec13ffd006fc3a758678e36c94dcc94beec4
When `ObjcCommon` was rewritten in Starlark in 4a0cc3b the `archives` list from `objc_import` (passed in via `extra_import_libraries`) got dropped from the `force_load_library` list in `objc_provider`. This fix adds them back so `-force_load` is correctly applied when `alwayslink` is set. Here is the original Java implementation for reference: https://github.com/bazelbuild/bazel/blob/4a0cc3b3f297f8df60022ae977e170148a4c7ae4/src/main/java/com/google/devtools/build/lib/rules/objc/ObjcCommon.java#L415-L424 This `for` loop is what was omitted in the rewrite and is what is added in this PR: ```java for (Artifact archive : extraImportLibraries) { objcProvider.add(FORCE_LOAD_LIBRARY, archive); } ``` Closes bazelbuild#15313. PiperOrigin-RevId: 455164591 Change-Id: Icc0a5aab26ec150475d82b57549b263418776141
PiperOrigin-RevId: 455180690 Change-Id: Ia15ac86fbb2a403afe64431b6252e6150b74a072
dependencies. PiperOrigin-RevId: 455186220 Change-Id: I415202a4a1910a82c8ebef4a18ff797d09b95f9b
PiperOrigin-RevId: 455205270 Change-Id: I545d02bfd7b14463bd2073c69271a0f341419a46
Use it to set "lang_objc" feature for Objective-C. A followup CL will migrate the remaining objc-specific features to cc_common, to unify the support for features, and to allow the C++ build API to set up the correct features for objc. PiperOrigin-RevId: 455231579 Change-Id: I8ff8011552cb4d8457d1513bf447d3cfa085aa76
This requires migrating the dead_strip and generate_linkmap options to CppOptions / CppConfiguration. For now, we keep the corresponding information in ObjcConfiguration, but we can eventually delete them. PiperOrigin-RevId: 455232743 Change-Id: I68cdeafe24064a7d3c56e6c090063179d1635c42
…ched directory creation. Since the action is to be rewound, it will completely re-execute including `Action#prepare`, which deletes its outputs including tree directories. Invalidate these directories in the `knownDirectories` cache so that they are created again. This change only affects builds which use rewinding without an in-memory action filesystem. This will soon be integration tested as part of b/229395817 - in fact, that's how I encountered this bug. PiperOrigin-RevId: 455250588 Change-Id: I5ca188c95d4528d7fbbfcd108b0b2192f2321d8d
This makes it easier for the crosstool to turn off warning flags that are not useful for it. Also generalize interface for enabling/disabling features, and use it to handle disabling of layering check and parse headers. PiperOrigin-RevId: 455391718 Change-Id: If5ac0f2c6dd1365e5277210da104600553bb481c
PiperOrigin-RevId: 455411406 Change-Id: I473a4c7cafa6be01ccebfac5c5549b4af6a8f730
*** Reason for rollback *** breaking blaze nightly 2022.06.16-1 *** Original change description *** Handle --objccopt in C++ Build API This requires moving the required information from ObjcConfiguration to CppConfiguration. CppConfiuration.objccopts now has the same information as ObjcConfiguration.copts, and we can eventually delete the latter. There are a couple slight changes in behavior: - C/C++ sources in objc_library will no longer get the options from --objccopt. This matches the behavior of other copts variants which are all done based on file extensions. - Objective-C parse... PiperOrigin-RevId: 455416523 Change-Id: Iccf6f951a050e14cfd309debbce9352cc456e587
The regular library was already accessible via the main_shared_library_output group but making it also available in interface_library when there is no actual interface library available is inline with the current behavior of cc_binary. RELNOTES:none PiperOrigin-RevId: 455497044 Change-Id: Ia80fed253e0c79584f23f08eb25b930362e3ff02
Adding it will make it possible to migrate the uses from proto_library_target to proto_info. When the migration is done proto_library_target will be removed. The cost of changing this now is still low, because it's not yet released/used in Bazel. PiperOrigin-RevId: 455616355 Change-Id: Ieb0f03b0600e1f90b72a61f90420675075c79a9e
RELNOTES: Singlejar accepts runtime Created-By field PiperOrigin-RevId: 455621799 Change-Id: Ie6d548b186a137e5b81d7c819f3f6f411956a9f7
Summary of changes: * Remove usage of Python rules where not necessary; the Python rules were/are being used to test features that aren't specific to the Python rules. * Use regex matching for failures instead of exact strings. The Starlark rules have slightly different phrasing or orderings of elements that don't affect behavior. This also makes the tests less brittle overall. * Disable attempting to use the Starlark implementation in all the tests requiring Python 2 (e.g. srcs_version checking etc). The Starlark implementation doesn't currently (and probably never will) support Python 2. bazelbuild#15684 filed to track removal of it in Bazel. * Disable attempting to use the Starlark implementation where toolchain resolution is required. This will eventually be implemented, but isn't is use at Google and otherwise blocks switching internally. * Tests verifying warnings are printed were removed; Starlark doesn't provide a warning facility. * Stamping is disabled in various tests because, with the Starlark implementation, it requires remote execution of actions, which some tests aren't setup for (they never needed it previously). Rather than set this up, stamping was disabled (affected tests don't require stamping anyways). PiperOrigin-RevId: 455695015 Change-Id: I82822eff05b6c0a66e65f131c9e1c8784b1573ac
…nd add incompatible_strict_action_env to maximize cache hits since command line launcher -> IDEA is the common workflow in this example
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[rules_intellij]: import scripts/ij.bazelproject as starting point, and add incompatible_strict_action_env to maximize cache hits since command line launcher -> IDEA is the common workflow in this example