[llvm-dev] TableGen assertion mechanism

[Jan Svoboda via llvm-dev]

Yes, I've been thinking about this mechanism.

Technically it works, but doesn't provide any context as to which definition and (multi-)class instantiation caused the assertion failure.
A proper assertion mechanism could be more helpful in this regard.

Anyways, assertions are not essential, but they could be helpful in certain situations.

> On Dec 15, 2020, at 5:10 PM, Paul C. Anagnostopoulos <paul at windfall.com> wrote:
> 
> TableGen does have an if/then/else statement. So for now you could use it, but the only sort of error message you could generate would be from a invalid statement:
> 
> def error;
> 
> multiclass MC<string flag> {
>  if !ne(flag, !subst("no-", "", flag)) then
>     def error {string message = "A flag name cannot begin with 'no-'.";}
>  def f # flag;
>  def fno_ # flag;
> }
> 
> which produces the nasty message:
> 
> test.td:5:6: error: def already exists: error
>     def error {string message = "A flag name cannot begin with 'no-'.";}
>     ^
> 
> Much better if you could write:
> 
>  assert !ne(!substr(flag, 0, 3), "no-"), "A flag name cannot begin with 'no-'.";
> 
> 
> At 12/15/2020 10:35 AM, Jan Svoboda wrote:
>> I'm currently working on the TableGen definitions of Clang command-line options.
>> 
>> One place where an assertion would be handy is the multiclass that generates the positive and negative flag from a base string, e.g.: "access-control" => "-faccess-control", "-fno-access-control". Users of the multiclass may get confused about the semantics and accidentally pass base string that already contains the "no-" prefix, resulting in incorrect flag names: "no-access-control" => "-fno-access-control", "-fno-no-access-control". This actually happens: <<https://reviews.llvm.org/D93104>https://reviews.llvm.org/D93104>. If we could do something like "assert !not(!strstartswith(name, "no-"));", we could prevent these types of bugs.
>> 
>> Another place this would be useful is in the BoolOptionBase multiclass (clang/include/clang/Driver/Options.td). The use-cases are decribed in TODOs.
>> 
>> I'm not sure how to implement something like this. So far, I've looked into the implementation of conditions, which might be a good starting point <<https://reviews.llvm.org/D71474>https://reviews.llvm.org/D71474>.
>