[PATCH] D36067: [analyzer] Create infrastructure for organizing and declaring analyzer configs.
teemperor abandoned this revision. teemperor added a comment. I see, thanks for the information! If we don't need to support this in the shell-completion and we shouldn't report invalid arguments, then it seems this review is stuck here. I'll abandon as I don't see any other use case for this code. (Also, sorry for the late response). https://reviews.llvm.org/D36067 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D36067: [analyzer] Create infrastructure for organizing and declaring analyzer configs.
dcoughlin added a comment. I just want to second that we really don't want to treat the analyzer-config options as user visible. These are useful as staging flags for analyzer development/testing and occasionally as customization points for IDEs/build systems. But they do not expose a coherent (or even intelligible) model to the end user. In particular, this means that we should never, ever ask (or recommend) that the end user set these from the command line. They are also not API -- we make no promises of backward compatibility. We also do sometimes use analyzer config flags as an escape hatch that lets us pass a flag to both a new clang (which understands the flag) and an old flag (which doesn't). It would be a shame if we lost that escape hatch. https://reviews.llvm.org/D36067 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D36067: [analyzer] Create infrastructure for organizing and declaring analyzer configs.
zaks.anna added a comment. >> I tried to keep this as a minimal starting example because this currently >> blocks @yamaguchi 's GSoC project for bash completion. There we want to >> complete the values for -analyzer-config and we currently don't have a good >> way to get a complete list of available configs from the driver :). It is not clear that we want to make the analyzer options user visible. These often used for staging purposes, where we develop a feature or a set of heuristics behind a flag. We do not support changing a lot of these options. https://reviews.llvm.org/D36067 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D36067: [analyzer] Create infrastructure for organizing and declaring analyzer configs.
teemperor added a comment. In https://reviews.llvm.org/D36067#825867, @xazax.hun wrote: > I like the directions of this patch. > In general, I am in favor of explicitly registering the options from user > defined checkers. > But changing a config option will now break the command line compatibility, > so I wonder how do we want to handle this: > > - Have a list of no-op configs that we accept but warn that it has been > replaced/removed? > - Just do not care and break compatibility? > - Something else? Don't have a preference here, but adding a forwarding config that also emits a warning should be easy to do. > I have a wishlist for this feature but I am perfectly fine to only address > those in follow-up patches: > > - Ability to set descriptions and maybe default values in the Checkers.td > - Command line argument to dump the list of options with descriptions (and > defaults) Yes, I would prefer having this in follow up patches. I tried to keep this as a minimal starting example because this currently blocks @yamaguchi 's GSoC project for bash completion. There we want to complete the values for `-analyzer-config` and we currently don't have a good way to get a complete list of available configs from the driver :). https://reviews.llvm.org/D36067 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D36067: [analyzer] Create infrastructure for organizing and declaring analyzer configs.
xazax.hun added a comment. I like the directions of this patch. In general, I am in favor of explicitly registering the options from user defined checkers. But changing a config option will now break the command line compatibility, so I wonder how do we want to handle this: - Have a list of no-op configs that we accept but warn that it has been replaced/removed? - Just do not care and break compatibility? - Something else? I have a wishlist for this feature but I am perfectly fine to only address those in follow-up patches: - Ability to set descriptions and maybe default values in the Checkers.td - Command line argument to dump the list of options with descriptions (and defaults) https://reviews.llvm.org/D36067 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
