Add a `cc_inputs` attribute to include arbitrary files in compilation actions and support location expansion

[jschear]

rules_swift's swift_library has a swiftc_inputs attribute, which serves as a way to pass labels that are used in $(location) expansion in other attributes.

There are a few places in rules_swift and rules_apple where the headers field of CcInfo is being used/abused for this purpose:

• https://github.com/bazelbuild/rules_apple/blob/master/apple/internal/header_map.bzl#L98
• https://github.com/bazelbuild/rules_swift/blob/646d6d229edc0b22ea3b9dc891062de519d27d4c/mixed_language/internal/library.bzl#L154

It would be nice if there was a dedicated attribute. I'd be happy to contribute if this request makes sense.

[jschear]

Documenting another usage of this:

https://github.com/bazelbuild/rules_apple/blob/e930d524ff7927182e99ff70ce92f30cfd6e3304/apple/internal/framework_import_support.bzl#L173-L187

[trybka]

We would consider a contribution for this, but would like to know a little more about what kinds of things you would envision passing here for CC rules. Maybe for my own edification--what kinds of things to folks pass in swiftc_inputs ?

[brentleyjones]

Doesn't additional_compiler_inputs already serve this purpose? (we need it for objc_library though).

[jschear]

https://bazel.build/reference/be/c-cpp#cc_library.additional_compiler_inputs

Any additional files you might want to pass to the compiler command line, such as sanitizer ignorelists, for example. Files specified here can then be used in copts with the $(location) function.

Ah yeah, exactly! Just missing from objc_library.

[jschear]

would like to know a little more about what kinds of things you would envision passing here for CC rules

One thing I currently use the headers attribute for is clang header maps: we (Square iOS) use these to allow Objective-C code to import headers by name, regardless of where the header is located on disk (i.e. for a header at headers/SomeHeader.h under the bazel package, we use #import "SomeHeader.h" instead of #import "full/bazel/package/path/MyModule/headers/SomeHeader.h"). Xcode uses header maps in this fashion by default, so iOS projects with legacy Objective-C code that migrate to Bazel often have to support header maps or perform a mass migration of their include style.

There's a rule to generate header maps in rules_apple, and it adds the header map to CcInfo.compilation_context.headers so that it's included as an input to compilation actions, and then references the header map target in objc_library's includes attribute because clang searches -I paths for header maps.

[brentleyjones]

And for us, we use it to pass profdata for IR optimization.