-
-
Notifications
You must be signed in to change notification settings - Fork 92
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
new lint: trait_method_marked_deprecated
#1098
new lint: trait_method_marked_deprecated
#1098
Conversation
6393141
to
ea19ac8
Compare
method_name: name @output @tag | ||
deprecated @filter(op: "=", value: ["$true"]) |
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.
This needs a public_api_eligible
check both here and on the baseline side.
Otherwise, this lint will flag trait methods that were #[doc(hidden)]
in the baseline, which is incorrect since they weren't public API.
Relevant docs here:
https://github.com/obi1kenobi/trustfall-rustdoc-adapter/blob/rustdoc-v39/src/rustdoc_schema.graphql#L91-L110
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.
Consider adding test cases for #[doc(hidden)]
on the trait and on the trait method, to make sure that non-public-API items don't get reported by this lint.
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.
Thank you! was looking into the sealed thing, and got stuck, why it is so complex 😭. I would continue and finish trait associated types
and trait associated constants
then
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.
why it is so complex
The best answer is that it's a system that grew organically, and was not designed intentionally as a whole. There's no concept of a "sealed" or "public API sealed" trait in rustc or the Rust language proper — those things are ones that someone merely noticed are possible within the current language boundaries, and they've proven useful to the community so they remain in use.
If they were designed intentionally, we'd have e.g. a #[sealed]
attribute on traits instead. This may yet happen! The process for #[non_exhaustive]
was similar: there was a common workaround for it that was broadly used in the community, and eventually enough momentum built for a language-level fix that became the #[non_exhaustive]
attribute.
I'm reasonably confident that sooner or later, we'll have something along these lines for trait sealing as well. But first, someone has to analyze the present situation, figure out all the edge cases, and write it up in a form that gets the community interested. In this case, that someone was me :)
part of #57