[PATCH] D23385: Implement __has_constant_initializer(obj) expression traits.
Jonathan Roelofs via cfe-commits
cfe-commits at lists.llvm.org
Thu Aug 11 16:51:57 PDT 2016
jroelofs added inline comments.
================
Comment at: include/clang/Basic/DiagnosticSemaKinds.td:6807
@@ +6806,3 @@
+
+def err_has_constant_init_expression_trait_invalid_arg : Error<
+ "expression does not reference a named variable">;
----------------
EricWF wrote:
> Help improving this wording would be appreciated.
`"expression must be a named variable"`, maybe?
A "counterexample" to the original wording is `__has_constant_initializer(x+1)`.
================
Comment at: lib/Sema/SemaExprCXX.cpp:4775
@@ +4774,3 @@
+ // a 'constant initializer'.
+ else if ((VD->hasGlobalStorage() ||
+ VD->getTLSKind() != VarDecl::TLS_None) && VD->hasInit()) {
----------------
EricWF wrote:
> EricWF wrote:
> > jroelofs wrote:
> > > no else after return.
> > >
> > > Also, what do you want this to do for `ParmVarDecl`s that happen to have an initializer? i.e:
> > >
> > > ```
> > > void foo(int i = 45) {}
> > > ```
> > I believe that case should return false. `i` isn't static or thread local so it doesn't have a "constant initializer" according to [basic.start.static].
> >
> Perhaps using `__has_constant_initializer` should emit a diagnostic when used on non-static, non-thread-local objects?
//Maybe// a warning... And you might want it to behave differently when it comes from a macro expansion. I'm not sure what the norm is for that sort of thing though.
I think the more important thing at this point is to precisely document what you want the behavior to be in the docs. Then any difference from that spec is "just a compiler bug", rather than potentially being a breaking change in behavior for someone who used your API in a way that you didn't expect.
https://reviews.llvm.org/D23385
More information about the cfe-commits
mailing list