Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
nbp opened this issue Mar 18, 2020 · 1 comment
Open

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

nbp opened this issue Mar 18, 2020 · 1 comment

Comments

@nbp
Copy link

nbp commented Mar 18, 2020

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
@KodrAus
Copy link
Contributor

KodrAus commented Nov 15, 2021

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.

EFanZh pushed a commit to EFanZh/log that referenced this issue Jul 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants