summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaInit.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Reland [LifetimeAnalysis] Support more STL idioms (template forward ↵Matthias Gehre2019-09-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | declaration and DependentNameType) Reland after https://reviews.llvm.org/D66806 fixed the false-positive diagnostics. Summary: This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ (the typedef for iterator on the template is a DependentNameType - we can only put the gsl::Pointer attribute on the underlaying record after instantiation) inference of gsl::Pointer on std::vector::iterator with libc++ (the class was forward-declared, we added the gsl::Pointer on the canonical decl (the forward decl), and later when the template was instantiated, there was no attribute on the definition so it was not instantiated). and a duplicate gsl::Pointer on some class with libstdc++ (we first added an attribute to a incomplete instantiation, and then another was copied from the template definition when the instantiation was completed). We now add the attributes to all redeclarations to fix thos issues and make their usage easier. Reviewers: gribozavr Subscribers: Szelethus, xazax.hun, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66179 llvm-svn: 371182
* [LifetimeAnalysis] Fix some false positivesGabor Horvath2019-09-031-0/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D66806 llvm-svn: 370773
* Fix variable HasArrayDesignator set but not used warning. NFCI.Simon Pilgrim2019-09-011-3/+0
| | | | llvm-svn: 370609
* [c++20] Add support for designated direct-list-initialization syntax.Richard Smith2019-08-311-3/+27
| | | | | | This completes the implementation of P0329R4. llvm-svn: 370558
* [c++20] Implement semantic restrictions for C++20 designatedRichard Smith2019-08-301-92/+176
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | initializers. This has some interesting interactions with our existing extensions to support C99 designated initializers as an extension in C++. Those are resolved as follows: * We continue to permit the full breadth of C99 designated initializers in C++, with the exception that we disallow a partial overwrite of an initializer with a non-trivially-destructible type. (Full overwrite is OK, because we won't run the first initializer at all.) * The C99 extensions are disallowed in SFINAE contexts and during overload resolution, where they could change the meaning of valid programs. * C++20 disallows reordering of initializers. We only check for that for the simple cases that the C++20 rules permit (designators of the form '.field_name =' and continue to allow reordering in other cases). It would be nice to improve this behavior in future. * All C99 designated initializer extensions produce a warning by default in C++20 mode. People are going to learn the C++ rules based on what Clang diagnoses, so it's important we diagnose these properly by default. * In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and so still diagnose C99 extensions as described above. We continue to accept designated C++20-compatible initializers in C++ <= 17 silently by default (but naturally still reject under -pedantic-errors). This is not a complete implementation of P0329R4. In particular, that paper introduces new non-C99-compatible syntax { .field { init } }, and we do not support that yet. This is based on a previous patch by Don Hinton, though I've made substantial changes when addressing the above interactions. Differential Revision: https://reviews.llvm.org/D59754 llvm-svn: 370544
* Fix silent wrong-code bugs and crashes with designated initialization.Richard Smith2019-08-291-176/+239
| | | | | | | | | | | | | | | | | | | | | We failed to correctly handle the 'holes' left behind by designated initializers in VerifyOnly mode. This would result in us thinking that a designated initialization would be valid, only to find that it is not actually valid when we come to build it. In a +Asserts build, that would assert, and in a -Asserts build, that would silently lose some part of the initialization or crash. With this change, when an InitListExpr contains any designators, we now always build a structured list so that we can track the locations of the 'holes' that we need to go back and fill in. We could in principle do better: we only need the structured form if there is a designator that jumps backwards (and can otherwise check for the holes as we progress through the initializer list), but dealing with that turns out to be rather complicated, so it's not done as part of this patch. llvm-svn: 370419
* Refactor InitListChecker to check only a single (explicit) initializerRichard Smith2019-08-291-45/+12
| | | | | | | | | | list, rather than recursively checking multiple lists in C. This simplification is in preparation for making InitListChecker maintain more state that's specific to the explicit initializer list, particularly when handling designated initialization. llvm-svn: 370418
* Refactor InitListChecker to make it a bit clearer that hasError is onlyRichard Smith2019-08-291-44/+36
| | | | | | | | | | set to true in VerifyOnly mode in cases where it's also set to true when actually building the initializer list. Add FIXMEs for the two cases where that's not true. No functionality change intended. llvm-svn: 370417
* Improve behavior in the case of stack exhaustion.Richard Smith2019-08-261-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Clang performs various recursive operations (such as template instantiation), and may use non-trivial amounts of stack space in each recursive step (for instance, due to recursive AST walks). While we try to keep the stack space used by such steps to a minimum and we have explicit limits on the number of such steps we perform, it's impractical to guarantee that we won't blow out the stack on deeply recursive template instantiations on complex ASTs, even with only a moderately high instantiation depth limit. The user experience in these cases is generally terrible: we crash with no hint of what went wrong. Under this patch, we attempt to do better: * Detect when the stack is nearly exhausted, and produce a warning with a nice template instantiation backtrace, telling the user that we might run slowly or crash. * For cases where we're forced to trigger recursive template instantiation in arbitrarily-deeply-nested contexts, check whether we're nearly out of stack space and allocate a new stack (by spawning a new thread) after producing the warning. Reviewers: rnk, aaron.ballman Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66361 llvm-svn: 369940
* [NFC] Add comments to some bool arguments for better readabilityGabor Horvath2019-08-261-4/+8
| | | | llvm-svn: 369928
* [LifetimeAnalysis] Make it possible to disable the new warningsGabor Horvath2019-08-231-38/+70
| | | | llvm-svn: 369817
* Revert "[LifetimeAnalysis] Support more STL idioms (template forward ↵Richard Smith2019-08-221-2/+2
| | | | | | | | | | declaration and DependentNameType)" This reverts commit r369591, because it causes the formerly-reliable -Wreturn-stack-address warning to start issuing false positives. Testcase provided on the commit thread. llvm-svn: 369677
* [LifetimeAnalysis] Support more STL idioms (template forward declaration and ↵Matthias Gehre2019-08-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | DependentNameType) Summary: This fixes inference of gsl::Pointer on std::set::iterator with libstdc++ (the typedef for iterator on the template is a DependentNameType - we can only put the gsl::Pointer attribute on the underlaying record after instantiation) inference of gsl::Pointer on std::vector::iterator with libc++ (the class was forward-declared, we added the gsl::Pointer on the canonical decl (the forward decl), and later when the template was instantiated, there was no attribute on the definition so it was not instantiated). and a duplicate gsl::Pointer on some class with libstdc++ (we first added an attribute to a incomplete instantiation, and then another was copied from the template definition when the instantiation was completed). We now add the attributes to all redeclarations to fix thos issues and make their usage easier. Reviewers: gribozavr Subscribers: Szelethus, xazax.hun, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66179 llvm-svn: 369591
* [LifetimeAnalysis] Add support for free functionsGabor Horvath2019-08-201-0/+29
| | | | | | Differential Revision: https://reviews.llvm.org/D66303 llvm-svn: 369408
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-1/+1
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942
* [LifetimeAnalysis] Support std::stack::top() and std::optional::value()Matthias Gehre2019-08-141-1/+1
| | | | | | | | | | | | | | Summary: Diagnose dangling pointers that come from std::stack::top() and std::optional::value(). Reviewers: gribozavr Subscribers: cfe-commits, xazax.hun Tags: #clang Differential Revision: https://reviews.llvm.org/D66164 llvm-svn: 368929
* [LifetimeAnalysis] Fix false negatives of statement local lifetime analysis ↵Gabor Horvath2019-08-141-19/+42
| | | | | | | | for some STL implementation Differential Revision: https://reviews.llvm.org/D66152 llvm-svn: 368871
* Fix multiple lifetime warning messages for range based for loopGabor Horvath2019-08-121-2/+5
| | | | llvm-svn: 368588
* [OpenCL] Ignore parentheses for sampler initializationSven van Haastregt2019-08-121-1/+1
| | | | | | | | | | | | The sampler handling logic in SemaInit.cpp would inadvertently treat parentheses around sampler arguments as an implicit cast, leading to an unreachable "can't implicitly cast lvalue to rvalue with this cast kind". Fix by ignoring parentheses once we are in the sampler initializer case. Differential Revision: https://reviews.llvm.org/D66080 llvm-svn: 368561
* Properly detect temporary gsl::Owners through reference initialization chains.Gabor Horvath2019-08-111-1/+2
| | | | llvm-svn: 368534
* Properly handle reference initialization when detecting gsl::Pointer ↵Gabor Horvath2019-08-111-5/+9
| | | | | | initialization chains llvm-svn: 368528
* Fix a false positive warning when initializing members with gsl::Owners.Gabor Horvath2019-08-101-0/+5
| | | | llvm-svn: 368501
* Attempt to reapply "Even more warnings utilizing gsl::Owner/gsl::Pointer ↵Gabor Horvath2019-08-091-9/+29
| | | | | | annotations" llvm-svn: 368499
* Revert Even more warnings utilizing gsl::Owner/gsl::Pointer annotationsGabor Horvath2019-08-091-29/+9
| | | | | | This reverts r368454 (git commit 7c3c8ba8daf40534e09f6fe8701b723e25e4e2dc) llvm-svn: 368463
* Revert Fix a build bot failure and multiple warnings instances for range ↵Gabor Horvath2019-08-091-6/+3
| | | | | | | | base for loops This reverts r368459 (git commit 2bf522aea62e4fb653cacb68072167d25149099e) llvm-svn: 368462
* Fix a build bot failure and multiple warnings instances for range base for loopsGabor Horvath2019-08-091-3/+6
| | | | llvm-svn: 368459
* Even more warnings utilizing gsl::Owner/gsl::Pointer annotationsGabor Horvath2019-08-091-9/+29
| | | | | | Differential Revision: https://reviews.llvm.org/D65127 llvm-svn: 368454
* More warnings regarding gsl::Pointer and gsl::Owner attributesGabor Horvath2019-08-091-4/+22
| | | | | | Differential Revision: https://reviews.llvm.org/D65120 llvm-svn: 368446
* Update fix-it hints for std::move warnings.Richard Trieu2019-08-081-24/+27
| | | | | | | | | | | Fix -Wpessimizing-move and -Wredundant-move when warning on initializer lists. The new fix-it hints for removing the std::move call will now also suggest removing the braces for the initializer list so that the resulting code will still be compilable. This fixes PR42832 llvm-svn: 368237
* Teach some warnings to respect gsl::Pointer and gsl::Owner attributesGabor Horvath2019-08-061-9/+90
| | | | | | | | This patch extends some existing warnings to utilize the knowledge about the gsl::Pointer and gsl::Owner attributes. Differential Revision: https://reviews.llvm.org/D64256 llvm-svn: 368072
* [OpenCL] Allow OpenCL C style vector initialization in C++Anastasia Stulova2019-08-021-3/+11
| | | | | | | | | | | Allow creating vector literals from other vectors. float4 a = (float4)(1.0f, 2.0f, 3.0f, 4.0f); float4 v = (float4)(a.s23, a.s01); Differential revision: https://reviews.llvm.org/D65286 llvm-svn: 367675
* [OpenCL] Fixing sampler initialisations for C++ mode.Neil Hickey2019-07-161-3/+3
| | | | | | | | Allow conversions between integer and sampler type. Differential Revision: https://reviews.llvm.org/D64791 llvm-svn: 366212
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-161-3/+3
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
* [Sema] Fix diagnostic for addr spaces in reference bindingAnastasia Stulova2019-06-211-8/+18
| | | | | | | | Extend reference binding behavior to account for address spaces. Differential Revision: https://reviews.llvm.org/D62914 llvm-svn: 364032
* [Sema] Improved diagnostic for qualifiers in reference bindingAnastasia Stulova2019-06-211-1/+2
| | | | | | | | | Improved wording and also simplified by using printing method from qualifiers. Differential Revision: https://reviews.llvm.org/D62914 llvm-svn: 364023
* [Sema] Diagnose addr space mismatch while constructing objectsAnastasia Stulova2019-06-201-0/+2
| | | | | | | | | | | | | | If we construct an object in some arbitrary non-default addr space it should fail unless either: - There is an implicit conversion from the address space to default /generic address space. - There is a matching ctor qualified with an address space that is either exactly matching or convertible to the address space of an object. Differential Revision: https://reviews.llvm.org/D62156 llvm-svn: 363944
* Remove unused SK_LValueToRValue initialization step.Richard Smith2019-06-141-27/+0
| | | | | | | | | In addition to being unused and duplicating code, this was also wrong (it didn't properly mark the operand as being potentially not odr-used). This reinstates r363340, reverted in r363352. llvm-svn: 363430
* PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of typeRichard Smith2019-06-141-3/+7
| | | | | | | | | | | nullptr_t does not access memory. We now reuse CK_NullToPointer to represent a conversion from a glvalue of type nullptr_t to a prvalue of nullptr_t where necessary. This reinstates r363337, reverted in r363352. llvm-svn: 363429
* Revert 363295, it caused PR42276. Also revert follow-ups 363337, 363340.Nico Weber2019-06-141-0/+23
| | | | | | | | Revert 363340 "Remove unused SK_LValueToRValue initialization step." Revert 363337 "PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of type" Revert 363295 "C++ DR712 and others: handle non-odr-use resulting from an lvalue-to-rvalue conversion applied to a member access or similar not-quite-trivial lvalue expression." llvm-svn: 363352
* Remove unused SK_LValueToRValue initialization step.Richard Smith2019-06-131-27/+0
| | | | | | | In addition to being unused and duplicating code, this was also wrong (it didn't properly mark the operand as being potentially not odr-used). llvm-svn: 363340
* PR23833, DR2140: an lvalue-to-rvalue conversion on a glvalue of typeRichard Smith2019-06-131-3/+7
| | | | | | | | | | | | nullptr_t does not access memory. We now reuse CK_NullToPointer to represent a conversion from a glvalue of type nullptr_t to a prvalue of nullptr_t where necessary. This reinstates r345562, reverted in r346065, now that CodeGen's handling of non-odr-used variables has been fixed. llvm-svn: 363337
* PR42220: take into account the possibility of aggregates with baseRichard Smith2019-06-121-0/+3
| | | | | | classes when checking an InitListExpr for lifetime extension. llvm-svn: 363188
* [Sema] Prevent binding incompatible addr space ref to temporariesAnastasia Stulova2019-06-051-1/+18
| | | | | | | | | | | | References to arbitrary address spaces can't always be bound to temporaries. This change extends the reference binding logic to check that the address space of a temporary can be implicitly converted to the address space in a reference when temporary materialization is performed. Differential Revision: https://reviews.llvm.org/D61318 llvm-svn: 362604
* [Sema] Mark array element destructors referenced during initializationErik Pilkington2019-05-101-29/+41
| | | | | | | | | | | | This fixes a crash where we would neglect to mark a destructor referenced for an __attribute__((no_destory)) array. The destructor is needed though, since if an exception is thrown we need to cleanup the elements. rdar://48462498 Differential revision: https://reviews.llvm.org/D61165 llvm-svn: 360446
* [c++20] Add support for explicit(bool), as described in P0892R2.Richard Smith2019-05-091-41/+50
| | | | | | | | Patch by Tyker! Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360311
* Revert r359949 "[clang] adding explicit(bool) from c++2a"Hans Wennborg2019-05-061-48/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused Clang to start erroring on the following: struct S {   template <typename = int> explicit S(); }; struct T : S {}; struct U : T {   U(); }; U::U() {} $ clang -c /tmp/x.cc /tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T' U::U() {}    ^ /tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted because base class 'S' has no default constructor struct T : S {};            ^ 1 error generated. See discussion on the cfe-commits email thread. This also reverts the follow-ups r359966 and r359968. > this patch adds support for the explicit bool specifier. > > Changes: > - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. > - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. > - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. > - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. > - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. > - Test for Semantic and Serialization were added. > > This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. > Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. > > Patch by Tyker > > Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360024
* [clang] adding explicit(bool) from c++2aNicolas Lesser2019-05-041-40/+48
| | | | | | | | | | | | | | | | | | | | | this patch adds support for the explicit bool specifier. Changes: - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. - Test for Semantic and Serialization were added. This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. Patch by Tyker Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 359949
* SemaOverload: Complete candidates before emitting the error, to ensure ↵David Blaikie2019-05-031-40/+57
| | | | | | | | | | | | | | | | | diagnostics emitted (or suppressed) during completion don't interfere with the overload notes Because diagnostics and their notes are not connected at the API level, if the error message for an overload is emitted, then the overload candidates are completed - if a diagnostic is emitted during that work, the notes related to overload candidates would be attached to the latter diagnostic, not the original error. Sort of worse, if the latter diagnostic was disabled, the notes are disabled. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D61357 llvm-svn: 359854
* [PR41276] Fixed incorrect generation of addr space cast for 'this' in C++.Anastasia Stulova2019-04-041-3/+13
| | | | | | | | | | | | | | | Improved classification of address space cast when qualification conversion is performed - prevent adding addr space cast for non-pointer and non-reference types. Take address space correctly from the pointee. Also pass correct address space from 'this' object using AggValueSlot when generating addrspacecast in the constructor call. Differential Revision: https://reviews.llvm.org/D59988 llvm-svn: 357682
* [Sema][NFCI] Don't allocate storage for the various ↵Bruno Ricci2019-03-251-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CorrectionCandidateCallback unless we are going to do some typo correction The various CorrectionCandidateCallbacks are currently heap-allocated unconditionally. This was needed because of delayed typo correction. However these allocations represent currently 15.4% of all allocations (number of allocations) when parsing all of Boost (!), mostly because of ParseCastExpression, ParseStatementOrDeclarationAfterAttrtibutes and isCXXDeclarationSpecifier. Note that all of these callback objects are small. Let's not do this. Instead initially allocate the callback on the stack, and only do a heap allocation if we are going to do some typo correction. Do this by: 1. Adding a clone function to each callback, which will do a polymorphic clone of the callback. This clone function is required to be implemented by every callback (of which there is a fair amount). Make sure this is the case by making it pure virtual. 2. Use this clone function when we are going to try to correct a typo. This additionally cut the time of -fsyntax-only on all of Boost by 0.5% (not that much, but still something). No functional changes intended. Differential Revision: https://reviews.llvm.org/D58827 Reviewed By: rnk llvm-svn: 356925
OpenPOWER on IntegriCloud