Differential Revision: https://reviews.llvm.org/D42360


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_60@323132 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_60@323066 91177308-0d34-0410-b5e6-96231b3b80d8

Differential Revision: https://reviews.llvm.org/D41711

git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_60@321788 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321561 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320752 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320734 91177308-0d34-0410-b5e6-96231b3b80d8

This is C++14 with conforming GNU extensions.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320250 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320089 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320088 91177308-0d34-0410-b5e6-96231b3b80d8

[clang-format] Releasenotes for rL319024 : Add option to group multiple #include blocks when sorting includes

Summary:
This change adds missing releasenotes for commit rL319024
https://reviews.llvm.org/rL319024

Patch by Krzysztof Kapusta

Reviewers: sylvestre.ledru

Reviewed By: sylvestre.ledru

Differential Revision: https://reviews.llvm.org/D40827

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319748 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Currently clang static analyzer does warn on:
```
int x;
x+=1;
x-=1;
x=x+1;
x=x-1;
```
But does warn on:
```
int x;
x++;
x--;
--x;
++x;
```

This differential should fix that.
Fixes https://bugs.llvm.org/show_bug.cgi?id=35419

Reviewers: dcoughlin, NoQ

Reviewed By: dcoughlin

Subscribers: NoQ, xazax.hun, szepet, cfe-commits, a.sidorin

Tags: #clang

Differential Revision: https://reviews.llvm.org/D40463

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319411 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@317421 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316713 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316662 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316500 91177308-0d34-0410-b5e6-96231b3b80d8

Add release notes for the recent -fdouble-square-bracket-attributes and -fno-double-square-bracket-attributes compiler flags.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316269 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315875 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts r315614,r315615,r315621,r315622
Breaks http://bb9.pgr.jp/#/builders/20/builds/59

/home/bb9/bootstrap-clang-libcxx-lld-i686-linux/llvm-project/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp:95:17: error: comparison 'long long' > 9223372036854775807 is always false [-Werror,-Wtautological-constant-compare]
    if (max_sec > Lim::max()) return false;
        ~~~~~~~ ^ ~~~~~~~~~~
/home/bb9/bootstrap-clang-libcxx-lld-i686-linux/llvm-project/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp:124:13: error: comparison 'long long' < -9223372036854775808 is always false [-Werror,-Wtautological-constant-compare]
    if (sec < Lim::min() || sec > Lim::max())   return false;
        ~~~ ^ ~~~~~~~~~~
/home/bb9/bootstrap-clang-libcxx-lld-i686-linux/llvm-project/libcxx/test/std/experimental/filesystem/fs.op.funcs/fs.op.last_write_time/last_write_time.pass.cpp:124:33: error: comparison 'long long' > 9223372036854775807 is always false [-Werror,-Wtautological-constant-compare]
    if (sec < Lim::min() || sec > Lim::max())   return false;
                            ~~~ ^ ~~~~~~~~~~
3 errors generated.
--

I'm not yet sure what is the proper fix.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315631 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315614 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315107 91177308-0d34-0410-b5e6-96231b3b80d8

Differential Revision: https://reviews.llvm.org/D38186



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314387 91177308-0d34-0410-b5e6-96231b3b80d8

Differential Revision: https://reviews.llvm.org/D37647

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312957 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312750 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312535 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@312149 91177308-0d34-0410-b5e6-96231b3b80d8

-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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@311779 91177308-0d34-0410-b5e6-96231b3b80d8

Reviewers: djasper

Reviewed By: djasper

Subscribers: klimek, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D34824

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@310778 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@310700 91177308-0d34-0410-b5e6-96231b3b80d8

Fixes PR33796, rdar://33655115

Differential revision: https://reviews.llvm.org/D36191

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@310382 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@309846 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@309809 91177308-0d34-0410-b5e6-96231b3b80d8

The additions in r309562 triggered a docs buildbot failure.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@309564 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@309562 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@309145 91177308-0d34-0410-b5e6-96231b3b80d8

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/D35735

https://bugs.llvm.org/show_bug.cgi?id=33881

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@309007 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@308478 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@307995 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@307045 91177308-0d34-0410-b5e6-96231b3b80d8

-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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@306965 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@305269 91177308-0d34-0410-b5e6-96231b3b80d8