| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
| |
PathFragments are not well supported in Skylark, quite the opposite, the Skylark
team tries hard to not use path fragments if possible. All existing users I
looked into had to convert the PathFragment to string using str() anyway.
Because of that this cl should not break anybody.
RELNOTES: None.
PiperOrigin-RevId: 200372447
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 200366616
|
|
|
|
|
|
|
|
|
| |
This helps avoid name conflicts when users want to generate DEF files by themselves. For example, when using a genrule to do that, people naturally name the def file as <target name>.def.
Fixed https://github.com/bazelbuild/bazel/issues/5357
RELNOTES: None
PiperOrigin-RevId: 200354303
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 200246780
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 200100871
|
|
|
|
|
|
| |
- migrate all startTask/completeTask pairs to the new API
PiperOrigin-RevId: 200038703
|
|
|
|
|
|
|
|
|
|
| |
try)
This is a roll forward of https://github.com/bazelbuild/bazel/commit/3ab52e63079f1e43cb2c973425f615836a334082. The issue caused the objc rule breakage was fixed by https://github.com/bazelbuild/bazel/commit/5176300577b53a15128b3cb6a17d7883c5b7090e.
RELNOTES:
Flip default value of --experimental_shortened_obj_file_path to true, Bazel now generates short object file path by default.
PiperOrigin-RevId: 199806300
|
|
|
|
|
|
|
|
|
|
|
| |
This cl enabled skylark rules to create build variables used for C++ link
actions (in a limited form, e.g. build variables for thinlto are not exposed
etc).
Working towards #4571.
RELNOTES: None
PiperOrigin-RevId: 199792130
|
|
|
|
|
|
|
| |
LSC is finished.
RELNOTES:none
PiperOrigin-RevId: 199619978
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This cl adds Skylark constants allowing users to specify which C++ action they
want for the feature configuration Skylark API. This is done by exposing a
Skylark file at @bazel_tools//tools/cpp:action_names.bzl.
Skylark api to the C++ toolchain doc:
https://docs.google.com/document/d/1g91BWJITcYw_X-VxsDC0VgUn5E9g0kRBGoBSpoO41gA/edit#.
Progress on #4571.
RELNOTES: None.
PiperOrigin-RevId: 199596778
|
|
|
|
|
|
| |
(minor) ActionFS now implements MetadataProvider.getInput
PiperOrigin-RevId: 199575194
|
|
|
|
|
|
|
| |
Crossbinary FDO optimization is a special form of AutoFDO which uses a synthetic profile to optimize targets without any profile. The synthetic profile will often be used as a default profile and will use .xfdo as suffix. It will be passed though option -fdo_optimize just like Autofdo profile. If .xfdo file is passed through -fdo_optimize in the same command line with other types of profiles, .xfdo file will be neglected.
RELNOTES: Build support for enabling cross binary FDO optimization.
PiperOrigin-RevId: 199501260
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the process, make it so that running an extra action attached to a
CppCompileAction does not change the state of the CppCompileAction (yes, this
happened: if include scanning was not done, topLevelModules would be changed)
There are two changes in behavior this will: introduce
1. topLevelModules will no longer be set if include scanning is not in effect, but that's okay: it's never read except when shouldPruneModules is true, and if that is true, #discoverInputsStage2() will set it.
2. Extra actions attached to CppCompileAction will not get .pcm files on their inputs that were not used by the compiler
RELNOTES: None.
PiperOrigin-RevId: 199285276
|
|
|
|
|
|
|
| |
Crosstool selection will be based solely on --cpu and --compiler options.
RELNOTES: Option --glibc is removed, toolchain selection relies solely on --cpu and --compiler options.
PiperOrigin-RevId: 199156131
|
|
|
|
|
|
|
| |
It doesn't use CcLinkParamsStore and CppLinkAction directly anymore.
RELNOTES:none
PiperOrigin-RevId: 199107747
|
|
|
|
| |
PiperOrigin-RevId: 198877280
|
|
|
|
|
|
| |
No longer needed since proto_library cannot be used for Java.
PiperOrigin-RevId: 198859993
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
without reading the CROSSTOOL file.
As we want to reroute selecting the toolchain from CROSSTOOL through cc_toolchain, cc_toolchain_suite should have all the necesarry information for obtaining the cc_toolchain label without accessing the CROSSTOOL file.
In order to do that, besides the existing <toolchain.targetCpu>|<toolchain.compiler>, we add <cpu> type of key in 'toolchains' attribute of cc_toolchain_suite.
Now the selection of cc_toolchain label goes as follows:
1. Return toolchains[<cpu>|<compiler> if it exists
2. Return toolchains[<cpu>] if it exists
3. Fall back to the previous state: return toolchains[<toolchain.targetCpu>|<toolchain.compiler>]
RELNOTES: None.
PiperOrigin-RevId: 198588849
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 198518792
|
|
|
|
|
|
|
| |
host builds don't profit from it.
RELNOTES: None.
PiperOrigin-RevId: 198437467
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- declaredIncludeSrcs don't need to be looked at as they also become part of
the compilation prerequisites (see
CcCompilationContext.addDeclaredIncludeSrc())
- transitiveModules can never be "incorrect" as they get computed and added by
Bazel itself.
- declaredIncludeDirs/warnIncludeDirs can be computed lazily. As most people
aim for a warning-free build, it is rarely necessary to compute either set in
practice.
RELNOTES: None.
PiperOrigin-RevId: 198386262
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 198364550
|
|
|
|
|
|
|
| |
It's unused.
RELNOTES: NONE.
PiperOrigin-RevId: 198316668
|
|
|
|
|
|
|
| |
later. This wastes CPU cycles (directly and during GC).
RELNOTES: None.
PiperOrigin-RevId: 198302706
|
|
|
|
|
|
|
|
| |
discovery at the boundary of modular headers. C++ modules generally should be
self-contained and a using a C++ module doesn't require any of it's transitive
source files to be present.
PiperOrigin-RevId: 198299936
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 198094324
|
|
|
|
|
|
|
|
| |
This is part of a chain of CLs that will pull initialization of
CcCompilationContext from CcCompilationHelper.
RELNOTES:none
PiperOrigin-RevId: 198060027
|
|
|
|
|
| |
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
|