summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/TreeTransform.h
Commit message (Collapse)AuthorAgeFilesLines
* Don't lose the FoundDecl and template arguments for a DeclRefExpr inRichard Smith2019-08-271-5/+12
| | | | | | TreeTransform. llvm-svn: 369999
* [OpenCL][PR42033] Fix addr space deduction with template parametersAnastasia Stulova2019-07-181-7/+0
| | | | | | | | | | | | | | | If dependent types appear in pointers or references we allow addr space deduction because the addr space in template argument will belong to the pointee and not the pointer or reference itself. We also don't diagnose addr space on a function return type after template instantiation. If any addr space for the return type was provided on a template parameter this will be diagnosed during the parsing of template definition. Differential Revision: https://reviews.llvm.org/D62584 llvm-svn: 366417
* [OpenCL] Deduce addr space for pointee of dependent types in instantiation.Anastasia Stulova2019-07-151-0/+17
| | | | | | | | | | Since pointee doesn't require context sensitive addr space deduction it's easier to handle pointee of dependent types during templ instantiation. Differential Revision: https://reviews.llvm.org/D64400 llvm-svn: 366063
* Ignore trailing NullStmts in StmtExprs for GCC compatibility.Aaron Ballman2019-07-091-2/+2
| | | | | | | | Ignore trailing NullStmts in compound expressions when determining the result type and value. This is to match the GCC behavior which ignores semicolons at the end of compound expressions. Patch by Dominic Ferreira. llvm-svn: 365498
* [C++2a] Add __builtin_bit_cast, used to implement std::bit_castErik Pilkington2019-07-021-0/+26
| | | | | | | | | | | | | | | | | | This commit adds a new builtin, __builtin_bit_cast(T, v), which performs a bit_cast from a value v to a type T. This expression can be evaluated at compile time under specific circumstances. The compile time evaluation currently doesn't support bit-fields, but I'm planning on fixing this in a follow up (some of the logic for figuring this out is in CodeGen). I'm also planning follow-ups for supporting some more esoteric types that the constexpr evaluator supports, as well as extending __builtin_memcpy constexpr evaluation to use the same infrastructure. rdar://44987528 Differential revision: https://reviews.llvm.org/D62825 llvm-svn: 364954
* Remove redundant expression evaluation context when substituting into aRichard Smith2019-06-251-7/+5
| | | | | | | | template argument. We do need one of these but we don't need two. llvm-svn: 364347
* [C++20] add Basic consteval specifierGauthier Harnisch2019-06-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: this revision adds Lexing, Parsing and Basic Semantic for the consteval specifier as specified by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1073r3.html with this patch, the consteval specifier is treated as constexpr but can only be applied to function declaration. Changes: - add the consteval keyword. - add parsing of consteval specifier for normal declarations and lambdas expressions. - add the whether a declaration is constexpr is now represented by and enum everywhere except for variable because they can't be consteval. - adapt diagnostic about constexpr to print constexpr or consteval depending on the case. - add tests for basic semantic. Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: eraman, efriedma, rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61790 llvm-svn: 363362
* PR42104: Support instantiations of lambdas that implicitly captureRichard Smith2019-06-041-12/+51
| | | | | | | | | | | | | | | | | packs. Two changes: * Track odr-use via FunctionParmPackExprs to properly handle dependent odr-uses of packs in generic lambdas. * Do not instantiate implicit captures; instead, regenerate them by instantiating the body of the lambda. This is necessary to distinguish between cases where only one element of a pack is captured and cases where the entire pack is captured. This reinstates r362358 (reverted in r362375) with a fix for an uninitialized variable use in UpdateMarkingForLValueToRValue. llvm-svn: 362531
* Re-check in clang support gun asm goto after fixing tests.Jennifer Yu2019-06-031-2/+14
| | | | llvm-svn: 362410
* Revert rL362358 : PR42104: Support instantiations of lambdas that implicitly ↵Simon Pilgrim2019-06-031-51/+12
| | | | | | | | | | | | | | | | capture packs. Two changes: * Track odr-use via FunctionParmPackExprs to properly handle dependent odr-uses of packs in generic lambdas. * Do not instantiate implicit captures; instead, regenerate them by instantiating the body of the lambda. This is necessary to distinguish between cases where only one element of a pack is captured and cases where the entire pack is captured. ........ Fixes http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win buildbot failures llvm-svn: 362375
* PR42104: Support instantiations of lambdas that implicitly captureRichard Smith2019-06-031-12/+51
| | | | | | | | | | | | | | packs. Two changes: * Track odr-use via FunctionParmPackExprs to properly handle dependent odr-uses of packs in generic lambdas. * Do not instantiate implicit captures; instead, regenerate them by instantiating the body of the lambda. This is necessary to distinguish between cases where only one element of a pack is captured and cases where the entire pack is captured. llvm-svn: 362358
* [coroutines][PR41909] Don't build dependent coroutine statements for generic ↵Brian Gesiak2019-06-031-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lambda Summary: https://bugs.llvm.org/show_bug.cgi?id=41909 describes an issue in which a generic lambda that takes a dependent argument `auto set` causes the template instantiation machinery for coroutine body statements to crash with an ICE. The issue is two-fold: 1. The paths taken by the template instantiator contain several asserts that the coroutine promise must not have a dependent type. 2. The template instantiator unconditionally builds corotuine statements that depend on the promise type, which cannot be dependent. To work around the issue, prevent the template instantiator from building dependent coroutine statements if the coroutine promise type is dependent. Since we only expect this to occur in the case of a generic lambda, limit the workaround behavior to just that case. Reviewers: GorNishanov, EricWF, lewissbaker, tks2103 Reviewed By: GorNishanov Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62550 llvm-svn: 362348
* Transform lambda expression captures when transforming an expression toRichard Smith2019-06-021-5/+23
| | | | | | | | | potentially-evaluated. This ensures that every potentially-evaluated expression is built in a potentially-evaluated context. No functionality change intended. llvm-svn: 362336
* Revert "clang support gnu asm goto."Erich Keane2019-05-301-14/+2
| | | | | | | | | | | This reverts commit 954ec09aed4f2be04bb5f4e10dbb4ea8bd19ef9a. Reverting due to test failures as requested by Jennifer Yu. Conflicts: clang/test/CodeGen/asm-goto.c llvm-svn: 362106
* clang support gnu asm goto.Jennifer Yu2019-05-301-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Syntax: asm [volatile] goto ( AssemblerTemplate : : InputOperands : Clobbers : GotoLabels) https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html New llvm IR is "callbr" for inline asm goto instead "call" for inline asm For: asm goto("testl %0, %0; jne %l1;" :: "r"(cond)::label_true, loop); IR: callbr void asm sideeffect "testl $0, $0; jne ${1:l};", "r,X,X,~{dirflag},~{fpsr},~{flags}"(i32 %0, i8* blockaddress(@foo, %label_true), i8* blockaddress(@foo, %loop)) #1 to label %asm.fallthrough [label %label_true, label %loop], !srcloc !3 asm.fallthrough: Compiler need to generate: 1> a dummy constarint 'X' for each label. 2> an unique fallthrough label for each asm goto stmt " asm.fallthrough%number". Diagnostic 1> duplicate asm operand name are used in output, input and label. 2> goto out of scope. llvm-svn: 362045
* Defer creating fields for captures until we finish building theRichard Smith2019-05-281-1/+1
| | | | | | | | | | | | | | | capturing expression or statement. No functionality change yet. The intent is that we will also delay building the initialization expression until the enclosing context, so that: a) we build the initialization expression in the right context, and b) we can elide captures that are not odr-used, as suggested by P0588R1. This also consolidates some duplicated code building capture fields into a single place. llvm-svn: 361893
* Factor out repeated code to build 'this' expressions and mark themRichard Smith2019-05-241-4/+4
| | | | | | referenced. llvm-svn: 361588
* [c++20] P0780R2: Support pack-expansion of init-captures.Richard Smith2019-05-211-43/+100
| | | | | | | | | | | This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
* Implement __builtin_LINE() et. al. to support source location capture.Eric Fiselier2019-05-161-7/+34
| | | | | | | | | | | | | | | | | Summary: This patch implements the source location builtins `__builtin_LINE(), `__builtin_FUNCTION()`, `__builtin_FILE()` and `__builtin_COLUMN()`. These builtins are needed to implement [`std::experimental::source_location`](https://rawgit.com/cplusplus/fundamentals-ts/v2/main.html#reflection.src_loc.creation). With the exception of `__builtin_COLUMN`, GCC also implements these builtins, and Clangs behavior is intended to match as closely as possible. Reviewers: rsmith, joerg, aaron.ballman, bogner, majnemer, shafik, martong Reviewed By: rsmith Subscribers: rnkovacs, loskutov, riccibruno, mgorny, kunitoki, alexr, majnemer, hfinkel, cfe-commits Differential Revision: https://reviews.llvm.org/D37035 llvm-svn: 360937
* PR41845: Detect and reject mismatched inner/outer pack expansion sizesRichard Smith2019-05-131-7/+10
| | | | | | in fold expressions rather than crashing. llvm-svn: 360563
* Split ActOnCallExpr into an ActOnCallExpr to be called by the parser,Richard Smith2019-05-081-2/+2
| | | | | | | and a BuildCallExpr to be called internally within Sema to build / rebuild calls. llvm-svn: 360217
* Recommit r359859 "[Attribute/Diagnostics] Print macro if definition is an ↵Leonard Chan2019-05-071-0/+27
| | | | | | | | attribute declaration" Updated with fix for read of uninitialized memory. llvm-svn: 360109
* [c++20] Implement P1009R2: allow omitting the array bound in an arrayRichard Smith2019-05-061-7/+14
| | | | | | | | | | new expression. This was voted into C++20 as a defect report resolution, so we retroactively apply it to all prior language modes (though it can never actually be used before C++11 mode). llvm-svn: 360006
* Revert "[Attribute/Diagnostics] Print macro if definition is an attribute ↵Leonard Chan2019-05-031-27/+0
| | | | | | | | declaration" This reverts commit fc40cbd9d8c63e65eed3590ba925321afe782e1d. llvm-svn: 359859
* [Attribute/Diagnostics] Print macro if definition is an attribute declarationLeonard Chan2019-05-021-0/+27
| | | | | | | | | | | | | If an address_space attribute is defined in a macro, print the macro instead when diagnosing a warning or error for incompatible pointers with different address_spaces. We allow this for all attributes (not just address_space), and for multiple attributes declared in the same macro. Differential Revision: https://reviews.llvm.org/D51329 llvm-svn: 359826
* [OPENMP]Initial support for 'allocate' clause.Alexey Bataev2019-03-271-0/+36
| | | | | | Added parsing/sema analysis of the allocate clause. llvm-svn: 357068
* [OPENMP 5.0]Initial support for 'allocator' clause.Alexey Bataev2019-03-121-0/+20
| | | | | | | Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
* [clang][OpenMP] Revert "OMPFlushClause is synthetic, no such clause exists"Roman Lebedev2019-03-061-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This reverts rL352390 / D57280. As discussed in https://reviews.llvm.org/D57112#inline-506781, 'flush' clause does not exist in the OpenMP spec, it can not be specified, and `OMPFlushClause` class is just a helper class. Now, here's the caveat. I have read @ABataev's > Well, I think it would be good to filter out OMPC_flush somehow > because there is no such clause actually, it is a pseudo clause > for better handling of the flush directive. as if that clause is pseudo clause that only exists for the sole purpose of simplifying the parser. As in, it never reaches AST. I did not however try to verify that. Too bad, i was wrong. It absolutely *does* reach AST. Therefore my understanding/justification for the change was flawed, which makes the patch a regression which **must** be reverted. @gribozavr has brought that up again in https://reviews.llvm.org/D57112#inline-521238 > > ... > Sorry to be late for this discussion, but I don't think this conclusion > follows. ASTMatchers are supposed to match the AST as it is. > Even if OMPC_flush is synthetic, it exists in the AST, and users might > want to match it. I think users would find anything else (trying to filter > out AST nodes that are not in the source code) to be surprising. For example, > there's a matcher materializeTemporaryExpr even though this AST node is a > Clang invention and is not a part of the C++ spec. > > Matching only constructs that appear in the source code is not feasible with > ASTMatchers, because they are based on Clang's AST that exposes tons of semantic > information, and its design is dictated by the structure of the semantic information. > See "RFC: Tree-based refactorings with Clang" in cfe-dev for a library that will > focus on representing source code as faithfully as possible. > > Not to even mention that this code is in ASTTypeTraits, a general library for > handling AST nodes, not specifically for AST Matchers... Reviewers: gribozavr, ABataev, rjmccall, aaron.ballman Reviewed By: gribozavr, ABataev Subscribers: dylanmckay, guansong, arphaman, jdoerfert, cfe-commits, gribozavr, ABataev Tags: #clang, #openmp Differential Revision: https://reviews.llvm.org/D58979 llvm-svn: 355486
* [OpenMP 5.0] Parsing/sema support for from clause with mapper modifier.Michael Kruse2019-02-251-11/+15
| | | | | | | | | | | | | | | | | | | | This patch implements the parsing and sema support for the OpenMP 'from'-clause with potential user-defined mappers attached. User-defined mappers are a new feature in OpenMP 5.0. A 'from'-clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update from(mapper(id): ss) // use the mapper with name 'id' to map ss from device Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58638 llvm-svn: 354817
* [OpenMP 5.0] Parsing/sema support for to clause with mapper modifier.Michael Kruse2019-02-221-27/+47
| | | | | | | | | | | | | | | | | | | This patch implements the parsing and sema support for OpenMP to clause with potential user-defined mappers attached. User defined mapper is a new feature in OpenMP 5.0. A to/from clause can have an explicit or implicit associated mapper, which instructs the compiler to generate and use customized mapping functions. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target update to(mapper(id): ss) // use the mapper with name 'id' to map ss to device Contributed-by: <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58523 llvm-svn: 354698
* [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier.Michael Kruse2019-02-191-40/+66
| | | | | | | | | | | | | | | | | | | This patch implements the parsing and sema support for OpenMP map clauses with potential user-defined mapper attached. User defined mapper is a new feature in OpenMP 5.0. A map clause can have an explicit or implicit associated mapper, which instructs the compiler to generate extra data mapping. An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(id: struct S s) map(s, s.d[0:s.len]) struct S ss; #pragma omp target map(mapper(id) tofrom: ss) // use the mapper with name 'id' to map ss Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D58074 llvm-svn: 354347
* PR40642: Fix determination of whether the final statement of a statementRichard Smith2019-02-151-17/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | expression is a discarded-value expression. Summary: We used to get this wrong in three ways: 1) During parsing, an expression-statement followed by the }) ending a statement expression was always treated as producing the value of the statement expression. That's wrong for ({ if (1) expr; }) 2) During template instantiation, various kinds of statement (most statements not appearing directly in a compound-statement) were not treated as discarded-value expressions, resulting in missing volatile loads (etc). 3) In all contexts, an expression-statement with attributes was not treated as producing the value of the statement expression, eg ({ [[attr]] expr; }). Also fix incorrect enforcement of OpenMP rule that directives can "only be placed in the program at a position where ignoring or deleting the directive would result in a program with correct syntax". In particular, a label (be it goto, case, or default) should not affect whether directives are permitted. Reviewers: aaron.ballman, rjmccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57984 llvm-svn: 354090
* Re-commit "[AST] Introduce GenericSelectionExpr::Association"Bruno Ricci2019-01-291-5/+6
| | | | | | This time with a fix to make gcc 4.8 happy. llvm-svn: 352486
* Revert "[AST] Introduce GenericSelectionExpr::Association"Bruno Ricci2019-01-281-6/+5
| | | | | | This breaks GCC 4.8.4. Reported by email by Hans Wennborg. llvm-svn: 352403
* [clang][OpenMP] OMPFlushClause is synthetic, no such clause existsRoman Lebedev2019-01-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As discussed in https://reviews.llvm.org/D57112#inline-506781, 'flush' clause does not exist in the OpenMP spec, it can not be specified, and `OMPFlushClause` class is just a helper class. Therefore `OPENMP_CLAUSE()` in `clang/Basic/OpenMPKinds.def` should not contain 'flush' "clause". I have simply removed the `OPENMP_CLAUSE(flush, OMPFlushClause)` from `clang/Basic/OpenMPKinds.def`, grepped for `OPENMP_CLAUSE` and added `OPENMP_CLAUSE(flush, OMPFlushClause)` back to the **every** place where `OPENMP_CLAUSE` is defined and `clang/Basic/OpenMPKinds.def` is then included. So as-is, this patch is a NFC. Possibly, some of these `OPENMP_CLAUSE(flush, OMPFlushClause)` should be dropped, i don't really know. Test plan: `ninja check-clang` Reviewers: ABataev Reviewed By: ABataev Subscribers: guansong, arphaman, cfe-commits Tags: #openmp Differential Revision: https://reviews.llvm.org/D57280 llvm-svn: 352390
* [AST] Introduce GenericSelectionExpr::AssociationBruno Ricci2019-01-281-5/+6
| | | | | | | | | | | | | | | | | Introduce a new class GenericSelectionExpr::Association which bundle together an association expression and its TypeSourceInfo. An iterator GenericSelectionExpr::AssociationIterator is additionally added to make it possible to iterate over ranges of Associations. This iterator is a kind of proxy iterator which abstract over how exactly the expressions and the TypeSourceInfos are stored. Differential Revision: https://reviews.llvm.org/D57106 Reviewed By: aaron.ballman Reviewers: aaron.ballman, steveire, dblaikie, mclow.lists llvm-svn: 352369
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Refactor the way we handle diagnosing unused expression results.Aaron Ballman2019-01-041-6/+9
| | | | | | | | Rather than sprinkle calls to DiagnoseUnusedExprResult() around in places where we want diagnostics, we now diagnose unused expression statements and full expressions in a more generic way when acting on the final expression statement. This results in more appropriate diagnostics for [[nodiscard]] where we were previously lacking them, such as when the body of a for loop is not a compound statement. This patch fixes PR39837. llvm-svn: 350404
* [AST] Store the callee and argument expressions of CallExpr in a trailing array.Bruno Ricci2018-12-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since CallExpr::setNumArgs has been removed, it is now possible to store the callee expression and the argument expressions of CallExpr in a trailing array. This saves one pointer per CallExpr, CXXOperatorCallExpr, CXXMemberCallExpr, CUDAKernelCallExpr and UserDefinedLiteral. Given that CallExpr is used as a base of the above classes we cannot use llvm::TrailingObjects. Instead we store the offset in bytes from the this pointer to the start of the trailing objects and manually do the casts + arithmetic. Some notes: 1.) I did not try to fit the number of arguments in the bit-fields of Stmt. This leaves some space for future additions and avoid the discussion about whether x bits are sufficient to hold the number of arguments. 2.) It would be perfectly possible to recompute the offset to the trailing objects before accessing the trailing objects. However the trailing objects are frequently accessed and benchmarks show that it is slightly faster to just load the offset from the bit-fields. Additionally, because of 1), we have plenty of space in the bit-fields of Stmt. Differential Revision: https://reviews.llvm.org/D55771 Reviewed By: rjmccall llvm-svn: 349910
* [AST][NFC] Pass the AST context to one of the ctor of DeclRefExpr.Bruno Ricci2018-12-211-3/+3
| | | | | | | | | All of the other constructors already take a reference to the AST context. This avoids calling Decl::getASTContext in most cases. Additionally move the definition of the constructor from Expr.h to Expr.cpp since it is calling DeclRefExpr::computeDependence. NFC. llvm-svn: 349901
* [OPENMP] parsing and sema support for 'close' map-type-modifierKelvin Li2018-12-181-7/+9
| | | | | | | | | | | | A map clause with the close map-type-modifier is a hint to prefer that the variables are mapped using a copy into faster memory. Patch by Ahsan Saghir (saghir) Differential Revision: https://reviews.llvm.org/D55719 llvm-svn: 349551
* [OpenCL] Add generic AS to 'this' pointerMikael Nilsson2018-12-131-5/+8
| | | | | | | | | | | | | Address spaces are cast into generic before invoking the constructor. Added support for a trailing Qualifiers object in FunctionProtoType. Note: This recommits the previously reverted patch, but now it is commited together with a fix for lldb. Differential Revision: https://reviews.llvm.org/D54862 llvm-svn: 349019
* Revert "[OpenCL] Add generic AS to 'this' pointer"Mikael Nilsson2018-12-121-8/+5
| | | | | | Reverting because the patch broke lldb. llvm-svn: 348931
* [OpenCL] Add generic AS to 'this' pointerMikael Nilsson2018-12-121-5/+8
| | | | | | | | | | Address spaces are cast into generic before invoking the constructor. Added support for a trailing Qualifiers object in FunctionProtoType. Differential Revision: https://reviews.llvm.org/D54862 llvm-svn: 348927
* [OpenCL] Diagnose conflicting address spaces in templates.Anastasia Stulova2018-12-051-12/+23
| | | | | | | | | | | | | Added new diagnostic when templates are instantiated with different address space from the one provided in its definition. This also prevents deducing generic address space in pointer type of templates to allow giving them concrete address space during instantiation. Differential Revision: https://reviews.llvm.org/D55127 llvm-svn: 348382
* [OpenCL] Improve diags for addr spaces in templatesAnastasia Stulova2018-11-291-0/+7
| | | | | | | | | | | Fix ICEs on template instantiations that were leading to the creation of invalid code patterns with address spaces. Incorrect cases are now diagnosed properly. Differential Revision: https://reviews.llvm.org/D54858 llvm-svn: 347865
* [OPENMP]Fix handling of the LCVs in loop-based directives.Alexey Bataev2018-11-211-0/+3
| | | | | | | | | Loop-control variables with the default data-sharing attributes should not be captured in the OpenMP region as they are private by default. Also, default attributes should be emitted for such variables in the inner OpenMP regions for the correct data sharing during codegen. llvm-svn: 347409
* Add support for 'atomic_default_mem_order' clause on 'requires' directive. ↵Patrick Lyster2018-11-021-0/+7
| | | | | | Also renamed test files relating to 'requires'. Differntial review: https://reviews.llvm.org/D53513 llvm-svn: 345967
* Create ConstantExpr classBill Wendling2018-10-311-2/+8
| | | | | | | | | | | | | | | | A ConstantExpr class represents a full expression that's in a context where a constant expression is required. This class reflects the path the evaluator took to reach the expression rather than the syntactic context in which the expression occurs. In the future, the class will be expanded to cache the result of the evaluated expression so that it's not needlessly re-evaluated Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D53475 llvm-svn: 345692
* [AST] Refactor PredefinedExprBruno Ricci2018-10-271-3/+3
| | | | | | | | | | | | | | | | | | Make the following changes to PredefinedExpr: 1. Move PredefinedExpr below StringLiteral so that it can use its definition. 2. Rename IdentType to IdentKind to be more in line with clang's conventions, and propagate the change to its users. 3. Move the location and the IdentKind into the newly available space of the bit-fields of Stmt. 4. Only store the function name when needed. When parsing all of Boost, of the 1357 PredefinedExpr 919 have no function name. Differential Revision: https://reviews.llvm.org/D53605 Reviewed By: rjmccall llvm-svn: 345460
OpenPOWER on IntegriCloud