Paul C. Anagnostopoulos via llvm-dev
2020-Dec-15 16:10 UTC
[llvm-dev] TableGen assertion mechanism
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>.
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>. >