feat(interface-types) Add the binary encoder

[Hywan]

This PR adds the encoders::binary module, which exposes the ToBytes trait. It is used to encode the AST into the WIT binary representation.

Check the tests to get examples, but quickly, the roundtrip works:

fn test_binary_encoding_decoding_roundtrip() {
    // Let `original_ast` be an AST representing a set of WIT interfaces
    let original_ast = Interfaces {
        exports: vec![Export {
            name: "ab",
            input_types: vec![InterfaceType::I32],
            output_types: vec![InterfaceType::I32],
        }],
        types: vec![Type::new(
            "ab",
            vec!["cd", "e"],
            vec![InterfaceType::I32, InterfaceType::I32],
        )],
        imports: vec![Import {
            namespace: "a",
            name: "b",
            input_types: vec![InterfaceType::I32],
            output_types: vec![InterfaceType::I64],
        }],
        adapters: vec![Adapter::Import {
            namespace: "a",
            name: "b",
            input_types: vec![InterfaceType::I32],
            output_types: vec![InterfaceType::I32],
            instructions: vec![Instruction::ArgumentGet { index: 1 }],
        }],
        forwards: vec![Forward { name: "a" }],
    };

    // Let's encode the AST into the WIT binary representation.
    let mut binary = vec![];

    original_ast
        .to_bytes(&mut binary)
        .expect("Failed to encode the AST.");

    // And let's go back to the AST land.
    let (remainder, ast) = parse::<()>(binary.as_slice()).expect("Failed to decode the AST.");

    assert!(remainder.is_empty());

    // They must equal.
    assert_eq!(original_ast, ast);
}

The implementation with the ToBytes trait and the io::Write trait is —I hope— Rust idiomatic. I reckon the code is easy to read and understand.

[MarkMcCaskey]

Looks good to me!

We could probably use something like serde here but 🤷‍♂ , I think it's fine!

[Hywan]

bors r+

[Hywan]

I'm not sure serde will be faster, but the implementation could be simpler, maybe. Not sure. It's one less dependency. As you said, 🤷‍♂.

[bors]

Build succeeded

• continuous-integration/travis-ci/push
• wasmerio.wasmer

[MarkMcCaskey]

I'm not sure serde will be faster, but the implementation could be simpler, maybe. Not sure. It's one less dependency. As you said, 🤷‍♂.

Yeah, I don't think it'll be faster and it'll certainly be more complex if we have to implement the serde traits ourselves (I've done this 2-3 times and it's always orders of magnitude more complex than I expect... which probably means that I'm rushing ahead to implement it without understanding it first...), I think serde helps with flexibility and convenience when derive works, but I agree for now it's unnecessary!