support C++20 Modules, add deps-scanner#3
Open
PikachuHyA wants to merge 51 commits intocxx20-modules-support-patch-2-testfrom
Open
support C++20 Modules, add deps-scanner#3PikachuHyA wants to merge 51 commits intocxx20-modules-support-patch-2-testfrom
PikachuHyA wants to merge 51 commits intocxx20-modules-support-patch-2-testfrom
Conversation
PiperOrigin-RevId: 633898982 Change-Id: I9b9ba62b7622844ec62650ff3a6e3eba695d05c8
This adds a bit of convenience when executing pragmas that echo back the setting. PiperOrigin-RevId: 633913983 Change-Id: If2a9f747a1fe73393dfe5608ae17d366d271892e
This is in preparation for PR 21882 which uses runfiles in a Python test. PiperOrigin-RevId: 633936625 Change-Id: Icdb93bba4f35bb6d9036e8a56351f3f1cf507743
This was accidentally set to working dir. PiperOrigin-RevId: 633945840 Change-Id: Iab8ca88d155a542078f3a528cc815db4a4ac5452
This will be necessary to implement retry loops when the database is locked by another process (SQLITE_BUSY). However, I'm exporting all of the known error codes for future convenience. They're a stable API, so hardcoding the values should be fine. PiperOrigin-RevId: 633948990 Change-Id: Ic089d2792ddab28bcba20d583fbdedbaea421c4c
PiperOrigin-RevId: 633955277 Change-Id: I5e72a4ca70437bd404f3aef814c3a6ff30e54321
This helps to discover stamped target. The change covers all rule classes that use: - cc_common.register_linkstamp_compile_action - cc_common.link - cc_common.create_linking_context_from_compilation_outputs Which indirectly covers C++ and many Starlark rules that use this. It covers directly: - native.android_binary - java_binary - py_executable All native and builtin Bazel/Blaze rules should be covered. PiperOrigin-RevId: 633968697 Change-Id: Ia80d48b9455f42e60a0733ba21402f3165904fd6
in preparation for flipping `--incompatible_top_level_aspects_require_providers ` PiperOrigin-RevId: 633973908 Change-Id: I4f1d3e4645a96aaad577faaa03c2908e849e11e9
Preview: [] PiperOrigin-RevId: 633985418 Change-Id: I2d0f5711ecd99c92cb3959585c24b646cd01cca7
Preview: [] PiperOrigin-RevId: 633994832 Change-Id: I1f5fc8114c252970c29ad359f4f1d8db0d168451
…ory. This will make it easier for garbage collection to identify them. PiperOrigin-RevId: 634007262 Change-Id: I78b836f4fbae448c2ef408e7c2f8313447cedc22
The comment was added by unknown commit where it also implemented "discard actions after execution". However, this feature was removed by unknown commit but the comment was not updated. PiperOrigin-RevId: 634018989 Change-Id: If66b77e6699a40d1e77ecfc5ca18458d5861c7dc
…ild_event_upload=MINIMAL. In particular, this ensures that the compact execution log is uploaded (for which a test has been added). ByteStreamBuildEventArtifactUploader would have benefitted from a refactor, but I'm deliberately making a minimal change that can be cherry-picked into 7.2.0 without risking a regression. PiperOrigin-RevId: 634033159 Change-Id: I4d3df757f612337b5d2b222278d1171cc8e1aed4
…as its duplicated with recently added built_values on a clean build. Keep the logic for skyfunctino in SkyFrameStats though because its now used in `dump` PiperOrigin-RevId: 634035472 Change-Id: Iff58dbeada3e3361b66c7b5037c77a9b91cf2673
According to [Kittyhawk's website](https://kittyhawk.aero/), they have ceased operations. Closes bazelbuild#22382. PiperOrigin-RevId: 634073254 Change-Id: I966616021e46cf18dcf637b7fbe6bee1b96537e4
Apparently platform(exec_properties) propagates to ctx.actions.run(execution_requirements). This means that it is possible to mark entire platforms as "no-remote-exec". Let's add some testing coverage for this, to make sure it continues to work going forward. Closes bazelbuild#22363. PiperOrigin-RevId: 634083123 Change-Id: I26d7426657ba11b75a76f3911290fcf8fe5fe066
…ackage. This is in preparation for dumping the same information at the end of regular build commands akin to `--profile`; in order to do that, it needs to be done at the end of the command so hard-wiring it into `DumpCommand` just doesn't cut it. I considered moving it to the build.skyframe package but it would have been more complicated, since the logic does entail looking at objects that the build.skyframe package doesn't know about (aspects, configured targets, etc.) so I'd have had to add another layer of abstraction, which did not look that appealing. The game plan is to dump the data into a file and reference it through BEP. RELNOTES: None. PiperOrigin-RevId: 634232183 Change-Id: I2559a2a838f9208602dcfaafd9709b9286ad306f
Closes bazelbuild#22377. PiperOrigin-RevId: 634248140 Change-Id: I601cad0aeb51e5cd5ce769f8d822cd01762ec50b
Migrate away from `@bazel_tools//tools/android:android_extensions.bzl` END_PUBLIC PiperOrigin-RevId: 634374307 Change-Id: I5addfa5703b976f3f6598a75b6518e9f7f886d88
The bind mounting scheme used with the Linux sandbox' hermetic `/tmp` feature is modified to preserve all paths as they are outside the sandbox, which removes the need to rewrite paths when staging inputs into and, crucially, moving outputs out of the sandbox. Source roots and output base paths under `/tmp` are now treated just like any user-specified bind mount under `/tmp`: They are mounted under the hermetic tmp directory with their path relativized against `/tmp` before the hermetic tmp directory is mounted as `/tmp` as the final step. There is one caveat compared to user-specified mounts: Source roots, which may themselves not lie under `/tmp`, can be symlinks to directories under `/tmp` (e.g., when they arise from a `local_repository`). To handle this situation in the common case, all parent directories of package path entries (up to direct children of `/tmp`) are mounted into the sandbox. If users use `local_repository`s with fixed target paths under `/tmp`, they will need to specify `--sandbox_add_mount_pair`. Overlayfs has been considered as an alternative to this approach, but ultimately doesn't seem to work for this use case since its `lowerpath`, which would be `/tmp`, is not allowed to have child mounts from a different user namespace (see https://unix.stackexchange.com/questions/776030/mounting-overlayfs-in-a-user-namespace-with-child-mounts). However, this is exactly the situation created by a Bazel-in-Bazel test and can also arise if the user has existing mounts under `/tmp` when using Bazel (e.g. the JetBrains toolbox on Linux uses such mounts). This replaces and mostly reverts the following commits, but keeps their tests: * bazelbuild@bf6ebe9 * bazelbuild@fb6658c * bazelbuild@bc1d9d3 * bazelbuild@1829883 * bazelbuild@70691f2 * bazelbuild@a556969 * bazelbuild@8e32f44 (had its test lost in an incorrect merge conflict resolution, this PR adds it back) Fixes bazelbuild#20533 Work towards bazelbuild#20753 Fixes bazelbuild#21215 Fixes bazelbuild#22117 Fixes bazelbuild#22226 Fixes bazelbuild#22290 RELNOTES: Paths in the Linux sandbox are now again identical to those outside the sandbox, even with `--incompatible_sandbox_hermetic_tmp`. Closes bazelbuild#22001. PiperOrigin-RevId: 634381503 Change-Id: I9f7f3948c705be120c55c9b0c51204e5bea45f61
…Starlark Return None from LibraryToLink (pic_)object_files. That semantics is needed for the reset of the linking implementation. Expose LegacyLinkerInput fields to internal Starlark implementation. Generally users shouldn't be able to get their hands on those structures. Expose constructors of LegacyLinkerInput to cc_internal, for C++ internal consumption only. Expose missing fields on LibraryToLink to Starlark, but only as a guarded APIs. Some of those fields weren't exposed before and we need to evaluate if they are truly needed, before exposing them to all the users. PiperOrigin-RevId: 634393984 Change-Id: Id31597a3b87f48566d5734d61fbb2d9ba5050e7e
It could make the initial import a bit more convenient Following the change implemented in bazelbuild/intellij#5227 (comment), the IntelliJ plugin recognizes the "default" project view file. Closes bazelbuild#21969. PiperOrigin-RevId: 634394317 Change-Id: If4e4372e6489597c65c8127bfa0c508854674380
The external_include_paths feature enables specifying include paths locally with -I and with -isystem when the project is included as an external repo. This makes it possible to set -Werror against your own headers for development without propagating this to consumers of your libraries. For some reason this was only previously enabled on linux. I do not see a reason for not also enabling it on macos. Closes bazelbuild#21949. PiperOrigin-RevId: 634394452 Change-Id: I0df91b2a2c9b4a5bd52b22e64f99ea0745cb9759
This permits `linker_files`, `compiler_files`, etc. to depend on more exotic targets than just prebuilt binaries (e.g. the typescript compiler for Emscripten toolchain). RELNOTES: `cc_toolchain` now passes runfiles for its *_files attrs (e.g. data files for a tool built for linking). PiperOrigin-RevId: 634426810 Change-Id: Ib4b745e01663403d3174a2bb326635ee9732ba2e
With native cc rules, bazel only specified strip_files as input to the automatically generated {name}.stripped action for a cc_binary target. This change makes the starlark cc rules consistent with native behavior.
Closes bazelbuild#21357.
PiperOrigin-RevId: 634430466
Change-Id: I4b8769efc77ea1597a9a080998c9bd66c7852c33
It's no longer needed - Stardoc 0.7 switched to use starlark_doc_extract only. PiperOrigin-RevId: 634499917 Change-Id: I57f06691bccf78450b7fcaf71a5987e052b7f5c2
Previously we were handling such an interrupt the same as an actual failure with the option (e.g. a package loading error in the package defining the option), which resulted in an exit code of `2` and a failure detail of `STARLARK_OPTIONS_PARSE_FAILURE`. Now we correctly use an exit code of `8` and a failure detail of `INTERRUPTED`. PiperOrigin-RevId: 634564032 Change-Id: I628c9b4abc43c5795af967436869b4a070001348
Previously the code failed when the repository was in detached HEAD state (e.g. on CI). Closes bazelbuild#22405. PiperOrigin-RevId: 634564660 Change-Id: I60d87f1f24a1dceec6b74709a571c9630cf6bcc5
Fixes a typo I made Closes bazelbuild#22424. PiperOrigin-RevId: 634645156 Change-Id: Id0b927c1842946e47c756210970755c9574d2107
Closes bazelbuild#22310. PiperOrigin-RevId: 634649479 Change-Id: If287c2d8d0bf61d42bc03a0debbd571226e96a59
… whose name is the same as the main repository. This sounds like a weird corner case, but it happens in one very prominent case, which is protobuf: it contains a `local_repository(path=".")` rule in its WORKSPACE file in order to work around the consequences of the uncomfortable fact that `@bazel_tools` depends on it. If this was *not* done, when sibling repository layout is in effect, paths in the external repo would be resolved as ones in the main repo, thus causing "undeclared inclusion" errors when running C++ actions in the external repo. This is not perfect (after all, it's ambiguous which Artifact such paths refer to), but seems to be good enough for protobuf and will go away once the `@bazel_tools -> @com_google_protobuf` dependency is cut or if bzlmod is turned on for good. RELNOTES: None. PiperOrigin-RevId: 634663132 Change-Id: Id45eaa9bdd7746b33166e838dbb834febbec9335
This is used throughout the linking code. PiperOrigin-RevId: 634716136 Change-Id: Ib7771cd9d0a11f0bcc32a927e3c7ed27e134e943
It works by passing the `--experimental_skyframe_memory_dump=json` command line option to build-like commands. If `--experimental_stream_log_file_uploads` is in effect, the file will be streamed to remote storage, if not, it'll be written to the output base to the eponymous file. Either way, its URI will be reported on the BEP as the file `skyframe_memory.json`. The format is the same as `bazel dump --memory=full,summary` and befitting an experimental option, is subject to change. This is modeled after the now-defunct `--experimental_aquery_dump_after_build_format` (that one will be deleted after this change is submitted) RELNOTES: None. PiperOrigin-RevId: 634743262 Change-Id: I3b5b4e13a252c7e6f7b4bad3067ea88753ff5931
Intricate code with a lot of potential for suttle breakages, thus keeping on first iteration very close to native implementation. This codes connects convert_linker_inputs.bzl with link_build_variables.bzl: LibraryToLink objects are first converted to LegacyLinkerInputs, then to LibraryToLinkValues. PiperOrigin-RevId: 634761527 Change-Id: I2bf5ecd60c9728cd3c00c3cf1bd10ccd1f854b96
... and get rid of the last vestiges of the legacy skydoc/stardoc extractor. PiperOrigin-RevId: 634864746 Change-Id: I04247759681bbb8095095794d418bc6f67801723
…le.devtools.build.lib.starlarkdocextract The last step of eliminating the obsolete name "skydoc" from the codebase. PiperOrigin-RevId: 635228759 Change-Id: I9fa9eb32c5ec7dd5a39fd0a16d8cca8d5102f9e2
The logic for sandboxing hermetic tmp needs to take into account all paths under `/tmp` used during the build. A user may also pass a `sandbox_base` under `/tmp` even when the `output_base` is not. This change adds `sandbox_base` to the list. Fix suggested by fmeum Closes bazelbuild#22435. PiperOrigin-RevId: 635382607 Change-Id: I32497a514ff16e64a0e0d84c307f280d3d37544b
The reverts in 3fddc7f accidentally replaced `sandboxExecRoot` with `execRoot` in the function that computes writable directories for sandbox spawn runners. This issue was observed in MobileNativeFoundation/rules_xcodeproj#3029. Closes bazelbuild#22443. PiperOrigin-RevId: 635383877 Change-Id: I3d74bf78cf97ecd267ba90b68cf1b715850aba27
PikachuHyA
force-pushed
the
cxx20-modules-support-patch-3-test
branch
from
c7ddb02 to
66eda11
Compare
…` objects. Before this, there was a case where an incoming transition with invalid configuration would pass the raw `SelectorList` to the transition, which then could not do anything useful with it. PiperOrigin-RevId: 635435608 Change-Id: I4880811cf1b4c91b93877986ef7a0a0f09276fee
…o a subclass. Work towards starlark options parser cleanup: bazelbuild#22365. PiperOrigin-RevId: 635437320 Change-Id: Ib7baa5b880a091d747e0d296761eb50753b29e91
…AnalysisMock. Work towards platform-based flags: bazelbuild#19409. PiperOrigin-RevId: 635457036 Change-Id: I53d1429ca580ef7f0c933243e4b4f953d3c9394a
The Bazel client codebase doesn't use absl, but one of the library we use (e.g. gRPC) might. We wouldn't want that to spam the Bazel's user's stderr. Thus, this CL attempts to insulate the client program from that risk. We do this by disabling absl debug logging at the point in the life of the client program where we consider `--client_debug`. This is therefore a non-foolproof approach; consider a library we use that makes debug statements before that point in the life of our program. But we also add an integration test that would catch regressions like this! I noted future improvements in code comments. PiperOrigin-RevId: 635488965 Change-Id: I26d01f9aeda3a237aa68438586f958ae01d5448d
…iles. PiperOrigin-RevId: 635500424 Change-Id: I841f96c4ef3c23fa97fa3e8bb4d1220b31888652
…sion. Otherwise, anything that depends on `@platform//cpu` will fail. Work towards platform-based flags: bazelbuild#19409. PiperOrigin-RevId: 635502289 Change-Id: I2431a7bc849d2d0b0c6b4573de6a4838ffe9478e
… attribute and the rule was referenced by an output file. PiperOrigin-RevId: 635511847 Change-Id: Iacba4d4065dbb1d089c2d4df3c1c64ae5204fe35
This is a reland of 30b95e3 with a different approach to emitting display form labels that avoids adding a new `to_display_form()` method to `Label`: * In action command lines, which are the most frequent use of labels in rule implementation functions, labels are automatically emitted in display form since 9d3a8b0. * In module extensions and repository rules, if labels can be turned into display form, the inverse of the repository mapping would need to be tracked in lockfiles and marker files for correct incrementality. Furthermore, allowing implementation functions to access apparent names would allow them to "discriminate" against them, thus possibly breaking the user's capability to map repos at will via `use_repo` and `repo_name`. Similar to how providers on a target can't be enumerated, it is thus safer to not provide this information to the implementation functions directly. This change thus implements `StarlarkValue#debugPrint` for `Label` to allow ruleset authors to emit labels in display form in warnings and error messages while ensuring that Starlark logic doesn't have access to this information. `print("My message", label)` degrades gracefully with older Bazel versions (it just prints a canonical label literal) and can thus be adopted immediately without a need for feature detection. This requires changing the signature of `StarlarkValue#debugPrint` to receive the `StarlarkThread` instead of just the `StarlarkSemantics`. Since `debugPrint` is meant for emitting potentially non-deterministic information, it is safe to give it access to `StarlarkThread`. Also improves the Bzlmod cycle reporter so that it prints helpful information on a cycle encountered in a previous iteration of this PR. Fixes bazelbuild#20486 RELNOTES: `Label` instances passed to `print` or `fail` as positional arguments are now formatted with apparent repository names (optimized for human readability). Closes bazelbuild#21963. PiperOrigin-RevId: 635589078 Change-Id: If60fdc632a59f19dad0cb02312690c15a0540c8e
…ils to set `AbortReason`. When the main command thread is interrupted during a build, it may be due to a catastrophic error that happened on another thread. In this scenario we already correctly capture the `DetailedExitCode` in the `BuildResult`, in the `BuildCompleteEvent`. We do not include a `Throwable crash` in this scenario. For the 'test'/'run' commands, the `BuildEventStreamer` was incorrectly ignoring the error details specifically when the OOM error happened on another thread and did not have a `Throwable crash` in its `BuildResult`. A similar bug may exist for non-OOM catastrophic errors. Resolving this is left for a targeted followup. PiperOrigin-RevId: 635654254 Change-Id: Ifdeb0f17463ca6d05d90077fbe6a2045c2a21ab2
RELNOTES[INC]: The --experimental_aquery_dump_after_build_format and --experimental_aquery_dump_after_build_output_file command line options are not available anymore. PiperOrigin-RevId: 635721237 Change-Id: Ie6c13337bc42e104493637ae8dc6e383165bec2b
PikachuHyA
force-pushed
the
cxx20-modules-support-patch-3-test
branch
from
66eda11 to
721c87f
Compare
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
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.
No description provided.