summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST
Commit message (Collapse)AuthorAgeFilesLines
...
* Reinstate r359059, reverted in r359361, with a fix to properly preventRichard Smith2019-04-271-36/+43
| | | | | | | | | | | | | | | | | | | | | | | us emitting the operand of __builtin_constant_p if it has side-effects. Original commit message: Fix interactions between __builtin_constant_p and constexpr to match current trunk GCC. GCC permits information from outside the operand of __builtin_constant_p (but in the same constant evaluation context) to be used within that operand; clang now does so too. A few other minor deviations from GCC's behavior showed up in my testing and are also fixed (matching GCC): * Clang now supports nullptr_t as the argument type for __builtin_constant_p * Clang now returns true from __builtin_constant_p if called with a null pointer * Clang now returns true from __builtin_constant_p if called with an integer cast to pointer type llvm-svn: 359367
* Revert Fix interactions between __builtin_constant_p and constexpr to match ↵Jorge Gorbe Moya2019-04-271-35/+28
| | | | | | | | current trunk GCC. This reverts r359059 (git commit 0b098754b73f3b96d00ecb1c7605760b11c90298) llvm-svn: 359361
* [ASTImporter] Copy Argument Passing Restrictions setting when importing a ↵Shafik Yaghmour2019-04-261-0/+3
| | | | | | | | | | | | | | | CXXRecordDecl definition Summary: For a CXXRecordDecl the RecordDeclBits are stored in the DeclContext. Currently when we import the definition of a CXXRecordDecl via the ASTImporter we do not copy over this data. This change will add support for copying the ArgPassingRestrictions from RecordDeclBits to fix an LLDB expression parsing bug where we would set it to not pass in registers. Note, we did not copy over any other of the RecordDeclBits since we don't have tests for those. We know that copying over LoadedFieldsFromExternalStorage would be a error and that may be the case for others as well. The companion LLDB review: https://reviews.llvm.org/D61146 Differential Review: https://reviews.llvm.org/D61140 llvm-svn: 359338
* C++ DR2387: a variable template declared wtih (or instantiated with) aRichard Smith2019-04-261-30/+51
| | | | | | | | | const-qualified type is not implicitly given internal linkage. But a variable template declared 'static' is. This reinstates part of r359048, reverted in r359076. llvm-svn: 359260
* Use llvm::stable_sortFangrui Song2019-04-243-7/+7
| | | | llvm-svn: 359098
* Revert r359048: C++ DR2387: a variable template declared wthiIlya Biryukov2019-04-241-51/+30
| | | | | | | | | | | | | The change breaks libc++ with the follwing error: In file included from valarray:4: .../include/c++/v1/valarray:1062:60: error: explicit instantiation declaration of 'valarray<_Tp>' with internal linkage _LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::valarray(size_t)) ^ .../include/c++/v1/valarray:1063:60: error: explicit instantiation declaration of '~valarray<_Tp>' with internal linkage _LIBCPP_EXTERN_TEMPLATE(_LIBCPP_FUNC_VIS valarray<size_t>::~valarray()) llvm-svn: 359076
* [Builtins] Implement __builtin_is_constant_evaluated for use in C++2aEric Fiselier2019-04-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements `__builtin_is_constant_evaluated` as specifier by [P0595R2](https://wg21.link/p0595r2). It is built on the back of Bill Wendling's work for `__builtin_constant_p()`. More tests to come, but early feedback is appreciated. I plan to implement warnings for common mis-usages like those belowe in a following patch: ``` void foo(int x) { if constexpr (std::is_constant_evaluated())) { // condition is always `true`. Should use plain `if` instead. foo_constexpr(x); } else { foo_runtime(x); } } ``` Reviewers: rsmith, MaskRay, bruno, void Reviewed By: rsmith Subscribers: dexonsmith, zoecarver, fdeazeve, kristina, cfe-commits Differential Revision: https://reviews.llvm.org/D55500 llvm-svn: 359067
* Fix interactions between __builtin_constant_p and constexpr to matchRichard Smith2019-04-241-28/+35
| | | | | | | | | | | | | | | | | | current trunk GCC. GCC permits information from outside the operand of __builtin_constant_p (but in the same constant evaluation context) to be used within that operand; clang now does so too. A few other minor deviations from GCC's behavior showed up in my testing and are also fixed (matching GCC): * Clang now supports nullptr_t as the argument type for __builtin_constant_p * Clang now returns true from __builtin_constant_p if called with a null pointer * Clang now returns true from __builtin_constant_p if called with an integer cast to pointer type llvm-svn: 359059
* C++ DR2387: a variable template declared wtih (or instantiated with) aRichard Smith2019-04-231-30/+51
| | | | | | | const-qualified type is not implicitly given internal linkage. But a variable template declared 'static' is. llvm-svn: 359048
* MS ABI: Support mangling op<=> now that MSVC 2019 has a manglingNico Weber2019-04-231-9/+2
| | | | llvm-svn: 359009
* [c++2a] Implement semantic restrictions for 'export' declarations.Richard Smith2019-04-221-16/+0
| | | | llvm-svn: 358932
* Modules: Adopt template parameters for variable templates to set their decl ↵David Blaikie2019-04-191-0/+1
| | | | | | | | | | | context correctly Exposed by a related bug about visibility of default arguments of nested templates - without the correct decl context, default template parameters of variable templates nested in classes would have incorrect visibility computed. llvm-svn: 358796
* Fix overly-long line after r358731.Richard Smith2019-04-191-2/+2
| | | | llvm-svn: 358733
* Fix typo in function name [NFC]Ali Tamur2019-04-191-3/+3
| | | | llvm-svn: 358731
* [c++2a] Add semantic support for private module fragments.Richard Smith2019-04-181-10/+18
| | | | llvm-svn: 358713
* Move the implementation of getInnermostBlockDecl to the .cpp file to fixAkira Hatanaka2019-04-181-0/+12
| | | | | | failing bots. llvm-svn: 358627
* [AST][NFC] Add const children() accessors to all AST nodesBruno Ricci2019-04-122-0/+9
| | | | | | | | | | | | | | Systematically add the const-qualified version of children() to all statement/expression nodes. Previously the const-qualified variant was only defined for some nodes. NFC. Patch by: Nicolas Manichon Differential Revision: https://reviews.llvm.org/D60029 Reviewed By: riccibruno llvm-svn: 358288
* [clangd] Print template arguments helperKadir Cetinkaya2019-04-121-1/+15
| | | | | | | | | | | | | | | | Summary: Prepares ground for printing template arguments as written in the source code, part of re-landing rC356541 with D59599 applied. Reviewers: ioeric, ilya-biryukov Subscribers: mgorny, MaskRay, jkorous, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59639 llvm-svn: 358272
* [clang][ASTContext] Try to exit early before loading serialized comments ↵Jan Korous2019-04-101-18/+22
| | | | | | | | | | from AST files Loading external comments is expensive. This change probably doesn't apply to common cases but is almost for free and would save some work in case none of the declaration needs external comments to be loaded. Differential Revision: https://reviews.llvm.org/D60493 llvm-svn: 358133
* Fixed comment as pointed out by post-commit review of D59845Raphael Isemann2019-04-091-1/+1
| | | | llvm-svn: 358006
* [ASTImporter] Call to HandleNameConflict in VisitEnumDecl mistakeningly ↵Shafik Yaghmour2019-04-081-1/+1
| | | | | | | | | | | using Name instead of SearchName Summary: https://reviews.llvm.org/D51633 added error handling to the ASTNodeImporter::VisitEnumDecl(...) for the conflicting names case. This could lead to erroneous return of an error in that case since we should have been using SearchName. Name may be empty in the case where we find the name via getTypedefNameForAnonDecl(...). Differential Revision: https://reviews.llvm.org/D59665 llvm-svn: 357940
* Clean up ObjCPropertyDecl printingDavid Goldman2019-04-081-36/+53
| | | | | | | | | | | | | | | Summary: - `@property(attr, attr2)` instead of `@property ( attr,attr2 )`. - Change priority of attributes (see code/comments inline). - Support for printing weak and unsafe_unretained attributes. Subscribers: arphaman, jfb, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57965 llvm-svn: 357937
* Changed every use of ASTImporter::Import to Import_NewBalazs Keri2019-04-082-23/+51
| | | | | | | | | | | | | | 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
* Special case ObjCPropertyDecl for printingDavid Goldman2019-04-041-1/+7
| | | | | | | | 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
* [PR41276] Fixed incorrect generation of addr space cast for 'this' in C++.Anastasia Stulova2019-04-041-1/+1
| | | | | | | | | | | | | | | Improved classification of address space cast when qualification conversion is performed - prevent adding addr space cast for non-pointer and non-reference types. Take address space correctly from the pointee. Also pass correct address space from 'this' object using AggValueSlot when generating addrspacecast in the constructor call. Differential Revision: https://reviews.llvm.org/D59988 llvm-svn: 357682
* Attempt to fix failing buildbot (ppc64le)Gabor Marton2019-04-011-0/+1
| | | | llvm-svn: 357405
* [ASTImporter] Convert ODR diagnostics inside ASTImporter implementationGabor Marton2019-04-011-14/+14
| | | | | | | | | | | | | | | | | | | | | | Summary: ASTStructuralEquivalence uses a flag to indicate whether ODR diagnostics should be considered errors or warnings as module Sema is more strict than ASTMerge. The implementation of ASTImporter should allso follow along the same lines. Reviewers: martong, a.sidorin, shafik, a_sidorin Reviewed By: shafik, a_sidorin Subscribers: rnkovacs, martong, dkrupp, Szelethus, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59761 Patch by Endre Fulop! llvm-svn: 357402
* [ASTImporter] Make ODR error handling configurableGabor Marton2019-04-011-54/+106
| | | | | | | | | | | | | | | | | | | | | Summary: ODR errors are not necessarily true errors during the import of ASTs. ASTMerge and CrossTU should use the warning equivalent of every CTU error, while Sema should emit errors as before. Reviewers: martong, a_sidorin, shafik, a.sidorin Reviewed By: a_sidorin Subscribers: rnkovacs, dkrupp, Szelethus, jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58897 Patch by Endre Fulop! llvm-svn: 357394
* Range-style std::find{,_if} -> llvm::find{,_if}. NFCFangrui Song2019-03-315-13/+8
| | | | llvm-svn: 357359
* [ASTImporter] Fix IsStructuralMatch specialization for EnumDecl to prevent ↵Shafik Yaghmour2019-03-271-0/+6
| | | | | | | | | | | re-importing an EnumDecl while trying to complete it Summary: We may try and re-import an EnumDecl while trying to complete it in IsStructuralMatch(...) specialization for EnumDecl. This change mirrors a similar fix for the specialization for RecordDecl. Differential Revision: https://reviews.llvm.org/D59845 llvm-svn: 357100
* [OPENMP]Initial support for 'allocate' clause.Alexey Bataev2019-03-273-3/+41
| | | | | | Added parsing/sema analysis of the allocate clause. llvm-svn: 357068
* [ASTImporter] Changed use of Import to Import_New in ASTNodeImporter.Balazs Keri2019-03-251-50/+22
| | | | | | | | | | | | | | Reviewers: a.sidorin, shafik, martong, a_sidorin Reviewed By: a_sidorin Subscribers: a_sidorin, rnkovacs, gamesh411, dkrupp, martong, Szelethus, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D53757 llvm-svn: 356874
* [ASTTypeTraits][ASTMatchers][OpenMP] OMPClause handlingRoman Lebedev2019-03-211-0/+19
| | | | | | | | | | | | | | | | | | | Summary: `OMPClause` is the base class, it is not descendant from **any** other class, therefore for it to work with e.g. `VariadicDynCastAllOfMatcher<>`, it needs to be handled here. Reviewers: sbenza, bkramer, pcc, klimek, hokein, gribozavr, aaron.ballman, george.karpenkov Reviewed By: gribozavr, aaron.ballman Subscribers: guansong, jdoerfert, alexfh, ABataev, cfe-commits Tags: #openmp, #clang Differential Revision: https://reviews.llvm.org/D57112 llvm-svn: 356675
* Revert "[clangd] Print arguments in template specializations"Jordan Rupprecht2019-03-201-16/+1
| | | | | | This reverts commit 44a63f6a150dec72dea43730d2a89d292e58bd6f. It segfaults on an internal test case (will follow up off thread). llvm-svn: 356623
* Remove the unused return value in ASTImporter::Imported [NFC]Raphael Isemann2019-03-201-2/+1
| | | | | | | | | | | | | | | | | | Summary: `ASTImporter::Imported` currently returns a Decl, but that return value is not used by the ASTImporter (or anywhere else) nor is it documented. Reviewers: balazske, martong, a.sidorin, shafik Reviewed By: balazske, martong Subscribers: rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59595 llvm-svn: 356592
* [clang][OpeMP] Model OpenMP structured-block in AST (PR40563)Roman Lebedev2019-03-202-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Remove obsolete function ImportTemplateParameterList.Balazs Keri2019-03-201-49/+7
| | | | | | | | | | | | | | | | | | | Summary: The ASTNodeImporter::ImportTemplateParameterList is replaced by a template specialization of 'import' that already exists and does (almost) the same thing. Reviewers: martong, a.sidorin, shafik, a_sidorin Reviewed By: martong Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59134 llvm-svn: 356564
* [clangd] Print arguments in template specializationsKadir Cetinkaya2019-03-201-1/+16
| | | | | | | | | | | | Reviewers: ilya-biryukov Subscribers: ioeric, MaskRay, jkorous, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59354 llvm-svn: 356541
* Add a spelling of pass_object_size that uses __builtin_dynamic_object_sizeErik Pilkington2019-03-192-5/+10
| | | | | | | | | | | The attribute pass_dynamic_object_size(n) behaves exactly like pass_object_size(n), but instead of evaluating __builtin_object_size on calls, it evaluates __builtin_dynamic_object_size, which has the potential to produce runtime code when the object size can't be determined statically. Differential revision: https://reviews.llvm.org/D58757 llvm-svn: 356515
* [ASTImporter] Fix redecl failures of FunctionTemplateSpecGabor Marton2019-03-191-7/+14
| | | | | | | | | | | | | | | | | | | 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-136/+118
| | | | | | | | | | | | | | | | | | | 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
* Refactor cast<>'s in if conditionals, which can only assert on failure.Don Hinton2019-03-192-32/+31
| | | | | | | | | | | | | | | | | Summary: This patch refactors several instances of cast<> used in if conditionals. Since cast<> asserts on failure, the else branch can never be taken. In some cases, the fix is to replace cast<> with dyn_cast<>. While others required the removal of the conditional and some minor refactoring. A discussion can be seen here: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190318/265044.html Differential Revision: https://reviews.llvm.org/D59529 llvm-svn: 356441
* [Sema] Add some compile time _FORTIFY_SOURCE diagnosticsErik Pilkington2019-03-181-11/+15
| | | | | | | | | | | | | | | | | | | | | | | These diagnose overflowing calls to subset of fortifiable functions. Some functions, like sprintf or strcpy aren't supported right not, but we should probably support these in the future. We previously supported this kind of functionality with -Wbuiltin-memcpy-chk-size, but that diagnostic doesn't work with _FORTIFY implementations that use wrapper functions. Also unlike that diagnostic, we emit these warnings regardless of whether _FORTIFY_SOURCE is actually enabled, which is nice for programs that don't enable the runtime checks. Why not just use diagnose_if, like Bionic does? We can get better diagnostics in the compiler (i.e. mention the sizes), and we have the potential to diagnose sprintf and strcpy which is impossible with diagnose_if (at least, in languages that don't support C++14 constexpr). This approach also saves standard libraries from having to add diagnose_if. rdar://48006655 Differential revision: https://reviews.llvm.org/D58797 llvm-svn: 356397
* Make getFullyQualifiedName qualify both the pointee and class type for ↵Benjamin Kramer2019-03-151-0/+13
| | | | | | | | | | | member ptr types We already handle pointers and references, member ptrs are just another special case. Fixes PR40732. Differential Revision: https://reviews.llvm.org/D59387 llvm-svn: 356250
* [ASTImporter] Fix import of NestedNameSpecifierLoc.Balazs Keri2019-03-141-1/+4
| | | | | | | | | | | | | | | | | | | 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
* [AST] Improve support of external layouts in `MicrosoftRecordLayoutBuilder`Aleksandr Urakov2019-03-131-5/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes several small problems with external layouts support in `MicrosoftRecordLayoutBuilder`: - aligns properly the size of a struct that ends with a bit field. It was aligned on byte before, not on the size of the field, so the struct size was smaller than it should be; - adjusts the struct size when injecting a vbptr in the case when there were no bases or fields allocated after the vbptr. Similarly, without the adjustment the struct was smaller than it should be; - the same fix as above for the vfptr. All these fixes affect the non-virtual size of a struct, so they are tested through non-virtual inheritance. Reviewers: rnk, zturner, rsmith Reviewed By: rnk Subscribers: jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58544 llvm-svn: 356047
* [OPENMP 5.0]Initial support for 'allocator' clause.Alexey Bataev2019-03-124-7/+39
| | | | | | | Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
* [8.0 Regression] Fix handling of `__builtin_constant_p` inside template ↵Eric Fiselier2019-03-081-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | arguments, enumerators, case statements, and the enable_if attribute. Summary: The following code is accepted by Clang 7 and prior but rejected by the upcoming 8 release and in trunk [1] ``` // error {{never produces a constant expression}} void foo(const char* s) __attribute__((enable_if(__builtin_constant_p(*s) == false, "trap"))) {} void test() { foo("abc"); } ``` Prior to Clang 8, the call to `__builtin_constant_p` was a constant expression returning false. Currently, it's not a valid constant expression. The bug is caused because we failed to set `InConstantContext` when attempting to evaluate unevaluated constant expressions. [1] https://godbolt.org/z/ksAjmq Reviewers: rsmith, hans, sbenza Reviewed By: rsmith Subscribers: kristina, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59038 llvm-svn: 355743
* [ObjC] Emit a boxed expression as a compile-time constant if theAkira Hatanaka2019-03-081-0/+4
| | | | | | | | | | | | | | | | | | expression inside the parentheses is a valid UTF-8 string literal. Previously clang emitted an expression like @("abc") as a message send to stringWithUTF8String. This commit makes clang emit the boxed expression as a compile-time constant instead. This commit also has the effect of silencing the nullable-to-nonnull conversion warning clang started emitting after r317727, which originally motivated this commit (see https://oleb.net/2018/@keypath). rdar://problem/42684601 Differential Revision: https://reviews.llvm.org/D58729 llvm-svn: 355662
* [OPENMP 5.0]Add initial support for 'allocate' directive.Alexey Bataev2019-03-075-3/+52
| | | | | | | Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
OpenPOWER on IntegriCloud