| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 198025150
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'srcs') as textually included headers.
A private header is never exported to a different module and thus cannot be
used by a different module. We never need to compile a module just because one
of it's private headers is used from somewhere else. There must be a different
cc_library (and thus module) that exports the header.
At the same time, being compiled into a module doesn't provide benefits for the
compilation of that cc_library itself, because a module created for a
cc_library A is never used when compiling any of A's srcs.
PiperOrigin-RevId: 197846388
|
|
|
|
|
|
|
| |
This unclashes with the incoming ConfigurationTransition.apply
method described in https://docs.google.com/document/d/1_UJKmAQ9EE8i3Pl0il3YLTYr-Q9EKYYyLatt2zohfyM/edit#heading=h.96gongkwg852.
PiperOrigin-RevId: 197769784
|
|
|
|
|
|
|
|
| |
using C++ modules (yet) and thus we are paying some of the cost such as
building transitive modules and a taller critical path without reaping any
benefits.
PiperOrigin-RevId: 197768129
|
|
|
|
|
|
|
| |
This abstraction is not needed anymore.
RELNOTES: None.
PiperOrigin-RevId: 197739700
|
|
|
|
|
|
|
| |
This is needed for re-writing match_clif in Skylark.
RELNOTES:none
PiperOrigin-RevId: 197738067
|
|
|
|
|
|
|
|
| |
Related issue: https://github.com/bazelbuild/bazel/issues/1013
Fix https://github.com/bazelbuild/bazel/issues/5243
RELNOTES:
PiperOrigin-RevId: 197715690
|
|
|
|
|
|
|
| |
support.
RELNOTES: None.
PiperOrigin-RevId: 197708692
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 197707463
|
|
|
|
|
|
|
|
| |
New names are dynamicLibrariesForLinkingStatically and
dynamicLibrariesForLinkindDynamically respsectively.
RELNOTES: None.
PiperOrigin-RevId: 197579028
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The difference between them is that user_link_flags will stay after we remove
legacy fields from the crosstool.
This is an encore of https://github.com/bazelbuild/bazel/commit/2661abb96b1fe51fb726a63eb08698564a82eb20 after mitigating the memory regression.
Original cl regressed 12mb (on a big enough internal project :):
objsize chg instances space KB class name
------------------------------------------------------
24 +0 190265 4459 KB com.google.common.collect.ImmutableMapEntry
40 +0 95154 3716 KB com.google.common.collect.RegularImmutableMap
47 -2 95154 2230 KB [Ljava.util.Map$Entry;
44 -1 95154 2230 KB [Lcom.google.common.collect.ImmutableMapEntry;
24 +0 95149 2230 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$MapVariables
16 +0 95149 1486 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$StringSequence
89 +0 3188 176 KB [B
64 -8 0 -743 KB com.google.devtools.build.lib.rules.cpp.LinkCommandLine
76 +0 -1918 -1323 KB [Ljava.lang.Object;
24 +0 -95149 -2230 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$SingleVariables
------------------------------------------------------
The reason was that before legacy_link_flags were the only build variable
patched because of thinlto in CppLinkActionBuilder, so it used optimized
SingleVariables subclass. With the split, the patched variables instance had 2
variables therefore it received the full blown Variables instance. That
accounted for the ~7mb.
The fix was to move the patching logic to the initial link variables creation
and not to create patched variables at all. Now the regression is ~4.8mb, which
is perfectly expected since I introduce another variable and this is the
overhead of additional hashmap entry:
objsize chg instances space KB class name
------------------------------------------------------
24 +0 190418 4462 KB com.google.common.collect.ImmutableMapEntry
44 +1 31 1487 KB [Lcom.google.common.collect.ImmutableMapEntry;
16 +0 95149 1486 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$StringSequence
47 +0 31 744 KB [Ljava.util.Map$Entry;
89 +0 5723 315 KB [B
24 +0 5721 134 KB java.lang.String
64 -8 0 -743 KB com.google.devtools.build.lib.rules.cpp.LinkCommandLine
76 +0 -2387 -840 KB [Ljava.lang.Object;
24 +0 -95149 -2230 KB com.google.devtools.build.lib.rules.cpp.CcToolchainVariables$SingleVariables
------------------------------------------------------
I'll pay this dept back once we get rid of legacy crosstool fields (= removal of
legacy_link_flags variable).
RELNOTES: None.
PiperOrigin-RevId: 197574153
|
|
|
|
|
|
|
|
| |
Instead, internally look up the correct context by mnemonic. This simplifies
all the callers. We still need a little bit of special casing when constructing
the action context map.
PiperOrigin-RevId: 197572357
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change makes Bazel respect artifact name patterns specified in
CROSSTOOL.
Users cannot specify any arbitrary name pattern, it must ends with allowed
extensions. For example, for dynamic library, it can only ends with .so,
.dylib or .dll, otherwise Bazel throws an error.
Change-Id: I21d9e6fa7c3a282e1a9b8ff29679b00925cddb33
PiperOrigin-RevId: 197553413
|
|
|
|
|
|
|
|
|
| |
New names are dynamicLibrariesForLinking and
dynamicLibrariesForRuntime respectively. This is just a cleanup to make the
code more understandable.
RELNOTES: None.
PiperOrigin-RevId: 197535811
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks perf regtest
*** Original change description ***
Split user_link_flags from legacy_link_flags
The difference between them is that user_link_flags will stay after we remove
legacy fields from the crosstool.
RELNOTES: None.
PiperOrigin-RevId: 197180518
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 197132493
|
|
|
|
|
|
|
|
| |
Instead of using a string pattern, we replace it with a prefix and an
extension.
RELNOTES: NONE
PiperOrigin-RevId: 197132215
|
|
|
|
|
|
|
|
|
|
| |
Allows for ThinLTO to be enabled once the --features=fdo_implicit_thinlto feature is enabled in the crosstool. Also allows for --features=-thin_lto to override and prevent ThinLTO from being enabled.
This is essentially the same as https://github.com/bazelbuild/bazel/commit/8e3afccd8bea45105752ddeb33bde111c556fb8b but for instrumentation FDO
instead of AFDO.
RELNOTES: None.
PiperOrigin-RevId: 197038710
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a cleanup to clarify the code.
1. The getEnvironment method in the CommandAction interface does not have
access to the clientEnv, so it's return value is necessarily incomplete.
Rename to getIncompleteEnvironmentForTesting.
2. Add a final getEnvironment method to AbstractAction, which returns the
ActionEnvironment, which is intended to be a complete description of the
intended final environment of the action (technically, of any spawn running
within the action). This is not currently used, but is provided to prevent
action subclasses to add such a method (it may be used in the future).
PiperOrigin-RevId: 196991091
|
|
|
|
|
|
|
|
|
|
| |
These were previously ignoring the inhertied environment, i.e.,
--action_env=PATH did _not_ result in the PATH variable being forwarded from
the client environment.
Fixes #5142.
PiperOrigin-RevId: 196966822
|
|
|
|
|
|
|
|
| |
The difference between them is that user_link_flags will stay after we remove
legacy fields from the crosstool.
RELNOTES: None.
PiperOrigin-RevId: 196940832
|
|
|
|
|
|
|
|
|
| |
This flag assumes llvm supports an experimental 'prefetch-hints-flag' flag. The Bazel support simply plumbs the provided file through to the compiler.
The flag is independent from the other fdo_ flags, and may be applied in any combination with them.
RELNOTES: Introduce build support for providing cache prefetch hints.
PiperOrigin-RevId: 196916547
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 196870840
|
|
|
|
|
|
| |
out of CppConfiguration.
PiperOrigin-RevId: 196838680
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 196825564
|
|
|
|
|
|
|
|
|
|
| |
whether FDO optimization is used (--fdo_optimize or --fdo_profile)
As part of the work of removing usage of c++ toolchain from CppConfiguration, CppConfiguration#isLLVMCompiler method needs to be removed.
Currently, CppConfiguration#shouldIncludeZipperInToolchain (former CppConfiguration#isLLVMOptimizedFdo) method uses the CppConfiguration#isLLVMCompiler method to determine whether the compiler is LLVM and conditionally includes the zipper if the compiler is LLVM and FDO optimization is in place.
Instead of rerouting the information on the compiler and FDO profile through FeatureFlagInfo, we make the inclusion of the zipper executable depend only on usage of FDO optimization.
PiperOrigin-RevId: 196819907
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This cl enabled skylark rules to create build variables used for C++ compile
actions (in a limited form, e.g. build variables for modules are not exposed
etc).
Working towards #4571.
This is an encore of https://github.com/bazelbuild/bazel/commit/c4fc6201fdfa71993e2e9e295a946150e6990c75 after fixing memory regression
(CompileBuildVariables.getSafePathStrings fixed to return ImmutableList, which
has smaller memory footprint).
RELNOTES: None
PiperOrigin-RevId: 196797581
|
|
|
|
|
|
|
| |
Since it's not a provider, it doesn't need the Info suffix anymore.
RELNOTES:none
PiperOrigin-RevId: 196793557
|
|
|
|
|
|
|
|
|
| |
Extracts a class, InputArtifactData to hold the input data instead of using a raw map. This provides the flexibility needed to support both ActionFS and existing code so ActionFS does not need to rekey the input data.
Uses the smaller, getDeclaredIncludeSrcs instead of getAllowedDerivedInputs
when possible for staging optional inputs in ActionFS.
PiperOrigin-RevId: 196736703
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 196722758
|
|
|
|
|
|
|
|
| |
This class is not necessary anymore. We can use CcLinkParamsStoreImpl directly
which has been renamed to CcLinkParamsStore.
RELNOTES:none
PiperOrigin-RevId: 196656488
|
|
|
|
|
|
|
| |
This is in preparation for fixing env handling as well as cache key (to use
env) computations in subclasses of SpawnAction.
PiperOrigin-RevId: 196626495
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Caused a memory regression
*** Original change description ***
Expose cc_common.create_compile_build_variables
This cl enabled skylark rules to create build variables used for C++ compile
actions (in a limited form, e.g. build variables for modules are not exposed
etc).
Working towards #4571.
RELNOTES: None
PiperOrigin-RevId: 196566686
|
|
|
|
|
|
|
| |
separate class
RELNOTES: None.
PiperOrigin-RevId: 196517537
|
|
|
|
|
|
|
| |
Since it's not a provider, it doesn't need the Info suffix anymore.
RELNOTES:none
PiperOrigin-RevId: 196505329
|
|
|
|
|
|
|
| |
Since it's not a provider, it doesn't need the Info suffix anymore.
RELNOTES:none
PiperOrigin-RevId: 196498526
|
|
|
|
|
|
|
|
|
|
|
| |
This cl enabled skylark rules to create build variables used for C++ compile
actions (in a limited form, e.g. build variables for modules are not exposed
etc).
Working towards #4571.
RELNOTES: None
PiperOrigin-RevId: 196491567
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 196477775
|
|
|
|
|
|
|
|
|
| |
actually added for cc_library's include-attribute. For these, the same path is
present on the command line, but also ignored. For N of those directives, we
currently do O(N^2) prefix checks, which is unnecessarily expensive.
RELNOTES: None.
PiperOrigin-RevId: 196477307
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/5157
If a user's default system locale is not `en`, `en_US` or `en_UK`, there may be a chance that `String#toUpperCase` will result in a string that does not exist in the Enum declaration. This is the case in #5157.
To fix this, it's either
1) setting the Locale in the individual `toUpperCase` calls or
2) set Locale to English by default from `Bazel.java`.
I chose the first because it seemed less intrusive, but I'm open to suggestions.
Closes #5184.
PiperOrigin-RevId: 196261078
|
|
|
|
|
|
|
|
|
|
|
| |
Since we always pass true as argument (meaning it's for dynamic library), we
don't need the part for executable. And we don't want more users of this method,
therefore removing.
This is encore of https://github.com/bazelbuild/bazel/commit/ecb30676bdd7f1783afb3886e57caa9d6b1b9aee
RELNOTES: None.
PiperOrigin-RevId: 196241212
|
|
|
|
| |
PiperOrigin-RevId: 195973862
|
|
|
|
|
|
|
|
|
| |
This is to simplify the API that will eventually be exposed to Skylark.
Working towards #4571.
RELNOTES: None.
PiperOrigin-RevId: 195785588
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 195777400
|
|
|
|
|
|
|
|
|
| |
Staticness is confusing, I always have to investigate which is Staticness and
which is LinkStaticness, and even in isolation staticness is not a great name. I
believe LinkerOrArchiver is a better name :)
RELNOTES: None.
PiperOrigin-RevId: 195674810
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 195664306
|
|
|
|
|
|
|
| |
CcToolchainFeatureSelection class
RELNOTES: None.
PiperOrigin-RevId: 195425336
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks a few thousands targets
*** Original change description ***
Remove fully static linking part of ctx.fragments.cpp.fully_static_link_options
Since we always pass true as argument (meaning it's for dynamic library), we
don't need the part for executable. And we don't want more users of this method,
therefore removing.
RELNOTES: None.
PiperOrigin-RevId: 195411765
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 195279335
|
|
|
|
|
|
|
|
|
| |
Since we always pass true as argument (meaning it's for dynamic library), we
don't need the part for executable. And we don't want more users of this method,
therefore removing.
RELNOTES: None.
PiperOrigin-RevId: 195276402
|