Commit Graph

13 Commits

Author SHA1 Message Date
Richard Smith b3f6e3d6d6 Improve recovery from invalid template-ids.
Instead of bailing out of parsing when we encounter an invalid
template-name or template arguments in a template-id, produce an
annotation token describing the invalid construct.

This avoids duplicate errors and generally allows us to recover better.
In principle we should be able to extend this to store some kinds of
invalid template-id in the AST for tooling use, but that isn't handled
as part of this change.
2020-03-27 17:11:04 -07:00
Saar Raz 19fccc52ff [Concepts] Fix incorrect control flow when TryAnnotateTypeConstraint annotates an invalid template-id
TryAnnotateTypeConstraint could annotate a template-id which doesn't end up being a type-constraint,
in which case control flow would incorrectly flow into ParseImplicitInt.

Reenter the loop in this case.
Enable relevant tests for C++20. This required disabling typo-correction during TryAnnotateTypeConstraint
and changing a test case which is broken due to a separate bug (will be reported and handled separately).
2020-03-17 01:49:42 +02:00
Richard Smith b23c5e8c3d [c++20] Implement P0846R0: allow (ADL-only) calls to template-ids whose
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
2019-05-09 03:31:27 +00:00
Richard Smith 52f8d19ced Improve diagnosis of unknown template name.
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
2017-05-10 21:32:16 +00:00
Charles Li 542f04cc4d [Lit Test] Updated 26 Lit tests to be C++11 compatible.
Expected diagnostics have been expanded to vary by C++ dialect.
RUN line has also been expanded to: default, C++98/03 and C++11.

llvm-svn: 252785
2015-11-11 19:34:47 +00:00
Argyrios Kyrtzidis b39399de69 Add test case for rdar://11293995
llvm-svn: 155690
2012-04-27 04:31:46 +00:00
Richard Smith c5b0552055 Fix parsing of type-specifier-seq's. Types are syntactically allowed to be
defined here, but not semantically, so

  new struct S {};

is always ill-formed, even if there is a struct S in scope.

We also had a couple of bugs in ParseOptionalTypeSpecifier caused by it being
under-loved (due to it only being used in a few places) so merge it into
ParseDeclarationSpecifiers with a new DeclSpecContext. To avoid regressing, this
required improving ParseDeclarationSpecifiers' diagnostics in some cases. This
also required teaching ParseSpecifierQualifierList about constexpr... which
incidentally fixes an issue where we'd allow the constexpr specifier in other
bad places.

llvm-svn: 152549
2012-03-12 07:56:15 +00:00
Nick Lewycky 07e97c594d Make this error less specific but also less likely to cause confusion. Fixes
PR7702.

llvm-svn: 118181
2010-11-03 17:52:57 +00:00
John McCall eae5acbbd0 Fix PR6327: restore invariants when there's a parse error in an initializer.
llvm-svn: 99980
2010-03-31 02:13:20 +00:00
Douglas Gregor fe17d2550b Improve parsing and instantiation of destructor names, so that we can
now cope with the destruction of types named as dependent templates,
e.g.,

  y->template Y<T>::~Y()

Nominally, we implement C++0x [basic.lookup.qual]p6. However, we don't
follow the letter of the standard here because that would fail to
parse

  template<typename T, typename U>
  X0<T, U>::~X0() { }

properly. The problem is captured in core issue 339, which gives some
(but not enough!) guidance. I expect to revisit this code when the
resolution of 339 is clear, and/or we start capturing better source
information for DeclarationNames.

Fixes PR6152.

llvm-svn: 96367
2010-02-16 19:09:40 +00:00
Daniel Dunbar 8fbe78f6fc Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
   which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
   can be useful to redefine what gets run as 'clang -cc1' (for example, to set
   a default target).

llvm-svn: 91446
2009-12-15 20:14:24 +00:00
Douglas Gregor 30d60cb36e Replace the code that parses member access expressions after "." or
"->" with a use of ParseUnqualifiedId. Collapse
ActOnMemberReferenceExpr, ActOnDestructorReferenceExpr (both of them),
ActOnOverloadedOperatorReferenceExpr,
ActOnConversionOperatorReferenceExpr, and
ActOnMemberTemplateIdReferenceExpr into a single, new action
ActOnMemberAccessExpr that does the same thing more cleanly (and can
keep more source-location information).

llvm-svn: 85930
2009-11-03 19:44:04 +00:00
Douglas Gregor 522fbc4969 Support explicit C++ member operator syntax, from James Porter!
llvm-svn: 80608
2009-08-31 19:52:13 +00:00