Enable generic type encoding via TypeResolver and remove dependency on scale-info
#19
Conversation
| uses: actions/checkout@v3 | ||
|
|
||
| - name: Diff READMEs | ||
| run: diff -q README.md scale-encode/README.md |
There was a problem hiding this comment.
dq: why do we need two readme's?
There was a problem hiding this comment.
The one in /scale-encode is the oen that is shown on crates.io for the crate, and the one at root is shown on github! This was the laziest way I could think of to make sure that they were kept in sync :)
There was a problem hiding this comment.
you could just link to root/github README in the Cargo.toml of the crate but fine :)
There was a problem hiding this comment.
Yep, probably a symlink would work here to avoid some extra CI minutes :D
There was a problem hiding this comment.
That might not work because if the readme is outside of the crate it won't be uploaded with it, but I'd have to try it!
There was a problem hiding this comment.
Git does handle symlinks ok (as long as the FS supports it) though by the sounds of it (eg https://stackoverflow.com/questions/954560/how-does-git-handle-symbolic-links) (I'd assumed that it wouldn't!), so we could just make one readme be a symlink to the other, but I'm not too bothered either way given the CI check :)
| @@ -17,8 +17,8 @@ | |||
|
|
|||
| /*! | |||
| `parity-scale-codec` provides an `Encode` trait which allows types to SCALE encode themselves based on their shape. | |||
There was a problem hiding this comment.
dq: Could we #[include_str(README.md)] here?
There was a problem hiding this comment.
We could; I think the only reason I don't do that is because the lib docs benefit from doc links ([Foo]) whereas in the README it's better to remove the []'s!
There's almost certainly a tool somewhere though which takes the lib docs and copies them into a README for you, stripping such links!
There was a problem hiding this comment.
It makes sense, the only crate I can think of might be: https://crates.io/crates/docify, something that substrate's been using for pallet docs
| type_id: &R::TypeId, | ||
| types: &R, | ||
| ) -> Result<Vec<u8>, Error> { | ||
| let mut out = Vec::new(); |
There was a problem hiding this comment.
Would it be beneficial at some point in the future to have a size_hint? To preallocate the memory, ensuring we allocate only once?
There was a problem hiding this comment.
If we could come up with a way that wasn't too complicated I'd be up for it :) Offhand I'm not sure how!
This replaces all uses of
scale-infowithscale_type_resolver::TypeResolverandscale_type_resolver::visitor's to handle resolving types in the various impls.