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
Implement cc_args_list.
It's completely unneccesary to implement it this early, but collecting args lists is also required for cc_feature.
END_PUBLIC
PiperOrigin-RevId: 609833962
Change-Id: I369a929af4280c0a7ebbe2e13159b640c1968209
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
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
Similar to the previous CL, this CL is to ensure that we agree on the relationship between each different type.
This will also allow for developing two things in parallel:
* The rules that generate these providers.
* Toolchain validation, and conversion to the cc_toolchain_config_lib providers.
PiperOrigin-RevId: 606391257
Change-Id: I9c2a9895d71ed987e85eb60f908d9833b838d9f8
