summaryrefslogtreecommitdiff
path: root/include/clang/Sema
Commit message (Collapse)AuthorAgeFilesLines
* Sema: Create a no-op implicit cast for lvalue function conversions.Peter Collingbourne2019-10-191-5/+5
| | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375313 91177308-0d34-0410-b5e6-96231b3b80d8
* [hip][cuda] Fix the extended lambda name mangling issue.Michael Liao2019-10-191-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375309 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] Add rewriting from comparison operators to <=> / ==.Richard Smith2019-10-192-28/+121
| | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375306 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP50]Add support for master taskloop simd.Alexey Bataev2019-10-181-0/+5
| | | | | | Added trsing/semantics/codegen for combined construct master taskloop simd. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@375255 91177308-0d34-0410-b5e6-96231b3b80d8
* [Concept] Associated Constraints InfrastructureSaar Raz2019-10-151-1/+7
| | | | | | | | | Add code to correctly calculate the associated constraints of a template (no enforcement yet). D41284 on Phabricator. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374938 91177308-0d34-0410-b5e6-96231b3b80d8
* Added support for "#pragma clang section relro=<name>"Dmitry Mikulin2019-10-151-1/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D68806 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374934 91177308-0d34-0410-b5e6-96231b3b80d8
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-151-4/+39
| | | | | | | | | | | | 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) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374903 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert 374882 "[Concepts] Concept Specialization Expressions"Nico Weber2019-10-151-39/+4
| | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374899 91177308-0d34-0410-b5e6-96231b3b80d8
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-151-4/+39
| | | | | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is referenced with arguments, and tests thereof. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374882 91177308-0d34-0410-b5e6-96231b3b80d8
* PR43080: Do not build context-sensitive expressions during name classification.Richard Smith2019-10-141-17/+78
| | | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374826 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP50]Add support for 'parallel master taskloop' construct.Alexey Bataev2019-10-141-0/+5
| | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374791 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP]Fix codegen for private variably length vars in combinedAlexey Bataev2019-10-141-0/+4
| | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374787 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP50]Support for 'master taskloop' directive.Alexey Bataev2019-10-101-0/+5
| | | | | | Added full support for master taskloop directive. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374437 91177308-0d34-0410-b5e6-96231b3b80d8
* [sema] Revise `getCurrentMangleNumberContext` interface. NFC.Michael Liao2019-10-101-6/+4
| | | | | | | - Prefer returning mulitple values using a tuple instead of additional pointers/references. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374274 91177308-0d34-0410-b5e6-96231b3b80d8
* Re-land [mangle] Fix mangling where an extra mangle context is required.Reid Kleckner2019-10-101-13/+1
| | | | | | | | | | | This reverts r374268 (git commit c34385d07c7d59447bf836b740f032235391d121) I think I reverted this by mistake, so I'm relanding it. While my bisect found this revision, I think the crashes I'm seeing locally must be environmental. Maybe the version of clang I'm using miscompiles tot clang. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374269 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert [mangle] Fix mangling where an extra mangle context is required.Reid Kleckner2019-10-101-1/+13
| | | | | | | | This reverts r374200 (git commit fd18e94697c987d5f24e25aa4e27adaffff3cce4) Causes crashes just compiling `int main() {}` on my machine. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374268 91177308-0d34-0410-b5e6-96231b3b80d8
* [CUDA][HIP] Fix host/device check with -fopenmpYaxun Liu2019-10-091-0/+13
| | | | | | | | | | | | | | | | | CUDA/HIP program may be compiled with -fopenmp. In this case, -fopenmp is only passed to host compilation to take advantages of multi-threads computation. CUDA/HIP and OpenMP both use Sema::DeviceCallGraph to store functions to be analyzed and remove them once they decide the function is sure to be emitted. CUDA/HIP and OpenMP have different functions to determine if a function is sure to be emitted. To check host/device correctly for CUDA/HIP when -fopenmp is enabled, there needs a unified logic to determine whether a function is to be emitted. The logic needs to be aware of both CUDA and OpenMP logic. Differential Revision: https://reviews.llvm.org/D67837 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374263 91177308-0d34-0410-b5e6-96231b3b80d8
* [mangle] Fix mangling where an extra mangle context is required.Michael Liao2019-10-091-13/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - [Itanium C++ ABI][1], for certain contexts like default parameter and etc., mangling numbering will be local to the particular argument in which it appears. - However, for these cases, the mangle numbering context is allocated per expression evaluation stack entry. That causes, for example, two lambdas defined/used understand the same default parameter are numbered as the same value and, in turn, one of them is not generated at all. - In this patch, an extra mangle numbering context map is maintained in the AST context to map taht extra declaration context to its numbering context. So that, 2 different lambdas defined/used in the same default parameter are numbered differently. [1]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html Reviewers: rsmith, eli.friedman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68715 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374200 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] P1152R4: warn on any simple-assignment to a volatile lvalueRichard Smith2019-10-091-0/+8
| | | | | | | | | | | | whose value is not ignored. We don't warn on all the cases that are deprecated: specifically, we choose to not warn for now if there are parentheses around the assignment but its value is not actually used. This seems like a more defensible rule, particularly for cases like sizeof(v = a), where the parens are part of the operand rather than the sizeof syntax. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374135 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP50]Multiple vendors in vendor context must be treated as logicalAlexey Bataev2019-10-081-5/+5
| | | | | | | | | | | | | and of vendors, not or. If several vendors are provided in the same vendor context trait, the context shall match only if all vendors are matching, not one of them. This is per OpenMP 5.0, 2.3.3 Matching and Scoring Context Selectors, all selectors in the construct, device, and implementation sets of the context selector appear in the corresponding trait set of the OpenMP context. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374107 91177308-0d34-0410-b5e6-96231b3b80d8
* [BPF] do compile-once run-everywhere relocation for bitfieldsYonghong Song2019-10-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A bpf specific clang intrinsic is introduced: u32 __builtin_preserve_field_info(member_access, info_kind) Depending on info_kind, different information will be returned to the program. A relocation is also recorded for this builtin so that bpf loader can patch the instruction on the target host. This clang intrinsic is used to get certain information to facilitate struct/union member relocations. The offset relocation is extended by 4 bytes to include relocation kind. Currently supported relocation kinds are enum { FIELD_BYTE_OFFSET = 0, FIELD_BYTE_SIZE, FIELD_EXISTENCE, FIELD_SIGNEDNESS, FIELD_LSHIFT_U64, FIELD_RSHIFT_U64, }; for __builtin_preserve_field_info. The old access offset relocation is covered by FIELD_BYTE_OFFSET = 0. An example: struct s { int a; int b1:9; int b2:4; }; enum { FIELD_BYTE_OFFSET = 0, FIELD_BYTE_SIZE, FIELD_EXISTENCE, FIELD_SIGNEDNESS, FIELD_LSHIFT_U64, FIELD_RSHIFT_U64, }; void bpf_probe_read(void *, unsigned, const void *); int field_read(struct s *arg) { unsigned long long ull = 0; unsigned offset = __builtin_preserve_field_info(arg->b2, FIELD_BYTE_OFFSET); unsigned size = __builtin_preserve_field_info(arg->b2, FIELD_BYTE_SIZE); #ifdef USE_PROBE_READ bpf_probe_read(&ull, size, (const void *)arg + offset); unsigned lshift = __builtin_preserve_field_info(arg->b2, FIELD_LSHIFT_U64); #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ lshift = lshift + (size << 3) - 64; #endif #else switch(size) { case 1: ull = *(unsigned char *)((void *)arg + offset); break; case 2: ull = *(unsigned short *)((void *)arg + offset); break; case 4: ull = *(unsigned int *)((void *)arg + offset); break; case 8: ull = *(unsigned long long *)((void *)arg + offset); break; } unsigned lshift = __builtin_preserve_field_info(arg->b2, FIELD_LSHIFT_U64); #endif ull <<= lshift; if (__builtin_preserve_field_info(arg->b2, FIELD_SIGNEDNESS)) return (long long)ull >> __builtin_preserve_field_info(arg->b2, FIELD_RSHIFT_U64); return ull >> __builtin_preserve_field_info(arg->b2, FIELD_RSHIFT_U64); } There is a minor overhead for bpf_probe_read() on big endian. The code and relocation generated for field_read where bpf_probe_read() is used to access argument data on little endian mode: r3 = r1 r1 = 0 r1 = 4 <=== relocation (FIELD_BYTE_OFFSET) r3 += r1 r1 = r10 r1 += -8 r2 = 4 <=== relocation (FIELD_BYTE_SIZE) call bpf_probe_read r2 = 51 <=== relocation (FIELD_LSHIFT_U64) r1 = *(u64 *)(r10 - 8) r1 <<= r2 r2 = 60 <=== relocation (FIELD_RSHIFT_U64) r0 = r1 r0 >>= r2 r3 = 1 <=== relocation (FIELD_SIGNEDNESS) if r3 == 0 goto LBB0_2 r1 s>>= r2 r0 = r1 LBB0_2: exit Compare to the above code between relocations FIELD_LSHIFT_U64 and FIELD_LSHIFT_U64, the code with big endian mode has four more instructions. r1 = 41 <=== relocation (FIELD_LSHIFT_U64) r6 += r1 r6 += -64 r6 <<= 32 r6 >>= 32 r1 = *(u64 *)(r10 - 8) r1 <<= r6 r2 = 60 <=== relocation (FIELD_RSHIFT_U64) The code and relocation generated when using direct load. r2 = 0 r3 = 4 r4 = 4 if r4 s> 3 goto LBB0_3 if r4 == 1 goto LBB0_5 if r4 == 2 goto LBB0_6 goto LBB0_9 LBB0_6: # %sw.bb1 r1 += r3 r2 = *(u16 *)(r1 + 0) goto LBB0_9 LBB0_3: # %entry if r4 == 4 goto LBB0_7 if r4 == 8 goto LBB0_8 goto LBB0_9 LBB0_8: # %sw.bb9 r1 += r3 r2 = *(u64 *)(r1 + 0) goto LBB0_9 LBB0_5: # %sw.bb r1 += r3 r2 = *(u8 *)(r1 + 0) goto LBB0_9 LBB0_7: # %sw.bb5 r1 += r3 r2 = *(u32 *)(r1 + 0) LBB0_9: # %sw.epilog r1 = 51 r2 <<= r1 r1 = 60 r0 = r2 r0 >>= r1 r3 = 1 if r3 == 0 goto LBB0_11 r2 s>>= r1 r0 = r2 LBB0_11: # %sw.epilog exit Considering verifier is able to do limited constant propogation following branches. The following is the code actually traversed. r2 = 0 r3 = 4 <=== relocation r4 = 4 <=== relocation if r4 s> 3 goto LBB0_3 LBB0_3: # %entry if r4 == 4 goto LBB0_7 LBB0_7: # %sw.bb5 r1 += r3 r2 = *(u32 *)(r1 + 0) LBB0_9: # %sw.epilog r1 = 51 <=== relocation r2 <<= r1 r1 = 60 <=== relocation r0 = r2 r0 >>= r1 r3 = 1 if r3 == 0 goto LBB0_11 r2 s>>= r1 r0 = r2 LBB0_11: # %sw.epilog exit For native load case, the load size is calculated to be the same as the size of load width LLVM otherwise used to load the value which is then used to extract the bitfield value. Differential Revision: https://reviews.llvm.org/D67980 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374099 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP50]Allow functions in declare variant directive to have differentAlexey Bataev2019-10-081-1/+1
| | | | | | | | | | C linkage. After some discussion with OpenMP developers, it was decided that the functions with the different C linkage can be used in declare variant directive. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374057 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP50]Treat range-based for as canonical loop.Alexey Bataev2019-10-071-0/+4
| | | | | | | According to OpenMP 5.0, range-based for is also considered as a canonical form of loops. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373939 91177308-0d34-0410-b5e6-96231b3b80d8
* OverloadCandidate::getNumParams - silence static analyzer ↵Simon Pilgrim2019-10-031-2/+2
| | | | | | | | | | getAs<FunctionProtoType> null dereference warning. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use castAs<FunctionProtoType> directly and if not assert will fire for us. Also replaces an auto to make the type more obvious. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373665 91177308-0d34-0410-b5e6-96231b3b80d8
* Check for qualified function types after substituting into the operandRichard Smith2019-10-031-0/+2
| | | | | | | | | | of 'typeid'. This is a rare place where it's valid for a function type to be substituted but not valid for a qualified function type to be substituted, so needs a special check. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373648 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP50]Add parsing/sema analysis for declare variant score.Alexey Bataev2019-10-021-2/+5
| | | | | | | | Context selectors may include optional score clause in format `score(<expr>):`, where `<expr>` must be a constant integer expression. Added parsing/sema analysis only. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373502 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP50]Parsing/sema support for 'implementation/vendor' contextAlexey Bataev2019-09-251-6/+22
| | | | | | | | | selector. Added basic parsing/semantic support for 'implementation={vendor(<vendor>)}' context selector. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372917 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sema] Fix the atomic expr rebuilding order.Michael Liao2019-09-231-3/+6
| | | | | | | | | | | | | | | | Summary: - Rearrange the atomic expr order to the API order when rebuilding atomic expr during template instantiation. Reviewers: erichkeane Subscribers: jfb, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67924 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372640 91177308-0d34-0410-b5e6-96231b3b80d8
* Ensure AtomicExpr goes through SEMA checking after TreeTransformErich Keane2019-09-201-0/+3
| | | | | | | | | | | RebuildAtomicExpr was skipping doing semantic analysis which broke in the cases where the expressions were not dependent. This resulted in the ImplicitCastExpr from an array to a pointer being lost, causing a crash in IR CodeGen. Differential Revision: https://reviews.llvm.org/D67854 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372422 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP5.0]Allow multiple context selectors in the context selectorAlexey Bataev2019-09-181-4/+15
| | | | | | | | | sets. According to OpenMP 5.0, context selector set might include several context selectors, separated with commas. Patch fixes this problem. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372235 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP5.0]Introduce attribute for declare variant directive.Alexey Bataev2019-09-171-0/+6
| | | | | | | | Added attribute for declare variant directive. It will allow to handle declare variant directive at the codegen and will allow to add extra checks. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372147 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP5.0]Add basic support for declare variant directive.Alexey Bataev2019-09-131-0/+19
| | | | | | | Added basic support for declare variant directive and its match clause with user context selector. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371892 91177308-0d34-0410-b5e6-96231b3b80d8
* [NFCI]Create CommonAttributeInfo Type as base type of *Attr and ParsedAttr.Erich Keane2019-09-132-201/+114
| | | | | | | | | | | | In order to enable future improvements to our attribute diagnostics, this moves info from ParsedAttr into CommonAttributeInfo, then makes this type the base of the *Attr and ParsedAttr types. Quite a bit of refactoring took place, including removing a bunch of redundant Spelling Index propogation. Differential Revision: https://reviews.llvm.org/D67368 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371875 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sema] Diagnose default-initialization, destruction, and copying ofAkira Hatanaka2019-09-071-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371275 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] Add support for designated direct-list-initialization syntax.Richard Smith2019-08-311-1/+1
| | | | | | This completes the implementation of P0329R4. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@370558 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] Implement semantic restrictions for C++20 designatedRichard Smith2019-08-301-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@370544 91177308-0d34-0410-b5e6-96231b3b80d8
* PR42587: diagnose unexpanded uses of a pack parameter of a genericRichard Smith2019-08-262-0/+8
| | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@369985 91177308-0d34-0410-b5e6-96231b3b80d8
* Improve behavior in the case of stack exhaustion.Richard Smith2019-08-261-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@369940 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP5.0]Add support for device_type clause in declare targetAlexey Bataev2019-08-231-3/+31
| | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@369775 91177308-0d34-0410-b5e6-96231b3b80d8
* [OpenMP] Permit map with DSA on combined directiveJoel E. Denny2019-08-222-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@369619 91177308-0d34-0410-b5e6-96231b3b80d8
* [OPENMP]Fix delayed diagnostics for standalone declare target directive.Alexey Bataev2019-08-201-1/+2
| | | | | | | If the function is marked as declare target in a standalone directive, the delayed diagnostics is not emitted. Patch fixes this problem. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@369432 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sema][Typo] Fix assertion failure for expressions with multiple typosDavid Goldman2019-08-201-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@369427 91177308-0d34-0410-b5e6-96231b3b80d8
* Replace llvm::integer_sequence and friends with the C++14 standard versionBenjamin Kramer2019-08-151-2/+2
| | | | | | The implementation in libc++ takes O(1) compile time, ours was O(n). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@368990 91177308-0d34-0410-b5e6-96231b3b80d8
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-142-5/+5
| | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@368942 91177308-0d34-0410-b5e6-96231b3b80d8
* gsl::Owner/gsl::Pointer: Add implicit annotations for some std typesMatthias Gehre2019-08-071-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Hard code gsl::Owner/gsl::Pointer for std types. The paper mentions some types explicitly. Generally, all containers and their iterators are covered. For iterators, we cover both the case that they are defined as an nested class or as an typedef/using. I have started to test this implementation against some real standard library implementations, namely libc++ 7.1.0, libc++ 8.0.1rc2, libstdc++ 4.6.4, libstdc++ 4.8.5, libstdc++ 4.9.4, libstdc++ 5.4.0, libstdc++ 6.5.0, libstdc++ 7.3.0, libstdc++ 8.3.0 and libstdc++ 9.1.0. The tests are currently here https://github.com/mgehre/llvm-project/blob/lifetime-ci/lifetime-attr-test.sh https://github.com/mgehre/llvm-project/blob/lifetime-ci/lifetime-attr-test.cpp I think due to their dependency on a standard library, they are not a good fit for clang/test/. Where else could I put them? Reviewers: gribozavr, xazax.hun Subscribers: rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64448 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@368147 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sema] Add -Wpointer-compareGeorge Burgess IV2019-08-051-0/+1
| | | | | | | | | | | | This patch adds a warning that diagnoses comparisons of pointers to '\0'. This is often indicative of a bug (e.g. the user might've forgotten to dereference the pointer). Patch by Elaina Guan! Differential Revision: https://reviews.llvm.org/D65595 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@367940 91177308-0d34-0410-b5e6-96231b3b80d8
* Delay emitting dllexport explicitly defaulted members until the class is ↵Hans Wennborg2019-08-011-0/+1
| | | | | | | | | | | | | | | | | | | | fully parsed (PR40006) This is similar to r245139, but that only addressed dllexported classes. It was still possible to run into the same problem with dllexported members in an otherwise normal class (see bug). This uses the same strategy to fix: delay defining the method until the whole class has been parsed. (The easiest way to see the ordering problem is in Parser::ParseCXXMemberSpecification(): it calls ParseLexedMemberInitializers() *after* ActOnFinishCXXMemberDecls(), which was trying to define the dllexport method. Now we delay it to ActOnFinishCXXNonNestedClass() which is called after both of those.) Differential revision: https://reviews.llvm.org/D65511 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@367520 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sema] Actually map a variable template specialization from pattern to ↵Erik Pilkington2019-07-301-0/+5
| | | | | | | | | | | | | instantiation We were previously just using a specialization in the class template instead of creating a new specialization in the class instantiation. Fixes llvm.org/PR42779. Differential revision: https://reviews.llvm.org/D65359 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@367367 91177308-0d34-0410-b5e6-96231b3b80d8
* [NFC] avoid AlignedCharArray in clangJF Bastien2019-07-291-2/+2
| | | | | | As discussed in D65249, don't use AlignedCharArray or std::aligned_storage. Just use alignas(X) char Buf[Size];. This will allow me to remove AlignedCharArray entirely, and works on the current minimum version of Visual Studio. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@367274 91177308-0d34-0410-b5e6-96231b3b80d8
* When determining whether a lambda-expression is implicitly constexpr,Richard Smith2019-07-291-2/+10
| | | | | | | | | | | | check the formal rules rather than seeing if the normal checks produce a diagnostic. This fixes the handling of C++2a extensions in lambdas in C++17 mode, as well as some corner cases in earlier language modes where we issue diagnostics for things other than not satisfying the formal constexpr requirements. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@367254 91177308-0d34-0410-b5e6-96231b3b80d8
View Lorry Controller Status