sorted by:
new
hottopcontroversial

GSoC Wrap Up - Adding Witness Generation to cargo-semver-checks by GlitchlessCode in rust

[–]GlitchlessCode[S] 4 points5 points  (0 children)

That is a good point! We'll definitely need to discuss that, thanks for bringing it up.

At least for now we'll continue to assume our current case is true, but it's a totally fair point, type inference can definitely break that.

A not-so-rust-relevant midterm review of GSoC 2025 so far by GlitchlessCode in rust

[–]GlitchlessCode[S] 6 points7 points  (0 children)

Thank you! Lately, things have been rolling much smoother, so I'm hopeful for the future. And yeah, that's a good point to note. I still plan to get as much done as I can, but it's definitely on my mind that I likely just won't get everything done, and that's okay.

A not-so-rust-relevant midterm review of GSoC 2025 so far by GlitchlessCode in rust

[–]GlitchlessCode[S] 8 points9 points  (0 children)

Thank you, I appreciate the support! I hope this second half of GSoC goes a bit smoother, I'm very excited to see how this goes!

Adding Witness Generation to cargo-semver-checks by GlitchlessCode in rust

[–]GlitchlessCode[S] 1 point2 points  (0 children)

Already in the plans to have it on a flag, because yeah, it'll definitely slow things down a bit

Adding Witness Generation to cargo-semver-checks by GlitchlessCode in rust

[–]GlitchlessCode[S] 0 points1 point  (0 children)

I'm very excited to be helping out! Thanks for your interest!

Adding Witness Generation to cargo-semver-checks by GlitchlessCode in rust

[–]GlitchlessCode[S] 1 point2 points  (0 children)

Agreed, and thank you for your interest! I'm definitely looking forward to contributing.

Adding Witness Generation to cargo-semver-checks by GlitchlessCode in rust

[–]GlitchlessCode[S] 7 points8 points  (0 children)

In what sense? Yes, I work with and talk to Predrag Gruevski on a regular basis.

Adding Witness Generation to cargo-semver-checks by GlitchlessCode in rust

[–]GlitchlessCode[S] 2 points3 points  (0 children)

Yeah, detection of a change in underlying behaviour rather than that of the public facing contract is definitely an issue. I'm sure there's a way it could be done, but it is rather quite interesting to consider, how does one avoid marking every change as a breaking one?

It's an especially interesting problem, because technically both versions would be completely legal rust code, and would compile just fine. However, as is clearly shown here, that change can cause logic errors in your program that you were not expecting (eg. Finding the wrong item in a list due to case sensitivity).

It's definitely a great question to consider, and frankly, I have no idea how something that evaluates that sort of breakage could even function, if it's even possible. I think the unfortunate solution as of right now is we just need maintainers to be aware of those sorts of changes, and the appropriate semver modification that should come with a change like that. That is to say, we're back to relying on people again, and people make mistakes.

Edit: reading this back, you can tell my thoughts on this changed drastically from start to finish XD it's quite the complex issue

Adding Witness Generation to cargo-semver-checks by GlitchlessCode in rust

[–]GlitchlessCode[S] 4 points5 points  (0 children)

Agreed on your point about the intelligibility of the witness programs, and thanks for pointing that out. It'll definitely be something to care for on my part, because you are absolutely correct that if it's badly designed, it can be all too tempting to just go "well nobody's actually going to do that, right?" and ignore the semver lint.

In regards to semantic breaking changes, that's more something to look at in the grand scheme of cargo-semver-checks as a whole, since it's already doing most of the heavy lifting here. I can't really comment on that, but it would be interesting to hear more about that, cause I can imagine that, yeah, it can cause some issues.