summaryrefslogtreecommitdiffstats
path: root/clang/lib/Serialization/ASTReaderDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Reapply af57dbf12e54 "Add support for options -frounding-math, ↵Melanie Blower2019-12-051-0/+1
| | | | | | | | | | | | ftrapping-math, -ffp-model=, and -ffp-exception-behavior=" Patch was reverted because https://bugs.llvm.org/show_bug.cgi?id=44048 The original patch is modified to set the strictfp IR attribute explicitly in CodeGen instead of as a side effect of IRBuilder. In the 2nd attempt to reapply there was a windows lit test fail, the tests were fixed to use wildcard matching. Differential Revision: https://reviews.llvm.org/D62731
* Revert " Reapply af57dbf12e54 "Add support for options ↵Melanie Blower2019-12-041-1/+0
| | | | | | | -frounding-math, ftrapping-math, -ffp-model=, and -ffp-exception-behavior="" This reverts commit cdbed2dd856c14687efd741c2d8321686102acb8. Build break on Windows (lit fail)
* Reapply af57dbf12e54 "Add support for options -frounding-math, ↵Melanie Blower2019-12-041-0/+1
| | | | | | | | | | ftrapping-math, -ffp-model=, and -ffp-exception-behavior=" Patch was reverted because https://bugs.llvm.org/show_bug.cgi?id=44048 The original patch is modified to set the strictfp IR attribute explicitly in CodeGen instead of as a side effect of IRBuilder Differential Revision: https://reviews.llvm.org/D62731
* [clang][modules] Add support for merging lifetime-extended temporariesTyker2019-12-021-0/+22
| | | | | | | | | | | | | | Summary: Add support for merging lifetime-extended temporaries Reviewers: rsmith Reviewed By: rsmith Subscribers: xbolva00, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70190
* Revert "[clang][modules] Add support for merging lifetime-extended temporaries"Tyker2019-12-011-22/+0
| | | | This reverts commit a3cbe1a202df6ec8e23bd55e14db254e4bc33021.
* [clang][modules] Add support for merging lifetime-extended temporariesTyker2019-12-011-0/+22
| | | | | | | | | | | | | | Summary: Add support for merging lifetime-extended temporaries Reviewers: rsmith Reviewed By: rsmith Subscribers: xbolva00, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70190
* Revert "[clang][modules] Add support for merging lifetime-extended temporaries"Tyker2019-12-011-22/+0
| | | | This reverts commit 85c74384778909789389b9012a75cfcca7964a28.
* [clang][modules] Add support for merging lifetime-extended temporariesTyker2019-11-301-0/+22
| | | | | | | | | | | | | | Summary: Add support for merging lifetime-extended temporaries Reviewers: rsmith Reviewed By: rsmith Subscribers: xbolva00, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70190
* Revert "[clang][modules] Add support for merging lifetime-extended temporaries"Tyker2019-11-301-26/+0
| | | | This reverts commit 3c7f6b439699a9cbbc0ac8d288cc70aff357446b.
* [clang][modules] Add support for merging lifetime-extended temporariesTyker2019-11-301-0/+26
| | | | | | | | | | | | | | Summary: Add support for merging lifetime-extended temporaries Reviewers: rsmith Reviewed By: rsmith Subscribers: xbolva00, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70190
* clang/Modules: Move Serialization/Module.{h,cpp} to ModuleFile, NFCDuncan P. N. Exon Smith2019-11-211-1/+1
| | | | | | | | | Remove some cognitive load by renaming clang/Serialization/Module.h to clang/Serialization/ModuleFile.h, since it declares the ModuleFile class. This also makes editing a bit easier, since the basename of the file no long conflicts with clang/Basic/Module.h, which declares the Module class. Also move lib/Serialization/Module.cpp to lib/Serialization/ModuleFile.cpp.
* [NFC] Refactor representation of materialized temporariesTyker2019-11-191-0/+14
| | | | | | | | | | | | | | | Summary: this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718 Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: thakis, sammccall, ilya-biryukov, rnkovacs, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69360
* Revert "[NFC] Refactor representation of materialized temporaries"Nico Weber2019-11-171-14/+0
| | | | | | This reverts commit 08ea1ee2db5f9d6460fef1d79d0d1d1a5eb78982. It broke ./ClangdTests/FindExplicitReferencesTest.All on the bots, see comments on https://reviews.llvm.org/D69360
* [NFC] Refactor representation of materialized temporariesTyker2019-11-161-0/+14
| | | | | | | | | | | | | | | Summary: this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718 Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: rnkovacs, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69360
* Redeclare Objective-C property accessors inside the ObjCImplDecl in which ↵Adrian Prantl2019-11-081-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | they are synthesized. This patch is motivated by (and factored out from) https://reviews.llvm.org/D66121 which is a debug info bugfix. Starting with DWARF 5 all Objective-C methods are nested inside their containing type, and that patch implements this for synthesized Objective-C properties. 1. SemaObjCProperty populates a list of synthesized accessors that may need to inserted into an ObjCImplDecl. 2. SemaDeclObjC::ActOnEnd inserts forward-declarations for all accessors for which no override was provided into their ObjCImplDecl. This patch does *not* synthesize AST function *bodies*. Moving that code from the static analyzer into Sema may be a good idea though. 3. Places that expect all methods to have bodies have been updated. I did not update the static analyzer's inliner for synthesized properties to point back to the property declaration (see test/Analysis/Inputs/expected-plists/nullability-notes.m.plist), which I believed to be more bug than a feature. Differential Revision: https://reviews.llvm.org/D68108 rdar://problem/53782400
* [hip][cuda] Fix the extended lambda name mangling issue.Michael Liao2019-10-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - HIP/CUDA host side needs to use device kernel symbol name to match the device side binaries. Without a consistent naming between host- and device-side compilations, it's risky that wrong device binaries are executed. Consistent naming is usually not an issue until unnamed types are used, especially the lambda. In this patch, the consistent name mangling is addressed for the extended lambdas, i.e. the lambdas annotated with `__device__`. - In [Itanium C++ ABI][1], the mangling of the lambda is generally unspecified unless, in certain cases, ODR rule is required to ensure consisent naming cross TUs. The extended lambda is such a case as its name may be part of a device kernel function, e.g., the extended lambda is used as a template argument and etc. Thus, we need to force ODR for extended lambdas as they are referenced in both device- and host-side TUs. Furthermore, if a extended lambda is nested in other (extended or not) lambdas, those lambdas are required to follow ODR naming as well. This patch revises the current lambda mangle numbering to force ODR from an extended lambda to all its parent lambdas. - On the other side, the aforementioned ODR naming should not change those lambdas' original linkages, i.e., we cannot replace the original `internal` with `linkonce_odr`; otherwise, we may violate ODR in general. This patch introduces a new field `HasKnownInternalLinkage` in lambda data to decouple the current linkage calculation based on mangling number assigned. [1]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html Reviewers: tra, rsmith, yaxunl, martong, shafik Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68818 llvm-svn: 375309
* [Concept] Associated Constraints InfrastructureSaar Raz2019-10-151-3/+5
| | | | | | | Add code to correctly calculate the associated constraints of a template (no enforcement yet). D41284 on Phabricator. llvm-svn: 374938
* Move most CXXRecordDecl::DefinitionData bit-fields out into a separateRichard Smith2019-10-111-104/+16
| | | | | | | | | | | file. Reduces duplication and thereby reduces the risk that someone will forget to update one of these places, as I did when adding DefaultedDestructorIsConstexpr (though I've been unable to produce a testcase for which that matters so far). llvm-svn: 374484
* For P0784R7: compute whether a variable has constant destruction if itRichard Smith2019-09-291-2/+3
| | | | | | | | | | has a constexpr destructor. For constexpr variables, reject if the variable does not have constant destruction. In all cases, do not emit runtime calls to the destructor for variables with constant destruction. llvm-svn: 373159
* [NFCI]Create CommonAttributeInfo Type as base type of *Attr and ParsedAttr.Erich Keane2019-09-131-5/+23
| | | | | | | | | | | | In order to enable future improvements to our attribute diagnostics, this moves info from ParsedAttr into CommonAttributeInfo, then makes this type the base of the *Attr and ParsedAttr types. Quite a bit of refactoring took place, including removing a bunch of redundant Spelling Index propogation. Differential Revision: https://reviews.llvm.org/D67368 llvm-svn: 371875
* [Sema] Diagnose default-initialization, destruction, and copying ofAkira Hatanaka2019-09-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | non-trivial C union types This recommits r365985, which was reverted because it broke a few projects using unions containing non-trivial ObjC pointer fields in system headers. We now have a patch to fix the problem (see https://reviews.llvm.org/D65256). Original commit message: This patch diagnoses uses of non-trivial C unions and structs/unions containing non-trivial C unions in the following contexts, which require default-initialization, destruction, or copying of the union objects, instead of disallowing fields of non-trivial types in C unions, which is what we currently do: - function parameters. - function returns. - assignments. - compound literals. - block captures except capturing of `__block` variables by non-escaping blocks. - local and global variable definitions. - lvalue-to-rvalue conversions of volatile types. See the discussion in https://reviews.llvm.org/D62988 for more background. rdar://problem/50679094 Differential Revision: https://reviews.llvm.org/D63753 llvm-svn: 371275
* [OPENMP5.0]Add support for device_type clause in declare targetAlexey Bataev2019-08-231-4/+7
| | | | | | | | | | construct. OpenMP 5.0 introduced new clause for declare target directive, device_type clause, which may accept values host, nohost, and any. Host means that the function must be emitted only for the host, nohost - only for the device, and any - for both, device and the host. llvm-svn: 369775
* Revert "[Sema] Diagnose default-initialization, destruction, and copying of"Akira Hatanaka2019-07-261-3/+0
| | | | | | | | | | | | | | | This reverts commit r365985. Prior to r365985, clang used to mark C union fields that have non-trivial ObjC ownership qualifiers as unavailable if the union was declared in a system header. r365985 stopped doing so, which caused the swift compiler to crash when it tried to import a non-trivial union. I have a patch that fixes the crash (https://reviews.llvm.org/D65256), but I'm temporarily reverting the original patch until we can decide on whether it's taking the right approach. llvm-svn: 367076
* [Sema] Diagnose default-initialization, destruction, and copying ofAkira Hatanaka2019-07-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | non-trivial C union types This patch diagnoses uses of non-trivial C unions and structs/unions containing non-trivial C unions in the following contexts, which require default-initialization, destruction, or copying of the union objects, instead of disallowing fields of non-trivial types in C unions, which is what we currently do: - function parameters. - function returns. - assignments. - compound literals. - block captures except capturing of `__block` variables by non-escaping blocks. - local and global variable definitions. - lvalue-to-rvalue conversions of volatile types. See the discussion in https://reviews.llvm.org/D62988 for more background. rdar://problem/50679094 Differential Revision: https://reviews.llvm.org/D63753 llvm-svn: 365985
* [Concepts] Concept definitions (D40381)Saar Raz2019-07-101-0/+10
| | | | | | | First in a series of patches to land C++2a Concepts support. This patch adds AST and parsing support for concept-declarations. llvm-svn: 365699
* [Bitcode] Move Bitstream to a separate libraryFrancis Visoiu Mistrih2019-07-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This moves Bitcode/Bitstream*, Bitcode/BitCodes.h to Bitstream/. This is needed to avoid a circular dependency when using the bitstream code for parsing optimization remarks. Since Bitcode uses Core for the IR part: libLLVMRemarks -> Bitcode -> Core and Core uses libLLVMRemarks to generate remarks (see IR/RemarkStreamer.cpp): Core -> libLLVMRemarks we need to separate the Bitstream and Bitcode part. For clang-doc, it seems that it doesn't need the whole bitcode layer, so I updated the CMake to only use the bitstream part. Differential Revision: https://reviews.llvm.org/D63899 llvm-svn: 365091
* BitStream reader: propagate errorsJF Bastien2019-06-261-13/+52
| | | | | | | | | | | | | | | | | | | | | | The bitstream reader handles errors poorly. This has two effects: * Bugs in file handling (especially modules) manifest as an "unexpected end of file" crash * Users of clang as a library end up aborting because the code unconditionally calls `report_fatal_error` The bitstream reader should be more resilient and return Expected / Error as soon as an error is encountered, not way late like it does now. This patch starts doing so and adopting the error handling where I think it makes sense. There's plenty more to do: this patch propagates errors to be minimally useful, and follow-ups will propagate them further and improve diagnostics. https://bugs.llvm.org/show_bug.cgi?id=42311 <rdar://problem/33159405> Differential Revision: https://reviews.llvm.org/D63518 llvm-svn: 364464
* [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
* Permit static local structured bindings to be named from arbitrary scopes ↵Richard Smith2019-05-251-1/+3
| | | | | | inside their declaring scope. llvm-svn: 361686
* [c++20] Add support for explicit(bool), as described in P0892R2.Richard Smith2019-05-091-5/+4
| | | | | | | | Patch by Tyker! Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360311
* Revert r359949 "[clang] adding explicit(bool) from c++2a"Hans Wennborg2019-05-061-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [clang] adding explicit(bool) from c++2aNicolas Lesser2019-05-041-5/+4
| | | | | | | | | | | | | | | | | | | | | 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
* Replace ad-hoc tracking of pattern for an instantiated class-scopeRichard Smith2019-05-021-7/+19
| | | | | | | | | | explicit function specialization with the MemberSpecializationInfo used everywhere else. Not NFC: the ad-hoc pattern tracking was not being serialized / deserialized properly. That's fixed here. llvm-svn: 359747
* [OPENMP]Improve detection of omp_allocator_handle_t type and predefinedAlexey Bataev2019-03-201-2/+7
| | | | | | | | | | | allocators. It is better to deduce omp_allocator_handle_t type from the predefined allocators, because omp.h header might not define it explicitly. Plus, it allows to identify the predefined allocators correctly when trying to build the allcoator for the global variables. llvm-svn: 356607
* [OPENMP 5.0]Initial support for 'allocator' clause.Alexey Bataev2019-03-121-4/+14
| | | | | | | Added parsing/sema analysis/serialization/deserialization for the 'allocator' clause of the 'allocate' directive. llvm-svn: 355952
* [OPENMP 5.0]Add initial support for 'allocate' directive.Alexey Bataev2019-03-071-1/+21
| | | | | | | Added parsing/sema analysis/serialization/deserialization support for 'allocate' directive. llvm-svn: 355614
* Avoid needlessly copying a block to the heap when a block literalAkira Hatanaka2019-02-271-0/+1
| | | | | | | | | | | | initializes a local auto variable or is assigned to a local auto variable that is declared in the scope that introduced the block literal. rdar://problem/13289333 https://reviews.llvm.org/D58514 llvm-svn: 355012
* [modules] Fix handling of initializers for templated global variables.Richard Smith2019-02-051-1/+1
| | | | | | | | | | | | | | | For global variables with unordered initialization that are instantiated within a module, we previously did not emit the global (or its initializer) at all unless it was used in the importing translation unit (and sometimes not even then!), leading to misbehavior and link errors. We now emit the initializer for an instantiated global variable with unordered initialization with side-effects in a module into every translation unit that imports the module. This is unfortunate, but mostly matches the behavior of a non-modular compilation and seems to be the best that we can reasonably do. llvm-svn: 353240
* [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive.Michael Kruse2019-02-011-1/+22
| | | | | | | | | | | | | | | | | This patch implements parsing and sema for "omp declare mapper" directive. User defined mapper, i.e., declare mapper directive, is a new feature in OpenMP 5.0. It is introduced to extend existing map clauses for the purpose of simplifying the copy of complex data structures between host and device (i.e., deep copy). An example is shown below: struct S { int len; int *d; }; #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory region that d points to is also mapped using this mapper. Contributed-by: Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D56326 llvm-svn: 352906
* 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
* [ObjCARC] Add an new attribute, objc_externally_retainedErik Pilkington2019-01-041-1/+1
| | | | | | | | | | | | | | | | | | | | This attribute, called "objc_externally_retained", exposes clang's notion of pseudo-__strong variables in ARC. Pseudo-strong variables "borrow" their initializer, meaning that they don't retain/release it, instead assuming that someone else is keeping their value alive. If a function is annotated with this attribute, implicitly strong parameters of that function aren't implicitly retained/released in the function body, and are implicitly const. This is useful to expose for performance reasons, most functions don't need the extra safety of the retain/release, so programmers can opt out as needed. This attribute can also apply to declarations of local variables, with similar effect. Differential revision: https://reviews.llvm.org/D55865 llvm-svn: 350422
* Fix up diagnostics.Richard Trieu2018-12-141-1/+0
| | | | | | | | | | | Move some diagnostics around between Diagnostic*Kinds.td files. Diagnostics used in multiple places were moved to DiagnosticCommonKinds.td. Diagnostics listed in the wrong place (ie, Sema diagnostics listed in DiagnosticsParseKinds.td) were moved to the correct places. One diagnostic split into two so that the diagnostic string is in the .td file instead of in code. Cleaned up the diagnostic includes after all the changes. llvm-svn: 349125
* Use zip_longest for iterator range comparisons. NFC.Michael Kruse2018-12-101-10/+15
| | | | | | | | | | | | | | | | | | | Use zip_longest in two locations that compare iterator ranges. zip_longest allows the iteration using a range-based for-loop and to be symmetric over both ranges instead of prioritizing one over the other. In that latter case code have to handle the case that the first is longer than the second, the second is longer than the first, and both are of the same length, which must partially be checked after the loop. With zip_longest, this becomes an element comparison within the loop like the comparison of the elements themselves. The symmetry makes it clearer that neither the first and second iterators are handled differently. The iterators are not event used directly anymore, just the ranges. Differential Revision: https://reviews.llvm.org/D55468 llvm-svn: 348762
* Distinguish `__block` variables that are captured by escaping blocksAkira Hatanaka2018-10-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | from those that aren't. This patch changes the way __block variables that aren't captured by escaping blocks are handled: - Since non-escaping blocks on the stack never get copied to the heap (see https://reviews.llvm.org/D49303), Sema shouldn't error out when the type of a non-escaping __block variable doesn't have an accessible copy constructor. - IRGen doesn't have to use the specialized byref structure (see https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a non-escaping __block variable anymore. Instead IRGen can emit the variable as a normal variable and copy the reference to the block literal. Byref copy/dispose helpers aren't needed either. This reapplies r343518 after fixing a use-after-free bug in function Sema::ActOnBlockStmtExpr where the BlockScopeInfo was dereferenced after it was popped and deleted. rdar://problem/39352313 Differential Revision: https://reviews.llvm.org/D51564 llvm-svn: 343542
* Revert r343518.Akira Hatanaka2018-10-011-1/+0
| | | | | | | | | Bots are still failing. http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/24420 http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/12958 llvm-svn: 343531
* Distinguish `__block` variables that are captured by escaping blocksAkira Hatanaka2018-10-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | from those that aren't. This patch changes the way __block variables that aren't captured by escaping blocks are handled: - Since non-escaping blocks on the stack never get copied to the heap (see https://reviews.llvm.org/D49303), Sema shouldn't error out when the type of a non-escaping __block variable doesn't have an accessible copy constructor. - IRGen doesn't have to use the specialized byref structure (see https://clang.llvm.org/docs/Block-ABI-Apple.html#id8) for a non-escaping __block variable anymore. Instead IRGen can emit the variable as a normal variable and copy the reference to the block literal. Byref copy/dispose helpers aren't needed either. This reapplies r341754, which was reverted in r341757 because it broke a couple of bots. r341754 was calling markEscapingByrefs after the call to PopFunctionScopeInfo, which caused the popped function scope to be cleared out when the following code was compiled, for example: $ cat test.m struct A { id data[10]; }; void foo() { __block A v; ^{ (void)v; }; } This commit calls markEscapingByrefs before calling PopFunctionScopeInfo to prevent that from happening. rdar://problem/39352313 Differential Revision: https://reviews.llvm.org/D51564 llvm-svn: 343518
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-261-1/+1
| | | | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: rsmith, #clang, dblaikie Reviewed By: rsmith, #clang Subscribers: mgrang, arphaman, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D52576 llvm-svn: 343147
* [OPENMP] Add support for OMP5 requires directive + unified_address clauseKelvin Li2018-09-261-0/+16
| | | | | | | | | Add support for OMP5.0 requires directive and unified_address clause. Patches to follow will include support for additional clauses. Differential Revision: https://reviews.llvm.org/D52359 llvm-svn: 343063
* [OPENMP] Fix PR38903: Crash on instantiation of the non-dependentAlexey Bataev2018-09-131-4/+11
| | | | | | | | | | | declare reduction. If the declare reduction construct with the non-dependent type is defined in the template construct, the compiler might crash on the template instantition. Reworked the whole instantiation scheme for the declare reduction constructs to fix this problem correctly. llvm-svn: 342151
* Track definition merging on the canonical declaration even when localRichard Smith2018-09-121-15/+2
| | | | | | | | | | | | | | submodule visibility is disabled. Attempting to pick a specific declaration to make visible when the module containing the merged declaration becomes visible is error-prone, as we don't yet know which declaration we'll choose to be the definition when we are informed of the merging. This reinstates r342019, reverted in r342020. The regression previously observed after this commit was fixed in r342096. llvm-svn: 342097
OpenPOWER on IntegriCloud