Flag panic=abort is causing build script to fail

[dunnock]

Instruction to reproduce:

1. Clone https://github.com/servo/rust-cssparser
2. Run build RUSTFLAGS="-Cpanic=abort" cargo +nightly build --verbose

     Running `/Users/max/src/tari/rust-cssparser/target/debug/build/cssparser-53fdf5411b8667a8/build-script-build`
error: failed to run custom build command for `cssparser v0.27.2 (/Users/max/src/tari/rust-cssparser)`

Caused by:
  process didn't exit successfully: `/Users/max/src/tari/rust-cssparser/target/debug/build/cssparser-53fdf5411b8667a8/build-script-build` (signal: 6, SIGABRT: process abort signal)
  --- stdout
  cargo:rustc-cfg=rustc_has_pr45225
  cargo:rerun-if-changed=/Users/max/src/tari/rust-cssparser/src/tokenizer.rs

I'm submitting it here as it does not panicing nor failing without panic=abort flag, all compiles good.

This issue reproduces for me on nightly-2020-07-07 as well as latest rustc 1.49.0-nightly (dd7fc54eb 2020-10-15)

I initially thought that it is #70148 though realized it was already fixed long time ago and this issue reproduces with -Cpanic=abort.

I tried this code in Cargo.toml:

[dependencies]
cssparser = "=0.27.2"

I expected to see this happen: explanation
Successful compilation

Instead, this happened: explanation
Resulting in a build script to abort:

     Running `/Users/max/src/tari/rust-cssparser/target/debug/build/cssparser-53fdf5411b8667a8/build-script-build`
error: failed to run custom build command for `cssparser v0.27.2 (/Users/max/src/tari/rust-cssparser)`

Caused by:
  process didn't exit successfully: `/Users/max/src/tari/rust-cssparser/target/debug/build/cssparser-53fdf5411b8667a8/build-script-build` (signal: 6, SIGABRT: process abort signal)
  --- stdout
  cargo:rustc-cfg=rustc_has_pr45225
  cargo:rerun-if-changed=/Users/max/src/tari/rust-cssparser/src/tokenizer.rs

Meta

rustc --version --verbose:

❯ rustc +nightly --version --verbose
rustc 1.49.0-nightly (dd7fc54eb 2020-10-15)
binary: rustc
commit-hash: dd7fc54ebdca419ad9d3ab1e9f5ed14e770768ea
commit-date: 2020-10-15
host: x86_64-apple-darwin
release: 1.49.0-nightly
LLVM version: 11.0

Backtrace

there is no backtrace as it is compiled with -Cpanic=abort

[ehuss]

The machinery (proc-macros) used by syn are fundamentally incompatible with panic=abort. You must set the panic strategy via the Cargo profile. Unfortunately RUSTFLAGS are opaque to Cargo, so it has no knowledge of what you are trying to do. There are several issues for tracking giving more flexibility to setting flags (like rust-lang/cargo#6375). However, in this case, you should be using the profile, since Cargo needs to know about the panic strategy.

[ohsayan]

Although I'm not sure if this is specifically relevant to unwinding (without looking at the source), I'll still label it to be something related to RT

[dunnock]

Thank you @ehuss, let me explain purpose - I'm setting this flag for coverage reporting as it is adviced in grcov crate docs. I guess to workaround this issue if I got it right what you suggesting is to create temporary Cargo.toml with test profile having setting panic=abort. Will try that.

Just found a similar ticket #72609 . Should I close this one too in regards to the RUSTFLAGS tickets which you mentioned?

[dunnock]

Thank you @ehuss , specifying options via Cargo has worked! but I also used a cargo feature named-profiles.

For anyone facing similar issue a following extension to my workspace's Cargo.toml has helped:

cargo-features = ["named-profiles"]

[profile.coverage]
panic = "abort"
opt-level = 0
overflow-checks = false
incremental = false
codegen-units = 1
inherits = "test"

Then I am able to collect code coverage metrics with a following command:

export RUSTFLAGS="-Zprofile"
cargo test -p $pkg --lib --all-features --profile=coverage -Z unstable-options
# and collect coverage metrics respectively
grcov ./target/coverage/ -s . -t lcov --llvm --branch --ignore-not-existing --ignore "cli*" --ignore "*test*"  --ignore "target/*"  --ignore "*migrations*" --excl-start '#\[cfg\(test\)\]' --excl-stop '^}' -o $coverage_report

Closing this issue as I also outlined solution in grcov crate.