feat: `should_panic` should accept constant feilts in its `expected:` parameter

[Nenad Misić]

Feature Request

Describe the Feature Request

Passing a constant felt252 to should_panic > expected parameter should be valid syntax.

Currently the compiler complains with:

Plugin diagnostic: Expected panic must be of the form `expected: <tuple of felt252s and strings>` or
`expected: "some string"` or `expected: <some felt252>`.

Describe Preferred Solution

Passing a constant felt252 to should_panic > expected should compile.

Related Code

// this works as expected
#[test]
#[should_panic(expected: 'Some error')]
fn test_panic() {
     panic(array!['Some error']);
} 

// but this does not work
const ERR: felt252 = 'Some error';

#[test]
#[should_panic(expected: ERR)] // <- compiler error
fn test_panic() {
     panic(array![ERR]);
} 

Additional Context

This would very beneficial to have when writing tests for both regular Cairo code and for Starknet contracts, as the developer wouldn't be forced to hardcode error messages - they could define them in one place and then import and reuse them in tests.

If the feature request is approved, would you be willing to submit a PR?
(Help can be provided if you need assistance submitting a PR)

• Yes
• No

Don't know enough Rust yet.

[orizi]

I think we shouldn't support it - similarly to rust which does not support it - as it will become less and less types when additiona; patterns are added to it.

for contracts specifically since a safe-dispatcher can be used in testing - you can specifically compare the results and use whatever constants you wish to build the comparison.

[Nenad Misić]

@orizi should I close this then?

[orizi]

If you have nothing to add.

[Nenad Misić]

The only benefit would be as described in "additional context" section:

This would very beneficial to have when writing tests for both regular Cairo code and for Starknet contracts, as the developer wouldn't be forced to hardcode error messages - they could define them in one place and then import and reuse them in tests.

If this would cause some unrelated issues in the language, or if it goes against Cairo's philosophy, then I'd say this isn't a must-have.

for contracts specifically since a safe-dispatcher can be used in testing - you can specifically compare the results and use whatever constants you wish to build the comparison.

Can you just expand a little bit more on this? I didn't quite get what you were trying to say.

[orizi]

generally - semantic analysis during work of macros - is possible - but problematic - as macros are mostly to be run on the syntax - so it is at the very least philosophically problematic.

in most cases - panic! is not being called extremely internally - so there's probably a high level thing that fails, in the test level.
if you have a Result for example - you can just compare it to directly using asserts to Result::Err(array!['whatever-is-expected']).
in the cases of contracts - there's unstable feature of SafeDispatcher which returns Result of the starknet interface return value, instead of the basic interface return value, so you'd be able to check its value directly.