The Solidity Contract-Oriented Programming Language - By chatting here you agree to the https://github.com/ethereum/solidity/blob/develop/CODE_OF_CONDUCT.md
Newbie question: Having problems with solc.compile - compile script reads all contracts in a /contracts folder. Can get the source and packages up a json object as part of the setup to the compile input. But alas...I keep getting the following error from compiler:
{"errors":[{"component":"general","formattedMessage":"Unknown key \"errors\"","message":"Unknown key \"errors\"","severity":"error","type":"JSONError"}]}
QUESTION: Currently the input is an object containing contract source in text...comma separated. Should each contract source be an object?
Thank you in advance. Ash
Did some tests on remix. I found that it costs less than 5k and more than 0 to write the same non-zero value to storage.
I also found that if you are modifying most of the values (ie, in a struct), it is cheaper to not check each value before writing the entire struct to storage, and if you are updating only some of the values it is cheaper to check before writing each struct value to storage.
Hi,
Under Solidity 0.5, I could write such contract:
interface I {
function f() external;
}
contract C {
function f() external { /* do something useful */ }
}
contract D is I, C {
}I.e. D would satisfy the interface I with C.
With Solidity 0.6 and above, I can no longer write this, because the compiler insists that I override f because it is inherited both from I and C, although there is only a single actual implementation of f (which is C.f).
Would it be possible for the compiler to allow the user to not override a function inherited multiple times when only one of
these functions has an implementation (i.e. has a body) ?
C.f really is a semantically correct implementation of I.f (it could be an unrelated function that just happens to have the same name). The only way to be sure that C.f and I.f are actually meant to be "the same" function, is for f to occur in a common base interface. So ideally, if you can be sure that C.f actually implements I.f, then C should either inherit from I or from a common base interface of C and I. If there is such a common base interface, then the compiler does allow the case in which there is only one unique implementation in the base classes without overriding.
Actually, @ekpyron, I have an additional question.
How come this one is fine :
interface I { function f() external; }
interface J is I { function f() external override; }
contract C is J { function f() external override {} }
contract D is I, C { }While this one is not ? (just swapping I and J in C and D's parents)
interface I { function f() external; }
interface J is I { function f() external override; }
contract C is I { function f() external override {} }
contract D is J, C { }More formally, it is not required to override a function.... The idea is that you traverse the inheritance graph backwards from the most derived contract and check if there is any ambiguity whatsoever (more detailed in the paragraph in the docs). In your example the main question is: why does J explicitly mention f? It would implicitly contain the f inherited from I even if it didn't mention it at all. So the reasoning is: since J mentions f explicitly, it is expected to impose some additional requirements on f beyond those of the f in I- and since C.f assures to implement I.f, but not J.f, you can't be sure that C.f satisfies the requirements of J.f. In the working example, this problem doesn't occur, since D inheriting from I just means it needs an I.f and since C indirectly implements I.f that requirement is clearly fulfilled. Does that make sense :-)?
Note that
interface I { function f() external; }
interface J is I { }
contract C is I { function f() external override {} }
contract D is J, C { }is practically the same as your second snippet, only that J doesn't explicitly mention f (indicating that it just needs a generic I.f and not some more specific version of f). So here it is again clear that C.f is a fine implementation of f in D, so this works without overriding.
Dear solidity team:
Wanted to raise a strange compiler error we are seeing in solc-0.7.5
This is specifically dedicated to the following snippet:
function simulateDelegatecallInternal(
address targetContract,
bytes memory calldataPayload
) public returns (bytes memory response) {
(bool success, response) = targetContract.delegatecall(
calldataPayload
);
}The issue seems to occur when the return variable name is specified and we want to define it inside of a tuple where the other variable has not yet been declared. Here this is bool success.
The error we see is "Expected identifier but got ')'"
This can be worked around by defining success as a bool beforhand as follows:
function simulateDelegatecallInternal(
address targetContract,
bytes memory calldataPayload
) public returns (bytes memory response) {
bool success;
(success, response) = targetContract.delegatecall(
calldataPayload
);
}but seems a bit unnecessary. Wondering if I should file this as a bug, but thought I'd reach out here first...
= is considered to be an absolute path inside the compiler's virtual file system
../ is considered bad practice exactly because it does not mix well with these remappings
myproject/library/x.sol you should import e.g. import myproject/otherCode/y.sol
solc =/path/m file.sol to do this when the empty remapping is allowed before. But it removed currently.
@adridadou For an array of atomic values, you can calculate the hash of an array value with:
keccak256(abi.encodePacked(array))For arrays of structs, you have to calculate the hashes of the struct elements first:
bytes32[] memory structHashes = new bytes32[](array.length);
for (uint256 i; i <array.length; i++){
structHashes[i] = hash(array[i]);
}where hash() computes the EIP712 struct hash of the array element. You then treat the hash array just like an atomic array:
keccak256(abi.encodePacked(structHashes))There are some examples of doing this in this contract