Diagnose use of VLAs in C++ by default

Reapplication of 7339c0f782d5c70e0928f8991b0c05338a90c84c with a fix
for a crash involving arrays without a size expression.

Clang supports VLAs in C++ as an

Diagnose use of VLAs in C++ by default

Reapplication of 7339c0f782d5c70e0928f8991b0c05338a90c84c with a fix
for a crash involving arrays without a size expression.

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565

show more ...

Revert "Diagnose use of VLAs in C++ by default"

This reverts commit 7339c0f782d5c70e0928f8991b0c05338a90c84c.

Breaks bots:
https://lab.llvm.org/buildbot/#/builders/139/builds/51875
https://lab.llvm

Revert "Diagnose use of VLAs in C++ by default"

This reverts commit 7339c0f782d5c70e0928f8991b0c05338a90c84c.

Breaks bots:
https://lab.llvm.org/buildbot/#/builders/139/builds/51875
https://lab.llvm.org/buildbot/#/builders/164/builds/45262

show more ...

Diagnose use of VLAs in C++ by default

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they'r

Diagnose use of VLAs in C++ by default

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565

show more ...

[Clang] Modify sanity check assert in AggExprEmitter::VisitInitListExpr to cover anonymous struct in a union GNU extension

AggExprEmitter::VisitInitListExpr sanity checks that an empty union is real

[Clang] Modify sanity check assert in AggExprEmitter::VisitInitListExpr to cover anonymous struct in a union GNU extension

AggExprEmitter::VisitInitListExpr sanity checks that an empty union is really
empty and not a semantic analysis failure. The assert is missing that we allow
anonymous structs as a GNU extension. I have updated the assert to take that into account.

This fixes: https://github.com/llvm/llvm-project/issues/58800

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

show more ...

Disable -Wmissing-prototypes for internal linkage functions that aren't explicitly marked "static"

Some functions can end up non-externally visible despite not being
declared "static" or in an unnam

Disable -Wmissing-prototypes for internal linkage functions that aren't explicitly marked "static"

Some functions can end up non-externally visible despite not being
declared "static" or in an unnamed namespace in C++ - such as by having
parameters that are of non-external types.

Such functions aren't mistakenly intended to be defining some function
that needs a declaration. They could be maybe more legible (except for
the operator new example) with an explicit static, but that's a
stylistic thing outside what should be addressed by a warning.

This reapplies 275c56226d7fbd6a4d554807374f78d323aa0c1c - once we figure
out what to do about the change in behavior for -Wnon-c-typedef-for-linkage
(this reverts the revert commit 85ee1d3ca1d06b6bd3477515b8d0c72c8df7c069)

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

show more ...

[C++20] Support for lambdas in unevaluated context

Partially implement P0315R4.

This patch allow lambda in unevaluated context.
It does not implement temp.deduct/9.

PR44406: Follow behavior of array bound constant folding in more recent versions of GCC.

Old GCC used to aggressively fold VLAs to constant-bound arrays at block
scope in GNU mode. That's non-confor

PR44406: Follow behavior of array bound constant folding in more recent versions of GCC.

Old GCC used to aggressively fold VLAs to constant-bound arrays at block
scope in GNU mode. That's non-conforming, and more modern versions of
GCC only do this at file scope. Update Clang to do the same.

Also promote the warning for this from off-by-default to on-by-default
in all cases; more recent versions of GCC likewise warn on this by
default.

This is still slightly more permissive than GCC, as pointed out in
PR44406, as we still fold VLAs to constant arrays in structs, but that
seems justifiable given that we don't support VLA-in-struct (and don't
intend to ever support it), but GCC does.

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

show more ...

Ensure that we don't compute linkage for an anonymous class too early if
it has a member whose name is the same as a builtin.

Fixes a regression from the introduction of BuiltinAttr.

[Sema] Diagnose more cases of static data members in local or unnamed classes

We currently diagnose static data members directly contained in unnamed classes,
but we should also diagnose when they'r

[Sema] Diagnose more cases of static data members in local or unnamed classes

We currently diagnose static data members directly contained in unnamed classes,
but we should also diagnose when they're in a class that is nested (directly or
indirectly) in an unnamed class. Do this by iterating up the list of parent
DeclContexts and checking if any is an unnamed class.

Similarly also check for function or method DeclContexts (which includes things
like blocks and openmp captured statements) as then the class is considered to
be a local class, which means static data members aren't allowed.

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

show more ...

Fix false positive with -Wnon-c-typedef-for-linkage

Implicit methods for structs can confuse the warning, so exclude checking
the Decl's that are implicit. Implicit Decl's for lambdas still need to

Fix false positive with -Wnon-c-typedef-for-linkage

Implicit methods for structs can confuse the warning, so exclude checking
the Decl's that are implicit. Implicit Decl's for lambdas still need to
be checked, so skipping all implicit Decl's won't work.

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

show more ...

Implement P1766R1: diagnose giving non-C-compatible classes a typedef name for linkage purposes.

Summary:
Due to a recent (but retroactive) C++ rule change, only sufficiently
C-compatible classes ar

Implement P1766R1: diagnose giving non-C-compatible classes a typedef name for linkage purposes.

Summary:
Due to a recent (but retroactive) C++ rule change, only sufficiently
C-compatible classes are permitted to be given a typedef name for
linkage purposes. Add an enabled-by-default warning for these cases, and
rephrase our existing error for the case where we encounter the typedef
name for linkage after we've already computed and used a wrong linkage
in terms of the new rule.

Reviewers: rjmccall

Subscribers: cfe-commits

Tags: #clang

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

show more ...

Add missing diagnostic for anonymous struct/union definitions that don't
introduce any names.

llvm-svn: 359051

[Clang Tablegen][RFC] Allow Early Textual Substitutions in `Diagnostic` messages.

Summary:
There are cases where the same string or select is repeated verbatim in a lot of diagnostics. This can be a

[Clang Tablegen][RFC] Allow Early Textual Substitutions in `Diagnostic` messages.

Summary:
There are cases where the same string or select is repeated verbatim in a lot of diagnostics. This can be a pain to maintain and update. Tablegen provides no way stash the common text somewhere and reuse it in the diagnostics, until now!

This patch allows diagnostic texts to contain `%sub{<definition-name>}`, where `<definition-name>` names a Tablegen record of type `TextSubstitution`. These substitutions are done early, before the diagnostic string is otherwise processed. All `%sub` modifiers will be replaced before the diagnostic definitions are emitted.

The substitution must specify all arguments used by the substitution, and modifier indexes in the substitution are re-numbered accordingly. For example:

```
def select_ovl_candidate : TextSubstitution<"%select{function|constructor}0%select{| template| %2}1">;
```
when used as
```
"candidate `%sub{select_ovl_candidate}3,2,1 not viable"
```
will act as if we wrote:
```
"candidate %select{function|constructor}3%select{| template| %1}2 not viable"
```

Reviewers: rsmith, rjmccall, aaron.ballman, a.sidorin

Reviewed By: rjmccall

Subscribers: cfe-commits

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

llvm-svn: 332799

show more ...

Add test for anonymous struct containing an implicitly private data member.

Patch by Jacob Young!

llvm-svn: 300266

Lit C++11 Compatibility Patch #8

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

llvm-svn: 266387

Diagnose typedef names for linkage purposes that would change
a previously-computed linkage as an unsupportable error condition.

Per discussion on cfe-commits, this appears to be a
difficult-to-reso

Diagnose typedef names for linkage purposes that would change
a previously-computed linkage as an unsupportable error condition.

Per discussion on cfe-commits, this appears to be a
difficult-to-resolve flaw in our implementation approach;
we may pursue this as a language defect, but for now it's
better to diagnose it as unsupported than to produce
inconsistent results (or assertions). Anything that we can
do to limit how often this diagnostic fires, such as the
changes in r200380, is probably for the best, though.

llvm-svn: 200438

show more ...

Properly compute triviality for explicitly-defaulted or deleted special members.
Remove pre-standard restriction on explicitly-defaulted copy constructors with
'incorrect' parameter types, and instea

Properly compute triviality for explicitly-defaulted or deleted special members.
Remove pre-standard restriction on explicitly-defaulted copy constructors with
'incorrect' parameter types, and instead just make those special members
non-trivial as the standard requires.

This required making CXXRecordDecl correctly handle classes which have both a
trivial and a non-trivial special member of the same kind.

This also fixes PR13217 by reimplementing DiagnoseNontrivial in terms of the
new triviality computation technology.

llvm-svn: 169667

show more ...

Don't provide errors for anonymous unions when they're actually anonymous classes.

llvm-svn: 142551

Emit diagnostic error when the field of an anonymous struct is non trivial.

llvm-svn: 111158