//! What `build.rs` records about the build for a measurement report
//! (`extensions/energy-measurement.md` §5, §8). This file is compiled twice:
//! into the crate, and into `build.rs` through `#[path]`, so the mapping the
//! build applies is the one the crate's tests check. It uses nothing but
//! `core`.

/// The build-profile label for cargo's `OPT_LEVEL`: `release` for an optimised
/// build — `opt-level` 2 or 3, or the size levels `s` and `z`, which is how a
/// WebAssembly build ships — and `debug` for `opt-level` 0 or 1, or a level cargo
/// did not report. Cargo's `PROFILE` is not read: the label is decided by the
/// optimisation the code was built with, whatever the profile is named, so a dev
/// profile turned up to an optimising level is `release` and a release profile
/// turned down to 0 or 1 is `debug`. Nor is it a statement about debug
/// assertions: an optimised build with assertions on is still `release`.
pub fn profile_label(opt_level: &str) -> &'static str {
    match opt_level {
        "2" | "3" | "s" | "z" => "release",
        _ => "debug",
    }
}

#[cfg(test)]
mod tests {
    use super::profile_label;

    #[test]
    fn release_means_an_optimised_build() {
        for level in ["2", "3", "s", "z"] {
            assert_eq!(profile_label(level), "release", "opt-level {level} is optimised");
        }
        for level in ["0", "1", "", "4", "S"] {
            assert_eq!(profile_label(level), "debug", "opt-level {level:?} is not an optimised level cargo reports");
        }
    }
}
