[Clang][Sema] Diagnose friend declarations with enum elaborated-type-specifier in all language modes (#80171)

According to [dcl.type.elab] p4:
> If an _elaborated-type-specifier_ appears with the `

[Clang][Sema] Diagnose friend declarations with enum elaborated-type-specifier in all language modes (#80171)

According to [dcl.type.elab] p4:
> If an _elaborated-type-specifier_ appears with the `friend` specifier
as an entire _member-declaration_, the _member-declaration_ shall have
one of the following forms:
> `friend` _class-key_ _nested-name-specifier_(opt) _identifier_ `;`
> `friend` _class-key_ _simple-template-id_ `;`
> `friend` _class-key_ _nested-name-specifier_ `template`(opt)
_simple-template-id_ `;`

Notably absent from this list is the `enum` form of an
_elaborated-type-specifier_ "`enum` _nested-name-specifier_(opt)
_identifier_", which appears to be intentional per the resolution of
CWG2363.

Most major implementations accept these declarations, so the diagnostic
is a pedantic warning across all C++ versions.

In addition to the trivial cases previously diagnosed in C++98, we now
diagnose cases where the _elaborated-type-specifier_ has a dependent
_nested-name-specifier_:
```
template<typename T>
struct A
{
enum class E;
};

struct B
{
template<typename T>
friend enum A<T>::E; // pedantic warning: elaborated enumeration type cannot be a friend
};

template<typename T>
struct C
{
friend enum T::E; // pedantic warning: elaborated enumeration type cannot be a friend
};
```

show more ...

[clang] Remove rdar links; NFC

We have a new policy in place making links to private resources
something we try to avoid in source and test files. Normally, we'd
organically switch to the new policy

[clang] Remove rdar links; NFC

We have a new policy in place making links to private resources
something we try to avoid in source and test files. Normally, we'd
organically switch to the new policy rather than make a sweeping change
across a project. However, Clang is in a somewhat special circumstance
currently: recently, I've had several new contributors run into rdar
links around test code which their patch was changing the behavior of.
This turns out to be a surprisingly bad experience, especially for
newer folks, for a handful of reasons: not understanding what the link
is and feeling intimidated by it, wondering whether their changes are
actually breaking something important to a downstream in some way,
having to hunt down strangers not involved with the patch to impose on
them for help, accidental pressure from asking for potentially private
IP to be made public, etc. Because folks run into these links entirely
by chance (through fixing bugs or working on new features), there's not
really a set of problematic links to focus on -- all of the links have
basically the same potential for causing these problems. As a result,
this is an omnibus patch to remove all such links.

This was not a mechanical change; it was done by manually searching for
rdar, radar, radr, and other variants to find all the various
problematic links. From there, I tried to retain or reword the
surrounding comments so that we would lose as little context as
possible. However, because most links were just a plain link with no
supporting context, the majority of the changes are simple removals.

Differential Review: https://reviews.llvm.org/D158071

show more ...

[clang] Enable C++11-style attributes in all language modes

This also ignores and deprecates the `-fdouble-square-bracket-attributes` command line flag, which seems to not be used anywhere. At least

[clang] Enable C++11-style attributes in all language modes

This also ignores and deprecates the `-fdouble-square-bracket-attributes` command line flag, which seems to not be used anywhere. At least a code search exclusively found mentions of it in documentation: https://sourcegraph.com/search?q=context:global+-fdouble-square-bracket-attributes+-file:clang/*+-file:test/Sema/*+-file:test/Parser/*+-file:test/AST/*+-file:test/Preprocessor/*+-file:test/Misc/*+archived:yes&patternType=standard&sm=0&groupBy=repo

RFC: https://discourse.llvm.org/t/rfc-enable-c-11-c2x-attributes-in-all-standard-modes-as-an-extension-and-remove-fdouble-square-bracket-attributes

This enables `[[]]` attributes in all C and C++ language modes without warning by default. `-Wc++-extensions` does warn. GCC has enabled this extension in all C modes since GCC 10.

Reviewed By: aaron.ballman, MaskRay

Spies: #clang-vendors, beanz, JDevlieghere, Michael137, MaskRay, sstefan1, jplehr, cfe-commits, lldb-commits, dmgreen, jdoerfert, wenlei, wlei

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

show more ...

Revert "Remove rdar links; NFC"

This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d.
This commit wasn't reviewed ahead of time and significant concerns were
raised immediately after it land

Revert "Remove rdar links; NFC"

This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d.
This commit wasn't reviewed ahead of time and significant concerns were
raised immediately after it landed. According to our developer policy
this warrants immediate revert of the commit.

https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy

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

show more ...

Remove rdar links; NFC

This removes links to rdar, which is an internal bug tracker that the
community doesn't have visibility into.

See further discussion at:
https://discourse.llvm.org/t/code-rev

Remove rdar links; NFC

This removes links to rdar, which is an internal bug tracker that the
community doesn't have visibility into.

See further discussion at:
https://discourse.llvm.org/t/code-review-reminder-about-links-in-code-commit-messages/71847

show more ...

Change the behavior of implicit int diagnostics

C89 allowed a type specifier to be elided with the resulting type being
int, aka implicit int behavior. This feature was subsequently removed
in C99 w

Change the behavior of implicit int diagnostics

C89 allowed a type specifier to be elided with the resulting type being
int, aka implicit int behavior. This feature was subsequently removed
in C99 without a deprecation period, so implementations continued to
support the feature. Now, as with implicit function declarations, is a
good time to reevaluate the need for this support.

This patch allows -Wimplicit-int to issue warnings in C89 mode (off by
default), defaults the warning to an error in C99 through C17, and
disables support for the feature entirely in C2x. It also removes a
warning about missing declaration specifiers that really was just an
implicit int warning in disguise and other minor related cleanups.

show more ...

PR45294: Fix handling of assumed template names looked up in the lexical
scope.

There are a few contexts in which we assume a name is a template name;
if such a context is one where we should perfor

PR45294: Fix handling of assumed template names looked up in the lexical
scope.

There are a few contexts in which we assume a name is a template name;
if such a context is one where we should perform an unqualified lookup,
and lookup finds nothing, we would form a dependent template name even
if the name is not dependent. This happens in particular for the lookup
of a pseudo-destructor.

In passing, rename ActOnDependentTemplateName to just ActOnTemplateName
given that we apply it for non-dependent template names too.

show more ...

PR12350: Handle remaining cases permitted by CWG DR 244.

Also add extension warnings for the cases that are disallowed by the
current rules for destructor name lookup, refactor and simplify the
look

PR12350: Handle remaining cases permitted by CWG DR 244.

Also add extension warnings for the cases that are disallowed by the
current rules for destructor name lookup, refactor and simplify the
lookup code, and improve the diagnostic quality when lookup fails.

The special case we previously supported for converting
p->N::S<int>::~S() from naming a class template into naming a
specialization thereof is subsumed by a more general rule here (which is
also consistent with Clang's historical behavior and that of other
compilers): if we can't find a suitable S in N, also look in N::S<int>.

The extension warnings are off by default, except for a warning when
lookup for p->N::S::~T() looks for T in scope instead of in N (or N::S).
That seems sufficiently heinous to warn on by default, especially since
we can't support it for a dependent nested-name-specifier.

show more ...

Remove redundant CXXScopeSpec from TemplateIdAnnotation.

A TemplateIdAnnotation represents only a template-id, not a
nested-name-specifier plus a template-id. Don't make a redundant copy of
the CXXS

Remove redundant CXXScopeSpec from TemplateIdAnnotation.

A TemplateIdAnnotation represents only a template-id, not a
nested-name-specifier plus a template-id. Don't make a redundant copy of
the CXXScopeSpec and store it on the template-id annotation.

This slightly improves error recovery by more properly handling the case
where we would form an invalid CXXScopeSpec while parsing a typename
specifier, instead of accidentally putting the token stream into a
broken "annot_template_id with a scope specifier, but with no preceding
annot_cxxscope token" state.

show more ...

Fix parser bug that permitted 'private' as a (no-op) decl-specifier even outside OpenCL.

Parse A::template B as an identifier rather than as a template-id with no
template arguments.

This fixes some cases where we'd incorrectly accept "A::template B" when B is a
kind of template that re

Parse A::template B as an identifier rather than as a template-id with no
template arguments.

This fixes some cases where we'd incorrectly accept "A::template B" when B is a
kind of template that requires template arguments (in particular, a variable
template or a concept).

llvm-svn: 331013

show more ...

[Parser] Fix assertion-on-invalid for unexpected typename.

In `ParseDeclarationSpecifiers` for the code

class A typename A;

we were able to annotate token `kw_typename` because it refers to
ex

[Parser] Fix assertion-on-invalid for unexpected typename.

In `ParseDeclarationSpecifiers` for the code

class A typename A;

we were able to annotate token `kw_typename` because it refers to
existing type. But later during processing token `annot_typename` we
failed to `SetTypeSpecType` and exited switch statement leaving
annotation token unconsumed. The code after the switch statement failed
because it didn't expect a special token.

The fix is not to assume that switch statement consumes all special
tokens and consume any token, not just non-special.

rdar://problem/37099386

Reviewers: rsmith, arphaman

Reviewed By: rsmith

Subscribers: jkorous-apple, cfe-commits

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

llvm-svn: 329735

show more ...

Add a fixit for attributes incorrectly placed prior to 'struct/class/enum' keyword.

Suggest moving the following erroneous attrib list (based on location)
[[]] struct X;
to
struct [[]] X;

Additi

Add a fixit for attributes incorrectly placed prior to 'struct/class/enum' keyword.

Suggest moving the following erroneous attrib list (based on location)
[[]] struct X;
to
struct [[]] X;

Additionally, added a fixme for the current implementation that diagnoses misplaced attributes to consider using the newly introduced diagnostic (that I think is more user-friendly).

llvm-svn: 321449

show more ...

Suppress "redundant parens" warning for "A (::B())".

This is a slightly odd construct (it's more common to see "A (::B)()") but can
happen in friend declarations, and the parens are not redundant as

Suppress "redundant parens" warning for "A (::B())".

This is a slightly odd construct (it's more common to see "A (::B)()") but can
happen in friend declarations, and the parens are not redundant as they prevent
the :: binding to the left.

llvm-svn: 321318

show more ...

Don't produce redundant parentheses warning for "A (::B);" and the like.

The parentheses here are not redundant as they affect the binding of the
'::' token.

llvm-svn: 321304

Lit C++11 Compatibility Patch #8

24 tests have been updated for C++11 compatibility.

llvm-svn: 266387

Replace "can not" with "cannot" in diagnostics messages.

llvm-svn: 203302

Downgrade bogus ExtWarn on duplicate 'friend' specifier to a Warning, and add a
Warning for a duplicate 'constexpr' specifier.

llvm-svn: 198956

PR9547: If we're parsing a simple-declaration that contains a tag definition,
and we see an ill-formed declarator that would probably be well-formed if the
tag definition were just missing a semicolo

PR9547: If we're parsing a simple-declaration that contains a tag definition,
and we see an ill-formed declarator that would probably be well-formed if the
tag definition were just missing a semicolon, use that as the diagnostic
instead of producing some other mysterious error.

llvm-svn: 195163

show more ...

PR17567: Improve diagnostic for a mistyped constructor name. If we see something
that looks like a function declaration, except that it's missing a return type,
try typo-correcting it to the relevant

PR17567: Improve diagnostic for a mistyped constructor name. If we see something
that looks like a function declaration, except that it's missing a return type,
try typo-correcting it to the relevant constructor name.

In passing, fix a bug where the missing-type-specifier recovery codepath would
drop a preceding scope specifier on the floor, leading to follow-on diagnostics
and incorrect recovery for the auto-in-c++98 hack.

llvm-svn: 192644

show more ...

Parser: Avoid a crash-on-invalid when trying to diagnose function calls with -> in it.

Use the existing convenience function.

llvm-svn: 192347

Parse: Don't crash during parsing if we lack a simple-type-specifier

Summary:
Parsing cast expressions during error recovery can put us in a bad
state. Check to see if the token for a simple-type-s

Parse: Don't crash during parsing if we lack a simple-type-specifier

Summary:
Parsing cast expressions during error recovery can put us in a bad
state. Check to see if the token for a simple-type-specifier makes
sense before further parsing.

Fixes PR17255.

Reviewers: rsmith, doug.gregor, CornedBee, eli.friedman

CC: cfe-commits

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

llvm-svn: 191159

show more ...

For "expected unqualified-id" errors after a double colon, and the double colon
is at the end of the line, point to the location after the double colon instead
of at the next token. There is more co

For "expected unqualified-id" errors after a double colon, and the double colon
is at the end of the line, point to the location after the double colon instead
of at the next token. There is more context to be given this way. In addition,
the next token can be several lines later.

llvm-svn: 190029

show more ...

PR5066: If a declarator cannot have an identifier, and cannot possibly be
followed by an identifier, then diagnose an identifier as being a bogus part of
the declarator instead of tripping over it. I

PR5066: If a declarator cannot have an identifier, and cannot possibly be
followed by an identifier, then diagnose an identifier as being a bogus part of
the declarator instead of tripping over it. Improves diagnostics for cases like

std::vector<const int *p> my_vec;

llvm-svn: 186061

show more ...

Don't accidentally and silently accept C++11 attributes in decl-specifier-seqs
in C++98.

llvm-svn: 175879