dcoughlin added inline comments.

================
Comment at: include/clang/Basic/Attr.td:602
 def AnalyzerNoReturn : InheritableAttr {
-  let Spellings = [GNU<"analyzer_noreturn">];
+  let Spellings = [Clang<"analyzer_noreturn">];
   let Documentation = [Undocumented];
----------------
aaron.ballman wrote:
> dcoughlin wrote:
> > aaron.ballman wrote:
> > > rsmith wrote:
> > > > Hmm, should the clang static analyzer reuse the `clang::` namespace, or 
> > > > should it get its own?
> > > Good question, I don't have strong opinions on the answer here, but 
> > > perhaps @dcoughlin does?
> > > 
> > > If we want to use a separate namespace for the analyzer, would we want to 
> > > use that same namespace for any clang-tidy specific attributes? Or should 
> > > clang-tidy get its own namespace? (Do we ever plan to execute clang-tidy 
> > > through the clang driver? That might change our answer.)
> > How would this look if we added a special namespace for the clang static 
> > analyzer? Would this lead to duplication (say, 
> > [[clang_analyzer::analyzer_noreturn]]) so that we keep the "analyzer_" 
> > prefix for __attribute__((analyzer_noreturn))? Or could we have the 
> > "analyzer_" prefix only for GNU-style attributes but not for C++ (for 
> > example, [[clang_analyzer::noreturn]])?
> > 
> > As for clang-tidy, I think it probably makes sense for it to have its own 
> > namespace, but we should ask @alexfh.
> > How would this look if we added a special namespace for the clang static 
> > analyzer? Would this lead to duplication (say, 
> > [[clang_analyzer::analyzer_noreturn]]) so that we keep the "analyzer_" 
> > prefix for attribute((analyzer_noreturn))? Or could we have the "analyzer_" 
> > prefix only for GNU-style attributes but not for C++ (for example, 
> > [[clang_analyzer::noreturn]])?
> 
> We have the ability to do whatever we'd like there. Given that the semantics 
> are so similar to `[[noreturn]]`, I think it would be reasonable to use 
> `[[clang_analyzer::noreturn]]` and `__attribute__((analyzer_noreturn))` if 
> that's the direction you think is best.
> 
> > As for clang-tidy, I think it probably makes sense for it to have its own 
> > namespace, but we should ask @alexfh.
> 
> I'm less enthusiastic about giving clang-tidy a vendor namespace that's 
> separate from the static analyzer, should the need arise. My biggest concern 
> there is that I would *really* like to see clang-tidy be more tightly 
> integrated with the clang driver (so users don't have to manually execute a 
> secondary tool). If that were to happen, then the user experience would be 
> that there are two vendor namespaces both related to analyzer attributes.
> 
> That said, I would also not be opposed to putting all of these attributes 
> under the `clang` vendor namespace and not having a separate vendor for the 
> analyzer or clang-tidy.
I would be find with keeping all of these things under the `clang` namespace, 
too.

That said, I do think there is some value in having a namespace for analyzer 
attributes separate from clang proper because the namespace would make it more 
clear that the attribute doesn't affect code generation.


https://reviews.llvm.org/D40625



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to