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

new lint: trait_method_marked_deprecated #1098

Merged

Conversation

Frank-III
Copy link
Contributor

part of #57

Comment on lines 23 to 24
method_name: name @output @tag
deprecated @filter(op: "=", value: ["$true"])
Copy link
Owner

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

Copy link
Owner

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.

Copy link
Contributor Author

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

Copy link
Owner

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 :)

@obi1kenobi obi1kenobi merged commit 0aedef0 into obi1kenobi:main Feb 4, 2025
31 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants