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.
Functions without prototypes in C (also known as K&R C functions) were
introduced into C89 as a deprecated feature and C2x is now reclaiming
that syntax space with different semantics. However, Clang's
-Wstrict-prototypes diagnostic is off-by-default (even in pedantic
mode) and does not suffice to warn users about issues in their code.
This patch changes the behavior of -Wstrict-prototypes to only diagnose
declarations and definitions which are not going to change behavior in
C2x mode, and enables the diagnostic in -pedantic mode. The diagnostic
is now specifically about the fact that the feature is deprecated.
It also adds -Wdeprecated-non-prototype, which is grouped under
-Wstrict-prototypes and diagnoses declarations or definitions which
will change behavior in C2x mode. This diagnostic is enabled by default
because the risk is higher for the user to continue to use the
deprecated feature.
Differential Revision: https://reviews.llvm.org/D122895
This adds support for multiple attributes in `#pragma clang attribute push`, for example:
```
```
or
```
```
Related attributes can now be applied with a single pragma, which makes it harder for developers to make an accidental error later when editing the code.
rdar://78269653
Differential Revision: https://reviews.llvm.org/D121283
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 sixth batch of tests being updated (there are a significant
number of other tests left to be updated).
The `printf` specifier `%n` is not supported on Android's libc and will soon be removed from Fuchsia's
Reviewed By: enh
Differential Revision: https://reviews.llvm.org/D117611
This adds the Unicode 13 data for XID_Start and XID_Continue.
The definition of valid identifier is changed in all C++ modes
as P1949 (https://wg21.link/p1949) was accepted by WG21 as a defect
report.
This commit adds support for Mac Catalyst availability attribute, as
supported by the Apple clang compiler. A follow-up commit will provide
additional support for inferring Mac Catalyst availability from macOS
availability using the mapping in the SDKSettings.json.
Differential Revision: https://reviews.llvm.org/D105052
Word on the grapevine was that the committee had some discussion that
ended with unanimous agreement on eliminating relational function pointer comparisons.
We wanted to be bold and just ban all of them cold turkey.
But then we chickened out at the last second and are going for
eliminating just the spaceship overload candidate instead, for now.
See D104680 for reference.
This should be fine and "safe", because the only possible semantic change this
would cause is that overload resolution could possibly be ambiguous if
there was another viable candidate equally as good.
But to save face a little we are going to:
* Issue an "error" for three-way comparisons on function pointers.
But all this is doing really is changing one vague error message,
from an "invalid operands to binary expression" into an
"ordered comparison of function pointers", which sounds more like we mean business.
* Otherwise "warn" that comparing function pointers like that is totally
not cool (unless we are told to keep quiet about this).
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D104892
These are intended to mimic warnings available in gcc.
-Wunused-but-set-variable is triggered in the case of a variable which
appears on the LHS of an assignment but not otherwise used.
For instance:
void f() {
int x;
x = 0;
}
-Wunused-but-set-parameter works similarly, but for function parameters
instead of variables.
In C++, they are triggered only for scalar types; otherwise, they are
triggered for all types. This is gcc's behavior.
-Wunused-but-set-parameter is controlled by -Wextra, while
-Wunused-but-set-variable is controlled by -Wunused. This is slightly
different from gcc's behavior, but seems most consistent with clang's
behavior for -Wunused-parameter and -Wunused-variable.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D100581
Create fix-it hints to fix the order of constructors.
To make this a lot simpler, I've grouped all the warnings for each out of order initializer into 1.
This is necessary as fixing one initializer would often interfere with other initializers.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D98745
In case a char-literal of type int (C/ObjectiveC) corresponds to a
format specifier with the %hh length modifier, don't treat the literal
as of type char for issuing diagnostics, as otherwise this results in:
printf("%hhd", 'e');
warning: format specifies type 'char' but the argument has type 'char'.
Differential revision: https://reviews.llvm.org/D97951
If a static assert has a message as the right side of an and condition, suggest a fix it of replacing the '&&' to ','.
`static_assert(cond && "Failed Cond")` -> `static_assert(cond, "Failed cond")`
This use case comes up when lazily replacing asserts with static asserts.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D89065
Add fixits for messaging self in MRR or using super, as the intent is
clear, and it turns out people do that a lot more than expected.
Allow for objc_direct_members on main interfaces, it's extremely useful
for internal only classes, and proves to be quite annoying for adoption.
Add some better warnings around properties direct/non-direct clashes (it
was done for methods but properties were a miss).
Add some errors when direct properties are marked @dynamic.
Radar-Id: rdar://problem/58355212
Signed-off-by: Pierre Habouzit <phabouzit@apple.com>
Differential Revision: https://reviews.llvm.org/D73755
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.
Add fixits for messaging self in MRR or using super, as the intent is
clear, and it turns out people do that a lot more than expected.
Allow for objc_direct_members on main interfaces, it's extremely useful
for internal only classes, and proves to be quite annoying for adoption.
Add some better warnings around properties direct/non-direct clashes (it
was done for methods but properties were a miss).
Radar-Id: rdar://problem/58355212
Signed-off-by: Pierre Habouzit <phabouzit@apple.com>
This is mostly the same as the
[[clang::require_constant_initialization]] attribute, but has a couple
of additional syntactic and semantic restrictions.
In passing, I added a warning for the attribute form being added after
we have already seen the initialization of the variable (but before we
see the definition); that case previously slipped between the cracks and
the attribute was silently ignored.
llvm-svn: 370972
This permits an init-capture to introduce a new pack:
template<typename ...T> auto x = [...a = T()] { /* a is a pack */ };
To support this, the mechanism for allowing ParmVarDecls to be packs has
been extended to support arbitrary local VarDecls.
llvm-svn: 361300
Summary:
This adds a new error for missing parentheses around lambdas in delete operators.
```
int main() {
delete []() { return new int(); }();
}
```
This will result in:
```
test.cpp:2:3: error: '[]' after delete interpreted as 'delete[]'
delete []() { return new int(); }();
^~~~~~~~~
test.cpp:2:9: note: add parentheses around the lambda
delete []() { return new int(); }();
^
( )
```
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: riccibruno, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D36357
llvm-svn: 361119
template name is not visible to unqualified lookup.
In order to support this without a severe degradation in our ability to
diagnose typos in template names, this change significantly restructures
the way we handle template-id-shaped syntax for which lookup of the
template name finds nothing.
Instead of eagerly diagnosing an undeclared template name, we now form a
placeholder template-name representing a name that is known to not find
any templates. When the parser sees such a name, it attempts to
disambiguate whether we have a less-than comparison or a template-id.
Any diagnostics or typo-correction for the name are delayed until its
point of use.
The upshot should be a small improvement of our diagostic quality
overall: we now take more syntactic context into account when trying to
resolve an undeclared identifier on the left hand side of a '<'. In
fact, this works well enough that the backwards-compatible portion (for
an undeclared identifier rather than a lookup that finds functions but
no function templates) is enabled in all language modes.
llvm-svn: 360308
recursively captured.
Under ARC, a block variable is zero-initialized when it is recursively
captured by the block literal initializer.
rdar://problem/11022762
llvm-svn: 359049
We want to make objc_nonlazy_class apply to implementations, but ran into this.
There doesn't seem to be any reason that this isn't supported.
Differential revision: https://reviews.llvm.org/D60542
llvm-svn: 358200
Currently, we only accept clang as the scoped attribute identifier for double square bracket attributes provided by Clang, but this has the potential to conflict with user-defined macros. To help alleviate these concerns, this introduces the _Clang scoped attribute identifier as an alias for clang. It also introduces a warning with a fixit on the off chance someone attempts to use __clang__ as the scoped attribute (which is a predefined compiler identification macro).
llvm-svn: 346521
This diff adds a fixit to suggest removing unused lambda captures
in the appropriate diagnostic.
Patch by Andrew Comminos!
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D48845
llvm-svn: 337148
Summary:
Pick D42933 back up, and make NSInteger/NSUInteger with %zu/%zi specifiers on Darwin warn only in pedantic mode. The default -Wformat recently started warning for the following code because of the added support for analysis for the '%zi' specifier.
NSInteger i = NSIntegerMax;
NSLog(@"max NSInteger = %zi", i);
The problem is that on armv7 %zi is 'long', and NSInteger is typedefed to 'int' in Foundation. We should avoid this warning as it's inconvenient to our users: it's target specific (happens only on armv7 and not arm64), and breaks their existing code. We should also silence the warning for the '%zu' specifier to ensure consistency. This is acceptable because Darwin guarantees that, despite the unfortunate choice of typedef, sizeof(size_t) == sizeof(NS[U]Integer), the warning is therefore noisy for pedantic reasons. Once this is in I'll update public documentation.
Related discussion on cfe-dev:
http://lists.llvm.org/pipermail/cfe-dev/2018-May/058050.html
<rdar://36874921&40501559>
Reviewers: ahatanak, vsapsai, alexshap, aaron.ballman, javed.absar, jfb, rjmccall
Subscribers: kristof.beyls, aheejin, cfe-commits
Differential Revision: https://reviews.llvm.org/D47290
llvm-svn: 335393
function-style cast.
This fires for cases such as
T(x);
... where 'x' was previously declared and T is a type. This construct declares
a variable named 'x' rather than the (probably expected) interpretation of a
function-style cast of 'x' to T.
llvm-svn: 314570
Fixes nullability fix-it for `id<SomeProtocol>`. With this change
nullability specifier is inserted after ">" instead of between
"id" and "<".
rdar://problem/34260995
Reviewers: jordan_rose, doug.gregor, ahatanak, arphaman
Reviewed By: jordan_rose
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38327
llvm-svn: 314473
C11 standard refers to the unsigned counterpart of the type ptrdiff_t
in the paragraph 7.21.6.1p7 where it defines the format specifier %tu.
In Clang (in PrintfFormatString.cpp, lines 508-510) there is a FIXME for this case,
in particular, Clang didn't diagnose %tu issues at all, i.e.
it didn't emit any warnings on the code printf("%tu", 3.14).
In this diff we add a method getUnsignedPointerDiffType for getting the corresponding type
similarly to how it's already done in the other analogous cases (size_t, ssize_t, ptrdiff_t etc)
and fix -Wformat diagnostics for %tu plus the emitted fix-it as well.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D38270
llvm-svn: 314470
For the triple thumbv7-apple-ios8.0.0 ssize_t is long and size_t is unsigned long,
while NSInteger is int and NSUinteger is unsigned int. Following
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/Strings/Articles/formatSpecifiers.html
Clang catches it and insert a cast to long, for example
printf("%zd", getNSInteger())
will be replaced with
printf("%zd", (long)getNSInteger())
but since the underlying type of ssize_t is long the specifier "%zd" is not getting replaced.
This diff changes this behavior to enable replacing the specifier "%zd" with the correct one.
Differential revision: https://reviews.llvm.org/D38159
Test plan: make check-all
llvm-svn: 314011
This patch, by hamzasood, implements P0409R2, and allows [=, this] pre-C++2a as an extension (with appropriate warnings) for consistency.
https://reviews.llvm.org/D36572
Thanks Hamza!
llvm-svn: 311224
Base::TraverseStmt when visiting the then/else branches of if statements
This ensures that the statement stack is correctly tracked and correct
multi-statement fixit is generated inside of an if (@available)
llvm-svn: 311088
The %T lit expansion expands to a common directory shared between all the tests in the same directory, which is unexpected and unintuitive, and more importantly, it's been a source of subtle race conditions and flaky tests. In https://reviews.llvm.org/D35396, it was agreed that it would be best to simply ban %T and only keep %t, which is unique to each test. When a test needs a temporary directory, it can just create one using mkdir %t.
This patch removes %T in clang.
Differential Revision: https://reviews.llvm.org/D36437
llvm-svn: 310950
This diff makes the test FixIt/format.m more robust.
The issue was caught by the build bot clang-cmake-thumbv7-a15.
Test plan: make check-all
llvm-svn: 308073
Aaron Ballman