ffs
I was looking for the issue in other places
Or learn the verye elementary basics of js before you start working with it?
1 reply
Would be nice if instead of making mistakes, the person could anticipate an upcoming mistake and ask for directions before it happens.
2 replies
do you consider solc-js production?
I did anticipate the issue was "something about JS I didn't know about", and was looking for things in that direction, like async etc
was caught by surprise
axic: https://github.com/uuverifiers/eldarica
this Horn solver recently added the missing logics that the SMTChecker needs, so I'm trying it out on our test suite
this Horn solver recently added the missing logics that the SMTChecker needs, so I'm trying it out on our test suite
it doesn't have a c++ api, so I'm running it via the callback
Works quite nicely.
in some examples it performs better than Spacer
if we have something like this:
==== ExternalSource: _non_normalized_paths/a.sol ====
==== ExternalSource: _non_normalized_paths//b.sol ====
==== ExternalSource: C/////c.sol=_non_normalized_paths/c.sol ====
==== ExternalSource: C/../////D/d.sol=_non_normalized_paths///d.sol ====
import "_non_normalized_paths/a.sol";
import "_non_normalized_paths/b.sol";
import "C/c.sol";
import "D/d.sol”;
the imports only work, because i normalized them in
TestCaseReader
they need to be exactly as defined by the remapping, if we dont normalize
e.g.
==== ExternalSource: _non_normalized_paths/a.sol ====
==== ExternalSource: _non_normalized_paths//b.sol ====
==== ExternalSource: C/////c.sol=_non_normalized_paths/c.sol ====
==== ExternalSource: C/../////D/d.sol=_non_normalized_paths///d.sol ====
import "_non_normalized_paths/a.sol";
import "_non_normalized_paths//b.sol";
import "C/////c.sol";
import "C/../////D/d.sol";
but I’m not sure whether this is the behaviour we expected to have
For better or worse.
It might be different when I'm done with paths. But even then adding normalization would be a breaking change.
So we would only introduce it in 0.9.0 I think.
Yeah, it's a natural assumption in my opinion :) Part of the reason why I want to change it.
Basically, if you do
import "C/../////D/d.sol"; then the compiler expects to find exactly C/../////D/d.sol in its VFS.
So if you use Standard JSON, you have to use that name.
But if it's not in the VFS, the compiler will invoke the file loader.
But only for filesystem lookup.
Once it finds
Once it finds
D/d.sol on disk it will give the content to CompilerStack and CompilerStack will put it under C/../////D/d.sol, not D/d.sol.
Yeah, I would guess normalization.
I took a look but the output was a jumbled mess. I think it's easier to fix normalization first and only then try to figure it out. Maybe it will go away so you will not have to :)
✅ Nightly job t_ems_test_ext_colony succeeded on develop. Please see https://circleci.com/gh/ethereum/solidity/695454 for details.
❌ Nightly job t_ubu_ossfuzz failed on develop. Please see https://circleci.com/gh/ethereum/solidity/695459 for details.