This Lexer test unconditionally used the i128 integer literal suffix.
This suffix is only available to targets that have 128-bit arithmetic
support.
llvm-svn: 211446
Anyone enabling this warning would expect to hear about all occurrences
including those in system headers that can cause non-reproducible builds.
To achieve this, rework ShowInSystemHeader to remove broken unused mapping code
that didn't make sense with a simpler and correct scheme.
llvm-svn: 210512
digits. Turns out we have completely separate lexing codepaths for floating
point numbers depending on whether or not they start with a zero. Who knew...
=)
llvm-svn: 206932
At one point, -fexceptions was a synonym for -fcxx-exceptions. While
the driver options still enables cxx-exceptions by default, the cc1
flag is purely about exception tables and this doesn't account for
objective C exceptions. Because of this, checking for the
cxx_exceptions feature in objective C++ often gives the wrong answer.
The cxx_exceptions feature should be based on the -fcxx-exceptions cc1
flag, not -fexceptions. Furthermore, at some point the tests were
changed to use cc1 even though they were testing the driver behaviour.
We're better off testing both the driver and cc1 here.
llvm-svn: 206352
The -fms-extensions option affects a number of subtle front-end C/C++
behaviors, and it would be useful to be able to distinguish MS keywords
from regular identifiers in the ms-extensions mode even if the triple
does not define a Windows target. It should make life easier if anyone
needs to port their Windows codes to elsewhere.
Differential Revision: http://reviews.llvm.org/D3034
llvm-svn: 206069
Unfortunately, XFAIL applies to the entire file. Split the test into two
different units, enabling the proper application of XFAIL on the test which is
expected to fail on Windows.
llvm-svn: 203633
The warning for backslash and newline separated by whitespace was missed in
this code path.
backslash<whitespace><newline> is handled differently from compiler to compiler
so it's important to warn consistently where there's ambiguity.
Matches similar handling of block comments and non-comment lines.
llvm-svn: 197331
This patch was submitted to the list for review and didn't receive a LGTM.
(In fact one explicit objection and one query were raised.)
This reverts commit r197295.
llvm-svn: 197299
Previously, a line like
// expected-error-re {{foo}}
treats the entirety of foo as a regex. This is inconvenient when matching type
names containing regex characters. For example, to match
"void *(class test8::A::*)(void)" inside such a regex, one would have to type
"void \*\(class test8::A::\*\)\(void\)".
This patch changes the semantics of expected-error-re to only treat the parts
of the directive wrapped in double curly braces as regexes. This avoids the
escaping problem and leads to nicer patterns for those cases; see e.g. the
change to test/Sema/format-strings-scanf.c.
(The balanced search for closing }} of a directive also makes us handle the
full directive in test\SemaCXX\constexpr-printing.cpp:41 and :53.)
Differential Revision: http://llvm-reviews.chandlerc.com/D2388
llvm-svn: 197092
If the edit distance between the two macros is more than 50%, DefinedMacro may not be header guard or can be header guard of another header file or it might be defining something completely different set by the build environment.
llvm-svn: 192547
Summary:
This fixes PR17145 and avoids unknown pragma warnings.
This change does not attempt to map MSVC warning numbers to clang
warning flags. Perhaps in the future we will implement a mapping for
some common subset of Microsoft warnings, but for now we don't.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1652
llvm-svn: 190726
This patch adds the following flags covering existing warnings:
-Wgnu-zero-variadic-macro-arguments
-Wgnu-imaginary-constant
-Wgnu-binary-literal
-Wgnu-zero-line-directive
Patch by Peter Lewis.
llvm-svn: 190017
If the user has requested this warning, we should emit it, even if it's not
an extension in the current language mode. However, being an extension is
more important, so prefer the pedantic warning or the pedantic-compatibility
warning if those are enabled.
<rdar://problem/12922063>
llvm-svn: 189110
Various tests had sprung up over the years which had --check-prefix=ABC on the
RUN line, but "CHECK-ABC:" later on. This happened to work before, but was
strictly incorrect. FileCheck is getting stricter soon though.
Patch by Ron Ofir.
llvm-svn: 188174
It turns out that Plum Hall depends on us not emitting an error on
integer literals which fit into long long, but fit into
unsigned long long. So C99 conformance requires not conforming to C99. :)
llvm-svn: 187172
Switch some warnings over to errors which should never have been warnings
in the first place. (Also, a minor fix to the preprocessor rules for
integer literals while I'm here.)
llvm-svn: 186903
and a '!defined(X)' if we find a broken header guard. This is suboptimal; we
should point the diagnostic at the 'X' token not the 'if' token, but it fixes
the crash.
llvm-svn: 184054
properly. This warning checks that the #ifndef and #define directives at
the beginning of a header refer to the same macro name. Includes a fix-it
hint to correct the header guard.
llvm-svn: 183867
This commit improves Clang's diagnostics for string initialization.
Where it would previously say:
/tmp/a.c:3:9: error: array initializer must be an initializer list
wchar_t s[] = "Hi";
^
/tmp/a.c:4:6: error: array initializer must be an initializer list or string literal
char t[] = L"Hi";
^
It will now say
/tmp/a.c:3:9: error: initializing wide char array with non-wide string literal
wchar_t s[] = "Hi";
^
/tmp/a.c:4:6: error: initializing char array with wide string literal
char t[] = L"Hi";
^
As a bonus, it also fixes the fact that Clang would previously reject
this valid C11 code:
char16_t s[] = u"hi";
char32_t t[] = U"hi";
because it would only recognize the built-in types for char16_t and
char32_t, which do not exist in C.
llvm-svn: 181880
Add __has_feature and __has_extension checks for C++1y features (based on the provisional names from
the C++ features study group), and update documentation to match.
llvm-svn: 181342
MSVC provides __wchar_t, either as an alias for the built-in wchar_t
type, or as a separate type depending on language (C vs C++) and flags
(-fno-wchar).
In -fms-extensions, Clang will simply accept __wchar_t as an alias for
whatever type is used for wide character literals. In -fms-compatibility, we
try to mimic MSVC's behavior by always making __wchar_t a builtin type.
This fixes PR15815.
llvm-svn: 181004
Richard Smith