NagyDonat wrote: > Do you have asserts enabled in the benchmark?
Very good question :grin: but yes, we do have assertions enabled. > I think the trick for creating a test case for this is to figure out how to > have a `loc::ConcreteInt`. If you have one SVal like that, you can assign to > it to trigger the evalBind. Binding to a `loc::ConcreteInt` is irrelevant for this PR, because it is a `Loc`, which is on the "regular" branch where the changes of this PR are clearly NFC. (I would assume that we do have some LIT testcases that assign to `loc::ConcreteInt`.) Binding to `UnknownVal` is already tested by multiple LIT testcases, which all pass without changes when this PR is applied. (I inspected the code of upstream `check::Bind` checkers and based on that I'm confident that the behavior in this "bind to unknown" case won't change unless there is some downstream checker that introduces nontrivial non-sink transitions in a `check::Bind` that binds to unknown.) I don't know whether binding to `UndefinedVal` is possible (it does not appear in the LIT tests), but if it is possible, it would behave identically to the `UnknownVal` case. I _hope_ that binding to a `NonLoc` (e.g. `nonloc::ConcreteInt` or `nonloc::LocAsInteger`) never happens, because it is against common sense (and doesn't happen in the LIT test). I'm primarily running the benchmark to catch if there exists a corner case where the `Location` passed to `evalBind` is a `NonLoc`. https://github.com/llvm/llvm-project/pull/196313 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
