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

Disable debug_assertions won't ingore function calls in debug!(..) statements. #84

Closed
yangby-cryptape opened this issue Apr 16, 2024 · 9 comments · Fixed by #98
Closed

Comments

@yangby-cryptape
Copy link

Issue

I have the following code:

#[cfg(debug_assertions)]
use ckb_std::ckb_types::prelude::*;

debug!("script hash = {:#x}", script_hash.pack());

When set debug_assertions = false, the above could NOT be compiled.

Description

When users don't want to print the debug messages, all functions in debug!(..), such as script_hash.pack() in above code, should be ignored and they should never be executed.

ckb-std/src/debug.rs

Lines 38 to 44 in 6764555

($fmt:literal, $($args:expr),+) => {
#[cfg(debug_assertions)]
$crate::syscalls::debug(alloc::format!($fmt, $($args), +));
// Avoid unused warnings.
#[cfg(not(debug_assertions))]
core::mem::drop(($(&$args),+));
};

@XuJiandong
Copy link
Collaborator

It's due to the "Avoid unused warnings. ". Try this:

use ckb_std::ckb_types::prelude::*;
debug!("script hash = {:#x}", script_hash.pack());

@yangby-cryptape
Copy link
Author

It's due to the "Avoid unused warnings. ". Try this:

use ckb_std::ckb_types::prelude::*;
debug!("script hash = {:#x}", script_hash.pack());

Why execute functions (or cost cycles) when no log outputs are required?

I think it is a bug.

@blckngm
Copy link
Collaborator

blckngm commented Aug 8, 2024

It was to avoid a warning here in release build that tx_hash is not used: https://github.com/nervosnetwork/capsule/blob/a439682150afa2248fc53b1fa7990fb591ee4a07/templates/rust/contract/src/entry.rs#L31

Maybe you should fix the template instead. Then you don't need the drop.

@yangby-cryptape
Copy link
Author

yangby-cryptape commented Aug 11, 2024

Maybe you should fix the template instead. Then you don't need the drop.

Sorry, I didn’t get you.

Did you meaning I should remove the .pack()?

In fact, my final goal is disabling any function calls in the debug! macro.
Some type conversions (or data load) are only for debugging, they don't have to execute when in release mode.

They just waste cycles.


If you allowed, I could push a PR to remove the drop function.
And I promise there will be no warnings.

@quake
Copy link
Member

quake commented Aug 11, 2024

It's due to the "Avoid unused warnings. ". Try this:

use ckb_std::ckb_types::prelude::*;
debug!("script hash = {:#x}", script_hash.pack());

I think using drop in debug macro is wrong, for example, this code doesn't compiling:

    let tx_hash = load_tx_hash()?;
    debug!("tx hash is {:?}", tx_hash);
    let h0 = tx_hash[0]

@quake
Copy link
Member

quake commented Aug 12, 2024

resolved by #98

@blckngm
Copy link
Collaborator

blckngm commented Aug 12, 2024

I mean you should modify the template to maybe

debug!("tx hash is {:?}", load_tx_hash()?);

Or like what quake wrote which uses the tx_hash in let h0 = tx_hash[0]. So that there isn't an unused variable tx_hash when debug assertions are not enabled.

@quake
Copy link
Member

quake commented Aug 12, 2024

I mean you should modify the template to maybe

debug!("tx hash is {:?}", load_tx_hash()?);

Or like what quake wrote which uses the tx_hash in let h0 = tx_hash[0]. So that there isn't an unused variable tx_hash when debug assertions are not enabled.

I think that my code snippet doesn't compiling when debug assertions is disabled, we should remove the drop from macro.

@blckngm
Copy link
Collaborator

blckngm commented Aug 12, 2024

I think that my code snippet doesn't compiling when debug assertions is disabled, we should remove the drop from macro.

Yeah, I mean how to avoid the warning when the drop is removed.

@quake quake closed this as completed in #98 Aug 13, 2024
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

Successfully merging a pull request may close this issue.

4 participants