summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaDeclCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fixit for -Wfinal-dtor-non-final-classDavid Bolvansky2019-09-031-1/+0
| | | | llvm-svn: 370740
* Added fixit notes for -Wfinal-dtor-non-final-classDavid Bolvansky2019-09-031-4/+8
| | | | llvm-svn: 370737
* [clang] Warning for non-final classes with final destructorsDavid Bolvansky2019-08-311-0/+13
| | | | | | | | | | | | Marking a class' destructor final prevents the class from being inherited from. However, it is a subtle and awkward way to express that at best, and unintended at worst. It may also generate worse code (in other compilers) than marking the class itself final. For these reasons, this revision adds a warning for nonfinal classes with final destructors, with a note to suggest marking the class final to silence the warning. See https://reviews.llvm.org/D66621 for more background. Patch by logan-5 (Logan Smith) Differential Revision: https://reviews.llvm.org/D66711 llvm-svn: 370594
* PR40674: fix assertion failure if a structured binding declaration has aRichard Smith2019-08-241-1/+2
| | | | | | | tuple-like decomposition that produces value-dependent reference bindings. llvm-svn: 369829
* Implement P1668R1Erich Keane2019-08-191-0/+3
| | | | | | | Allow inline assembly statements in unexecuted branches of constexpr functions. llvm-svn: 369281
* [SemaDeclCXX] Allow inheriting constructor declaration to specify a ↵Tan S. B.2019-08-171-1/+2
| | | | | | | | cv-qualified type Differential Revision: https://reviews.llvm.org/D47419 llvm-svn: 369196
* [Sema] Implement DR2386 for C++17 structured bindingReid Kleckner2019-08-151-7/+4
| | | | | | | | | | | | | | | | | | Allow implementations to provide complete definitions of std::tuple_size<T>, but to omit the 'value' member to signal that T is not tuple-like. The Microsoft standard library implements std::tuple_size<const T> this way. If the value member exists, clang still validates that it is an ICE, but if it does not, then the type is considered to not be tuple-like. Fixes PR33236 Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D66040 llvm-svn: 369043
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-3/+3
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942
* Don't try emitting dllexported explicitly defaulted non-trivial ctors twice ↵Hans Wennborg2019-08-021-1/+7
| | | | | | | | | | during explicit template instantiation definition (PR42857) Trying to emit the definition twice triggers an assert. Differential revision: https://reviews.llvm.org/D65579 llvm-svn: 367661
* Delay emitting dllexport explicitly defaulted members until the class is ↵Hans Wennborg2019-08-011-2/+11
| | | | | | | | | | | | | | | | | | | | fully parsed (PR40006) This is similar to r245139, but that only addressed dllexported classes. It was still possible to run into the same problem with dllexported members in an otherwise normal class (see bug). This uses the same strategy to fix: delay defining the method until the whole class has been parsed. (The easiest way to see the ordering problem is in Parser::ParseCXXMemberSpecification(): it calls ParseLexedMemberInitializers() *after* ActOnFinishCXXMemberDecls(), which was trying to define the dllexport method. Now we delay it to ActOnFinishCXXNonNestedClass() which is called after both of those.) Differential revision: https://reviews.llvm.org/D65511 llvm-svn: 367520
* When determining whether a lambda-expression is implicitly constexpr,Richard Smith2019-07-291-106/+224
| | | | | | | | | | | | check the formal rules rather than seeing if the normal checks produce a diagnostic. This fixes the handling of C++2a extensions in lambdas in C++17 mode, as well as some corner cases in earlier language modes where we issue diagnostics for things other than not satisfying the formal constexpr requirements. llvm-svn: 367254
* [OpenCL] Improve destructor support in C++ for OpenCLMarco Antognini2019-07-221-25/+25
| | | | | | | This re-applies r366422 with a fix for Bug PR42665 and a new regression test. llvm-svn: 366670
* Revert r366422: [OpenCL] Improve destructor support in C++ for OpenCLIlya Biryukov2019-07-181-25/+25
| | | | | | | | Reason: this commit causes crashes in the clang compiler when building LLVM Support with libc++, see https://bugs.llvm.org/show_bug.cgi?id=42665 for details. llvm-svn: 366429
* [OpenCL] Improve destructor support in C++ for OpenCLMarco Antognini2019-07-181-25/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch does mainly three things: 1. It fixes a false positive error detection in Sema that is similar to D62156. The error happens when explicitly calling an overloaded destructor for different address spaces. 2. It selects the correct destructor when multiple overloads for address spaces are available. 3. It inserts the expected address space cast when invoking a destructor, if needed, and therefore fixes a crash due to the unmet assertion in llvm::CastInst::Create. The following is a reproducer of the three issues: struct MyType { ~MyType() {} ~MyType() __constant {} }; __constant MyType myGlobal{}; kernel void foo() { myGlobal.~MyType(); // 1 and 2. // 1. error: cannot initialize object parameter of type // '__generic MyType' with an expression of type '__constant MyType' // 2. error: no matching member function for call to '~MyType' } kernel void bar() { // 3. The implicit call to the destructor crashes due to: // Assertion `castIsValid(op, S, Ty) && "Invalid cast!"' failed. // in llvm::CastInst::Create. MyType myLocal; } The added test depends on D62413 and covers a few more things than the above reproducer. Subscribers: yaxunl, Anastasia, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64569 llvm-svn: 366422
* [OpenCL] Update comments/diagnostics to refer to C++ for OpenCLAnastasia Stulova2019-07-181-2/+2
| | | | | | | | | Clang doesn't implement OpenCL C++, change the comments to reflect that. Differential Revision: https://reviews.llvm.org/D64867 llvm-svn: 366421
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-161-4/+4
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
* [Concepts] Concept definitions (D40381)Saar Raz2019-07-101-1/+1
| | | | | | | 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
* [cxx2a] P0624R2 fix: only lambdas with no lambda-capture are ↵David Blaikie2019-07-081-1/+1
| | | | | | | | | | | | | | default-constructible and assignable. This is a fix for rG864949 which only disabled default construction and assignment for lambdas with capture-defaults, where the C++2a draft disables them for lambdas with any lambda-capture at all. Patch by Logan Smith! Differential Revision: https://reviews.llvm.org/D64058 llvm-svn: 365406
* [clang] Small improvments after Adding APValue to ConstantExprGauthier Harnisch2019-06-211-2/+0
| | | | | | | | | | | | | | | | | | | | | | | Summary: this patch has multiple small improvements related to the APValue in ConstantExpr. changes: - APValue in ConstantExpr are now cleaned up using ASTContext::addDestruction instead of there own system. - ConstantExprBits Stores the ValueKind of the result beaing stored. - VerifyIntegerConstantExpression now stores the evaluated value in ConstantExpr. - the Constant Evaluator uses the stored value of ConstantExpr when available. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63376 llvm-svn: 364011
* [Sema] Diagnose addr space mismatch while constructing objectsAnastasia Stulova2019-06-201-1/+8
| | | | | | | | | | | | | | If we construct an object in some arbitrary non-default addr space it should fail unless either: - There is an implicit conversion from the address space to default /generic address space. - There is a matching ctor qualified with an address space that is either exactly matching or convertible to the address space of an object. Differential Revision: https://reviews.llvm.org/D62156 llvm-svn: 363944
* [C++20] add Basic consteval specifierGauthier Harnisch2019-06-141-28/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Factor out repeated code to build a DeclRefExpr and mark it referenced.Richard Smith2019-06-041-2/+2
| | | | llvm-svn: 362537
* PR39728: When completing a class, complete the destructor first.Richard Smith2019-05-311-39/+53
| | | | | | | | | We need to know whether the destructor is trivial in order to tell whether other parts of the class are valid (in particular, this affects whether the type is a literal type, which affects whether defaulted special members can be declared constexpr or are implicitly constexpr). llvm-svn: 362184
* Add Attribute NoThrow as an Exception Specifier TypeErich Keane2019-05-301-0/+2
| | | | | | | | | | | | | | | In response to https://bugs.llvm.org/show_bug.cgi?id=33235, it became clear that the current mechanism of hacking through checks for the exception specification of a function gets confused really quickly when there are alternate exception specifiers. This patch introcues EST_NoThrow, which is the equivilent of EST_noexcept when caused by EST_noThrow. The existing implementation is left in place to cover functions with no FunctionProtoType. Differential Revision: https://reviews.llvm.org/D62435 llvm-svn: 362119
* Part of P1091R3: permit structured bindings to be declared 'static' andRichard Smith2019-05-221-5/+25
| | | | | | 'thread_local' in C++20. llvm-svn: 361424
* Implement __builtin_LINE() et. al. to support source location capture.Eric Fiselier2019-05-161-3/+3
| | | | | | | | | | | | | | | | | Summary: This patch implements the source location builtins `__builtin_LINE(), `__builtin_FUNCTION()`, `__builtin_FILE()` and `__builtin_COLUMN()`. These builtins are needed to implement [`std::experimental::source_location`](https://rawgit.com/cplusplus/fundamentals-ts/v2/main.html#reflection.src_loc.creation). With the exception of `__builtin_COLUMN`, GCC also implements these builtins, and Clangs behavior is intended to match as closely as possible. Reviewers: rsmith, joerg, aaron.ballman, bogner, majnemer, shafik, martong Reviewed By: rsmith Subscribers: rnkovacs, loskutov, riccibruno, mgorny, kunitoki, alexr, majnemer, hfinkel, cfe-commits Differential Revision: https://reviews.llvm.org/D37035 llvm-svn: 360937
* [c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith2019-05-131-15/+23
| | | | | | | | | | | | | evaluation. This reinstates r360559, reverted in r360580, with a fix to avoid crashing if evaluation-for-overflow mode encounters a virtual call on an object of a class with a virtual base class, and to generally not try to resolve virtual function calls to objects whose (notional) vptrs are not readable. (The standard rules are unclear here, but this seems like a reasonable approach.) llvm-svn: 360635
* Revert r360559 "[c++20] P1064R0: Allow virtual function calls in constant ↵Hans Wennborg2019-05-131-23/+15
| | | | | | | | | expression evaluation." This caused Chromium builds to hit the new "can't handle virtual calls with virtual bases" assert. Reduced repro coming up. llvm-svn: 360580
* [c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith2019-05-131-15/+23
| | | | | | evaluation. llvm-svn: 360559
* [Sema] Mark array element destructors referenced during initializationErik Pilkington2019-05-101-6/+11
| | | | | | | | | | | | This fixes a crash where we would neglect to mark a destructor referenced for an __attribute__((no_destory)) array. The destructor is needed though, since if an exception is thrown we need to cleanup the elements. rdar://48462498 Differential revision: https://reviews.llvm.org/D61165 llvm-svn: 360446
* [c++20] Add support for explicit(bool), as described in P0892R2.Richard Smith2019-05-091-18/+41
| | | | | | | | Patch by Tyker! Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360311
* [c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whoseRichard Smith2019-05-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | template name is not visible to unqualified lookup. In order to support this without a severe degradation in our ability to diagnose typos in template names, this change significantly restructures the way we handle template-id-shaped syntax for which lookup of the template name finds nothing. Instead of eagerly diagnosing an undeclared template name, we now form a placeholder template-name representing a name that is known to not find any templates. When the parser sees such a name, it attempts to disambiguate whether we have a less-than comparison or a template-id. Any diagnostics or typo-correction for the name are delayed until its point of use. The upshot should be a small improvement of our diagostic quality overall: we now take more syntactic context into account when trying to resolve an undeclared identifier on the left hand side of a '<'. In fact, this works well enough that the backwards-compatible portion (for an undeclared identifier rather than a lookup that finds functions but no function templates) is enabled in all language modes. llvm-svn: 360308
* Split ActOnCallExpr into an ActOnCallExpr to be called by the parser,Richard Smith2019-05-081-3/+3
| | | | | | | and a BuildCallExpr to be called internally within Sema to build / rebuild calls. llvm-svn: 360217
* Revert r359949 "[clang] adding explicit(bool) from c++2a"Hans Wennborg2019-05-061-41/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* P1286R2: Remove restriction that the exception specification of aRichard Smith2019-05-061-66/+19
| | | | | | defaulted special member matches the implicit exception specification. llvm-svn: 360011
* [clang] adding explicit(bool) from c++2aNicolas Lesser2019-05-041-18/+41
| | | | | | | | | | | | | | | | | | | | | 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
* [COFF, ARM64] Fix ABI implementation of struct returnsMandeep Singh Grang2019-05-031-1/+4
| | | | | | | | | | | | | | | | | | Summary: Related llvm patch: D60348. Patch co-authored by Sanjin Sijaric. Reviewers: rnk, efriedma, TomTan, ssijaric, ostannard Reviewed By: efriedma Subscribers: dmajor, richard.townsend.arm, ostannard, javed.absar, kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60349 llvm-svn: 359932
* [MinGW] Do dllexport inline methods in template instantiationMartin Storsjo2019-04-261-2/+5
| | | | | | | | | | | | | | | | | | Normally, in MinGW mode, inline methods aren't dllexported. However, in the case of a dllimported template instantiation, the inline methods aren't instantiated locally, but referenced from the instantiation. Therefore, those methods also need to be dllexported, in the case of an instantiation. GCC suffers from the same issue, reported at [1], but the issue is still unresolved there. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89088 Differential Revision: https://reviews.llvm.org/D61176 llvm-svn: 359343
* [MinGW] Fix dllexport of explicit template instantiationMartin Storsjo2019-04-261-2/+4
| | | | | | | | | | | | | | | | | Contrary to MSVC, GCC/MinGW needs to have the dllexport attribute on the template instantiation declaration, not on the definition. Previously clang never marked explicit template instantiations as dllexport in MinGW mode, if the instantiation had a previous declaration, regardless of where the attribute was placed. This makes Clang behave like GCC in this regard, and allows using the same attribute form for both MinGW compilers. This fixes PR40256. Differential Revision: https://reviews.llvm.org/D61118 llvm-svn: 359285
* [c++2a] Implement semantic restrictions for 'export' declarations.Richard Smith2019-04-221-0/+3
| | | | llvm-svn: 358932
* [Sema][NFCI] Don't allocate storage for the various ↵Bruno Ricci2019-03-251-15/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CorrectionCandidateCallback unless we are going to do some typo correction The various CorrectionCandidateCallbacks are currently heap-allocated unconditionally. This was needed because of delayed typo correction. However these allocations represent currently 15.4% of all allocations (number of allocations) when parsing all of Boost (!), mostly because of ParseCastExpression, ParseStatementOrDeclarationAfterAttrtibutes and isCXXDeclarationSpecifier. Note that all of these callback objects are small. Let's not do this. Instead initially allocate the callback on the stack, and only do a heap allocation if we are going to do some typo correction. Do this by: 1. Adding a clone function to each callback, which will do a polymorphic clone of the callback. This clone function is required to be implemented by every callback (of which there is a fair amount). Make sure this is the case by making it pure virtual. 2. Use this clone function when we are going to try to correct a typo. This additionally cut the time of -fsyntax-only on all of Boost by 0.5% (not that much, but still something). No functional changes intended. Differential Revision: https://reviews.llvm.org/D58827 Reviewed By: rnk llvm-svn: 356925
* Reapply "Make static counters in ASTContext non-static." with fixes.Alexander Kornienko2019-02-251-12/+12
| | | | | | This reverts commit e50038e4dc53caee1acc811362ac0b15e00ef5eb. llvm-svn: 354827
* Revert "Make static counters in ASTContext non-static."Vlad Tsyrklevich2019-02-251-12/+12
| | | | | | | This reverts commit r354795, I suspect it is causing test failures on MSan sanitizer bots. llvm-svn: 354812
* Make static counters in ASTContext non-static.Alexander Kornienko2019-02-251-12/+12
| | | | | | | | | | | | | | | | | | Summary: Fixes a data race and makes it possible to run clang-based tools in multithreaded environment with TSan. Reviewers: ilya-biryukov, riccibruno Reviewed By: riccibruno Subscribers: riccibruno, jfb, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58612 llvm-svn: 354795
* Fix implementation of [temp.local]p4.Richard Smith2019-02-151-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | When a template-name is looked up, we need to give injected-class-name declarations of class templates special treatment, as they denote a template rather than a type. Previously we achieved this by applying a filter to the lookup results after completing name lookup, but that is incorrect in various ways, not least of which is that it lost all information about access and how members were named, and the filtering caused us to generally lose all ambiguity errors between templates and non-templates. We now preserve the lookup results exactly, and the few places that need to map from a declaration found by name lookup into a declaration of a template do so explicitly. Deduplication of repeated lookup results of the same injected-class-name declaration is done by name lookup instead of after the fact. This reinstates r354091, which was previously reverted in r354097 because it exposed bugs in lldb and compiler-rt. Those bugs were fixed in r354173 and r354174 respectively. llvm-svn: 354176
* Revert "Fix implementation of [temp.local]p4."Francis Visoiu Mistrih2019-02-151-0/+1
| | | | | | | | | This reverts commit 40bd10b770813bd1471d46f514545437516aa4ba. This seems to now emit an error when building the sanitizer tests: http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/53965/consoleFull. llvm-svn: 354097
* Fix implementation of [temp.local]p4.Richard Smith2019-02-151-1/+0
| | | | | | | | | | | | | | | | | | | | When a template-name is looked up, we need to give injected-class-name declarations of class templates special treatment, as they denote a template rather than a type. Previously we achieved this by applying a filter to the lookup results after completing name lookup, but that is incorrect in various ways, not least of which is that it lost all information about access and how members were named, and the filtering caused us to generally lose all ambiguity errors between templates and non-templates. We now preserve the lookup results exactly, and the few places that need to map from a declaration found by name lookup into a declaration of a template do so explicitly. Deduplication of repeated lookup results of the same injected-class-name declaration is done by name lookup instead of after the fact. llvm-svn: 354091
* [Sema] Fix a crash in access checking for deduction guidesIlya Biryukov2019-02-121-1/+5
| | | | | | | | | | | | | | | | Summary: See the added test for a repro. Reviewers: sammccall Reviewed By: sammccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58111 llvm-svn: 353840
* [Sema][ObjC] Allow declaring ObjC pointer members with non-trivialAkira Hatanaka2019-02-021-3/+37
| | | | | | | | | | | | | | | ownership qualifications in C++ unions under ARC. An ObjC pointer member with non-trivial ownership qualifications causes all of the defaulted special functions of the enclosing union to be defined as deleted, except when the member has an in-class initializer, the default constructor isn't defined as deleted. rdar://problem/34213306 Differential Revision: https://reviews.llvm.org/D57438 llvm-svn: 352949
* Revert "[Sema] Make canPassInRegisters return true if the CXXRecordDecl passed"Akira Hatanaka2019-02-011-3/+0
| | | | | | | | | | | This reverts commit r350920 as it is not clear whether we should force a class to be returned in registers when copy and move constructors are both deleted. For more background, see the following discussion: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190128/259907.html llvm-svn: 352822
OpenPOWER on IntegriCloud