summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaInit.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Merging r347261:Tom Stellard2018-11-281-1/+4
| | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------------------ r347261 | vedantk | 2018-11-19 12:10:21 -0800 (Mon, 19 Nov 2018) | 11 lines [Sema] Fix PR38987: keep end location of a direct initializer list If PerformConstructorInitialization of a direct initializer list constructor is called while instantiating a template, it has brace locations in its BraceLoc arguments but not in the Kind argument. This reverts the hunk https://reviews.llvm.org/D41921#inline-468844. Patch by Orivej Desh! Differential Revision: https://reviews.llvm.org/D53231 ------------------------------------------------------------------------ llvm-svn: 347797
* Merging r340101:Reid Kleckner2018-08-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------------------ r340101 | rnk | 2018-08-17 15:11:31 -0700 (Fri, 17 Aug 2018) | 14 lines Don't warn on returning the address of a label from a statement expression 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: 340103
* Merging r338749:Hans Wennborg2018-08-031-1/+5
| | | | | | | | | | | | | | | ------------------------------------------------------------------------ r338749 | mstorsjo | 2018-08-02 20:12:08 +0200 (Thu, 02 Aug 2018) | 6 lines Work around more GCC miscompiles exposed by r338464. 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: 338845
* 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
* P0702R1: in class template argument deduction from a list of one element, ifRichard Smith2017-09-071-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
* Fix PR 10758: Infinite recursion when dealing with copy-initializationAlex Lorenz2017-05-161-0/+38
| | | | | | | | | | | | | | | | | | This commit fixes a bug that's tracked by PR 10758 and duplicates like PR 30343. The bug causes clang to crash with a stack overflow while recursing infinitely trying to perform copy-initialization on a type without a copy constructor but with a constructor that accepts another type that can be constructed using the original type. The commit fixes this bug by detecting the recursive behavior and failing correctly with an appropriate error message. It also tries to provide a meaningful diagnostic note about the constructor which leads to this behavior. rdar://28483944 Differential Revision: https://reviews.llvm.org/D25051 llvm-svn: 303156
* [OpenCL] Handle OpenCL specific subelement typesEgor Churaev2017-05-101-1/+1
| | | | | | | | | | | | Reviewers: Anastasia, cfe-commits Reviewed By: Anastasia Subscribers: bader, yaxunl Differential Revision: https://reviews.llvm.org/D32898 llvm-svn: 302633
* PR32280: Do not crash on nested initializers.Vassil Vassilev2017-04-141-8/+10
| | | | | | Patch by Yuka Takahashi (D31591)! llvm-svn: 300313
* Fix PR31934: forming refs to functions with enable_if attrs.George Burgess IV2017-04-131-0/+13
| | | | llvm-svn: 300283
* Fix lambda to block conversion in C++17 by avoiding copy elision for theAlex Lorenz2017-04-061-0/+17
| | | | | | | | | | | | | | | | lambda capture used by the created block The commit r288866 introduced guaranteed copy elision to C++ 17. This unfortunately broke the lambda to block conversion in C++17 (the compiler crashes when performing IRGen). This commit fixes the conversion by avoiding copy elision for the capture that captures the lambda that's used in the block created by the lambda to block conversion process. rdar://31385153 Differential Revision: https://reviews.llvm.org/D31669 llvm-svn: 299646
* [OpenCL] Extended diagnostics for atomic initializationEgor Churaev2017-04-051-0/+14
| | | | | | | | | | | | | | | | | | Summary: I saw the same changes in the following review: https://reviews.llvm.org/D17438 I don't know in that way I could determine that atomic variable was initialized by macro ATOMIC_VAR_INIT. Anyway I added check that atomic variables can be initialize only in global scope. I think that we can discuss this change. Reviewers: Anastasia, cfe-commits Reviewed By: Anastasia Subscribers: bader, yaxunl Differential Revision: https://reviews.llvm.org/D30643 llvm-svn: 299537
* [OpenCL] Enables passing sampler initializer to function argumentEgor Churaev2017-04-051-1/+1
| | | | | | | | | | | | Reviewers: Anastasia, cfe-commits Reviewed By: Anastasia Subscribers: yaxunl, bader Differential Revision: https://reviews.llvm.org/D31594 llvm-svn: 299524
* [Objective-C] Miscellaneous -fobjc-weak FixesBrian Kelley2017-03-291-8/+4
| | | | | | | | | | | | | | Summary: After examining the remaining uses of LangOptions.ObjCAutoRefCount, found a some additional places to also check for ObjCWeak not covered by previous test cases. Added a test file to verify all the code paths that were changed. Reviewers: rsmith, doug.gregor, rjmccall Reviewed By: rjmccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D31007 llvm-svn: 299015
* Fix handling of initialization from parenthesized initializer list.Richard Smith2017-03-241-1/+31
| | | | | | | | | | | | | This change fixes a crash on initialization of a reference from ({}) during template instantiation and incidentally improves diagnostics. This reverts a prior attempt to handle this in r286721. Instead, we teach the initialization code that initialization cannot be performed if a source type is required and the initializer is an initializer list (which is not an expression and does not have a type), and likewise for function-style cast expressions. llvm-svn: 298676
OpenPOWER on IntegriCloud