Change:
// PanicInfo with the `can_unwind` flag set to false forces an abort. let pi = PanicInfo::new( <del> fmt, </del> <ins> &fmt, </ins> Location::caller(), /* can_unwind */ false, force_no_backtrace,

Discussion:
Code is minimized as much as possible and here is a demo repository: - this is smart contract that panics and terminates with an error - some intermediate directory that is generated by our utility I expected to see this happen: removed from wasm Instead, this happened: is not removed from wasm We want 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 , 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 , but I haven't checked every commit. Although it is worth noting that is very useful as we can get panic message and remove panic location in stable rust. It most recently worked on: Starting from , behavior has changed
Related to
can you please elaborate about the longer build times you mention? Can you provide some numbers? thanks
we use the 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 , 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 . 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 (since 1.81), but for some reason compiler can't strip panic locations.
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.
Does using work? 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.
it works, but it's not what we want. Previously, no build flags were needed, only the feature was needed.
, and 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 ?

It shouldn't affect build times at all.
remapping was to the gear-wasm-builder utility here: I also want to show how to reproduce slow build with , but without minimal example.
It may be the case that RUSTFLAGS was forgotten to be set somewhere, causing unnecessary rebuilds that cause the total build time to be higher.
will be set whenever was passed to env. It's also worth noting that we're using and maybe this is some kind of flags caching bug? is used because it is global, unlike , and works with it.
Ok, I probably found the reason The thing is that passes by value instead of reference and it seems to lead to worse optimization when using , which also uses . Here is my fix. I'll put this in the PR and it would be nice to run some benchmarks on this patch.
modify labels: +regression-from-stable-to-beta -regression-untriaged
modify labels: -regression-from-stable-to-beta +regression-from-stable-to-stable (Actually from just stabilized nightly feature to stable)