Construct PortableRegistry dynamically at runtime

[ascjones]

Updates all type builders to allow construction of PortableForm types, and introduces the PortableRegistryBuilder to allow construction of a PortableRegistry dynamically. Currently this is only possible from an instance of the Registry which requires static type definitions.

The motivation for this is for solang to be able to generate metadata for ink! contracts, where static rust types are not available (since it is compiling Solidity contracts).

It is also generally useful to be able to dynamically define portable type hierarchies e.g. for post processing of statically generated metadata, or for testing.

Note: It is a goal that this should not be a breaking change and can be a minor release. So reviewers please look out for that.

[ascjones]

Modified this to allow constructing of PortableRegistry and temporarily made type fields public to allow direct construction with PortableForm. See use-ink/cargo-contract#659 (comment)

[xermicus]

Modified this to allow constructing of PortableRegistry and temporarily made type fields public to allow direct construction with PortableForm. See paritytech/cargo-contract#659 (comment)

Thanks! I couldn't get it to work (or figure a sane way to do so) neither with the static fn pointer. This looks promising now, I'll let you know!

[ascjones]

Note that this is not a required change, just a clippy suggestion since arrays implement IntoIter

[jsdw]

This is very silly/edge casey but it's possible for this to be a breaking change because the type checker doesn't know quite so much about what name could be any more. Stupid contrived example:

fn into_string(val: impl Into<String>) {}
fn concrete_string(val: String) {}

fn main() {
    let maybe_string = ['a','b','c'].into_iter().collect();
    // breaks if changed to into_string:
    concrete_string(maybe_string);
}

Is it worth caring about? quite possibly not!

[ascjones]

Possibly, but I have split this anyway into new (legacy for MetaForm) and added a new new_portable method as I have for other types here. c9149c2

[jsdw]

Looks good to me! Excited about the new PortableRegistryBuilder; I'm almos certain there will be places I can use that to simplify stuff.

As we chatted about, I think that while this technically could introduce breaking changes owing to loosening of types (and less type information for the compiler to work with), as you said the acid test will be whether it fails to compile on some crates that use this stuff heavily like substrate, scale-decode and whatever else. So I'd be happy with this being a minor bump if it doesn't cause any breakage on this set of crates known to use it a bunch (a mini crater run if you will).

[ascjones]

as you said the acid test will be whether it fails to compile on some crates that use this stuff heavily like substrate, scale-decode and whatever else. So I'd be happy with this being a minor bump if it doesn't cause any breakage on this set of crates known to use it a bunch (a mini crater run if you will).

Indeed, as part of the release prep for 2.3 I will definitely check that all these things compile with no changes.