-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
#[allow(private_bounds)]
does not work when applied directly to the "bad" item.
#115475
Labels
A-lint
Area: Lints (warnings about flaws in source code) such as unused_mut.
A-visibility
Area: Visibility / privacy
C-bug
Category: This is a bug.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
rustbot
added
the
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
label
Sep 2, 2023
Noratrieb
added
A-lint
Area: Lints (warnings about flaws in source code) such as unused_mut.
A-visibility
Area: Visibility / privacy
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
and removed
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
labels
Sep 4, 2023
The problem here is that the lint is associated with the private item, not the item which names it in its bounds:
|
cc @Bryanskiy |
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this issue
Sep 7, 2023
…t-node, r=petrochenkov Lint node for `PRIVATE_BOUNDS`/`PRIVATE_INTERFACES` is the item which names the private type The HIR that the `PRIVATE_BOUNDS` lint should be attached to is the item that has the *bounds*, not the private type. This PR also aligns this behavior with the `EXPORTED_PRIVATE_DEPENDENCIES` lint, which also requires putting the `allow` on the item that names the private type. Fixes rust-lang#115475 r? petrochenkov
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this issue
Sep 7, 2023
…t-node, r=petrochenkov Lint node for `PRIVATE_BOUNDS`/`PRIVATE_INTERFACES` is the item which names the private type The HIR that the `PRIVATE_BOUNDS` lint should be attached to is the item that has the *bounds*, not the private type. This PR also aligns this behavior with the `EXPORTED_PRIVATE_DEPENDENCIES` lint, which also requires putting the `allow` on the item that names the private type. Fixes rust-lang#115475 r? petrochenkov
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this issue
Sep 7, 2023
…t-node, r=petrochenkov Lint node for `PRIVATE_BOUNDS`/`PRIVATE_INTERFACES` is the item which names the private type The HIR that the `PRIVATE_BOUNDS` lint should be attached to is the item that has the *bounds*, not the private type. This PR also aligns this behavior with the `EXPORTED_PRIVATE_DEPENDENCIES` lint, which also requires putting the `allow` on the item that names the private type. Fixes rust-lang#115475 r? petrochenkov
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Sep 8, 2023
Rollup merge of rust-lang#115633 - compiler-errors:PRIVATE_BOUNDS-lint-node, r=petrochenkov Lint node for `PRIVATE_BOUNDS`/`PRIVATE_INTERFACES` is the item which names the private type The HIR that the `PRIVATE_BOUNDS` lint should be attached to is the item that has the *bounds*, not the private type. This PR also aligns this behavior with the `EXPORTED_PRIVATE_DEPENDENCIES` lint, which also requires putting the `allow` on the item that names the private type. Fixes rust-lang#115475 r? petrochenkov
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-lint
Area: Lints (warnings about flaws in source code) such as unused_mut.
A-visibility
Area: Visibility / privacy
C-bug
Category: This is a bug.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
I tried this code:
I expected to see this happen: The
private_bounds
lint is allowed.Instead, this happened: The
private_bounds
lint still triggers.(Applying
#[allow(private_bounds)]
to the entire module works).(I'm assuming that this is unintentional, thus reporting as a "bug". If this behavior is intentional, consider this a feature request to change it).
Meta
Latest playground nightly:
The text was updated successfully, but these errors were encountered: