Skip to content
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

Merged
merged 2 commits into from
Jan 31, 2022

Conversation

ibraheemdev
Copy link
Member

Resolves #93210

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jan 22, 2022
@rust-highfive
Copy link
Collaborator

r? @michaelwoerister

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 22, 2022
fn main() {
A::default().hey;
//~^ ERROR no field `hey` on type `A`
//~| NOTE unknown field
Copy link
Member Author

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 🤔

@nagisa
Copy link
Member

nagisa commented Jan 22, 2022

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 doc(hidden) before its front-and-center before the user.

My intuition is that rustc itself should not look at the doc attributes to inform its own behaviour, much like it does not look at e.g. #[rustfmt::*] or #[clippy::*] attributes.

That said it seems like it already does account for doc(hidden) in at least some places such as e.g.

if missing_ctor.is_doc_hidden_variant(pcx)
so I guess my intuition is invalid.


For the Pin case specifically, there's another potential problem – I suspect we suggest unstable fields when user is compiling with a stable compiler, or without a relevant feature enabled. That sounds like something that would want a fix given that the field cannot be accessed in that situation.

@m-ou-se
Copy link
Member

m-ou-se commented Jan 24, 2022

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 doc(hidden) before its front-and-center before the user.

#[doc(hidden)] is the only way and a very common way for libraries to mark something as 'not part of the pubilc api' when it has to be pub for macro-related reasons. In the standard library we combine it with #[unstable], but in libraries that need to work on stable Rust, there's not much more one can do than #[doc(hidden)] and adding a bunch of underscores in the name.

I suspect we suggest unstable fields when user is compiling with a stable compiler, or without a relevant feature enabled. That sounds like something that would want a fix given that the field cannot be accessed in that situation.

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.

@danielhenrymantilla
Copy link
Contributor

I've added handling for unstability in my own branch: danielhenrymantilla@issue-93210

  • (you can apply it here with git pull https://github.com/danielhenrymantilla/rust issue-93210)

Comment on lines +14 to +15
fn main() {
A::default().hey;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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

@michaelwoerister
Copy link
Member

Looks like there are design questions to be solved here, so r? rust-lang/diagnostics

Copy link
Member

@davidtwco davidtwco left a 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).

@davidtwco
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Jan 31, 2022

📌 Commit b734abc has been approved by davidtwco

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 31, 2022
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 31, 2022
…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
@danielhenrymantilla
Copy link
Contributor

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 😅).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

'available fields are' message in diagnostic lists unstable/hidden fields.
9 participants