summaryrefslogtreecommitdiffstats
path: root/clang/unittests/AST
Commit message (Collapse)AuthorAgeFilesLines
...
* [ASTImporter] Using Lang_CXX14 in ASTImporterVisibilityTest.Balazs Keri2019-07-151-17/+23
| | | | | | | | | | | | | | | | | | | | Summary: These tests may work with C++14 language constructs in the future (variable templates and others). To avoid warnings about language version C++ version constants in the tests are updated. Reviewers: martong, a.sidorin Reviewed By: martong Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64477 llvm-svn: 366061
* [ASTImporter] Added visibility context check for EnumDecl.Balazs Keri2019-07-091-0/+65
| | | | | | | | | | | | | | | | | | | Summary: ASTImporter makes now difference between enums with same name in different translation units if these are not visible outside. ("Scoped enums" are not handled yet.) Reviewers: martong, a.sidorin, shafik, a_sidorin Reviewed By: a_sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62484 llvm-svn: 365464
* [ASTImporter] Fix import of lambda in function paramGabor Marton2019-07-081-0/+39
| | | | | | | | | | | | | | | | | | | | | Summary: The current import implementation fails to import the definition of a lambda class if the lambda class is defined in a function param. E.g., the lambda class below will be imported without any methods: ``` template <typename F> void f(F L = [](){}) {} ``` Reviewers: a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64073 llvm-svn: 365315
* cmake: Add CLANG_LINK_CLANG_DYLIB optionTom Stellard2019-07-031-1/+1
| | | | | | | | | | | | | | | | Summary: Setting CLANG_LINK_CLANG_DYLIB=ON causes clang tools to link against libclang_shared.so instead of the individual component libraries. Reviewers: mgorny, beanz, smeenai, phosek, sylvestre.ledru Subscribers: arphaman, cfe-commits, llvm-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63503 llvm-svn: 365092
* [ASTImporter] Structural eq: handle DependentScopeDeclRefExprGabor Marton2019-07-021-0/+138
| | | | | | | | | | | | | | | | Summary: Structural equivalence did not handle dependent template args properly when the arg contained a DependentScopeDeclRefExpr. Reviewers: a_sidorin, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62329 llvm-svn: 364889
* [ASTImporter] Mark erroneous nodes in shared stGabor Marton2019-07-013-38/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now we store the errors for the Decls in the "to" context too. For that, however, we have to put these errors in a shared state (among all the ASTImporter objects which handle the same "to" context but different "from" contexts). After a series of imports from different "from" TUs we have a "to" context which may have erroneous nodes in it. (Remember, the AST is immutable so there is no way to delete a node once we had created it and we realized the error later.) All these erroneous nodes are marked in ASTImporterSharedState::ImportErrors. Clients of the ASTImporter may use this as an input. E.g. the static analyzer engine may not try to analyze a function if that is marked as erroneous (it can be queried via ASTImporterSharedState::getImportDeclErrorIfAny()). Reviewers: a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62376 llvm-svn: 364785
* [ASTImporter] Mark erroneous nodes in from ctxGabor Marton2019-07-011-14/+197
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: During import of a specific Decl D, it may happen that some AST nodes had already been created before we recognize an error. In this case we signal back the error to the caller, but the "to" context remains polluted with those nodes which had been created. Ideally, those nodes should not had been created, but that time we did not know about the error, the error happened later. Since the AST is immutable (most of the cases we can't remove existing nodes) we choose to mark these nodes as erroneous. Here are the steps of the algorithm: 1) We keep track of the nodes which we visit during the import of D: See ImportPathTy. 2) If a Decl is already imported and it is already on the import path (we have a cycle) then we copy/store the relevant part of the import path. We store these cycles for each Decl. 3) When we recognize an error during the import of D then we set up this error to all Decls in the stored cycles for D and we clear the stored cycles. Reviewers: a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62375 llvm-svn: 364771
* [ASTImporter] Propagate error from ImportDeclContextGabor Marton2019-07-011-0/+87
| | | | | | | | | | | | | | | | | | | | | | Summary: During analysis of one project we failed to import one CXXDestructorDecl. But since we did not propagate the error in importDeclContext we had a CXXRecordDecl without a destructor. Then the analyzer engine had a CallEvent where the nonexistent dtor was requested (crash). Solution is to propagate the errors we have during importing a DeclContext. Reviewers: a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63603 llvm-svn: 364752
* [ASTImporter] Store import errors for DeclsGabor Marton2019-06-253-2/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We add a new member which is a mapping from the already-imported declarations in the "from" context to the error status of the import of that declaration. This map contains only the declarations that were not correctly imported. The same declaration may or may not be included in ImportedDecls. This map is updated continuously during imports and never cleared (like ImportedDecls). In Import(Decl*) we use this mapping, so if there was a previous failed import we return with the existing error. We add/remove from the Lookuptable in consistency with ImportedFromDecls. When we map a decl in the 'to' context to something in the 'from' context then and only then we add it to the lookup table. When we remove a mapping then and only then we remove it from the lookup table. This patch is the first in a series of patches whose aim is to further strengthen the error handling in ASTImporter. Reviewers: a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62373 llvm-svn: 364279
* [ASTImporter] Fix unhandled cases in ASTImporterLookupTableGabor Marton2019-06-111-5/+51
| | | | | | | | | | | | | | | | | | | | | Summary: In most cases the FriendDecl contains the declaration of the befriended class as a child node, so it is discovered during the recursive visitation. However, there are cases when the befriended class is not a child, thus it must be fetched explicitly from the FriendDecl, and only then can we add it to the lookup table. (Note, this does affect only CTU and does not affect LLDB, because we cannot and do not use the ASTImporterLookupTable in LLDB.) Reviewers: a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62064 llvm-svn: 363062
* [clang] Respect TerseOutput when printing lambdasKadir Cetinkaya2019-05-271-0/+14
| | | | | | | | | | | | Reviewers: ilya-biryukov, hokein, sammccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62487 llvm-svn: 361771
* [ASTImporter] Added visibility context check for CXXRecordDecl.Balazs Keri2019-05-271-2/+35
| | | | | | | | | | | | | | | | | | | Summary: ASTImporter makes now difference between classes with same name in different translation units if these are not visible outside. These classes are not linked into one decl chain. Reviewers: martong, a.sidorin, shafik Reviewed By: shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62312 llvm-svn: 361752
* [ASTImporter] Enable disabled but passing testsGabor Marton2019-05-202-13/+3
| | | | | | | | | | | | Reviewers: a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62066 llvm-svn: 361139
* Add a Visit overload for DynTypedNode to ASTNodeTraverserStephen Kelly2019-05-192-0/+225
| | | | | | | | | | | | Reviewers: aaron.ballman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61834 llvm-svn: 361117
* Revert r361033 "Add a Visit overload for DynTypedNode to ASTNodeTraverser"Nico Weber2019-05-172-221/+0
| | | | | | | | It fails to build on some bots. Also revert follow-up r361055. llvm-svn: 361059
* Add a Visit overload for DynTypedNode to ASTNodeTraverserStephen Kelly2019-05-172-0/+221
| | | | | | | | | | | | Reviewers: aaron.ballman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61834 llvm-svn: 361033
* [ASTImporter] Use llvm::Expected and Error in the importer APIGabor Marton2019-05-152-3/+3
| | | | | | | | | | | | | | | | | | | | | | Summary: This is the final phase of the refactoring towards using llvm::Expected and llvm::Error in the ASTImporter API. This involves the following: - remove old Import functions which returned with a pointer, - use the Import_New functions (which return with Err or Expected) everywhere and handle their return value - rename Import_New functions to Import This affects both Clang and LLDB. Reviewers: shafik, teemperor, aprantl, a_sidorin, balazske, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits, lldb-commits Tags: #clang, #lldb Differential Revision: https://reviews.llvm.org/D61438 llvm-svn: 360760
* [ASTImporter] Separate unittest filesGabor Marton2019-05-136-1065/+1189
| | | | | | | | | | | | | | | | Summary: Move generic redecl chain tests and visibility tests into their own separate test files. Reviewers: a_sidorin, a.sidorin, shafik Subscribers: mgorny, rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61786 llvm-svn: 360572
* [c++20] Add support for explicit(bool), as described in P0892R2.Richard Smith2019-05-094-0/+48
| | | | | | | | Patch by Tyker! Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360311
* [ASTImporter] Corrected type of integer constant in a test.Balazs Keri2019-05-071-2/+2
| | | | llvm-svn: 360156
* [ASTImporter] Import TemplateParameterLists in function templates.Balazs Keri2019-05-071-0/+18
| | | | | | | | | | | | | | | | Summary: Correct missing import of TemplateParameterList in function decl. Reviewers: martong, a.sidorin, shafik Reviewed By: martong Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60461 llvm-svn: 360132
* Revert r359949 "[clang] adding explicit(bool) from c++2a"Hans Wennborg2019-05-064-48/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused Clang to start erroring on the following: struct S {   template <typename = int> explicit S(); }; struct T : S {}; struct U : T {   U(); }; U::U() {} $ clang -c /tmp/x.cc /tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T' U::U() {}    ^ /tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted because base class 'S' has no default constructor struct T : S {};            ^ 1 error generated. See discussion on the cfe-commits email thread. This also reverts the follow-ups r359966 and r359968. > this patch adds support for the explicit bool specifier. > > Changes: > - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. > - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. > - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. > - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. > - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. > - Test for Semantic and Serialization were added. > > This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. > Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. > > Patch by Tyker > > Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360024
* [c++20] Implement P0428R2 - Familiar template syntax for generic lambdasHamza Sood2019-05-041-0/+37
| | | | | | Differential Revision: https://reviews.llvm.org/D36527 llvm-svn: 359967
* [clang] adding explicit(bool) from c++2aNicolas Lesser2019-05-044-0/+48
| | | | | | | | | | | | | | | | | | | | | this patch adds support for the explicit bool specifier. Changes: - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. - Test for Semantic and Serialization were added. This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. Patch by Tyker Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 359949
* Fix gcc "-Wdangling-else" warnings. NFCI.Simon Pilgrim2019-04-301-3/+6
| | | | llvm-svn: 359550
* [ASTImporter] Add an ImportImpl method to allow customizing Import behavior.Raphael Isemann2019-04-291-9/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We are currently implementing support in LLDB that reconstructs the STL templates from the target program in the expression evaluator. This reconstruction happens during the import process from our debug info AST into the expression evaluation AST, which means we need a way to intercept the ASTImporter import process. This patch adds an protected ImportImpl method that we can overwrite in LLDB to implement our special importing logic (which is essentially just looking into a C++ module that is attached to the target context). Because ImportImpl has to call MapImported/AddToLookup for the decls it creates, this patch also exposes those via a new unified method and checks that we call it when importing decls. Reviewers: martong, balazske, a.sidorin, shafik, a_sidorin Reviewed By: martong, a_sidorin Subscribers: rnkovacs, cfe-commits, lldb-commits, aprantl Tags: #clang Differential Revision: https://reviews.llvm.org/D59485 llvm-svn: 359502
* Changed every use of ASTImporter::Import to Import_NewBalazs Keri2019-04-081-18/+37
| | | | | | | | | | | | | | Reviewers: a.sidorin, shafik, martong, a_sidorin Reviewed By: a_sidorin Subscribers: rnkovacs, dkrupp, martong, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D55049 llvm-svn: 357913
* Fix error in NamedDeclPrinterTestDavid Goldman2019-04-051-16/+20
| | | | | | | | Caused by D56924, shouldn't use raw string literals in macros. Differential Revision: https://reviews.llvm.org/D60326 llvm-svn: 357799
* Special case ObjCPropertyDecl for printingDavid Goldman2019-04-041-0/+40
| | | | | | | | ObjCPropertyDecl should use the category interface as a context similar to what is done for methods. Previously category methods would be printed as `::property`; now they are printed as `Class::property`. llvm-svn: 357720
* Range-style std::find{,_if} -> llvm::find{,_if}. NFCFangrui Song2019-03-311-5/+4
| | | | llvm-svn: 357359
* Basic: Return a reference from FileManager::getVirtualFileSystem, NFCDuncan P. N. Exon Smith2019-03-261-1/+1
| | | | | | | | | | FileManager constructs a VFS in its constructor if it isn't passed one, and there's no way to reset it. Make that contract clear by returning a reference from its accessor. https://reviews.llvm.org/D59388 llvm-svn: 357038
* [AST] OMPStructuredBlockTest: avoid using multiline string literals in macrosRoman Lebedev2019-03-221-7/+9
| | | | | | | | | | That is what i have been doing elsewhere in these tests, maybe that's it? Maybe this helps with failing builds: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/17921 http://lab.llvm.org:8011/builders/clang-cmake-aarch64-global-isel/builds/10248 llvm-svn: 356749
* [AST] OMPStructuredBlockTest: two matchers were promoted into ASTMatchers.hRoman Lebedev2019-03-211-6/+1
| | | | llvm-svn: 356679
* [ASTMatchers][OpenMP] Add base ompExecutableDirective() matcher.Roman Lebedev2019-03-211-4/+0
| | | | | | | | | | | | | | | | | | Summary: A simple matcher for `OMPExecutableDirective` Stmt type. Split off from D57113. Reviewers: gribozavr, aaron.ballman, JonasToth, george.karpenkov Reviewed By: gribozavr, aaron.ballman Subscribers: guansong, jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59453 llvm-svn: 356674
* [clang][OpenMP] Fix build when using libgompJordan Rupprecht2019-03-201-1/+1
| | | | | | | | | | | | | | Summary: rL356570 introduced a test which only passes with the default openmp library, libomp, and fails with other openmp libraries, such as libgomp. Explicitly choose libomp. Reviewers: lebedev.ri Subscribers: guansong, jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59609 llvm-svn: 356614
* [clang][OpeMP] Model OpenMP structured-block in AST (PR40563)Roman Lebedev2019-03-204-75/+641
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf, page 3: ``` structured block For C/C++, an executable statement, possibly compound, with a single entry at the top and a single exit at the bottom, or an OpenMP construct. COMMENT: See Section 2.1 on page 38 for restrictions on structured blocks. ``` ``` 2.1 Directive Format Some executable directives include a structured block. A structured block: • may contain infinite loops where the point of exit is never reached; • may halt due to an IEEE exception; • may contain calls to exit(), _Exit(), quick_exit(), abort() or functions with a _Noreturn specifier (in C) or a noreturn attribute (in C/C++); • may be an expression statement, iteration statement, selection statement, or try block, provided that the corresponding compound statement obtained by enclosing it in { and } would be a structured block; and Restrictions Restrictions to structured blocks are as follows: • Entry to a structured block must not be the result of a branch. • The point of exit cannot be a branch out of the structured block. C / C++ • The point of entry to a structured block must not be a call to setjmp(). • longjmp() and throw() must not violate the entry/exit criteria. ``` Of particular note here is the fact that OpenMP structured blocks are as-if `noexcept`, in the same sense as with the normal `noexcept` functions in C++. I.e. if throw happens, and it attempts to travel out of the `noexcept` function (here: out of the current structured-block), then the program terminates. Now, one of course can say that since it is explicitly prohibited by the Specification, then any and all programs that violate this Specification contain undefined behavior, and are unspecified, and thus no one should care about them. Just don't write broken code /s But i'm not sure this is a reasonable approach. I have personally had oss-fuzz issues of this origin - exception thrown inside of an OpenMP structured-block that is not caught, thus causing program termination. This issue isn't all that hard to catch, it's not any particularly different from diagnosing the same situation with the normal `noexcept` function. Now, clang static analyzer does not presently model exceptions. But clang-tidy has a simplisic [[ https://clang.llvm.org/extra/clang-tidy/checks/bugprone-exception-escape.html | bugprone-exception-escape ]] check, and it is even refactored as a `ExceptionAnalyzer` class for reuse. So it would be trivial to use that analyzer to check for exceptions escaping out of OpenMP structured blocks. (D59466) All that sounds too great to be true. Indeed, there is a caveat. Presently, it's practically impossible to do. To check a OpenMP structured block you need to somehow 'get' the OpenMP structured block, and you can't because it's simply not modelled in AST. `CapturedStmt`/`CapturedDecl` is not it's representation. Now, it is of course possible to write e.g. some AST matcher that would e.g. match every OpenMP executable directive, and then return the whatever `Stmt` is the structured block of said executable directive, if any. But i said //practically//. This isn't practical for the following reasons: 1. This **will** bitrot. That matcher will need to be kept up-to-date, and refreshed with every new OpenMP spec version. 2. Every single piece of code that would want that knowledge would need to have such matcher. Well, okay, if it is an AST matcher, it could be shared. But then you still have `RecursiveASTVisitor` and friends. `2 > 1`, so now you have code duplication. So it would be reasonable (and is fully within clang AST spirit) to not force every single consumer to do that work, but instead store that knowledge in the correct, and appropriate place - AST, class structure. Now, there is another hoop we need to get through. It isn't fully obvious //how// to model this. The best solution would of course be to simply add a `OMPStructuredBlock` transparent node. It would be optimal, it would give us two properties: * Given this `OMPExecutableDirective`, what's it OpenMP structured block? * It is trivial to check whether the `Stmt*` is a OpenMP structured block (`isa<OMPStructuredBlock>(ptr)`) But OpenMP structured block isn't **necessarily** the first, direct child of `OMP*Directive`. (even ignoring the clang's `CapturedStmt`/`CapturedDecl` that were inserted inbetween). So i'm not sure whether or not we could re-create AST statements after they were already created? There would be other costs to a new AST node: https://bugs.llvm.org/show_bug.cgi?id=40563#c12 ``` 1. You will need to break the representation of loops. The body should be replaced by the "structured block" entity. 2. You will need to support serialization/deserialization. 3. You will need to support template instantiation. 4. You will need to support codegen and take this new construct to account in each OpenMP directive. ``` Instead, there **is** an functionally-equivalent, alternative solution, consisting of two parts. Part 1: * Add a member function `isStandaloneDirective()` to the `OMPExecutableDirective` class, that will tell whether this directive is stand-alone or not, as per the spec. We need it because we can't just check for the existance of associated statements, see code comment. * Add a member function `getStructuredBlock()` to the OMPExecutableDirective` class itself, that assert that this is not a stand-alone directive, and either return the correct loop body if this is a loop-like directive, or the captured statement. This way, given an `OMPExecutableDirective`, we can get it's structured block. Also, since the knowledge is ingrained into the clang OpenMP implementation, it will not cause any duplication, and //hopefully// won't bitrot. Great we achieved 1 of 2 properties of `OMPStructuredBlock` approach. Thus, there is a second part needed: * How can we check whether a given `Stmt*` is `OMPStructuredBlock`? Well, we can't really, in general. I can see this workaround: ``` class FunctionASTVisitor : public RecursiveASTVisitor<FunctionASTVisitor> { using Base = RecursiveASTVisitor<FunctionASTVisitor>; public: bool VisitOMPExecDir(OMPExecDir *D) { OmpStructuredStmts.emplace_back(D.getStructuredStmt()); } bool VisitSOMETHINGELSE(???) { if(InOmpStructuredStmt) HI! } bool TraverseStmt(Stmt *Node) { if (!Node) return Base::TraverseStmt(Node); if (OmpStructuredStmts.back() == Node) ++InOmpStructuredStmt; Base::TraverseStmt(Node); if (OmpStructuredStmts.back() == Node) { OmpStructuredStmts.pop_back(); --InOmpStructuredStmt; } return true; } std::vector<Stmt*> OmpStructuredStmts; int InOmpStructuredStmt = 0; }; ``` But i really don't see using it in practice. It's just too intrusive; and again, requires knowledge duplication. .. but no. The solution lies right on the ground. Why don't we simply store this `i'm a openmp structured block` in the bitfield of the `Stmt` itself? This does not appear to have any impact on the memory footprint of the clang AST, since it's just a single extra bit in the bitfield. At least the static assertions don't fail. Thus, indeed, we can achieve both of the properties without a new AST node. We can cheaply set that bit right in sema, at the end of `Sema::ActOnOpenMPExecutableDirective()`, by just calling the `getStructuredBlock()` that we just added. Test coverage that demonstrates all this has been added. This isn't as great with serialization though. Most of it does not use abbrevs, so we do end up paying the full price (4 bytes?) instead of a single bit. That price, of course, can be reclaimed by using abbrevs. In fact, i suspect that //might// not just reclaim these bytes, but pack these PCH significantly. I'm not seeing a third solution. If there is one, it would be interesting to hear about it. ("just don't write code that would require `isa<OMPStructuredBlock>(ptr)`" is not a solution.) Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=40563 | PR40563 ]]. Reviewers: ABataev, rjmccall, hfinkel, rsmith, riccibruno, gribozavr Reviewed By: ABataev, gribozavr Subscribers: mgorny, aaron.ballman, steveire, guansong, jfb, jdoerfert, cfe-commits Tags: #clang, #openmp Differential Revision: https://reviews.llvm.org/D59214 llvm-svn: 356570
* [ASTImporter] Fix redecl failures of FunctionTemplateSpecGabor Marton2019-03-191-77/+60
| | | | | | | | | | | | | | | | | | | Summary: Redecl chains of function template specializations are not handled well currently. We want to handle them similarly to functions, i.e. try to keep the structure of the original AST as much as possible. The aim is to not squash a prototype with a definition, rather we create both and put them in a redecl chain. Reviewers: a_sidorin, shafik, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58668 llvm-svn: 356455
* [ASTImporter] Fix redecl failures of ClassTemplateSpecGabor Marton2019-03-191-6/+42
| | | | | | | | | | | | | | | | | | | Summary: Redecl chains of class template specializations are not handled well currently. We want to handle them similarly to functions, i.e. try to keep the structure of the original AST as much as possible. The aim is to not squash a prototype with a definition, rather we create both and put them in a redecl chain. Reviewers: a_sidorin, shafik, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58673 llvm-svn: 356452
* [ASTImporter] Fix import of NestedNameSpecifierLoc.Balazs Keri2019-03-141-0/+20
| | | | | | | | | | | | | | | | | | | Summary: Import type location in case of TypeSpec and TypeSpecWithTemplate. Without this fix the imported NespedNameSpecifierLoc will have an invalid begin location. Reviewers: a.sidorin, shafik, a_sidorin, martong Reviewed By: a_sidorin Subscribers: rnkovacs, jdoerfert, dkrupp, martong, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D55358 llvm-svn: 356151
* [ASTImporter] Import member expr with explicit template argsGabor Marton2019-03-071-0/+50
| | | | | | | | | | | | | | | | Summary: Member expressions with explicit template arguments were not imported correctly: the DeclRefExpr was missing. This patch fixes. Reviewers: a_sidorin, shafik, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58830 llvm-svn: 355596
* [ASTImporter] Handle redecl chain of FunctionTemplateDeclsGabor Marton2019-03-071-34/+14
| | | | | | | | | | | | | | | | | | | Summary: Redecl chains of function templates are not handled well currently. We want to handle them similarly to functions, i.e. try to keep the structure of the original AST as much as possible. The aim is to not squash a prototype with a definition, rather we create both and put them in a redecl chain. Reviewers: a_sidorin, shafik, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58494 llvm-svn: 355593
* [ASTImporter] Fix redecl failures of Class and ClassTemplateGabor Marton2019-03-051-8/+4
| | | | | | | | | | | | | | | | | | | Summary: Redecl chains of classes and class templates are not handled well currently. We want to handle them similarly to functions, i.e. try to keep the structure of the original AST as much as possible. The aim is to not squash a prototype with a definition, rather we create both and put them in a redecl chain. Reviewers: a_sidorin, shafik, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58502 llvm-svn: 355390
* [ASTImporter] Add support for importing ChooseExpr AST nodes.Tom Roeder2019-02-261-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This allows ASTs to be merged when they contain ChooseExpr (the GNU __builtin_choose_expr construction). This is needed, for example, for cross-CTU analysis of C code that makes use of __builtin_choose_expr. The node is already supported in the AST, but it didn't have a matcher in ASTMatchers. So, this change adds the matcher and adds support to ASTImporter. This was originally reviewed and approved in https://reviews.llvm.org/D58292 and submitted as r354832. It was reverted in r354839 due to failures on the Windows CI builds. This version fixes the test failures on Windows, which were caused by differences in template expansion between versions of clang on different OSes. The version of clang built with MSVC and running on Windows never expands the template in the C++ test in ImportExpr.ImportChooseExpr in clang/unittests/AST/ASTImporter.cpp, but the version on Linux does for the empty arguments and -fms-compatibility. So, this version of the patch drops the C++ test for __builtin_choose_expr, since that version was written to catch regressions of the logic for isConditionTrue() in the AST import code for ChooseExpr, and those regressions are also caught by ASTImporterOptionSpecificTestBase.ImportChooseExpr, which does work on Windows. Reviewers: shafik, a_sidorin, martong, aaron.ballman, rnk, a.sidorin Subscribers: cfe-commits, jdoerfert, rnkovacs, aaron.ballman Tags: #clang Differential Revision: https://reviews.llvm.org/D58663 llvm-svn: 354916
* Revert r354832 "[ASTImporter] Add support for importing ChooseExpr AST nodes."Reid Kleckner2019-02-261-49/+0
| | | | | | Test does not pass on Windows llvm-svn: 354839
* [ASTImporter] Add support for importing ChooseExpr AST nodes.Tom Roeder2019-02-251-0/+49
| | | | | | | | | | | | | | | | | | | | | Summary: This allows ASTs to be merged when they contain ChooseExpr (the GNU __builtin_choose_expr construction). This is needed, for example, for cross-CTU analysis of C code that makes use of __builtin_choose_expr. The node is already supported in the AST, but it didn't have a matcher in ASTMatchers. So, this change adds the matcher and adds support to ASTImporter. Reviewers: shafik, a_sidorin, martong, aaron.ballman Subscribers: aaron.ballman, rnkovacs, jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58292 llvm-svn: 354832
* Fix remaining semicolon pedantic errors for intelGabor Marton2019-02-201-2/+2
| | | | llvm-svn: 354503
* Fix compile error with Intel's compiler (-Werror=pedantic)Gabor Marton2019-02-201-60/+60
| | | | | | | An extra semicolon at the end of macro invocations caused a build bot failure for Intel's compiler when pedantic is turned on. llvm-svn: 354482
* [ASTImporter] Find previous friend function templateGabor Marton2019-02-181-0/+30
| | | | | | | | | | | | Reviewers: a_sidorin, shafik, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57910 llvm-svn: 354267
* [ASTImporter] Unify redecl chain tests as type parameterized testsGabor Marton2019-02-181-641/+556
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch unifies all those tests which check the correctness of the redecl chains. Previously we had several structurally very similar test cases for each language construct (class, function, variable, function template, ...). We still use value-parameterized tests for the different AST compatibility switches (-fdelayed-template-parsing, -fms-compatibility). Gtest makes it possible to have either value-parameterized or type-parameterized fixtures. However, we cannot have both value- and type-parameterized test fixtures. So we use a value-parameterized test fixture in the gtest sense. We intend to mimic gtest's type-parameters via the type template parameter. We manually instantiate the different tests with the each types. After this patch I am planning to put the "generic redecl chain" related tests into their own separate test file (in another patch). Reviewers: a_sidorin, shafik, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Differential Revision: https://reviews.llvm.org/D57236 llvm-svn: 354259
* [ASTImporter] Import every Decl in lambda recordGabor Marton2019-02-151-0/+20
| | | | | | | | | | | | | | | | | | | | Summary: Previously only the fields were imported. Now every Decl is imported. This way the destructor decl is not missing after import. Patch by balazske (Balázs Kéri) Reviewers: a.sidorin, shafik Reviewed By: shafik Subscribers: balazske, cfe-commits, Szelethus, martong, dkrupp Tags: #clang Differential Revision: https://reviews.llvm.org/D57740 llvm-svn: 354120
OpenPOWER on IntegriCloud