cargo clippy -p mint fails on master, and the assertions it flags are vacuous #27

New issue

Open

opened 2026-10-07 13:58:48 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-10-07 13:58:48 +01:00

Collaborator

cargo clippy -p mint --all-targets fails on master with six errors, and the assertions it objects to are vacuous — they cannot fail on any input, so they verify nothing.

Primary goals:

Clippy gate passes again — cargo clippy -p mint --all-targets exits 0 on master, so it can be used as a merge gate instead of being a known-red command.
Vacuous assertions replaced or removed — each assert! in the affected block either constrains something that could actually be violated, or goes away.

Current state and specifics

roles/mint/tests/sv2_connection_integration.rs asserts message-type constants against the bounds of their own type:

assert!(MESSAGE_TYPE_SETUP_CONNECTION >= COMMON_MSG_MIN);
assert!(MESSAGE_TYPE_SETUP_CONNECTION <= COMMON_MSG_MAX);
assert!(MINT_QUOTE_REQUEST >= MINT_MSG_MIN);
assert!(MINT_QUOTE_REQUEST <= MINT_MSG_MAX);

The constants are u8 and the bounds are that type's own minimum and maximum, so every one of these comparisons is always true. Clippy's absurd_extreme_comparisons is deny by default, so the run fails:

error: this comparison involving the minimum or maximum element for this type contains a case that is always true or always false
   = note: `#[deny(clippy::absurd_extreme_comparisons)]` on by default

Six errors in total. Reproduced on the current master tree; the file is byte-identical on master, on agent/epoch-mechanics, and at 922637e9, so this is not introduced by any open branch.

The deeper problem is the one clippy is pointing at rather than the lint itself. These assertions are of the shape allod/memory shell.md warns about under assertion traps: a check that cannot be shown to fail on sabotaged input does not count. Changing any of these message-type constants to a wrong-but-in-range value leaves every assertion in the block still passing, so the test gives the appearance of pinning the wire protocol's message-type ranges while pinning nothing. If the intent is to assert that each constant sits inside the range its own protocol subspace defines, the bounds need to be those subspace limits rather than the integer type's limits; if there is no such constraint worth testing, the assertions should go.

Scope

In scope: roles/mint/tests/sv2_connection_integration.rs — fix or remove the six flagged assertions, and check the rest of that file for others of the same shape that clippy does not flag because their bounds are not the type's extremes.

Out of scope: the two pre-existing translator_sv2 clippy warnings (wallet.rs:15 useless conversion, channel_manager.rs:900 fallible conversion), which are warnings rather than errors and are recorded nits on vnprc/hashpool#23.

Validation

cargo clippy -p mint --all-targets exits 0. Then sabotage one message-type constant to a wrong in-range value and confirm the retained assertions actually fail; if they still pass, they are still vacuous and the change is not done.

`cargo clippy -p mint --all-targets` fails on master with six errors, and the assertions it objects to are vacuous — they cannot fail on any input, so they verify nothing. Primary goals: - **Clippy gate passes again** — `cargo clippy -p mint --all-targets` exits 0 on master, so it can be used as a merge gate instead of being a known-red command. - **Vacuous assertions replaced or removed** — each `assert!` in the affected block either constrains something that could actually be violated, or goes away. ### Current state and specifics `roles/mint/tests/sv2_connection_integration.rs` asserts message-type constants against the bounds of their own type: ```rust assert!(MESSAGE_TYPE_SETUP_CONNECTION >= COMMON_MSG_MIN); assert!(MESSAGE_TYPE_SETUP_CONNECTION <= COMMON_MSG_MAX); assert!(MINT_QUOTE_REQUEST >= MINT_MSG_MIN); assert!(MINT_QUOTE_REQUEST <= MINT_MSG_MAX); ``` The constants are `u8` and the bounds are that type's own minimum and maximum, so every one of these comparisons is always true. Clippy's `absurd_extreme_comparisons` is `deny` by default, so the run fails: ``` error: this comparison involving the minimum or maximum element for this type contains a case that is always true or always false = note: `#[deny(clippy::absurd_extreme_comparisons)]` on by default ``` Six errors in total. Reproduced on the current master tree; the file is byte-identical on master, on `agent/epoch-mechanics`, and at `922637e9`, so this is not introduced by any open branch. The deeper problem is the one clippy is pointing at rather than the lint itself. These assertions are of the shape `allod/memory` `shell.md` warns about under assertion traps: a check that cannot be shown to fail on sabotaged input does not count. Changing any of these message-type constants to a wrong-but-in-range value leaves every assertion in the block still passing, so the test gives the appearance of pinning the wire protocol's message-type ranges while pinning nothing. If the intent is to assert that each constant sits inside the range its own protocol subspace defines, the bounds need to be those subspace limits rather than the integer type's limits; if there is no such constraint worth testing, the assertions should go. ### Scope In scope: `roles/mint/tests/sv2_connection_integration.rs` — fix or remove the six flagged assertions, and check the rest of that file for others of the same shape that clippy does not flag because their bounds are not the type's extremes. Out of scope: the two pre-existing `translator_sv2` clippy warnings (`wallet.rs:15` useless conversion, `channel_manager.rs:900` fallible conversion), which are warnings rather than errors and are recorded nits on vnprc/hashpool#23. ### Validation `cargo clippy -p mint --all-targets` exits 0. Then sabotage one message-type constant to a wrong in-range value and confirm the retained assertions actually fail; if they still pass, they are still vacuous and the change is not done.

vnprc-agent referenced this issue

2026-10-07 13:59:23 +01:00

mint epoch mechanics: height-named units, records, manual rotation lever #24