-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include name in repr
of exported rule
s
#18392
Conversation
repr
of rule
srepr
of exported rule
s
@comius Could you review this (very small) change? |
@comius Friendly ping |
I'm slightly reluctant to approve this, but seems to be the best of the bad choices. In general people shouldn't rely on string representation. The PR fixes a previous unintentional change in the representation. The representation has the problem of not including .bzl file where the rule was created. But that's the same problem that pests ctx.rule.kind. |
For an exported rule `foo_library`, `repr(foo_library)` now evaluates to `<rule foo_library>`, not `<rule>`, matching the behavior of native rules more closely. Fixes bazelbuild#17483 Closes bazelbuild#18392. PiperOrigin-RevId: 538458291 Change-Id: I331955655756a3c235be0a93f1394716ddf9849d
@bazel-io flag |
@bazel-io fork 6.4.0 |
For an exported rule `foo_library`, `repr(foo_library)` now evaluates to `<rule foo_library>`, not `<rule>`, matching the behavior of native rules more closely. Fixes bazelbuild#17483 Closes bazelbuild#18392. PiperOrigin-RevId: 538458291 Change-Id: I331955655756a3c235be0a93f1394716ddf9849d
For an exported rule `foo_library`, `repr(foo_library)` now evaluates to `<rule foo_library>`, not `<rule>`, matching the behavior of native rules more closely. Fixes #17483 Closes #18392. Commit 002490b PiperOrigin-RevId: 538458291 Change-Id: I331955655756a3c235be0a93f1394716ddf9849d Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>
For an exported rule
foo_library
,repr(foo_library)
now evaluates to<rule foo_library>
, not<rule>
, matching the behavior of native rules more closely.Fixes #17483