aaron.ballman 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];
----------------
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.
https://reviews.llvm.org/D40625
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
