Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
I wonder how many of these options crash in no-asserts mode, and if it contradicts the purpose of -analyzer-config to avoid crashes when incompatible flags are passed.
I wonder how many of these options crash in no-asserts mode, and if it contradicts the purpose of -analyzer-config to avoid crashes when incompatible flags are passed.
Unless the analyzer has other bugs, it should not crash under any exploration order... A good stress-test would be even running all tests under all possible exploration orders.
I mean, say, you add a new exploration order, then an external tool tells clang to use the new order, then this tool is used in combination with an old clang that doesn't have the mode yet, then the mode remains unset, goes through llvm_unreachable, and what not.
@NoQ argh. I suppose we could print an error message and resort back to DFS? I do not think such an approach is good in any way, but if never-crashing is an absolute must here...
For now all other options are broken in a similar manner and nobody complained, just a thought.
@NoQ @dcoughlin I think I know what we should do: we should have different behavior depending on whether the analyzer is compiled with assertions, which is a very strong indicator that the user does want to have crashing error messages on bad options, as with other asserts.
If assertions are in, we should crash in such cases. Otherwise, do whatever is a sensible thing (e.g. switch to DFS).
I think this will also solve the problem of analyzer silently ignoring misspelled configuration options.