summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaTemplate.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert r329684 (and follow-ups 329693, 329714). See discussion on ↵Nico Weber2018-04-101-7/+0
| | | | | | https://reviews.llvm.org/D43578. llvm-svn: 329739
* -ftime-report switch support in Clang.Andrew V. Tischenko2018-04-101-0/+7
| | | | | | | | | | The current support of the feature produces only 2 lines in report: -Some general Code Generation Time; -Total time of Backend Consumer actions. This patch extends Clang time report with new lines related to Preprocessor, Include Filea Search, Parsing, etc. Differential Revision: https://reviews.llvm.org/D43578 llvm-svn: 329684
* Fix typos in clangAlexander Kornienko2018-04-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of: archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.) Differential revision: https://reviews.llvm.org/D44188 llvm-svn: 329399
* Implement C++ DR727, which permits explicit specializations at class scope.Richard Smith2018-03-161-99/+22
| | | | | | | | | More generally, this permits a template to be specialized in any scope in which it could be defined, so this also supersedes DR44 and DR374 (the latter of which we previously only implemented in C++11 mode onwards due to unclarity as to whether it was a DR). llvm-svn: 327705
* When substituting previously-checked template arguments into a templateRichard Smith2018-03-081-12/+14
| | | | | | | | | | | | | template parameter that is an expanded parameter pack, only substitute into the current slice, not the entire pack. This reduces the checking of N template template arguments for an expanded parameter pack containing N parameters from quadratic time to linear time in the length of the pack. This is important because one (and possibly the only?) general technique for splitting a template parameter pack in linear time depends on doing this. llvm-svn: 326973
* Remove redundant casts. NFCGeorge Burgess IV2018-03-011-14/+12
| | | | | | | | | | | | | | | | | | | 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 cases where we would fail to correctly parse deduced class ↵Richard Smith2018-02-281-2/+53
| | | | | | | | | | | | | | | | template specialization types. Specifically, we would not properly parse these types within template arguments (for non-type template parameters), and in tentative parses. Fixing both of these essentially requires that we parse deduced template specialization types as types in all contexts, even in template argument lists -- in particular, tentative parsing may look ahead and annotate a deduced template specialization type before we figure out that we're actually supposed to treat the tokens as a template-name. We deal with this by simply permitting deduced template specialization types when parsing template arguments, and converting them to template template arguments. llvm-svn: 326299
* Again reverting an attempt to convert the DeclSpec enums into scoped enums.Faisal Vali2018-01-011-5/+5
| | | | | | | | | | | | - reverts r321622, r321625, and r321626. - the use of bit-fields is still resulting in warnings - even though we can use static-asserts to harden the code and ensure the bit-fields are wide enough. The bots still complain of warnings being seen. - to silence the warnings requires specifying the bit-fields with the underlying enum type (as opposed to the enum type itself), which then requires lots of unnecessary static casts of each enumerator within DeclSpec to the underlying-type, which even though could be seen as implementation details, it does hamper readability - and given the additional litterings, makes me question the value of the change. So in short - I give up (for now at least). Sorry about the noise. llvm-svn: 321628
* [NFC] Modernize enums TypeSpecifierWidth, TypeSpecifierSign & ↵Faisal Vali2018-01-011-5/+5
| | | | | | | | | | | | TypeSpecifierType into scoped enums with underlying types. - Since these enums are used as bit-fields - for the bit-fields to be interpreted as unsigned, the underlying type must be specified as unsigned. Previous failed attempt - wherein I did not specify an underlying type - was the sum of: https://reviews.llvm.org/rC321614 https://reviews.llvm.org/rC321615 llvm-svn: 321622
* Revert r321614 and r321615Faisal Vali2018-01-011-5/+5
| | | | | | | | - the enum changes to TypeSpecifierType are breaking some tests - and will require a more careful integration. Sorry about rushing these changes - thought I could sneak them in prior to heading out for new years ;) llvm-svn: 321616
* [NFC] Modernize enums TypeSpecifierWidth, TypeSpecifierSign & ↵Faisal Vali2018-01-011-5/+5
| | | | | | | | TypeSpecifierType into scoped enums. llvm-svn: 321614
* [NFC] Modernize enum 'UnqualifiedId::IdKind' into a scoped enum ↵Faisal Vali2017-12-301-12/+12
| | | | | | UnqualifiedIdKind. llvm-svn: 321574
* [NFC] Update the template-parameter parsers and analyzers to return ↵Faisal Vali2017-12-231-3/+3
| | | | | | | | NamedDecl (vs Decl) This patch addresses a FIXME and has the template-parameter processing functions return a more derived common type NamedDecl (as opposed to a type needlessly higher up in the inheritance hierarchy : Decl). llvm-svn: 321409
* Fix unused variable warning in SemaTemplate. NFCSam McCall2017-12-221-1/+1
| | | | llvm-svn: 321346
* Diagnose the various invalid decl-specifiers on nontype template parameters.Faisal Vali2017-12-221-0/+54
| | | | | | | | | | | | | The standard correctly forbids various decl-specifiers that dont make sense on non-type template parameters - such as the extern in: template<extern int> struct X; This patch implements those restrictions (in a fashion similar to the corresponding checks on function parameters within ActOnParamDeclarator). Credit goes to miyuki (Mikhail Maltsev) for drawing attention to this issue, authoring the initial versions of this patch, and supporting the effort to re-engineer it slightly. Thank you! For details of how this patch evolved please see: https://reviews.llvm.org/D40705 llvm-svn: 321339
* Remove old concepts parsing codeHubert Tong2017-12-071-37/+0
| | | | | | | | | | | | | | | | | | Summary: This is so we can implement concepts per P0734R0. Relevant failing test cases are disabled. Reviewers: hubert.reinterpretcast, rsmith, saar.raz, nwilson Reviewed By: saar.raz Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D40380 Patch by Changyu Li! llvm-svn: 319992
* Generalize "static data member instantiated" notification to cover variable ↵Richard Smith2017-12-051-1/+0
| | | | | | | | | templates too. While here, split the "point of instantiation changed" notification out from it; these two really are orthogonal changes. llvm-svn: 319727
* Now that C++17 is official (https://www.iso.org/standard/68564.html), start ↵Aaron Ballman2017-12-041-4/+4
| | | | | | changing the C++1z terminology over to C++17. NFC intended, these are all mechanical changes. llvm-svn: 319688
* MS ABI: Treat explicit instantiation definitions of dllimport function ↵Hans Wennborg2017-11-291-1/+9
| | | | | | | | | | | templates as explicit instantiation decls (PR35435) This matches MSVC's behaviour, and we already do it for class templates since r270897. Differential revision: https://reviews.llvm.org/D40621 llvm-svn: 319386
* Fix template parameter default args missed if redecledErich Keane2017-10-241-1/+6
| | | | | | | | | | | | | | | | | This bug was found via self-build on lld, and worked around here: https://reviews.llvm.org/rL316180 The issue is that the 'using' causes the lookup to pick up the first decl. However, when setting inherited default parameters, we only update 'forward', not 'backward'. SO, only the newest param list has all the information about the default arguments. This patch ensures that the list of parameters we look through checks the newest decl's template parameter list so it doesn't miss a default. Differential Revision: https://reviews.llvm.org/D39127 llvm-svn: 316405
* [C++17] Fix PR34970 - tweak overload resolution for class template ↵Faisal Vali2017-10-221-10/+11
| | | | | | | | | | | | | | | | | | | deduction-guides in line with WG21's p0620r0. In order to identify the copy deduction candidate, I considered two approaches: - attempt to determine whether an implicit guide is a copy deduction candidate by checking certain properties of its subsituted parameter during overload-resolution. - using one of the many bits (WillHaveBody) from FunctionDecl (that CXXDeductionGuideDecl inherits from) that are otherwise irrelevant for deduction guides After some brittle gymnastics w the first strategy, I settled on the second, although to avoid confusion and to give that bit a better name, i turned it into a member of an anonymous union. Given this identification 'bit', the tweak to overload resolution was a simple reordering of the deduction guide checks (in SemaOverload.cpp::isBetterOverloadCandidate), in-line with Jason Merrill's p0620r0 drafting which made it into the working paper. Concordant with that, I made sure the copy deduction candidate is always added. References: See https://bugs.llvm.org/show_bug.cgi?id=34970 See http://wg21.link/p0620r0 llvm-svn: 316292
* [Modules TS] Module ownership semantics for redeclarations.Richard Smith2017-10-101-5/+8
| | | | | | | | | | | | | | | | | When declaring an entity in the "purview" of a module, it's never a redeclaration of an entity in the purview of a default module or in no module ("in the global module"). Don't consider those other declarations as possible redeclaration targets if they're not visible, and reject any cases where we pick a prior visible declaration that violates this rule. This reinstates r315251 and r315256, reverted in r315309 and r315308 respectively, tweaked to avoid triggering a linkage calculation when declaring implicit special members (this exposed our pre-existing issue with typedef names for linkage changing the linkage of types whose linkage has already been computed and cached in more cases). A testcase for that regression has been added in r315366. llvm-svn: 315379
* Revert "[Modules TS] Module ownership semantics for redeclarations."Eric Liu2017-10-101-8/+5
| | | | | | This reverts commit r315251. See the original commit thread for reason. llvm-svn: 315309
* [Modules TS] Module ownership semantics for redeclarations.Richard Smith2017-10-091-5/+8
| | | | | | | | | | When declaring an entity in the "purview" of a module, it's never a redeclaration of an entity in the purview of a default module or in no module ("in the global module"). Don't consider those other declarations as possible redeclaration targets if they're not visible, and reject any cases where we pick a prior visible declaration that violates this rule. llvm-svn: 315251
* Remove unused variables. No functionality change.Benjamin Kramer2017-10-081-1/+0
| | | | llvm-svn: 315196
* Dependent Address Space SupportAndrew Gozillon2017-10-021-0/+5
| | | | | | | | | | | | | | This patch relates to: https://reviews.llvm.org/D33666 This adds support for template parameters to be passed to the address_space attribute. The main goal is to add further flexibility to the attribute and allow for it to be used easily with templates. The main additions are a new type (DependentAddressSpaceType) alongside its TypeLoc and its mangling. As well as the logic required to support dependent address spaces which mainly resides in TreeTransform.h and SemaType.cpp. llvm-svn: 314649
* Diagnostic specific failed condition in a static_assert.Douglas Gregor2017-09-141-14/+23
| | | | | | | | When a static_assert fails, dig out a specific condition to diagnose, using the same logic that we use to find the enable_if condition to diagnose. llvm-svn: 313315
* [NFC] Remove a cstyle cast and replace some uses of Decl with NamedDecl ↵Faisal Vali2017-08-251-2/+2
| | | | | | during the processing of TemplateParameterLists. llvm-svn: 311788
* [MS] Don't statically initialize dllimport member function pointersReid Kleckner2017-07-071-40/+40
| | | | | | | | | | | | | | | | | | | | Summary: r306137 made dllimport pointers to member functions non-constant. This is correct because a load must be executed to resolve any dllimported data. However, r306137 did not account for the use of dllimport member function pointers used as template arguments. This change re-lands r306137 with a template instantiation fix. This fixes PR33570. Reviewers: rnk, majnemer Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D34714 llvm-svn: 307446
* Fix test case in pre-C++11 mode; address Aaron Ballman's code review.Douglas Gregor2017-07-051-2/+2
| | | | llvm-svn: 307202
* Cope with Range-v3's CONCEPT_REQUIRES idiomDouglas Gregor2017-07-051-0/+34
| | | | llvm-svn: 307197
* Customize the SFINAE diagnostics for enable_if to provide the failed condition.Douglas Gregor2017-07-051-7/+131
| | | | | | | | | | | | | | | | | | | | When enable_if disables a particular overload resolution candidate, rummage through the enable_if condition to find the specific condition that caused the failure. For example, if we have something like: template< typename Iter, typename = std::enable_if_t<Random_access_iterator<Iter> && Comparable<Iterator_value_type<Iter>>>> void mysort(Iter first, Iter last) {} and we call "mysort" with "std::list<int>" iterators, we'll get a diagnostic saying that the "Random_access_iterator<Iter>" requirement failed. If we call "mysort" with "std::vector<something_not_comparable>", we'll get a diagnostic saying that the "Comparable<...>" requirement failed. llvm-svn: 307196
* [Sema] Fix a crash-on-invalid when a template parameter list has a classAkira Hatanaka2017-06-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | definition or non-reference class type. The crash occurs when there is a template parameter list in a class that is missing the closing angle bracket followed by a definition of a struct. For example: class C0 { public: template<typename T, typename T1 = T // missing closing angle bracket struct S0 {}; C0() : m(new S0<int>) {} S0<int> *m; }; This happens because the parsed struct is added to the scope of the enclosing class without having its access specifier set, which results in an assertion failure in SemaAccess.cpp later. This commit fixes the crash by adding the parsed struct to the enclosing file scope and marking structs as invalid if they are defined in template parameter lists. rdar://problem/31783961 rdar://problem/19570630 Differential Revision: https://reviews.llvm.org/D33606 llvm-svn: 306317
* Added llvm_unreachable to make sure the switch is always exhaustive.Galina Kistanova2017-06-081-0/+1
| | | | llvm-svn: 304997
* When determining the target function of an explicit instantiation, makeJohn McCall2017-06-071-19/+25
| | | | | | | | | | sure that non-template functions don't end up in the candidate set. Fixes PR14211. Patch by Don Hinton! llvm-svn: 304951
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-071-0/+3
| | | | llvm-svn: 304870
* [modules] Switch from inferring owning modules based on source location toRichard Smith2017-05-181-1/+3
| | | | | | | | | | | | | | | inferring based on the current module at the point of creation. This should result in no functional change except when building a preprocessed module (or more generally when using #pragma clang module begin/end to switch module in the middle of a file), in which case it allows us to correctly track the owning module for declarations. We can't map from FileID to module in the preprocessed module case, since all modules would have the same FileID. There are still a couple of remaining places that try to infer a module from a source location; I'll clean those up in follow-up changes. llvm-svn: 303322
* Remove unnecessary mapping from SourceLocation to Module.Richard Smith2017-05-111-3/+3
| | | | | | | | When we parse a redefinition of an entity for which we have a hidden existing declaration, make it visible in the current module instead of mapping the current source location to its containing module. llvm-svn: 302842
* Improve diagnosis of unknown template name.Richard Smith2017-05-101-2/+2
| | | | | | | | | When an undeclared identifier in a context that requires a type is followed by '<', only look for type templates when typo-correcting, tweak the diagnostic text to say that a template name (not a type name) was undeclared, and parse the template arguments when recovering from the error. llvm-svn: 302732
* When we see a '<' operator, check whether it's a probable typo for a ↵Richard Smith2017-05-101-0/+79
| | | | | | | | | | | | | | | | | | | template-id. The heuristic that we use here is: * the left-hand side must be a simple identifier or a class member access * the right-hand side must be '<' followed by either a '>' or by a type-id that cannot be an expression (in particular, not followed by '(' or '{') * there is a '>' token matching the '<' token The second condition guarantees the expression would otherwise be ill-formed. If we're confident that the user intended the name before the '<' to be interpreted as a template, diagnose the fact that we didn't interpret it that way, rather than diagnosing that the template arguments are not valid expressions. llvm-svn: 302615
* Don't mark a member as a member specialization until we know we're keeping ↵Richard Smith2017-05-091-48/+63
| | | | | | | | | | | | | | | | | | | | | | | | | the specialization. This improves our behavior in a few ways: * We now guarantee that if a member is marked as being a member specialization, there will actually be a member specialization declaration somewhere on its redeclaration chain. This fixes a crash in modules builds where we would try to check that there was a visible declaration of the member specialization and be surprised to not find any declaration of it at all. * We don't set the source location of the in-class declaration of the member specialization to the out-of-line declaration's location until we have actually finished merging them. This fixes some very silly looking diagnostics, where we'd point a "previous declaration is here" note at the same declaration we're complaining about. Ideally we wouldn't mess with the prior declaration's location at all, but too much code assumes that the first declaration of an entity is a reasonable thing to use as an indication of where it was declared, and that's not really true for a member specialization unless we fake it like this. llvm-svn: 302596
* PR32673: Don't wrap parameter packs in SubstTemplateTypeParmPackType nodes ↵Richard Smith2017-04-201-5/+16
| | | | | | | | | when forming implicit deduction guides. Doing so thwarts template type deduction. Instead, substitute the pack directly by picking "slice 0" of the resulting expansion. llvm-svn: 300805
* PR32185: Revert r291512 and add a testcase for PR32185.Richard Smith2017-04-131-19/+19
| | | | | | | | | | | | | | | This reverts an attempt to check that types match when matching a dependently-typed non-type template parameter. (This comes up when matching the parameters of a template template parameter against the parameters of a template template argument.) The matching rules here are murky at best. Our behavior after this revert is definitely wrong for certain C++17 features (for 'auto' template parameter types within the parameter list of a template template argument in particular), but our behavior before this revert is wrong for some pre-existing testcases, so reverting to our prior behavior seems like our best option. llvm-svn: 300262
* [NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped EnumFaisal Vali2017-04-011-4/+4
| | | | | | | | - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
* Fix typo, defind -> defined.Eric Christopher2017-03-311-1/+1
| | | | llvm-svn: 299148
* Correct class-template deprecation behavior-REDUXErich Keane2017-03-231-0/+7
| | | | | | | | | | | | | | | | | | Correct class-template deprecation behavior Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case: template<typename T> [[deprecated]] class Foo{}; Foo<int> f; This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute. Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute. Previous DiffRev: https://reviews.llvm.org/D27486, was reverted. This patch fixes the issues brought up here by the reverter: https://reviews.llvm.org/rL298410 Differential Revision: https://reviews.llvm.org/D31245 llvm-svn: 298634
* Revert "Correct class-template deprecation behavior"Martin Bohme2017-03-221-7/+0
| | | | | | | This reverts commit r298410 (which produces incorrect warnings, see comments on https://reviews.llvm.org/rL298410). llvm-svn: 298504
* Correct class-template deprecation behaviorErich Keane2017-03-211-0/+7
| | | | | | | | | | | | | Based on the comment in the test, and my reading of the standard, a deprecated warning should be issued in the following case: template<typename T> [[deprecated]] class Foo{}; Foo<int> f; This was not the case, because the ClassTemplateSpecializationDecl creation did not also copy the deprecated attribute. Note: I did NOT audit the complete set of attributes to see WHICH ones should be copied, so instead I simply copy ONLY the deprecated attribute. Differential Revision: https://reviews.llvm.org/D27486 llvm-svn: 298410
* Improve support for 'decltype(auto)' in template template parameter matching.Richard Smith2017-02-221-0/+13
| | | | | | | | | | | | | | | A 'decltype(auto)' parameter can match any other kind of non-type template parameter, so should be usable in place of any other parameter in a template template argument. The standard is sadly extremely unclear on how this is supposed to work, but this seems like the obviously-correct result. It's less clear whether an 'auto' parameter should be able to match 'decltype(auto)', since the former cannot be used if the latter turns out to be used for a reference type, but if we disallow that then consistency suggests we should also disallow 'auto' matching 'T' for the same reason, defeating intended use cases of the feature. llvm-svn: 295866
* PR32010: Fix template argument depth mixup when forming implicit constructorRichard Smith2017-02-211-2/+6
| | | | | | | | | | | | | template deduction guides for class template argument deduction. Ensure that we have a local instantiation scope for tracking the instantiated parameters. Additionally, unusually, we're substituting at depth 1 and leaving depth 0 alone; make sure that we don't reduce template parameter depth by 2 for inner parameters in the process. (This is probably also broken for alias templates in the case where they're expanded within a dependent context, but this patch doesn't fix that.) llvm-svn: 295696
OpenPOWER on IntegriCloud