summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST
Commit message (Collapse)AuthorAgeFilesLines
* [clang] fix undefined behaviour in RawComment::getFormattedText()Oliver Bruns2020-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Calling `back()` and `pop_back()` on the empty string is undefined behavior [1,2]. The issue manifested itself as an uncaught `std::out_of_range` exception when running `clangd` compiled on RHEL7 using devtoolset-9. [1] https://en.cppreference.com/w/cpp/string/basic_string/back [2] https://en.cppreference.com/w/cpp/string/basic_string/pop_back Fixes: 1ff7c32fc91c607b690d4bb9cf42f406be8dde68 Reviewers: teemperor, ioeric, cfe-commits Reviewed By: teemperor Subscribers: ilya-biryukov, kadircet, usaxena95 Tags: #clang Differential Revision: https://reviews.llvm.org/D77468 (cherry picked from commit ad7211df6f257e39da2e5a11b2456b4488f32a1e)
* PR45350: Handle unsized array CXXConstructExprs in constant evaluationRichard Smith2020-05-181-1/+22
| | | | | | of array new expressions with runtime bound. (cherry picked from commit 9a7eda1bece887ca9af085d79fe6e4fb8826dcda)
* PR45000: Let Sema::SubstParmVarDecl handle default args of lambdas in ↵Aaron Puchert2020-05-061-1/+4
| | | | | | | | | | | | | | | | | | | | initializers Summary: We extend the behavior for local functions and methods of local classes to lambdas in variable initializers. The initializer is not a separate scope, but we treat it as such. We also remove the (faulty) instantiation of default arguments in TreeTransform::TransformLambdaExpr, because it doesn't do proper initialization, and if it did, we would do it twice (and thus also emit eventual errors twice). Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D76038 (cherry picked from commit f43859a099fa3587123717be941fa63ba8d0d4f2)
* PR45083: Mark statement expressions as being dependent if they appear inRichard Smith2020-03-121-2/+3
| | | | | | | | | | | | | | | | a dependent context. This matches the GCC behavior. We track the enclosing template depth when determining whether a statement expression is within a dependent context; there doesn't appear to be any other reliable way to determine this. We previously assumed they were neither value- nor instantiation-dependent under any circumstances, which would lead to crashes and other misbehavior. (cherry picked from commit 5c845c1c50ac89a6f12557d1571678f3d1432478)
* Revert "PR45083: Mark statement expressions as being dependent if they ↵Hans Wennborg2020-03-121-3/+2
| | | | | | | | | appear in" This turned out to cause problems, and was reverted on master together with its follow-up change in 66addf8e803618758457e4d578c5084e322ca448. This reverts commit 3a843031a5ad83a00d2603f623881cb2b2bf719d.
* PR45083: Mark statement expressions as being dependent if they appear inRichard Smith2020-03-041-2/+3
| | | | | | | | | | dependent contexts. We previously assumed they were neither value- nor instantiation-dependent under any circumstances, which would lead to crashes and other misbehavior. (cherry picked from commit bdad0a1b79273733df9acc1be4e992fa5d70ec56)
* Fix type-dependency of bitfields in templatesElizabeth Andrews2020-02-131-0/+5
| | | | | | | | | | | | | This patch is a follow up to 878a24ee244a24. Name of bitfields with value-dependent width should be set as type-dependent. This patch adds the required value-dependency check and sets the type-dependency accordingly. Patch fixes PR44886 Differential revision: https://reviews.llvm.org/D72242 (cherry picked from commit a58017e5cae5be948fd1913b68d46553e87aa622)
* PR44786: Don't assert when profiling <=> expressions.Richard Smith2020-02-041-2/+2
| | | | (cherry picked from commit b96c6b65b93f7b3878bced2374bef747a4c3b690)
* Fix wrong devirtualization when the final overrider in one base classRichard Smith2020-01-312-4/+30
| | | | | | overrides the final overrider in a different base class. (cherry picked from commit aade5fbbfef3e8555df202082bea905deebc2ca5)
* [Concept] Fix incorrect check for containsUnexpandedParameterPack in CSESaar Raz2020-01-302-21/+50
| | | | | | | | | | We previously checked for containsUnexpandedParameterPack in CSEs by observing the property in the converted arguments of the CSE. This may not work if the argument is an expanded type-alias that contains a pack-expansion (see added test). Check the as-written arguments when determining containsUnexpandedParameterPack and isInstantiationDependent. (cherry picked from commit c83d9bedc0cc430dc620e7a807daeb985d390325)
* [Concepts] Transform constraints of non-template functions to ConstantEvaluatedSaar Raz2020-01-251-2/+2
| | | | | | | | | | We would previously try to evaluate atomic constraints of non-template functions as-is, and since they are now unevaluated at first, this would cause incorrect evaluation (bugs #44657, #44656). Substitute into atomic constraints of non-template functions as we would atomic constraints of template functions, in order to rebuild the expressions in a constant-evaluated context. (cherry picked from commit 713562f54858f10bf8998ee21ff2c7e7bad0d177)
* [Concepts] Deprecate -fconcepts-ts, enable Concepts under -std=c++2aSaar Raz2020-01-241-1/+1
| | | | | | | | | Now with concepts support merged and mostly complete, we do not need -fconcepts-ts (which was also misleading as we were not implementing the TS) and can enable concepts features under C++2a. A warning will be generated if users still attempt to use -fconcepts-ts. (cherry picked from commit 67c608a9695496cfc9d3fdf9d0b12b554ac6b4df)
* [Concepts] Placeholder constraints and abbreviated templatesSaar Raz2020-01-2410-96/+319
| | | | | | | | | | | | | | | | | | | | | | | This patch implements P1141R2 "Yet another approach for constrained declarations". General strategy for this patch was: - Expand AutoType to include optional type-constraint, reflecting the wording and easing the integration of constraints. - Replace autos in parameter type specifiers with invented parameters in GetTypeSpecTypeForDeclarator, using the same logic previously used for generic lambdas, now unified with abbreviated templates, by: - Tracking the template parameter lists in the Declarator object - Tracking the template parameter depth before parsing function declarators (at which point we can match template parameters against scope specifiers to know if we have an explicit template parameter list to append invented parameters to or not). - When encountering an AutoType in a parameter context we check a stack of InventedTemplateParameterInfo structures that contain the info required to create and accumulate invented template parameters (fields that were already present in LambdaScopeInfo, which now inherits from this class and is looked up when an auto is encountered in a lambda context). Resubmit after fixing MSAN failures caused by incomplete initialization of AutoTypeLocs in TypeSpecLocFiller. Differential Revision: https://reviews.llvm.org/D65042 (cherry picked from commit b481f028144ca91c15d1db3649ce14f174259e7e)
* [Concepts] Profile TypeConstraints in ProfileTemplateParameterListSaar Raz2020-01-241-1/+4
| | | | | | | | | | | Profile TypeConstraints in ProfileTemplateParameterList so we can distinguish between partial specializations which differ in their TemplateParameterList type constraints. Recommit, now profiling the IDC so that we can deal with situations where the TemplateArgsAsWritten are nullptr (happens when canonicalizing type constraints). (cherry picked from commit 62c221b5090c2e1d3ca408bcab6f69c4d9e175b7)
* [Concepts] Fix circular AST->Sema dependency in ASTConcept.cppSaar Raz2020-01-241-1/+4
| | | | | | Remove inappropriate Sema include in ASTConcept.cpp introduced by D72552 for the finer-grained includes actually needed. (cherry picked from commit bb9b964072eb42a09e76fe148b36eefcfff077b2)
* [Concepts] Constraint Satisfaction CachingSaar Raz2020-01-241-0/+10
| | | | | | | | | | | Add a simple cache for constraint satisfaction results. Whether or not this simple caching would be permitted in final C++2a is currently being discussed but it is required for acceptable performance so we use it in the meantime, with the possibility of adding some cache invalidation mechanisms later. Differential Revision: https://reviews.llvm.org/D72552 (cherry picked from commit b933d37cd3774e5431b35e82187eebb59b1ff59e)
* [Concepts] Requires ExpressionsSaar Raz2020-01-2412-78/+306
| | | | | | | | | | Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360 (cherry picked from commit a0f50d731639350c7a79f140f026c27a18215531)
* [Concepts] Fix ConceptSpecializationExpr profiling crashSaar Raz2020-01-241-3/+3
| | | | | | | | | | | | ConceptSpecializationExprs (CSEs) were being created with nullptr TemplateArgsAsWritten during TemplateTemplateParmDecl canonicalization, and we were relying on them during profiling which caused sporadic crashes in test/CXX/.../temp.arg.template/p3-2a.cpp introduced in D44352. Change profiling of CSEs to instead rely on the actual converted template arguments and concept named. (cherry picked from commit 8a3446746098ba29348bb8f85357dd0b466a6d6e)
* Revert 9007f06af0e "Revert "Allow system header to provide their own ↵Hans Wennborg2020-01-171-0/+8
| | | | | | | implementation of some builtin"" This should no longer be necessary after cd4c65f91d5 "Add __warn_memset_zero_len builtin as a workaround for glibc issue"
* Revert "Allow system header to provide their own implementation of some builtin"Amy Huang2020-01-171-8/+0
| | | | | | | | | This reverts commit 921f871ac438175ca8fcfcafdfcfac4d7ddf3905 because it causes libc++ code to trigger __warn_memset_zero_len. See https://reviews.llvm.org/D71082. (cherry picked from commit 3d210ed3d1880c615776b07d1916edb400c245a6)
* PR44540: Prefer an inherited default constructor over an initializerRichard Smith2020-01-141-37/+43
| | | | | | | | | list constructor when initializing from {}. We would previously pick between calling an initializer list constructor and calling a default constructor unstably in this situation, depending on whether the inherited default constructor had already been used elsewhere in the program.
* [Concepts] Type ConstraintsSaar Raz2020-01-157-63/+262
| | | | | | | Add support for type-constraints in template type parameters. Also add support for template type parameters as pack expansions (where the type constraint can now contain an unexpanded parameter pack). Differential Revision: https://reviews.llvm.org/D44352
* Removed PointerUnion3 and PointerUnion4 aliases in favor of the variadic ↵Dmitri Gribenko2020-01-141-4/+4
| | | | template
* Fix "null pointer passed to nonnull argument" clang static analyzer ↵Simon Pilgrim2020-01-141-3/+3
| | | | | | warnings. NFCI. Assert that the memcpy arguments are valid.
* Make helper functions static or move them into anonymous namespaces. NFC.Benjamin Kramer2020-01-141-1/+1
|
* Implement VectorType conditional operator GNU extension.Erich Keane2020-01-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC supports the conditional operator on VectorTypes that acts as a 'select' in C++ mode. This patch implements the support. Types are converted as closely to GCC's behavior as possible, though in a few places consistency with our existing vector type support was preferred. Note that this implementation is different from the OpenCL version in a number of ways, so it unfortunately required a different implementation. First, the SEMA rules and promotion rules are significantly different. Secondly, GCC implements COND[i] != 0 ? LHS[i] : RHS[i] (where i is in the range 0- VectorSize, for each element). In OpenCL, the condition is COND[i] < 0 ? LHS[i]: RHS[i]. In the process of implementing this, it was also required to make the expression COND ? LHS : RHS type dependent if COND is type dependent, since the type is now dependent on the condition. For example: T ? 1 : 2; Is not typically type dependent, since the result can be deduced from the operands. HOWEVER, if T is a VectorType now, it could change this to a 'select' (basically a swizzle with a non-constant mask) with the 1 and 2 being promoted to vectors themselves. While this is a change, it is NOT a standards incompatible change. Based on my (and D. Gregor's, at the time of writing the code) reading of the standard, the expression is supposed to be type dependent if ANY sub-expression is type dependent. Differential Revision: https://reviews.llvm.org/D71463
* Fix cppcheck uninitialized variable in DiffTree() constructor warning. NFCI.Simon Pilgrim2020-01-131-2/+1
|
* Merge isVectorType() and getAs<VectorType> calls to silence clang static ↵Simon Pilgrim2020-01-131-2/+1
| | | | analyzer warning. NFCI.
* Fix some cppcheck shadow variable warnings. NFCI.Simon Pilgrim2020-01-131-15/+13
|
* Fix "pointer is null" static analyzer warnings. NFCI.Simon Pilgrim2020-01-131-2/+2
| | | | Use castAs<> instead of getAs<> since the pointers are always dereferenced and castAs will perform the null assertion for us.
* Fix "pointer is null" static analyzer warnings. NFCI.Simon Pilgrim2020-01-121-2/+2
| | | | Use castAs<> instead of getAs<> since the pointers are dereferenced immediately and castAs will perform the null assertion for us.
* Fix "pointer is null" static analyzer warning. NFCI.Simon Pilgrim2020-01-111-1/+1
| | | | Use castAs<> instead of getAs<> since the pointer is dereferenced immediately within mangleCallingConvention and castAs will perform the null assertion for us.
* Allow system header to provide their own implementation of some builtinserge-sans-paille2020-01-101-0/+8
| | | | | | | | | | | | | | | | | | If a system header provides an (inline) implementation of some of their function, clang still matches on the function name and generate the appropriate llvm builtin, e.g. memcpy. This behavior is in line with glibc recommendation « users may not provide their own version of symbols » but doesn't account for the fact that glibc itself can provide inline version of some functions. It is the case for the memcpy function when -D_FORTIFY_SOURCE=1 is on. In that case an inline version of memcpy calls __memcpy_chk, a function that performs extra runtime checks. Clang currently ignores the inline version and thus provides no runtime check. This code fixes the issue by detecting functions whose name is a builtin name but also have an inline implementation. Differential Revision: https://reviews.llvm.org/D71082
* Add builtins for aligning and checking alignment of pointers and integersAlex Richardson2020-01-091-11/+163
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change introduces three new builtins (which work on both pointers and integers) that can be used instead of common bitwise arithmetic: __builtin_align_up(x, alignment), __builtin_align_down(x, alignment) and __builtin_is_aligned(x, alignment). I originally added these builtins to the CHERI fork of LLVM a few years ago to handle the slightly different C semantics that we use for CHERI [1]. Until recently these builtins (or sequences of other builtins) were required to generate correct code. I have since made changes to the default C semantics so that they are no longer strictly necessary (but using them does generate slightly more efficient code). However, based on our experience using them in various projects over the past few years, I believe that adding these builtins to clang would be useful. These builtins have the following benefit over bit-manipulation and casts via uintptr_t: - The named builtins clearly convey the semantics of the operation. While checking alignment using __builtin_is_aligned(x, 16) versus ((x & 15) == 0) is probably not a huge win in readably, I personally find __builtin_align_up(x, N) a lot easier to read than (x+(N-1))&~(N-1). - They preserve the type of the argument (including const qualifiers). When using casts via uintptr_t, it is easy to cast to the wrong type or strip qualifiers such as const. - If the alignment argument is a constant value, clang can check that it is a power-of-two and within the range of the type. Since the semantics of these builtins is well defined compared to arbitrary bit-manipulation, it is possible to add a UBSAN checker that the run-time value is a valid power-of-two. I intend to add this as a follow-up to this change. - The builtins avoids int-to-pointer casts both in C and LLVM IR. In the future (i.e. once most optimizations handle it), we could use the new llvm.ptrmask intrinsic to avoid the ptrtoint instruction that would normally be generated. - They can be used to round up/down to the next aligned value for both integers and pointers without requiring two separate macros. - In many projects the alignment operations are already wrapped in macros (e.g. roundup2 and rounddown2 in FreeBSD), so by replacing the macro implementation with a builtin call, we get improved diagnostics for many call-sites while only having to change a few lines. - Finally, the builtins also emit assume_aligned metadata when used on pointers. This can improve code generation compared to the uintptr_t casts. [1] In our CHERI compiler we have compilation mode where all pointers are implemented as capabilities (essentially unforgeable 128-bit fat pointers). In our original model, casts from uintptr_t (which is a 128-bit capability) to an integer value returned the "offset" of the capability (i.e. the difference between the virtual address and the base of the allocation). This causes problems for cases such as checking the alignment: for example, the expression `if ((uintptr_t)ptr & 63) == 0` is generally used to check if the pointer is aligned to a multiple of 64 bytes. The problem with offsets is that any pointer to the beginning of an allocation will have an offset of zero, so this check always succeeds in that case (even if the address is not correctly aligned). The same issues also exist when aligning up or down. Using the alignment builtins ensures that the address is used instead of the offset. While I have since changed the default C semantics to return the address instead of the offset when casting, this offset compilation mode can still be used by passing a command-line flag. Reviewers: rsmith, aaron.ballman, theraven, fhahn, lebedev.ri, nlopes, aqjune Reviewed By: aaron.ballman, lebedev.ri Differential Revision: https://reviews.llvm.org/D71499
* Improve support of GNU mempcpyserge-sans-paille2020-01-091-0/+7
| | | | | | | - Lower to the memcpy intrinsic - Raise warnings when size/bounds are known Differential Revision: https://reviews.llvm.org/D71374
* [Concepts] Function trailing requires clausesSaar Raz2020-01-095-41/+76
| | | | | | Function trailing requires clauses now parsed, supported in overload resolution and when calling, referencing and taking the address of functions or function templates. Differential Revision: https://reviews.llvm.org/D43357
* Fix "pointer is null" static analyzer warning. NFCI.Simon Pilgrim2020-01-071-3/+3
|
* [NFC] Use isX86() instead of getArch()Jim Lin2020-01-071-3/+1
| | | | | | | | | | | | | | Summary: This is a clean up for https://reviews.llvm.org/D72247. Reviewers: MaskRay, craig.topper, jhenderson Reviewed By: MaskRay Subscribers: hiraditya, rupprecht, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72320
* Add Triple::isX86()Fangrui Song2020-01-061-3/+1
| | | | | | Reviewed By: craig.topper, skan Differential Revision: https://reviews.llvm.org/D72247
* Fix oversight in AST traversal helperStephen Kelly2020-01-051-1/+1
|
* Adds fixit hints to the -Wrange-loop-analysisMark de Wever2020-01-011-0/+6
| | | | Differential Revision: https://reviews.llvm.org/D68913
* Fix crash in getFullyQualifiedName for inline namespaceAlexey Bader2019-12-281-1/+1
| | | | | | | | | | | | | | Summary: The ICE happens when the most outer namespace is an inline namespace. Reviewers: bkramer, ilya-biryukov Reviewed By: ilya-biryukov Subscribers: ebevhan, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71962
* [OpenCL] Pretty print __private addr spaceAnastasia Stulova2019-12-271-1/+1
| | | | | | | | | | Add printing of __private address space to TypePrinter to allow it appears in diagnostics and AST dumps as all other language addr spaces. Tags: #clang Differential Revision: https://reviews.llvm.org/D71272
* [OpenMP][NFCI] Use the libFrontend ProcBindKind in ClangJohannes Doerfert2019-12-261-1/+2
| | | | | | | | | | | | This removes the OpenMPProcBindClauseKind enum in favor of llvm::omp::ProcBindKind which lives in OpenMPConstants.h and was introduced in D70109. No change in behavior is expected. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D70289
* [OPENMP50]Basic support for conditional lastprivate.Alexey Bataev2019-12-241-5/+13
| | | | Added parsing/sema checks for conditional lastprivates.
* [clang] [ast] CXXRecordDecl::getVisibleConversionFunctions() could be constWhisperity2019-12-241-12/+10
| | | | | | | | | | The function and its called static helpers don't modify the received CXXRecordDecl arguments at all as the method's result is put into an output parameter. Thus they can be const which allows for neatly grabbing the conversion methods in a context where we only have a const ASTUnit at hand. Differential Revision: https://reviews.llvm.org/D71805
* [Sema][X86] Consider target attribute into the checks in validateOutputSize ↵Craig Topper2019-12-231-0/+63
| | | | | | | | | | | | | and validateInputSize. The validateOutputSize and validateInputSize need to check whether AVX or AVX512 are enabled. But this can be affected by the target attribute so we need to factor that in. This patch moves some of the code from CodeGen to create an appropriate feature map that we can pass to the function. Differential Revision: https://reviews.llvm.org/D68627
* [OPENMP50]Codegen for nontemporal clause.Alexey Bataev2019-12-232-5/+14
| | | | | | | | | | | | | | | | Summary: Basic codegen for the declarations marked as nontemporal. Also, if the base declaration in the member expression is marked as nontemporal, lvalue for member decl access inherits nonteporal flag from the base lvalue. Reviewers: rjmccall, hfinkel, jdoerfert Subscribers: guansong, arphaman, caomhin, kkwli0, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71708
* [Concepts] Constrained partial specializations and function overloads.Saar Raz2019-12-232-28/+85
| | | | | | | Added support for constraint satisfaction checking and partial ordering of constraints in constrained partial specialization and function template overloads. Re-commit after fixing another crash (added regression test). Differential Revision: https://reviews.llvm.org/D41910
* Revert "[Concepts] Constrained partial specializations and function overloads."Reid Kleckner2019-12-222-85/+28
| | | | | | This reverts commit d3f5769d5e93b30d4a8b4696381d5e4a304992fa. Causes crashes on Chromium. Have reproducer, will reduce and send along.
OpenPOWER on IntegriCloud