[PATCH] D139010: [clang][WebAssembly] Implement support for table types and builtins

Paulo Matos via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 27 05:38:02 PDT 2023


pmatos marked an inline comment as done.
pmatos added inline comments.


================
Comment at: clang/test/Sema/wasm-refs-and-tables.c:17
+static __externref_t t6[] = {0}; // expected-error {{only zero-length WebAssembly tables are currently supported}}
+__externref_t t7[0];             // expected-error {{WebAssembly table must be static}}
+static __externref_t t8[0][0];   // expected-error {{multi-dimensional arrays of WebAssembly references are not allowed}}
----------------
aaron.ballman wrote:
> pmatos wrote:
> > aaron.ballman wrote:
> > > So why is `extern __externref_t r2;` allowed? Is it because it's not an array declaration?
> > I am not sure I understand the question. The externref value can be declared in another module and here we just define that. Array declarations of externref just define tables of externref values.
> Thanks, that helps explain my confusion (boy, I *really* do not like these types; they are quite unintuitive). What was confusing me here is that `__externref_t t7[0];` fails because the declaration doesn't declare a static identifier (yet, in C, it doesn't declare *anything at all* because it an array of zero elements of a sizeless type) while `extern __externref_t r2;` is fine despite not declaring a static identifier (yet, in C, it also doesn't declare *anything at all* because it's a sizeless type). I don't think there's anything to be done about this, the design is what it is in the WebAssembly standard, but all of my discomfort stems around how deeply weird this design is (and it shows with just how much effort we have to go to in order to restrict all the various ways you can use these identifiers).
Yes, I understand. 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D139010/new/

https://reviews.llvm.org/D139010



More information about the llvm-commits mailing list