`trace!` code still present in the generated non-release binary. #386

New issue

Open

opened 2020-03-18 07:17:08 -05:00 by nbp · 1 comment

nbp commented

2020-03-18 07:17:08 -05:00

(Migrated from github.com)

When using max_level_debug feature, and compiling a non-release build, my expectation would be that trace! code is not present in the binary. As mentioned in the documentation:

Log levels can be statically disabled at compile time via Cargo features. Log invocations at disabled levels will be skipped and will not even be present in the resulting binary

However, the binary still contains some code which is not optimized away by the Rust compiler:

  33a8bb:       e8 70 bf ff ff          callq  336830 <_ZN76_$LT$log..Level$u20$as$u20$core..cmp..PartialOrd$LT$log..LevelFilter$GT$$GT$2le17hd9204c8739150144E

When using `max_level_debug` feature, and compiling a non-release build, my expectation would be that `trace!` code is not present in the binary. As mentioned in the documentation: > Log levels can be statically disabled at compile time via Cargo features. Log invocations at disabled levels will be skipped and will not even be present in the resulting binary However, the binary still contains some code which is not optimized away by the Rust compiler: ``` 33a8bb: e8 70 bf ff ff callq 336830 <_ZN76_$LT$log..Level$u20$as$u20$core..cmp..PartialOrd$LT$log..LevelFilter$GT$$GT$2le17hd9204c8739150144E ```

👀 2

KodrAus commented

2021-11-15 04:34:07 -06:00

(Migrated from github.com)

Interesting! Is this still the case today? I’m guessing that’s coming from these checks? https://github.com/rust-lang/log/blob/master/src/macros.rs#L34

I wonder if that’s got anything to do with the PartialOrd impl being non-const? It is #[inline] though.

Interesting! Is this still the case today? I’m guessing that’s coming from these checks? https://github.com/rust-lang/log/blob/master/src/macros.rs#L34 I wonder if that’s got anything to do with the `PartialOrd` impl being non-const? It is `#[inline]` though.