Is it working with MSVC on Windows?

[cg31]

Has anyone tried it with x86_64-pc-windows-msvc?

I tried it with both stable (1.37) and beta (1.38)-msvc with Visual Studio 2019, even an empty function will still generate the ERROR[no-panic] message.

[dtolnay]

It should work with msvc but I don't have a windows install to test it on. The crate relies on optimizations that happen in rustc even before it hits LLVM IR so there is nothing platform specific.

Are you building in release mode?

[cg31]

It indeed works in release build...

And, I just tried playing "opt-level = x", "opt-level = 2" works, but "opt-level = 1" (as you mentioned in readme) doesn't.

[asajeffrey]

I've been having problems in Windows too, for example https://travis-ci.com/asajeffrey/ipc-experiments/jobs/227536492

The matching Linux and MacOS builds pass the no-panic tests.

[asajeffrey]

BTW, this crate is great! I've been wanting static analysis for panic-freedom for ages!

[mchesser]

Here is a simple example that fails to compile on Windows but succeeds on Linux (both in debug and release builds):

some-lib/src/lib.rs:

pub struct SomeObject {}

impl SomeObject {
    pub fn new() -> SomeObject {
        SomeObject {}
    }

    #[no_panic::no_panic]
    fn test(&self) -> u8 {
        0
    }
}

some-bin/src/main.rs:

fn main() {
    some_lib::SomeObject::new();
}

The issue seems to be related to no-panic methods in external crates. I don't even need to call the method directly, any call to an un-inlined method on the object (in this case new) triggers the error.

Enabling any kind of LTO allows it to compile successfully on Windows.

[Lokathor]

I hit this same bug myself. lto=true also fixed it for me.

[dtolnay]

The readme now mentions that lto may be needed.