chore(corelib): drop internal #[panic_with] usages - #10095
Conversation
|
This change is |
This stack of pull requests is managed by Graphite. Learn more about stacking. |
PR SummaryMedium Risk Overview For arrays, For integers, attributes are dropped from Reviewed by Cursor Bugbot for commit 0335928. Bugbot is set up for automated code reviews on this repo. Configure here. |
eytan-starkware
left a comment
There was a problem hiding this comment.
@eytan-starkware reviewed 2 files and all commit messages, and made 1 comment.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on TomerStarkware).
TomerStarkware
left a comment
There was a problem hiding this comment.
@TomerStarkware reviewed 2 files and all commit messages, and made 1 comment.
Reviewable status:
30760d2 to
a25d6f4
Compare
ccf3121 to
063248d
Compare
a25d6f4 to
61f97b4
Compare
063248d to
6cbbfb3
Compare
`#[panic_with]` is deprecated. Remove its uses in corelib, which also drops the
panicking wrappers it generated (`array_at`, `u128_from_felt252`, `u128_sub`,
`u*_as_non_zero`, `u256_sub`, ...).
`Array`/`Span` indexing now calls `array_get(...).expect('Index out of bounds')`
and the index/at impls delegate to each other instead of the generated wrapper.
The integer helpers were internal and unused elsewhere, so they are simply
removed. No behavior change — panic messages are preserved.
61f97b4 to
4409061
Compare
6cbbfb3 to
0335928
Compare
Summary
Removes all
#[panic_with(...)]attribute usages fromarray.cairoandinteger.cairo, replacing the generated panic wrapper functions with explicitexpect(...)calls or direct delegation at the call sites.array_at(generated from#[panic_with('Index out of bounds', array_at)]onarray_get) is replaced witharray_get(...).expect('Index out of bounds').unbox()inArrayImpl::at, and call sites inArrayIndex,SpanImpl::at, andSpanIndexare updated to delegate throughArrayTrait::atorself.snapshot.at(index).u128_from_felt252,u128_sub,u128_as_non_zero,u8_from_felt252,u8_as_non_zero,u16_from_felt252,u16_as_non_zero,u32_from_felt252,u32_as_non_zero,u64_from_felt252,u64_as_non_zero,u256_sub,u256_as_non_zero) are removed by dropping their#[panic_with(...)]attributes from the corresponding_try_*functions.Type of change
Please check one:
Why is this change needed?
The
#[panic_with(...)]attribute generates a secondary function that panics onNone, but this pattern bypasses the standardOption/Resulthandling idioms and creates implicit, hard-to-trace panic paths. Removing these attributes and replacing usages with explicitexpect(...)calls makes the panic behavior visible at the call site and consistent with idiomatic Cairo error handling.What was the behavior or documentation before?
Functions like
array_get,u128_try_from_felt252,u128_checked_sub, etc. had#[panic_with(...)]attributes that auto-generated wrapper functions (e.g.,array_at,u128_from_felt252,u128_sub) which would panic with a fixed message if the underlyingOptionreturnedNone.What is the behavior or documentation after?
The generated wrapper functions are removed. Call sites that previously used them now use the
_try_*/_checked_*variants directly with explicit.expect(...)calls, or delegate through a single canonical implementation, making panic behavior explicit and traceable.Related issue or discussion (if any)
N/A
Additional context
This is a breaking change for any downstream code that directly calls the now-removed generated functions (e.g.,
array_at,u128_from_felt252,u128_sub,u256_sub,u*_as_non_zero). Callers should migrate to the corresponding_try_*or_checked_*variants with explicit error handling.