Now that this is a C-only warning, we can use "static" instead of "internal
linkage", which is a term developers are probably more familiar with.
This makes for a better warning message. The warning name was changed to match,
since "internal linkage" is not mentioned in the warning text anymore.
llvm-svn: 158853
The original r158700 caused crashes in the gcc test suite,
g++.abi/vtable3a.C among others. It also caused failures in the libc++
test suite.
llvm-svn: 158749
Per post-commit review, it's not appropriate to use ExtWarn in C++, because
we can't prove that the inline function will actually be defined in more than
one place (and thus we can't prove that this violates the ODR).
This removes the warning entirely from uses in the main source file in C++.
llvm-svn: 158689
This includes treating anonymous namespaces like internal linkage, and allowing
const variables to be used even if internal. The whole thing's been broken out
into a separate function to avoid nested ifs.
llvm-svn: 158683
This handles the very common case of people writing inline functions in their
main source files and not tagging them as inline. These cases should still
behave as the user intended. (The diagnostic is still emitted as an extension.)
I'm reworking this code anyway to account for C++'s equivalent restriction in
[basic.def.odr]p6, but this should get some bots back to green.
llvm-svn: 158666
This is explicitly forbidden in C99 6.7.4p3. This is /not/ forbidden in C++,
probably because by default file-scope const/constexpr variables have internal
linkage, while functions have external linkage. There's also the issue of
anonymous namespaces to consider. Nevertheless, there should probably be a
similar warning, since the semantics of inlining a function that references
a variable with internal linkage do not seem well-defined.
<rdar://problem/11577619>
llvm-svn: 158531
In standard C since C89, a 'translation-unit' is syntactically defined to have
at least one "external-declaration", which is either a decl or a function
definition. In Clang the latter gives us a declaration as well.
The tricky bit about this warning is that our predefines can contain external
declarations (__builtin_va_list and the 128-bit integer types). Therefore our
AST parser now makes sure we have at least one declaration that doesn't come
from the predefines buffer.
Also, remove bogus warning about empty source files. This doesn't catch source
files that only contain comments, and never fired anyway because of our
predefines.
PR12665 and <rdar://problem/9165548>
llvm-svn: 158085
-Wsometimes-uninitialized diagnostics to make it clearer that the cause
of the issue may be a condition which must always evaluate to true or
false, rather than an uninitialized variable.
To emphasize this, add a new note with a fixit which removes the
impossible condition or replaces it with a constant.
Also, downgrade the diagnostic from -Wsometimes-uninitialized to
-Wconditional-uninitialized when it applies to a range-based for loop,
since the condition is not written explicitly in the code in that case.
llvm-svn: 157511
-Wsometimes-uninitialized. This detects cases where an explicitly-written branch
inevitably leads to an uninitialized variable use (so either the branch is dead
code or there is an uninitialized use bug).
This chunk of warnings tentatively lives within -Wuninitialized, in order to
give it more visibility to existing Clang users.
llvm-svn: 157458
about argument type mismatch.
This gives a nicer diagnostic in cases like
printf(fmt,
i);
where previously the snippet just pointed at 'fmt' (with a note at the
definition of fmt).
It's a wash for cases like
printf("%f",
i);
where previously we snippeted the offending portion of the format string,
but didn't indicate which argument was at fault.
llvm-svn: 156968
Moves the bool bail-out down a little in SemaChecking - so now
-Wnull-conversion and -Wliteral-conversion can fire when the target type is
bool.
Also improve the wording/details in the -Wliteral-conversion warning to match
the -Wconstant-conversion.
llvm-svn: 156826
Currently cold functions are marked with the "optsize" attribute in CodeGen
so they are always optimized for size. The hot attribute is just ignored,
LLVM doesn't have a way to express hotness at the moment.
llvm-svn: 156723
__attribute__((aligned)). Fixes <rdar://problem/11435441>, a
regression I introduced in r156003. This is the narrow fix; a more
comprehensive fix is coming.
llvm-svn: 156657
// FIXME: This needs to happen before we merge declarations. Then,
// let attribute merging cope with attribute conflicts.
This was already being done for variables, but for functions we were merging
then first and then applying the attributes. To avoid duplicating merging
logic, some of the helpers in SemaDeclAttr.cpp become methods that can
handle merging two attributes in one decl or inheriting attributes from one
decl to another.
With this change we are now able to produce errors for variables with
incompatible visibility attributes or warn about unused dllimports in
variables.
This changes the attribute list iteration back to being in reverse source
code order, as that matches what decl merging does and avoids differentiating
the two cases is the merge*Attr methods.
llvm-svn: 156531
For "%hhx", printf expects an unsigned char. This makes Clang
accept a 'char' argument for that also when using -funsigned-char.
This fixes PR12761.
llvm-svn: 156388
match gcc behavior for two conflicting visibilities in the same decl. It also
makes handling of dllimport/dllexport more natural.
As a bonus we now warn on the dllimport in
void __attribute__((dllimport)) foo13();
void __attribute__((dllexport)) foo13();
as does gcc.
llvm-svn: 156343
for having a uniform logic for adding attributes to a decl. This in turn
is needed to fix the FIXME:
// FIXME: This needs to happen before we merge declarations. Then,
// let attribute merging cope with attribute conflicts.
ProcessDeclAttributes(S, NewFD, D,
/*NonInheritable=*/false, /*Inheritable=*/true);
The idea is that mergeAvailabilityAttr will become a method. Once attributes
are processed before merging, it will be called from handleAvailabilityAttr to
handle multiple attributes in one decl:
void f(int) __attribute__((availability(ios,deprecated=3.0),
availability(ios,introduced=2.0)));
and from SemaDecl.cpp to handle multiple decls:
void f(int) __attribute__((availability(ios,deprecated=3.0)));
void f(int) __attribute__((availability(ios,introduced=2.0)));
As a bonus, use the new structure to diagnose incompatible availability
attributes added to different decls (see included testcases).
llvm-svn: 156269
Teach ASTContext about WIntType, and have it taken from TargetInfo like WCharType. Should fix test/Sema/format-strings.c for ARM, with the exception of one subtest which will fail if wint_t and wchar_t are the same size and wint_t is signed, wchar_t is unsigned.
There'll be a followup commit to fix that.
Reviewed by Chandler and Hans at http://llvm.org/reviews/r/8
llvm-svn: 156165
#define TEST int y; int x = y;
void foo() {
TEST
}
-Wuninitialized gives this warning:
invalid-loc.cc:4:3: warning: variable 'y' is uninitialized when used here
[-Wuninitialized]
TEST
^~~~
invalid-loc.cc:2:29: note: expanded from macro 'TEST'
#define TEST int y; int x = y;
^
note: initialize the variable 'y' to silence this warning
1 warning generated.
The second note lacks filename, line number, and code snippet. This change
will remove the fixit and only point to variable declaration.
invalid-loc.cc:4:3: warning: variable 'y' is uninitialized when used here
[-Wuninitialized]
TEST
^~~~
invalid-loc.cc:2:29: note: expanded from macro 'TEST'
#define TEST int y; int x = y;
^
invalid-loc.cc:4:3: note: variable 'y' is declared here
TEST
^
invalid-loc.cc:2:14: note: expanded from macro 'TEST'
#define TEST int y; int x = y;
^
1 warning generated.
llvm-svn: 156045
i32 __builtin_annotation(i32, string);
Applying it to i64 (e.g., long long) generates the following IR.
trunc i64 {{.*}} to i32
call i32 @llvm.annotation.i32
zext i32 {{.*}} to i64
The redundant truncation and extension make the result difficult to use.
This patch makes __builtin_annotation() generic.
type __builtin_annotation(type, string);
For the i64 example, it simplifies the generated IR to:
call i64 @llvm.annotation.i64
Patch by Xi Wang!
llvm-svn: 155764
Passing -verify to clang without -cc1 or -Xclang silently passes (with a
printed warning, but lit doesn't care about that). This change adds -cc1 or,
as is necessary in one case, -Xclang to fix this so that these tests are
actually verifying as intended.
I'd like to change the driver so this kind of mistake could not be made, but
I'm not entirely sure how. Further, since the driver only warns about unknown
flags in general, we could have similar bugs with a misspellings of arguments
that would be nice to find.
llvm-svn: 154776
__atomic_test_and_set, __atomic_clear, plus a pile of undocumented __GCC_*
predefined macros.
Implement library fallback for __atomic_is_lock_free and
__c11_atomic_is_lock_free, and implement __atomic_always_lock_free.
Contrary to their documentation, GCC's __atomic_fetch_add family don't
multiply the operand by sizeof(T) when operating on a pointer type.
libstdc++ relies on this quirk. Remove this handling for all but the
__c11_atomic_fetch_add and __c11_atomic_fetch_sub builtins.
Contrary to their documentation, __atomic_test_and_set and __atomic_clear
take a first argument of type 'volatile void *', not 'void *' or 'bool *',
and __atomic_is_lock_free and __atomic_always_lock_free have an argument
of type 'const volatile void *', not 'void *'.
With this change, libstdc++4.7's <atomic> passes libc++'s atomic test suite,
except for a couple of libstdc++ bugs and some cases where libc++'s test
suite tests for properties which implementations have latitude to vary.
llvm-svn: 154640
The codepath already only works for source bits > target bits, it's just that
it was testing for the source expr bits to be exactly 64. This meant simple
cases (int i = x_long / 2) were missed & ended up under the general
-Wconversion warning, which a user might not have enabled.
llvm-svn: 154626
This is not quite sufficient for libstdc++'s <atomic>: we still need
__atomic_test_and_set and __atomic_clear, and may need a more complete
__atomic_is_lock_free implementation.
We are also missing an implementation of __atomic_always_lock_free,
__atomic_nand_fetch, and __atomic_fetch_nand, but those aren't needed
for libstdc++.
llvm-svn: 154579
<stdatomic.h> header.
In passing, fix LanguageExtensions to note that C11 and C++11 are no longer
"upcoming standards" but are now actually standardized.
llvm-svn: 154513
This diagnostic seems to be production ready, it's just an oversight that it
wasn't turned on by default.
The test changes are a bit of a mixed bag. Some tests that seemed like they
clearly didn't need to use this behavior have been modified not to use it.
Others that I couldn't be sure about, I added the necessary expected-warnings
to.
It's possible the diagnostic message could be improved to make it clearer that
this warning can be suppressed by using a value that won't lose precision when
converted to the target type (but can still be a floating point literal, such
as "bool b = 1.0;").
llvm-svn: 154068
a type specifier and can be combined with unsigned. This allows libstdc++4.7 to
be used with clang in c++98 mode.
Several other changes are still required for libstdc++4.7 to work with clang in
c++11 mode.
llvm-svn: 153999
non-constant value encountered. This allows the evaluator to deduce that
expressions like (x < 5 || true) is equal to true. Previously, it would visit
x and determined that the entire expression is could not evaluated to a
constant.
This fixes PR12318.
llvm-svn: 153226
This allows us to handle extreme cases of chained binary operators without causing stack
overflow.
The binary operators that are handled with the data recursive evaluator are
comma, logical, or operators that have operands with integral or enumeration type.
Part of rdar://10941790.
llvm-svn: 152819
Err on the side of brevity and rename (while providing aliases for the original
name) -Wbool-conversions, -Wint-conversions, and -Wvector-conversions for
consistency with constant, literal, string, and sign conversion warnings. And
name the diagnostic groups explicitly while I'm here rather than rewriting the
string in the groups and sema td files.
Curiously, vector-conversion is not under -Wconversion. Perhaps it should be.
llvm-svn: 152776
defined here, but not semantically, so
new struct S {};
is always ill-formed, even if there is a struct S in scope.
We also had a couple of bugs in ParseOptionalTypeSpecifier caused by it being
under-loved (due to it only being used in a few places) so merge it into
ParseDeclarationSpecifiers with a new DeclSpecContext. To avoid regressing, this
required improving ParseDeclarationSpecifiers' diagnostics in some cases. This
also required teaching ParseSpecifierQualifierList about constexpr... which
incidentally fixes an issue where we'd allow the constexpr specifier in other
bad places.
llvm-svn: 152549
Before r151307 this part worked without compiler errors but now it only verifies
that our handling of irregular pragmas is broken compared to gcc, it has no
practical usefulness; it creates invalid structs that cannot be used for 'offsetof' testing.
If we later decide to handle irregular pragmas without compiler errors we can
put back this part.
llvm-svn: 152480
basic source character set in C++98. Add -Wc++98-compat diagnostics for same in
literals in C++11. Extend such support to cover string literals as well as
character literals, and mark N2170 as done.
This seems too minor to warrant a release note to me. Let me know if you disagree.
llvm-svn: 152444
This renames the -Wformat-non-standard flag to -Wformat-non-iso,
rewords the current warnings a bit (pointing out that a format string
is not supported by ISO C rather than being "non standard"),
and adds a warning about positional arguments.
llvm-svn: 152403
But it is in the underlying c part of clang. clang crashes
in IRGen when passing an incomplete type argument to
variadic function (instead of diagnosing the bug).
// rdar://10961370
llvm-svn: 151862
The bug that was caught by Apple's internal buildbots was valid and also showed another bug in my implementation.
These are now fixed, with regression tests added to catch them both (not Darwin-specific).
Original log:
====================
Revert r151638 because it causes assertion hit on PCH creation for Cocoa.h
Original log:
---------------------
Correctly track tags and enum members defined in the prototype of a function, and ensure they are properly scoped.
This fixes code such as:
enum e {x, y};
int f(enum {y, x} n) {
return 0;
}
This finally fixes PR5464 and PR5477.
---------------------
I also reverted r151641 which was enhancement on top of r151638.
====================
llvm-svn: 151712
Original log:
---------------------
Correctly track tags and enum members defined in the prototype of a function, and ensure they are properly scoped.
This fixes code such as:
enum e {x, y};
int f(enum {y, x} n) {
return 0;
}
This finally fixes PR5464 and PR5477.
---------------------
I also reverted r151641 which was enhancement on top of r151638.
llvm-svn: 151667
Original log:
When evaluating integer expressions handle logical operators outside
VisitBinaryOperator() to reduce stack pressure for source with huge number
of logical operators.
Fixes rdar://10913206.
llvm-svn: 151464
(Hopefully, common usage of these pragmas isn't irregular enough to break our current handling. Doug has ideas for a more crazy approach if necessary.)
llvm-svn: 151307
This adds the -Wformat-non-standard flag (off by default,
enabled by -pedantic), which warns about non-standard
things in format strings (such as the 'q' length modifier,
the 'S' conversion specifier, etc.)
llvm-svn: 151154
This is in preparation for being able to warn about 'q' and other
non-standard format string features.
It also allows us to print its name correctly.
llvm-svn: 150697
Jordan Rose