Szelethus added a comment. In https://reviews.llvm.org/D52984#1294258, @NoQ wrote:
> In https://reviews.llvm.org/D52984#1294233, @aaron.ballman wrote: > > > Personally, I think it's detrimental to the community for subprojects to > > come up with their own coding guidelines. My preference is for the static > > analyzer to come more in line with the rest of the project (over time, > > organically) in terms of style, terminology, diagnostic wording, etc. > > However, if the consensus is that we want a separate coding standard, I > > think it should be explicitly documented somewhere public and then > > maintained as part of the project. > > > I tihnk it's mostly conventions of using Analyzer-specific APIs, eg. avoid > `addTransition()` hell - i guess we already have that, or how to register > custom immutable maps, or how to implement checker dependencies or > inter-checker APIs, or how much do we want to split modeling and checking > into separate checkers, stuff like that. Indeed, I don't mean to change anything about the LLVM coding guideline, just add a couple Static Analyzer specific additional restrictions. https://reviews.llvm.org/D52984 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
