Running cargo check --release is functionally equivalent to cargo check.

Minimal test case:

// src/main.rs

// Warn about unused stuff when in debug mode, fail compilation in release
#![cfg_attr(debug_assertions, warn(unused))]
#![cfg_attr(not(debug_assertions), deny(unused))]

fn main() {
    let unused = 0;
}

Results:

Reproduced on cargo 0.25.0 (96d8071da 2018-02-26) and cargo 1.26.0-nightly (d6c3983fe 2018-03-16).

I did a bit of digging, and I think I know why this is happening:

When running cargo check --release, the debug_assertions variable is still set to true instead of false, but when running cargo build --release, that flag is properly left disabled.

debug_assertions is defined within the Profile struct (manifest.rs), and an instance of Profile is retrieved during compilation:

As you can see above, when finding the correct Profile we essentially just get the default Profile instance defined for each action (assuming we're using a default Workspace struct, which most people are) - with the notable exception of CompileMode::Build: for that mode, we either return a Profile made for release-mode or the default Profile that has debug_assertions enabled. We don't do this for CompileMode::Check. So, assuming we just retrieve the default Profile...

The default profiles are defined as such:

Things to note: the release Profile actually just corresponds to cargo build --release; there isn't a definition for a check_release field. The function definitions are here:

And as you can see, the default Profile for CompileMode::Check is equivalent to the default development Profile, with debug_assertions enabled. There is no Profile for CompileMode::Check that is also for release mode.