I'm in the process of refactoring AnalyzerOptions. The main motivation behind here is to emit warnings if an invalid -analyzer-config option is given from the command line, and be able to list them all.
In this patch, I'll implement the warning.
Differential D53280
[analyzer] Emit an error for invalid -analyzer-config inputs Szelethus on Oct 15 2018, 3:45 AM. Authored by
Details I'm in the process of refactoring AnalyzerOptions. The main motivation behind here is to emit warnings if an invalid -analyzer-config option is given from the command line, and be able to list them all. In this patch, I'll implement the warning.
Diff Detail
Event TimelineComment Actions @whisperity @xazax.hun A worry of mine is shared libraries, for example, we've got an array of Ericsson-specific checkers that we load run-time. Do we (or should we) support acquiring non-checker -analyzer-config options? Comment Actions I guess we should consider the idea in http://lists.llvm.org/pipermail/cfe-dev/2018-October/059864.html
Comment Actions I agree with NoQ. Forward and backward compatibility might be important for CodeChecker as well.
Or we could choose the deafults the other way around. What do you think? Does it make sense to have the compatibility mode on a per config bases or too much code for too little gain?
Comment Actions Since I've dug myself quite deep into the refactoring effort, I realized that there are more elegant ways of achieving this, should I hammer AnalyzerOptions for long enough. I'll probably change everything but the revision title. Comment Actions
Comment Actions Overall looks good to me, some minor comments inline.
Comment Actions Thanks! I'll commit around friday (with the requested fixes) to leave enough time for everyone to object.
Comment Actions Thanks, this looks great!
Comment Actions Thanks!
Comment Actions Ugh. We broke backwards compatibility when an invalid -analyzer-config is specified but -analyze isn't specified. Yes, people are accidentally relying on that :/ :/ :/ In this case the driver doesn't know that it needs to add analyzer-config-compatibility-mode=true (or, even better, outright ignore all analyzer options) but the frontend doesn't know that it doesn't need to parse them. Comment Actions Oh my god. Can you go a little more in depth? Was the problem something along the lines of treu typo, or a non-existent flag? Is that at all salvageable? I mean, losing the entire patch would be super bad imo. Also, I can't attend to this issue immediately -- replying on the phone is one thing, but almost any other action is out of my reach for the next couple days/weeks.
Comment Actions It's a flag that was removed but old soft doesn't know that it was removed, and it won't be fixed because it's old. I guess a typo would have caused the same problem. Not urgent, no pressure. Yes, i believe this patch is good and should stay there. At the same time, by the looks of it, coming up with a fix for this "problem" may be annoying.
Comment Actions We could just add the flag back, and do nothing with it. We have already mentioned converting some frontend flags to analyzer configs, and removing some long enabled-by-default options while still leaving them in the code in some form or another for backward compatibility, so some carefully documented litter in AnalyzerOptions here and there wouldn't be the end of the world. Edit: I just realized that this could easily be an issue for other users of the static analyzer (or clang in general) as well.
Comment Actions I guess the solution would be to check whether there are any user supplied flags with "analyze" substring, and add the compatibility flag then. It is possible if not probable that a non-static-analyzer related flag with a name like that will eventually be added, but I guess we can live with it. The deadline is around the creation of the 8.0.0. release branch, right? Comment Actions Yeah, that's pretty much the easiest solution that i see (i guess we need to look for -analyzer-config specifically), but it's still pretty gross.
I'd feel slightly more comfortable if some sort of fix gets in before the Christmas break. It doesn't sound appealing to bring back all the flags that we've removed recently, but i guess it's not that hard to track back all the options that we removed since, say, 6.0.0 and add them back, marked as "deprecated" somehow, and remove them later when either we have a solution for the general case or we don't care anymore :) Comment Actions
Sure! :) |
I wonder if it is a good idea to put the comment inside the macro.