summaryrefslogtreecommitdiffstats
path: root/clang/test/CXX/basic/basic.lookup
Commit message (Collapse)AuthorAgeFilesLines
* Add -std=c++20 flag, replace C++2a with C++20 throughout the ClangRichard Smith2020-02-191-2/+2
| | | | | | | | | | | | | user interface and documentation, and update __cplusplus for C++20. WG21 considers the C++20 standard to be finished (even though it still has some more steps to pass through in the ISO process). The old flag names are accepted for compatibility, as usual, and we still have lots of references to C++2a in comments and identifiers; those can be cleaned up separately. (cherry picked from commit 24ad121582454e625bdad125c90d9ac0dae948c8)
* When diagnosing the lack of a viable conversion function, also listRichard Smith2020-01-091-1/+1
| | | | | | | | | | | | | | explicit functions that are not candidates. It's not always obvious that the reason a conversion was not possible is because the function you wanted to call is 'explicit', so explicitly say if that's the case. It would be nice to rank the explicit candidates higher in the diagnostic if an implicit conversion sequence exists for their arguments, but unfortunately we can't determine that without potentially triggering non-immediate-context errors that we're not permitted to produce.
* [c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whoseRichard Smith2019-05-091-9/+51
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Sema] ADL: Associated namespaces for class types and enumeration types (CWG ↵Bruno Ricci2019-04-221-5/+13
| | | | | | | | | | | | | | | | | | | 1691) CWG 1691 changed the definition of the namespaces associated with a class type or enumeration type. For a class type, the associated namespaces are the innermost enclosing namespaces of the associated classes. For an enumeration type, the associated namespace is the innermost enclosing namespace of its declaration. This also fixes CWG 1690 and CWG 1692. Differential Revision: https://reviews.llvm.org/D60573 Reviewed By: rjmccall, rsmith llvm-svn: 358882
* [Sema][NFC] Add more tests for the behavior of argument-dependent name lookupBruno Ricci2019-04-225-0/+565
| | | | | | | | | | | | | | | | | | | | | | | The goal here is to exercise each rule in [basic.lookup.argdep] at least once. These new tests expose what I believe are 2 issues: 1. CWG 1691 needs to be implemented (p2: [...] Its associated namespaces are the innermost enclosing namespaces of its associated classes [...]) The corresponding tests are adl_class_type::X2 and adl_class_type::X5. 2. The end of paragraph 2 ([...] Additionally, if the aforementioned set of overloaded functions is named with a template-id, its associated classes and namespaces also include those of its type template-arguments and its template template-arguments.) is not implemented. Closely related, the restriction on non-dependent parameter types in this same paragraph needs to be removed. The corresponding tests are in adl_overload_set (both issues are from CWG 997). Differential Revision: https://reviews.llvm.org/D60570 Reviewed By: riccibruno, Quuxplusone llvm-svn: 358881
* Restore pre-r335182 behavior for naming inherited constructors asRichard Smith2018-06-221-0/+15
| | | | | | | | | | | | | | members of dependent contexts. This permits cases where the names before and after the '::' in a dependent inherited constructor using-declaration do not match, but where we can nonetheless tell when parsing the template that a constructor is being named. Under (open) core language DR 2070, such cases will probably be ill-formed, but r335182 does not quite give that result and didn't intend to change this, so restore the old behavior for now. llvm-svn: 335381
* Add a "vexing parse" warning for ambiguity between a variable declaration and aRichard Smith2017-09-291-0/+1
| | | | | | | | | | | | | | function-style cast. This fires for cases such as T(x); ... where 'x' was previously declared and T is a type. This construct declares a variable named 'x' rather than the (probably expected) interpretation of a function-style cast of 'x' to T. llvm-svn: 314570
* Print nested name specifiers for typedefs and type aliasesAlex Lorenz2017-03-101-1/+1
| | | | | | | | | | | | Printing typedefs or type aliases using clang_getTypeSpelling() is missing the namespace they are defined in. This is in contrast to other types that always yield the full typename including namespaces. Patch by Michael Reiher! Differential Revision: https://reviews.llvm.org/D29944 llvm-svn: 297465
* Fix hole in our enforcement of rule requiring 'typename' prior to a dependentRichard Smith2017-02-011-2/+6
| | | | | | | | | | | name. If the dependent name happened to end in a template-id (X<T>::Y<U>), we would fail to notice that the 'typename' keyword is missing when resolving it to a type. It turns out that GCC has a similar bug. If this shows up in much real code, we can easily downgrade this to an ExtWarn. llvm-svn: 293815
* Finish implementation of C++ DR1310 (http://wg21.link/cwg1310).Richard Smith2017-01-201-3/+1
| | | | | | | Diagnose the case when a dependent template name instantiates to an injected-class-name outside a nested-name-specifier. llvm-svn: 292545
* PR13403 (+duplicates): implement C++ DR1310 (http://wg21.link/cwg1310).Richard Smith2017-01-191-4/+85
| | | | | | | | | | | | | | | | | | | | | | Under this defect resolution, the injected-class-name of a class or class template cannot be used except in very limited circumstances (when declaring a constructor, in a nested-name-specifier, in a base-specifier, or in an elaborated-type-specifier). This is apparently done to make parsing easier, but it's a pain for us since we don't know whether a template-id using the injected-class-name is valid at the point when we annotate it (we don't yet know whether the template-id will become part of an elaborated-type-specifier). As a tentative resolution to a perceived language defect, mem-initializer-ids are added to the list of exceptions here (they generally follow the same rules as base-specifiers). When the reference to the injected-class-name uses the 'typename' or 'template' keywords, we permit it to be used to name a type or template as an extension; other compilers also accept some cases in this area. There are also a couple of corner cases with dependent template names that we do not yet diagnose, but which will also get this treatment. llvm-svn: 292518
* Improve error message when referencing a non-tag type with a tagReid Kleckner2016-12-091-2/+2
| | | | | | | | | | | | | | | | | | | | Other compilers accept invalid code here that we reject, and we need a better error message to try to convince users that the code is really incorrect. Consider: class Foo { typedef MyIterHelper<Foo> iterator; friend class iterator; }; Previously our wording was "elaborated type refers to a typedef". "elaborated type" isn't widely known terminology, so the new diagnostic says "typedef 'iterator' cannot be referenced with class specifier". Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D25216 llvm-svn: 289259
* P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:Richard Smith2016-06-281-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11. Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations. For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.) In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor. Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class llvm-svn: 274049
* Lit C++11 Compatibility Patch #8Charles Li2016-04-141-3/+14
| | | | | | 24 tests have been updated for C++11 compatibility. llvm-svn: 266387
* [Lit Test] Updated 34 Lit tests to be C++11 compatible.Charles Li2015-11-172-2/+17
| | | | | | | Added expected diagnostics new to C++11. Expanded RUN line to: default, C++98/03 and C++11. llvm-svn: 253371
* Update error message text.Serge Pavlov2015-01-181-1/+1
| | | | | | | | | Previously if an enumeration was used in a nested name specifier in pre-C++11 language dialect, error message was 'XXX is not a class, namespace, or scoped enumeration'. This patch removes the word 'scoped' as in C++11 any enumeration may be used in this context. llvm-svn: 226410
* The exception-declaration for a function-try-block cannot redeclare aAaron Ballman2014-06-021-2/+6
| | | | | | | function parameter. One of our existing test cases was XFAILed because of this. This fixes the issue and un-XFAILs the test. llvm-svn: 210026
* This test should no longer be XFAILed; the standard has stabilized, and the ↵Aaron Ballman2014-05-301-13/+12
| | | | | | test contents are acceptable. No diagnostics expected from this test. llvm-svn: 209891
* Test requires exceptionsAlp Toker2014-05-281-1/+1
| | | | | | It's still XFAIL, but slightly closer to passing. llvm-svn: 209729
* Sema: Implement DR244David Majnemer2014-05-211-1/+2
| | | | | | | | | | | | | | | | Summary: Naming the destructor using a typedef-name for the class-name is well-formed. This fixes PR19620. Reviewers: rsmith, doug.gregor Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3583 llvm-svn: 209319
* Revert "Sema: Implement DR244"David Majnemer2014-05-031-2/+1
| | | | | | | | This was accidentally committed. This reverts commit r207892. llvm-svn: 207893
* Sema: Implement DR244David Majnemer2014-05-031-1/+2
| | | | | | | | | Naming the destructor using a typedef-name for the class-name is well-formed. This fixes PR19620. llvm-svn: 207892
* Don't fold together the name lookup entries for two declarations if they areRichard Smith2014-03-171-0/+11
| | | | | | declared in different namespaces in the same inline namespace set. llvm-svn: 204082
* Improve diagnostic for using non-class/namespace/scoped enum in a nested ↵David Blaikie2014-02-091-1/+2
| | | | | | | | | | | | | | | name specifier. Rather than simply saying "X is not a class or namespace", clarify what X is by providing the aka type in the case where X is a type, or pointing to the named declaration if there's an unambiguous one to refer to. In the ambiguous case, the ambiguities are already enumerated (though could be clarified by describing what kind of entities they are) Included a few FIXMEs in tests where some further improvements could be made. llvm-svn: 201038
* Added warning on structures/unions that are empty or contain onlySerge Pavlov2013-11-141-1/+1
| | | | | | | | | | bit fields of zero size. Warnings are generated in C++ mode and if only such type is defined inside extern "C" block. The patch fixed PR5065. Differential Revision: http://llvm-reviews.chandlerc.com/D2151 llvm-svn: 194653
* Teach typo correction to look inside of classes like it does namespaces.Kaelyn Uhrain2013-09-261-4/+4
| | | | | | | | | | | | | | | Unlike with namespaces, searching inside of classes requires also checking the access to correction candidates (i.e. don't suggest a correction to a private class member for a correction occurring outside that class and its methods or friends). Included is a small (one line) fix for a bug, that was uncovered while cleaning up the unit tests, where the decls from a TypoCorrection candidate were preserved in new TypoCorrection candidates that are derived (copied) from the old TypoCorrection--notably when creating a new candidate by changing the NestedNameSpecifier associated with the base idenitifer. llvm-svn: 191449
* Skip transparent contexts when looking for using directives in name lookup.Douglas Gregor2013-04-091-4/+8
| | | | | | Fixes the bootstrap regression I introduced in r179067. llvm-svn: 179079
* <rdar://problem/13540899> Collect using directives from all of the semantic ↵Douglas Gregor2013-04-081-0/+19
| | | | | | | | | | | | contexts not represented by scopes. This fixes a regression I introduced in r178136, where we would not consider the using directives from the semantic declaration contexts that aren't represented by the lexical scopes (Scope) when performing unqualified name lookup. This lead to horribly funny diagnostics like "no identifier named 'foo'; did you mean 'foo'?". llvm-svn: 179067
* <rdar://problem/13317030> Consider using directives when performing ↵Douglas Gregor2013-03-271-0/+30
| | | | | | unqualified name lookup into declarations contexts represented by the qualified-id but not in the actual scope hierarchy. llvm-svn: 178136
* Remove FIXMEs: these are covered by a core issue which we don't yet implementRichard Smith2013-03-261-2/+0
| | | | | | (but we happen to get this part right). llvm-svn: 177958
* Implement special-case name lookup for inheriting constructors: memberRichard Smith2013-03-261-1/+93
| | | | | | | using-declarations with names which look constructor-like are interpreted as constructor names. llvm-svn: 177957
* Add quotation marks to template names in diagnostics.David Blaikie2013-03-051-1/+1
| | | | llvm-svn: 176474
* Prior to adding the new "expected-no-diagnostics" directive to ↵Andy Gibbs2012-10-1910-0/+10
| | | | | | VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive. llvm-svn: 166280
* Instantiate class template specializations during ADL.John McCall2012-08-241-0/+24
| | | | llvm-svn: 162586
* We don't need a lengthy quote from the wrong standard.Douglas Gregor2012-05-011-20/+0
| | | | llvm-svn: 155942
* Add test cases for r155935.Douglas Gregor2012-05-012-0/+110
| | | | llvm-svn: 155940
* When determining whether an identifier followed by a '<' in a memberDouglas Gregor2012-03-101-0/+25
| | | | | | | | access expression is the start of a template-id, ignore function templates found in the context of the entire postfix-expression. Fixes PR11856. llvm-svn: 152520
* Modify how the -verify flag works. Currently, the verification string andRichard Trieu2011-12-153-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | diagnostic message are compared. If either is a substring of the other, then no error is given. This gives rise to an unexpected case: // expect-error{{candidate function has different number of parameters}} will match the following error messages from Clang: candidate function has different number of parameters (expected 1 but has 2) candidate function has different number of parameters It will also match these other error messages: candidate function function has different number of parameters number of parameters This patch will change so that the verification string must be a substring of the diagnostic message before accepting. Also, all the failing tests from this change have been corrected. Some stats from this cleanup: 87 - removed extra spaces around verification strings 70 - wording updates to diagnostics 40 - extra leading or trailing characters (typos, unmatched parens or quotes) 35 - diagnostic level was included (error:, warning:, or note:) 18 - flag name put in the warning (-Wprotocol) llvm-svn: 146619
* Update all tests other than Driver/std.cpp to use -std=c++11 rather thanRichard Smith2011-10-131-1/+1
| | | | | | -std=c++0x. Patch by Ahmed Charles! llvm-svn: 141900
* De-Unicode-ify.NAKAMURA Takumi2011-08-121-1/+1
| | | | llvm-svn: 137430
* When performing the lookup in the current scope for a member access toDouglas Gregor2011-08-101-0/+18
| | | | | | | | | | | | a member template, e.g., x.f<int> if we have found a template in the type of x, but the lookup in the current scope is ambiguous, just ignore the lookup in the current scope. Fixes <rdar://problem/9915664>. llvm-svn: 137255
* Update this test to reflect the new (deterministic) order in r134038.Chandler Carruth2011-06-281-2/+2
| | | | | | | This was part of Kaelyn's original patch that got dropped while I was working on it, but after I ran my tests. =/ Sorry. llvm-svn: 134039
* Modify test case to allow buildbots to make forward progress. This test shouldChad Rosier2011-06-281-2/+2
| | | | | | | now (incorrectly) pass. Once the appropriate fixes have been made this test should be reverted. llvm-svn: 134035
* Add support for C++ namespace-aware typo correction, e.g., correctingDouglas Gregor2011-06-281-3/+10
| | | | | | | | | | | | | | | vector<int> to std::vector<int> Patch by Kaelyn Uhrain, with minor tweaks + PCH support from me. Fixes PR5776/<rdar://problem/8652971>. Thanks Kaelyn! llvm-svn: 134007
* Teach Sema::ActOnUninitializedDecl() not to try to interpret when oneDouglas Gregor2011-05-211-0/+3
| | | | | | | | should use a constructor to default-initialize a variable. InitializationSequence knows the rules for default initialization, better. Fixes <rdar://problem/8501008>. llvm-svn: 131796
* When emitting a "too many arguments to function call..." error, also include ↵Ted Kremenek2011-04-041-1/+1
| | | | | | a note with a location for the function prototype. llvm-svn: 128833
* "const std::vector<int>*" not "std::vector<int> const*"Chris Lattner2010-09-051-1/+1
| | | | llvm-svn: 113094
* Rip out the C++0x-specific handling of destructor names. The specification ↵Sebastian Redl2010-07-071-0/+3
| | | | | | is still in flux and unclear, and our interim workaround was broken. Fixes PR7467. llvm-svn: 107835
* Add an extension to avoid an error when a global template has the same name asJeffrey Yasskin2010-06-051-0/+46
| | | | | | | | | | | | | | | | | | | | a member template, and you try to call the member template with an explicit template argument. See PR7247 For example, this downgrades the error to a warning in: template<typename T> struct set{}; struct Value { template<typename T> void set(T value) { } }; void foo() { Value v; v.set<double>(3.2); // Warning here. } llvm-svn: 105518
* A more minimal fix for PR6762.John McCall2010-05-281-0/+11
| | | | llvm-svn: 104991
OpenPOWER on IntegriCloud