In working on bytecodealliance/wasm-tools#2335 I found that there's a
few test cases in wasm-tools which Wasmtime was panicking to compile.
The issues were all related to resource types and how information wasn't
registered ahead of time before it was translated from wasmparser's
representation to Wasmtime's representation. The high-level cause for
this had to do with how component and instance types are handled, as
opposed to concrete components or instances themselves. This was
effectively a hole in Wasmtime's translation process for components
which has never been filled out since the original implementation of
resources. The reason that this never came up before is:

* Most components don't currently import or export a component itself.
* Most components don't currently import or export component or instance
  types (as opposed to values).

One of these was required to trigger this issue. The solution
implemented in this commit is to plumb the concept of an "abstract
resource" which is part of a type but not actually ever used at runtime
except for type equality during type reflection. This is expected to
have little-to-no impact on real-world components given that these
situations are rarely occurring.

In working on bytecodealliance/wasm-tools#2335 I found that there's a
few test cases in wasm-tools which Wasmtime was panicking to compile.
The issues were all related to resource types and how information wasn't
registered ahead of time before it was translated from wasmparser's
representation to Wasmtime's representation. The high-level cause for
this had to do with how component and instance types are handled, as
opposed to concrete components or instances themselves. This was
effectively a hole in Wasmtime's translation process for components
which has never been filled out since the original implementation of
resources. The reason that this never came up before is:

* Most components don't currently import or export a component itself.
* Most components don't currently import or export component or instance
  types (as opposed to values).

One of these was required to trigger this issue. The solution
implemented in this commit is to plumb the concept of an "abstract
resource" which is part of a type but not actually ever used at runtime
except for type equality during type reflection. This is expected to
have little-to-no impact on real-world components given that these
situations are rarely occurring.

…11798)

In working on bytecodealliance/wasm-tools#2335 I found that there's a
few test cases in wasm-tools which Wasmtime was panicking to compile.
The issues were all related to resource types and how information wasn't
registered ahead of time before it was translated from wasmparser's
representation to Wasmtime's representation. The high-level cause for
this had to do with how component and instance types are handled, as
opposed to concrete components or instances themselves. This was
effectively a hole in Wasmtime's translation process for components
which has never been filled out since the original implementation of
resources. The reason that this never came up before is:

* Most components don't currently import or export a component itself.
* Most components don't currently import or export component or instance
  types (as opposed to values).

One of these was required to trigger this issue. The solution
implemented in this commit is to plumb the concept of an "abstract
resource" which is part of a type but not actually ever used at runtime
except for type equality during type reflection. This is expected to
have little-to-no impact on real-world components given that these
situations are rarely occurring.