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

Support running custom user-specified checks #38

Open
obi1kenobi opened this issue Aug 7, 2022 · 3 comments
Open

Support running custom user-specified checks #38

obi1kenobi opened this issue Aug 7, 2022 · 3 comments
Labels
A-cli Area: engine around the lints C-enhancement Category: raise the bar on expectations

Comments

@obi1kenobi
Copy link
Owner

There are valid use cases for running additional (not-necessarily-semver) user-provided checks against a codebase. A few examples:

  • Ensuring that a builder pattern struct always uses either &mut self or self and doesn't mix across them.
  • Ensuring that certain types don't leak out through the API, even though they are public (perhaps from another crate).

These are all reasonable queries runnable over the existing schema and Trustfall adapter used here. We just need to design the CLI for specifying the additional checks, and the file format (serde struct) the additional check files should use.

Tangentially related to #5.

@obi1kenobi obi1kenobi pinned this issue Aug 7, 2022
@epage
Copy link
Collaborator

epage commented Aug 9, 2022

FYI these sound more like clippy lints than API diffing checks

@epage epage added A-cli Area: engine around the lints C-enhancement Category: raise the bar on expectations labels Aug 9, 2022
@thomaseizinger
Copy link
Sponsor Contributor

  • Ensuring that certain types don't leak out through the API, even though they are public (perhaps from another crate).

I am really interested in this one, mostly because leaking another library's type in your API can be a semver hazard, esp. if that library is pre 1.0.

Is a semver violation through dependency bumps of libraries that appear in the public API caught today?

@obi1kenobi
Copy link
Owner Author

I am really interested in this one, mostly because leaking another library's type in your API can be a semver hazard, esp. if that library is pre 1.0.

It would indeed be awesome to have. Unfortunately, we probably need to figure out how to best enable/disable checks on an individual basis (#58), because not all users will want to prohibit all external types.

In the meantime, this crate might be worth a look, although I haven't used it personally: https://crates.io/crates/cargo-check-external-types

Is a semver violation through dependency bumps of libraries that appear in the public API caught today?

I'm not sure — it depends on how exactly it's represented in rustdoc JSON. I'm hesitant to give an "authoritative" answer since a change in the rustdoc JSON format could flip the boolean in the answer :)

I can say that if this is caught today, it's caught via a happy accident as opposed to intentionally.

@obi1kenobi obi1kenobi unpinned this issue Jan 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-cli Area: engine around the lints C-enhancement Category: raise the bar on expectations
Projects
None yet
Development

No branches or pull requests

3 participants