Skip to content

feat: add warnings and specifically unused variable warnings#246

Open
stringhandler wants to merge 1 commit intoBlockstreamResearch:masterfrom
stringhandler:feat/warnings
Open

feat: add warnings and specifically unused variable warnings#246
stringhandler wants to merge 1 commit intoBlockstreamResearch:masterfrom
stringhandler:feat/warnings

Conversation

@stringhandler
Copy link
Contributor

@stringhandler stringhandler commented Mar 18, 2026

This PR adds warnings, taken originally from #232, by themselves, without the extra clutter of infix operators.

However, I did want to add an unused variable warning.

A particularly dangerous case is where the developer uses an add_N jet, but doesn't do anything with the carry, allowing silent overflows.

fn main() {
    let a: u8 = 250;
    let b: u8 = 255;

    let (carry, sum) :(bool, u8) = jet::add_8(a,b);
    // carry is not used. This will generate a warning.
    assert!(jet::eq_8(sum, 200));

}

With this PR the warning is added:

warning: Variable `carry` is bound but never used. Prefix the variable name with `_` to silence this warning.     
 --> .\debug\unused_variable_warning.simf:5:6
  |
5 |     let (carry, sum) :(bool, u8) = jet::add_8(a,b);
  |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

warning: `.\debug\unused_variable_warning.simf` generated 1 warning
Program:
4jTYfQIQKE2H+CEChBhxqKNLQQgUH0mJsMgECwZtoIwCBNB+FggG4DhAHDg=
CMR:
9b79d61e50740f752cfaf42f5dbf95c918e6cba7c1d2d4de1a2b16a9fa00f6f7

I also added scripts to run all the examples to see if they still compile. If this bugs anyone, I'm happy to remove it.

@stringhandler stringhandler requested a review from delta1 as a code owner March 18, 2026 12:26
@stringhandler stringhandler changed the title add warnings and specifically unused variable warnings feat: add warnings and specifically unused variable warnings Mar 18, 2026
@apoelstra
Copy link
Contributor

utACK 7f35d30 -- but CI needs fixing.

This looks great! In a followup we will want to abstract out the color formatting stuff but it's fine for shell codes to be hardcoded for now. I also suspect that we could find a nicer way to thread warnings through the whole codebase than to have these tuples everywhere, but let's not let the perfect be the enemy of the good.

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