TableGen assertion mechanism

I have been thinking about an assertion feature, but it is difficult to figure out when assertions can be performed. Can you give me one or two specific examples of what you want to check?

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>. 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>.

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-'.";

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.

Oh, it's definitely nasty. But you could use it temporarily while I cook up a real assertion facility. I already had !substr() on my list.

Sounds good, thanks for the suggestion, Paul.

I think !substr and assertions are the only things I miss in TableGen.

Cheers,
Jan