When cpu value is not enough to distinguish between two toolchains, we use the compiler value. In that case, the user needs to specify the compiler value for all cc_toolchain_config rules, even for the ones with unique cpu. This cl fixes the allowed values in the compiler attribute to account for the values from unique toolchains.
Issue #5380
RELNOTES: None.
PiperOrigin-RevId: 239396228
This would have not introduced the osx crosstool bug in 2d0e27e8bc which was then fixed in unknown commit.
RELNOTES: None.
PiperOrigin-RevId: 238699176
This will make sure the copybara export is reversible, which is needed for setting up copybara workflow for importing github PRs.
RELNOTES: None.
PiperOrigin-RevId: 238445502
Since unknown commit is submitted, the principled variable to use in per_object_debug_info is is_using_fission, not per_object_debug_info_file (in case of thinlto build, the former is present also for thinlto bitcode compile, the latter only for backend compile).
RELNOTES: None.
PiperOrigin-RevId: 237192121
* # copybara-scrub suffix now works in BUILD and bzl files
* //tools/cpp is rewritten to @bazel_build//tools/cpp **in any filetype**
* //third_party/bazel_rules/rules_cc is rewritten to // **in any filetype**
PiperOrigin-RevId: 233919400
Another dark corner corner of crosstools appeared, and apparently we didn't enable MOSTLY STATIC linking mode flags for dynamic libraries or objc. This cl addresses that in the legacy fields migrator.
RELNOTES: None.
PiperOrigin-RevId: 233397974
Starlark constructors for tool_path and tool do not allow empty strings for the path field. Therefore the migrator replaces the "" with "NOT_USED". We should ignore this difference when comparing the CToolchains.
#5380
PiperOrigin-RevId: 232827179
And fix an error where we added previously unseen action_names to the dictionary of familiar ACTION_NAMES, so later when we would encounter them, we would treat them as variables, not as string literals
eg
env_set {
action = "a"
}
would translate to
env_set(
actions = [a],
)
which is, obviously wrong.
Issue #5380
PiperOrigin-RevId: 232817515
If toolchain A and B need feature f, but toolchain C doesn't, the generated declaration statement for feature f would be:
if ctx.attr.cpu == 'A.cpu':
f = feature(...)
elif ctx.attr.cpu == "B.cpu" and ctx.attr.compiler == "B.compiler":
f = feature(...)
else:
fail("Unreachable")
This will break the rule implementation in the case of toolchain C because it will reach the fail("Unreachable") although it doesn't need to declare feature f
This cl fixes that
Issue #5380
PiperOrigin-RevId: 232683639
If an action_config's name doesn't appear in the action_names.bzl, eg action-a.b+c, in it's assignments statement we would declare it as:
action_a.b+c_action = action_config( ...
This cl fixes it to create the action_config variable with the +, - and .
It also adds tests for action_config
Issue #5380
PiperOrigin-RevId: 232681355
Having a 'per_object_debug_data' feature enabled is giving the same signal as having supports_fission enabled. This is a safe change because all crosstools that have supports_fission: true have per_object_debug_info disabled, and with the legacy crosstool fields migration we will migrate this feature to be enabled by default for these crosstools.
https://github.com/bazelbuild/bazel/issues/6861https://github.com/bazelbuild/bazel/issues/5883
RELNOTES: None.
PiperOrigin-RevId: 230701029
This ensures that the generated files will be unique in the package and therefore there won't be action conflict.
RELNOTES: None.
PiperOrigin-RevId: 230514342
While here, Also fix _read_crosstool_or_ctoolchain_proto to actually return the CToolchain found in the CROSSTOOL file, and add some missing \n.
RELNOTES: None.
PiperOrigin-RevId: 229926500
This cl fixes a bug in the migrator where it didn't pass mentioned flags to c++-nodeps-dynamic-library unconditionally (it only passed them as with feature { feature: 'dynamic_linking_mode' }, which is incorrect, the feature doesn't not apply to nodeps-dynamic-library, only to transitive linking actions.
https://github.com/bazelbuild/bazel/issues/6861https://github.com/bazelbuild/bazel/issues/5883
RELNOTES: None.
PiperOrigin-RevId: 229692958
When renaming legacy_*_flags to default_*_flags, also rename other fields such as requires.
We're intentionally not replacing the implies line, just removing it, because default_*_features are enabled by default, so they don't need to be implied (Implied field is older than enabled field, so there are uses of it where enabled would work just fine. The only semantic difference is that implied features cannot be disabled, whereas enabled can. But since the standard style of writing crosstools seems to prefer enabled, I'm doing the same here.)
https://github.com/bazelbuild/bazel/issues/6861https://github.com/bazelbuild/bazel/issues/5883
RELNOTES: None.
PiperOrigin-RevId: 229518029
Another round of fixes:
* if the toolchain contains legacy_compile_flags or legacy_link_flags, replace the feature with default_compile_flags or default_link_flags. This is to ensure the location of the flags stays intact.
* it fixes the order of compilation flags, the correct order is:
1) compiler_flag
2) compilation_mode_flags.compiler_flag
3) cxx_flag
4) compilation_mode_flags.cxx_flag
* We don't add cxx_flags to assemble and preprocess-assemble actions
* We don't add sysroot to assemble action
https://github.com/bazelbuild/bazel/issues/6861https://github.com/bazelbuild/bazel/issues/5883
RELNOTES: None.
PiperOrigin-RevId: 229336027
A quick hack of a tool that will be used for removing runtime filegroups
Issue for the --incompatible_disable_runtimes_filegroups incompatible flag
(which this cl is a step towards to): #6942
Tracking issue for legacy crosstool fields removal: #5883
RELNOTES: None.
PiperOrigin-RevId: 225995150
Googler