-
Notifications
You must be signed in to change notification settings - Fork 53
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
[2025H1] Continue cargo-semver-checks
goal from 2024H2.
#166
[2025H1] Continue cargo-semver-checks
goal from 2024H2.
#166
Conversation
src/2025h1/cargo-semver-checks.md
Outdated
| Allow linting generic types, lifetimes, bounds | @obi1kenobi | | | ||
| Handle "special cases" like `'static` and `?Sized` | @obi1kenobi | | | ||
| Handle `#[doc(hidden)]` in sealed trait analysis | @obi1kenobi | | | ||
| Discussion and moral support | ![Team][] [cargo] | | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can also count on "discussion and moral support" from T-Rustdoc as-well here. You can probably expect small-simple things from us (eg rust-lang/rust#133715, rust-lang/rust#119246), but not larger things (the big one presumably being robust cross-crate Id's (which I don't think has a tracking issue, welp).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds great, I can add it — thank you.
Any idea if for the purposes of the goal tracking, that should be a separate row in the table, or another team entry in the same row? I know there's some automation around this and I don't want to break it 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found a precedent for it in another proposal :)
Add T-rustdoc discussion and moral support.
The main difficulty here lies with the expressiveness of the Rust type system. For example, none of the following changes are breaking: | ||
```rust | ||
// previous release: | ||
pub fn example(value: String) {} | ||
|
||
// new release: | ||
pub fn example(value: impl Into<String>) {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies if this is out of topic, but I didn't know where else to report this.
The text is saying that it is not a breaking change to turn a String
into a impl Into<String>
, but it is a breaking change when considering type inference.
example(Default::default());
example("hello".into());
Both call worked in the former case but not anymore in the second case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you're right — this is just imprecise use of language on my part.
The changes are not major, in the sense of requiring a SemVer major bump. They are breaking for the current implementation of inference. They are not breaking in an absolute sense, in that better tooling (rustc
or other tools) could avoid the breakage without changing program semantics. This is why inference-related breakage does not require a major bump in Rust.
More info here: https://predr.ag/blog/some-rust-breaking-changes-do-not-require-major-version/
Rendered.
Continuation of the 2024H2 goal. Check out its tracking issue here.