Closed djriffel closed 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.
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:
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/jsAlso 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
orcontractMap
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.