Fixed grammatical error in "enum specifier" error msg #94443 (#94592)

As discussed in #94443, this PR changes the wording to be more correct.

Add boundary check for ASTUnresolvedSet::erase

When compile following code with clang (Debug build), Assertion will be triggered.

```
struct A
{
struct Nested {};
operator Nested*()

Add boundary check for ASTUnresolvedSet::erase

When compile following code with clang (Debug build), Assertion will be triggered.

```
struct A
{
struct Nested {};
operator Nested*() {return 0;};
};

struct B : A
{
using A::operator typename A::Nested*;
operator typename A::Nested *() {
struct A * thi = this;
return *thi;
};
};
```

The assertion fail is caused by: `void erase(unsigned I) { Decls[I] = Decls.pop_back_val(); }` when size of `Decls` is 1 before erase.

Reviewed By: rjmccall, MaskRay

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

show more ...

Rewording "static_assert" diagnostics

This patch rewords the static assert diagnostic output. Failing a
_Static_assert in C should not report that static_assert failed. This
changes the wording to b

Rewording "static_assert" diagnostics

This patch rewords the static assert diagnostic output. Failing a
_Static_assert in C should not report that static_assert failed. This
changes the wording to be more like GCC and uses "static assertion"
when possible instead of hard coding the name. This also changes some
instances of 'static_assert' to instead be based on the token in the
source code.

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

show more ...

Revert "Rewording the "static_assert" to static assertion"

Looks like we again are going to have problems with libcxx tests that
are overly specific in their dependency on clang's diagnostics.

This

Revert "Rewording the "static_assert" to static assertion"

Looks like we again are going to have problems with libcxx tests that
are overly specific in their dependency on clang's diagnostics.

This reverts commit 6542cb55a3eb115b1c3592514590a19987ffc498.

show more ...

Rewording the "static_assert" to static assertion

This patch is basically the rewording of the static assert statement's
output(error) on screen after failing. Failing a _Static_assert in C
should n

Rewording the "static_assert" to static assertion

This patch is basically the rewording of the static assert statement's
output(error) on screen after failing. Failing a _Static_assert in C
should not report that static_assert failed. It’d probably be better to
reword the diagnostic to be more like GCC and say “static assertion”
failed in both C and C++.

consider a c file having code

_Static_assert(0, "oh no!");

In clang the output is like:

<source>:1:1: error: static_assert failed: oh no!
_Static_assert(0, "oh no!");
^ ~
1 error generated.
Compiler returned: 1

Thus here the "static_assert" is not much good, it will be better to
reword it to the "static assertion failed" to more generic. as the gcc
prints as:

<source>:1:1: error: static assertion failed: "oh no!"
1 | _Static_assert(0, "oh no!");
| ^~~~~~~~~~~~~~
Compiler returned: 1

The above can also be seen here. This patch is about rewording
the static_assert to static assertion.

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

show more ...

Revert "Rewording "static_assert" diagnostics"

This reverts commit b7e77ff25fb2412f6ab6d6cc756666b0e2f97bd3.

Reason: Broke sanitizer builds bots + libcxx. 'static assertion
expression is not an int

Revert "Rewording "static_assert" diagnostics"

This reverts commit b7e77ff25fb2412f6ab6d6cc756666b0e2f97bd3.

Reason: Broke sanitizer builds bots + libcxx. 'static assertion
expression is not an integral constant expression'. More details
available in the Phabricator review: https://reviews.llvm.org/D129048

show more ...

Rewording "static_assert" diagnostics

This patch rewords the static assert diagnostic output. Failing a
_Static_assert in C should not report that static_assert failed. This
changes the wording to b

Rewording "static_assert" diagnostics

This patch rewords the static assert diagnostic output. Failing a
_Static_assert in C should not report that static_assert failed. This
changes the wording to be more like GCC and uses "static assertion"
when possible instead of hard coding the name. This also changes some
instances of 'static_assert' to instead be based on the token in the
source code.

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

show more ...

Fix a diagnoses-valid bug with using declarations

The following was found by a customer and is accepted by the other primary
C++ compilers, but fails to compile in Clang:

namespace sss {
double foo

Fix a diagnoses-valid bug with using declarations

The following was found by a customer and is accepted by the other primary
C++ compilers, but fails to compile in Clang:

namespace sss {
double foo(int, double);
template <class T>
T foo(T); // note: target of using declaration
} // namespace sss

namespace oad {
void foo();
}

namespace oad {
using ::sss::foo;
}

namespace sss {
using oad::foo; // note: using declaration
}

namespace sss {
double foo(int, double) { return 0; }
template <class T>
T foo(T t) { // error: declaration conflicts with target of using
return t;
}
} // namespace sss

I believe the issue is that MergeFunctionDecl() was calling
checkUsingShadowRedecl() but only considering a FunctionDecl as a
possible shadow and not FunctionTemplateDecl. The changes in this patch
largely mirror how variable declarations were being handled by also
catching FunctionTemplateDecl.

show more ...

Improve error message when referencing a non-tag type with a tag

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

Improve error message when referencing a non-tag type with a tag

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

show more ...

[Sema] Prevent using member declaration diagnostic if the base class is invalid.

Summary:
Once a base class has been made invalid (by a static_assert for example) all using-member declarations in th

[Sema] Prevent using member declaration diagnostic if the base class is invalid.

Summary:
Once a base class has been made invalid (by a static_assert for example) all using-member declarations in the derived classes will result in a "not a base class" diagnostic. This diagnostic is very misleading and should not be emitted.

This change is needed to help libc++ produce reasonable diagnostics in `std::optional` and `std::variant`.

Reviewers: rsmith, majnemer, aaron.ballman

Subscribers: cfe-commits

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

llvm-svn: 283755

show more ...

Fix a crash on invalid with template handling

This is a fix for https://llvm.org/bugs/show_bug.cgi?id=25561 which was a
crash on invalid. Change the handling of invalid decls to have a catch-all
ca

Fix a crash on invalid with template handling

This is a fix for https://llvm.org/bugs/show_bug.cgi?id=25561 which was a
crash on invalid. Change the handling of invalid decls to have a catch-all
case to prevent unexpecting decls from triggering an assertion.

llvm-svn: 265467

show more ...

Fix assert if an attempt is made to explicitly instantiate an alias template.
Patch by Ismail Pazarbasi!

llvm-svn: 184650

Add a testcase which uses an UnresolvedUsingTypenameDecl as the base of an NNS.

llvm-svn: 184386

Fix Sema::CorrectTypo to ignore found but unresolved symbols

llvm-svn: 139252

Don't be so eager to replace UsingDecls in a DeclContext's lookup table;
check that the TargetNestedNameDecl is the same first.

llvm-svn: 118239

When pretty-printing tag types, only print the tag if we're in C (and
therefore not creating ElaboratedTypes, which are still pretty-printed
with the written tag).

Most of these testcase changes wer

When pretty-printing tag types, only print the tag if we're in C (and
therefore not creating ElaboratedTypes, which are still pretty-printed
with the written tag).

Most of these testcase changes were done by script, so don't feel too
sorry for my fingers.

llvm-svn: 98149

show more ...

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 o

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

show more ...

Correctly implement the C++03 and 0x restrictions on class-member using
declarations.

llvm-svn: 90843

Fix "using typename" and the instantiation of non-dependent using declarations.

llvm-svn: 90614

Incremental progress on using declarations. Split UnresolvedUsingDecl into
two classes, one for typenames and one for values; this seems to have some
support from Doug if not necessarily from the e

Incremental progress on using declarations. Split UnresolvedUsingDecl into
two classes, one for typenames and one for values; this seems to have some
support from Doug if not necessarily from the extremely-vague-on-this-point
standard. Track the location of the 'typename' keyword in a using-typename
decl. Make a new lookup result for unresolved values and deal with it in
most places.

llvm-svn: 89184

show more ...

CreateDeclRefExprs that point to UnresolvedUsingDecls.

llvm-svn: 80413

Add another check for UnresolvedUsingDecl.

llvm-svn: 80412

Check for UnresolvedUsingDecl when determining if a declaration is a redeclaration or not.

llvm-svn: 80383

Instantiate unresolved using declarations.

llvm-svn: 80366