summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaInit.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* PR24164, PR39336: init-captures are not distinct full-expressions.Richard Smith2018-10-191-0/+14
| | | | | | | | | Rather, they are subexpressions of the enclosing lambda-expression, and any temporaries in them are destroyed at the end of that full-expression, or when the corresponding lambda-expression is destroyed if they are lifetime-extended. llvm-svn: 344801
* Handle dependent class template names in class template argumentRichard Smith2018-09-281-1/+4
| | | | | | deduction for new-expressions. llvm-svn: 343293
* P1008R1 Classes with user-declared constructors are never aggregates inRichard Smith2018-09-261-3/+32
| | | | | | C++20. llvm-svn: 343131
* Enhance -Wc++14-compat for class template argument deduction to list theRichard Smith2018-09-101-6/+11
| | | | | | deduced type (if known). llvm-svn: 341858
* [Sema] Check that the destructor for each element of class type isAkira Hatanaka2018-09-071-1/+78
| | | | | | | | | | accessible from the context where aggregate initialization occurs. rdar://problem/38168772 Differential Revision: https://reviews.llvm.org/D45898 llvm-svn: 341629
* Add missing -Wc++11-compat / -Wc++14-compat warnings for:Richard Smith2018-08-301-0/+4
| | | | | | | | * generic lambdas * return type deduction * class template argument deduction llvm-svn: 341098
* Model type attributes as regular Attrs.Richard Smith2018-08-201-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
* Don't warn on returning the address of a label from a statement expressionReid Kleckner2018-08-171-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
* Revert r339623 "Model type attributes as regular Attrs."Reid Kleckner2018-08-141-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
* Model type attributes as regular Attrs.Richard Smith2018-08-131-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
* Port getLocEnd -> getEndLocStephen Kelly2018-08-091-31/+30
| | | | | | | | | | Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50351 llvm-svn: 339386
* Port getLocStart -> getBeginLocStephen Kelly2018-08-091-158/+140
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
* Work around more GCC miscompiles exposed by r338464.Martin Storsjo2018-08-021-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
* Avoid exposing name for range-based for '__range' variables in lifetime ↵Richard Smith2018-08-011-3/+5
| | | | | | warnings. llvm-svn: 338467
* [P0936R0] add [[clang::lifetimebound]] attributeRichard Smith2018-08-011-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
* Remove trailing spaceFangrui Song2018-07-301-29/+29
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* PR38355 Prevent infinite recursion when checking initializer lifetime ifRichard Smith2018-07-301-1/+2
| | | | | | an initializer is self-referential. llvm-svn: 338230
* Add missing temporary materialization conversion on left-hand side of .Richard Smith2018-07-271-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
* [Sema] Fix a crash by completing a type before using itErik Pilkington2018-07-261-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
* Fix unused variable warnings; NFCGeorge Burgess IV2018-07-241-2/+2
| | | | | | | Looks like MTE was previously used for its SourceLoc, but we're now using a seperate SourceLocation here. llvm-svn: 337796
* Warn if a local variable's initializer retains a pointer/reference to aRichard Smith2018-07-241-73/+37
| | | | | | non-lifetime-extended temporary object. llvm-svn: 337790
* Support lifetime-extension of conditional temporaries.Richard Smith2018-07-231-8/+1
| | | | llvm-svn: 337767
* Do not try to perform lifetime-extension through conditionalRichard Smith2018-07-231-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
* Fold -Wreturn-stack-address into general initialization lifetimeRichard Smith2018-07-231-118/+318
| | | | | | checking. llvm-svn: 337743
* Separate out the initialization kind for a statement expression resultRichard Smith2018-07-231-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
* Fold dangling-field warning into general initialization lifetime checks.Richard Smith2018-07-231-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
* Revert "Fold dangling-field warning into general initialization lifetime ↵Ilya Biryukov2018-07-231-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
* Fold dangling-field warning into general initialization lifetime checks.Richard Smith2018-07-201-82/+170
| | | | llvm-svn: 337627
* Restructure checking for, and warning on, lifetime extension.Richard Smith2018-07-171-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
* Temporarily revert r337226 "Restructure checking for, and warning on, ↵Florian Hahn2018-07-171-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
* Restructure checking for, and warning on, lifetime extension.Richard Smith2018-07-171-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
* [C++11] Fix warning when dropping cv-qualifiers when assigning to a ↵Nicolas Lesser2018-07-121-16/+29
| | | | | | reference with a braced initializer list llvm-svn: 336922
* Per C++ [over.match.copy]p1, direct-initialization of a reference canRichard Smith2018-07-021-4/+6
| | | | | | only invoke converting constructors of the reference's underlying type. llvm-svn: 336153
* Simplify. No behavior change.Nico Weber2018-06-201-7/+1
| | | | llvm-svn: 335139
* clang-cl: Emit narrowing diag for initializer lists if -fmsc-version is at ↵Nico Weber2018-06-191-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
* Use zeroinitializer for (trailing zero portion of) large array initializersRichard Smith2018-05-231-0/+3
| | | | | | | | more reliably. This re-commits r333044 with a fix for PR37560. llvm-svn: 333141
* Revert r333044 "Use zeroinitializer for (trailing zero portion of) large ↵Hans Wennborg2018-05-231-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
* Use zeroinitializer for (trailing zero portion of) large array initializersRichard Smith2018-05-231-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
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-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
* Implement P0482R2, support for char8_t type.Richard Smith2018-05-011-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
* PR37189 Fix incorrect end source location and spelling for a split '>>' token.Richard Smith2018-04-301-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
* Fix typos in clangAlexander Kornienko2018-04-061-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
* PR36055: fix computation of *-dependence in nested initializer lists.Richard Smith2018-02-071-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
* [Parse] Forward brace locations to TypeConstructExprVedant Kumar2018-01-171-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
* Silence a bunch of implicit fallthrough warningsAdrian Prantl2017-12-191-2/+2
| | | | llvm-svn: 321115
* Now that C++17 is official (https://www.iso.org/standard/68564.html), start ↵Aaron Ballman2017-12-041-9/+9
| | | | | | changing the C++1z terminology over to C++17. NFC intended, these are all mechanical changes. llvm-svn: 319688
* [ObjC++] Don't warn about pessimizing move for __block variablesAlex Lorenz2017-11-071-0/+4
| | | | | | rdar://33316951 llvm-svn: 317620
* Suppress -Wmissing-braces warning when aggregate-initializing a struct with ↵Richard Smith2017-10-031-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
* [Sema] Suppress warnings for C's zero initializerDaniel Marjamaki2017-09-291-2/+5
| | | | | | | | Patch by S. Gilles! Differential Revision: https://reviews.llvm.org/D28148 llvm-svn: 314499
* Resolve a defect in C++17 copy omission.Richard Smith2017-09-261-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
OpenPOWER on IntegriCloud