Uh oh!
There was an error while loading. Please reload this page.
unify bootstrap and shim binaries - #95164
Conversation
rust-highfive
commented
Mar 21, 2022
(rust-highfive has picked a reviewer for you, use r? to override) |
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.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Maybe use Build::copy instead? It hardlinks and falls back to copying if it fails. Some systems may not support hardlinks.
There was a problem hiding this comment.
Build::copy defeats the point, it means the new files won't be updated on changes.
I don't know a good solution here :/ maybe we could do test somewhere of whether the fs supports file links and copy unconditionally if so?
There was a problem hiding this comment.
it means the new files won't be updated on changes
Not sure what you meant. The current implementation is as follows:
/// Copies a file from `src` to `dst`pubfncopy(&self,src:&Path,dst:&Path){ifself.config.dry_run{return;}self.verbose_than(1,&format!("Copy {:?} to {:?}", src, dst));if src == dst {return;}let _ = fs::remove_file(&dst);let metadata = t!(src.symlink_metadata());if metadata.file_type().is_symlink(){let link = t!(fs::read_link(src));t!(symlink_file(link, dst));}elseifletOk(()) = fs::hard_link(src, dst){// Attempt to "easy copy" by creating a hard link// (symlinks don't work on windows), but if that fails// just fall back to a slow `copy` operation.}else{ifletErr(e) = fs::copy(src, dst){panic!("failed to copy `{}` to `{}`: {}", src.display(), dst.display(), e)}t!(fs::set_permissions(dst, metadata.permissions()));let atime = FileTime::from_last_access_time(&metadata);let mtime = FileTime::from_last_modification_time(&metadata);t!(filetime::set_file_times(dst, atime, mtime));}}Which is akin to an unconditional hard_link.
There was a problem hiding this comment.
No, because if you hit the fs::copy path, then the next time bootstrap is executed "rustc".exists() will return true and it will never recopy the binary. Which defeats the whole point of this change.
There was a problem hiding this comment.
That is true, I will just remove the check for rustc.exists() because it was triggering a filesystem error because the dest file already existed.
There was a problem hiding this comment.
Ah, I suppose that works too. The hard link should be very cheap compared to everything else bootstrap does 👍
Mark-Simulacrum
left a comment
There was a problem hiding this comment.
Can we name the "primary" (i.e., the one produced by rustc) binary something less difficult to refer to? Maybe rustbuild-binary-dispatch-shim?
Please also squash the commits as you make changes, no need for "review changes" commits.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
a6aa04c to
578826aCompare
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
commented
Apr 10, 2022
☔ The latest upstream changes (presumably #95253) made this pull request unmergeable. Please resolve the merge conflicts. |
they are now dispatched based on the binary name it is called with.
`target/debug/rust{c, doc}` are now hard linked to `bootstrap`.fee1-dead
commented
May 10, 2022
Umm, I took a look and it looks like it already tries to remove the destination before copying: https://cs.github.com/rust-lang/rust/blob/fee75fbe11b1fad5d93c723234178b2a329a3c03/src/bootstrap/lib.rs#L1418 |
bjorn3
commented
May 11, 2022
Windows doesn't allow deleting files that are currently open by default. I believe FILE_DISPOSITION_POSIX_SEMANTICS allows deleting open files though. |
fee1-dead
commented
May 11, 2022
So I tried to use |
Mark-Simulacrum
commented
May 11, 2022
I'm not sure that function is publicly exposed, but we can try. @bors r+ |
bors
commented
May 11, 2022
📌 Commit 64a8af9 has been approved by |
bors
commented
May 11, 2022
⌛ Testing commit 64a8af9 with merge c0220834cf72ccea19c0454ad82db04e18ea67a7... |
bors
commented
May 11, 2022
💔 Test failed - checks-actions |
rust-log-analyzer
commented
May 11, 2022
The job Click to see the possible cause of the failure (guessed by this bot) |
bors
commented
May 14, 2022
⌛ Testing commit 64a8af9 with merge 83698375db8b68e4b56f5a650443f96accc44471... |
bors
commented
May 14, 2022
💔 Test failed - checks-actions |
rust-log-analyzer
commented
May 14, 2022
The job Click to see the possible cause of the failure (guessed by this bot) |
jyn514
commented
May 25, 2022
This should no longer be necessary with the new plan, since no one will run Sorry to spend so much of your time on this. |
fee1-dead
commented
May 26, 2022
I did take a look at rustup, and it looks like they retry the deletion with timeout instead of invoking the functions once. Maybe that will resolve the issue (perhaps due to concurrency?) But if this is not needed anymore I'm happy to leave it. |
they are now dispatched based on the binary name it is called with.
target/debug/rust{c, doc}are now hard linked tobootstrap.This fixes#95141, cc @jyn514.