Commit Graph

9 Commits

Author SHA1 Message Date
Richard Smith afe48f9d68 Fold -Wreturn-stack-address into general initialization lifetime
checking.

llvm-svn: 337743
2018-07-23 21:21:22 +00:00
Richard Smith d87aab939a Restructure checking for, and warning on, lifetime extension.
This change implements C++ DR1696, which makes initialization of a
reference member of a class from a temporary object ill-formed. The
standard wording here is imprecise, but we interpret it as meaning that
any time a mem-initializer would result in lifetime extension, the
program is ill-formed.

This reinstates r337226, reverted in r337255, with a fix for the
InitializedEntity alignment problem that was breaking ARM buildbots.

llvm-svn: 337329
2018-07-17 22:24:09 +00:00
Florian Hahn 0aa117dd2c Temporarily revert r337226 "Restructure checking for, and warning on, lifetime extension."
This change breaks on ARM because pointers to clang::InitializedEntity are only
4 byte aligned and do not have 3 bits to store values. A possible solution
would be to change the fields in clang::InitializedEntity to enforce a bigger
alignment requirement.

The error message is

llvm/include/llvm/ADT/PointerIntPair.h:132:3: error: static_assert failed "PointerIntPair with integer size too large for pointer"
  static_assert(IntBits <= PtrTraits::NumLowBitsAvailable,
include/llvm/ADT/PointerIntPair.h:73:13: note: in instantiation of template class 'llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> >' requested here
    Value = Info::updateInt(Info::updatePointer(0, PtrVal),
llvm/include/llvm/ADT/PointerIntPair.h:51:5: note: in instantiation of member function 'llvm::PointerIntPair<const clang::InitializedEntity *, 3, (anonymous namespace)::LifetimeKind, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *>, llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> > >::setPointerAndInt' requested here
    setPointerAndInt(PtrVal, IntVal);
    ^
llvm/tools/clang/lib/Sema/SemaInit.cpp:6237:12: note: in instantiation of member function 'llvm::PointerIntPair<const clang::InitializedEntity *, 3, (anonymous namespace)::LifetimeKind, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *>, llvm::PointerIntPairInfo<const clang::InitializedEntity *, 3, llvm::PointerLikeTypeTraits<const clang::InitializedEntity *> > >::PointerIntPair' requested here
    return {Entity, LK_Extended};

Full log here:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-global-isel/builds/1330
http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/1394

llvm-svn: 337255
2018-07-17 09:23:31 +00:00
Richard Smith 0a9969b36b Restructure checking for, and warning on, lifetime extension.
This change implements C++ DR1696, which makes initialization of a
reference member of a class from a temporary object ill-formed. The
standard wording here is imprecise, but we interpret it as meaning that
any time a mem-initializer would result in lifetime extension, the
program is ill-formed.

llvm-svn: 337226
2018-07-17 00:11:41 +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
Reid Kleckner d60b82f93e Handle use of default member initializers before end of outermost class
Specifically, when we have this situation:
  struct A {
    template <typename T> struct B {
      int m1 = sizeof(A);
    };
    B<int> m2;
  };

We can't parse m1's initializer eagerly because we need A to be
complete.  Therefore we wait until the end of A's class scope to parse
it. However, we can trigger instantiation of B before the end of A,
which will attempt to instantiate the field decls eagerly, and it would
build a bad field decl instantiation that said it had an initializer but
actually lacked one.

Fixed by deferring instantiation of default member initializers until
they are needed during constructor analysis. This addresses a long
standing FIXME in the code.

Fixes PR19195.

Reviewed By: rsmith

Differential Revision: http://reviews.llvm.org/D5690

llvm-svn: 222192
2014-11-17 23:36:45 +00:00
Richard Smith e3b28bc363 Move detection of reference members binding to temporaries from building of
CXXCtorInitializers to the point where we perform the questionable lifetime
extension. This exposed a selection of false negatives in the warning.

llvm-svn: 183869
2013-06-12 21:51:50 +00:00
Andy Gibbs c6e68daac0 Prior to adding the new "expected-no-diagnostics" directive to VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive.
llvm-svn: 166280
2012-10-19 12:44:48 +00:00
Richard Smith d0e1c95dcc Implement [temp.param]p5: the top-level cv-qualifiers on a non-type template
parameter's declaration are ignored when determining the parameter's type.

llvm-svn: 152619
2012-03-13 07:21:50 +00:00