aaron.ballman added a reviewer: erichkeane.
aaron.ballman added inline comments.
================
Comment at: clang/include/clang/AST/Stmt.h:456
- class ArrayOrMatrixSubscriptExprBitfields {
+ class AMTSubscriptExprBitfields {
friend class ArraySubscriptExpr;
----------------
I am not certain what `AMT` stands for -- you might need some comments to
explain what this stands for.
================
Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:11827
+def err_wasm_builtin_arg_must_be_integer_type : Error <
+ "%ordinal0 argument must be an integer">;
} // end of sema component.
----------------
pmatos wrote:
> asb wrote:
> > aaron.ballman wrote:
> > > I'm a bit shocked by the number of new diagnostics for this type as it
> > > seems incredibly restrictive and like the rules are going to be hard to
> > > understand. For example, you cannot use this type in an exception
> > > specification despite that being a compile-time property. Can you use it
> > > within a conditional explicit clause (https://godbolt.org/z/sn3G8xE3T)?
> > > It must be static, but can it be thread local?
> > >
> > > Basically, it seems like this type is unlike basically any other type and
> > > we're going to have to carry a significant amount of extra code around to
> > > handle all the edge cases and those edge cases look a bit like
> > > whack-a-mole in practice.
> > The whack-a-mole aspect of disallowing table uses is something I'm not fond
> > of either....but I'm not sure I see a better approach. Do you have any
> > alternatives in mind?
> A couple concrete answers in addition to what @asb already said.
>
> * I don't think we can use tables at the moment in conditional explicit
> clause. Indeed it doesn't make sense since there's no what, at the moment, to
> statically initialize the table.
> * Tables are thread local. Indeed, threads in WebAssembly share only linear
> memory so anything that's not in linear memory is thread local. This is true
> for tables but also for all reference types.
> The whack-a-mole aspect of disallowing table uses is something I'm not fond
> of either....but I'm not sure I see a better approach. Do you have any
> alternatives in mind?
I don't have good ideas off the top of my head, but this is a lot of overhead
for the feature so my default idea is "don't add this type to the compiler"
which may not help all that much. Do you have evidence that this type is
necessary, will have enough uses in the wild to justify adding it, and is not
possible to make it more regular?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D139010/new/
https://reviews.llvm.org/D139010
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
