Add --deny undocumented option about cargo-public-api

[Enselic]

Thank you for the feature request. This raises the question of what tool cargo public-api is or want to be. Do we want it to become sort of a linter? I'm not sure we want that actually. But I am open to be convinced otherwise, and am happy to discuss this.

But, wouldn't it be better to fix this in rustdoc/rustc directly? Sounds like a bug in rustdoc/rustc.

[inikulin]

I would say it's already a linter with "deny" set of options for diffs. I'm going to fill an issue with rustdoc, but I believe it more likely a by design behaviour: those lints suppose to operate on a crate level and rustdoc doesn't really have a concept of public API for workspaces.

I would say this tool fills this gap - it allows complex rust codebases to introduce an "API surface concept" including stuff re-exported from internal or external crates and provide a toolset to work with that.

[Enselic]

Did you have time to file an upstream issue yet?

To me, a "linter" is a tool that finds problems with a specific version of some code. So the --deny functionality we have is not linting functionality, since it applies to a two different versions of the same code. I will try to not get into a purely semantic discussion, but I still wanted to clarify what I mean by "linter".

In order to help us evaluate the use case you have in mind, would you mind providing some minimal example code please, along with how you would invoke cargo public-api and what output you expect?

[Emilgardis]

something I just realised, isn't this already possible?

cargo clippy --workspace -- -D missing_docs

[Enselic]

Closing for now. Of course feel free to re-open in case you want to keep discussing this.