If I build normally (using cargo build), it succeeds. If I build passing RUSTFLAGS='-C link-dead-code', Rust attempts to monomorphize Foo::baz and fails despite Foo::baz never being used:
error[E0080]: evaluation of `<() as Foo>::baz::{constant#0}` failed
--> src/lib.rs:5:17
|
5 | const { panic!() }
| ^^^^^^^^ the evaluated program panicked at 'explicit panic', src/lib.rs:5:17
|
= note: this error originates in the macro `$crate::panic::panic_2021` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)
note: erroneous constant encountered
--> src/lib.rs:5:9
|
5 | const { panic!() }
| ^^^^^^^^^^^^^^^^^^
note: the above error was encountered while instantiating `fn <() as Foo>::baz`
Post-monomorphization errors (PMEs) are often used to detect error conditions at compile time that cannot be encoded in the type system proper. We do this in zerocopy 0.8 in certain APIs to ban dynamically-sized types whose trailing element type is zero-sized.
cargo fuzz builds using -C link-dead-code, and so it has been causing build failures for our users. In our specific case, it's possible to work around this because (for entirely coincidental reasons) the issue is only triggered by deprecated APIs that we can likely just remove. However, it's only luck that this hasn't caused more serious breakage for us.
I'm not sure what the right thing to do here is. From our perspective, having -C link-dead-code be more permissive would be good, but I understand why that might not be desirable for other users.
122301 might be of interest here. Basically: by introducing a generic you can delay the instantiation of the const until it's used with some concrete T. This isn't a guaranteed language property yet but it seems like opinions are leaning towards that way.
I have the following code:
If I build normally (using
cargo build
), it succeeds. If I build passingRUSTFLAGS='-C link-dead-code'
, Rust attempts to monomorphizeFoo::baz
and fails despiteFoo::baz
never being used:Post-monomorphization errors (PMEs) are often used to detect error conditions at compile time that cannot be encoded in the type system proper. We do this in zerocopy 0.8 in certain APIs to ban dynamically-sized types whose trailing element type is zero-sized.
cargo fuzz
builds using-C link-dead-code
, and so it has been causing build failures for our users. In our specific case, it's possible to work around this because (for entirely coincidental reasons) the issue is only triggered by deprecated APIs that we can likely just remove. However, it's only luck that this hasn't caused more serious breakage for us.I'm not sure what the right thing to do here is. From our perspective, having
-C link-dead-code
be more permissive would be good, but I understand why that might not be desirable for other users.Miscellaneous
Cargo version 1.81.0.