SRI-CSL / solidity

This is solc-verify, a modular verifier for Solidity.
https://github.com/SRI-CSL/solidity/blob/boogie/SOLC-VERIFY-README.md
GNU General Public License v3.0
50 stars 14 forks source link

[0.7] Only allowed integer magic identifier is 'now' #160

Closed hajduakos closed 4 years ago

hajduakos commented 4 years ago

specs/SumPushPop.sol gives

> Error while running compiler, details:
> Warning: This is a pre-release compiler version, please do not use it in production.
> 
> 
> ======= Converting to Boogie IVL =======
> 
> ======= test/solc-verify/specs/SumPushPop.sol =======
> solc-verify internal exception: 
> Details:
> /home/user/workspace/solidity/libsolidity/analysis/TypeChecker.cpp(3096): Throw in function virtual bool solidity::frontend::TypeChecker::visit(const solidity::frontend::Identifier&)
> Dynamic exception type: boost::exception_detail::clone_impl<solidity::langutil::InternalCompilerError>
> std::exception::what: 
> [solidity::util::tag_comment*] = 
> 
hajduakos commented 4 years ago

The problem here is the following: The type checker has a check whether an identifier that is a magic variable, is of type integer. If yes, it asserts that it has to be named "now" and then reports a deprecation error to use block.timestamp instead. So it seems like it is hardcoded that the only magic identifier of type int can be now. However, we also have __verifier_idx_int (see specs/SumPushPop.sol), which causes the assertion to fail. A quick solution would be to turn the assertion into a condition: if we have an identifier which is a magic variable and it is an integer, then instead of asserting, we check if it is now and if yes, report the deprecation. However, this would make a little modification in the type checker. A cleaner but more compex solution that I can imagine is to declare these __verifier_idx_XXX variables similarly to the quantified variables, i.e., create a "regular" declaration (instead of a magic variable) and add it to the scope of the specification expression every time. What do you think @dddejan?

dddejan commented 4 years ago

Simple solutions is probably best. We can figure out a better solution later.

hajduakos commented 4 years ago

Fixed it with the simple solution in a75b4a8226601480315a0ad462c8ffb9b7e83390