[move-cm][closures] Refactor: Move type conversions out of Loader into a trait
#15669
+613
−503
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
⏱️ 50m total CI duration on this PR
|
16 tasks
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
This was referenced Jan 4, 2025
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
wrwg
force-pushed
the
wrwg/clos_ability_move
branch
from
34517a1 to
7862e77
Compare
wrwg
force-pushed
the
wrwg/clos_type_conv
branch
from
4972a5c to
2fed681
Compare
wrwg
force-pushed
the
wrwg/clos_ability_move
branch
from
7862e77 to
ee49138
Compare
wrwg
force-pushed
the
wrwg/clos_type_conv
branch
from
2fed681 to
9c0814c
Compare
wrwg
force-pushed
the
wrwg/clos_ability_move
branch
from
ee49138 to
9fbe74f
Compare
wrwg
force-pushed
the
wrwg/clos_type_conv
branch
from
9c0814c to
8b11451
Compare
…nto a trait Type conversions from runtime types to `MoveTypeLayout` and `TypeTag` currently are associated with the `Loader` type. However, they are needed for the `FunctionValueExtension` trait which needs to be constructed in contexts where no loader but only `ModuleStorage` exists. This PR moves the conversion functions into a new trait `TypeConverter`. The trait is then implemented two times based on `ModuleStorage` only and based on the existing `Loader`, for downwards compatibility.
wrwg
force-pushed
the
wrwg/clos_type_conv
branch
from
8b11451 to
dcb6bc5
Compare
wrwg
requested review from
georgemitenkov,
runtian-zhou,
vgao1996,
vineethk and
ziaptos
| } | ||
|
|
||
| /// Converts a runtime type to a type tag. | ||
| fn type_to_type_tag(&self, ty: &Type) -> PartialVMResult<TypeTag> { |
There was a problem hiding this comment.
FYI, I have a PR to move type tag conversion outside of loader as well...: #15676. We should probably sync changes for this one.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
[PR 3/n vm closures]
Type conversions from runtime types to
MoveTypeLayoutandTypeTagcurrently are associated with theLoadertype. However, they are needed for theFunctionValueExtensiontrait which needs to be constructed in contexts where no loader but onlyModuleStorageexists.This PR moves the conversion functions into a new trait
TypeConverter. The trait is then implemented two times, once based onModuleStorageonly and once based on the existingLoader, for downwards compatibility.How Has This Been Tested?
Refactoring only, existing tests
Type of Change
Which Components or Systems Does This Change Impact?