Skip to content
New issue

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

Moved storage size assert to TypeChecker from DeclarationTypeChecker #12186

Merged
merged 3 commits into from
Oct 27, 2021

Conversation

hrkrshnn
Copy link
Member

Replaces: #12163
Fixes: #12159

cameel
cameel previously approved these changes Oct 25, 2021
Changelog.md Outdated
@@ -20,6 +20,7 @@ Bugfixes:
* Commandline Interface: Disallow ``--error-recovery`` option outside of the compiler mode.
* SMTChecker: Fix internal error in magic type access (``block``, ``msg``, ``tx``).
* TypeChecker: Fix internal error when using user defined value types in public library functions.
* TypeChecker: Fix internal error when using arrays with user defined value types before declaration.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added this changelog.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it's not just arrays. I just found a new failing case (and it fails even with this fix):

struct S { U u; }
contract C { S s; }
type U is address;
Internal compiler error:
/solidity/libsolidity/ast/Types.cpp(2538): Throw in function const solidity::frontend::Type& solidity::frontend::UserDefinedValueType::underlyingType() const
Dynamic exception type: boost::wrapexcept<solidity::langutil::InternalCompilerError>
std::exception::what: Solidity assertion failed
[solidity::util::tag_comment*] = Solidity assertion failed

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will take a look now. Thanks for noticing!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bshastry Any idea why the fuzzer missed this?

Copy link
Member Author

@hrkrshnn hrkrshnn Oct 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This basically opened a bag of bugs. Basically any call to underlyingType() from DeclarationTypeChecker can be converted into an ICE. Will fix all of them.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wasn't as bad as I thought, other than canBeStored (from the struct example), only isValueType() will cause issues:

MyInt constant x;
type MyInt is int;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bshastry Any idea why the fuzzer missed this?

Because, the grammar-based generator does not do a second pass over type declarations i.e., forward references are not created.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hrkrshnn are the things you mention (canBeStored...) already in this PR? Could not find any changes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not yet, moving https://github.com/ethereum/solidity/blob/develop/libsolidity/analysis/DeclarationTypeChecker.cpp#L442 to TypeChecker created additional issues in other tests. Will keep this as draft for now.

@hrkrshnn hrkrshnn force-pushed the fix-userdefined-ice branch from 0f0d5ca to cbee4fc Compare October 25, 2021 15:55
@hrkrshnn hrkrshnn marked this pull request as draft October 25, 2021 19:02
This is to avoid a assert from failing for forward declared user defined value types.
And added a proper error message when constant types containing (nested) mapping types are used.
@hrkrshnn hrkrshnn force-pushed the fix-userdefined-ice branch from 06c87cf to 8815d6f Compare October 26, 2021 16:43
m_errorReporter.fatalDeclarationError(
3530_error,
_variable.location(),
"The type contains a (nested) mapping and therefore cannot be a constant."
Copy link
Member Author

@hrkrshnn hrkrshnn Oct 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See existing tests with this message. They were throwing, without this additional check.

@hrkrshnn hrkrshnn marked this pull request as ready for review October 26, 2021 16:45
@chriseth chriseth merged commit 9be882c into develop Oct 27, 2021
@chriseth chriseth deleted the fix-userdefined-ice branch October 27, 2021 14:12
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.

ICE in UserDefinedValueType::underlyingType() when the the type is used before it is declared
4 participants