Change signal constants to c_int on espidf

[saethlin]

The espidf targets cannot build libtest because the types of these signal constants disagree with all the other cfg(unix) targets. Since they're of course macros on the C side https://github.com/espressif/newlib-esp32/blob/7cdcb0b0848a5d909e906834fe81903ba9466c90/newlib/libc/include/sys/signal.h#L259-L269 I think c_int is a more reasonable type to use. Without this change, attempting to build libtest will produce this error:

error[E0308]: mismatched types
   --> /home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/test/src/test_result.rs:108:18
    |
107 |         None => match status.signal() {
    |                       --------------- this expression has type `std::option::Option<i32>`
108 |             Some(libc::SIGABRT) => TestResult::TrFailed,
    |                  ^^^^^^^^^^^^^ expected `i32`, found `usize`

It's not entirely clear to me why the conversation on #3615 and the issues from there petered out. I'm a bit concerned that the users just configured their editors to suppress the error and moved on. That's certainly what it looks like.

I've checked that this fixes the problem by pointing my rust-lang/rust checkout to my libc branch and running

MIRI_LIB_SRC=/home/ben/rust/library cargo +nightly miri setup --target riscv32imafc-esp-espidf

or

x check library/test --target riscv32imafc-esp-espidf

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @JohnTitor (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[saethlin]

cc @Tevz-Beskovnik because you wrote #3658, just in case you want to tell me that this PR is a bad idea for some target-specific reason 🙈

[tgross35]

This looks reasonable to me since the sigaction functions seem to still use the default int https://github.com/espressif/newlib-esp32/blob/7cdcb0b0848a5d909e906834fe81903ba9466c90/newlib/libc/include/sys/signal.h#L184 (our version

libc/src/unix/mod.rs

Line 1533 in cdf6896

pub fn sigaction(

), I don't know where else these would be used. But I'll give another day or two for Tevz-Beskovnik to respond before merging, just in case.

[saethlin]

Also I would rather like to have this in the rustc repo so that the relevant targets can build again. I think that means this needs to go to the 0.2 branch as well? Do you just take care of that?

[tgross35]

Yeah, if you just put the stable-nominated label then I'll get it in the next round of cherry picks before my release this week (I already added it here, and it works with rustbot too)

[tgross35]

I want to do a release today so I'm just going to merge this. @Tevz-Beskovnik feel free to leave any feedback if there is a reason this shouldn't be done. We can always change it back if needed since this is tier 3.