-
Notifications
You must be signed in to change notification settings - Fork 13.9k
[WIP] Bring rust-semverver in-tree and test that it builds. #73902
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
Conversation
Make it work again :)
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@bors rollup=never (in case the tools builder fails) |
|
I am a strong supporter of us shipping this tool, but I'd like to understand the maintenance plan -- can we create a team for it under the dev-tools team, for example? |
|
Yes, that's one of the questions I was hoping an MCP (or similar, perhaps RFC or so) would answer. To be clear, I've not been planning on reviewing this until someone with "T-compiler" hat on says that we're going to merge this in and we have some sort of plan for maintenance etc. |
|
The dev tools team has been "maintenance mode" maintaining it, doing rustups. We can continue keeping an eye on it, in part one of the things we do is keep an eye out for these smaller tools. We'd need maintainers to do more |
This comment has been minimized.
This comment has been minimized.
Bump mingw-check CI image from Ubuntu 16.04 to 18.04. I chose 18.04 because we use it for other builders, and it's enough to get a version of MinGW that can build `libssh2-sys`. This is a prereq for rust-lang#73902, where `libssh2-sys` shows up as an indirect dependency of `x.py check src/tools/semverver` (through `src/tools/cargo`, which we don't currently `x.py check` because it's not in-tree). See also rust-lang#73902 (comment). r? @Mark-Simulacrum cc @mati865
This comment has been minimized.
This comment has been minimized.
|
@bors rollup=never |
|
☔ The latest upstream changes (presumably #73441) made this pull request unmergeable. Please resolve the merge conflicts. |
|
☔ The latest upstream changes (presumably #73265) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Closing this as it's blocked for a long time |
What is
rust-semverver?This PR initializes
src/tools/rust-semververto rust-lang/rust-semverver@0bbdabf usinggit subtree add, akin to what @oli-obk did to bringclippyin-tree. Only the last 3 commits are mine.I was also able to make
./x.py check src/tools/semververand./x.py build src/tools/semververwork, but for now I've kept./x.py test src/tools/semververequivalent tobuild(i.e. not actually running any tests), pending actual test integration.To get tests working I suspect we'll have to rewrite some of the test driving logic in
src/tools/semverver/teststo rely more on environment variables than relative paths (akin to whatclippydoes).In order to get
rust-semververto build successfully in-tree, I had to work around the fact that it depends on some Cargo crates which do not build withSourceType::InTree(i.e. Cargo doesn't build with-Drust_2018_idioms), so for now it's usingSourceType::Submoduledespite that being incorrect forsrc/tools/semververitself.I also updated it to the latest rustc and Cargo, but I haven't tested that it still works afterwards.
r? @Mark-Simulacrum cc @ibabushkin @rust-lang/compiler @rust-lang/dev-tools @Manishearth @JohnTitor