summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[clang] Add no_builtin attribute"Vlad Tsyrklevich2019-10-282-76/+0
| | | | | This reverts commit bd87916109483d33455cbf20da2309197b983cdd. It was causing ASan/MSan failures on the sanitizer buildbots.
* Revert "[Concepts] Constraint Enforcement & Diagnostics"Vlad Tsyrklevich2019-10-287-490/+103
| | | | | This reverts commit ffa214ef22892d75340dc6720271863901dc2c90, it was causing ASAN test failures on sanitizer-x86_64-linux-bootstrap.
* [OPENMP]Fix PR43771: Do not capture contexprs variables.Alexey Bataev2019-10-281-1/+5
| | | | If the variable is a constexpr variable, it should not be captured in the OpenMP region.
* [clang] Add no_builtin attributeGuillaume Chatelet2019-10-282-0/+76
| | | | | | | | | | | | | | Summary: This is a follow up on https://reviews.llvm.org/D61634 This patch is simpler and only adds the no_builtin attribute. Reviewers: tejohnson, courbet, theraven, t.p.northover, jdoerfert Subscribers: mgrang, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68028
* [clangd] Do not insert parentheses when completing a using declarationIlya Biryukov2019-10-281-17/+16
| | | | | | | | | | | | | | | | | | Summary: Would be nice to also fix this in clang, but that looks like more work if we want to preserve signatures in informative chunks. Fixes https://github.com/clangd/clangd/issues/118 Reviewers: kadircet Reviewed By: kadircet Subscribers: merge_guards_bot, MaskRay, jkorous, arphaman, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69382
* [c++20] Enforce rule that a union-like class or class with referenceRichard Smith2019-10-271-3/+36
| | | | members cannot have defaulted comparisons.
* PR43775: don't produce a bogus 'auto' -Wc++98-compat warning for CTADRichard Smith2019-10-271-1/+1
|
* [Sema][Typo Correction] Fix another infinite loop on ambiguityDavid Goldman2019-10-251-2/+3
| | | | | | | | | | | See also: D67515 - For the given call expression we would end up repeatedly trying to transform the same expression over and over again - Fix is to keep the old TransformCache when checking for ambiguity Differential Revision: https://reviews.llvm.org/D69060
* When diagnosing an ambiguity, only note the candidates that contributeRichard Smith2019-10-244-38/+69
| | | | to the ambiguity, rather than noting all viable candidates.
* [Concepts] Constraint Enforcement & DiagnosticsSaar Raz2019-10-257-103/+490
| | | | | | Part of the C++20 concepts implementation effort. - Associated constraints (requires clauses, currently) are now enforced when instantiating/specializing templates and when considering partial specializations and function overloads. - Elaborated diagnostics give helpful insight as to why the constraints were not satisfied. Phabricator: D41569
* [clang,ARM] Initial ACLE intrinsics for MVE.Simon Tatham2019-10-243-4/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit sets up the infrastructure for auto-generating <arm_mve.h> and doing clang-side code generation for the builtins it relies on, and demonstrates that it works by implementing a representative sample of the ACLE intrinsics, more or less matching the ones introduced in LLVM IR by D67158,D68699,D68700. Like NEON, that header file will provide a set of vector types like uint16x8_t and C functions with names like vaddq_u32(). Unlike NEON, the ACLE spec for <arm_mve.h> includes a polymorphism system, so that you can write plain vaddq() and disambiguate by the vector types you pass to it. Unlike the corresponding NEON code, I've arranged to make every user- facing ACLE intrinsic into a clang builtin, and implement all the code generation inside clang. So <arm_mve.h> itself contains nothing but typedefs and function declarations, with the latter all using the new `__attribute__((__clang_builtin))` system to arrange that the user- facing function names correspond to the right internal BuiltinIDs. So the new MveEmitter tablegen system specifies the full sequence of IRBuilder operations that each user-facing ACLE intrinsic should translate into. Where possible, the ACLE intrinsics map to standard IR operations such as vector-typed `add` and `fadd`; where no standard representation exists, I call down to the sample IR intrinsics introduced in an earlier commit. Doing it like this means that you get the polymorphism for free just by using __attribute__((overloadable)): the clang overload resolution decides which function declaration is the relevant one, and _then_ its BuiltinID is looked up, so by the time we're doing code generation, that's all been resolved by the standard system. It also means that you get really nice error messages if the user passes the wrong combination of types: clang will show the declarations from the header file and explain why each one doesn't match. (The obvious alternative approach would be to have wrapper functions in <arm_mve.h> which pass their arguments to the underlying builtins. But that doesn't work in the case where one of the arguments has to be a constant integer: the wrapper function can't pass the constantness through. So you'd have to do that case using a macro instead, and then use C11 `_Generic` to handle the polymorphism. Then you have to add horrible workarounds because `_Generic` requires even the untaken branches to type-check successfully, and //then// if the user gets the types wrong, the error message is totally unreadable!) Reviewers: dmgreen, miyuki, ostannard Subscribers: mgorny, javed.absar, kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67161
* [clang] New __attribute__((__clang_arm_mve_alias)).Simon Tatham2019-10-241-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows you to declare a function with a name of your choice (say `foo`), but have clang treat it as if it were a builtin function (say `__builtin_foo`), by writing static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_foo))) int foo(args); I'm intending to use this for the ACLE intrinsics for MVE, which have to be polymorphic on their argument types and also need to be implemented by builtins. To avoid having to implement the polymorphism with several layers of nested _Generic and make error reporting hideous, I want to make all the user-facing intrinsics correspond directly to clang builtins, so that after clang resolves __attribute__((overloadable)) polymorphism it's already holding the right BuiltinID for the intrinsic it selected. However, this commit itself just introduces the new attribute, and doesn't use it for anything. To avoid unanticipated side effects if this attribute is used to make aliases to other builtins, there's a restriction mechanism: only (BuiltinID, alias) pairs that are approved by the function ArmMveAliasValid() will be permitted. At present, that function doesn't permit anything, because the Tablegen that will generate its list of valid pairs isn't yet implemented. So the only test of this facility is one that checks that an unapproved builtin _can't_ be aliased. Reviewers: dmgreen, miyuki, ostannard Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67159
* [c++2a] Allow comparison functions to be explicitly defaulted.Richard Smith2019-10-223-69/+247
| | | | | | This adds some initial syntactic checking that only the appropriate function signatures can be defaulted. No implicit definitions are generated yet.
* [HIP] Add option -fgpu-allow-device-initYaxun (Sam) Liu2019-10-221-0/+2
| | | | | | | | | | | | | | Add this option to allow device side class type global variables with non-trivial ctor/dtor. device side init/fini functions will be emitted, which will be executed by HIP runtime when the fat binary is loaded/unloaded. This feature is to facilitate implementation of device side sanitizer which requires global vars with non-trival ctors. By default this option is disabled. Differential Revision: https://reviews.llvm.org/D69268
* Minor coding style fix. NFC.Michael Liao2019-10-221-1/+2
| | | | llvm-svn: 375478
* SemaTemplateDeduction - silence static analyzer getAs<> null dereference ↵Simon Pilgrim2019-10-211-7/+3
| | | | | | | | warnings. NFCI. The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 375443
* SemaExceptionSpec - silence static analyzer getAs<> null dereference ↵Simon Pilgrim2019-10-211-4/+3
| | | | | | | | warnings. NFCI. The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 375440
* Add -Wbitwise-conditional-parentheses to warn on mixing '|' and '&' with "?:"Richard Trieu2019-10-191-2/+11
| | | | | | | | | | | | | | | | | | | | Extend -Wparentheses to cover mixing bitwise-and and bitwise-or with the conditional operator. There's two main cases seen with this: unsigned bits1 = 0xf0 | cond ? 0x4 : 0x1; unsigned bits2 = cond1 ? 0xf0 : 0x10 | cond2 ? 0x5 : 0x2; // Intended order of evaluation: unsigned bits1 = 0xf0 | (cond ? 0x4 : 0x1); unsigned bits2 = (cond1 ? 0xf0 : 0x10) | (cond2 ? 0x5 : 0x2); // Actual order of evaluation: unsigned bits1 = (0xf0 | cond) ? 0x4 : 0x1; unsigned bits2 = cond1 ? 0xf0 : ((0x10 | cond2) ? 0x5 : 0x2); Differential Revision: https://reviews.llvm.org/D66043 llvm-svn: 375326
* New tautological warning for bitwise-or with non-zero constant always true.Richard Trieu2019-10-191-6/+18
| | | | | | | | | | | | | | | | | | Taking a value and the bitwise-or it with a non-zero constant will always result in a non-zero value. In a boolean context, this is always true. if (x | 0x4) {} // always true, intended '&' This patch creates a new warning group -Wtautological-bitwise-compare for this warning. It also moves in the existing tautological bitwise comparisons into this group. A few other changes were needed to the CFGBuilder so that all bool contexts would be checked. The warnings in -Wtautological-bitwise-compare will be off by default due to using the CFG. Fixes: https://bugs.llvm.org/show_bug.cgi?id=42666 Differential Revision: https://reviews.llvm.org/D66046 llvm-svn: 375318
* Sema: Create a no-op implicit cast for lvalue function conversions.Peter Collingbourne2019-10-194-35/+50
| | | | | | | | | | This fixes an assertion failure in the case where an implicit conversion for a function call involves an lvalue function conversion, and makes the AST for initializations involving implicit lvalue function conversions more accurate. Differential Revision: https://reviews.llvm.org/D66437 llvm-svn: 375313
* [hip][cuda] Fix the extended lambda name mangling issue.Michael Liao2019-10-192-21/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - HIP/CUDA host side needs to use device kernel symbol name to match the device side binaries. Without a consistent naming between host- and device-side compilations, it's risky that wrong device binaries are executed. Consistent naming is usually not an issue until unnamed types are used, especially the lambda. In this patch, the consistent name mangling is addressed for the extended lambdas, i.e. the lambdas annotated with `__device__`. - In [Itanium C++ ABI][1], the mangling of the lambda is generally unspecified unless, in certain cases, ODR rule is required to ensure consisent naming cross TUs. The extended lambda is such a case as its name may be part of a device kernel function, e.g., the extended lambda is used as a template argument and etc. Thus, we need to force ODR for extended lambdas as they are referenced in both device- and host-side TUs. Furthermore, if a extended lambda is nested in other (extended or not) lambdas, those lambdas are required to follow ODR naming as well. This patch revises the current lambda mangle numbering to force ODR from an extended lambda to all its parent lambdas. - On the other side, the aforementioned ODR naming should not change those lambdas' original linkages, i.e., we cannot replace the original `internal` with `linkonce_odr`; otherwise, we may violate ODR in general. This patch introduces a new field `HasKnownInternalLinkage` in lambda data to decouple the current linkage calculation based on mangling number assigned. [1]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html Reviewers: tra, rsmith, yaxunl, martong, shafik Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68818 llvm-svn: 375309
* [c++20] Add rewriting from comparison operators to <=> / ==.Richard Smith2019-10-195-127/+426
| | | | | | | | | | | | | | | | | This adds support for rewriting <, >, <=, and >= to a normal or reversed call to operator<=>, for rewriting != to a normal or reversed call to operator==, and for rewriting <=> and == to reversed forms of those same operators. Note that this is a breaking change for various C++17 code patterns, including some in use in LLVM. The most common patterns (where an operator== becomes ambiguous with a reversed form of itself) are still accepted under this patch, as an extension (with a warning). I'm hopeful that we can get the language rules fixed before C++20 ships, and the extension warning is aimed primarily at providing data to inform that decision. llvm-svn: 375306
* [c++20] Add CXXRewrittenBinaryOperator to represent a comparisonRichard Smith2019-10-192-0/+35
| | | | | | | | operator that is rewritten as a call to multiple other operators. No functionality change yet: nothing creates these expressions. llvm-svn: 375305
* [OPENMP50]Add support for master taskloop simd.Alexey Bataev2019-10-182-1/+75
| | | | | | Added trsing/semantics/codegen for combined construct master taskloop simd. llvm-svn: 375255
* [ObjC] Diagnose implicit type coercion from ObjC 'Class' to objectJames Y Knight2019-10-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pointer types. For example, in Objective-C mode, the initialization of 'x' in: ``` @implementation MyType + (void)someClassMethod { MyType *x = self; } @end ``` is correctly diagnosed with an incompatible-pointer-types warning, but in Objective-C++ mode, it is not diagnosed at all -- even though incompatible pointer conversions generally become an error in C++. This patch fixes that oversight, allowing implicit conversions involving Class only to/from unqualified-id, and between qualified and unqualified Class, where the protocols are compatible. Note that this does change some behaviors in Objective-C, as well, as shown by the modified tests. Of particular note is that assignment from from 'Class<MyProtocol>' to 'id<MyProtocol>' now warns. (Despite appearances, those are not compatible types. 'Class<MyProtocol>' is not expected to have instance methods defined by 'MyProtocol', while 'id<MyProtocol>' is.) Differential Revision: https://reviews.llvm.org/D67983 llvm-svn: 375125
* SemaExprCXX - silence static analyzer getAs<> null dereference warnings. NFCI.Simon Pilgrim2019-10-171-3/+3
| | | | | | The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 375101
* SemaDeclObjC - silence static analyzer getAs<> null dereference warnings. NFCI.Simon Pilgrim2019-10-171-3/+3
| | | | | | The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 375097
* Revert Tag CFI-generated data structures with "#pragma clang section" ↵Dmitry Mikulin2019-10-171-19/+0
| | | | | | | | attributes. This reverts r375022 (git commit e2692b3bc0327606748b6d291b9009d2c845ced5) llvm-svn: 375069
* [Concepts] ConceptSpecializationExprs manglingSaar Raz2019-10-171-1/+1
| | | | | | | | | Implement mangling for CSEs to match regular template-ids. Reviewed as part of D41569 <https://reviews.llvm.org/D41569>. Re-commit fixing failing test. llvm-svn: 375063
* [OPENMP]Allow priority clause in combined task-based directives.Alexey Bataev2019-10-161-13/+10
| | | | | | | The expression of the priority clause must be captured in the combined task-based directives, like 'parallel master taskloop' directive. llvm-svn: 375026
* Tag CFI-generated data structures with "#pragma clang section" attributes.Dmitry Mikulin2019-10-161-0/+19
| | | | | | Differential Revision: https://reviews.llvm.org/D68808 llvm-svn: 375022
* Revert 374967 "[Concepts] ConceptSpecializationExprs mangling"Nico Weber2019-10-161-1/+1
| | | | | | | | | | | | | | | This reverts commit 5e34ad109ced8dbdea9500ee28180315b2aeba3d. The mangling test fails on Windows: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/15944 It also fails on ppc64le: http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/21092 Also revert follow-up 374971 "Fix failing mangle-concept.cpp test." (it did not help on Win/ppc64le). llvm-svn: 374985
* [Concepts] ConceptSpecializationExprs manglingSaar Raz2019-10-161-1/+1
| | | | | | | Implement mangling for CSEs to match regular template-ids. Reviewed as part of D41569. llvm-svn: 374967
* [OPENMP]Allow final clause in combined task-based directives.Alexey Bataev2019-10-151-3/+20
| | | | | | | The condition of the final clause must be captured in the combined task-based directives, like 'parallel master taskloop' directive. llvm-svn: 374942
* [Concept] Associated Constraints InfrastructureSaar Raz2019-10-153-61/+48
| | | | | | | Add code to correctly calculate the associated constraints of a template (no enforcement yet). D41284 on Phabricator. llvm-svn: 374938
* Added support for "#pragma clang section relro=<name>"Dmitry Mikulin2019-10-152-0/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D68806 llvm-svn: 374934
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-156-26/+257
| | | | | | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) llvm-svn: 374903
* Revert 374882 "[Concepts] Concept Specialization Expressions"Nico Weber2019-10-156-257/+26
| | | | | | | | | | This reverts commit ec87b003823d63f3342cf648f55a134c1522e612. The test fails on Windows, see e.g. http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/11533/steps/stage%201%20check/logs/stdio Also revert follow-up r374893. llvm-svn: 374899
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-156-26/+257
| | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is referenced with arguments, and tests thereof. llvm-svn: 374882
* PR43080: Do not build context-sensitive expressions during name classification.Richard Smith2019-10-143-119/+194
| | | | | | | | | | | | | | | | | | | | | | | Summary: We don't know what context to use until the classification result is consumed by the parser, which could happen in a different semantic context. So don't build the expression that results from name classification until we get to that point and can handle it properly. This covers everything except C++ implicit class member access, which is a little awkward to handle properly in the face of the protected member access check. But it at least fixes all the currently-filed instances of PR43080. Reviewers: efriedma Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68896 llvm-svn: 374826
* [OPNEMP]Allow num_tasks clause in combined task-based directives.Alexey Bataev2019-10-141-5/+14
| | | | | | | The expression of the num_tasks clause must be captured in the combined task-based directives, like 'parallel master taskloop' directive. llvm-svn: 374819
* [OPNEMP]Allow grainsize clause in combined task-based directives.Alexey Bataev2019-10-141-8/+97
| | | | | | | The expression of the grainsize clause must be captured in the combined task-based directives, like 'parallel master taskloop' directive. llvm-svn: 374810
* [OPENMP50]Add support for 'parallel master taskloop' construct.Alexey Bataev2019-10-142-1/+135
| | | | | | | | | Added parsing/sema/codegen support for 'parallel master taskloop' constructs. Some of the clauses, like 'grainsize', 'num_tasks', 'final' and 'priority' are not supported in full, only constant expressions can be used currently in these clauses. llvm-svn: 374791
* [OPENMP]Fix codegen for private variably length vars in combinedAlexey Bataev2019-10-142-1/+23
| | | | | | | | | | | constructs. If OpenMP construct includes several capturing regions and the variable is declared as private, the length of the inner variable length array is not captured in outer captured regions, only in the innermost region. Patch fixes this bug. llvm-svn: 374787
* Suppress false-positive -Wdeprecated-volatile warning from ↵Richard Smith2019-10-111-1/+7
| | | | | | __is_*_assignable(volatile T&, U). llvm-svn: 374580
* Reland r374450 with Richard Smith's comments and test fixed.Erich Keane2019-10-111-0/+6
| | | | | | | | | | The behavior from the original patch has changed, since we're no longer allowing LLVM to just ignore the alignment. Instead, we're just assuming the maximum possible alignment. Differential Revision: https://reviews.llvm.org/D68824 llvm-svn: 374562
* Fix assertion failure for a cv-qualified array as a non-type templateRichard Smith2019-10-111-4/+10
| | | | | | | | | | parameter type. We were both failing to decay the array type to a pointer and failing to remove the top-level cv-qualifications. Fix this by decaying array parameters even if the parameter type is dependent. llvm-svn: 374496
* Revert 374450 "Fix __builtin_assume_aligned with too large values."Nico Weber2019-10-101-10/+0
| | | | | | | | | | | | | The test fails on Windows, with error: 'warning' diagnostics expected but not seen: File builtin-assume-aligned.c Line 62: requested alignment must be 268435456 bytes or smaller; assumption ignored error: 'warning' diagnostics seen but not expected: File builtin-assume-aligned.c Line 62: requested alignment must be 8192 bytes or smaller; assumption ignored llvm-svn: 374456
* Fix __builtin_assume_aligned with too large values.Erich Keane2019-10-101-0/+10
| | | | | | | | | | | | | | Code to handle __builtin_assume_aligned was allowing larger values, but would convert this to unsigned along the way. This patch removes the EmitAssumeAligned overloads that take unsigned to do away with this problem. Additionally, it adds a warning that values greater than 1 <<29 are ignored by LLVM. Differential Revision: https://reviews.llvm.org/D68824 llvm-svn: 374450
* [OPENMP50]Support for 'master taskloop' directive.Alexey Bataev2019-10-102-1/+62
| | | | | | Added full support for master taskloop directive. llvm-svn: 374437
OpenPOWER on IntegriCloud