Skip to content

Conversation

@JoseSK999
Copy link
Contributor

What is the purpose of this pull request?

  • Bug fix
  • Documentation update
  • New feature
  • Test
  • Other: New macro bhash

Which crates are being modified?

  • floresta-chain
  • floresta-cli
  • floresta-common
  • floresta-compact-filters
  • floresta-electrum
  • floresta-watch-only
  • floresta-wire
  • floresta
  • florestad
  • Other: .

Description

I have created the bhash macro, short for block hash, that enforces a compile time check on the literal (must be 64 hex digits).

It uses the pattern const _: () = ...;, where the right side is evaluated at compile time. All the bhash!(literals) will be checked at compile time, even if they are not accessed at runtime (see https://doc.rust-lang.org/reference/items/constant-items.html#evaluation).

In other words, code that contains invalid literals won't compile (while currently it would compile and the program would panic at runtime only if the value is used). Also an IDE with cargo check lints will now display the error immediately.

Notes to the reviewers

You can verify that this works, you can try to mess with any hash values and then try to compile: it won't.

error[E0080]: evaluation of constant value failed
    --> crates/floresta-chain/src/pruned_utreexo/chain_state.rs:1495:13
     |
1495 | ...   bhash!("572ac401b94915dde6c4957b706abdb13b5824b000cad7f6065ebd9aea6dad1...
     |       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'Hash literal is not exactly 64 hex digits', crates/floresta-chain/src/pruned_utreexo/chain_state.rs:1495:13
     |
     = note: this error originates in the macro `$crate::panic::panic_2021` which comes from the expansion of the macro `bhash`

I have created the `bhash` macro, short for block hash, that enforces a compile time check on the literal (must be 64 hex digits).

It uses the pattern `const _: () = ...;`, where the right side is evaluated at compile time. All the `bhash!(literals)` will be checked at compile time, even if they are not accessed at runtime (see https://doc.rust-lang.org/reference/items/constant-items.html#evaluation).

In other words, code that contains invalid literals won't compile (while currently it would compile and the program would panic at runtime only if the value is used). Also an IDE with cargo check lints will now display the error immediately.
@JoseSK999
Copy link
Contributor Author

Another benefit is that it makes the hash parameters and test literals more concise, avoiding the .parse().unwrap() or BlockHash::from_str().unwrap()

@Davidson-Souza
Copy link
Member

This is pretty cool! Perhaps this approach can be useful for other stuff, like Stumps and Txid?

ack ac4fe53

@JoseSK999
Copy link
Contributor Author

Yes! It seems neat, I will be checking those as well

@Davidson-Souza Davidson-Souza merged commit c5a8f4e into vinteumorg:master Mar 10, 2025
8 checks passed
lucad70 pushed a commit to lucad70/Floresta that referenced this pull request Mar 11, 2025
I have created the `bhash` macro, short for block hash, that enforces a compile time check on the literal (must be 64 hex digits).

It uses the pattern `const _: () = ...;`, where the right side is evaluated at compile time. All the `bhash!(literals)` will be checked at compile time, even if they are not accessed at runtime (see https://doc.rust-lang.org/reference/items/constant-items.html#evaluation).

In other words, code that contains invalid literals won't compile (while currently it would compile and the program would panic at runtime only if the value is used). Also an IDE with cargo check lints will now display the error immediately.
@JoseSK999 JoseSK999 deleted the hash-literals-compile-check branch March 15, 2025 10:31
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 this pull request may close these issues.

2 participants