| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
As suggested in readability review for https://github.com/bazelbuild/bazel/commit/2789c97149a1f253b659aa0f2401f44705a3258f. Ended up being a fair number of changes, but I think I got them all.
PiperOrigin-RevId: 163975846
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add flag --convert_lipo_to_thinlto, which allows builds with LLVM to use
ThinLTO when the user specifies LIPO + FDO flags; if that flag is not set, and
the user requests a build with LLVM, the compile will now fail.
Add an attribute supports_lipo to the DefaultCpuToolchain crosstool proto and
skip default toolchains that do not support LIPO when the user has specified
LIPO flags in the toolchain selection; this enables CROSSTOOL files to cause
an implicit fallback to a hybrid / LIPO toolchain when using an LLVM toolchain
as the default.
Add a CrosstoolBuilder to MockCcSupport and add a new method
setupCrosstoolFromScratch that allows unit tests to fully control the setup.
The other methods available in MockCcSupport will always load in a default
CROSSTOOL file and may show different unit test results depending on the
content of that file.
RELNOTES: None.
PiperOrigin-RevId: 163819246
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 163338873
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 163331254
|
|
|
|
|
|
| |
Part of the static configuration removal cleanup.
PiperOrigin-RevId: 163130922
|
|
|
|
|
|
|
|
|
| |
directory.
This will probably need some more work so that there are no name clashes with e.g. Android output directory names, but let's take one step at a time.
RELNOTES: None.
PiperOrigin-RevId: 162328750
|
|
|
|
|
|
|
| |
The option filters proto dependency can be removed from the OptionsParser. This is in response to option parser users that want to avoid the bazel-internal proto file in their dependencies.
RELNOTES: None.
PiperOrigin-RevId: 162249778
|
|
|
|
|
|
|
|
|
|
| |
OptionMetadataTags.
These are similar, no need to have both fields. Removing the "DOCUMENTED" default, the absence of UNDOCUMENTED will be used instead.
Since requiring a documentation category for undocumented options doesn't make sense, list that as one of the OptionDocumentationCategories, but list HIDDEN and INTERNAL as part of OptionMetadata. These options should list UNDOCUMENTED as their category.
PiperOrigin-RevId: 161515674
|
|
|
|
|
|
|
|
| |
These are now dead code - configuration dependencies are loaded by Skyframe
and do not need to be listed ahead of time - and were only ever used in
tests.
PiperOrigin-RevId: 161146721
|
|
|
|
|
|
|
|
| |
Move the default from the annotation to every mention. This makes the incompleteness explicit. Will add the defaults to test targets in a separate change.
Once all dependencies are cleaned up, the Option annotation will no longer allow options without the documentationCategory or effectTag, to prevent new options being added without categories while we migrate to the new option categorization.
PiperOrigin-RevId: 160281252
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 157578255
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) Remove obsolete originalOptions field. This was originally added to
support "parent" transitions, which supported config1 -> config2 -> config1
transitions by having config2 store config1's options.
The purpose of this feature was to support LIPO (which has a DATA -> TARGET
transition). But https://github.com/bazelbuild/bazel/commit/ff29c0b39cf936a2699b05edd54f483f1a037d93
makes this unnecessary.
2) Support the "disable actions" feature of the LIPO context collector configuration.
Putting this in BuildOptions make this dynamic config-compatible.
This change intentionally doesn't add disableOptions to BuildOptions.equals() or
BuildOptions.hashCode(). It'd be great to do that. But that has semantic consequences.
And we've run into really tricky bugs in the past with dynamic configurations and
BuildOptions.equals / BuildConfiguration.equals. So it's best to experiment with
that in its own change.
PiperOrigin-RevId: 154999718
|
|
|
|
|
|
| |
--print-symbol-counts.
PiperOrigin-RevId: 154843561
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here is what is done today:
bazel build -c opt --fdo_optimize=<path_to_profdata_file> //target
The .profdata file is the LLVM profiles in indexed format and bazel creates a
symlink to it from bazel-fdo/_fdo/... and compiles the target.
However, the instrumented binary generates a .profraw file and hence the
conversion to .profdata must be done manually using the llvm-profdata binary
which is shipped along with the crosstool as:
$ llvm-profdata -merge -o <path_to_profdata_file> <path_profraw_file>
We are trying to avoid this intermediate step in this change by baking this
into bazel.
This implementation does the following:
* In CppConfiguration.java, adds new tool llvm-profdata.
* In CcToolchain.java, in function create, if LLVM instrumented FDO is desired,
the profile format is checked and the profile conversion takes place.
* FdoSupport.java checks for LLVM instrumented FDO is bypassed.
RELNOTES[NEW]: Raw LLVM profiles are now supported.
PiperOrigin-RevId: 154569896
|
|
|
|
|
|
|
|
| |
restrictions.
Prevent the old category strings "undocumented," "hidden," or "internal" from being used as categories, to prevent developers from relying on deprecated behavior.
PiperOrigin-RevId: 153525499
|
|
|
|
|
|
|
|
|
|
| |
The key change is to eliminate the need to transition from the data to the target configuration by relying on out-of-band configuration state. Specifically, the old model drops LIPO options from the data configuration. In the cases when we have to switch back (i.e. TARGET_CONFIG_FOR_LIPO), those options have to get re-injected somehow. Static configurations achieve this with the global configuration transitions table. But dynamic configs have no comparable source (and they consciously eschew global state).
This cl changes the model to *keep* LIPO settings in the data config, then use a new "enableOrDisable" flag to determine whether or not to actually use them. With this model, the data -> target transition is now as simple as toggling that flag.
This change doesn't actually add dynamic config LIPO support. It's doing enough as it is, and we need to make sure it doesn't break existing LIPO semantics. Dynamic support will come as a followup.
PiperOrigin-RevId: 153504240
|
|
|
|
|
|
|
|
|
| |
These are two different concepts. Do not remove category overload compatibility in this CL, to keep this change limited to converting the current uses of category.
With some flyby formatting fixes on affected OptionsBases.
RELNOTES: None.
PiperOrigin-RevId: 153390002
|
|
|
|
|
|
|
|
| |
redirects.
--
PiperOrigin-RevId: 150647389
MOS_MIGRATED_REVID=150647389
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is intended to be used for "flags" which should never appear on the
command line - things like configuration distinguishers, which are used
internally and must be part of the build options, but should always be set
to their default value at the top level.
This is already a convention within Bazel, but doesn't actually work the way
Bazel expects - flags with spaces can be set by simply escaping or quoting
the spaces so that word splitting will not break on them. This means they
can also be matched by config_settings, which pass a single string.
Forbidding the parser from matching these flags solves both of these
unintended cases.
Existing cases like this have also been converted to internal.
--
PiperOrigin-RevId: 150497246
MOS_MIGRATED_REVID=150497246
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically:
1) Read BuildOptions instead of BuildConfiguration
2) Remove unused extra parameters
1) is especially useful for dynamic configs. Before this change, dynamic configs just didn't support attribute configurators. This is because support would require Skyframe-instantiating temporary intermediate configurations, which is horribly awkward and would massively complicate Bazel's dependency evaluation logic. Using BuildOptions instead of BuildConfiguration completely eliminates the problem.
As a bonus, dynamic configs can compose attribute configurators with any other transitions (including splits). This actually makes them more powerful than static configs. Whether anyone wants to use that composition is a different story, but that's now a policy decision vs. a technical limitation. This should also come in handy for RuleClass configurators, which will likely also leverage this.
--
PiperOrigin-RevId: 150080977
MOS_MIGRATED_REVID=150080977
|
|
|
|
|
|
|
|
|
|
| |
Closes #2543.
--
Change-Id: I0cd7566fc9ae91f3c1374eca61500a64b3cc8079
Reviewed-on: https://github.com/bazelbuild/bazel/pull/2543
PiperOrigin-RevId: 148449853
MOS_MIGRATED_REVID=148449853
|
|
|
|
|
|
|
|
| |
--dynamic_mode=auto on the command line.
--
PiperOrigin-RevId: 147824992
MOS_MIGRATED_REVID=147824992
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
flag, the headers of a target are compiled into a C++ module instead of being
parsed as their own translation unit. The module otherwise remains unused.
This way, parse_headers can be used to get a codebase ready for C++ modules.
parse_headers currently already gets close, but there are still ways in which a
header can be modules-incompatible although it parses fine.
--
PiperOrigin-RevId: 145729231
MOS_MIGRATED_REVID=145729231
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If linkstatic was explicitly set to 0 for a non-test target, we didn't set
CcLibraryHelper to create CcLinkOutputs, but would still try to link those in
instead of the compile output. Instead, pull out a variable that puts this
logic into a single spot.
Also rename the flag to --experimental_link_compile_output_separately, which
IMO makes slightly more sense. Not too important as I don't think we should
keep this flag long-term anyway.
--
PiperOrigin-RevId: 144194903
MOS_MIGRATED_REVID=144194903
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cc_binary if we are doing dynamic linking anyway. The additional option is
only for a smooth rollout and will go away once everything works as expected.
The benefit is in an incremental save-build-test-cycle. When editing a test (or
any of it's transitive headers), the linker input currently changes, meaning we
need to do the full link again before the test can run. However, in conjunction
with the option --interface_shared_objects, this actually isn't necessary. With
this new option, the test source gets compiled into a .so file and while that
file changes with each source change, the .ifso file often does not change.
Thus, the costly link linking to gether all the .so and .ifso files can be
retrieved from cache. Thus, this change should remove this linking step from
the critical path of many save-build-test-cycles.
--
PiperOrigin-RevId: 142244352
MOS_MIGRATED_REVID=142244352
|
|
|
|
|
|
|
|
|
|
|
|
| |
New option --experimental_dynamic_configs=notrim_partial automatically
switches to --experimental_dynamic_configs=off if any BuildOptions
fragment sets useStaticConfigurationsOverride().
CppOptions implements this override for FDO/LIPO.
--
PiperOrigin-RevId: 140864317
MOS_MIGRATED_REVID=140864317
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
critical paths.
When the inputs of a module M are reduced to a set S, then that same set S also
needs to be supplied to compile something that uses M. To do this, input
discovery is divided into two stages. For each CppCompileAction, the first
stage discovers the necessary modules (M above). These are then added as inputs
to ensure that they are built. The second stage then finds all the modules (S
above) that are required to use those and also adds them as inputs.
For now, the new behavior is guarded by a new flag
--experimental_prune_more_modules.
This is currently implemented by reading the .d files of used modules add
adding all their module dependencies. There are two noteworthy alternatives:
1. Hack up input discovery to understand modules, e.g. if a modular header is
hit, continue scanning from all it's headers. However, this seems very
brittle and a lot of additional information would have to be passed to the
input discovery.
2. Directly pass the results from input discovery of one CppCompileAction to
another one. However, this seems to tightly couple the execution of
different CppCompileActions and might lead to a mess of different states,
more memory consumption, etc.
With the current implementation, there is a bit of runtime overhead of
reading the .d files (many times). This could potentially be improved by
caching the results. However, even without this caching, the runtime overhead
is limited (<10%) for all builds I have tried (I have tried with builds where
all the compile results are already in the executor's cache.
--
MOS_MIGRATED_REVID=140793217
|
|
|
|
|
|
|
| |
This makes it much easier to pass options just to the LTO indexing. Previously these had to be passed via --linkopt, but that also passed the options to the final native link, which causes issues since most useful ThinLTO indexing options are plugin options and gold gives an error when these are passed to native links not involving a plugin.
--
MOS_MIGRATED_REVID=140735846
|
|
|
|
|
|
|
|
|
| |
Requiring all transitive modules to always be available can lead to long
critical paths and even unnecessary compiles in combination with the
prune_header_modules feature.
--
MOS_MIGRATED_REVID=137696794
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If this flag is disabled, Bazel continues to behave as previously - includes
reached through isystem paths are completely ignored, i.e., they don't have
to be declared in any rule. This applies primarily to cc_library.includes.
When the flag is enabled, Bazel gives an error for any such header file that
isn't declared in srcs or hdrs of a dependent rule.
Goes towards fixing #1162.
RELNOTES[NEW]: Use --strict_system_includes to apply hdrs_check=strict also to
cc_library.includes, even if sandboxing is disabled.
--
MOS_MIGRATED_REVID=137125638
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=130938527
|
|
|
|
|
|
|
|
|
|
|
| |
BuildConfiguration.
It makes much more sense there because it does *not* specify C++ #defines but BUILD variables. Also rename the getter method to make that clearer.
This allows us to remove BuildConfiguration.Fragment#getCommandLineDefines().
--
MOS_MIGRATED_REVID=129080014
|
|
|
|
| |
MOS_MIGRATED_REVID=128827694
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=124792198
|
|
|
|
|
|
|
| |
RELNOTES: The --ues_isystem_for_includes command line option is not supported anymore.
--
MOS_MIGRATED_REVID=123617061
|
|
|
|
|
|
|
| |
RELNOTES[INC]: The --cwarn command line option is not supported anymore. Use --copt instead.
--
MOS_MIGRATED_REVID=123101536
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=120115843
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119653212
|
|
|
|
|
|
|
|
|
|
| |
compilation inputs. As
of r264664, Clang doesn't require files in module maps to be present anymore if
the sources are instead available in the corresponding .pcm files.
--
MOS_MIGRATED_REVID=118670841
|
|
|
|
|
|
|
|
|
|
|
| |
Also remove a try-catch block, which was converting all configuration
creation errors to IllegalStateException.
This uncovered a bug in CppOptions, which wasn't adding host_grte_top to the
set of explicit labels.
--
MOS_MIGRATED_REVID=118654358
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=115214428
|
|
|
|
|
|
|
|
|
|
|
| |
for targets in the transitive closure of a target that is built.
Rollback of commit e01291a1a3d65cd706190c9bf0c8cfc585f38eb7.
Added an additional test to check that the configuration value is actually
effectively used.
--
MOS_MIGRATED_REVID=113836105
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=113660258
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
The change this relies on is to be rolled back.
--
MOS_MIGRATED_REVID=113564031
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
The new test apparently breaks some targets. Rolling back to fix the build.
*** Original change description ***
Include .dwp file in the runfiles for cc_test when building with Fission.
--
MOS_MIGRATED_REVID=113310353
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=113295790
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for targets in the transitive closure of a target that is built.
Previously, this would only happen if a link action for the library containing
the headers was also built; this specifically means it did not trigger if
a library didn't contain source files, as there is no link action for such
libraries. That led to no header-only libraries would get their headers parsed,
which includes all cc_public_library rules.
Adding a flag to introduce this under so we can switch it on independently from
the blaze release. Once it is switched on, we can remove the edges in the
action graph from the link actions to the header processing actions.
--
MOS_MIGRATED_REVID=112782219
|
|
|
|
|
|
|
|
|
| |
host crosstool.
RELNOTES[NEW]: --grte_top no longer also sets --host_grte_top in the absence of the latter
--
MOS_MIGRATED_REVID=112258796
|
|
|
|
|
|
|
| |
CppSemantics instead.
--
MOS_MIGRATED_REVID=111406721
|
|
|
|
|
|
|
| |
RELNOTES: Bazel does strict validation of include files now to ensure correct incremental builds. If you see compilation errors when building C++ code, please make sure that you explicitly declare all header files in the srcs or hdrs attribute of your cc_* targets and that your cc_* targets have correct "deps" on cc_library's that they use.
--
MOS_MIGRATED_REVID=106410969
|