You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's quite unwieldy to inherit from a contract that makes a call to another contract, stemming from the fact that the parent contract isn't the entrypoint and thus doesn't implement TopLevelStorage when it is being inherited from.
I've managed to work around this by manually implementing CallContext (and StaticCallContext, in my case) for the parent contract, but this feels hacky and easy to misappropriate.
From what I gather, the TopLevelStorage trait is leveraged in this way to flush the storage cache in reentrant calls, but the inheritance situation I've laid out isn't really one of reentrancy...
I certainly lack some context on how the TopLevelStorage trait is implemented and intended to be leveraged, but this feels like it should be possible without enabling the reentrant flag
The text was updated successfully, but these errors were encountered:
This is something we intend to make nicer in an upcoming refactor, but right now this is possible if you use generics. We talk about it a bit in the Rust SDK Guide here, and here's an example contract that uses it. In summary, we can combine #[borrow] and TopLevelStorage to enable external calls in library code.
The reason for this is as follows: if you only have a mutable reference to substorage when making a call, you might alias other pieces of state if you call another contract (provided reentrancy is enabled, since that contract might call back into yours).
By restricting potentially reentrant calls to instances where you have a mutable reference to top level storage, Rust's type system will prevent you from patterns that alias storage. Library code needs to provide the same guarantee, for which we have SDK primitives like #[borrow] and Call::new_in() to make life easier. Hope this helps!
It's quite unwieldy to inherit from a contract that makes a call to another contract, stemming from the fact that the parent contract isn't the entrypoint and thus doesn't implement
TopLevelStorage
when it is being inherited from.I've managed to work around this by manually implementing
CallContext
(andStaticCallContext
, in my case) for the parent contract, but this feels hacky and easy to misappropriate.From what I gather, the
TopLevelStorage
trait is leveraged in this way to flush the storage cache in reentrant calls, but the inheritance situation I've laid out isn't really one of reentrancy...I certainly lack some context on how the
TopLevelStorage
trait is implemented and intended to be leveraged, but this feels like it should be possible without enabling thereentrant
flagThe text was updated successfully, but these errors were encountered: