-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Disable Ctrl-C handling on WASM #123788
Disable Ctrl-C handling on WASM #123788
Conversation
This comment has been minimized.
This comment has been minimized.
WASM fundamentally doesn't support signals. If WASI ever gets support for notifying the guest process of a Ctrl-C that happened, this would have to be done through the guest process polling for the signal, which will require thread support in WASI too to be compatible with the api provided by the ctrlc crate.
It incorrectly filters out non-wasm dependencies too.
26291ce
to
8b0b88a
Compare
The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging. |
this seems reasonable to me, I don't know much about wasm though 🤷 cc @alexcrichton maybe? What's the impact of simply using r=me after CI |
CI failure is because of a tidy bug. It checks if a target dependent dependency applies to wasm and if so ignores it. This check however also triggers if it doesn't just apply to wasm but also to other targets. So for example |
I got a compilation failure when compiling the ctrlc crate. The errors in question
|
@@ -668,27 +670,7 @@ fn check_permitted_dependencies( | |||
let mut deps = HashSet::new(); | |||
for to_check in restricted_dependency_crates { | |||
let to_check = pkg_from_name(metadata, to_check); | |||
use cargo_platform::Cfg; | |||
use std::str::FromStr; | |||
// We don't expect the compiler to ever run on wasm32, so strip |
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.
😈
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.
r=me
@bors r=Nilstrieb,lcnr |
|
Looks good to me as well 👍 |
Yes, the cargo-platform dependency can be removed. I've opened #123796 for this as this PR is already being tested by bors. |
☀️ Test successful - checks-actions |
Finished benchmarking commit (72fe8a0): 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.
CyclesResultsThis 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 676.108s -> 675.554s (-0.08%) |
…ubby789 Remove unused cargo-platform dependency from tidy Noticed in rust-lang#123788 (comment)
Rollup merge of rust-lang#123796 - bjorn3:remove_cargo_platform, r=clubby789 Remove unused cargo-platform dependency from tidy Noticed in rust-lang#123788 (comment)
WASM fundamentally doesn't support signals. If WASI ever gets support for notifying the guest process of a Ctrl-C that happened, this would have to be done through the guest process polling for the signal, which will require thread support in WASI too to be compatible with the api provided by the ctrlc crate.