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