aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Sema/SemaInit.cpp
AgeCommit message (Collapse)AuthorFilesLines
2018-09-28Handle dependent class template names in class template argumentRichard Smith1-1/+4
deduction for new-expressions. llvm-svn: 343293
2018-09-26P1008R1 Classes with user-declared constructors are never aggregates inRichard Smith1-3/+32
C++20. llvm-svn: 343131
2018-09-10Enhance -Wc++14-compat for class template argument deduction to list theRichard Smith1-6/+11
deduced type (if known). llvm-svn: 341858
2018-09-07[Sema] Check that the destructor for each element of class type isAkira Hatanaka1-1/+78
accessible from the context where aggregate initialization occurs. rdar://problem/38168772 Differential Revision: https://reviews.llvm.org/D45898 llvm-svn: 341629
2018-08-30Add missing -Wc++11-compat / -Wc++14-compat warnings for:Richard Smith1-0/+4
* generic lambdas * return type deduction * class template argument deduction llvm-svn: 341098
2018-08-20Model type attributes as regular Attrs.Richard Smith1-1/+1
Specifically, AttributedType now tracks a regular attr::Kind rather than having its own parallel Kind enumeration, and AttributedTypeLoc now holds an Attr* instead of holding an ad-hoc collection of Attr fields. Differential Revision: https://reviews.llvm.org/D50526 This reinstates r339623, reverted in r339638, with a fix to not fail template instantiation if we instantiate a QualType with no associated type source information and we encounter an AttributedType. llvm-svn: 340215
2018-08-17Don't warn on returning the address of a label from a statement expressionReid Kleckner1-0/+4
Summary: There isn't anything inherently wrong with returning a label from a statement expression. In practice, the Linux kernel uses this pattern to materialize PCs. Fixes PR38569 Reviewers: niravd, rsmith, nickdesaulniers Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50805 llvm-svn: 340101
2018-08-14Revert r339623 "Model type attributes as regular Attrs."Reid Kleckner1-1/+1
This breaks compiling atlwin.h in Chromium. I'm sure the code is invalid in some way, but we put a lot of work into accepting it, and I'm sure rejecting it was not an intended consequence of this refactoring. :) llvm-svn: 339638
2018-08-13Model type attributes as regular Attrs.Richard Smith1-1/+1
Specifically, AttributedType now tracks a regular attr::Kind rather than having its own parallel Kind enumeration, and AttributedTypeLoc now holds an Attr* instead of holding an ad-hoc collection of Attr fields. Differential Revision: https://reviews.llvm.org/D50526 llvm-svn: 339623
2018-08-09Port getLocEnd -> getEndLocStephen Kelly1-31/+30
Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50351 llvm-svn: 339386
2018-08-09Port getLocStart -> getBeginLocStephen Kelly1-158/+140
Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
2018-08-02Work around more GCC miscompiles exposed by r338464.Martin Storsjo1-1/+5
This is the same fix as in r338478, for another occurrance of the same pattern from r338464. See gcc.gnu.org/PR86769 for details of the bug. llvm-svn: 338749
2018-08-01Avoid exposing name for range-based for '__range' variables in lifetime ↵Richard Smith1-3/+5
warnings. llvm-svn: 338467
2018-08-01[P0936R0] add [[clang::lifetimebound]] attributeRichard Smith1-74/+157
This patch adds support for a new attribute, [[clang::lifetimebound]], that indicates that the lifetime of a function result is related to one of the function arguments. When walking an initializer to make sure that the lifetime of the initial value is at least as long as the lifetime of the initialized object, we step through parameters (including the implicit object parameter of a non-static member function) that are marked with this attribute. There's nowhere to write an attribute on the implicit object parameter, so in lieu of that, it may be applied to a function type (where it appears immediately after the cv-qualifiers and ref-qualifier, which is as close to a declaration of the implicit object parameter as we have). I'm currently modeling this in the AST as the attribute appertaining to the function type. Differential Revision: https://reviews.llvm.org/D49922 llvm-svn: 338464
2018-07-30Remove trailing spaceFangrui Song1-29/+29
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-07-30PR38355 Prevent infinite recursion when checking initializer lifetime ifRichard Smith1-1/+2
an initializer is self-referential. llvm-svn: 338230
2018-07-27Add missing temporary materialization conversion on left-hand side of .Richard Smith1-10/+0
in some member function calls. Specifically, when calling a conversion function, we would fail to create the AST node representing materialization of the class object. llvm-svn: 338135
2018-07-26[Sema] Fix a crash by completing a type before using itErik Pilkington1-0/+1
Only apply this exception on a type that we're able to check. rdar://41903969 Differential revision: https://reviews.llvm.org/D49868 llvm-svn: 338089
2018-07-24Fix unused variable warnings; NFCGeorge Burgess IV1-2/+2
Looks like MTE was previously used for its SourceLoc, but we're now using a seperate SourceLocation here. llvm-svn: 337796
2018-07-24Warn if a local variable's initializer retains a pointer/reference to aRichard Smith1-73/+37
non-lifetime-extended temporary object. llvm-svn: 337790
2018-07-23Support lifetime-extension of conditional temporaries.Richard Smith1-8/+1
llvm-svn: 337767
2018-07-23Do not try to perform lifetime-extension through conditionalRichard Smith1-20/+39
expressions. CodeGen can't cope with that yet. Instead, produce a "not supported" warning for now and don't extend lifetime. llvm-svn: 337744
2018-07-23Fold -Wreturn-stack-address into general initialization lifetimeRichard Smith1-118/+318
checking. llvm-svn: 337743
2018-07-23Separate out the initialization kind for a statement expression resultRichard Smith1-1/+23
from that for a return value. No functionality change intended: I don't believe any of the diagnostics affected by this patch are reachable when initializing the result of statement expression. llvm-svn: 337728
2018-07-23Fold dangling-field warning into general initialization lifetime checks.Richard Smith1-85/+177
This reinstates r337627, reverted in r337671, with a fix to correctly handle the lvalueness of array subscript expressions on pointers. llvm-svn: 337726
2018-07-23Revert "Fold dangling-field warning into general initialization lifetime ↵Ilya Biryukov1-170/+82
checks." This reverts commit r337627. After the change, clang started producing invalid warning on the following code: struct foo { foo(char *x) : x_(&x[10]) {} private: char *x_; }; 1.cpp:2:21: warning: initializing pointer member 'x_' with the stack address of parameter 'x' [-Wdangling-field] llvm-svn: 337671
2018-07-20Fold dangling-field warning into general initialization lifetime checks.Richard Smith1-82/+170
llvm-svn: 337627
2018-07-17Restructure checking for, and warning on, lifetime extension.Richard Smith1-104/+266
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-17Temporarily revert r337226 "Restructure checking for, and warning on, ↵Florian Hahn1-266/+104
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-17Restructure checking for, and warning on, lifetime extension.Richard Smith1-104/+266
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-12[C++11] Fix warning when dropping cv-qualifiers when assigning to a ↵Nicolas Lesser1-16/+29
reference with a braced initializer list llvm-svn: 336922
2018-07-02Per C++ [over.match.copy]p1, direct-initialization of a reference canRichard Smith1-4/+6
only invoke converting constructors of the reference's underlying type. llvm-svn: 336153
2018-06-20Simplify. No behavior change.Nico Weber1-7/+1
llvm-svn: 335139
2018-06-19clang-cl: Emit narrowing diag for initializer lists if -fmsc-version is at ↵Nico Weber1-19/+23
least 1900 (i.e. MSVC2015). Diagnostics for narrowing conversions in initializer lists are currently DefaultIgnored in Microsoft mode. But MSVC 2015 did add warnings about narrowing conversions (C2397), so clang-cl can remove its special case code if MSCompatibilityVersion is new enough. (In MSVC, C2397 is just a warning and in clang it's default-mapped to an error, but it can be remapped, and disabled with -Wno-c++11-narrowing, so that should be fine.) Fixes PR37314. https://reviews.llvm.org/D48296 llvm-svn: 335082
2018-05-23Use zeroinitializer for (trailing zero portion of) large array initializersRichard Smith1-0/+3
more reliably. This re-commits r333044 with a fix for PR37560. llvm-svn: 333141
2018-05-23Revert r333044 "Use zeroinitializer for (trailing zero portion of) large ↵Hans Wennborg1-3/+0
array initializers" It caused asserts, see PR37560. > Use zeroinitializer for (trailing zero portion of) large array initializers > more reliably. > > Clang has two different ways it emits array constants (from InitListExprs and > from APValues), and both had some ability to emit zeroinitializer, but neither > was able to catch all cases where we could use zeroinitializer reliably. In > particular, emitting from an APValue would fail to notice if all the explicit > array elements happened to be zero. In addition, for large arrays where only an > initial portion has an explicit initializer, we would emit the complete > initializer (which could be huge) rather than emitting only the non-zero > portion. With this change, when the element would have a suffix of more than 8 > zero elements, we emit the array constant as a packed struct of its initial > portion followed by a zeroinitializer constant for the trailing zero portion. > > In passing, I found a bug where SemaInit would sometimes walk the entire array > when checking an initializer that only covers the first few elements; that's > fixed here to unblock testing of the rest. > > Differential Revision: https://reviews.llvm.org/D47166 llvm-svn: 333067
2018-05-23Use zeroinitializer for (trailing zero portion of) large array initializersRichard Smith1-0/+3
more reliably. Clang has two different ways it emits array constants (from InitListExprs and from APValues), and both had some ability to emit zeroinitializer, but neither was able to catch all cases where we could use zeroinitializer reliably. In particular, emitting from an APValue would fail to notice if all the explicit array elements happened to be zero. In addition, for large arrays where only an initial portion has an explicit initializer, we would emit the complete initializer (which could be huge) rather than emitting only the non-zero portion. With this change, when the element would have a suffix of more than 8 zero elements, we emit the array constant as a packed struct of its initial portion followed by a zeroinitializer constant for the trailing zero portion. In passing, I found a bug where SemaInit would sometimes walk the entire array when checking an initializer that only covers the first few elements; that's fixed here to unblock testing of the rest. Differential Revision: https://reviews.llvm.org/D47166 llvm-svn: 333044
2018-05-09Remove \brief commands from doxygen comments.Adrian Prantl1-23/+23
This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-01Implement P0482R2, support for char8_t type.Richard Smith1-5/+43
This is not yet part of any C++ working draft, and so is controlled by the flag -fchar8_t rather than a -std= flag. (The GCC implementation is controlled by a flag with the same name.) This implementation is experimental, and will be removed or revised substantially to match the proposal as it makes its way through the C++ committee. llvm-svn: 331244
2018-04-30PR37189 Fix incorrect end source location and spelling for a split '>>' token.Richard Smith1-1/+1
When a '>>' token is split into two '>' tokens (in C++11 onwards), or (as an extension) when we do the same for other tokens starting with a '>', we can't just use a location pointing to the first '>' as the location of the split token, because that would result in our miscomputing the length and spelling for the token. As a consequence, for example, a refactoring replacing 'A<X>' with something else would sometimes replace one character too many, and similarly diagnostics highlighting a template-id source range would highlight one character too many. Fix this by creating an expansion range covering the first character of the '>>' token, whose spelling is '>'. For this to work, we generalize the expansion range of a macro FileID to be either a token range (the common case) or a character range (used in this new case). llvm-svn: 331155
2018-04-06Fix typos in clangAlexander Kornienko1-1/+1
Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of: archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.) Differential revision: https://reviews.llvm.org/D44188 llvm-svn: 329399
2018-02-07PR36055: fix computation of *-dependence in nested initializer lists.Richard Smith1-12/+37
When we synthesize an implicit inner initializer list when analyzing an outer initializer list, we add it to the outer list immediately, and then fill in the inner list. This gives the outer list no chance to update its *-dependence bits with those of the completed inner list. To fix this, re-add the inner list to the outer list once it's completed. Note that we do not recompute the *-dependence bits from scratch when we complete an outer list; this would give the wrong result for the case where a designated initializer overwrites a dependent initializer with a non-dependent one. The resulting list in that case should still be dependent, even though all traces of the dependence were removed from the semantic form. llvm-svn: 324537
2018-01-17[Parse] Forward brace locations to TypeConstructExprVedant Kumar1-10/+10
When parsing C++ type construction expressions with list initialization, forward the locations of the braces to Sema. Without these locations, the code coverage pass crashes on the given test case, because the pass relies on getLocEnd() returning a valid location. Here is what this patch does in more detail: - Forwards init-list brace locations to Sema (ParseExprCXX), - Builds an InitializationKind with these locations (SemaExprCXX), and - Uses these locations for constructor initialization (SemaInit). The remaining changes fall out of introducing a new overload for creating direct-list InitializationKinds. Testing: check-clang, and a stage2 coverage-enabled build of clang with asserts enabled. Differential Revision: https://reviews.llvm.org/D41921 llvm-svn: 322729
2017-12-19Silence a bunch of implicit fallthrough warningsAdrian Prantl1-2/+2
llvm-svn: 321115
2017-12-04Now that C++17 is official (https://www.iso.org/standard/68564.html), start ↵Aaron Ballman1-9/+9
changing the C++1z terminology over to C++17. NFC intended, these are all mechanical changes. llvm-svn: 319688
2017-11-07[ObjC++] Don't warn about pessimizing move for __block variablesAlex Lorenz1-0/+4
rdar://33316951 llvm-svn: 317620
2017-10-03Suppress -Wmissing-braces warning when aggregate-initializing a struct with ↵Richard Smith1-1/+30
a single field that is itself an aggregate. In C++, such initialization of std::array<T, N> types is guaranteed to work by the standard, is completely idiomatic, and the "suggested" alternative from Clang was technically invalid. llvm-svn: 314838
2017-09-29[Sema] Suppress warnings for C's zero initializerDaniel Marjamaki1-2/+5
Patch by S. Gilles! Differential Revision: https://reviews.llvm.org/D28148 llvm-svn: 314499
2017-09-26Resolve a defect in C++17 copy omission.Richard Smith1-13/+74
When selecting constructors for initializing an object of type T from a single expression of class type U, also consider conversion functions of U that convert to T (rather than modeling such conversions as calling a conversion function and then calling a constructor). This approach is proposed as the resolution for the defect, and is also already implemented by GCC. llvm-svn: 314231
2017-09-07P0702R1: in class template argument deduction from a list of one element, ifRichard Smith1-0/+21
that element's type is (or is derived from) a specialization of the deduced template, skip the std::initializer_list special case. llvm-svn: 312703
generated by cgit v1.1 at 2025-10-13 22:57:21 +0000