| 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
|
|
|
|
|
|
|
|
|
|
|
| |
This cl changes copts to be immutable (and changes addCopts methods into
setCopts, so it's simpler to reason about copts) and exposes copts as a build
variable. It also introduces CompileBuildVariablesTest, similar to
LinkBuildVariablesTest, to test that right build variables are exposed for right
actions.
RELNOTES: None.
PiperOrigin-RevId: 163876774
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 162725697
|
|
|
|
|
|
|
|
| |
One less thing to worry about. C++ action builders cannot be used without
FeatureConfiguration anyway.
RELNOTES: None.
PiperOrigin-RevId: 162471228
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 162344071
|
|
|
|
|
|
|
| |
This was causing some builds to error more aggressively than before.
RELNOTES: None.
PiperOrigin-RevId: 161907484
|
|
|
|
|
|
|
| |
Show meaningful message instead.
RELNOTES: None.
PiperOrigin-RevId: 161196096
|
|
|
|
|
|
|
| |
With a few manual fixes for readability.
RELNOTES: None.
PiperOrigin-RevId: 160582556
|
|
|
|
|
| |
RELNOTES: NONE.
PiperOrigin-RevId: 158703123
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Fixes memory issue that caused this CL to be rolled back.
*** Original change description ***
Automated g4 rollback of commit cbbb423663b154d82e3dfa5e9a56839583987999.
*** Reason for rollback ***
Need to roll this back as part of http://b/38171368
*** Original change description ***
RELNOTES: Effectively remove sysroot from CppConfiguration and allow it to use select statements.
PiperOrigin-RevId: 155651879
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Need to roll this back as part of http://b/38171368
*** Original change description ***
RELNOTES: Effectively remove sysroot from CppConfiguration and allow it to use select statements.
PiperOrigin-RevId: 155547813
|
|
|
|
|
|
| |
use select statements.
PiperOrigin-RevId: 155480011
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Original CL was rolled backed incorrectly. See post-submit discussion on http://https://github.com/bazelbuild/bazel/commit/7beadb7277453efec7e12b925005e7f0e003b592.
*** Original change description ***
Automated g4 rollback of commit 38b835097f9ae9a6062172b8a33ec2e2d1edde20.
*** Reason for rollback ***
Breaking Bazel build on linux, see http://ci.bazel.io/job/bazel-tests/733/
Repro: bazel build //src/test/java/com/google/devtools/build/lib:packages_test
Found by bisecting.
*** Original change description ***
Only allocate some formerly frequently allocated PathFragment objects once.
This reduces both gc churn and retained memory usage.
RELNOTES: None
PiperOrigin-RevId: 154839279
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaking Bazel build on linux, see http://ci.bazel.io/job/bazel-tests/733/
Repro: bazel build //src/test/java/com/google/devtools/build/lib:packages_test
Found by bisecting.
*** Original change description ***
Only allocate some formerly frequently allocated PathFragment objects once.
This reduces both gc churn and retained memory usage.
RELNOTES: None
PiperOrigin-RevId: 154821457
|
|
|
|
|
|
| |
This reduces both gc churn and retained memory usage.
PiperOrigin-RevId: 154718782
|
|
|
|
|
|
|
|
| |
This is the Blaze side of the support for emitting and using minimized bitcode files during the LTO indexing (thin link) step of a ThinLTO build. The llvm support has already been released to stable, and this needs to be submitted after the companion Crosstool support (unknown commit, will send for review once this larger part is reviewed).
This enables large applications successfully build using ThinLTO and -g, otherwise the bitcode files that are input to the LTO indexing step are huge and the maximum input size is exceeded.
PiperOrigin-RevId: 153549687
|
|
|
|
|
|
|
|
|
|
|
|
| |
'create' method.
This paves the way for changing PathFragment to e.g. an abstract class with multiple subclasses. This way we can split out the windows-specific stuff into one of these concrete classes, making the code more readable and also saving memory (since the shallow heap size of the NonWindowsPathFragment subclass will hopefully be smaller than that of the current PathFragment).
This also lets us pursue gc churn optimizations. We can now do interning in PathFragment#create and can also get rid of unnecessary intermediate PathFragment allocations.
RELNOTES: None
PiperOrigin-RevId: 152145768
|
|
|
|
|
|
|
|
| |
This way, we'll eventually get closer to the ideal world where inputs are clearly classified as either mandatory, prunable, discovered or discovered and prunable.
--
PiperOrigin-RevId: 150061912
MOS_MIGRATED_REVID=150061912
|
|
|
|
|
|
|
|
|
| |
- use SimpleSpawn in SpawnGccStrategy
- set PWD in CppCompileAction for consistency
--
PiperOrigin-RevId: 149745059
MOS_MIGRATED_REVID=149745059
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Broke tests on CI: http://ci.bazel.io/job/bazel-tests/570/
*** Original change description ***
Roll forward execroot change
RELNOTES[INC]: Previously, an external repository would be symlinked into the
execution root at execroot/local_repo/external/remote_repo. This changes it to
be at execroot/remote_repo. This may break genrules/Skylark actions that
hardcode execution root paths. If this causes breakages for you, ensure that
genrules are using $(location :target) to access files and Skylark rules are
using http://bazel.io/docs/skylark/lib/File.html's path, dirname, etc.
functions. Cust...
--
PiperOrigin-RevId: 147833177
MOS_MIGRATED_REVID=147833177
|
|
|
|
|
|
|
|
| |
Also Stop copying CcToolchainFeatures.Variables over when making copy of CppCompileActionBuilder.
--
PiperOrigin-RevId: 147798008
MOS_MIGRATED_REVID=147798008
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 147765641
MOS_MIGRATED_REVID=147765641
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RELNOTES[INC]: Previously, an external repository would be symlinked into the
execution root at execroot/local_repo/external/remote_repo. This changes it to
be at execroot/remote_repo. This may break genrules/Skylark actions that
hardcode execution root paths. If this causes breakages for you, ensure that
genrules are using $(location :target) to access files and Skylark rules are
using http://bazel.io/docs/skylark/lib/File.html's path, dirname, etc.
functions. Custom crosstools that hardcode external/<repo> paths will have to
be updated.
Issue #1262.
--
PiperOrigin-RevId: 147726370
MOS_MIGRATED_REVID=147726370
|
|
|
|
|
|
|
|
|
|
|
|
| |
potentially reduce the linker input. The content of a C++ module (specifically
the inline definitions) is currently put into every single .o file that uses
them and thus can be input to the same final link many times. By generating a
separate .o file for the module itself, we can avoid this unnecessary
duplication of linker input.
--
PiperOrigin-RevId: 147579947
MOS_MIGRATED_REVID=147579947
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a configuration to be passed into the cc backend and used to scope output artifacts.
Artifacts involved:
(1) Object files: see change in CppHelper, CppModel, CppCompileActionBuilder
(2) Archive files: see change in CppModel
(3) Archive objfile list: see change in ObjcVariablesExtension.
Other little things that needed to be cleaned up to enable this:
(1) neverlink set on objc archive actions. Without neverlink, colliding solib artifacts are generated from the two archives arising from the multi-arch split.
(2) Toolchain selection in CrosstoolCompilationSupport uses passed-in configuration instead of :cc_toolchain attribute. This allows for each of the compiles spawned from apple_binary.srcs to select the correct toolchain based on the child configuration.
--
PiperOrigin-RevId: 147550618
MOS_MIGRATED_REVID=147550618
|
|
|
|
|
|
|
|
| |
CppCompileActions that to be executed at execution time.
--
PiperOrigin-RevId: 147163077
MOS_MIGRATED_REVID=147163077
|
|
|
|
|
|
|
|
| |
Update the builder to allow setting arbitrary execution info.
--
PiperOrigin-RevId: 147130533
MOS_MIGRATED_REVID=147130533
|
|
|
|
|
|
|
|
|
|
| |
":cc_toolchain" in RuleContext, instead take the provider from users and pass it around to where it is used.
This gives J2ObjcAspect the ability to specify the C++ toolchain attribute under a different name to avoid attribute conflicts with attached rules that have already declared attribute ":cc_toolchain".
--
PiperOrigin-RevId: 146920294
MOS_MIGRATED_REVID=146920294
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 146694092
MOS_MIGRATED_REVID=146694092
|
|
|
|
|
|
|
|
| |
be a saner name.
--
PiperOrigin-RevId: 146109129
MOS_MIGRATED_REVID=146109129
|
|
|
|
|
|
|
|
|
|
| |
Action#getInputsWhenSkippingInputDiscovery().
This has the side effect of always allowing new inputs to be discovered when Action#discoversInputs() return true, but since those actions are very few and have mostly to do with C++, I think it's an acceptable tradeoff for th ecode being that much simpler.
--
PiperOrigin-RevId: 146098150
MOS_MIGRATED_REVID=146098150
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Fixes #2372.
--
PiperOrigin-RevId: 145539067
MOS_MIGRATED_REVID=145539067
|
|
|
|
|
|
|
|
|
|
| |
--experimental_prune_more_modules. Both flags have proven to be stable for a
few weeks. Instead provide a (probably permanent) option to disable modules
pruning completely.
--
PiperOrigin-RevId: 144215146
MOS_MIGRATED_REVID=144215146
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
assessment was wrong and this does work properly now that all the inputs are
properly declared.
--
MOS_MIGRATED_REVID=140618631
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=140613176
|
|
|
|
|
|
|
|
|
|
|
|
| |
CppCompileAction. It seems wrong to bind this to a context. Instead, we should
be able to determine for each action, whether it can use modules or not. Also
allow overwriting the value obtained by the feature configuration in the
CppCompileActionBuilder. This can e.g. be used to disable modules in
CppSemantics.finalizeCompileActionBuilder(), if modules cannot be supported
under certain circumstances.
--
MOS_MIGRATED_REVID=140610096
|
|
|
|
|
|
|
| |
building with modules.
--
MOS_MIGRATED_REVID=137368548
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes Ulf's TODO by adding fields for the local shell environment and code
coverage and as stated on it accessing anything other than these fields can
impact correctness.
--
Change-Id: I9ccebaa0bc8ed920e2941b3d156692cb1e0fe117
Reviewed-on: https://bazel-review.googlesource.com/c/6870/
MOS_MIGRATED_REVID=137275206
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
C++/Python.
--
MOS_MIGRATED_REVID=133863929
|
|
|
|
|
|
|
|
|
|
| |
a85bf4b19c680a6db11f21758847dc88ec0aa658.
The bad merge undid part of the behavior around pruning header modules and also
passed in "shouldPruneModules" as "usePic".
--
MOS_MIGRATED_REVID=132846871
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=132550233
|
|
|
|
|
|
|
|
| |
build first before discovering their inputs and this build doesn't properly
declare its inputs if we do pruning.
--
MOS_MIGRATED_REVID=132414200
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Prunes .modulemap files incorrectly. See [].
*** Original change description ***
Implement input pruning using .d files in objc.
--
MOS_MIGRATED_REVID=132246906
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=132061988
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pruning here can lead to a insufficient rebuilds which in turn cause
module-out-of-date errors. The problem surfaces if a module A depends on a
module B, but the headers of module A don't actually use any of B's headers.
Then we would currently not need to rebuild A when B changes although we are
storing a dependency in it. If B changes and we then build something that uses
A (a header of it), we mark A as well as all of its transitive dependencies as
inputs. We still don't need to rebuild A, as none of its inputs have changed,
but we do rebuild B now and then the two modules are out of sync.
For now, just disable pruning of header modules while building the modules. In
the long run, it would be even better to not embed a dependency on B into A,
but that requires signficantly larger changes.
--
MOS_MIGRATED_REVID=132039754
|
|
|
|
|
|
|
| |
off in the objc case.
--
MOS_MIGRATED_REVID=131943500
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the C++ rules standalone, and the CcCommonTest ensures that (at
least) analysis of C++ targets works even if no Apple / Xcode rules are
present.
We can also compile them separately, in a future change.
--
MOS_MIGRATED_REVID=131583691
|