Skip to content
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

Update to new scale-info and codec releases #663

Merged
merged 8 commits into from
Jan 28, 2021

Conversation

ascjones
Copy link
Collaborator

@ascjones ascjones commented Jan 28, 2021

@ascjones ascjones marked this pull request as ready for review January 28, 2021 11:53
@ascjones ascjones requested a review from Robbepop January 28, 2021 11:53
@@ -152,7 +152,7 @@ where
}

#[inline]
fn encode_to<O: scale::Output>(&self, output: &mut O) {
fn encode_to<O: scale::Output + ?Sized>(&self, output: &mut O) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice addition!

form::CompactForm,
IntoCompact as _,
form::{
FormString,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is a FormString bringing to the table?

crates/metadata/src/tests.rs Show resolved Hide resolved
@Robbepop
Copy link
Collaborator

All in all the PR LGTM, however I really wonder about some more recent design changes in the scale-info crate such as FormString and parameterizing PortableForm with a String type. Both of which do not really make a sense to me from an API design standpoint.

@codecov-io
Copy link

codecov-io commented Jan 28, 2021

Codecov Report

Merging #663 (c6e35ce) into master (a8707cc) will decrease coverage by 15.83%.
The diff coverage is 73.33%.

Impacted file tree graph

@@             Coverage Diff             @@
##           master     #663       +/-   ##
===========================================
- Coverage   82.89%   67.05%   -15.84%     
===========================================
  Files         161      161               
  Lines        7389     7389               
===========================================
- Hits         6125     4955     -1170     
- Misses       1264     2434     +1170     
Impacted Files Coverage Δ
crates/env/src/engine/off_chain/call_data.rs 23.52% <0.00%> (ø)
crates/metadata/src/layout/tests.rs 96.55% <ø> (ø)
crates/metadata/src/lib.rs 0.00% <0.00%> (ø)
crates/primitives/src/key.rs 65.82% <0.00%> (-16.46%) ⬇️
crates/storage/src/alloc/allocation.rs 82.14% <ø> (ø)
...tes/storage/src/collections/binary_heap/reverse.rs 22.22% <ø> (ø)
crates/storage/src/lazy/entry.rs 94.73% <ø> (ø)
crates/storage/src/pack.rs 100.00% <ø> (ø)
crates/metadata/src/specs.rs 72.72% <72.41%> (ø)
crates/metadata/src/layout/mod.rs 73.03% <85.00%> (+0.61%) ⬆️
... and 44 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a8707cc...c6e35ce. Read the comment docs.

@ascjones
Copy link
Collaborator Author

All in all the PR LGTM, however I really wonder about some more recent design changes in the scale-info crate such as FormString and parameterizing PortableForm with a String type. Both of which do not really make a sense to me from an API design standpoint.

See original rationale: paritytech/scale-info#35 (comment)

It's because substrate runtimes discourage use of String and to that end parity-scale-codec only support strings in std See https://github.com/paritytech/parity-scale-codec/blob/master/src/codec.rs#L357.

One idea I still need to investigate is the possibility of not storing the metadata in the runtime itself, but doing something similar to ink! where we generate the metadata up front using std. That would avoid the problem of having to support both & 'static str and String because we could just use std and String

@Robbepop Robbepop merged commit 6831813 into master Jan 28, 2021
@Robbepop Robbepop deleted the aj-update-scale-info-and-codec branch January 28, 2021 14:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants