-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Respect doc(hidden) when suggesting available fields #93214
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
fn main() { | ||
A::default().hey; | ||
//~^ ERROR no field `hey` on type `A` | ||
//~| NOTE unknown field |
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'm not sure why this note is needed, it doesn't show up in the stderr output 🤔
I’m… not entirely sure this is a holistically a correct thing to do. Compiler diagnostics are not documentation. And the field is accessible either way – it just takes another tool failing to account for My intuition is that rustc itself should not look at the That said it seems like it already does account for
For the |
It might be good to do the same thing as with enum variants: To also hide them when a field is part of an unstable feature that's not enabled. |
I've added handling for unstability in my own branch: danielhenrymantilla@issue-93210
|
fn main() { | ||
A::default().hey; |
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.
fn main() { | |
A::default().hey; | |
fn main() { | |
A::default().hallo; | |
A::default().hey; |
.hallo
may trigger similarly-named field suggestions, which may also be interesting behavior to test
Looks like there are design questions to be solved here, so r? rust-lang/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 agree with @nagisa that it seems less than great that #[doc(hidden)]
is used here.
It seems like we could either use a pub(macro)
(can only be used in downstream crates when through one of this crate's macro), but I imagine that wouldn't really work with procedural macros; or a new attribute that the user can use to signal that something shouldn't be used in suggestions, rather than #[doc(hidden)]
.
Regardless, it seems like #[doc(hidden)]
is what we've got right now and we're using it for this in other places, so might as well do so here too. Implementation for this looks good - if you want to address @danielhenrymantilla's comment then feel free to, otherwise r=me (I'll do this in a day or two if there aren't any changes).
@bors r+ |
📌 Commit b734abc has been approved by |
…askrgr Rollup of 8 pull requests Successful merges: - rust-lang#90277 (Improve terminology around "after typeck") - rust-lang#92918 (Allow eliding GATs in expression position) - rust-lang#93039 (Don't suggest inaccessible fields) - rust-lang#93155 (Switch pretty printer to block-based indentation) - rust-lang#93214 (Respect doc(hidden) when suggesting available fields) - rust-lang#93347 (Make `char::DecodeUtf16::size_hist` more precise) - rust-lang#93392 (Clarify documentation on char::MAX) - rust-lang#93444 (Fix some CSS warnings and errors from VS Code) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Out-of-topic / meta comment: wow, since my commit was originally pushed (to my branch) quite a while ago, now that it has just been integrated in this PR, it nonetheless appears as occurring before I even made the very comment about it! 😆 (more seriously, I was confused by the lack of apparent changes in the "PR feed" near the bottom; I hope they somehow change that 😅). |
Resolves #93210