Description of the bug:

Running str on a built-in rule function written in java, such as py_library, returns strings like <built-in rule py_library>, while for one whose implementation has been rewritten in starlark, such as cc_library, it merely returns <rule>. Upgrading from Bazel 4 to 6 broke some of our macros which take those functions as inputs and make decisions based on what rules they correspond to. Given such a function, there no longer seems to be a way to determine the name of the rule to which it corresponds. One can work around it by explicitly comparing things against native.cc_library and so on, but the difference in output seems like an unintended regression. Preferably, the string representations of internal starlarkified rules should somehow expose the rules' names, but another generic means of determining the names of arbitrary rules would suffice instead.

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Compare the outputs of str(cc_library) and str(py_library) using Bazel 6, which are <rule> and <built-in rule py_binary> respectively.

Which operating system are you running Bazel on?

Ubuntu

What is the output of bazel info release?

release 6.0.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response