This unfortunately results in a substantial breaking change when
switching to C++20, but it's not yet clear what / how much we should
do about that. We may want to add a compatibility conversion from
u8 string literals to const char*, similar to how C++98 provided a
compatibility conversion from string literals to non-const char*,
but that's not handled by this patch.
The feature can be disabled in C++20 mode with -fno-char8_t.
llvm-svn: 346892
This can be used to detect whether the code is being built with UBSan using
the __has_feature(undefined_behavior_sanitizer) predicate.
Differential Revision: https://reviews.llvm.org/D52386
llvm-svn: 342793
This can be used to detect whether the code is being built with XRay
instrumentation using the __has_feature(xray_instrument) predicate.
Differential Revision: https://reviews.llvm.org/D52159
llvm-svn: 342358
Boilerplate code for using KMSAN instrumentation in Clang.
We add a new command line flag, -fsanitize=kernel-memory, with a
corresponding SanitizerKind::KernelMemory, which, along with
SanitizerKind::Memory, maps to the memory_sanitizer feature.
KMSAN is only supported on x86_64 Linux.
It's incompatible with other sanitizers, but supports code coverage
instrumentation.
llvm-svn: 341641
Changes the default Windows target triple returned by
GetHostTriple.cmake from the old environment names (which we wanted to
move away from) to newer, normalized ones. This also requires updating
all tests to use the new systems names in constraints.
Differential Revision: https://reviews.llvm.org/D47381
llvm-svn: 339307
Libc++ needs to know when aligned allocation is supported by clang, but is
otherwise unavailable at link time. Otherwise, libc++ will incorrectly end up
generating calls to `__builtin_operator_new`/`__builtin_operator_delete` with
alignment arguments.
This patch implements the following changes:
* The `__cpp_aligned_new` feature test macro to no longer be defined when
aligned allocation is otherwise enabled but unavailable.
* The Darwin driver no longer passes `-faligned-alloc-unavailable` when the
user manually specifies `-faligned-allocation` or `-fno-aligned-allocation`.
* Instead of a warning Clang now generates a hard error when an aligned
allocation or deallocation function is referenced but unavailable.
Patch by Eric Fiselier.
Reviewers: rsmith, vsapsai, erik.pilkington, ahatanak, dexonsmith
Reviewed By: rsmith
Subscribers: Quuxplusone, cfe-commits
Differential Revision: https://reviews.llvm.org/D45015
llvm-svn: 338934
Summary: Add a flag `-fno-digraphs` to disable digraphs in the lexer, similar to `-fno-operator-names` which disables alternative names for C++ operators.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D48266
llvm-svn: 337232
This is not yet part of any C++ working draft, and so is controlled by the flag
-fchar8_t rather than a -std= flag. (The GCC implementation is controlled by a
flag with the same name.)
This implementation is experimental, and will be removed or revised
substantially to match the proposal as it makes its way through the C++
committee.
llvm-svn: 331244
ARC mode.
Declaring __strong pointer fields in structs was not allowed in
Objective-C ARC until now because that would make the struct non-trivial
to default-initialize, copy/move, and destroy, which is not something C
was designed to do. This patch lifts that restriction.
Special functions for non-trivial C structs are synthesized that are
needed to default-initialize, copy/move, and destroy the structs and
manage the ownership of the objects the __strong pointer fields point
to. Non-trivial structs passed to functions are destructed in the callee
function.
rdar://problem/33599681
Differential Revision: https://reviews.llvm.org/D41228
llvm-svn: 326307
For input `0'e+1` lexer tokenized as numeric constant only `0'e`. Later
NumericLiteralParser skipped 0 and ' as digits and parsed `e+1` as valid
exponent going past the end of the token. Because it didn't mark numeric
literal as having an error, it continued parsing and tried to expandUCNs
with StringRef of length -2.
The fix is not to parse exponent when we reached the end of token.
Discovered by OSS-Fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4588
rdar://problem/36076719
Reviewers: rsmith, t.p.northover
Reviewed By: rsmith
Subscribers: cfe-commits, jkorous-apple
Differential Revision: https://reviews.llvm.org/D41834
llvm-svn: 324419
Fix makes the loop in LexAngledStringLiteral more like the loops in
LexStringLiteral, LexCharConstant. When we skip a character after
backslash, we need to check if we reached the end of the file instead of
reading the next character unconditionally.
Discovered by OSS-Fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3832
rdar://problem/35572754
Reviewers: arphaman, kcc, rsmith, dexonsmith
Reviewed By: rsmith, dexonsmith
Subscribers: cfe-commits, rsmith, dexonsmith
Differential Revision: https://reviews.llvm.org/D41423
llvm-svn: 322390
Specifically, warn if:
* we find a character that the language standard says we must treat as an
identifier, and
* that character is not reasonably an identifier character (it's a punctuation
character or similar), and
* it renders identically to a valid non-identifier character in common
fixed-width fonts.
Some tools "helpfully" substitute the surprising characters for the expected
characters, and replacing semicolons with Greek question marks is a common
"prank".
llvm-svn: 320697
Move the logic for determining the `wchar_t` type information into the
driver. Rather than passing the single bit of information of
`-fshort-wchar` indicate to the frontend the desired type of `wchar_t`
through a new `-cc1` option of `-fwchar-type` and indicate the
signedness through `-f{,no-}signed-wchar`. This replicates the current
logic which was spread throughout Basic into the
`RenderCharacterOptions`.
Most of the changes to the tests are to ensure that the frontend uses
the correct type. Add a new test set under `test/Driver/wchar_t.c` to
ensure that we calculate the proper types for the various cases.
llvm-svn: 315126
This is a recommit of r312781; in some build configurations
variable names are omitted, so changed the new regression
test accordingly.
llvm-svn: 312794
This adds _Float16 as a source language type, which is a 16-bit floating point
type defined in C11 extension ISO/IEC TS 18661-3.
In follow up patches documentation and more tests will be added.
Differential Revision: https://reviews.llvm.org/D33719
llvm-svn: 312781
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
Previously, a preamble only included #if blocks (and friends like
ifdef) if there was a corresponding #endif before any declaration or
definition. The problem is that any header file that uses include guards
will not have a preamble generated, which can make code-completion very
slow.
To prevent errors about unbalanced preprocessor conditionals in the
preamble, and unbalanced preprocessor conditionals after a preamble
containing unfinished conditionals, the conditional stack is stored
in the pch file.
This fixes PR26045.
Differential Revision: http://reviews.llvm.org/D15994
llvm-svn: 304207
Summary: This patch is needed so that Libc++ can actually tess if Clang supports coroutines, instead of just paying lip service with a partial implementation. Otherwise the libc++ test suite will fail against older versions of Clang
Reviewers: GorNishanov, rsmith
Reviewed By: GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33536
llvm-svn: 303867
Previously, if an escaped newline was followed by a newline or a nul, we'd lex
the escaped newline as a bogus space character. This led to a bunch of
different broken corner cases:
For the pattern "\\\n\0#", we would then have a (horizontal) space whose
spelling ends in a newline, and would decide that the '#' is at the start of a
line, and incorrectly start preprocessing a directive in the middle of a
logical source line. If we were already in the middle of a directive, this
would result in our attempting to process multiple directives at the same time!
This resulted in crashes, asserts, and hangs on invalid input, as discovered by
fuzz-testing.
For the pattern "\\\n" at EOF (with an implicit following nul byte), we would
produce a bogus trailing space character with spelling "\\\n". This was mostly
harmless, but would lead to clang-format getting confused and misformatting in
rare cases. We now produce a trailing EOF token with spelling "\\\n",
consistent with our handling for other similar cases -- an escaped newline is
always part of the token containing the next character, if any.
For the pattern "\\\n\n", this was somewhat more benign, but would produce an
extraneous whitespace token to clients who care about preserving whitespace.
However, it turns out that our lexing for line comments was relying on this bug
due to an off-by-one error in its computation of the end of the comment, on the
slow path where the comment might contain escaped newlines.
llvm-svn: 300515
Summary: When using the C preprocessor with assembly files, either with a
capital `S` file extension, or with `-xassembler-with-cpp`, the Unicode escape
sequence `\u` is ignored. The `\u` pattern can be used for expanding a macro
argument that starts with `u`.
Author: Salman Arif <salman.arif@arm.com>
Reviewers: rengolin, olista01
Reviewed By: olista01
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D31765
llvm-svn: 299754
Summary: This is a patch for PR31836. As the bug replaces the path separators in the included file name with the characters following them, the test script makes sure that there's no "Ccase-insensitive-include-pr31836.h" in the warning message.
Reviewers: rsmith, eric_niebler
Reviewed By: eric_niebler
Subscribers: karies, cfe-commits
Differential Revision: https://reviews.llvm.org/D30000
llvm-svn: 295779
by providing a memchr builtin that returns char* instead of void*.
Also add a __has_feature flag to indicate the presence of constexpr forms of
the relevant <string> functions.
llvm-svn: 292555
Summary:
Also makes -fcoroutines_ts to be both a Driver and CC1 flag.
Patch mostly by EricWF.
Reviewers: rnk, cfe-commits, rsmith, EricWF
Subscribers: mehdi_amini
Differential Revision: https://reviews.llvm.org/D25130
llvm-svn: 283064
Differential Revision: http://reviews.llvm.org/D19843
Corresponding LLVM change: http://reviews.llvm.org/D19842
Re-commit after addressing issues with of generating too many warnings for Windows and asan test failures.
Patch by Eric Niebler
llvm-svn: 272562
Summary:
Adds a new -fsanitize=efficiency-working-set flag to enable esan's working
set tool. Adds appropriate tests for the new flag.
Reviewers: aizatsky
Subscribers: vitalybuka, zhaoqin, kcc, eugenis, llvm-commits
Differential Revision: http://reviews.llvm.org/D20484
llvm-svn: 270641
MSVC now supports the __is_assignable type trait intrinsic,
to enable easier and more efficient implementation of the
Standard Library's is_assignable trait.
As of Visual Studio 2015 Update 3, the VC Standard Library
implementation uses the new intrinsic unconditionally.
The implementation is pretty straightforward due to the previously
existing is_nothrow_assignable and is_trivially_assignable.
We handle __is_assignable via the same code as the other two except
that we skip the extra checks for nothrow or triviality.
Patch by Dave Bartolomeo!
Differential Revision: http://reviews.llvm.org/D20492
llvm-svn: 270458
Add supported OpenCL extensions to target info. It serves as default values to save the users of the burden setting each supported extensions and optional core features in command line.
Re-commit after fixing build error due to missing override attribute.
Differential Revision: http://reviews.llvm.org/D19484
llvm-svn: 269670
Revert r269431 due to build failure caused by warning msg:
llvm/tools/clang/lib/Basic/Targets.cpp:2090:9: error: 'setSupportedOpenCLOpts' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
void setSupportedOpenCLOpts() {
llvm-svn: 269435
Add supported OpenCL extensions to target info. It serves as default values to save the users of the burden setting each supported extensions and optional core features in command line.
Differential Revision: http://reviews.llvm.org/D19484
llvm-svn: 269431
Summary:
Adds a framework to enable the instrumentation pass for the new
EfficiencySanitizer ("esan") family of tools. Adds a flag for esan's
cache fragmentation tool via -fsanitize=efficiency-cache-frag.
Adds appropriate tests for the new flag.
Reviewers: eugenis, vitalybuka, aizatsky, filcab
Subscribers: filcab, kubabrecka, llvm-commits, zhaoqin, kcc
Differential Revision: http://reviews.llvm.org/D19169
llvm-svn: 267059
This can happen as we look for '<<<<' while scanning tokens but then expect
'<<<<\n' to tell apart perforce from diff3 conflict markers. Just harden
the pointer arithmetic.
Found by libfuzzer + asan!
llvm-svn: 265125
OpenCL Extension v1.2 s9.5 allows half precision floating point
type literals with suffices h or H when cl_khr_fp16 is enabled.
Example: half x = 1.0h;
Patch by Liu Yaxun (Sam)!
Differential Revision: http://reviews.llvm.org/D16865
llvm-svn: 261084
[cpp.cond]p4:
Prior to evaluation, macro invocations in the list of preprocessing
tokens that will become the controlling constant expression are replaced
(except for those macro names modified by the 'defined' unary operator),
just as in normal text. If the token 'defined' is generated as a result
of this replacement process or use of the 'defined' unary operator does
not match one of the two specified forms prior to macro replacement, the
behavior is undefined.
This isn't an idle threat, consider this program:
#define FOO
#define BAR defined(FOO)
#if BAR
...
#else
...
#endif
clang and gcc will pick the #if branch while Visual Studio will take the
#else branch. Emit a warning about this undefined behavior.
One problem is that this also applies to function-like macros. While the
example above can be written like
#if defined(FOO) && defined(BAR)
#defined HAVE_FOO 1
#else
#define HAVE_FOO 0
#endif
there is no easy way to rewrite a function-like macro like `#define FOO(x)
(defined __foo_##x && __foo_##x)`. Function-like macros like this are used in
practice, and compilers seem to not have differing behavior in that case. So
this a default-on warning only for object-like macros. For function-like
macros, it is an extension warning that only shows up with `-pedantic`.
(But it's undefined behavior in both cases.)
llvm-svn: 258128
This works around existing system headers which unconditionally
redefine these macros.
This is reasonably safe to do because we used to warn about it anyway
(outside of system headers). Continue to warn if the redefinition
would have changed the expansion. Still permit redefinition if the
macro is explicitly #undef'ed first.
rdar://23788307
llvm-svn: 255311
the "" and the suffix; that breaks names such as 'operator""if'. For symmetry,
also remove the space between the 'operator' and the '""'.
llvm-svn: 249641
In versions of clang prior to r238238, __declspec was recognized as a keyword in
all modes. It was then changed to only be enabled when Microsoft or Borland
extensions were enabled (and for CUDA, as a temporary measure). There is a
desire to support __declspec in Playstation code, and possibly other
environments. This commit adds a command-line switch to allow explicit
enabling/disabling of the recognition of __declspec as a keyword. Recognition
is enabled by default in Microsoft, Borland, CUDA, and PS4 environments, and
disabled in all other environments.
Patch by Warren Ristow!
llvm-svn: 249279
Binary literals predate C++14, but they are listed as a C++14 extension since
this was the first time they were standardized in the language. Move the
warning into a subgroup so it can be selectively disabled when checking for
other C++14 features.
llvm-svn: 248064
-fno-rtti-data makes it so that vtables emitted in the current TU lack
RTTI data. This means that dynamic_cast usually fails at runtime. Users
of the existing cxx_rtti feature expect all of RTTI to work, not just
some of it.
Chromium bug for context: http://crbug.com/518191
llvm-svn: 244922
There is currently no support in MSVC for using i128 as an integer
literal suffix. In fact, there appears to be no evidence that they have
ever supported this feature in any of their compilers. This was an over
generalization of their actual feature and is a nasty source of bugs.
Why is it a source of bugs? Because most code in clang expects that
evaluation of an integer constant expression won't give them something
that 'long long' can't represent. Instead of providing a meaningful
feature, i128 gives us cute ways of exploding the compiler.
llvm-svn: 243243
This patch adds initial support for the -fsanitize=kernel-address flag to Clang.
Right now it's quite restricted: only out-of-line instrumentation is supported, globals are not instrumented, some GCC kasan flags are not supported.
Using this patch I am able to build and boot the KASan tree with LLVMLinux patches from github.com/ramosian-glider/kasan/tree/kasan_llvmlinux.
To disable KASan instrumentation for a certain function attribute((no_sanitize("kernel-address"))) can be used.
llvm-svn: 240131
Summary:
This patch enables lexing of `concept` and `requires` as keywords.
Further changes which add messages for future keyword compat are to
follow.
Test Plan:
Testing of C++14 + Concepts TS mode is added to
`test/Lexer/keywords_test.cpp`, which expects that the new keywords are
enabled under said mode.
Reviewers: faisalv, fraggamuffin, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10233
llvm-svn: 239128
This applies the existing checks in has_feature_cxx0x to -std=c++1z.
In addition, references to C++1y are updated to refer to C++14
No functional change. Testing of __has_feature for C++1z features
is not added in this change.
Patch by Hubert Tong!
llvm-svn: 237992
in-progress implementation of the Concepts TS. The recommended feature
test macro __cpp_experimental_concepts is set to 1 (as opposed to
201501) to indicate that the feature is enabled, but the
implementation is incomplete.
The link to the Concepts TS in cxx_status is updated to refer to the
PDTS (N4377). Additional changes related to __has_feature and
__has_extension are to follow in a later change.
Relevant tests include:
test/Lexer/cxx-features.cpp
The test file is updated with testing of the C++14 + Concepts TS mode.
The expected behaviour is the same as that of the C++14 modes except
for the case of __cpp_experimental_concepts."
- Hubert Tong.
Being committed for Hubert (as per his understanding with Richard Smith) as we start work on the concepts-ts following our preliminary strategy session earlier today.
The patch is tiny and seems quite standard.
Thanks Hubert!
llvm-svn: 237982
Summary:
Fix PR22407, where the Lexer overflows the buffer when parsing
#include<\
(end of file after slash)
Test Plan:
Added a test that will trigger in asan build.
This case is also covered by the clang-fuzzer bot.
Reviewers: rnk
Reviewed By: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9489
llvm-svn: 236466
While dereferencing ThisTokEnd is fine and we know that it's not in
[a-zA-Z0-9_.], ThisTokEnd[1] is really past the end.
Found by asan and with a little help from clang-fuzz.
llvm-svn: 233491
There are no widely deployed standard libraries providing sized
deallocation functions, so we have to punt and ask the user if they want
us to use sized deallocation. In the future, when such libraries are
deployed, we can teach the driver to detect them and enable this
feature.
N3536 claimed that a weak thunk from sized to unsized deallocation could
be emitted to avoid breaking backwards compatibility with standard
libraries not providing sized deallocation. However, this approach and
other variations don't work in practice.
With the weak function approach, the thunk has to have default
visibility in order to ensure that it is overridden by other DSOs
providing sized deallocation. Weak, default visibility symbols are
particularly expensive on MachO, so John McCall was considering
disabling this feature by default on Darwin. It also changes behavior
ELF linking behavior, causing certain otherwise unreferenced object
files from an archive to be pulled into the link.
Our second approach was to use an extern_weak function declaration and
do an inline conditional branch at the deletion call site. This doesn't
work because extern_weak only works on MachO if you have some archive
providing the default value of the extern_weak symbol. Arranging to
provide such an archive has the same challenges as providing the symbol
in the standard library. Not to mention that extern_weak doesn't really
work on COFF.
Reviewers: rsmith, rjmccall
Differential Revision: http://reviews.llvm.org/D8467
llvm-svn: 232788
Currently -fms-extensions controls this behavior, which doesn't make
much sense. It means we can't identify what is and isn't a system header
when compiling our own preprocessed output, because #line doesn't
represent this information.
If someone is feeding Clang's preprocessed output to another compiler,
they can use this flag.
Fixes PR20553.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D5217
llvm-svn: 230587
-trigraphs is now an alias for -ftrigraphs. -fno-trigraphs makes it possible
to explicitly disable trigraphs, which couldn't be done before.
clang -std=c++11 -fno-trigraphs
now builds without GNU extensions, but with trigraphs disabled. Previously,
trigraphs were only disabled in GNU modes or with -std=c++1z.
Make the new -f flags the cc1 interface too. This requires changing -trigraphs
to -ftrigraphs in a few cc1 tests.
Related to PR21974.
llvm-svn: 224790
Clang should form a wide string literal from L#macro_arg in a function-like macro in -fms-compatibility mode.
Fix for http://llvm.org/PR9984.
Differential Revision: http://reviews.llvm.org/D6604
llvm-svn: 224228
We would check if the terminator marker is on a newline. However, the
logic would end up out-of-bounds if the terminator marker immediately
follows the start marker.
This fixes PR21820.
llvm-svn: 224210
'char' is unsigned on all ARM and Thumb architectures. Clang gets this
right for ARM, and for thumb when using and arm triple and the -mthumb
option, but gets it wrong for thumb triples. This fixes that.
llvm-svn: 220555
This is long-since overdue, and matches GCC 5.0. This should also be
backwards-compatible, because we already supported all of C11 as an extension
in C99 mode.
llvm-svn: 220244
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
Richard Smith