-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Account for sealed traits in privacy and trait bound errors #112686
Conversation
r? @fee1-dead (rustbot has picked a reviewer for you, use r? to override) |
This comment was marked as resolved.
This comment was marked as resolved.
This comment has been minimized.
This comment has been minimized.
This comment was marked as resolved.
This comment was marked as resolved.
compiler/rustc_trait_selection/src/traits/error_reporting/suggestions.rs
Outdated
Show resolved
Hide resolved
compiler/rustc_trait_selection/src/traits/error_reporting/suggestions.rs
Outdated
Show resolved
Hide resolved
compiler/rustc_trait_selection/src/traits/error_reporting/suggestions.rs
Outdated
Show resolved
Hide resolved
error[E0603]: module `index` is private | ||
--> $DIR/private-trait-non-local.rs:2:18 | ||
| | ||
LL | use core::slice::index::private_slice_index::Sealed; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I quite like this framing, though I wonder if we should either link to somewhere with privacy rules, or at least drive this home by noting something like "an item is only reachable via a path if all of the segments are reachable" -- with maybe better wording than what I wrote...
Just want something that folks can take away from the error message as intuition for why public-unreachable error happen the way they do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to add some note about it, but I'm not sure what it should look like at the moment.
This touches name resolution infra, not only diagnostics. |
You guys really want me to suffer. In a typical estebank's fashion the PR
As a result, I don't want to see this PR merged due to |
Could you split this into parts small enough to make it digestable?
(And also add a PR description.) |
@petrochenkov This review was really in bad form. You have valid critique that could have carried its own weight without either of the first two lines. Slipping in a public, passive-aggressive callout is no way to talk things out with your fellow project members. Please avoid that in the future, and if you feel you need help resolving issues with other people in the community, please reach out to Mods. We're here to help issues before they escalate, not just after. |
I've split this PR to the best of my abilities into easily digestible units. That being done, I do not believe initial PR was unreasonably unfocused, the changes were tightly related. Given the nature of the work when I'm doing these kind of changes, I sometimes have to experiment with multiple alternative ways of accomplishing the result I'm looking for looking for the most minimally invasive way of doing so. The above separation of commits is ahistorical and somewhat artificial and the ask requires more additional work from me than what would otherwise be required from the reviewer. In more general terms, I understand that we have different perspectives on where different changes fall in the "increased complexity"/"user focus" axes, but I must say, I do not appreciate the antagonistic way you interact with me, here or in the past. If you desire to talk about it, with mods or on our own, you can find me in Zulip. I do not believe this is the appropriate place for that discussion. |
@estebank |
err.span_label( | ||
outer_ident.span, | ||
format!("{} `{}` is not publicly reachable", this_res.descr(), ident), | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can this use translatable diagnostics?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll do this as part of a separate PR.
compiler/rustc_trait_selection/src/traits/error_reporting/suggestions.rs
Show resolved
Hide resolved
Some more detailed meta-comments to clarify what I'd like to see from PRs like this as a reviewer:
I'll post the comments on code a bit later. |
resolve: Minor cleanup to `fn resolve_path_with_ribs` A single-use closure is inlined and one unnecessary enum is removed. Noticed when reviewing rust-lang#112686.
r=me after addressing #112686 (comment) and cleaning up git history. |
Addressed the last review comments. Rebased on top of a recent master to incorporate #112892. Do you want me to merge everything into a single commit? |
When implementing a public trait with a private super-trait, we now emit a note that the missing bound is not going to be able to be satisfied, and we explain the concept of a sealed trait.
Suggest publicly accessible paths for items in private mod: When encountering a path in non-import situations that are not reachable due to privacy constraints, search for any public re-exports that the user could use instead. Track whether an import suggestion is offering a re-export. When encountering a path with private segments, mention if the item at the final path segment is not publicly accessible at all. Add item visibility metadata to privacy errors from imports: On unreachable imports, record the item that was being imported in order to suggest publicly available re-exports or to be explicit that the item is not available publicly from any path. In order to allow this, we add a mode to `resolve_path` that will not add new privacy errors, nor return early if it encounters one. This way we can get the `Res` corresponding to the final item in the import, which is used in the privacy error machinery.
Well, ideally it would still be commit per independent change, but the PR is now much smaller so it's not too bad as is. |
☀️ Test successful - checks-actions |
Finished benchmarking commit (04075b3): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 661.969s -> 663.045s (0.16%) |
On trait bound errors caused by super-traits, identify if the super-trait is publicly accessibly and if not, explain "sealed traits".
Deduplicate privacy errors that point to the same path segment even if their deduplication span are different.
When encountering a path that is not reachable due to privacy constraints path segments other than the last, keep metadata for the last path segment's
Res
in order to look for alternative import paths for that item to suggest. If there are none, be explicit that the item is not accessible.