summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplateInstantiate.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[Concepts] Constraint Enforcement & Diagnostics"Vlad Tsyrklevich2019-10-281-21/+18
| | | | | This reverts commit ffa214ef22892d75340dc6720271863901dc2c90, it was causing ASAN test failures on sanitizer-x86_64-linux-bootstrap.
* [Concepts] Constraint Enforcement & DiagnosticsSaar Raz2019-10-251-18/+21
| | | | | | Part of the C++20 concepts implementation effort. - Associated constraints (requires clauses, currently) are now enforced when instantiating/specializing templates and when considering partial specializations and function overloads. - Elaborated diagnostics give helpful insight as to why the constraints were not satisfied. Phabricator: D41569
* [c++20] Add rewriting from comparison operators to <=> / ==.Richard Smith2019-10-191-0/+7
| | | | | | | | | | | | | | | | | This adds support for rewriting <, >, <=, and >= to a normal or reversed call to operator<=>, for rewriting != to a normal or reversed call to operator==, and for rewriting <=> and == to reversed forms of those same operators. Note that this is a breaking change for various C++17 code patterns, including some in use in LLVM. The most common patterns (where an operator== becomes ambiguous with a reversed form of itself) are still accepted under this patch, as an extension (with a warning). I'm hopeful that we can get the language rules fixed before C++20 ships, and the extension warning is aimed primarily at providing data to inform that decision. llvm-svn: 375306
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-151-2/+49
| | | | | | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) llvm-svn: 374903
* Revert 374882 "[Concepts] Concept Specialization Expressions"Nico Weber2019-10-151-49/+2
| | | | | | | | | | This reverts commit ec87b003823d63f3342cf648f55a134c1522e612. The test fails on Windows, see e.g. http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/11533/steps/stage%201%20check/logs/stdio Also revert follow-up r374893. llvm-svn: 374899
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-151-2/+49
| | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is referenced with arguments, and tests thereof. llvm-svn: 374882
* [NFCI]Create CommonAttributeInfo Type as base type of *Attr and ParsedAttr.Erich Keane2019-09-131-3/+2
| | | | | | | | | | | | 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
* Improve behavior in the case of stack exhaustion.Richard Smith2019-08-261-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Clang performs various recursive operations (such as template instantiation), and may use non-trivial amounts of stack space in each recursive step (for instance, due to recursive AST walks). While we try to keep the stack space used by such steps to a minimum and we have explicit limits on the number of such steps we perform, it's impractical to guarantee that we won't blow out the stack on deeply recursive template instantiations on complex ASTs, even with only a moderately high instantiation depth limit. The user experience in these cases is generally terrible: we crash with no hint of what went wrong. Under this patch, we attempt to do better: * Detect when the stack is nearly exhausted, and produce a warning with a nice template instantiation backtrace, telling the user that we might run slowly or crash. * For cases where we're forced to trigger recursive template instantiation in arbitrarily-deeply-nested contexts, check whether we're nearly out of stack space and allocate a new stack (by spawning a new thread) after producing the warning. Reviewers: rnk, aaron.ballman Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66361 llvm-svn: 369940
* PR42104: Support instantiations of lambdas that implicitly captureRichard Smith2019-06-041-5/+9
| | | | | | | | | | | | | | | | | packs. Two changes: * Track odr-use via FunctionParmPackExprs to properly handle dependent odr-uses of packs in generic lambdas. * Do not instantiate implicit captures; instead, regenerate them by instantiating the body of the lambda. This is necessary to distinguish between cases where only one element of a pack is captured and cases where the entire pack is captured. This reinstates r362358 (reverted in r362375) with a fix for an uninitialized variable use in UpdateMarkingForLValueToRValue. llvm-svn: 362531
* Revert rL362358 : PR42104: Support instantiations of lambdas that implicitly ↵Simon Pilgrim2019-06-031-9/+5
| | | | | | | | | | | | | | | | capture packs. Two changes: * Track odr-use via FunctionParmPackExprs to properly handle dependent odr-uses of packs in generic lambdas. * Do not instantiate implicit captures; instead, regenerate them by instantiating the body of the lambda. This is necessary to distinguish between cases where only one element of a pack is captured and cases where the entire pack is captured. ........ Fixes http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win buildbot failures llvm-svn: 362375
* PR42104: Support instantiations of lambdas that implicitly captureRichard Smith2019-06-031-5/+9
| | | | | | | | | | | | | | packs. Two changes: * Track odr-use via FunctionParmPackExprs to properly handle dependent odr-uses of packs in generic lambdas. * Do not instantiate implicit captures; instead, regenerate them by instantiating the body of the lambda. This is necessary to distinguish between cases where only one element of a pack is captured and cases where the entire pack is captured. llvm-svn: 362358
* [c++20] P0780R2: Support pack-expansion of init-captures.Richard Smith2019-05-211-24/+32
| | | | | | | | | | | This permits an init-capture to introduce a new pack: template<typename ...T> auto x = [...a = T()] { /* a is a pack */ }; To support this, the mechanism for allowing ParmVarDecls to be packs has been extended to support arbitrary local VarDecls. llvm-svn: 361300
* [c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith2019-05-131-1/+11
| | | | | | | | | | | | | 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-11/+1
| | | | | | | | | 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-1/+11
| | | | | | evaluation. llvm-svn: 360559
* make -ftime-trace also print template argumentsLubos Lunak2019-05-121-1/+5
| | | | | | | | | Without this, I get e.g. 'PerformPendingInstantiations' -> 'std::fill', now I get 'std::fill<unsigned long *, int>'. Differential Revision: https://reviews.llvm.org/D61822 llvm-svn: 360539
* Replace ad-hoc tracking of pattern for an instantiated class-scopeRichard Smith2019-05-021-3/+2
| | | | | | | | | | 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
* Simplify exclusion of nested classes from extern template instantiation, NFCReid Kleckner2019-04-291-8/+7
| | | | | | | | | | | | | | | | | | | | | Summary: This simplifies three checks for MS ABI, Win Itanium, or Win GNU to just "is Windows". The question remains, however, if this is really the correct thing to do. We could, for example, only not consider inner classes to be externally available if the outer class has a dllexport annotation. However, I will leave that as future work. Reviewers: hans, mstorsjo Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61278 llvm-svn: 359507
* [MinGW] Don't let template instantiation declarations cover nested classesMartin Storsjo2019-04-261-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An explicit template instantiation declaration used to let callers assume both outer and nested classes instantiations were defined in a different translation unit. If the instantiation is marked dllexport, only the outer class is exported, but the caller will try to reference the instantiation of both outer and inner classes. This makes MinGW mode match both MSVC and Windows Itanium, by having instantations only cover the outer class, and locally emitting definitions of the nested classes. Windows Itanium was changed to use this behavious in SVN r300804. This deviates from what GCC does, but should be safe (and only inflate the object file size a bit, but MSVC and Windows Itanium modes do the same), and fixes cases where inner classes aren't dllexported. This fixes missing references in combination with dllexported/imported template intantiations. GCC suffers from the same issue, reported at [1], but the issue is still unresolved there. The issue can probably be solved either by making dllexport cover all nested classes as well, or this way (matching MSVC). [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89087 Differential Revision: https://reviews.llvm.org/D61175 llvm-svn: 359342
* PR41607: Don't forget to substitute outer template arguments into aRichard Smith2019-04-261-5/+9
| | | | | | class-scope explicit specialization of a class template. llvm-svn: 359266
* Check i < FD->getNumParams() before queryingDmitri Gribenko2019-04-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: As was already stated in a previous comment, the parameter isn't necessarily referring to one of the DeclContext's parameter. We should check the index is within the range to avoid out-of-boundary access. Reviewers: gribozavr, rsmith, lebedev.ri Reviewed By: gribozavr, rsmith Subscribers: lebedev.ri, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60055 Patch by Violet. llvm-svn: 358134
* Adds `-ftime-trace` option to clang that produces Chrome `chrome://tracing` ↵Anton Afanasyev2019-03-301-0/+6
| | | | | | | | | | | | | | compatible JSON profiling output dumps. This change adds hierarchical "time trace" profiling blocks that can be visualized in Chrome, in a "flame chart" style. Each profiling block can have a "detail" string that for example indicates the file being processed, template name being instantiated, function being optimized etc. This is taken from GitHub PR: https://github.com/aras-p/llvm-project-20170507/pull/2 Patch by Aras Pranckevičius. Differential Revision: https://reviews.llvm.org/D58675 llvm-svn: 357340
* 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
* [OpenCL] Add generic AS to 'this' pointerMikael Nilsson2018-12-131-5/+5
| | | | | | | | | | | | | Address spaces are cast into generic before invoking the constructor. Added support for a trailing Qualifiers object in FunctionProtoType. Note: This recommits the previously reverted patch, but now it is commited together with a fix for lldb. Differential Revision: https://reviews.llvm.org/D54862 llvm-svn: 349019
* Revert "[OpenCL] Add generic AS to 'this' pointer"Mikael Nilsson2018-12-121-5/+5
| | | | | | Reverting because the patch broke lldb. llvm-svn: 348931
* [OpenCL] Add generic AS to 'this' pointerMikael Nilsson2018-12-121-5/+5
| | | | | | | | | | Address spaces are cast into generic before invoking the constructor. Added support for a trailing Qualifiers object in FunctionProtoType. Differential Revision: https://reviews.llvm.org/D54862 llvm-svn: 348927
* Fix clang -Wimplicit-fallthrough warnings across llvm, NFCReid Kleckner2018-11-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch should not introduce any behavior changes. It consists of mostly one of two changes: 1. Replacing fall through comments with the LLVM_FALLTHROUGH macro 2. Inserting 'break' before falling through into a case block consisting of only 'break'. We were already using this warning with GCC, but its warning behaves slightly differently. In this patch, the following differences are relevant: 1. GCC recognizes comments that say "fall through" as annotations, clang doesn't 2. GCC doesn't warn on "case N: foo(); default: break;", clang does 3. GCC doesn't warn when the case contains a switch, but falls through the outer case. I will enable the warning separately in a follow-up patch so that it can be cleanly reverted if necessary. Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu Differential Revision: https://reviews.llvm.org/D53950 llvm-svn: 345882
* [AST] Refactor PredefinedExprBruno Ricci2018-10-271-1/+1
| | | | | | | | | | | | | | | | | | Make the following changes to PredefinedExpr: 1. Move PredefinedExpr below StringLiteral so that it can use its definition. 2. Rename IdentType to IdentKind to be more in line with clang's conventions, and propagate the change to its users. 3. Move the location and the IdentKind into the newly available space of the bit-fields of Stmt. 4. Only store the function name when needed. When parsing all of Boost, of the 1357 PredefinedExpr 919 have no function name. Differential Revision: https://reviews.llvm.org/D53605 Reviewed By: rjmccall llvm-svn: 345460
* [clang] Add the exclude_from_explicit_instantiation attributeLouis Dionne2018-10-041-4/+14
| | | | | | | | | | | | | | | | | | | | | | Summary: This attribute allows excluding a member of a class template from being part of an explicit template instantiation of that class template. This also makes sure that code using such a member will not take for granted that an external instantiation exists in another translation unit. The attribute was discussed on cfe-dev at [1] and is primarily motivated by the removal of always_inline in libc++ to control what's part of the ABI (see links in [1]). [1]: http://lists.llvm.org/pipermail/cfe-dev/2018-August/059024.html rdar://problem/43428125 Reviewers: rsmith Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D51789 llvm-svn: 343790
* PR38627: Fix handling of exception specification adjustment forRichard Smith2018-09-051-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | destructors. We previously tried to patch up the exception specification after completing the class, which went wrong when the exception specification was needed within the class body (in particular, by a friend redeclaration of the destructor in a nested class). We now mark the destructor as having a not-yet-computed exception specification immediately after creating it. This requires delaying various checks against the exception specification (where we'd previously have just got the wrong exception specification, and now find we have an exception specification that we can't compute yet) when those checks fire while the class is being defined. This also exposed an issue that we were missing a CodeSynthesisContext for computation of exception specifications (otherwise we'd fail to make the module containing the definition of the class visible when computing its members' exception specs). Adding that incidentally also gives us a diagnostic quality improvement. This has also exposed an pre-existing problem: making the exception specification evaluation context a non-SFINAE context (as it should be) results in a bootstrap failure; PR38850 filed for this. llvm-svn: 341499
* Port getLocEnd -> getEndLocStephen Kelly2018-08-091-2/+2
| | | | | | | | | | Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50351 llvm-svn: 339386
* Port getLocStart -> getBeginLocStephen Kelly2018-08-091-2/+2
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
* Remove trailing spaceFangrui Song2018-07-301-146/+146
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [clang:sema] de-duplicate getDepthAndIndex helpersNick Desaulniers2018-07-251-13/+0
| | | | | | | | | | | | | | | | | | | Summary: Continuing off of: https://reviews.llvm.org/D38382 Fixes: https://bugs.llvm.org/show_bug.cgi?id=12176 Reviewers: srhines, pirama, vsk Reviewed By: vsk Subscribers: cfe-commits, vsk, maitesin Differential Revision: https://reviews.llvm.org/D49760 llvm-svn: 337944
* [Sema] Fix crash on BlockExprs in a default member initializersErik Pilkington2018-07-231-0/+5
| | | | | | | | | | | | Clang would crash when instantiating a BlockDecl that appeared in a default-member-initializer of a class template. Fix this by deferring the instantiation until we instantate the BlockExpr. rdar://41200624 Differential revision: https://reviews.llvm.org/D49688 llvm-svn: 337766
* AttributeList de-listifying:Erich Keane2018-07-121-1/+1
| | | | | | | | | | | Basically, "AttributeList" loses all list-like mechanisms, ParsedAttributes is switched to use a TinyPtrVector (and a ParsedAttributesView is created to have a non-allocating attributes list). DeclaratorChunk gets the later kind, Declarator/DeclSpec keep ParsedAttributes. Iterators are added to the ParsedAttribute types so that for-loops work. llvm-svn: 336945
* [Sema] Produce diagnostics for attribute 'trivial_abi' that appearsAkira Hatanaka2018-06-191-4/+0
| | | | | | | | | | | | after the closing brace of a class declaration. Merge the two call sites of checkIllFormedTrivialABIStruct and sink it into CheckCompletedCXXClass so that it is called after the attribute has been attached to the CXXRecordDecl. rdar://problem/40873297 llvm-svn: 335021
* [Sema] Fix assertion when constructor is disabled with partially specialized ↵Volodymyr Sapsai2018-05-161-102/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | template. The added test case was triggering assertion > Assertion failed: (!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set to a class template partial specialization!"), function setInstantiationOf, file clang/include/clang/AST/DeclTemplate.h, line 1825. It was happening with ClassTemplateSpecializationDecl `enable_if_not_same<int, int>`. Because this template is specialized for equal types not to have a definition, it wasn't instantiated and its specialization kind remained TSK_Undeclared. And because it was implicit instantiation, we didn't mark the decl as invalid. So when we try to find the best matching partial specialization the second time, we hit the assertion as partial specialization is already set. Fix by reusing stored partial specialization when available, instead of looking for the best match every time. rdar://problem/39524996 Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46909 llvm-svn: 332509
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-29/+29
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* Sink PrettyDeclStackTrace down to the AST libraryJordan Rose2018-03-231-4/+4
| | | | | | | ...and add some very basic stack trace entries for module building. This would have helped track down rdar://problem/38434694 sooner. llvm-svn: 328276
* Remove redundant casts. NFCGeorge Burgess IV2018-03-011-1/+1
| | | | | | | | | | | | | | | | | | | So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and `dyn_cast`s for fun. This is a portion of what it found for clang; I plan to do similar cleanups in LLVM and other subprojects when I find time. Because of the volume of changes, I explicitly avoided making any change that wasn't highly local and obviously correct to me (e.g. we still have a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading is a thing and the cast<Bar> did actually change the type -- just up the class hierarchy). I also tried to leave the types we were cast<>ing to somewhere nearby, in cases where it wasn't locally obvious what we were dealing with before. llvm-svn: 326416
* Fix a couple of places where we assumed that non-type template parameters ↵Richard Smith2018-02-141-5/+5
| | | | | | are always rvalues. llvm-svn: 325095
* [Templight] Template Instantiation ObserverGabor Horvath2018-02-101-2/+17
| | | | | | | | | | | | | | | | | | | | | This patch adds a base-class called TemplateInstantiationObserver which gets notified whenever a template instantiation is entered or exited during semantic analysis. This is a base class used to implement the template profiling and debugging tool called Templight (https://github.com/mikael-s-persson/templight). The patch also makes a few more changes: * ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h). * CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function). * TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers. * Notifications to the template-inst observer are added at the key places where templates are instantiated. Patch by: Abel Sinkovics! Differential Revision: https://reviews.llvm.org/D5767 llvm-svn: 324808
* Add support for attribute 'trivial_abi'.Akira Hatanaka2018-02-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | The 'trivial_abi' attribute can be applied to a C++ class, struct, or union. It makes special functions of the annotated class (the destructor and copy/move constructors) to be trivial for the purpose of calls and, as a result, enables the annotated class or containing classes to be passed or returned using the C ABI for the underlying type. When a type that is considered trivial for the purpose of calls despite having a non-trivial destructor (which happens only when the class type or one of its subobjects is a 'trivial_abi' class) is passed to a function, the callee is responsible for destroying the object. For more background, see the discussions that took place on the mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-November/055955.html http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180101/thread.html#214043 rdar://problem/35204524 Differential Revision: https://reviews.llvm.org/D41039 llvm-svn: 324269
* Generalize "static data member instantiated" notification to cover variable ↵Richard Smith2017-12-051-1/+1
| | | | | | | | | templates too. While here, split the "point of instantiation changed" notification out from it; these two really are orthogonal changes. llvm-svn: 319727
* Refactor functions PrintTemplateArgumentListSerge Pavlov2017-11-281-4/+4
| | | | | | | | | | | These functions were defined as static members of TemplateSpecializationType. Now they are moved to namespace level. Previously there were different implementations for lists containing TemplateArgument and TemplateArgumentLoc, now these implementations share the same code. This change is a result of refactoring patch D40508. NFC. llvm-svn: 319178
* [Sema] Prevent InstantiateClass from checking unrelated exception specs.Volodymyr Sapsai2017-09-211-9/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Sema::InstantiateClass should check only exception specs added during class instantiation and ignore already present delayed specs. This fixes a case where we instantiate a class before parsing member initializers, check exceptions for a different class and fail to find a member initializer. Which is required for comparing exception specs for explicitly-defaulted and implicit default constructor. With the fix we are still checking exception specs but only after member initializers are present. Removing errors in crash-unparsed-exception.cpp is acceptable according to discussion in PR24000 because other compilers accept code in crash-unparsed-exception.cpp as valid. rdar://problem/34167492 Reviewers: davide, rsmith Reviewed By: rsmith Subscribers: dim, cfe-commits Differential Revision: https://reviews.llvm.org/D37881 llvm-svn: 313906
* PR10147: When substituting a template template argument, substitute in the mostRichard Smith2017-08-291-9/+5
| | | | | | | recent (non-friend) declaration to pick up the right set of default template arguments. llvm-svn: 312049
* PR33552: Distinguish between declarations that are owned by no module andRichard Smith2017-06-231-2/+2
| | | | | | | | | | | | | | | | | | | declarations that are owned but unconditionally visible. This allows us to set declarations as visible even if they have a local owning module, without losing information. In turn, that means that our Objective-C support can keep on incorrectly assuming the "hidden" bit on the declaration is the whole story with regard to name visibility. This will also be useful once we support the C++ Modules TS export semantics. Objective-C name visibility is still incorrect in any case where the "hidden" bit is not the complete story: for instance, in Objective-C++ the set of visible categories will be wrong during template instantiation, and with local submodule visibility enabled it will be wrong when building modules. Fixing that will require a major overhaul of how visibility is handled for Objective-C (and particularly for categories). llvm-svn: 306075
* [c++1z] Support deducing B in noexcept(B).Richard Smith2017-06-071-8/+14
| | | | | | | | This is not required by the standard (yet), but there seems to be reasonable support for this being a defect according to CWG discussion, and libstdc++ 7.1 relies on it working. llvm-svn: 304946
OpenPOWER on IntegriCloud