rust-semverver issues

[gnzlbg]

rust-semverver was migrated from the nursery, to the rust-dev-tools org:

• it's CI has not been working on PRs since (travis and appveyor). I've complained on Discord, PRs comments, etc. many times, but no action has been taken.

• it's tied to the rust toolchain version, so it breaks often. This isn't an issue, what's an issue is when PRs that fix this take weeks to merge, at which point some other rust nightly change has broken the tool.

• a new cargo release removed support for APIs that this library is using, meaning that its stuck using a 5 months old cargo version. These things should be better coordinated: breaking tools without providing / discussing a migration path should not happen by accident.

[Manishearth]

cc @nrc could you grant admin permissions on this org to a couple more people? I'll look into fixing CI.

I'm not sure if this tool is actually being actively maintained by the devtools team 😄 It was developed as a GSOC project, but I don't think we've got anyone maintaining it long term at the moment. I could be wrong; @ibabushkin would know more.

We're currently in the process of reorganizing the devtools team but we'll probably try and keep track of smaller tools like this much better in the future.

[gnzlbg]

I'm (hopefully temporarily) libc's only maintainer. I'm manually using this tool to verify that changes to rust-lang/libc are non-breaking. If the tool was more actively maintained, CI could do this for me (there is a PR that does this, but can't be merged until maintenance improves: rust-lang/libc#1154), which would allow me to use my time for other things.

Adding new functionality or refactoring code in libc without introducing breaking changes is hard, and this tool helps me a lot.

@ibabushkin has written a super-awesome tool that every critical crate to the Rust ecosystem should be using (libc, libcore/liballoc/libstd, etc.). We should support moving this tool over the finish line and ship it via rustup and/or cargo.

[dwijnand]

I very much agree too. I've already got my hand in a few jars already but, generally, I'd be happy to try and help get this tool ready for widespread adoption.

[Manishearth]

I suspect the other issue here is getting this on the cargo team's radar (perhaps having them adopt it?) so that they can work with any maintainers we have on this side to make the integration story more robust.

Dale, do you think you would be able to push on this on the cargo team's side?

[dwijnand]

I can present to the team this logistical issue, but I don't know what the current integration story is, so I'd have to look into that or someone would have to explain it to me in order for me to present it to the cargo team. But I would be happy to.

[ibabushkin]

Okay, to chime in: I essentially had a not-so-brief hiatus for unrelated reasons and not much time to push development forward, and @gnzlbg recently picked up a number of issues.

In terms of integration, I think the best way forward would be to compile a list of problems currently and to decide how we want to work on those. Off the top of my head:

• type checks relying on internal rustc APIs are not entirely correct
• we are using cargo to handle compilation, but a number of hacks limit the features semverver has (like supporting multi-crate repos well, feature flags, ...)
• at times internal APIs get removed and due to my lack of time I failed to push the interests in those from semverver's perspective in the corresponding places

Luckily, @gnzlbg very helpful involvement pretty much coincides with me having time again, so I'm looking forward to doing my part.

[Manishearth]

Sweet. If we want to, we can eventually move towards having this shipped with rustup as a tool like clippy and the rest, though I think we need to let the tool mature a lot before it reaches that status.

In the meantime we can still have Rust nightly CI set up the way servo does to catch breakages. We can also move most of the unstable code into rustc as an unstable API with smaller API surface, to help it break less. This was much harder to do for clippy (and only happened a little bit), but in this case you're using the rustc APIs for a specific thing that won't change too much, so that can be upstreamed hopefully.

This could also be moved to use the save_analysis APIs, which are much more stable.

[ibabushkin]

On 2019-02-28, Manish Goregaokar wrote: Sweet. If we want to, we can eventually move towards having this shipped with rustup as a tool like clippy and the rest, though I think we need to let the tool mature a lot before it reaches that status. In the meantime we can still have Rust nightly CI set up the way servo does to catch breakages. We can also move _most_ of the unstable code into rustc as an unstable API with smaller API surface, to help it break less. This was much harder to do for clippy (and only happened a little bit), but in this case you're using the rustc APIs for a specific thing that won't change too much, so that can be upstreamed hopefully. This could also be moved to use the save_analysis APIs, which are much more stable. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #45 (comment)

We had such a CI, but since the move of the repo out of the nursery, it seems to require constant attention and works rather erratically, possibly some permission issue. In terms of moving unstable code to rustc -- that seems reasonable, and might be a good point to redesign some of the checks to improve correctness.

[gnzlbg]

• type checks relying on internal rustc APIs are not entirely correct

I feel I have to raise the issue that, feature-wise, the tool is already in a far-beyond-MVP state. Rust will keep evolving, and the tool will always need to evolve to support new stable and nightly features.

Many critical crates (libc, winapi-rs, all the -sys crates, ...) don't use any fancy Rust features (no generics, no traits, no life-times, etc.) and could benefit from the tool in its current state if the organizational and infrastructure issues related to shipping it would be solved.

[ibabushkin]

On 2019-02-28, gnzlbg wrote: > * type checks relying on internal rustc APIs are not entirely correct I feel I have to raise the issue that, feature-wise, the tool is already in a far-beyond-MVP state. Rust will keep evolving, and the tool will always need to evolve to support new stable and nightly features. Many critical crates (`libc`, `winapi-rs`, all the `-sys` crates, ...) don't use any fancy Rust features (no generics, no traits, no life-times, etc.) and could benefit from the tool in its current state if the organizational and infrastructure issues related to shipping it would be solved. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #45 (comment)

While that is true, there are cases where semverver outputs incorrectly classified errors for not-so-fancy code. I'll try to come up with a solution.

[Manishearth]

Looks like someone enabled travis recently, if it's still broken lmk.

[JohnTitor]

So, I currently maintain libc crate and semverver still needs rustup sometimes. Since the maintenance is very slow, I use my own fork for libc testing but it'd be great that upstream has a fix asap and release it. I'm available for rustup, could someone (maybe @Manishearth?) give me collaborator access?

[Manishearth]

Reluctant to hand over commit access directly, but if you want things merged you can just r? me and I'll merge them. After some time I'll probably hand over commit access.