-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
fix: use git-commit-info for version information #100557
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) soon. Please see the contribution instructions for more information. |
r? @jyn514 |
Hm, so my initial thought here is that we should probably still embed some indication that the rustc isn't actually being built from that git commit, since otherwise it'll be pretty confusing when a distro patch accidentally or intentionally changes behavior (even just in terms of what can link together successfully). Can you say more about what motivates this? It looks like based on the fixed issues largely to be a case of using srlo std binaries with a distro rustc, but that feels like a pretty odd use case to me (why not just use rustup entirely at that point), and I'm wary that adding rudimentary support is enough to get people into trouble later. At the very least I'd like to know more about the desire and think about it. |
This comment has been minimized.
This comment has been minimized.
Hello. I do agree that using an srlo binary just for std would indeed be strange and uncommon (probably why that first issue has been open for such a long time). I do think, however, that it's better to have more complete version information for binaries compiled from the tarballs. I suppose that that could be harmful if the tarball was changed and someone assumed it was the same as the actual commit, though. Perhaps jyn514 has some other thoughts on that as well.
How do you think this could look, if this was done? I do agree that that's probably a good thing to have in there, but I'm not sure how. On another note, I'll try to fix up those formatting issues tomorrow morning, I completely forgot to run that. |
We could put this in --version --verbose maybe. I think in practice it won't be a giant deal; if distros are applying in patches, they should already be using
"We shouldn't arbitrarily limit what people can compile". If the people build from source without patches, that's effectively the same compiler we distribute on static.rlo and there's no reason to prevent people from using it with the precompiled artifacts. That said, I agree it's pretty strange to want to do this - would love to hear from @japaric or @Zapeth why they wanted this feature originally. (I still think it's very useful to embed the commit metadata somehow even if we don't guarantee metadata compatibility, though.) |
I think a reasonable compromise would be to set rust.description to include "tarball", by default, with a comment recommending how to avoid git-commit-hash being populated if building with patches. If we have that there I think that's enough for most of my concerns to be addressed. Even building from source without patches is a little on the questionable side (e.g., there's going to be divergence in performance due to lack of PGO and other opts we run). I think building std from source is something I'm less worried about (ultimately required for many use cases and we intend to officially support that in the future), but re-compiling rustc and then loading std from srlo seems odd. |
👍 seems good to me, we still let people do this but they have to opt into it intentionally. @dawnofmidnight could you make that change please? I would expect the code for it to be somewhere near the changes you've already made, but I haven't looked at it. |
I'm not sure what other information I can provide aside from what was already written in the linked issues, but from what I can remember my use case was that I wanted to cross-compile my rust code with a distribution-provided toolchain (ie built from tarball). I agree that adding an indication in the version information about rustc possibly not corresponding to upstream source would be useful. Maybe this could be added as an optional postfix to the git-commit-hash, using an environment variable when building the toolchain? (assuming this doesn't conflict again with targeting srlo binaries). |
This is what I meant with
No, this is incompatible with patches. If you have a different compiler, it cannot reuse the same metadata, patches can change metadata handling in arbitrary ways. You can either patch the compiler, or you can reuse pre-compiled libraries, but you can't do both. |
@jyn514 I'm a little confused, what exactly do you mean by |
@dawnofmidnight yes, those fields in config.toml are exactly what I mean :) you can read their documentation in config.toml.example. Both show up in --version iirc, which means they also affect whether metadata can be reused between compilers. |
Got it, thank you. I guess I'll append something like "Built from a source tarball." to the description. |
☔ The latest upstream changes (presumably #99967) made this pull request unmergeable. Please resolve the merge conflicts. |
I've got a local fix that makes
Does that look okay? I'll get it pushed once I figure out these git issues. |
@dawnofmidnight yes, that looks fine :) thanks! |
Okay, I think I've gotten everything figured out wrt git rebasing, but please let me know if there's something I messed up. |
This comment has been minimized.
This comment has been minimized.
...it appears not. That error doesn't seem to exist locally, strangely. I'll try again and make sure everything is fine. |
Some changes occurred in src/tools/cargo cc @ehuss |
That wasn't supposed to happen. Maybe I screwed something up while rebasing. I'm not sure how to fix this, so I'm just going to leave it alone for a bit so I don't mess anything else up. |
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.
You should be able to undo the cargo changes by running git checkout HEAD~2 src/tools/cargo && git commit --amend
.
This looks mostly right to me, but I think we're no longer solving the original issue; I left a review comment.
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.
This looks great, thanks :) I assigned this to @Mark-Simulacrum since he had opinions on the approach earlier, but r=me if Mark doesn't have comments.
@rustbot author |
Do I need to clean up the history (squashing, presumably) of this PR? It is a bit messy. @rustbot review |
r=me with commits squashed, thanks! |
This PR adds support for fetching version information from the `git-commit-info` file when building the compiler from a source tarball.
@bors r=Mark-Simulacrum |
☀️ Test successful - checks-actions |
Finished benchmarking commit (de692f1): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Footnotes |
@@ -897,12 +898,12 @@ impl Step for PlainSourceTarball { | |||
|
|||
// Create the version file | |||
builder.create(&plain_dst_src.join("version"), &builder.rust_version()); | |||
if let Some(sha) = builder.rust_sha() { | |||
builder.create(&plain_dst_src.join("git-commit-hash"), &sha); |
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.
Yeah, I overlooked this edit. I think we'll want to keep the git-commit-hash file around; it's consumed by build-manifest (
rust/src/tools/build-manifest/src/versions.rs
Line 144 in 744e397
Some("git-commit-hash") => dest = &mut git_commit, |
We can probably also fix that code, but I think it's best to leave the file in place.
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.
Oh, my bad, I didn't realize other parts of code used it. Should I open a PR to add that back, or should that be handled somehow else?
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.
If you could open a PR that would be great :)
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.
#102610 is now open :)
…rk-Simulacrum re-add git-commit-hash file to tarballs rust-lang#100557 removed the `git-commit-hash` file and replaced it with `git-commit-info`. However, build-manifest relies on the `git-commit-hash` file being present, so this adds it back. r? `@Mark-Simulacrum`
…crum re-add git-commit-hash file to tarballs rust-lang/rust#100557 removed the `git-commit-hash` file and replaced it with `git-commit-info`. However, build-manifest relies on the `git-commit-hash` file being present, so this adds it back. r? `@Mark-Simulacrum`
…crum re-add git-commit-hash file to tarballs rust-lang/rust#100557 removed the `git-commit-hash` file and replaced it with `git-commit-info`. However, build-manifest relies on the `git-commit-hash` file being present, so this adds it back. r? `@Mark-Simulacrum`
Fixes #33286.
Fixes #86587.
This PR changes the current
git-commit-hash
file that./x.py
dist puts in therustc-{version}-src.tar.{x,g}z
to contain the hash, the short hash, and the commit date from which the tarball was created, assuming git was available when it was. It uses this for reading the version so that rustc has all the appropriate metadata.Testing
Testing this is kind of a pain. I did it with something like
Then, the output of
rustc -vV
with the stage1 compiler should have thecommit-hash
andcommit-date
fields filled, rather than beunknown
. To be completely sure, you can userustc --sysroot
with the stdlib that the original./x.py dist
made, which will require that the metadata matches.