-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Tracking Issue for removing unsafe code from bootstrap #109859
Comments
I'm not convinced that replacing trivial unsafe for calling libc or windows APIs with dependencies makes sense. That code is rarely changed and the dependency isn't necessarily better vetted (certainly on updates more work). IMO unsafe code is fine where there's not much in the way of alternative implementations. |
The symlink code at least I think makes sense to replace, it's quite complicated and I don't know anyone on the team who could maintain it. I could be convinced What worries me most is that we don't have any sorts of tests for this code :/ @saethlin has already found one unsoundness in the cache code which broke local-rebuild for a stable release until we backported a fix. I'm not convinced there isn't more unsoundness that we just haven't noticed yet. |
Third party code that matches our code is just as likely to have problems, imo, and is harder to patch. So I don't really see soundness or lack thereof as a strong argument in this case. The majority of this code has worked fine for years at this point; I believe the soundness problem wasn't actually leading to UB? But in any case, certainly if we're changing the code replacing it with a library that does equivalent things is fine. But I wouldn't take a goal of "unsafe is special" here. |
cc #109960 :) |
…afe, r=clubby789 add `SAFETY` block on the usage of unsafe `getuid` We pointed out this unsafe usage in rust-lang#109859, and as a result, we received a fix PR rust-lang#116476. However, it's important to note that the `libc::getuid()` never actually fails. This PR aims to clarify its safety.
…afe, r=clubby789 add `SAFETY` block on the usage of unsafe `getuid` We pointed out this unsafe usage in rust-lang#109859, and as a result, we received a fix PR rust-lang#116476. However, it's important to note that the `libc::getuid()` never actually fails. This PR aims to clarify its safety.
Rollup merge of rust-lang#116577 - onur-ozkan:add-safety-block-on-unsafe, r=clubby789 add `SAFETY` block on the usage of unsafe `getuid` We pointed out this unsafe usage in rust-lang#109859, and as a result, we received a fix PR rust-lang#116476. However, it's important to note that the `libc::getuid()` never actually fails. This PR aims to clarify its safety.
The OP is a bit outdated, here's the current state of affairs.
|
Closing because:
E.g. replacing |
For more context, see the relevant Zulip thread. |
This is a tracking issue for removing unsafe code from bootstrap. This is an implementation detail of the build system and there is no associated RFC.
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
If you are interested in working on this issue, please leave a comment saying which part you are working on. Do not use
@rustbot claim
; this issue is too large to be done by a single person. Do not claim a checkbox that has already been claimed without first asking the existing assignee.Note that much of this code is platform-specific. I strongly recommend not working on Windows-specific code if you don't have a computer that can run Windows, and vice-versa for Unix.
You can ask for help in https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap, #dark-arts on the community discord (https://discord.gg/rust-lang-community), or #windows-dev on the community discord. Please do not ask for help on this tracking issue since it will quickly get overwhelming.
Here are the current uses of
unsafe
:rust/src/bootstrap/util.rs
Lines 149 to 249 in d6f2740
std::path::absolute
, copied into bootstrap:rust/src/bootstrap/util.rs
Lines 560 to 585 in d6f2740
std::path::absolute
#92750rusage
metadata on unix:rust/src/bootstrap/bin/rustc.rs
Lines 354 to 413 in d6f2740
rusage
metadata on windows:rust/src/bootstrap/bin/rustc.rs
Lines 281 to 352 in d6f2740
libc::setpriority
:rust/src/bootstrap/lib.rs
Lines 76 to 78 in 249198c
nix
.libc::getuid
:rust/src/bootstrap/lib.rs
Lines 349 to 358 in 249198c
job.rs
, I don't really understand what's going on there:rust/src/bootstrap/job.rs
Lines 50 to 143 in d6f2740
cache.rs
:rust/src/bootstrap/cache.rs
Lines 63 to 103 in fe0b042
cc @rust-lang/bootstrap
Unresolved Questions
Are there any safe wrappers for the following APIs?
job.rs
libc::setpriority
rusage
on WindowsImplementation history
The text was updated successfully, but these errors were encountered: