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

Prepare for merging into cargo #61

Open
7 of 26 tasks
epage opened this issue Aug 9, 2022 · 2 comments
Open
7 of 26 tasks

Prepare for merging into cargo #61

epage opened this issue Aug 9, 2022 · 2 comments

Comments

@epage
Copy link
Collaborator

epage commented Aug 9, 2022

Blockers

Nice-to-haves

Open questions

  • Integrated into cargo or separate rustup component like clippy?
  • How does the process for making new rustdoc JSON formats work w.r.t. cargo-semver-checks merged into cargo?
    • PRs to rust-lang/rust run submodule test suites, like cargo's. Presumably they would test the merged cargo-semver-checks as well.
    • If a PR to rust-lang/rust emits a new rustdoc JSON format version, cargo-semver-checks would need to be updated to support it.
    • That appears to be a chicken-and-egg problem: the PR won't pass, so no new versions of rustdoc-types will exist, so no new cargo-semver-checks -> cycle.

Things to remove

Merge Proposal (example):

Motivation

Drawbacks

Behavior

Alternatives

Prior Art

Future Possibilities

@epage
Copy link
Collaborator Author

epage commented Oct 16, 2022

While we have #86, the thing we need to keep in mind broadly is "what will it take for us to be comfortable locking down the design for near perfect compatibility?"

There several routes to use in answering that question

  • Stablize a subset but have vetted enough other designs to know we didn't pin ourselves down
  • Flesh out intended workflows polish them up for use.
  • Collect feedback
  • Put out a proposal to force people to speak up (people are quick to respond when they think someone is wrong on the internet)
  • Have an extended out-of-tree period for collecting input, iterating, etc.

Areas we need to consider

  • CLI
  • Lint names
  • Lint behavior
  • How to add lints without breaking compatibility
  • What level of lints is sufficient for the initial level people use before we allow them to opt-in to more

It might be good to get feedback from clippy on what their compatibility guarantees are around lints. I expect at minimum, we shouldn't be changing them in a way that significantly impacts how people use them.

@thomaseizinger
Copy link
Contributor

Would it make sense to integrate this directly into cargo check and run it by default?

The "no-false-positive" mindset seems like this would be safe!

Alternatively, it could also be part of cargo test, similar to how rustdoc tests run automatically.

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

No branches or pull requests

2 participants