Feature request: expose the Link Time Optimization profile settings to build scripts

[JSorngard]

Problem

It is not possible for build scripts to see whether the profile that is currently used enables LTO, or which level of it.

Proposed Solution

Make the value of the lto profile setting exposed to build scripts as an environment variable, along with the other ones: https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-build-scripts.

Notes

My reason for wanting this is that I use the no-panic crate to verify that a project of mine can't panic. In order to give some feedback if this test results in false positives I would like to be able to detect in a build script if the current profile enabled fat LTO.
EDIT: This is because no-panic can give false positives if LTO and optimizations are not enabled.

A related issue was recently closed: #11054.

Thanks for your time!

[epage]

What do you expect your build script to do with this information?

I'm assuming that generally, code shouldn't care about whether LTO isn't used anymore. This is a couple layers of workarounds

• Because a better way to enforce no-panic isn't provided, the no-panic crate exists
• Because of how the no-panic crate is implemented, it can't always see through some function calls and, if I'm understanding correctly, reports them as panicking. To see through these function calls, LTO is needed
• To check whether failures are false positives, I'm assuming some kind of LTO conditional compilation is needed

As this is the first issue opened after closing #11054, we haven't really setup a precedence for whether we should blanket provide this information or if the cases need enough justification. For the latter, I would question this and suggest we work to resolve one of the other layers of this. We have also had alternative names for profile fields added in the past and so by exposing a profile field, we'd be locking things in to a degree which we'd need to work out the specifics for.

[JSorngard]

Currently I use a workaround to read the profile name from the OUT_DIR variable, and emit a compile warning if the panic check is enabled, but the profile isn't the release-lto custom profile. The point is to tell the user that the errors they are getting are false positives and how those can be avoided.

I understand that some other solution to my proposal here might be preferred though.

I did some edits for clarity.