This should make the concept of "sentinel features" work correctly with known_features and enabled_features, rather than enabling them directly in features.
PiperOrigin-RevId: 681688437
Change-Id: I29184a2079ccfd0eb3a275439508a66ca61109af
BEGIN_PUBLIC
Add support for implicit include directories to rule-based toolchains
Reorients the `cc_toolchain.cxx_builtin_include_directories` attribute so it is expressed as an attribute on `cc_args` and `cc_tool` to signify that the tools or arguments imply include directories that Bazel's include path checker should allowlist. This moves the allowlist to the source of truth that implies these directories.
END_PUBLIC
PiperOrigin-RevId: 671393376
Change-Id: Ide8cae548783726835168adcd3f705028a1f4308
BEGIN_PUBLIC
Integrate cc_tool_map into rule-based toolchains
Integrates cc_tool_map as a new attribute of cc_toolchain, completely replacing cc_action_type_config.
END_PUBLIC
PiperOrigin-RevId: 666365739
Change-Id: Iac74a31736dad66ac3dc75b4478ab4d4d2412181
BEGIN_PUBLIC
Replace toolchain_features with known_features and enabled_features.
This should allow for the deprecation of action_type_config, as `implies` there is no longer required.
END_PUBLIC
PiperOrigin-RevId: 658620044
Change-Id: Idda9bd77edad1be1fd26d5a655e3b9084d38bca8
BEGIN_PUBLIC
Remove feature requirements from tools.
It's such a niche use case, adds a fair amount of complexity, and there are multiple alternatives available:
* Now that we're using rule based things, you should just be able to add a bazel flag and select on it in your tool definition.
* If you really want precisely that behaviour, you can make your feature add "--use-foo-tool" to the args, and make your tool a wrapper tool that reads the command-line argument, and if provided, invokes a different tool.
END_PUBLIC
PiperOrigin-RevId: 657383729
Change-Id: Idb4f3ad66dc92d48ef81a1e8875bf6d3ba215aa4
BEGIN_PUBLIC
Gather variable metadata for the new rule-based toolchain.
END_PUBLIC
PiperOrigin-RevId: 622000877
Change-Id: I5b2ea6c363fc43fd44e60ffc8fa7ae041545337e
After discussion with @amontanez in unknown commit, we decided that NestedArgs was a more appropriate name.
BEGIN_PUBLIC
Rename ExpandArgs to NestedArgs
END_PUBLIC
PiperOrigin-RevId: 617085672
Change-Id: I1d7190cac79f8fa953d23be7d0db3b028a84cf30
BEGIN_PUBLIC
Refactor AddArgsInfo into ExpandArgsInfo
This allows us to create a similar mechanism to the current toolchain, while maintaining type safety.
END_PUBLIC
PiperOrigin-RevId: 615939056
Change-Id: I9b6763150194f8a76dfd8da730a3e2d45accbe20
Implement ToolchainConfigInfo.
Add support to create the toolchain from feature, action config, and args targets, and validate it to ensure correctness.
END_PUBLIC
PiperOrigin-RevId: 612985448
Change-Id: I7d9086dd1dde07eb0c2484414c9c28c1b8bfb427
Implement cc_action_type_config.
Rename it from cc_action_config, to make it clear that we are not configuring an action, but rather configuring a type of action.
END_PUBLIC
PiperOrigin-RevId: 610518142
Change-Id: Ic10755952ee786d30a3a5564aa09a8dc16499f3a
Pull more info into ArgsListInfo.
This allows us to make queries such as "get me all the flags / files required for this specific action". This will allow us to implement cc_action_config more easily and efficiently.
END_PUBLIC
PiperOrigin-RevId: 609828504
Change-Id: Ie3978674c5027f892d2e5e4c8d937a52c59fde5d
Add support for testing against more complex subject types.
We can now use subjects such as subjects.result(subjects.str) for something that may return a string, or fail.
END_PUBLIC
PiperOrigin-RevId: 608971309
Change-Id: I9ae61c988a597189b84fb6ccef75c96697c6e364
Implement cc_args.
Also change cc_flag_set / cc_flag_group to cc_args / cc_arg_group. This is to lean into the idea that this is roughly equivalent to ctx.actions.args()
END_PUBLIC
PiperOrigin-RevId: 608804069
Change-Id: I74ea883b14219f904aaafc4eab902b96a1fb3e3d
Add support for testing rules_cc's new toolchains with rules_testing.
END_PUBLIC
PiperOrigin-RevId: 608769646
Change-Id: I1a698355e5e977cc86eedc7cf6e8e0f888593cb8
Googler