I should have done it in rL327558 / D43162, but forgot..
I'm not 100% sure about the text, but i don't think
it warrants a whole new differential revision.
llvm-svn: 327725
Summary:
--autocomplete flag now handles all the flags passed to shell, and this
implementation breaks backward compatibily before Clang 6.0.
Reviewers: teemperor, v.g.vassilev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D44191
llvm-svn: 326889
Add attribute target multiversioning to the release notes.
Additionally adds multiversioning support to the attribute
documentation for 'target'.
Differential Revision: https://reviews.llvm.org/D41837
llvm-svn: 322043
Most attributes will now use the Clang<"name"> construct to provide both __attribute__((name)) and [[clang::name]] syntaxes for the attribute. Attributes deviating from this should be marked with a comment explaining why they are not supported under both spellings. Common reasons are: the attribute is provided by some other specification that controls the syntax or the attribute cannot be exposed under a particular spelling for some given reason.
Because this is a mechanical change that only introduces new spellings, there are no test cases for the commit.
llvm-svn: 320752
builtin macros
This patch implements the __is_target_arch, __is_target_vendor, __is_target_os,
and __is_target_environment Clang preprocessor extensions that were proposed by
@compnerd in Bob's cfe-dev post:
http://lists.llvm.org/pipermail/cfe-dev/2017-November/056166.html.
These macros can be used to examine the components of the target triple at
compile time. A has_builtin(is_target_???) preprocessor check can be used to
check for their availability.
__is_target_arch allows you to check if an arch is specified without worring
about a specific subarch, e.g.
__is_target_arch(arm) returns 1 for the target arch "armv7"
__is_target_arch(armv7) returns 1 for the target arch "armv7"
__is_target_arch(armv6) returns 0 for the target arch "armv7"
__is_target_vendor and __is_target_environment match the specific vendor
or environment. __is_target_os matches the specific OS, but
__is_target_os(darwin) will match any Darwin-based OS. "Unknown" can be used
to test if the triple's component is specified.
rdar://35753116
Differential Revision: https://reviews.llvm.org/D41087
llvm-svn: 320734
This adds -std=c17, -std=gnu17, and -std=iso9899:2017 as language mode flags for C17 and updates the value of __STDC_VERSION__ to the value based on the C17 FDIS. Given that this ballot cannot succeed until 2018, it is expected that we (and GCC) will add c18 flags as aliases once the ballot passes.
llvm-svn: 320089
This behaves similar to the __has_cpp_attribute builtin macro in that it allows users to detect whether an attribute is supported with the [[]] spelling syntax, which can be enabled in C with -fdouble-square-bracket-attributes.
llvm-svn: 320088
Basically a regression after r316268.
However the diagnostic is correct, but the test coverage is bad.
So just like rL316500, introduce yet more tests,
and adjust the release notes.
See https://bugs.llvm.org/show_bug.cgi?id=35200
llvm-svn: 317421
clang currently uses .init_array instead of .ctors on Linux if it detects gcc
4.7+. Make it so that it also uses .init_array if no gcc installation is found
at all – if there's no old gcc, there's nothing we need to be compatible with.
icecc for example runs clang in a very small chroot, so before this change
clang would use .ctors if run under icecc. And lld currently silently mislinks
inputs with .ctors sections, so before this clang + icecc + lld would produce
broken binaries. (But this seems like a good change independent of that lld
bug.)
https://reviews.llvm.org/D39317
llvm-svn: 316713
Summary:
The warning was initially introduced in D32914 by @thakis,
and the concerns were raised there, and later in rL302247
and PR33771.
I do believe that it makes sense to relax the diagnostic
e.g. in this case, when the expression originates from the
system header, which can not be modified. This prevents
adoption for the diagnostic for codebases which use pthreads
(`PTHREAD_MUTEX_INITIALIZER`), gtest, etc.
As @malcolm.parsons suggests, it *may* make sense to also
not warn for the template types, but it is not obvious to
me how to do that in here.
Though, it still makes sense to complain about `NULL` macro.
While there, add more tests.
Reviewers: dblaikie, thakis, rsmith, rjmccall, aaron.ballman
Reviewed By: thakis
Subscribers: Rakete1111, hans, cfe-commits, thakis, malcolm.parsons
Tags: #clang
Differential Revision: https://reviews.llvm.org/D38954
llvm-svn: 316662
rL316268 / D39122 has fixed PR35009, and now when in C,
these three(?) diagnostics properly use the enum's underlying
datatype.
While it was fixed, the test coverage was clearly insufficient,
because the -Wsign-compare change didn't show up in any of the
tests, until it was reported in the post-commit mail for rL316268.
So add the test for the -Wsign-compare diagnostic for enum
for C code, and while there, document this in the release notes.
The fix itself was obviously correct, so unless we want to silence
this new diagnosed case, i deem this commit to be NFC.
llvm-svn: 316500
The first attempt, rL315614 was reverted because one libcxx
test broke, and i did not know at the time how to deal with it.
Summary:
Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`),
and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the
`std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak
Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147
Continuation of https://reviews.llvm.org/D37565
Reviewers: rjmccall, rsmith, aaron.ballman
Reviewed By: rsmith
Subscribers: rtrieu, jroelofs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D38101
llvm-svn: 315875
Summary:
Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`),
and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the
`std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak
Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147
Continuation of https://reviews.llvm.org/D37565
Reviewers: rjmccall, rsmith, aaron.ballman
Reviewed By: rsmith
Subscribers: rtrieu, jroelofs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D38101
llvm-svn: 315614
Summary:
This raises our default past 1900, which controls whether char16_t is a
builtin type or not.
Implements PR34243
Reviewers: hans
Subscribers: STL_MSFT, rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D38646
llvm-svn: 315107
Summary:
This is a first half(?) of a fix for the following bug:
https://bugs.llvm.org/show_bug.cgi?id=34147 (gcc -Wtype-limits)
GCC's -Wtype-limits does warn on comparison of unsigned value
with signed zero (as in, with 0), but clang only warns if the
zero is unsigned (i.e. 0U).
Also, be careful not to double-warn, or falsely warn on
comparison of signed/fp variable and signed 0.
Yes, all these testcases are needed.
Testing: $ ninja check-clang-sema check-clang-semacxx
Also, no new warnings for clang stage-2 build.
Reviewers: rjmccall, rsmith, aaron.ballman
Reviewed By: rjmccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D37565
llvm-svn: 312750
-Wobjc-messaging-id is a new, non-default warning that warns about
message sends to unqualified id in Objective-C. This warning is useful
for projects that would like to avoid any potential future compiler
errors/warnings, as the system frameworks might add a method with the same
selector which could make the message send to id ambiguous.
rdar://33303354
llvm-svn: 311779
Summary:
I thought we should add this information to release notes, because we
added a new flag to clang driver.
Reviewers: v.g.vassilev, teemperor, ruiu
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D36567
llvm-svn: 310700
In r309007, I made -fsanitize=null a hard prerequisite for -fsanitize=vptr. I
did not see the need for the two checks to have separate null checking logic
for the same pointer. I expected the two checks to either always be enabled
together, or to be mutually compatible.
In the mailing list discussion re: r309007 it became clear that that isn't the
case. If a codebase is -fsanitize=vptr clean but not -fsanitize=null clean,
it's useful to have -fsanitize=vptr emit its own null check. That's what this
patch does: with it, -fsanitize=vptr can be used without -fsanitize=null.
Differential Revision: https://reviews.llvm.org/D36112
llvm-svn: 309846
Originally, we weren't able to match on Type nodes themselves (only QualType),
so the hasDeclaration matcher was initially written to give what we thought are
reasonable results for QualType matches.
When we chagned the matchers to allow matching on Type nodes, it turned out
that the hasDeclaration matcher was by chance written templated enough to now
allow hasDeclaration to also match on (some) Type nodes.
This patch change the hasDeclaration matcher to:
a) work the same on Type and QualType nodes,
b) be completely explicit about what nodes we can match instead of just allowing
anything with a getDecl() to match,
c) explicitly control desugaring only one level in very specific instances.
d) adds hasSpecializedTemplate and tagType matchers to allow migrating
existing use cases that now need more explicit matchers
Note: This patch breaks clang-tools-extra. The corresponding patch there
is approved and will land in a subsequent patch.
Differential Revision: https://reviews.llvm.org/D27104
llvm-svn: 309809
The instrumentation generated by -fsanitize=vptr does not null check a
user pointer before loading from it. This causes crashes in the face of
UB member calls (this=nullptr), i.e it's causing user programs to crash
only after UBSan is turned on.
The fix is to make run-time null checking a prerequisite for enabling
-fsanitize=vptr, and to then teach UBSan to reuse these run-time null
checks to make -fsanitize=vptr safe.
Testing: check-clang, check-ubsan, a stage2 ubsan-enabled build
Differential Revision: https://reviews.llvm.org/D35735https://bugs.llvm.org/show_bug.cgi?id=33881
llvm-svn: 309007
Summary:
This way, the behavior of that warning flag
more closely resembles that of GCC.
Do note that there is at least one false-negative (see FIXME in tests).
Fixes PR4802.
Testing:
```
ninja check-clang-sema check-clang-semacxx
```
Reviewers: dblaikie, majnemer, rnk
Reviewed By: dblaikie, rnk
Subscribers: mclow.lists, cfe-commits, alexfh, rnk
Differential Revision: https://reviews.llvm.org/D33102
llvm-svn: 307045
-fslp-vectorize-aggressive and -fno-slp-vectorize-aggressive flags back
under this group and test for the warning. Document the future removal
in the ReleaseNotes.
Differential Revision: https://reviews.llvm.org/D34926
llvm-svn: 306965
Summary:
This way, the behavior of that warning flag
more closely resembles that of GCC.
Do note that there is at least one false-negative (see FIXME in tests).
Fixes PR4802.
Testing:
```
ninja check-clang-sema check-clang-semacxx
```
Reviewers: dblaikie, majnemer, rnk
Reviewed By: dblaikie, rnk
Subscribers: cfe-commits, alexfh, rnk
Differential Revision: https://reviews.llvm.org/D33102
llvm-svn: 305147
Roman Lebedev