Make diagnostic pragma override -Werror=foo and DefaultError warnings

In GCC, `#pragma GCC diagnostic warning "-Wfoo"` overrides command-line
`-Werror=foo` and errors that can become warnings (pedwa

Make diagnostic pragma override -Werror=foo and DefaultError warnings

In GCC, `#pragma GCC diagnostic warning "-Wfoo"` overrides command-line
`-Werror=foo` and errors that can become warnings (pedwarn with
-pedantic-errors and permerror).

```
#pragma GCC diagnostic warning "-Wnarrowing"
int x = {4.2};
#pragma GCC diagnostic warning "-Wundef"
#if FOO
#endif

// gcc -c -Werror=undef -Werror=narrowing => two warnings
```

These diagnostics are similar to our Warning/ExtWarn/Extension
diagnostics with DefaultError. This patch ports the behavior to Clang.

Fix #93474

Pull Request: https://github.com/llvm/llvm-project/pull/93647

show more ...

Fix a failing assertion with implicit function definitions

When implicitly defining a function in C, we would try to find an
appropriate declaration context for the function to be declared within.
H

Fix a failing assertion with implicit function definitions

When implicitly defining a function in C, we would try to find an
appropriate declaration context for the function to be declared within.
However, we did not account for GNU statement expressions, which
masquerade as a compound statement and can be used in other contexts
such as within structure member declarations.

Fixes https://github.com/llvm/llvm-project/issues/48579

show more ...

[C11/C2x] Change the behavior of the implicit function declaration warning

C89 had a questionable feature where the compiler would implicitly
declare a function that the user called but was never pr

[C11/C2x] Change the behavior of the implicit function declaration warning

C89 had a questionable feature where the compiler would implicitly
declare a function that the user called but was never previously
declared. The resulting function would be globally declared as
extern int func(); -- a function without a prototype which accepts zero
or more arguments.

C99 removed support for this questionable feature due to severe
security concerns. However, there was no deprecation period; C89 had
the feature, C99 didn't. So Clang (and GCC) both supported the
functionality as an extension in C99 and later modes.

C2x no longer supports that function signature as it now requires all
functions to have a prototype, and given the known security issues with
the feature, continuing to support it as an extension is not tenable.

This patch changes the diagnostic behavior for the
-Wimplicit-function-declaration warning group depending on the language
mode in effect. We continue to warn by default in C89 mode (due to the
feature being dangerous to use). However, because this feature will not
be supported in C2x mode, we've diagnosed it as being invalid for so
long, the security concerns with the feature, and the trivial
workaround for users (declare the function), we now default the
extension warning to an error in C99-C17 mode. This still gives users
an easy workaround if they are extensively using the extension in those
modes (they can disable the warning or use -Wno-error to downgrade the
error), but the new diagnostic makes it more clear that this feature is
not supported and should be avoided. In C2x mode, we no longer allow an
implicit function to be defined and treat the situation the same as any
other lookup failure.

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

show more ...

Use functions with prototypes when appropriate; NFC

A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a protot

Use functions with prototypes when appropriate; NFC

A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a prototype for the situations where the test is not specific to K&R C
declarations. e.g.,

void func();

becomes

void func(void);

This is the second batch of tests being updated (there are a significant
number of other tests left to be updated).

show more ...

[test] Properly test -Werror-implicit-function-declaration and -Wvec-elem-size

Reviewed By: dblaikie

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

PR34822: Fix a collection of related bugs with our handling of C89 implicit function declarations.

We were injecting the function into the wrong semantic context, resulting in it
failing to be regis

PR34822: Fix a collection of related bugs with our handling of C89 implicit function declarations.

We were injecting the function into the wrong semantic context, resulting in it
failing to be registered as a global for redeclaration lookup. As a
consequence, we accepted invalid code since r310616.

Fixing that resulted in the "out-of-scope declaration" diagnostic firing a lot
more often. It turned out that warning codepath was non-conforming, because it
did not cause us to inject the implicitly-declared function into the enclosing
block scope. We now only warn if the type of the out-of-scope declaration
doesn't match the type of an implicitly-declared function; in all other cases,
we produce the normal warning for an implicitly-declared function.

llvm-svn: 314871

show more ...

Place implictly declared functions at block scope

Such implicitly declared functions behave as if the enclosing block
contained the declaration extern int name() (C90, 6.3.3.2 Function calls),
thus

Place implictly declared functions at block scope

Such implicitly declared functions behave as if the enclosing block
contained the declaration extern int name() (C90, 6.3.3.2 Function calls),
thus their names should have block scope (C90, 6.1.2.1 Scope of identifiers).

This patch fixes https://bugs.llvm.org/show_bug.cgi?id=33224

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

llvm-svn: 310616

show more ...

Convert SemaDecl.cpp to pass callback objects to CorrectTypo.

Includes tests highlighting the cases where accuracy has improved
(there is one call that does no filtering beyond selecting the set
of

Convert SemaDecl.cpp to pass callback objects to CorrectTypo.

Includes tests highlighting the cases where accuracy has improved
(there is one call that does no filtering beyond selecting the set
of allowed keywords, and one call that only triggers for ObjC code
for which a test by someone who knows ObjC would be welcome). Also
fixes a small typo in one of the suggestion messages, and drops a
malformed "expected-note" for a suggestion that did not occur even
when the malformed note was committed as r145930.

llvm-svn: 148420

show more ...

Only do typo correction for implicit function decls when
they are treated as errors.

Doing typo correction when these are just warnings slows down the
compilation of source which deliberately uses i

Only do typo correction for implicit function decls when
they are treated as errors.

Doing typo correction when these are just warnings slows down the
compilation of source which deliberately uses implicit function
declarations.

llvm-svn: 146153

show more ...

Suggest typo corrections for implicit function declarations.

A mistyped function call becomes an inmplicit function declaration in C.
Suggest typo correction when one can be found.

llvm-svn: 145930

fix PR7280 by making the warning on code like this:

int test1() {
return;
}

default to an error.

llvm-svn: 108108

add a bunch of missing prototypes to tests

llvm-svn: 93072

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 ...

Rename clang to clang-cc.

Tests and drivers updated, still need to shuffle dirs.

llvm-svn: 67602

Merge function-return.c into function.c

Fix PR2790 by making a warning an EXTWARN instead of EXTENSION.
Add a new EXTENSION warning for "return (some void expression);"

llvm-svn: 61187

Make all the 'redefinition' diagnostics more consistent, and make the
"previously defined here" diagnostics all notes.

llvm-svn: 59920

Add explicit support for diagnosing implicit function decls.
Without this, the diagnostic is very confusing. The diag is now consistent with gcc as well.

llvm-svn: 49214