[PATCH] D34588: Check for _MSC_VER before define _LIBCPP_MSVCRT

[Ben Craig via Phabricator via cfe-commits]

bcraig added inline comments.



Comment at: include/__config:234-235
+// a MS compatibility version is specified.
 #  ifndef __MINGW32__
-#define _LIBCPP_MSVCRT // Using Microsoft's C Runtime library
+#ifdef _MSC_VER
+#  define _LIBCPP_MSVCRT // Using Microsoft's C Runtime library

majnemer wrote:
> compnerd wrote:
> > smeenai wrote:
> > > You can combine this into just
> > > 
> > > ```
> > > #  if defined(_MSC_VER) && !defined(__MINGW32__)
> > > ```
> > > 
> > > I don't know if `__MINGW32__` and `_MSC_VER` will ever be compiled 
> > > simultaneously. (clang never defines `_MSC_VER` for its MinGW triples, 
> > > for example.)
> > What if MinGW is built with clang/c2 and MSVC extensions?  I think that the 
> > two could be defined together.  What about cygwin and clang/c2?  I guess we 
> > can ignore that since cygwin is not under active development.
> > 
> > I think this really goes back to my idea for an additional flag to indicate 
> > the C library in use.  We can interpret it from the canonicalized triple 
> > that LLVM/clang use.
> clang/c2 is dead.
At some point, I would like to see (or will need to introduce) a flag for which 
Windows C library is in use (so I'm agreeing with / echoing @compnerd).  What 
all options are there right now?  There's the Visual Studio C-runtime (multiple 
versions), there's msvcrt (used by the OS and mingw), there's the ancient 
crtdll that we shouldn't ever support, and there's the kernel C runtime (I'm 
probably the only person that cares about that).

I will note that I don't like the name of the macro here.  _LIBCPP_MSVCRT 
implies that msvcrt.dll is being used, when it isn't.  I don't think that this 
patch needs to fix that naming though.


https://reviews.llvm.org/D34588



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D34523: AST: mangle BlockDecls under MS ABI

[David Majnemer via Phabricator via cfe-commits]

majnemer added inline comments.



Comment at: lib/AST/MicrosoftMangle.cpp:985
+
+  Out << '?' << Discriminate("_block_invoke", Discriminator) << '@';
+  if (const auto *RD = dyn_cast(DC))

Should this be `Out << '?' << mangleSourceName(Discriminate("_block_invoke", 
Discriminator));`



Comment at: lib/AST/MicrosoftMangle.cpp:990-994
+  Out << "YAX";
+  Out << "PA";
+  mangleArtificalTagType(TTK_Struct,
+ Discriminate("__block_literal", Discriminator));
+  Out << "@Z";

You should probably add comments explaining these bits.


Repository:
  rL LLVM

https://reviews.llvm.org/D34523



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D34588: Check for _MSC_VER before define _LIBCPP_MSVCRT

[David Majnemer via Phabricator via cfe-commits]

majnemer added inline comments.



Comment at: include/__config:234-235
+// a MS compatibility version is specified.
 #  ifndef __MINGW32__
-#define _LIBCPP_MSVCRT // Using Microsoft's C Runtime library
+#ifdef _MSC_VER
+#  define _LIBCPP_MSVCRT // Using Microsoft's C Runtime library

compnerd wrote:
> smeenai wrote:
> > You can combine this into just
> > 
> > ```
> > #  if defined(_MSC_VER) && !defined(__MINGW32__)
> > ```
> > 
> > I don't know if `__MINGW32__` and `_MSC_VER` will ever be compiled 
> > simultaneously. (clang never defines `_MSC_VER` for its MinGW triples, for 
> > example.)
> What if MinGW is built with clang/c2 and MSVC extensions?  I think that the 
> two could be defined together.  What about cygwin and clang/c2?  I guess we 
> can ignore that since cygwin is not under active development.
> 
> I think this really goes back to my idea for an additional flag to indicate 
> the C library in use.  We can interpret it from the canonicalized triple that 
> LLVM/clang use.
clang/c2 is dead.


https://reviews.llvm.org/D34588



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D34588: Check for _MSC_VER before define _LIBCPP_MSVCRT

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd added inline comments.



Comment at: include/__config:234-235
+// a MS compatibility version is specified.
 #  ifndef __MINGW32__
-#define _LIBCPP_MSVCRT // Using Microsoft's C Runtime library
+#ifdef _MSC_VER
+#  define _LIBCPP_MSVCRT // Using Microsoft's C Runtime library

smeenai wrote:
> You can combine this into just
> 
> ```
> #  if defined(_MSC_VER) && !defined(__MINGW32__)
> ```
> 
> I don't know if `__MINGW32__` and `_MSC_VER` will ever be compiled 
> simultaneously. (clang never defines `_MSC_VER` for its MinGW triples, for 
> example.)
What if MinGW is built with clang/c2 and MSVC extensions?  I think that the two 
could be defined together.  What about cygwin and clang/c2?  I guess we can 
ignore that since cygwin is not under active development.

I think this really goes back to my idea for an additional flag to indicate the 
C library in use.  We can interpret it from the canonicalized triple that 
LLVM/clang use.


https://reviews.llvm.org/D34588



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33816: [Sema][ObjC] Don't allow -Wunguarded-availability to be silenced with redeclarations

[Erik Pilkington via Phabricator via cfe-commits]

erik.pilkington updated this revision to Diff 103852.
erik.pilkington added a comment.

Improve enum diagnostics, as @arphaman suggested. This causes a bit of churn 
throughout the availability diagnostic machinery, if it would make it at all 
easier to review, I would be happy to separate out these changes.
Thanks,
Erik


https://reviews.llvm.org/D33816

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/DelayedDiagnostic.h
  include/clang/Sema/Sema.h
  lib/Sema/DelayedDiagnostic.cpp
  lib/Sema/SemaDeclAttr.cpp
  lib/Sema/SemaExpr.cpp
  test/Sema/attr-availability.c
  test/Sema/attr-deprecated.c
  test/Sema/attr-unavailable-message.c
  test/SemaCXX/attr-deprecated.cpp
  test/SemaObjC/attr-availability.m
  test/SemaObjC/unguarded-availability-new.m
  test/SemaObjC/unguarded-availability.m

Index: test/SemaObjC/unguarded-availability.m
===
--- test/SemaObjC/unguarded-availability.m
+++ test/SemaObjC/unguarded-availability.m
@@ -5,6 +5,8 @@
 #define AVAILABLE_10_11 __attribute__((availability(macos, introduced = 10.11)))
 #define AVAILABLE_10_12 __attribute__((availability(macos, introduced = 10.12)))
 
+typedef int AVAILABLE_10_12 new_int; // expected-note + {{marked partial here}}
+
 int func_10_11() AVAILABLE_10_11; // expected-note 4 {{'func_10_11' has been explicitly marked partial here}}
 
 #ifdef OBJCPP
@@ -70,9 +72,9 @@
 }
 
 __attribute__((objc_root_class))
-AVAILABLE_10_11 @interface Class_10_11 {
+AVAILABLE_10_11 @interface Class_10_11 { // expected-note{{annotate 'Class_10_11' with an availability attribute to silence}}
   int_10_11 foo;
-  int_10_12 bar; // expected-warning {{'int_10_12' is partial: introduced in macOS 10.12}} expected-note{{redeclare}}
+  int_10_12 bar; // expected-warning {{'int_10_12' is partial: introduced in macOS 10.12}}
 }
 - (void)method1;
 - (void)method2;
@@ -125,7 +127,7 @@
   };
 }
 
-void test_params(int_10_12 x); // expected-warning {{'int_10_12' is partial: introduced in macOS 10.12}} expected-note{{redeclare}}
+void test_params(int_10_12 x); // expected-warning {{'int_10_12' is partial: introduced in macOS 10.12}} expected-note{{annotate 'test_params' with an availability attribute to silence}}
 
 void test_params2(int_10_12 x) AVAILABLE_10_12; // no warn
 
@@ -234,3 +236,23 @@
 }
 
 #endif
+
+struct InStruct { // expected-note{{annotate 'InStruct' with an availability attribute to silence}}
+  new_int mem; // expected-warning{{'new_int' is partial}}
+
+  struct { new_int mem; } anon; // expected-warning{{'new_int' is partial}} expected-note{{annotate '' with an availability attribute}}
+};
+
+@interface InInterface
+-(new_int)meth; // expected-warning{{'new_int' is partial}} expected-note{{annotate 'meth' with an availability attribute}}
+@end
+
+@interface Proper // expected-note{{annotate 'Proper' with an availability attribute}}
+@property (class) new_int x; // expected-warning{{'new_int' is partial}}
+@end
+
+void with_local_struct() {
+  struct local { // expected-note{{annotate 'local' with an availability attribute}}
+new_int x; // expected-warning{{'new_int' is partial}}
+  };
+}
Index: test/SemaObjC/unguarded-availability-new.m
===
--- test/SemaObjC/unguarded-availability-new.m
+++ test/SemaObjC/unguarded-availability-new.m
@@ -96,16 +96,16 @@
 FUNC_AVAILABLE new_int x;
 #ifndef NO_WARNING
 #ifdef MAC
-  // expected-warning@-3 {{'new_int' is partial: introduced in macOS 10.14}} expected-note@-3 {{explicitly redeclare 'new_int' to silence this warning}}
+  // expected-warning@-3 {{'new_int' is partial: introduced in macOS 10.14}} expected-note@-3 {{annotate 'new_int'}}
 #endif
 #ifdef IOS
-  // expected-warning@-6 {{'new_int' is partial: introduced in iOS 12}} expected-note@-6 {{explicitly redeclare 'new_int' to silence this warning}}
+  // expected-warning@-6 {{'new_int' is partial: introduced in iOS 12}} expected-note@-6 {{annotate 'new_int'}}
 #endif
 #ifdef TVOS
-  // expected-warning@-9 {{'new_int' is partial: introduced in tvOS 13}} expected-note@-9 {{explicitly redeclare 'new_int' to silence this warning}}
+  // expected-warning@-9 {{'new_int' is partial: introduced in tvOS 13}} expected-note@-9 {{annotate 'new_int'}}
 #endif
 #ifdef WATCHOS
-  // expected-warning@-12 {{'new_int' is partial: introduced in watchOS 5}} expected-note@-12 {{explicitly redeclare 'new_int' to silence this warning}}
+  // expected-warning@-12 {{'new_int' is partial: introduced in watchOS 5}} expected-note@-12 {{annotate 'new_int'}}
 #endif
 #endif
 
Index: test/SemaObjC/attr-availability.m
===
--- test/SemaObjC/attr-availability.m
+++ test/SemaObjC/attr-availability.m
@@ -13,7 +13,7 @@
 @interface A 
 - (void)method __attribute__((availability(macosx,introduced=10.1,deprecated=10.2))); // expected-note {{'method' has been explicitly marked deprecated 

Buildbot is back to normal work

[Galina Kistanova via cfe-commits]

Hello everyone,

Buildbot master is back to usual work after transitional.
Please pay attention to errors.

Thanks

Galina
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] r303735 - Modify test so that it looks for patterns in stderr as well

[David Blaikie via cfe-commits]

On Sat, Jun 24, 2017 at 10:08 AM Serge Pavlov  wrote:

> With CMAKE_EXPORT_COMPILE_COMMANDS the file compile_commands.json is
> created in the directory
> /tools/clang/tools/extra/test/clang-tidy/Output,
>

I'd be really surprised if this is the case - why would
cmake/ninja/makefiles put the compile commands for the whole LLVM
project/build in that somewhat random subdirectory?


> but the tests from /llvm/tools/clang/tools/extra/test/clang-tidy
> run in the directory /tools/clang/tools/extra/test/clang-tidy,
> which does not contain json files. So the test passes successfully. Ubuntu
> 16.04, cmake 3.5.1.
>

Ah, perhaps you found a compile_commands for one of the test cases, not the
one generated by CMake. CMake 3.5.1 doesn't support
CMAKE_EXPORT_COMPILE_COMMANDS.

It was added in 3.5.2, according to the documentation:
https://cmake.org/cmake/help/v3.5/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html


>
> Thanks,
> --Serge
>
> 2017-06-24 9:42 GMT+07:00 David Blaikie :
>
>> Ping (+Manuel, perhaps he's got some ideas about this, given background
>> in the tooling & compilation database work, or could point this to someone
>> who does?)
>>
>>
>> On Thu, Jun 15, 2017 at 10:40 AM David Blaikie 
>> wrote:
>>
>>> https://sarcasm.github.io/notes/dev/compilation-database.html#cmake
>>>
>>> If you enable the CMAKE_EXPORT_COMPILE_COMMANDS option in cmake (& have
>>> a sufficiently recent cmake), then CMake will generate a
>>> compile_commands.json in the root of the build tree. The test finds this &
>>> fails, instead of finding no compilation database & succeeding.
>>>
>>> (to use this, you can then symlink from the root of the source tree to
>>> point to this in your build tree - this is how I get YCM to work for my
>>> LLVM builds & could work for other clang tools as well)
>>>
>>> On Thu, Jun 15, 2017 at 7:51 AM Serge Pavlov 
>>> wrote:
>>>
 2017-06-15 2:43 GMT+07:00 David Blaikie :

>
>
> On Wed, Jun 14, 2017, 8:17 AM Serge Pavlov 
> wrote:
>
>> 2017-06-14 4:24 GMT+07:00 David Blaikie :
>>
>>> Ah, I find that the test passes if I remove the
>>> compile_commands.json file from my build directory (I have Ninja 
>>> configured
>>> to generate a compile_commands.json file).
>>>
>>> Looks like what happens is it finds the compilation database and
>>> fails hard when the database doesn't contain a compile command for the 
>>> file
>>> in question. If the database is not found, it falls back to some basic
>>> command behavior, perhaps?
>>>
>>>
>> You are right, constructor of `CommonOptionsParser` calls
>> `autoDetectFromSource` or `autoDetectFromDirectory` prior to final
>> construction of `FixedCompilationDatabase.
>>
>> Is there some way this test could be fixed to cope with this,
>>> otherwise it seems to get in the way of people actually using clang 
>>> tools
>>> in their LLVM/Clang build environment?
>>>
>>>
>> IIUC, presence of stale compilation database file in test directory
>> could break many tests. I don't understand why only diagnostic.cpp fails,
>> probably there is something wrong with the clang-tidy application cleanup
>> in this case?
>>
>
> Except it's neither stale nor in the test directory.
>
> It's the up to date/useful/used compile_commands.json generated by
> ninja in the root of the build tree.
>

 I miss something. If I could reproduce the problem, I would investigate
 it.


>
>
>>
>>> On Tue, Jun 13, 2017 at 7:41 AM Serge Pavlov 
>>> wrote:
>>>
 I cannot reproduce such fail, so I can only guess how changes made
 in https://reviews.llvm.org/rL303756 and
 https://reviews.llvm.org/rL303741 could cause such problem.
 Behavior of `Driver::BuildCompilation` is changed so that it returns 
 null
 pointer if errors occur during driver argument parse. It is called in
 `CompilationDatabase.cpp` from `stripPositionalArgs`. The call stack at
 this point is:
 stripPositionalArgs
 clang::tooling::FixedCompilationDatabase::loadFromCommandLine
 clang::tooling::CommonOptionsParser::CommonOptionsParser
 clang::tidy::clangTidyMain
 main
 `FixedCompilationDatabase::loadFromCommandLine` returns null and
 CommonOptionsParser uses another method to create compilation 
 database. The
 output "Compile command not found" means that no input file were found 
 in
 `ClangTool::run`. Maybe some file names are nulls?


 Thanks,
 --Serge

 2017-06-13 3:42 GMT+07:00 David Blaikie :

> I've been seeing errors from this test 

Re: [clang-tools-extra] r303735 - Modify test so that it looks for patterns in stderr as well

[Serge Pavlov via cfe-commits]

With CMAKE_EXPORT_COMPILE_COMMANDS the file compile_commands.json is
created in the directory
/tools/clang/tools/extra/test/clang-tidy/Output, but the tests
from /llvm/tools/clang/tools/extra/test/clang-tidy run in the
directory /tools/clang/tools/extra/test/clang-tidy, which does
not contain json files. So the test passes successfully. Ubuntu 16.04,
cmake 3.5.1.

Thanks,
--Serge

2017-06-24 9:42 GMT+07:00 David Blaikie :

> Ping (+Manuel, perhaps he's got some ideas about this, given background in
> the tooling & compilation database work, or could point this to someone who
> does?)
>
>
> On Thu, Jun 15, 2017 at 10:40 AM David Blaikie  wrote:
>
>> https://sarcasm.github.io/notes/dev/compilation-database.html#cmake
>>
>> If you enable the CMAKE_EXPORT_COMPILE_COMMANDS option in cmake (& have a
>> sufficiently recent cmake), then CMake will generate a
>> compile_commands.json in the root of the build tree. The test finds this &
>> fails, instead of finding no compilation database & succeeding.
>>
>> (to use this, you can then symlink from the root of the source tree to
>> point to this in your build tree - this is how I get YCM to work for my
>> LLVM builds & could work for other clang tools as well)
>>
>> On Thu, Jun 15, 2017 at 7:51 AM Serge Pavlov  wrote:
>>
>>> 2017-06-15 2:43 GMT+07:00 David Blaikie :
>>>


 On Wed, Jun 14, 2017, 8:17 AM Serge Pavlov  wrote:

> 2017-06-14 4:24 GMT+07:00 David Blaikie :
>
>> Ah, I find that the test passes if I remove the compile_commands.json
>> file from my build directory (I have Ninja configured to generate a
>> compile_commands.json file).
>>
>> Looks like what happens is it finds the compilation database and
>> fails hard when the database doesn't contain a compile command for the 
>> file
>> in question. If the database is not found, it falls back to some basic
>> command behavior, perhaps?
>>
>>
> You are right, constructor of `CommonOptionsParser` calls
> `autoDetectFromSource` or `autoDetectFromDirectory` prior to final
> construction of `FixedCompilationDatabase.
>
> Is there some way this test could be fixed to cope with this,
>> otherwise it seems to get in the way of people actually using clang tools
>> in their LLVM/Clang build environment?
>>
>>
> IIUC, presence of stale compilation database file in test directory
> could break many tests. I don't understand why only diagnostic.cpp fails,
> probably there is something wrong with the clang-tidy application cleanup
> in this case?
>

 Except it's neither stale nor in the test directory.

 It's the up to date/useful/used compile_commands.json generated by
 ninja in the root of the build tree.

>>>
>>> I miss something. If I could reproduce the problem, I would investigate
>>> it.
>>>
>>>


>
>> On Tue, Jun 13, 2017 at 7:41 AM Serge Pavlov 
>> wrote:
>>
>>> I cannot reproduce such fail, so I can only guess how changes made
>>> in https://reviews.llvm.org/rL303756 and https://reviews.llvm.org/
>>> rL303741 could cause such problem. Behavior of
>>> `Driver::BuildCompilation` is changed so that it returns null pointer if
>>> errors occur during driver argument parse. It is called in
>>> `CompilationDatabase.cpp` from `stripPositionalArgs`. The call stack at
>>> this point is:
>>> stripPositionalArgs
>>> clang::tooling::FixedCompilationDatabase::loadFromCommandLine
>>> clang::tooling::CommonOptionsParser::CommonOptionsParser
>>> clang::tidy::clangTidyMain
>>> main
>>> `FixedCompilationDatabase::loadFromCommandLine` returns null and
>>> CommonOptionsParser uses another method to create compilation database. 
>>> The
>>> output "Compile command not found" means that no input file were found 
>>> in
>>> `ClangTool::run`. Maybe some file names are nulls?
>>>
>>>
>>> Thanks,
>>> --Serge
>>>
>>> 2017-06-13 3:42 GMT+07:00 David Blaikie :
>>>
 I've been seeing errors from this test recently:

 Command Output (stderr):
 --
 1 error generated.
 Error while processing /usr/local/google/home/
 blaikie/dev/llvm/src/tools/clang/tools/extra/test/clang-
 tidy/diagnostic.cpp.nonexistent.cpp.
 /usr/local/google/home/blaikie/dev/llvm/src/tools/
 clang/tools/extra/test/clang-tidy/diagnostic.cpp:10:12: error:
 expected string not found in input
 // CHECK2: :[[@LINE+2]]:9: warning: implicit conversion from
 'double' to 'int' changes value from 1.5 to 1 
 [clang-diagnostic-literal-
 conversion]
^
 :2:1: note: scanning from here
 Skipping 

[PATCH] D33470: [clang-tidy] Add misc-default-numerics

[Piotr Padlewski via Phabricator via cfe-commits]

Prazek added a comment.

In https://reviews.llvm.org/D33470#764846, @aaron.ballman wrote:

> Once you fix the typo in the check, can you run it over some large C++ code 
> bases to see if it finds any results?


I tried it on LLVM code base (after fixing bug with the numeric_limits name) 
and it didn't find anything suspisious.
Unfortunatelly I don't have enough time to try it on different codebases, but I 
am weiling to fix any bug with this check if it would happen in the future.
The release 5.0 is near, so I would like to push it upstream. Does it sound 
good to you?


https://reviews.llvm.org/D33470



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33470: [clang-tidy] Add misc-default-numerics

[Piotr Padlewski via Phabricator via cfe-commits]

Prazek updated this revision to Diff 103837.
Prazek marked 4 inline comments as done.
Prazek added a comment.

- fixed docs
- fixes


https://reviews.llvm.org/D33470

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/DefaultNumericsCheck.cpp
  clang-tidy/misc/DefaultNumericsCheck.h
  clang-tidy/misc/MiscTidyModule.cpp
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-default-numerics.rst
  test/clang-tidy/misc-default-numerics.cpp

Index: test/clang-tidy/misc-default-numerics.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-default-numerics.cpp
@@ -0,0 +1,42 @@
+// RUN: %check_clang_tidy %s misc-default-numerics %t
+
+namespace std {
+
+template 
+struct numeric_limits {
+  static T min() { return T(); }
+  static T max() { return T(); }
+};
+
+template <>
+struct numeric_limits {
+  static int min() { return -1; }
+  static int max() { return 1; }
+};
+
+} // namespace std
+
+class MyType {};
+template 
+class MyTemplate {};
+
+void test() {
+  auto x = std::numeric_limits::min();
+
+  auto y = std::numeric_limits::min();
+  // CHECK-MESSAGES: [[@LINE-1]]:12: warning: 'std::numeric_limits::min' called with type 'MyType'; no such specialization exists, so the default value for that type is returned
+
+  auto z = std::numeric_limits::max();
+  // CHECK-MESSAGES: [[@LINE-1]]:12: warning: 'std::numeric_limits::max' called with type 'MyTemplate';
+}
+
+template 
+void fun() {
+  auto x = std::numeric_limits::min();
+}
+
+void testTemplate() {
+  fun();
+  // FIXME: This should generate warning with backtrace.
+  fun;
+}
Index: docs/clang-tidy/checks/misc-default-numerics.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/misc-default-numerics.rst
@@ -0,0 +1,23 @@
+.. title:: clang-tidy - misc-default-numerics
+
+misc-default-numerics
+=
+
+This check flags usages of ``std::numeric_limits::{min,max}()`` for
+unspecialized types. It is dangerous because the calls return ``T()``
+in this case, which is unlikely to represent the minimum or maximum value for
+the type.
+
+Consider scenario:
+.. code-block:: c++
+
+  // 1. Have a:
+  typedef long long BigInt
+
+  // 2. Use
+  std::numeric_limits::min()
+
+  // 3. Replace the BigInt typedef with class implementing BigIntegers
+  class BigInt { ;;; };
+
+  // 4. Your code continues to compile, but the call to min() returns BigInt{}
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -75,6 +75,7 @@
misc-assert-side-effect
misc-bool-pointer-implicit-conversion
misc-dangling-handle
+   misc-default-numerics
misc-definitions-in-headers
misc-fold-init-type
misc-forward-declaration-namespace
Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -72,6 +72,10 @@
 
   Allow custom memory management functions to be considered as well.
 
+- New `misc-default-numerics
+  `_ check
+  Finds uses of ``std::numeric_limits`` for unspecialized types
+
 - New `misc-forwarding-reference-overload
   `_ check
 
Index: clang-tidy/misc/MiscTidyModule.cpp
===
--- clang-tidy/misc/MiscTidyModule.cpp
+++ clang-tidy/misc/MiscTidyModule.cpp
@@ -14,6 +14,7 @@
 #include "AssertSideEffectCheck.h"
 #include "BoolPointerImplicitConversionCheck.h"
 #include "DanglingHandleCheck.h"
+#include "DefaultNumericsCheck.h"
 #include "DefinitionsInHeadersCheck.h"
 #include "FoldInitTypeCheck.h"
 #include "ForwardDeclarationNamespaceCheck.h"
@@ -67,6 +68,7 @@
 CheckFactories.registerCheck("misc-argument-comment");
 CheckFactories.registerCheck(
 "misc-assert-side-effect");
+CheckFactories.registerCheck("misc-default-numerics");
 CheckFactories.registerCheck(
 "misc-forwarding-reference-overload");
 CheckFactories.registerCheck(
Index: clang-tidy/misc/DefaultNumericsCheck.h
===
--- /dev/null
+++ clang-tidy/misc/DefaultNumericsCheck.h
@@ -0,0 +1,37 @@
+//===--- DefaultNumericsCheck.h - clang-tidy-*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_DEFAULT_NUMERICS_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_MISC_DEFAULT_NUMERICS_H
+
+#include 

[PATCH] D34275: [analyzer] Re-implemente current virtual calls checker in a path-sensitive way

[wangxin via Phabricator via cfe-commits]

wangxindsb updated this revision to Diff 103832.
wangxindsb added a comment.

Add license to VirtualCallChecker.cpp


https://reviews.llvm.org/D34275

Files:
  lib/StaticAnalyzer/Checkers/VirtualCallChecker.cpp
  test/Analysis/virtualcall.cpp

Index: test/Analysis/virtualcall.cpp
===
--- test/Analysis/virtualcall.cpp
+++ test/Analysis/virtualcall.cpp
@@ -1,79 +1,49 @@
 // RUN: %clang_analyze_cc1 -analyzer-checker=optin.cplusplus.VirtualCall -analyzer-store region -verify -std=c++11 %s
-// RUN: %clang_analyze_cc1 -analyzer-checker=optin.cplusplus.VirtualCall -analyzer-store region -analyzer-config optin.cplusplus.VirtualCall:Interprocedural=true -DINTERPROCEDURAL=1 -verify -std=c++11 %s
-// RUN: %clang_analyze_cc1 -analyzer-checker=optin.cplusplus.VirtualCall -analyzer-store region -analyzer-config optin.cplusplus.VirtualCall:PureOnly=true -DPUREONLY=1 -verify -std=c++11 %s
 
-/* When INTERPROCEDURAL is set, we expect diagnostics in all functions reachable
-   from a constructor or destructor. If it is not set, we expect diagnostics
-   only in the constructor or destructor.
-
-   When PUREONLY is set, we expect diagnostics only for calls to pure virtual
-   functions not to non-pure virtual functions.
-*/
+// RUN: %clang_analyze_cc1 -analyzer-checker=optin.cplusplus.VirtualCall -analyzer-store region -analyzer-config optin.cplusplus.VirtualCall:PureOnly=true -DPUREONLY=1 -verify -std=c++11 %s
 
 class A {
 public:
   A();
   A(int i);
 
   ~A() {};
   
-  virtual int foo() = 0; // from Sema: expected-note {{'foo' declared here}}
-  virtual void bar() = 0;
+  virtual int foo(); // from Sema: expected-note {{'foo' declared here}}
+  virtual void bar();
   void f() {
 foo();
-#if INTERPROCEDURAL
-// expected-warning-re@-2 ^}}Call Path : foo <-- fCall to pure virtual function during construction has undefined behavior}}
-#endif
+// expected-warning:Call to virtual function during construction
   }
 };
 
 class B : public A {
 public:
   B() {
 foo();
-#if !PUREONLY
-#if INTERPROCEDURAL
-// expected-warning-re@-3 ^}}Call Path : fooCall to virtual function during construction will not dispatch to derived class}}
-#else
-// expected-warning-re@-5 ^}}Call to virtual function during construction will not dispatch to derived class}}
-#endif
-#endif
-
+// expected-warning:Call to virtual function during construction
   }
   ~B();
   
   virtual int foo();
   virtual void bar() { foo(); }
-#if INTERPROCEDURAL
-  // expected-warning-re@-2 ^}}Call Path : foo <-- barCall to virtual function during destruction will not dispatch to derived class}}
-#endif
+  // expected-warning:Call to virtual function during destruction
 };
 
 A::A() {
   f();
 }
 
 A::A(int i) {
   foo(); // From Sema: expected-warning {{call to pure virtual member function 'foo' has undefined behavior}}
-#if INTERPROCEDURAL
-  // expected-warning-re@-2 ^}}Call Path : fooCall to pure virtual function during construction has undefined behavior}}
-#else
-  // expected-warning-re@-4 ^}}Call to pure virtual function during construction has undefined behavior}}
-#endif
+  // expected-warning:Call to virtual function during construction
 }
 
 B::~B() {
   this->B::foo(); // no-warning
   this->B::bar();
   this->foo();
-#if !PUREONLY
-#if INTERPROCEDURAL
-  // expected-warning-re@-3 ^}}Call Path : fooCall to virtual function during destruction will not dispatch to derived class}}
-#else
-  // expected-warning-re@-5 ^}}Call to virtual function during destruction will not dispatch to derived class}}
-#endif
-#endif
-
+  // expected-warning:Call to virtual function during destruction
 }
 
 class C : public B {
@@ -87,13 +57,7 @@
 
 C::C() {
   f(foo());
-#if !PUREONLY
-#if INTERPROCEDURAL
-  // expected-warning-re@-3 ^}}Call Path : fooCall to virtual function during construction will not dispatch to derived class}}
-#else
-  // expected-warning-re@-5 ^}}Call to virtual function during construction will not dispatch to derived class}}
-#endif
-#endif
+  // expected-warning:Call to virtual function during construction
 }
 
 class D : public B {
@@ -115,7 +79,6 @@
   int foo() override;
 };
 
-// Regression test: don't crash when there's no direct callee.
 class F {
 public:
   F() {
@@ -125,17 +88,68 @@
   void foo();
 };
 
-int main() {
-  A *a;
-  B *b;
-  C *c;
-  D *d;
-  E *e;
-  F *f;
-}
+class G {
+public:
+  virtual void bar();
+  void foo() {
+bar();
+  // no warning
+  }
+};
 
-#include "virtualcall.h"
+class H{
+public:
+  H() : initState(0) { init(); }
+  int initState;
+  virtual void f() const;
+  void init() {
+if (initState)
+  f();
+  // no warning
+  }
 
-#define AS_SYSTEM
-#include "virtualcall.h"
-#undef AS_SYSTEM
+  H(int i) {
+G g;
+g.foo();
+g.bar();
+  // no warning
+f();
+  // expected-warning:Call to