Commit Graph

8 Commits

Author SHA1 Message Date
Richard Smith baf8130c47 PR20090: Add (passing) test from this bug; it's been fixed for a while.
llvm-svn: 291319
2017-01-07 00:52:10 +00:00
Richard Smith d6a150829b PR23135: Don't instantiate constexpr functions referenced in unevaluated operands where possible.
This implements something like the current direction of DR1581: we use a narrow
syntactic check to determine the set of places where a constant expression
could be evaluated, and only instantiate a constexpr function or variable if
it's referenced in one of those contexts, or is odr-used.

It's not yet clear whether this is the right set of syntactic locations; we
currently consider all contexts within templates that would result in odr-uses
after instantiation, and contexts within list-initialization (narrowing
conversions take another victim...), as requiring instantiation. We could in
principle restrict the former cases more (only const integral / reference
variable initializers, and contexts in which a constant expression is required,
perhaps). However, this is sufficient to allow us to accept libstdc++ code,
which relies on GCC's behavior (which appears to be somewhat similar to this
approach).

llvm-svn: 291318
2017-01-07 00:48:55 +00:00
Alp Toker b0869036c1 Tweak diagnostic wording for init list narrowing
The conventional form is '<action> to silence this warning'.

Also call the diagnostic an 'issue' rather than a 'message' because the latter
term is more widely used with reference to message expressions.

llvm-svn: 209052
2014-05-17 01:13:18 +00:00
Eli Friedman 4e28b26589 sizeof(void) etc. should be a hard error in C++.
PR16872.

llvm-svn: 188324
2013-08-13 22:26:42 +00:00
Richard Smith e10d304d20 PR11851 (and duplicates): Whenever a constexpr function is referenced,
instantiate it if it can be instantiated and implicitly define it if it can be
implicitly defined. This matches g++'s approach. Remove some cases from
SemaOverload which were marking functions as referenced when just planning how
overload resolution would proceed; such cases are not actually references.

llvm-svn: 167514
2012-11-07 01:14:25 +00:00
Richard Smith 35ecb36fcd Ensure that we instantiate static reference data members of class templates
early, since their values can be used in constant expressions in C++11. For
odr-use checking, the opposite change is required, since references are
odr-used whether or not they satisfy the requirements for appearing in a
constant expression.

llvm-svn: 151881
2012-03-02 04:14:40 +00:00
Richard Smith d3cf238e26 If a static data member of a class template which could be used in a constant
expression is referenced, defined, then referenced again, make sure we
instantiate it the second time it's referenced. This is the static data member
analogue of r150518.

llvm-svn: 150560
2012-02-15 02:42:50 +00:00
Richard Smith 4a941e25f2 If a constexpr function template specialization is referenced, and then the
template is defined, and then the specialization is referenced again, don't
forget to instantiate the template on the second reference. Use the source
location of the first reference as the point of instantiation, though.

llvm-svn: 150518
2012-02-14 22:25:15 +00:00