We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cairo version:
Tried at commit f030973
Current behavior: While trying to: assert(contract_address1.into() == contract_address2.into(), 'Some message');
assert(contract_address1.into() == contract_address2.into(), 'Some message');
Makes me crash into: thread 'main' panicked at 'Types should be fully resolved at this point.'
But if I do: assert(contract_address1.into() == contract_address_to_felt(contract_address1), 'Some message');
assert(contract_address1.into() == contract_address_to_felt(contract_address1), 'Some message');
It works, as the left side knows it should transform into the felt type to comply with the right side
Expected behavior:
It shouldn't complain and resolve a common type they both can agree on.
Other information:
Maybe ContractAddress should implement the PartialEq and Eq trait to not have to perform this operation. But still it should be fixed
The text was updated successfully, but these errors were encountered:
Fix trait function call reducing
14baf77
Move type reducing after trait resolving Solves #2171
9e4420e
Successfully merging a pull request may close this issue.
Bug Report
Cairo version:
Tried at commit f030973
Current behavior:
While trying to:
assert(contract_address1.into() == contract_address2.into(), 'Some message');
Makes me crash into:
thread 'main' panicked at 'Types should be fully resolved at this point.'
But if I do:
assert(contract_address1.into() == contract_address_to_felt(contract_address1), 'Some message');
It works, as the left side knows it should transform into the felt type to comply with the right side
Expected behavior:
It shouldn't complain and resolve a common type they both can agree on.
Other information:
Maybe ContractAddress should implement the PartialEq and Eq trait to not have to perform this operation.
But still it should be fixed
The text was updated successfully, but these errors were encountered: