summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema
Commit message (Collapse)AuthorAgeFilesLines
...
* Fixes an assertion while instantiating a template with an incomplete ↵Aaron Ballman2019-09-071-2/+6
| | | | | | | | | | typo-corrected type. Fixes PR35682. When a template in instantiated with an incomplete typo corrected type an assertion can trigger if the -ferror-limit is used to reduce the number of errors. Patch by Mark de Wever. llvm-svn: 371320
* [Sema][ObjC] Mark C union fields that have non-trivial ObjC ownershipAkira Hatanaka2019-09-073-52/+34
| | | | | | | | | | | | | | | | | qualifications as unavailable if the union is declared in a system header r365985 stopped marking those fields as unavailable, which caused the union's NonTrivialToPrimitive* bits to be set to true. This patch restores the behavior prior to r365985, except that users can explicitly specify the ownership qualification of the field to instruct the compiler not to mark it as unavailable. rdar://problem/53420753 Differential Revision: https://reviews.llvm.org/D65256 llvm-svn: 371276
* [Sema] Diagnose default-initialization, destruction, and copying ofAkira Hatanaka2019-09-074-34/+352
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | non-trivial C union types This recommits r365985, which was reverted because it broke a few projects using unions containing non-trivial ObjC pointer fields in system headers. We now have a patch to fix the problem (see https://reviews.llvm.org/D65256). Original commit message: This patch diagnoses uses of non-trivial C unions and structs/unions containing non-trivial C unions in the following contexts, which require default-initialization, destruction, or copying of the union objects, instead of disallowing fields of non-trivial types in C unions, which is what we currently do: - function parameters. - function returns. - assignments. - compound literals. - block captures except capturing of `__block` variables by non-escaping blocks. - local and global variable definitions. - lvalue-to-rvalue conversions of volatile types. See the discussion in https://reviews.llvm.org/D62988 for more background. rdar://problem/50679094 Differential Revision: https://reviews.llvm.org/D63753 llvm-svn: 371275
* [NFCI] Unbreak buildbotsDavid Bolvansky2019-09-061-22/+10
| | | | llvm-svn: 371226
* [Diagnostics] Refactor code for -Wsizeof-pointer-div, catch more cases; also ↵David Bolvansky2019-09-062-12/+25
| | | | | | | | | | | | | | | | add -Wsizeof-array-div Previously, -Wsizeof-pointer-div failed to catch: const int *r; sizeof(r) / sizeof(int); Now fixed. Also introduced -Wsizeof-array-div which catches bugs like: sizeof(r) / sizeof(short); (Array element type does not match type of sizeof operand). llvm-svn: 371222
* Reland [LifetimeAnalysis] Support more STL idioms (template forward ↵Matthias Gehre2019-09-064-15/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Diagnostics] Minor improvements for -Wxor-used-as-powDavid Bolvansky2019-09-051-22/+35
| | | | | | Extracted from D66397; implemented suggestion for 2^64; tests revisited. llvm-svn: 371122
* [OpenCL] Add image type handling for builtinsSven van Haastregt2019-09-051-43/+151
| | | | | | | | | | | | | | | | | | | Image types were previously available, but not working. This patch adds image type handling. Rename the image type definitions in the .td file to make them consistent with other type names. Use abstract types to represent the unqualified types. Instantiate access-qualified image types at the point of use using, e.g. `ImageType<Image2d, "RO">`. Add/update TableGen definitions for the read_image/write_image builtin functions. Patch by Pierre Gondois and Sven van Haastregt. Differential Revision: https://reviews.llvm.org/D63480 llvm-svn: 371046
* [Sema] Refactor LookupVisibleDecls. NFCIlya Biryukov2019-09-051-272/+289
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We accumulated some configuration parameters for LookupVisibleDecls that are being passed unchanged to recursive calls, e.g. LoadExternal and IncludeDependentBases. At the same time, there is a bunch of parameters that can change in the recursive invocations. It is hard to tell the difference between those groups, making the code hard to follow. This change introduces a helper struct and factors out the non-changing bits into fields, making recursive calls in the implementation code easier to read. Reviewers: sammccall Reviewed By: sammccall Subscribers: riccibruno, doug.gregor, jkorous, arphaman, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65752 llvm-svn: 371032
* [c++20] Fix some ambiguities in our mangling of lambdas with explicitRichard Smith2019-09-051-2/+6
| | | | | | | | | | | | | template parameters. This finishes the implementation of the proposal described in https://github.com/itanium-cxx-abi/cxx-abi/issues/31. (We already implemented the <lambda-sig> extensions, but didn't take them into account when computing mangling numbers, and didn't deal properly with expanded parameter packs, and didn't disambiguate between different levels of template parameters in manglings.) llvm-svn: 371004
* For PR43213, track whether template parameters are implicit throughRichard Smith2019-09-041-0/+3
| | | | | | | template instantiation so we know whether to mangle them in lambda-expressions. llvm-svn: 370991
* [c++20] P1143R2: Add support for the C++20 'constinit' keyword.Richard Smith2019-09-044-40/+155
| | | | | | | | | | | | | This is mostly the same as the [[clang::require_constant_initialization]] attribute, but has a couple of additional syntactic and semantic restrictions. In passing, I added a warning for the attribute form being added after we have already seen the initialization of the variable (but before we see the definition); that case previously slipped between the cracks and the attribute was silently ignored. llvm-svn: 370972
* [PowerPC][Altivec][Clang] Check compile-time constant for vec_dst*Jinsong Ji2019-09-041-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is follow up of https://reviews.llvm.org/D66699. We might get ISEL ICE if we call vec_dss with non const 3rd arg. ``` Cannot select: intrinsic %llvm.ppc.altivec.dst ``` We should check the constraints in clang and generate better error messages. Reviewers: nemanjai, hfinkel, echristo, #powerpc, wuzish Reviewed By: #powerpc, wuzish Subscribers: wuzish, kbarton, MaskRay, shchenz, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66748 llvm-svn: 370912
* [PowerPC][Altivec] Fix constant argument for vec_dssJinsong Ji2019-09-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is similar to vec_ct* in https://reviews.llvm.org/rL304205. The argument must be a constant, otherwise instruction selection will fail. always_inline is not enough for isel to always fold everything away at -O0. The fix is to turn the function into macros in altivec.h. Fixes https://bugs.llvm.org/show_bug.cgi?id=43072 Reviewers: nemanjai, hfinkel, #powerpc, wuzish Reviewed By: #powerpc, wuzish Subscribers: wuzish, kbarton, MaskRay, shchenz, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66699 llvm-svn: 370902
* [LifetimeAnalysis] Fix some false positivesGabor Horvath2019-09-031-0/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D66806 llvm-svn: 370773
* Fixit for -Wfinal-dtor-non-final-classDavid Bolvansky2019-09-031-1/+0
| | | | llvm-svn: 370740
* Added fixit notes for -Wfinal-dtor-non-final-classDavid Bolvansky2019-09-031-4/+8
| | | | llvm-svn: 370737
* Fix variable HasArrayDesignator set but not used warning. NFCI.Simon Pilgrim2019-09-011-3/+0
| | | | llvm-svn: 370609
* [clang] Warning for non-final classes with final destructorsDavid Bolvansky2019-08-311-0/+13
| | | | | | | | | | | | Marking a class' destructor final prevents the class from being inherited from. However, it is a subtle and awkward way to express that at best, and unintended at worst. It may also generate worse code (in other compilers) than marking the class itself final. For these reasons, this revision adds a warning for nonfinal classes with final destructors, with a note to suggest marking the class final to silence the warning. See https://reviews.llvm.org/D66621 for more background. Patch by logan-5 (Logan Smith) Differential Revision: https://reviews.llvm.org/D66711 llvm-svn: 370594
* [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] Disallow template argument deduction from a braced-init-listRichard Smith2019-08-311-0/+12
| | | | | | | | | | | | containing designators. The C++20 wording doesn't actually say what happens in this case, but treating this as a non-deduced context seems like the most natural behavior. (We might want to consider deducing through array designators as an extension in the future, but will need to be careful to deduce the array bound properly if we do so. That's not permitted herein.) llvm-svn: 370555
* [c++20] Implement semantic restrictions for C++20 designatedRichard Smith2019-08-304-100/+250
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix variable ‘IsInitCapturePack’ set but not used warning. NFCI.Simon Pilgrim2019-08-291-4/+1
| | | | llvm-svn: 370345
* [OpenCL] Fix diagnosing enqueue_kernel call with too few argsSven van Haastregt2019-08-291-1/+3
| | | | | | | | | | | | The err_typecheck_call_too_few_args diagnostic takes arguments, but none were provided causing clang to crash when attempting to diagnose an enqueue_kernel call with too few arguments. Fixes llvm.org/PR42045 Differential Revision: https://reviews.llvm.org/D66883 llvm-svn: 370322
* Move EH spec mismatches under -fms-compatibilityReid Kleckner2019-08-271-6/+6
| | | | | | | | | | | | | | | | | | | | | -fms-extensions is intended to enable conforming language extensions and -fms-compatibility is intended to language rule relaxations, so a user could plausibly compile with -fno-ms-compatibility on Windows while still using dllexport, for example. This exception specification validation behavior has been handled as a warning since before -fms-compatibility was added in 2011. I think it's just an oversight that it hasn't been moved yet. This will help users find conformance issues in their code such as those found in _com_ptr_t as described in https://llvm.org/PR42842. Reviewers: hans Subscribers: STL_MSFT, cfe-commits Differential Revision: https://reviews.llvm.org/D66770 llvm-svn: 370087
* Don't lose the FoundDecl and template arguments for a DeclRefExpr inRichard Smith2019-08-271-5/+12
| | | | | | TreeTransform. llvm-svn: 369999
* PR42587: diagnose unexpanded uses of a pack parameter of a genericRichard Smith2019-08-265-34/+89
| | | | | | | | | | | | | | | | | lambda from within the lambda-declarator. Instead of trying to reconstruct whether a parameter pack was declared inside a lambda (which we can't do correctly in general because we might not have attached parameters to their declaration contexts yet), track the set of parameter packs introduced in each live lambda scope, and require only those parameters to be immediately expanded when they appear inside that lambda. In passing, fix incorrect disambiguation of a lambda-expression starting with an init-capture pack in a braced-init-list. We previously incorrectly parsed that as a designated initializer. llvm-svn: 369985
* Improve behavior in the case of stack exhaustion.Richard Smith2019-08-269-121/+199
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [OpenCL] Microoptimize OCL2Qual a bitBenjamin Kramer2019-08-241-11/+10
| | | | | | Still not optimal, but makes clang 25k smaller. llvm-svn: 369846
* PR42513: Enter the proper DeclContext before substituting into anRichard Smith2019-08-241-0/+1
| | | | | | | | | | | | default template argument expression. We already did this for type template parameters and template template parameters, but apparently forgot to do so for non-type template parameters. This causes the substituted default argument expression to be substituted in the proper context, and in particular to properly mark its subexpressions as odr-used. llvm-svn: 369834
* PR40674: fix assertion failure if a structured binding declaration has aRichard Smith2019-08-241-1/+2
| | | | | | | tuple-like decomposition that produces value-dependent reference bindings. llvm-svn: 369829
* [LifetimeAnalysis] Make it possible to disable the new warningsGabor Horvath2019-08-231-38/+70
| | | | llvm-svn: 369817
* [Sema] Don't warn on printf('%hd', [char]) (PR41467)Nathan Huckleberry2019-08-231-2/+6
| | | | | | | | | | | | | | | | Summary: Link: https://bugs.llvm.org/show_bug.cgi?id=41467 Reviewers: rsmith, nickdesaulniers, aaron.ballman, lebedev.ri Reviewed By: nickdesaulniers, aaron.ballman, lebedev.ri Subscribers: lebedev.ri, nickdesaulniers, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66186 llvm-svn: 369791
* Fixed a typo.Artem Belevich2019-08-231-1/+1
| | | | llvm-svn: 369777
* [OPENMP5.0]Add support for device_type clause in declare targetAlexey Bataev2019-08-233-45/+262
| | | | | | | | | | construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
* [NFC] Move some variable declarations into their 'if' conditions.Erich Keane2019-08-231-9/+7
| | | | | | | | A couple of variables are being declared outside of the 'if' condition that is their only actual use. Additionally, switch a few 'const TYPE *' to 'const auto *' for consistency. llvm-svn: 369773
* Revert "PR42587: diagnose unexpanded uses of a pack parameter of a generic" ↵Richard Smith2019-08-232-10/+3
| | | | | | | | due to buildbot breakage. This reverts commit r369722. llvm-svn: 369725
* PR42587: diagnose unexpanded uses of a pack parameter of a genericRichard Smith2019-08-232-3/+10
| | | | | | lambda from within the lambda-declarator. llvm-svn: 369722
* Revert "[LifetimeAnalysis] Support more STL idioms (template forward ↵Richard Smith2019-08-224-31/+15
| | | | | | | | | | 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
* [OPENMP]Generalization of handling of declare target attribute.Alexey Bataev2019-08-222-2/+2
| | | | | | | Used OMPDeclareTargetDeclAttr::isDeclareTargetDeclaration instead of direct checking of the OMPDeclareTargetDeclAttr attribute. llvm-svn: 369668
* [OpenMP] Permit map with DSA on combined directiveJoel E. Denny2019-08-224-27/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | For `map`, the following restriction changed in OpenMP 5.0: * OpenMP 4.5 [2.15.5.1, Restrictions]: "A list item cannot appear in both a map clause and a data-sharing attribute clause on the same construct. * OpenMP 5.0 [2.19.7.1, Restrictions]: "A list item cannot appear in both a map clause and a data-sharing attribute clause on the same construct unless the construct is a combined construct." This patch removes this restriction in the case of combined constructs and OpenMP 5.0, and it updates Sema not to capture a scalar by copy in the target region when `firstprivate` and `map` appear for that scalar on a combined target construct. This patch also adds a fixme to a test that now reveals that a diagnostic about loop iteration variables is dropped in the case of OpenMP 5.0. That bug exists regardless of this patch's changes. Reviewed By: ABataev, jdoerfert, hfinkel, kkwli0 Differential Revision: https://reviews.llvm.org/D65835 llvm-svn: 369619
* [LifetimeAnalysis] Support more STL idioms (template forward declaration and ↵Matthias Gehre2019-08-214-15/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* clang: Fix typo in commentNico Weber2019-08-211-1/+1
| | | | llvm-svn: 369542
* clang: Fix typo in commentNico Weber2019-08-211-1/+1
| | | | | | | (Sorry for all these commits; trying to sort out why svn doesn't want to store my password.) llvm-svn: 369540
* [OPENMP]Fix delayed diagnostics for standalone declare target directive.Alexey Bataev2019-08-202-9/+16
| | | | | | | If the function is marked as declare target in a standalone directive, the delayed diagnostics is not emitted. Patch fixes this problem. llvm-svn: 369432
* [Sema][Typo] Fix assertion failure for expressions with multiple typosDavid Goldman2019-08-202-42/+154
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As Typo Resolution can create new TypoExprs while resolving typos, it is necessary to recurse through the expression to search for more typos. This should fix the assertion failure in `clang::Sema::~Sema()`: `DelayedTypos.empty() && "Uncorrected typos!"` Notes: - In case some TypoExprs are created but thrown away, Sema now has a Vector that is used to keep track of newly created typos. - For expressions with multiple typos, we only give suggestions if we are able to resolve all typos in the expression - This patch is similar to D37521 except that it does not eagerly commit to a correction for the first typo in the expression. Instead, it will search for corrections which fix all of the typos in the expression. Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62648 llvm-svn: 369427
OpenPOWER on IntegriCloud