-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sorting modules by dependencies #549
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a few minor comments, but this looks like it will get the job done. That being said, I'm curious about the approach of assigning each module a number and then match
ing on the sorted module numbers? I have two minor concerns there.
First, I think the generated code might be quadratic in the number of modules (I'm not sure if rustc is smart enough to optimize a match on an integer into a jump). That's probably ok, since the number of modules should be small, but it's a little unexpected.
Second, the match
just feels a little bit ugly/hacky. Again that's not a blocker - sometimes you need a hack to make things work; but this seems like code smell to me.
I think we can solve both problems with a small tweak to the API. If we make sorted_modules a &mut Vec<&'a dyn Genesis>
, then we can just iterate over it directly instead of using the match
. That also means we'll need to change the signature of the other args to have a dyn Genesis
in place of T
. Or, equivalently, we can use a supertrait of ModuleInfo
and Genesis
so that we can pass around a single trait object.
Anyway, I'm curious if there's some drawback to that approach that I'm missing.
…pendencies # Conflicts: # module-system/sov-modules-api/src/lib.rs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks @LukaszRozmej
simplify test with mocking modules
Codecov Report
|
* Generating ModuleTrait.dependencies and implementing sort_by_dependencies * fix whitespace * Add ModuleInfo macro dependencies test * change sorting modules to have additional type * change genesis macro * add sorting modules tests * formatting * make Vec fully qualified in macros * split sort_modules_by_dependencies and sort_values_by_modules_dependencies * rename param * fix whitespace * refactor sort_modules_by_dependencies to use ModuleVisitor struct for mutable elements * fix whitespace * refactor * Add support for cyclic dependencies * Change sort_values_by_modules_dependencies from &Tvalue to TValue * remove & in genesic macro identyfiers * fix test * fix * fix test * move Hash trait implementation for addresses to macros * reverse cycle order in error message * I give up, make test order invariant * Try fixing test * simplify tests * improve cycle detection with stack simplify test with mocking modules * fix too much cloning * slim tests setup
Description
ModuleInfo
trait was expanded with thedependencies
function and returns the addresses of modules it depends on.derive_module_info
macro generatesdependencies
function for each module using#[module]
attribute.sort_by_dependencies
function allows to sortModuleInfo
by their dependencies. It takes modules and additional type tuples and returns sorted vector of this additional type. This done this way to easily map it back to compile time generated constants (see expandedderive_genesis
macro).derive_genesis
macro changed howfn genesis
was created. Now it creates aVec<ModuleTrait, usize>
that is sorted withsort_by_dependencies
and then theusize
are matched to correct modulegenesis
call.Side effect changes
AddressTrait
and all its implementations was expanded withHash
trait.ModuleInfo
is not subtrait ofDefault
, this wasn't required and made the trait not object safe.Example of expanded
derive_genesis
macro for demo-appLinked Issues
Genesis
cross-module dependencies. #428Testing
derive_module_info
macro andsort_by_dependencies
,derive_genesis
macro was already expanded in other tests.Docs