components: Expanded aliases should be deduplicated

[alexcrichton]

Currently this component:

(component
  (core module $m
    (global (export "f") i32 i32.const 0)
  )
  (core instance $m (instantiate $m))
  (core instance
    (export "a" (global $m "f"))
    (export "b" (global $m "f"))
  )
)

dumps as:

$ cargo run -q dump foo.wat
...
 0x32 | 03 0b       | core alias section
 0x34 | 02          | 2 count
 0x35 | 03 00 00 01 | core alias [global 0] InstanceExport { kind: Global, instance_index: 0, name: "f" }
      | 66
 0x3a | 03 00 00 01 | core alias [global 1] InstanceExport { kind: Global, instance_index: 0, name: "f" }
      | 66
...

This should ideally only create one core alias annotation instead of two, recognizing that the alias was already added.

[alexcrichton]

This is basically the same as https://github.com/bytecodealliance/wasm-tools/issues/598 except for aliases instead of types

[macovedj]

Was poking around and was wondering if it would make sense to create a list of aliases that have already been encountered when parsing that could be compared against when new ones are encountered, so as to prevent them from making it into the ast. Thought here could make sense in the binary_reader? Probably could do it with a smaller piece of data though.

[alexcrichton]

Thanks for the interest here! Sorry but to clarify though this issue has to do with the wast crate, not the wasmparser crate. This is specifically an issue in the text-to-binary translation rather than the binary parsing side of things.

This could be fixed via one of two general routes I think:

1. Currently alias expansion happens as part of name resolution. This could be updated to keep an internal map of seen aliases so that if an alias is expanded the map is looked up in first before injecting one to reuse prior ones.
2. Alternatively the alias expansion I think could move forward to crates/wast/src/component/expand.rs which happens before resolution since I don't think that this requires name resolution to be running.

Either way would have the same basic approach, it's just generally about where this happens.

[macovedj]

Cool, I'll try and check out trying one of those options when I get a chance.

[macovedj]

New draft PR exists. I went with the first approach that you referenced above @alexcrichton. I also don't get to work with rust all that often... so if there are obvious ways for me to be more idiomatic, would love to hear about it.