Use typed indices via a new wasm-types crate

[samestep]

Following up on some conversation in #1985, this draft PR is a start on what it might look like to use typed indices throughout the whole codebase. I was originally planning to finish this before coming back to #1985, but it eventually became clear to me that this is considerably bigger than I expected.

In any case, I'm opening this PR to gauge whether there's any interest in going further down this path, or if I should just call this an interesting experiment and abandon it. There were some unintuitive cases, so maybe there is some potential value in these from a codebase documentation/consistency perspective? For example:

wasm-tools/crates/wasm-encoder/src/reencode/component.rs

Lines 963 to 966 in beac7de

	wasmparser::CanonicalFunction::ThreadSpawn { func_ty_index } => {
	let func_ty = reencoder.type_index(func_ty_index);
	section.thread_spawn(func_ty);
	}

This code made me mark the func_ty_index field of the CanonicalFunction::ThreadSpawn variant as TypeIdx instead of ComponentTypeIdx, unlike all the fields in all the Resource variants. Is this correct? I don't know much about the component model, so maybe threads just happen to use core type indices while other similar-looking things use component type indices. Maybe it's clear from the spec (?), but it's not clear from the docstring:

wasm-tools/crates/wasmparser/src/readers/component/canonicals.rs

Lines 70 to 74 in beac7de

	/// A function which spawns a new thread by invoking the shared function.
	ThreadSpawn {
	/// The index of the function to spawn.
	func_ty_index: u32,
	},

Another random question I had while working on this: why do both wasm_encoder::NameSection::tag and wasm_encoder::NameSection::tags exist? Don't they do the same thing?

[alexcrichton]

Thanks again for your work on this! I wanted to give a heads up that I'm at least a bit swamped right now so it may take a bit before I get back to this, but it's in my inbox so I don't forget about it.

[gkgoat1]

Following up on some conversation in #1985, this draft PR is a start on what it might look like to use typed indices throughout the whole codebase. I was originally planning to finish this before coming back to #1985, but it eventually became clear to me that this is considerably bigger than I expected.

In any case, I'm opening this PR to gauge whether there's any interest in going further down this path, or if I should just call this an interesting experiment and abandon it. There were some unintuitive cases, so maybe there is some potential value in these from a codebase documentation/consistency perspective? For example:

wasm-tools/crates/wasm-encoder/src/reencode/component.rs

Lines 963 to 966 in beac7de

	wasmparser::CanonicalFunction::ThreadSpawn { func_ty_index } => {
	let func_ty = reencoder.type_index(func_ty_index);
	section.thread_spawn(func_ty);
	}

This could also extend outside the codebase; it would be useful for interoperability with walrus and waffle (both the original and my fork). A similar thing could also be done with Operator. +1, though I'm not in BA

This code made me mark the func_ty_index field of the CanonicalFunction::ThreadSpawn variant as TypeIdx instead of ComponentTypeIdx, unlike all the fields in all the Resource variants. Is this correct? I don't know much about the component model, so maybe threads just happen to use core type indices while other similar-looking things use component type indices. Maybe it's clear from the spec (?), but it's not clear from the docstring:

wasm-tools/crates/wasmparser/src/readers/component/canonicals.rs

Lines 70 to 74 in beac7de

	/// A function which spawns a new thread by invoking the shared function.
	ThreadSpawn {
	/// The index of the function to spawn.
	func_ty_index: u32,
	},

Another random question I had while working on this: why do both wasm_encoder::NameSection::tag and wasm_encoder::NameSection::tags exist? Don't they do the same thing?

[gkgoat1]

+1 again, I am developing a new WASM framework for storing and processing modules in-memory and this would help, again.