This is a reland of 30b95e3 with a different approach to emitting display form labels that avoids adding a new `to_display_form()` method to `Label`:
* In action command lines, which are the most frequent use of labels in rule implementation functions, labels are automatically emitted in display form since 9d3a8b0.
* In module extensions and repository rules, if labels can be turned into display form, the inverse of the repository mapping would need to be tracked in lockfiles and marker files for correct incrementality. Furthermore, allowing implementation functions to access apparent names would allow them to "discriminate" against them, thus possibly breaking the user's capability to map repos at will via `use_repo` and `repo_name`. Similar to how providers on a target can't be enumerated, it is thus safer to not provide this information to the implementation functions directly.

This change thus implements `StarlarkValue#debugPrint` for `Label` to allow ruleset authors to emit labels in display form in warnings and error messages while ensuring that Starlark logic doesn't have access to this information. `print("My message", label)` degrades gracefully with older Bazel versions (it just prints a canonical label literal) and can thus be adopted immediately without a need for feature detection.

This requires changing the signature of `StarlarkValue#debugPrint` to receive the `StarlarkThread` instead of just the `StarlarkSemantics`. Since `debugPrint` is meant for emitting potentially non-deterministic information, it is safe to give it access to `StarlarkThread`.

Also improves the Bzlmod cycle reporter so that it prints helpful information on a cycle encountered in a previous iteration of this PR.

Fixes bazelbuild#20486

RELNOTES: `Label` instances passed to `print` or `fail` as positional arguments are now formatted with apparent repository names (optimized for human readability).

Closes bazelbuild#21963.

PiperOrigin-RevId: 635589078
Change-Id: If60fdc632a59f19dad0cb02312690c15a0540c8e

This is a reland of 30b95e3 with a different approach to emitting display form labels that avoids adding a new `to_display_form()` method to `Label`:
* In action command lines, which are the most frequent use of labels in rule implementation functions, labels are automatically emitted in display form since 9d3a8b0.
* In module extensions and repository rules, if labels can be turned into display form, the inverse of the repository mapping would need to be tracked in lockfiles and marker files for correct incrementality. Furthermore, allowing implementation functions to access apparent names would allow them to "discriminate" against them, thus possibly breaking the user's capability to map repos at will via `use_repo` and `repo_name`. Similar to how providers on a target can't be enumerated, it is thus safer to not provide this information to the implementation functions directly.

This change thus implements `StarlarkValue#debugPrint` for `Label` to allow ruleset authors to emit labels in display form in warnings and error messages while ensuring that Starlark logic doesn't have access to this information. `print("My message", label)` degrades gracefully with older Bazel versions (it just prints a canonical label literal) and can thus be adopted immediately without a need for feature detection.

This requires changing the signature of `StarlarkValue#debugPrint` to receive the `StarlarkThread` instead of just the `StarlarkSemantics`. Since `debugPrint` is meant for emitting potentially non-deterministic information, it is safe to give it access to `StarlarkThread`.

Also improves the Bzlmod cycle reporter so that it prints helpful information on a cycle encountered in a previous iteration of this PR.

Fixes bazelbuild#20486

RELNOTES: `Label` instances passed to `print` or `fail` as positional arguments are now formatted with apparent repository names (optimized for human readability).

Closes bazelbuild#21963.

PiperOrigin-RevId: 635589078
Change-Id: If60fdc632a59f19dad0cb02312690c15a0540c8e

…2460)

This is a reland of 30b95e3 with a
different approach to emitting display form labels that avoids adding a
new `to_display_form()` method to `Label`:
* In action command lines, which are the most frequent use of labels in
rule implementation functions, labels are automatically emitted in
display form since 9d3a8b0.
* In module extensions and repository rules, if labels can be turned
into display form, the inverse of the repository mapping would need to
be tracked in lockfiles and marker files for correct incrementality.
Furthermore, allowing implementation functions to access apparent names
would allow them to "discriminate" against them, thus possibly breaking
the user's capability to map repos at will via `use_repo` and
`repo_name`. Similar to how providers on a target can't be enumerated,
it is thus safer to not provide this information to the implementation
functions directly.

This change thus implements `StarlarkValue#debugPrint` for `Label` to
allow ruleset authors to emit labels in display form in warnings and
error messages while ensuring that Starlark logic doesn't have access to
this information. `print("My message", label)` degrades gracefully with
older Bazel versions (it just prints a canonical label literal) and can
thus be adopted immediately without a need for feature detection.

This requires changing the signature of `StarlarkValue#debugPrint` to
receive the `StarlarkThread` instead of just the `StarlarkSemantics`.
Since `debugPrint` is meant for emitting potentially non-deterministic
information, it is safe to give it access to `StarlarkThread`.

Also improves the Bzlmod cycle reporter so that it prints helpful
information on a cycle encountered in a previous iteration of this PR.

Fixes #20486

RELNOTES: `Label` instances passed to `print` or `fail` as positional
arguments are now formatted with apparent repository names (optimized
for human readability).

Closes #21963.

PiperOrigin-RevId: 635589078
Change-Id: If60fdc632a59f19dad0cb02312690c15a0540c8e

Closes #22136