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

[2025H1] Continue cargo-semver-checks goal from 2024H2. #166

Merged

Conversation

obi1kenobi
Copy link
Member

Rendered.

Continuation of the 2024H2 goal. Check out its tracking issue here.

| 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] | |
Copy link
Member

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).

Copy link
Member Author

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 😅

Copy link
Member Author

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 :)

@nikomatsakis nikomatsakis merged commit 8531567 into rust-lang:main Dec 2, 2024
1 check passed
Comment on lines +99 to +105
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>) {}

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.

Copy link
Member Author

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/

@obi1kenobi obi1kenobi deleted the continue-cargo-semver-checks branch January 19, 2025 20:00
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.

4 participants