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

Fix description and tests for inherent_method_must_use_added #677

Merged
merged 3 commits into from Mar 2, 2024

Conversation

pksunkara
Copy link
Contributor

Fixes #674

Copy link
Owner

@obi1kenobi obi1kenobi left a comment

Choose a reason for hiding this comment

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

Very nice, thank you! 🚀

I really appreciate your work on improving the lints! I'd love to merge any more improvements you find. If you might be interested in some opportunities for improvement deeper than the lints themselves, I'd be happy to suggest some ideas as well.

src/lints/inherent_method_must_use_added.ron Outdated Show resolved Hide resolved
@obi1kenobi obi1kenobi enabled auto-merge (squash) March 2, 2024 00:38
@obi1kenobi obi1kenobi merged commit 85de3e2 into obi1kenobi:main Mar 2, 2024
35 checks passed
@pksunkara pksunkara deleted the issue-674 branch March 2, 2024 00:44
@pksunkara
Copy link
Contributor Author

All functions defined within an impl block are called associated functions because they’re associated with the type named after the impl.

From my understanding, by default, associated fn of a type means the ones within inherent impl.

@pksunkara
Copy link
Contributor Author

If you might be interested in some opportunities for improvement deeper than the lints themselves

Honestly, I am really itching to revamp the whole test system so that it can be used to auto-generate documentation. But I have been holding back because I know it needs to be discussed first.

@obi1kenobi
Copy link
Owner

All functions defined within an impl block are called associated functions because they’re associated with the type named after the impl.

From my understanding, by default, associated fn of a type means the ones within inherent impl.

I'm not sure — and even if that is the case, it's best to err on the side of clarity. It's better to avoid causing misunderstandings than to be technically correct while confusing users.

Honestly, I am really itching to revamp the whole test system so that it can be used to auto-generate documentation. But I have been holding back because I know it needs to be discussed first.

Neat! I agree it could be better, in a variety of ways. Would you care to open an issue and write down your thoughts on it? I'd love to hear what you'd change, how you'd change it, and what auto-generated documentation would be created as a result!

I'm particularly curious about:

  • Whether we can make the revamp be a sequence of small, smooth steps, each of which is easy to review and merge, and leaves the overall system better off than before. This would massively de-risk the transition.
  • Whether we can easily add testing of the error message templating, since it's had issues in the past — some of which you've flagged as well.
  • Whether we should try to adopt a tool like insta (Consider switching to insta for snapshot testing #634) for managing our snapshot tests, or if it would be too slow or otherwise add too much friction.

Another key thing I strongly care about is making sure to keep the CONTRIBUTING.md doc updated to match how development happens, since otherwise our project wouldn't be very contributor-friendly.

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.

Description and tests for inherent_method_must_use_added is not complete
2 participants