Commit Graph

14 Commits

Author SHA1 Message Date
Hubert Tong 605eacafa7 Fix valid-for-expr ellipses eaten as invalid decl
Summary:
The trial parse for declarative syntax accepts an invalid pack
declaration syntax, which is ambiguous with valid pack expansions of
expressions. This commit removes the invalid pack declaration syntax to
avoid mistaking valid pack expansions as invalid declarator components.

Additionally, the trial parse of a //template-argument-list// then needs
to handle the optional ellipsis that is part of that grammar, as opposed
to relying on the trial parse for declarators accepting stray ellipses.

Reviewers: rsmith, rcraik, aaron.ballman

Reviewed By: rsmith

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D33339

llvm-svn: 303472
2017-05-20 00:21:55 +00:00
Richard Smith 74f02347ca PR13403 (+duplicates): implement C++ DR1310 (http://wg21.link/cwg1310).
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
2017-01-19 21:00:13 +00:00
Nico Weber 71e377d6ee If a function decl cannot be merged, mark it as invalid.
Clang currently crashes on

    class C {
      C() = default;
      C() = delete;
    };

My cunning plan for fixing this was to change the `if (!FnD)` in
Parser::ParseCXXInlineMethodDef() to `if (!FnD || FnD->isInvalidDecl)` – but
alas, the second constructor decl wasn't marked as invalid.  This lets
Sema::MergeFunctionDecl() return true on function redeclarations, which leads
to them being marked invalid.

This also improves error messages when functions are redeclared.

llvm-svn: 226365
2015-01-17 02:33:17 +00:00
Serge Pavlov 2e3ecb660a Recover from errors in enum definition
Previously any error in enum definition body stopped parsing it. With this
change parser tries to recover from errors.
The patch fixes PR10982.

Differential Revision: http://llvm-reviews.chandlerc.com/D2018

llvm-svn: 198259
2013-12-31 06:26:03 +00:00
Richard Smith 034185c2f9 The 'constexpr implies const' rule for non-static member functions is gone in
C++1y, so stop adding the 'const' there. Provide a compatibility warning for
code relying on this in C++11, with a fix-it hint. Update our lazily-written
tests to add the const, except for those ones which were testing our
implementation of this rule.

llvm-svn: 179969
2013-04-21 01:08:50 +00:00
Richard Smith 22c7c4131a Teach statement / declaration disambiguation about C++11-style generalized initializers.
llvm-svn: 177480
2013-03-20 03:35:02 +00:00
Richard Smith 434516c50c Don't skip '_Alignas' when disambiguating 'final'. '_Alignas' can't appear here,
and we used to assert if it did.

llvm-svn: 175866
2013-02-22 06:46:23 +00:00
Richard Smith b19337fbe4 PR15311: Finish implementation of the suggested resolution of core issue 1488,
which allows grouping parens in an abstract-pack-declarator. This was already
mostly implemented, but missed some cases. Add an ExtWarn for use of this
extension until CWG ratifies it.

llvm-svn: 175660
2013-02-20 20:19:27 +00:00
Richard Smith 45fbfc7f11 Do not warn about a function decl / direct init ambiguity if the function has a trailing return type.
llvm-svn: 160646
2012-07-23 21:41:30 +00:00
Richard Smith 369b9f997c Extend the "expected ';' after struct" logic to also apply to enums, and to
struct and enum forward-declarations.

llvm-svn: 159164
2012-06-25 21:37:02 +00:00
Richard Smith 43f340f440 If we see '(...' where we're expecting an abstract-declarator, that doesn't
necessarily mean we've found a function declarator. If the next token is not
a ')', this is actually a parenthesized pack expansion.

llvm-svn: 153544
2012-03-27 23:05:05 +00:00
David Blaikie 9933a5abab Fix a crash-on-invalid found by -Wlogical-op-parentheses.
llvm-svn: 152559
2012-03-12 15:39:49 +00:00
Richard Smith bfdb108fc5 Fix parsing of trailing-return-type. Types are syntactically prohibited from
being defined here: [] () -> struct S {} does not define struct S.

In passing, implement DR1318 (syntactic disambiguation of 'final').

llvm-svn: 152551
2012-03-12 08:56:40 +00:00
Richard Smith 1e3b0f0614 Update parser's disambiguation to cope with braced function-style casts in
C++11, and with braced-init-list initializers in conditions. This exposed an
ambiguity with enum underlying types versus bitfields, which we resolve by
treating 'enum E : T {' as always defining an enumeration (even if it would
only successfully parse as a bitfield). This appears to be g++ compatible.

llvm-svn: 151227
2012-02-23 01:36:12 +00:00