search

frangio / hardhat-exposed

Automatically expose internal Solidity functions for smart contract testing.
82 stars 13 forks source link

Generated contracts being marked as abstract when interface is fulfilled with a public member variable #2

Closed djriffel closed 3 years ago

djriffel commented 3 years ago

Hello,

I noticed that the generated contract code will prefix an XContract definition as abstract if one of the interface functions are fulfilled by a public member variable.

Example: 

interface IFoo {
    function memberField() external view returns (MyPublicMember);
}

contract Foo is IFoo{
    MyPublicMember public override memberField;
}

In the above code, the interface is fulfilled by the auto-generated getter function on the public field memberField, and so I can compile this and instantiate it using the non-generated code, but the XFoo generated code will be marked as an abstract contract, so it cannot be instantiated.

I found the functionality that is missing this logic to be in areFunctionsFullyImplemented() under core.ts/js

Also as a general follow-up question: Is this manual approach for determining the "abstract state" of a contract required? Would you not be able to key off of different attributes within the provided contract or contractMap parameters in that function? (ie: automatically mark any generated code from an interface, library or an abstract contract as an abstract XContract (or skip the code generation entirely), but then make all other generated code concrete), since the compiler would refuse to compile any non-abstract contracts in the base code if it isn't fully implemented anyways. Wondering about your thoughts on this.

frangio commented 3 years ago

Thanks for the report!

The issue with using the abstract state declared by the user is that if a contract is declared abstract by the user, but we can make the exposed contract concrete because it's fully implemented, we want to do that. For example, an Ownable contract can be declared abstract because it's not meant to be deployed on its own, but the tests will want to be able to deploy XOwnable as a concrete contract.

Fixed this in https://github.com/frangio/hardhat-exposed/commit/5a744907b22a499ae4c449e90eab89e8764b7fa4. Released in 0.1.9.