Apply repo mapping to cc_shared_library's exports_filter

[fmeum]

This is required for exports_filter to match any external repositories with Bzlmod enabled.

native.package_relative_label is used to convert the user-specified filter strings, which are always valid labels, to canonical label literals that are then passed to the actual cc_shared_library rule.

Fixes #21872

[fmeum]

This being a macro would require migrating the attribute docs to a function comment.

@comius What do you think of allowing native.package_relative_label in initializers instead, perhaps by providing a suitably trimmed down BazelStarlarkContext to the thread running the initializer? I understand why you don't want native.existing_rules to be run in one, but label conversion will be a frequent ask with Bzlmod.

[comius]

Initializers already lift strings of regular labels. Maybe the solution is to make exports_filter a label?

Should the lifting really be package relative? That's only the property of output labels. Otherwise labels are lifted call-site relative. Not much difference at the moment. But if you had a string label in an initializer, that would need to work relative to the initializer, right?

[fmeum]

Initializers already lift strings of regular labels. Maybe the solution is to make exports_filter a label?

Could you elaborate on that? My understanding is that making exports_filter a label_list would result in dependency edges on all entries of the list, which would result in errors since the __pkg__ pseudo targets don't exist.

Should the lifting really be package relative? That's only the property of output labels. Otherwise labels are lifted call-site relative. Not much difference at the moment. But if you had a string label in an initializer, that would need to work relative to the initializer, right?

I'm aware of three different "lifting" mechanisms in macros:

• Strings passed to attr.labels are resolved relative to the BUILD file call site.
• The Label constructor resolves relative to its own .bzl call site.
• native.package_relative_label resolves relative to the BUILD file call site.

I wouldn't expect initializers to behave differently here. But at the moment native.package_relative_label isn't available in initializers, so I don't know how to turn user-supplied strings into labels without creating a dependency edge.

[comius]

I don’t want to expose such functions to initializers, because they open space for crafting weird conversions and bugs with that.

A new type like attr.nodep_label_list would be the right thing to do. We have it natively.

But I’m also wondering, what’s going on in cc_shared_library, to make a usecase like this. In all the rules we touched, label comparison was a bad idea and we removed it.

[fmeum]

@oquenchil can explain that better than me. Having an attribute control the transitive closure of a top-level transitive target does seem like a reasonable if rare use case to me.

Given that this is essentially a bug fix for a regression caused by --enable_bzlmod, what do you think of using a macro for now until something like attr.nodep_label_list becomes available?

[comius]

Yeah, I think it's better to expose package_relative_label to initializers and use them.

Without initializers also the docs on bazel.build would break.

[fmeum]

I implemented this in #21740. I also allowed the other non-target related functions as they seemed equally safe and useful to allow in initializers.

[fmeum]

I am now using an initializer, PTAL.

[fmeum]

Original context is https://bazelbuild.slack.com/archives/CGA9QFQ8H/p1709829043052719

[fmeum]

Switching to draft as I will update it after #21740 has been merged.

[fmeum]

@bazel-io fork 7.2.0