rustc: Switch `extern` functions to abort by default on panic

[alexcrichton]

This was intended to land way back in 1.24, but it was backed out due to breakage which has long since been fixed. Prior to this PR a crate could panic and unwind past an extern fn boundary, but such behavior is UB. For example, this is undefined behavior:

extern fn foo() {
    panic!();
}

fn main() {
    foo();
}

This PR changes the behavior of generated code to be sound-by-default. If an extern fn is unwound (panicked through) then it immediately aborts the program. Put another way, no extern fn can unwind.

The implementation in this PR is pretty simple because an unstable #[unwind] attribute could already be used to tweak the unwinding behavior. As a result this PR basically just switches the default from #[unwind] to #[unwind(abort)] for all extern fn definitions.

Closes #52652

[rust-highfive]

r? @zackmdavis

(rust_highfive has picked a reviewer for you, use r? to override)

[zackmdavis]

@bors r+

[bors]

📌 Commit 6ea11fd has been approved by zackmdavis

[Mark-Simulacrum]

FWIW I still personally feel like changing stable behavior without providing a stabilized way to get back the old behavior is not great, but I'm not going to block this myself, both because I think this is fairly rare and the new behavior seems overall later.

[pietroalbini]

Maybe we should do a Crater run for this?

[alexcrichton]

@bors: r-

Seems fine by me to hold off on a crater run happening!

[alexcrichton]

@bors: try

[bors]

⌛️ Trying commit 6ea11fd with merge 2e026d6...

[bors]

☀️ Test successful - status-travis
State: approved= try=True

[alexcrichton]

@craterbot run start=master#6b9b97bd9b704f85f0184f7a213cc4d62bd9654c end=try#2e026d6e5d7621634147ad4c8074f1d964dbb1be mode=build-and-test

[craterbot]

👌 Experiment pr-55982 created and queued.
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-55982 is now running on agent aws-2.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment pr-55982 is completed!
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[alexcrichton]

From that report there are four legitimate-looking regressions

• mujs - faulting code
• coroutine - faulting code
• consistenttime - faulting code
• byond - this test causes this to panic

In testing I've also noticed that the compiler no longer emits nounwind attributes for extern functions. This appears to be a regression in #51041, first showing up in Rust 1.28.0.

I've now pushed a follow-up commit to fix the regression, now applying nounwind on extern function as intended.

[rust-highfive]

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_time:end:2312b483:start=1542755280460092720,finish=1542755281902444787,duration=1442352067
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-5.0
---
[00:17:49]    Compiling rustc_codegen_ssa v0.0.0 (/checkout/src/librustc_codegen_ssa)
[00:18:03] error[E0061]: this function takes 2 parameters but 1 parameter was supplied
[00:18:03]    --> librustc_codegen_llvm/attributes.rs:199:5
[00:18:03]     |
[00:18:03] 64  |   fn unwind(val: &'ll Value, can_unwind: bool) {
[00:18:03]     |   -------------------------------------------- defined here
[00:18:03] ...
[00:18:03] 199 | /     unwind(if cx.tcx.sess.panic_strategy() != PanicStrategy::Unwind {
[00:18:03] 200 | |         // In panic=abort mode we assume nothing can unwind anywhere, so
[00:18:03] 201 | |         // optimize based on this!
[00:18:03] ...   |
[00:18:03] 228 | |         true
[00:18:03] 229 | |     });
[00:18:03]     | |______^ expected 2 parameters
---
145100 ./obj/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib
145096 ./obj/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu
145092 ./obj/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib
134664 ./obj/build/bootstrap/debug/incremental/bootstrap-zemjd6kcyh2u
134660 ./obj/build/bootstrap/debug/incremental/bootstrap-zemjd6kcyh2u/s-f6v028rh0j-1jh577i-2q1xp1m83q6vz
107888 ./obj/build/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends
104700 ./src/tools/lldb
93748 ./src/tools/clang/test
89976 ./src/llvm-emscripten/test/CodeGen

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[alexcrichton]

@bors: r=zackmdavis

[bors]

📌 Commit 1091eee has been approved by zackmdavis

[bors]

⌛️ Testing commit 1091eee with merge 5316104...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: zackmdavis
Pushing 5316104 to master...

[bors]

👀 Test was successful, but fast-forwarding failed: 422 Update is not a fast forward

[alexcrichton]

@bors: retry

[bors]

⌛️ Testing commit 1091eee with merge 2f35a10...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: zackmdavis
Pushing 2f35a10 to master...

[SimonSapin]

but this is currently simply switching rustc's internal default to abort-by-default

This sounds like the default is unchanged, and this PR doesn’t do anything without #[unwind]. But that’s not what the test case changes suggest. @alexcrichton Could you clarify the PR description, for the eventual release notes?

[alexcrichton]

Sure! @SimonSapin does this clear things up?

---

This was intended to land way back in 1.24, but it was backed out due to breakage which has long since been fixed. Prior to this PR a crate could panic and unwind past an extern fn boundary, but such behavior is UB. For example, this is undefined behavior:

extern fn foo() {
    panic!();
}

fn main() {
    foo();
}

This PR changes the behavior of generated code to be sound-by-default. If an extern fn is unwound (panicked through) then it immediately aborts the program. Put another way, no extern fn can unwind.

The implementation in this PR is pretty simple because an unstable #[unwind] attribute could already be used to tweak the unwinding behavior. As a result this PR basically just switches the default from #[unwind] to #[unwind(abort)] for all extern fn definitions.

[SimonSapin]

Yes this is better, thanks! I don’t know if this example is actually UB though. I though what was undefined was unwinding from Rust into a call stack of another language.

[alexcrichton]

You can explore the UB through the IR of a program like this:

#![crate_type = "lib"]      
                            
#[inline(never)]            
extern fn foo() {           
    panic!("x");            
}                           
                            
struct A;                   
                            
impl Drop for A {           
    fn drop(&mut self) {    
        extern { fn foo(); }
        unsafe { foo(); }   
    }                       
}                           
                            
pub fn bar() {              
    let _x = A;             
    foo();                  
}                           

The compiler places the nounwind LLVM attribute on the function foo, but it actually ends up unwinding. According to LLVM:

If the function does raise an exception, its runtime behavior is undefined

Note that recent compilers have a bug where they don't place nounwind (fixed in this PR), but 1.25.0 for example placed the nounwind attribute.

[SimonSapin]

Ok I see. I didn’t know about nounwind. Thanks!