Сompiler can't remove panic locations if they are not used in panic handler

[StackOverflowExcept1on]

Code

Code is minimized as much as possible and here is a demo repository: https://github.com/StackOverflowExcept1on/rust-regression

• program - this is smart contract that panics and terminates with an error
• project - some intermediate directory that is generated by our utility

git clone https://github.com/StackOverflowExcept1on/rust-regression.git
cd rust-regression/project
./check.sh

/home/user/rust-regression/project
   Compiling rustversion v1.0.17
   Compiling arrayvec v0.7.6
   Compiling wasm-program v0.1.0 (/home/user/rust-regression/wasm-program)
   Compiling wasm-project v0.1.0 (/home/user/rust-regression/wasm-project)
    Finished `release` profile [optimized] target(s) in 0.59s
grep: ./target/wasm32-unknown-unknown/release/wasm_program.wasm: binary file matches
/home/user/... found in WASM :(

I expected to see this happen: /home/user/... removed from wasm

Instead, this happened: /home/user/... is not removed from wasm

We want /home/user/... to always be removed from smart contracts, otherwise it reveals some information about creator name and also increases cost of uploading to blockchain. We tried using --remap-path-prefix, but it results in longer build times. On the old version, rustc compiler was so smart that it figured out how to remove all panic locations from the binary file.

Maybe related to #115974, but I haven't checked every commit. Although it is worth noting that #115974 is very useful as we can get panic message and remove panic location in stable rust.

Version it worked on

It most recently worked on: nightly-2024-06-12

$ rustc +nightly-2024-06-12 --version --verbose
rustc 1.81.0-nightly (d0227c6a1 2024-06-11)
binary: rustc
commit-hash: d0227c6a19c2d6e8dceb87c7a2776dc2b10d2a04
commit-date: 2024-06-11
host: x86_64-unknown-linux-gnu
release: 1.81.0-nightly
LLVM version: 18.1.7

Version with regression

Starting from nightly-2024-06-13, behavior has changed

$ rustc +nightly-2024-06-13 --version --verbose
rustc 1.81.0-nightly (8337ba918 2024-06-12)
binary: rustc
commit-hash: 8337ba9189de188e2ed417018af2bf17a57d51ac
commit-date: 2024-06-12
host: x86_64-unknown-linux-gnu
release: 1.81.0-nightly
LLVM version: 18.1.7

[apiraino]

Related to #129080

[apiraino]

@StackOverflowExcept1on can you please elaborate about the longer build times you mention? Can you provide some numbers?

thanks

[StackOverflowExcept1on]

@apiraino we use the gear-wasm-builder utility to build our smart contracts. It is quite suboptimal because we have about 30-35 demo crates in the workspace, but only 1 crate can be built at a time. We had problem gear-tech/gear#2890, when the test build time increased from 45 sec to 9 minutes.

But we'd like to solve the problem described above, rather than using --remap-path-prefix. The compiler has been able to remove panic locations if they are not used in panic handler for last 2 years (I checked this on 2022 rustc). Now we have panic_info_message (since 1.81), but for some reason compiler can't strip panic locations.

[apiraino]

@StackOverflowExcept1on thanks for the reply.

I'm sorry to ask again, I still fail to see some data about increased build times. Do you have some CI logs? Some public code? A reproducible that shows a before and an after? Thanks again for your patience.

[bjorn3]

Does using cargo build -Zbuild-std=core,alloc -Zbuild-std-features=panic_immediate_abort --release --target wasm32-unknown-unknown work? panic_immediate_abort ensures that all panics are replaced with an aborting instruction, causing the panic handler to be skipped and panic locations to be omitted if you enable optimizations.

[StackOverflowExcept1on]

@bjorn3 it works, but it's not what we want. Previously, no build flags were needed, only the panic_info_message feature was needed.

[bjorn3]

--remap-path-prefix, panic_immediate_abort and -Zlocation-detail=none are the intended options to keep panic message paths out of the binary. If anything else worked, that it by accident and likely not something we will try to restore. Also can you provide more details on

We tried using --remap-path-prefix, but it results in longer build times.

? It shouldn't affect build times at all.