Re: [clang-tools-extra] r341375 - [clangd] Define a compact binary serialization fomat for symbol slab/index.

[Mikael Holmén via cfe-commits]

Hi Sam,

This doesn't compile for me. Both clang 3.6.0 and gcc 5.4.0 complain:

[1/6] Building CXX object 
tools/clang/tools/extra/clangd/CMakeFiles/clangDaemon.dir/index/Serialization.cpp.o
FAILED: 
tools/clang/tools/extra/clangd/CMakeFiles/clangDaemon.dir/index/Serialization.cpp.o 

/usr/bin/clang++  -march=corei7  -DGTEST_HAS_RTTI=0 -D_DEBUG 
-D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -Itools/clang/tools/extra/clangd 
-I../tools/clang/tools/extra/clangd -I../tools/clang/include 
-Itools/clang/include -I/usr/include/libxml2 -Iinclude -I../include 
-I/proj/flexasic/app/valgrind/3.11.0/include  -fPIC 
-fvisibility-inlines-hidden -Werror -Werror=date-time -std=c++11 -Wall 
-Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
-Wmissing-field-initializers -pedantic -Wno-long-long 
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
-Wstring-conversion -fdiagnostics-color -ffunction-sections 
-fdata-sections -fno-common -Woverloaded-virtual -Wno-nested-anon-types 
-O3-UNDEBUG  -fno-exceptions -fno-rtti -MMD -MT 
tools/clang/tools/extra/clangd/CMakeFiles/clangDaemon.dir/index/Serialization.cpp.o 
-MF 
tools/clang/tools/extra/clangd/CMakeFiles/clangDaemon.dir/index/Serialization.cpp.o.d 
-o 
tools/clang/tools/extra/clangd/CMakeFiles/clangDaemon.dir/index/Serialization.cpp.o 
-c ../tools/clang/tools/extra/clangd/index/Serialization.cpp
../tools/clang/tools/extra/clangd/index/Serialization.cpp:154:10: error: 
no viable conversion from 'clang::clangd::(anonymous 
namespace)::StringTableIn' to 'Expectednamespace)::StringTableIn>'

  return Table;
 ^
../include/llvm/Support/Error.h:434:41: note: candidate constructor (the 
implicit copy constructor) not viable: no known conversion from 
'clang::clangd::(anonymous namespace)::StringTableIn' to 'const 
llvm::Expected &' 
for 1st argument

template  class LLVM_NODISCARD Expected {
^
../include/llvm/Support/Error.h:456:3: note: candidate constructor not 
viable: no known conversion from 'clang::clangd::(anonymous 
namespace)::StringTableIn' to 'llvm::Error' for 1st argument

  Expected(Error Err)
  ^
../include/llvm/Support/Error.h:470:3: note: candidate constructor not 
viable: no known conversion from 'clang::clangd::(anonymous 
namespace)::StringTableIn' to 'llvm::ErrorSuccess' for 1st argument

  Expected(ErrorSuccess) = delete;
  ^
../include/llvm/Support/Error.h:488:3: note: candidate constructor not 
viable: no known conversion from 'clang::clangd::(anonymous 
namespace)::StringTableIn' to 'llvm::Expectednamespace)::StringTableIn> &&' for 1st argument

  Expected(Expected &&Other) { moveConstruct(std::move(Other)); }
  ^
../include/llvm/Support/Error.h:476:36: note: candidate template 
ignored: disabled by 'enable_if' [with OtherT = 
clang::clangd::(anonymous namespace)::StringTableIn &]
   typename std::enable_ifT>::value>::type

   ^
../include/llvm/Support/Error.h:493:3: note: candidate template ignored: 
could not match 'Expected' against 
'clang::clangd::(anonymous namespace)::StringTableIn'

  Expected(Expected &&Other,
  ^
In file included from 
../tools/clang/tools/extra/clangd/index/Serialization.cpp:9:
In file included from 
../tools/clang/tools/extra/clangd/index/Serialization.h:23:

In file included from ../tools/clang/tools/extra/clangd/index/Index.h:13:
In file included from ../tools/clang/include/clang/Index/IndexSymbol.h:14:
In file included from ../tools/clang/include/clang/Lex/MacroInfo.h:18:
In file included from ../tools/clang/include/clang/Lex/Token.h:17:
In file included from 
../tools/clang/include/clang/Basic/SourceLocation.h:19:

In file included from ../include/llvm/ADT/StringRef.h:13:
In file included from ../include/llvm/ADT/STLExtras.h:20:
../include/llvm/ADT/Optional.h:41:28: error: call to implicitly-deleted 
copy constructor of 'clang::clangd::SymbolSlab'

  new (storage.buffer) T(*O.getPointer());
   ^ ~~~
../include/llvm/ADT/Optional.h:141:3: note: in instantiation of member 
function 
'llvm::optional_detail::OptionalStoragefalse>::OptionalStorage' requested here

  Optional(const Optional &O) = default;
  ^
../tools/clang/tools/extra/clangd/index/Serialization.cpp:325:10: note: 
in instantiation of function template specialization 
'llvm::Expected::Expected&>' requested here

  return Result;
 ^
../tools/clang/tools/extra/clangd/index/Index.h:324:26: note: copy 
constructor of 'SymbolSlab' is implicitly deleted because field 'Arena' 
has a deleted copy constructor
  llvm::BumpPtrAllocator Arena; // Owns Symbol data that the Symbols do 
not.

 ^
../include/llvm/Support/Allocator.h:157:3: note: copy constructor is 
implicitly deleted because 'BumpPtrAllocatorImpl4096, 4096>' has a user-declared move constructor

  BumpPtrAllocatorImpl(BumpPtrAllocatorImpl &&Old)
  ^
2 errors generated.

Several build

Re: [clang-tools-extra] r341375 - [clangd] Define a compact binary serialization fomat for symbol slab/index.

[Mikael Holmén via cfe-commits]

On 09/05/2018 09:56 AM, Sam McCall wrote:

Sorry! r341451 should fix this, will keep an eye on the buildbots.



Now it compiles with clang 3.6.0 but with gcc 5.4.0 it fails with

/proj/bbi_twh/wh_bbi/x86_64-Linux2/bbigcc/1.5.4.0/crosscompiler/bin/g++ 
-I/proj/bbi_twh/wh_bbi/x86_64-Linux2/bbilibxml2/1/include 
-DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Itools/clang/tools/extra/clangd/global-symbol-builder 
-I../tools/clang/tools/extra/clangd/global-symbol-builder 
-I../tools/clang/include -Itools/clang/include -I/usr/include/libxml2 
-Iinclude -I../include 
-I../tools/clang/tools/extra/clangd/global-symbol-builder/.. 
-I/repo/app/valgrind/3.11.0/include  -fPIC -fvisibility-inlines-hidden 
-Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic 
-Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor 
-Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections 
-fno-common -Woverloaded-virtual -fno-strict-aliasing -O3-UNDEBUG 
-fno-exceptions -fno-rtti -MMD -MT 
tools/clang/tools/extra/clangd/global-symbol-builder/CMakeFiles/global-symbol-builder.dir/GlobalSymbolBuilderMain.cpp.o 
-MF 
tools/clang/tools/extra/clangd/global-symbol-builder/CMakeFiles/global-symbol-builder.dir/GlobalSymbolBuilderMain.cpp.o.d 
-o 
tools/clang/tools/extra/clangd/global-symbol-builder/CMakeFiles/global-symbol-builder.dir/GlobalSymbolBuilderMain.cpp.o 
-c 
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp
In file included from 
../tools/clang/include/clang/Frontend/CommandLineSourceLoc.h:19:0,
 from 
../tools/clang/include/clang/Frontend/FrontendOptions.h:13,
 from 
../tools/clang/include/clang/Frontend/CompilerInvocation.h:19,
 from 
../tools/clang/include/clang/Frontend/CompilerInstance.h:16,
 from 
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:22:
../include/llvm/Support/CommandLine.h:606:52: error: invalid cast from 
type 'llvm::cl::opt' to type 'int'

   llvm::cl::OptionEnumValue { FLAGNAME, int(ENUMVAL), DESC }
^
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:67:16: 
note: in expansion of macro 'clEnumValN'
clEnumValN(Format::YAML, "yaml", "human-readable YAML 
format"),

^
../include/llvm/Support/CommandLine.h:606:29: error: expected 
primary-expression before '{' token

   llvm::cl::OptionEnumValue { FLAGNAME, int(ENUMVAL), DESC }
 ^
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:67:16: 
note: in expansion of macro 'clEnumValN'
clEnumValN(Format::YAML, "yaml", "human-readable YAML 
format"),

^
../include/llvm/Support/CommandLine.h:606:52: error: invalid cast from 
type 'llvm::cl::opt' to type 'int'

   llvm::cl::OptionEnumValue { FLAGNAME, int(ENUMVAL), DESC }
^
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:68:16: 
note: in expansion of macro 'clEnumValN'
clEnumValN(Format::Binary, "binary", "binary RIFF 
format")),

^
../include/llvm/Support/CommandLine.h:606:29: error: expected 
primary-expression before '{' token

   llvm::cl::OptionEnumValue { FLAGNAME, int(ENUMVAL), DESC }
 ^
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:68:16: 
note: in expansion of macro 'clEnumValN'
clEnumValN(Format::Binary, "binary", "binary RIFF 
format")),

^
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:69:27: 
error: 'Format' is not a class, namespace, or enumeration

llvm::cl::init(Format::YAML));
   ^
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp: 
In function 'int main(int, const char**)':
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:276:23: 
error: 'clang::clangd::Format' is not a class, namespace, or enumeration

   case clang::clangd::Format::YAML:
   ^
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:279:23: 
error: 'clang::clangd::Format' is not a class, namespace, or enumeration

   case clang::clangd::Format::Binary: {
   ^
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:275:10: 
warning: enumeration value 'YAML' not handled in switch [-Wswitch]

   switch (clang::clangd::Format) {
  ^
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:275:10: 
warning: enumeration value 'Binary' not handled in sw

Re: [clang-tools-extra] r341375 - [clangd] Define a compact binary serialization fomat for symbol slab/index.

[Mikael Holmén via cfe-commits]

On 09/05/2018 12:41 PM, Sam McCall wrote:
Thanks. Unclear to me whether it's the enum class or the anonymous 
namespace that's triggering this (I believe) compiler bug, but r341459 
may help...


Still doesn't work.

In file included from 
../tools/clang/include/clang/Frontend/CommandLineSourceLoc.h:19:0,
 from 
../tools/clang/include/clang/Frontend/FrontendOptions.h:13,
 from 
../tools/clang/include/clang/Frontend/CompilerInvocation.h:19,
 from 
../tools/clang/include/clang/Frontend/CompilerInstance.h:16,
 from 
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:22:
../include/llvm/Support/CommandLine.h:606:29: error: expected 
primary-expression before '{' token

   llvm::cl::OptionEnumValue { FLAGNAME, int(ENUMVAL), DESC }
 ^
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:67:16: 
note: in expansion of macro 'clEnumValN'
clEnumValN(Format::YAML, "yaml", "human-readable YAML 
format"),

^
../include/llvm/Support/CommandLine.h:606:29: error: expected 
primary-expression before '{' token

   llvm::cl::OptionEnumValue { FLAGNAME, int(ENUMVAL), DESC }
 ^
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:68:16: 
note: in expansion of macro 'clEnumValN'
clEnumValN(Format::Binary, "binary", "binary RIFF 
format")),

^
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:69:27: 
error: 'Format' is not a class, namespace, or enumeration

llvm::cl::init(Format::YAML));
   ^
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp: 
In function 'int main(int, const char**)':
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:276:23: 
error: 'clang::clangd::Format' is not a class, namespace, or enumeration

   case clang::clangd::Format::YAML:
   ^
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:279:23: 
error: 'clang::clangd::Format' is not a class, namespace, or enumeration

   case clang::clangd::Format::Binary: {
   ^
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:275:10: 
warning: enumeration value 'YAML' not handled in switch [-Wswitch]

   switch (clang::clangd::Format) {
  ^
../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:275:10: 
warning: enumeration value 'Binary' not handled in switch [-Wswitch]


Changing the name of the enum from Format to Formats (so the name isn't 
the same as the variable) makes it compile.


I.e:

@@ -58,17 +58,17 @@ static llvm::cl::opt MergeOnTheFly(
 "usage and an almost instant reduce stage. Optimal for running 
as a "
 "standalone tool, but cannot be used with multi-process 
executors like "

 "MapReduce."),
 llvm::cl::init(true), llvm::cl::Hidden);

-enum Format { YAML, Binary };
-static llvm::cl::opt
+enum Formats { YAML, Binary };
+static llvm::cl::opt
 Format("format", llvm::cl::desc("Format of the index to be written"),
llvm::cl::values(
-   clEnumValN(Format::YAML, "yaml", "human-readable YAML 
format"),

-   clEnumValN(Format::Binary, "binary", "binary RIFF format")),
-   llvm::cl::init(Format::YAML));
+   clEnumValN(Formats::YAML, "yaml", "human-readable YAML 
format"),
+   clEnumValN(Formats::Binary, "binary", "binary RIFF 
format")),

+   llvm::cl::init(Formats::YAML));

 /// Responsible for aggregating symbols from each processed file and 
producing

 /// the final results. All methods in this class must be thread-safe,
 /// 'consumeSymbols' may be called from multiple threads.
 class SymbolsConsumer {
@@ -271,14 +271,14 @@ int main(int argc, const char **argv) {
   }
   // Reduce phase: combine symbols with the same IDs.
   auto UniqueSymbols = Consumer->mergeResults();
   // Output phase: emit result symbols.
   switch (clang::clangd::Format) {
-  case clang::clangd::Format::YAML:
+  case clang::clangd::Formats::YAML:
 SymbolsToYAML(UniqueSymbols, llvm::outs());
 break;
-  case clang::clangd::Format::Binary: {
+  case clang::clangd::Formats::Binary: {
 clang::clangd::IndexFileOut Out;
 Out.Symbols = &UniqueSymbols;
 llvm::outs() << Out;
   }
   }

seems to compile with gcc 5.4.0.

I've no idea if this is a gcc bug or if it's a bug in clang to not also 
complain about it.


/Mikael



On Wed, Sep 5, 2018 at 11:05 AM Mikael Holmén 
mailto:mikael.hol...@ericsson.com>> wrote:




On 09/05/2018 09:56 AM, Sam McCall wrote:
 > Sorry! r341451 should fix this, will keep an eye on the buildbots.
 >

Now it compiles with clang 3.6.0 but with gcc 5.4.0 it fails with

/

Re: [clang-tools-extra] r341375 - [clangd] Define a compact binary serialization fomat for symbol slab/index.

[Mikael Holmén via cfe-commits]

On 09/05/2018 03:26 PM, Sam McCall wrote:

Ah, thanks! Fixed in r341467.

I'd guess this was a GCC bug, because GCC >=6 accepts it: 
https://godbolt.org/z/Yb5gBT




Yep works now. Thanks!
/Mikael

On Wed, Sep 5, 2018 at 2:21 PM Mikael Holmén > wrote:




On 09/05/2018 12:41 PM, Sam McCall wrote:
 > Thanks. Unclear to me whether it's the enum class or the anonymous
 > namespace that's triggering this (I believe) compiler bug,
but r341459
 > may help...

Still doesn't work.

In file included from
../tools/clang/include/clang/Frontend/CommandLineSourceLoc.h:19:0,
                   from
../tools/clang/include/clang/Frontend/FrontendOptions.h:13,
                   from
../tools/clang/include/clang/Frontend/CompilerInvocation.h:19,
                   from
../tools/clang/include/clang/Frontend/CompilerInstance.h:16,
                   from

../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:22:
../include/llvm/Support/CommandLine.h:606:29: error: expected
primary-expression before '{' token
     llvm::cl::OptionEnumValue { FLAGNAME, int(ENUMVAL), DESC }
                               ^

../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:67:16:

note: in expansion of macro 'clEnumValN'
                  clEnumValN(Format::YAML, "yaml", "human-readable YAML
format"),
                  ^
../include/llvm/Support/CommandLine.h:606:29: error: expected
primary-expression before '{' token
     llvm::cl::OptionEnumValue { FLAGNAME, int(ENUMVAL), DESC }
                               ^

../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:68:16:

note: in expansion of macro 'clEnumValN'
                  clEnumValN(Format::Binary, "binary", "binary RIFF
format")),
                  ^

../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:69:27:

error: 'Format' is not a class, namespace, or enumeration
              llvm::cl::init(Format::YAML));
                             ^

../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:

In function 'int main(int, const char**)':

../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:276:23:

error: 'clang::clangd::Format' is not a class, namespace, or enumeration
     case clang::clangd::Format::YAML:
                         ^

../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:279:23:

error: 'clang::clangd::Format' is not a class, namespace, or enumeration
     case clang::clangd::Format::Binary: {
                         ^

../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:275:10:

warning: enumeration value 'YAML' not handled in switch [-Wswitch]
     switch (clang::clangd::Format) {
            ^

../tools/clang/tools/extra/clangd/global-symbol-builder/GlobalSymbolBuilderMain.cpp:275:10:

warning: enumeration value 'Binary' not handled in switch [-Wswitch]

Changing the name of the enum from Format to Formats (so the name isn't
the same as the variable) makes it compile.

I.e:

@@ -58,17 +58,17 @@ static llvm::cl::opt MergeOnTheFly(
           "usage and an almost instant reduce stage. Optimal for
running
as a "
           "standalone tool, but cannot be used with multi-process
executors like "
           "MapReduce."),
       llvm::cl::init(true), llvm::cl::Hidden);

-enum Format { YAML, Binary };
-static llvm::cl::opt
+enum Formats { YAML, Binary };
+static llvm::cl::opt
       Format("format", llvm::cl::desc("Format of the index to be
written"),
              llvm::cl::values(
-               clEnumValN(Format::YAML, "yaml", "human-readable YAML
format"),
-               clEnumValN(Format::Binary, "binary", "binary RIFF
format")),
-           llvm::cl::init(Format::YAML));
+               clEnumValN(Formats::YAML, "yaml", "human-readable YAML
format"),
+               clEnumValN(Formats::Binary, "binary", "binary RIFF
format")),
+           llvm::cl::init(Formats::YAML));

   /// Responsible for aggregating symbols from each processed file and
producing
   /// the final results. All methods in this class must be thread-safe,
   /// 'consumeSymbols' may be called from multiple threads.
   class SymbolsConsumer {
@@ -271,14 +271,14 @@ int main(int argc, const char **argv) {
     }
     // Reduce phase: combine symbols with the same IDs.
     auto UniqueSymbols = Consumer->mergeResults();
     // Output phase: emit result symbols.
     switch (clang::clangd::Format) {
-  case clang::clangd::Format::YAML:
+  

Re: r304852 - Improve error recovery for missing 'template' keyword in contexts where the

[Mikael Holmén via cfe-commits]

Hi Richard,

See below.

On 06/07/2017 02:29 AM, Richard Smith via cfe-commits wrote:

Author: rsmith
Date: Tue Jun  6 19:29:44 2017
New Revision: 304852

URL: http://llvm.org/viewvc/llvm-project?rev=304852&view=rev
Log:
Improve error recovery for missing 'template' keyword in contexts where the
template is valid with or without it (with different meanings).

If we see "dependent.x<...", and what follows the '<' is a valid expression,
we must parse the '<' as a comparison rather than a template angle bracket.
When we later come to instantiate, if we find that the LHS of the '<' actually
names an overload set containing function templates, produce a diagnostic
suggesting that the 'template' keyword was missed rather than producing a
mysterious diagnostic saying that the function must be called (and pointing
at what looks to already be a function call!).

Modified:
 cfe/trunk/lib/Sema/SemaExpr.cpp
 cfe/trunk/test/SemaTemplate/dependent-template-recover.cpp

Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=304852&r1=304851&r2=304852&view=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Tue Jun  6 19:29:44 2017
@@ -11828,6 +11828,32 @@ ExprResult Sema::BuildBinOp(Scope *S, So
RHSExpr->getType()->isOverloadableType())
  return BuildOverloadedBinOp(*this, S, OpLoc, Opc, LHSExpr, RHSExpr);
  }
+
+// If we're instantiating "a.x < b" or "A::x < b" and 'x' names a function
+// template, diagnose the missing 'template' keyword instead of diagnosing
+// an invalid use of a bound member function.
+//
+// Note that "A::x < b" might be valid if 'b' has an overloadable type due
+// to C++1z [over.over]/1.4, but we already checked for that case above.
+if (Opc == BO_LT && inTemplateInstantiation() &&
+(pty->getKind() == BuiltinType::BoundMember ||
+ pty->getKind() == BuiltinType::Overload)) {
+  auto *OE = dyn_cast(LHSExpr);
+  if (OE && !OE->hasTemplateKeyword() && !OE->hasExplicitTemplateArgs() &&
+  std::any_of(OE->decls_begin(), OE->decls_end(), [](NamedDecl *ND) {
+return isa(ND);
+  })) {
+if (auto *Q = OE->getQualifier()) {


I'm getting a compiler warning that looks reasonable here:

../tools/clang/lib/Sema/SemaExpr.cpp:11846:19: error: unused variable 
'Q' [-Werror,-Wunused-variable]

if (auto *Q = OE->getQualifier()) {
  ^
1 error generated.


I got the above with clang 3.6.

Regards,
Mikael


+  Diag(OE->getQualifierLoc().getBeginLoc(),
+   diag::err_template_kw_missing)
+<< OE->getName().getAsString() << "";
+} else {
+  Diag(OE->getNameLoc(), diag::err_template_kw_missing)
+<< OE->getName().getAsString() << "";
+}
+return ExprError();
+  }
+}
  
  ExprResult LHS = CheckPlaceholderExpr(LHSExpr);

  if (LHS.isInvalid()) return ExprError();

Modified: cfe/trunk/test/SemaTemplate/dependent-template-recover.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaTemplate/dependent-template-recover.cpp?rev=304852&r1=304851&r2=304852&view=diff
==
--- cfe/trunk/test/SemaTemplate/dependent-template-recover.cpp (original)
+++ cfe/trunk/test/SemaTemplate/dependent-template-recover.cpp Tue Jun  6 
19:29:44 2017
@@ -17,6 +17,28 @@ struct X {
}
  };
  
+struct MrsBadcrumble {

+  friend MrsBadcrumble operator<(void (*)(int), MrsBadcrumble);
+  friend void operator>(MrsBadcrumble, int);
+} mb;
+
+template void f(T t) {
+  t.f(0); // expected-error {{missing 'template' keyword prior to dependent 
template name 'f'}}
+  t.T::f(0); // expected-error {{missing 'template' keyword prior to 
dependent template name 'f'}}
+  T::g(0); // expected-error {{missing 'template' keyword prior to 
dependent template name 'g'}}
+
+  // Note: no diagnostic here, this is actually valid as a comparison between
+  // the decayed pointer to Y::g<> and mb!
+  T::g(0);
+}
+
+struct Y {
+  template  void f(int);
+  template  static void g(int); // expected-warning 0-1{{extension}}
+};
+void q() { void (*p)(int) = Y::g; }
+template void f<0>(Y); // expected-note {{in instantiation of}}
+
  namespace PR9401 {
// From GCC PR c++/45558
template 


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


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

Re: r327345 - [analyzer] Destroy and lifetime-extend inlined function return values properly.

[Mikael Holmén via cfe-commits]

Hi Artem,

This commit gives the following warning:

../tools/clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp:283:23: error: 
unused variable 'RCC' [-Werror,-Wunused-variable]
  if (const auto *RCC = 
dyn_cast(CC)) {

  ^
1 error generated.

Regards,
Mikael

On 03/13/2018 12:22 AM, Artem Dergachev via cfe-commits wrote:

Author: dergachev
Date: Mon Mar 12 16:22:35 2018
New Revision: 327345

URL: http://llvm.org/viewvc/llvm-project?rev=327345&view=rev
Log:
[analyzer] Destroy and lifetime-extend inlined function return values properly.

This patch uses the newly added CFGCXXRecordTypedCall element at the call site
of the caller to construct the return value within the callee directly into the
caller's stack frame. This way it is also capable of populating the temporary
destructor and lifetime extension maps for the temporary, which allows
temporary destructors and lifetime extension to work correctly.

This patch does not affect temporaries that were returned from conservatively
evaluated functions.

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

Modified:
 cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
 cfe/trunk/test/Analysis/lifetime-extension.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp?rev=327345&r1=327344&r2=327345&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp Mon Mar 12 16:22:35 2018
@@ -197,16 +197,19 @@ ExprEngine::getRegionForConstructedObjec
return MRMgr.getCXXTempObjectRegion(CE, LCtx);
  }
  case ConstructionContext::ReturnedValueKind: {
-  // TODO: We should construct into a CXXBindTemporaryExpr or a
-  // MaterializeTemporaryExpr around the call-expression on the previous
-  // stack frame. Currently we re-bind the temporary to the correct region
-  // later, but that's not semantically correct. This of course does not
-  // apply when we're in the top frame. But if we are in an inlined
-  // function, we should be able to take the call-site CFG element,
-  // and it should contain (but right now it wouldn't) some sort of
-  // construction context that'd give us the right temporary expression.
+  // The temporary is to be managed by the parent stack frame.
+  // So build it in the parent stack frame if we're not in the
+  // top frame of the analysis.
+  // TODO: What exactly happens when we are? Does the temporary object live
+  // long enough in the region store in this case? Would checkers think
+  // that this object immediately goes out of scope?
+  const LocationContext *TempLCtx = LCtx;
+  if (const LocationContext *CallerLCtx =
+  LCtx->getCurrentStackFrame()->getParent()) {
+TempLCtx = CallerLCtx;
+  }
CallOpts.IsTemporaryCtorOrDtor = true;
-  return MRMgr.getCXXTempObjectRegion(CE, LCtx);
+  return MRMgr.getCXXTempObjectRegion(CE, TempLCtx);
  }
  }
}
@@ -262,6 +265,7 @@ void ExprEngine::VisitCXXConstructExpr(c
assert(C || getCurrentCFGElement().getAs());
const ConstructionContext *CC = C ? C->getConstructionContext() : nullptr;
  
+  bool IsReturnedIntoParentStackFrame = false;

const CXXBindTemporaryExpr *BTE = nullptr;
const MaterializeTemporaryExpr *MTE = nullptr;
  
@@ -269,25 +273,44 @@ void ExprEngine::VisitCXXConstructExpr(c

case CXXConstructExpr::CK_Complete: {
  Target = getRegionForConstructedObject(CE, Pred, CC, CallOpts);
  
-// In case of temporary object construction, extract data necessary for

-// destruction and lifetime extension.
-if (const auto *TCC =
-dyn_cast_or_null(CC)) {
-  assert(CallOpts.IsTemporaryCtorOrDtor);
-  assert(!CallOpts.IsCtorOrDtorWithImproperlyModeledTargetRegion);
-  if (AMgr.getAnalyzerOptions().includeTemporaryDtorsInCFG()) {
-BTE = TCC->getCXXBindTemporaryExpr();
-MTE = TCC->getMaterializedTemporaryExpr();
-if (!BTE) {
-  // FIXME: lifetime extension for temporaries without destructors
-  // is not implemented yet.
-  MTE = nullptr;
+if (CC) {
+  // In case of temporary object construction, extract data necessary for
+  // destruction and lifetime extension.
+  const auto *TCC = dyn_cast(CC);
+
+  // If the temporary is being returned from the function, it will be
+  // destroyed or lifetime-extended in the caller stack frame.
+  if (const auto *RCC = dyn_cast(CC)) {
+const StackFrameContext *SFC = LCtx->getCurrentStackFrame();
+assert(SFC);
+if (SFC->getParent()) {
+  IsReturnedIntoParentStackFrame = true;
+  const CFGElement &CallElem =
+  (*SFC->getCallSiteBlock())[SFC->getIndex()];
+  if (

Re: r334935 - [analyzer] Checker for uninitialized C++ objects

[Mikael Holmén via cfe-commits]

Hi Kristof,

Building without asserts (-DNDEBUG) I get the following warning/error 
with this commit:


[3082/3387] Building CXX object 
tools/clang/lib/StaticAnalyzer/Checkers...eFiles/clangStaticAnalyzerCheckers.dir/UninitializedObjectChecker.cpp.
FAILED: 
tools/clang/lib/StaticAnalyzer/Checkers/CMakeFiles/clangStaticAnalyzerCheckers.dir/UninitializedObjectChecker.cpp.o 

/repo/app/clang/3.6/bin/clang++  -march=corei7  -DGTEST_HAS_RTTI=0 
-D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -Itools/clang/lib/StaticAnalyzer/Checkers 
-I../tools/clang/lib/StaticAnalyzer/Checkers -I../tools/clang/include 
-Itools/clang/include -I/usr/include/libxml2 -Iinclude -I../include 
-I/repo/app/valgrind/3.11.0/include  -fPIC -fvisibility-inlines-hidden 
-Werror -Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color 
-ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual 
-Wno-nested-anon-types -O3 -DNDEBUG-fno-exceptions -fno-rtti -MMD 
-MT 
tools/clang/lib/StaticAnalyzer/Checkers/CMakeFiles/clangStaticAnalyzerCheckers.dir/UninitializedObjectChecker.cpp.o 
-MF 
tools/clang/lib/StaticAnalyzer/Checkers/CMakeFiles/clangStaticAnalyzerCheckers.dir/UninitializedObjectChecker.cpp.o.d 
-o 
tools/clang/lib/StaticAnalyzer/Checkers/CMakeFiles/clangStaticAnalyzerCheckers.dir/UninitializedObjectChecker.cpp.o 
-c ../tools/clang/lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp
../tools/clang/lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp:215:6: 
error: unused function 'isPrimitiveType' [-Werror,-Wunused-function]

bool isPrimitiveType(const QualType &T) {
 ^
1 error generated.

Regards,
Mikael

On 06/18/2018 01:50 PM, Kristof Umann via cfe-commits wrote:

Author: szelethus
Date: Mon Jun 18 04:50:17 2018
New Revision: 334935

URL: http://llvm.org/viewvc/llvm-project?rev=334935&view=rev
Log:
[analyzer] Checker for uninitialized C++ objects

This checker analyzes C++ constructor calls, and reports uninitialized fields.

Due to the nature of this problem (uninitialized fields after an object
construction), this checker doesn't search for bugs, but rather is a tool to
enforce a specific programming model where every field needs to be initialized.

This checker lands in alpha for now, and a number of followup patches will be
made to reduce false negatives and to make it easier for the user to understand
what rules the checker relies on, eg. whether a derived class' constructor is
responsible for initializing inherited data members or whether it should be
handled in the base class' constructor.

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

Added:
 cfe/trunk/lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp
 
cfe/trunk/test/Analysis/Inputs/system-header-simulator-for-cxx-uninitialized-object.h
 cfe/trunk/test/Analysis/cxx-uninitialized-object-inheritance.cpp
 cfe/trunk/test/Analysis/cxx-uninitialized-object-ptr-ref.cpp
 cfe/trunk/test/Analysis/cxx-uninitialized-object.cpp
Modified:
 cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td
 cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt

Modified: cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td?rev=334935&r1=334934&r2=334935&view=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td (original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Checkers/Checkers.td Mon Jun 18 
04:50:17 2018
@@ -319,6 +319,10 @@ def MisusedMovedObjectChecker: Checker<"
"object will be reported">,
   DescFile<"MisusedMovedObjectChecker.cpp">;
  
+def UninitializedObjectChecker: Checker<"UninitializedObject">,

+ HelpText<"Reports uninitialized fields after object construction">,
+ DescFile<"UninitializedObjectChecker.cpp">;
+
  } // end: "alpha.cplusplus"
  
  


Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt?rev=334935&r1=334934&r2=334935&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt Mon Jun 18 04:50:17 
2018
@@ -92,6 +92,7 @@ add_clang_library(clangStaticAnalyzerChe
UndefResultChecker.cpp
UndefinedArraySubscriptChecker.cpp
UndefinedAssignmentChecker.cpp
+  UninitializedObjectChecker.cpp
UnixAPIChecker.cpp
UnreachableCodeChecker.cpp
VforkChecker.cpp

Added: cfe/trunk/lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp
URL: 
http://llvm.org/viewvc/ll

Re: [clang-tools-extra] r344650 - [clang-doc] Add unit tests for serialization

[Mikael Holmén via cfe-commits]

Hi Julie,

clang 3.6.0 complains on this commit:

/usr/bin/clang++  -march=corei7  -DGTEST_HAS_RTTI=0 
-DGTEST_HAS_TR1_TUPLE=0 -DGTEST_LANG_CXX11=1 -D_DEBUG -D_GNU_SOURCE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Itools/clang/tools/extra/unittests/clang-doc 
-I../tools/clang/tools/extra/unittests/clang-doc 
-I../tools/clang/include -Itools/clang/include -I/usr/include/libxml2 
-Iinclude -I../include -I../tools/clang/tools/extra/clang-doc 
-I../utils/unittest/googletest/include 
-I../utils/unittest/googlemock/include 
-I/proj/flexasic/app/valgrind/3.11.0/include  -fPIC 
-fvisibility-inlines-hidden -Werror -Werror=date-time -std=c++11 -Wall 
-Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
-Wmissing-field-initializers -pedantic -Wno-long-long 
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
-Wstring-conversion -fdiagnostics-color -ffunction-sections 
-fdata-sections -fno-common -Woverloaded-virtual -Wno-nested-anon-types 
-O3-UNDEBUG  -Wno-variadic-macros 
-Wno-gnu-zero-variadic-macro-arguments -fno-exceptions -fno-rtti -MMD 
-MT 
tools/clang/tools/extra/unittests/clang-doc/CMakeFiles/ClangDocTests.dir/BitcodeTest.cpp.o
 
-MF 
tools/clang/tools/extra/unittests/clang-doc/CMakeFiles/ClangDocTests.dir/BitcodeTest.cpp.o.d
 
-o 
tools/clang/tools/extra/unittests/clang-doc/CMakeFiles/ClangDocTests.dir/BitcodeTest.cpp.o
 
-c ../tools/clang/tools/extra/unittests/clang-doc/BitcodeTest.cpp
In file included from 
../tools/clang/tools/extra/unittests/clang-doc/BitcodeTest.cpp:12:
../tools/clang/tools/extra/unittests/clang-doc/ClangDocTest.h:25:14: 
error: suggest braces around initialization of subobject 
[-Werror,-Wmissing-braces]
 SymbolID{1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1};
  ^~
  { }
1 error generated.

Regards,
Mikael

On 10/17/2018 01:06 AM, Julie Hockett via cfe-commits wrote:
> Author: juliehockett
> Date: Tue Oct 16 16:06:42 2018
> New Revision: 344650
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=344650&view=rev
> Log:
> [clang-doc] Add unit tests for serialization
> 
> Adds unit tests for the Serialize library.
> 
> This is part of a move to convert clang-doc's tests to a more
> maintainable unit test framework, with a smaller number of integration
> tests to maintain and more granular failure feedback.
> 
> Differential Revision: https://reviews.llvm.org/D53081
> 
> Added:
>  clang-tools-extra/trunk/unittests/clang-doc/
>  clang-tools-extra/trunk/unittests/clang-doc/CMakeLists.txt
>  clang-tools-extra/trunk/unittests/clang-doc/ClangDocTest.cpp
>  clang-tools-extra/trunk/unittests/clang-doc/ClangDocTest.h
>  clang-tools-extra/trunk/unittests/clang-doc/SerializeTest.cpp
> Modified:
>  clang-tools-extra/trunk/unittests/CMakeLists.txt
> 
> Modified: clang-tools-extra/trunk/unittests/CMakeLists.txt
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/CMakeLists.txt?rev=344650&r1=344649&r2=344650&view=diff
> ==
> --- clang-tools-extra/trunk/unittests/CMakeLists.txt (original)
> +++ clang-tools-extra/trunk/unittests/CMakeLists.txt Tue Oct 16 16:06:42 2018
> @@ -16,6 +16,7 @@ endif()
>   
>   add_subdirectory(change-namespace)
>   add_subdirectory(clang-apply-replacements)
> +add_subdirectory(clang-doc)
>   add_subdirectory(clang-move)
>   add_subdirectory(clang-query)
>   add_subdirectory(clang-tidy)
> 
> Added: clang-tools-extra/trunk/unittests/clang-doc/CMakeLists.txt
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clang-doc/CMakeLists.txt?rev=344650&view=auto
> ==
> --- clang-tools-extra/trunk/unittests/clang-doc/CMakeLists.txt (added)
> +++ clang-tools-extra/trunk/unittests/clang-doc/CMakeLists.txt Tue Oct 16 
> 16:06:42 2018
> @@ -0,0 +1,29 @@
> +set(LLVM_LINK_COMPONENTS
> +  support
> +  BitReader
> +  BitWriter
> +  )
> +
> +get_filename_component(CLANG_DOC_SOURCE_DIR
> +  ${CMAKE_CURRENT_SOURCE_DIR}/../../clang-doc REALPATH)
> +include_directories(
> +  ${CLANG_DOC_SOURCE_DIR}
> +  )
> +
> +add_extra_unittest(ClangDocTests
> +  ClangDocTest.cpp
> +  SerializeTest.cpp
> +  )
> +
> +target_link_libraries(ClangDocTests
> +  PRIVATE
> +  clangAST
> +  clangASTMatchers
> +  clangBasic
> +  clangDoc
> +  clangFormat
> +  clangFrontend
> +  clangRewrite
> +  clangTooling
> +  clangToolingCore
> +  )
> 
> Added: clang-tools-extra/trunk/unittests/clang-doc/ClangDocTest.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clang-doc/ClangDocTest.cpp?rev=344650&view=auto
> ==
> --- clang-tools-extra/trunk/unittests/clang-doc/ClangDocTest.cpp (added)
>

Re: [clang-tools-extra] r344650 - [clang-doc] Add unit tests for serialization

[Mikael Holmén via cfe-commits]

On 10/17/2018 08:30 PM, Julie Hockett wrote:
> https://reviews.llvm.org/D53381 should fix this -- thanks for the note!

Yep, thanks!

/Mikael

> 
> Julie
> 
> On Wed, Oct 17, 2018 at 1:58 AM Mikael Holmén 
> mailto:mikael.hol...@ericsson.com>> wrote:
> 
> Hi Julie,
> 
> clang 3.6.0 complains on this commit:
> 
> /usr/bin/clang++  -march=corei7  -DGTEST_HAS_RTTI=0
> -DGTEST_HAS_TR1_TUPLE=0 -DGTEST_LANG_CXX11=1 -D_DEBUG -D_GNU_SOURCE
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -Itools/clang/tools/extra/unittests/clang-doc
> -I../tools/clang/tools/extra/unittests/clang-doc
> -I../tools/clang/include -Itools/clang/include -I/usr/include/libxml2
> -Iinclude -I../include -I../tools/clang/tools/extra/clang-doc
> -I../utils/unittest/googletest/include
> -I../utils/unittest/googlemock/include
> -I/proj/flexasic/app/valgrind/3.11.0/include  -fPIC
> -fvisibility-inlines-hidden -Werror -Werror=date-time -std=c++11 -Wall
> -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual
> -Wmissing-field-initializers -pedantic -Wno-long-long
> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
> -Wstring-conversion -fdiagnostics-color -ffunction-sections
> -fdata-sections -fno-common -Woverloaded-virtual -Wno-nested-anon-types
> -O3    -UNDEBUG  -Wno-variadic-macros
> -Wno-gnu-zero-variadic-macro-arguments -fno-exceptions -fno-rtti -MMD
> -MT
> 
> tools/clang/tools/extra/unittests/clang-doc/CMakeFiles/ClangDocTests.dir/BitcodeTest.cpp.o
> 
> -MF
> 
> tools/clang/tools/extra/unittests/clang-doc/CMakeFiles/ClangDocTests.dir/BitcodeTest.cpp.o.d
> 
> -o
> 
> tools/clang/tools/extra/unittests/clang-doc/CMakeFiles/ClangDocTests.dir/BitcodeTest.cpp.o
> 
> -c ../tools/clang/tools/extra/unittests/clang-doc/BitcodeTest.cpp
> In file included from
> ../tools/clang/tools/extra/unittests/clang-doc/BitcodeTest.cpp:12:
> ../tools/clang/tools/extra/unittests/clang-doc/ClangDocTest.h:25:14:
> error: suggest braces around initialization of subobject
> [-Werror,-Wmissing-braces]
>       SymbolID{1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
> 1, 1};
>   
> ^~
>                {   
>       }
> 1 error generated.
> 
> Regards,
> Mikael
> 
> On 10/17/2018 01:06 AM, Julie Hockett via cfe-commits wrote:
>  > Author: juliehockett
>  > Date: Tue Oct 16 16:06:42 2018
>  > New Revision: 344650
>  >
>  > URL: http://llvm.org/viewvc/llvm-project?rev=344650&view=rev
>  > Log:
>  > [clang-doc] Add unit tests for serialization
>  >
>  > Adds unit tests for the Serialize library.
>  >
>  > This is part of a move to convert clang-doc's tests to a more
>  > maintainable unit test framework, with a smaller number of
> integration
>  > tests to maintain and more granular failure feedback.
>  >
>  > Differential Revision: https://reviews.llvm.org/D53081
>  >
>  > Added:
>  >      clang-tools-extra/trunk/unittests/clang-doc/
>  >      clang-tools-extra/trunk/unittests/clang-doc/CMakeLists.txt
>  >      clang-tools-extra/trunk/unittests/clang-doc/ClangDocTest.cpp
>  >      clang-tools-extra/trunk/unittests/clang-doc/ClangDocTest.h
>  >      clang-tools-extra/trunk/unittests/clang-doc/SerializeTest.cpp
>  > Modified:
>  >      clang-tools-extra/trunk/unittests/CMakeLists.txt
>  >
>  > Modified: clang-tools-extra/trunk/unittests/CMakeLists.txt
>  > URL:
> 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/CMakeLists.txt?rev=344650&r1=344649&r2=344650&view=diff
>  >
> 
> ==
>  > --- clang-tools-extra/trunk/unittests/CMakeLists.txt (original)
>  > +++ clang-tools-extra/trunk/unittests/CMakeLists.txt Tue Oct 16
> 16:06:42 2018
>  > @@ -16,6 +16,7 @@ endif()
>  >
>  >   add_subdirectory(change-namespace)
>  >   add_subdirectory(clang-apply-replacements)
>  > +add_subdirectory(clang-doc)
>  >   add_subdirectory(clang-move)
>  >   add_subdirectory(clang-query)
>  >   add_subdirectory(clang-tidy)
>  >
>  > Added: clang-tools-extra/trunk/unittests/clang-doc/CMakeLists.txt
>  > URL:
> 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clang-doc/CMakeLists.txt?rev=344650&view=auto
>  >
> 
> ==
>  > --- clang-tools-extra/trunk/unittests/clang-doc/CMakeLists.txt
> (added)
>  > +++ clang-tools-extra/trunk/unittests/clang-doc/CMakeLists.txt
> Tue Oct 16 16:06:42 2018
>  > @@ -0,0 +1,29 @@
>  > +set(LLVM_LINK_COMPONENTS
>  > +  support
> 

Re: [clang-tools-extra] r352494 - [clangd] Interfaces for writing code tweaks

[Mikael Holmén via cfe-commits]

Hi Ilya,

I've no idea why, but when I compile this commit with gcc (7.4.0) the 
test fixits-command.test fails, and the output from clangd is rather 
different from when I compile it with clang (3.6.0).

So I run

build-all/bin/clangd -lit-test < 
/data/repo/master/llvm-master/tools/clang/tools/extra/test/clangd/fixits-command.test

and the first diff that I think is significant is that with gcc it says

E[09:44:29.470] error while getting semantic code actions: -32602: 
trying to get AST for non-added document

Before this patch the output from gcc and clang built clangd is identical.

Attaching logs with gcc and clang.

Any idea what the problem is?

Regards,
Mikael

On 1/29/19 3:17 PM, Ilya Biryukov via cfe-commits wrote:
> Author: ibiryukov
> Date: Tue Jan 29 06:17:36 2019
> New Revision: 352494
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=352494&view=rev
> Log:
> [clangd] Interfaces for writing code tweaks
> 
> Summary:
> The code tweaks are an implementation of mini-refactorings exposed
> via the LSP code actions. They run in two stages:
>- Stage 1. Decides whether the action is available to the user and
>  collects all the information required to finish the action.
>  Should be cheap, since this will run over all the actions known to
>  clangd on each textDocument/codeAction request from the client.
> 
>- Stage 2. Uses information from stage 1 to produce the actual edits
>  that the code action should perform. This stage can be expensive and
>  will only run if the user chooses to perform the specified action in
>  the UI.
> 
> One unfortunate consequence of this change is increased latency of
> processing the textDocument/codeAction requests, which now wait for an
> AST. However, we cannot avoid this with what we have available in the LSP
> today.
> 
> Reviewers: kadircet, ioeric, hokein, sammccall
> 
> Reviewed By: sammccall
> 
> Subscribers: mgrang, mgorny, MaskRay, jkorous, arphaman, cfe-commits
> 
> Differential Revision: https://reviews.llvm.org/D56267
> 
> Added:
>  clang-tools-extra/trunk/clangd/refactor/
>  clang-tools-extra/trunk/clangd/refactor/Tweak.cpp
>  clang-tools-extra/trunk/clangd/refactor/Tweak.h
>  clang-tools-extra/trunk/clangd/refactor/tweaks/
>  clang-tools-extra/trunk/clangd/refactor/tweaks/CMakeLists.txt
>  clang-tools-extra/trunk/clangd/refactor/tweaks/Dummy.cpp
> Modified:
>  clang-tools-extra/trunk/clangd/CMakeLists.txt
>  clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
>  clang-tools-extra/trunk/clangd/ClangdServer.cpp
>  clang-tools-extra/trunk/clangd/ClangdServer.h
>  clang-tools-extra/trunk/clangd/Protocol.cpp
>  clang-tools-extra/trunk/clangd/Protocol.h
>  clang-tools-extra/trunk/clangd/SourceCode.cpp
>  clang-tools-extra/trunk/clangd/SourceCode.h
>  clang-tools-extra/trunk/clangd/tool/CMakeLists.txt
>  clang-tools-extra/trunk/test/clangd/fixits-command.test
>  clang-tools-extra/trunk/test/clangd/initialize-params.test
> 
> Modified: clang-tools-extra/trunk/clangd/CMakeLists.txt
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/CMakeLists.txt?rev=352494&r1=352493&r2=352494&view=diff
> ==
> --- clang-tools-extra/trunk/clangd/CMakeLists.txt (original)
> +++ clang-tools-extra/trunk/clangd/CMakeLists.txt Tue Jan 29 06:17:36 2019
> @@ -71,6 +71,8 @@ add_clang_library(clangDaemon
> index/dex/PostingList.cpp
> index/dex/Trigram.cpp
>   
> +  refactor/Tweak.cpp
> +
> LINK_LIBS
> clangAST
> clangASTMatchers
> @@ -108,6 +110,7 @@ add_clang_library(clangDaemon
> ${CLANGD_ATOMIC_LIB}
> )
>   
> +add_subdirectory(refactor/tweaks)
>   if( LLVM_LIB_FUZZING_ENGINE OR LLVM_USE_SANITIZE_COVERAGE )
> add_subdirectory(fuzzer)
>   endif()
> 
> Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp?rev=352494&r1=352493&r2=352494&view=diff
> ==
> --- clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp (original)
> +++ clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp Tue Jan 29 06:17:36 
> 2019
> @@ -8,11 +8,14 @@
>   
>   #include "ClangdLSPServer.h"
>   #include "Diagnostics.h"
> +#include "Protocol.h"
>   #include "SourceCode.h"
>   #include "Trace.h"
>   #include "URI.h"
> +#include "clang/Tooling/Core/Replacement.h"
>   #include "llvm/ADT/ScopeExit.h"
>   #include "llvm/Support/Errc.h"
> +#include "llvm/Support/Error.h"
>   #include "llvm/Support/FormatVariadic.h"
>   #include "llvm/Support/Path.h"
>   #include "llvm/Support/ScopedPrinter.h"
> @@ -30,6 +33,28 @@ public:
> }
>   };
>   
> +/// Transforms a tweak into a code action that would apply it if executed.
> +/// EXPECTS: T.prepare() was called and returned true.
> +CodeAction toCodeAction(const ClangdServer::

Re: [clang-tools-extra] r352494 - [clangd] Interfaces for writing code tweaks

[Mikael Holmén via cfe-commits]

On 1/30/19 10:41 AM, Ilya Biryukov wrote:
> Should be fixed by r352612, let me know if it pops up again.
> This was a use after move, probably gcc and clang prefer different 
> evaluation order, hence the difference in behaviours.

Awesome! Now it passes also when I compile with gcc.

Thanks,
Mikael

> 
> On Wed, Jan 30, 2019 at 12:12 PM Ilya Biryukov  > wrote:
> 
> Hi Mikael,
> 
> I suspect an undefined value creeps in for protocol capabilities,
> given that we have responses in different formats.
> I'll investigate, thanks for the report!
> 
> On Wed, Jan 30, 2019 at 12:05 PM Mikael Holmén
> mailto:mikael.hol...@ericsson.com>> wrote:
> 
> Hi Ilya,
> 
> I've no idea why, but when I compile this commit with gcc
> (7.4.0) the
> test fixits-command.test fails, and the output from clangd is
> rather
> different from when I compile it with clang (3.6.0).
> 
> So I run
> 
> build-all/bin/clangd -lit-test <
> 
> /data/repo/master/llvm-master/tools/clang/tools/extra/test/clangd/fixits-command.test
> 
> and the first diff that I think is significant is that with gcc
> it says
> 
> E[09:44:29.470] error while getting semantic code actions: -32602:
> trying to get AST for non-added document
> 
> Before this patch the output from gcc and clang built clangd is
> identical.
> 
> Attaching logs with gcc and clang.
> 
> Any idea what the problem is?
> 
> Regards,
> Mikael
> 
> On 1/29/19 3:17 PM, Ilya Biryukov via cfe-commits wrote:
>  > Author: ibiryukov
>  > Date: Tue Jan 29 06:17:36 2019
>  > New Revision: 352494
>  >
>  > URL: http://llvm.org/viewvc/llvm-project?rev=352494&view=rev
>  > Log:
>  > [clangd] Interfaces for writing code tweaks
>  >
>  > Summary:
>  > The code tweaks are an implementation of mini-refactorings
> exposed
>  > via the LSP code actions. They run in two stages:
>  >    - Stage 1. Decides whether the action is available to the
> user and
>  >      collects all the information required to finish the action.
>  >      Should be cheap, since this will run over all the
> actions known to
>  >      clangd on each textDocument/codeAction request from the
> client.
>  >
>  >    - Stage 2. Uses information from stage 1 to produce the
> actual edits
>  >      that the code action should perform. This stage can be
> expensive and
>  >      will only run if the user chooses to perform the
> specified action in
>  >      the UI.
>  >
>  > One unfortunate consequence of this change is increased
> latency of
>  > processing the textDocument/codeAction requests, which now
> wait for an
>  > AST. However, we cannot avoid this with what we have
> available in the LSP
>  > today.
>  >
>  > Reviewers: kadircet, ioeric, hokein, sammccall
>  >
>  > Reviewed By: sammccall
>  >
>  > Subscribers: mgrang, mgorny, MaskRay, jkorous, arphaman,
> cfe-commits
>  >
>  > Differential Revision: https://reviews.llvm.org/D56267
>  >
>  > Added:
>  >      clang-tools-extra/trunk/clangd/refactor/
>  >      clang-tools-extra/trunk/clangd/refactor/Tweak.cpp
>  >      clang-tools-extra/trunk/clangd/refactor/Tweak.h
>  >      clang-tools-extra/trunk/clangd/refactor/tweaks/
>  > 
> clang-tools-extra/trunk/clangd/refactor/tweaks/CMakeLists.txt
>  >      clang-tools-extra/trunk/clangd/refactor/tweaks/Dummy.cpp
>  > Modified:
>  >      clang-tools-extra/trunk/clangd/CMakeLists.txt
>  >      clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
>  >      clang-tools-extra/trunk/clangd/ClangdServer.cpp
>  >      clang-tools-extra/trunk/clangd/ClangdServer.h
>  >      clang-tools-extra/trunk/clangd/Protocol.cpp
>  >      clang-tools-extra/trunk/clangd/Protocol.h
>  >      clang-tools-extra/trunk/clangd/SourceCode.cpp
>  >      clang-tools-extra/trunk/clangd/SourceCode.h
>  >      clang-tools-extra/trunk/clangd/tool/CMakeLists.txt
>  >      clang-tools-extra/trunk/test/clangd/fixits-command.test
>  >      clang-tools-extra/trunk/test/clangd/initialize-params.test
>  >
>  > Modified: clang-tools-extra/trunk/clangd/CMakeLists.txt
>  > URL:
> 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/CMakeLists.txt?rev=352494&r1=352493&r2=352494&view=diff
>  >
> 
> ==
>  > --- clang-

Re: [PATCH] D53651: [clangd] Use thread pool for background indexing.

[Mikael Holmén via cfe-commits]

Hi,

On 11/7/18 11:03 AM, Sam McCall wrote:
> On Wed, Nov 7, 2018 at 10:32 AM Mikael Holmén via Phabricator 
> mailto:revi...@reviews.llvm.org>> wrote:
> 
> uabelho added a comment.
> 
> Hi,
> 
> I've got a post-review comment about the use of SCHED_IDLE vs the
> needed gcc version.
> 
> 
> 
> 
> Comment at: clang-tools-extra/trunk/clangd/Threading.cpp:110
> +      T.native_handle(),
> +      Priority == ThreadPriority::Low ? SCHED_IDLE : SCHED_OTHER,
> &priority);
> +#endif
> 
> I noticed that when I compile this with gcc 5.4.0, I get a
> compilation error about SCHED_IDLE not being defined.
> Indeed, if I look in sched.h used with gcc 5.4.0, these are the
> SCHED_* definitions:
> 
> Sorry for the breakage here!
> 
> sched.h comes from glibc, rather than GCC.
> SCHED_IDLE was added in glibc 2.12, which is considerably older than any 
> supported compiler (2010, vs 2013 for gcc 4.8 and 2016 for gcc 5.4).
> 
> I don't think there's a documented policy on libc versions... what does 
> this system look like? (e.g. glibc version, distribution?)

Ok, we're apparently using glibc 2.11.3. A bit too old then :/

We're cross-compiling llvm using rather old gcc and glibc versions so 
that it will work on a number of different machines with different OS 
versions that our users have.

/Mikael

> 
> (It seems like it would be OK to #ifdef SCHED_IDLE here and do nothing 
> the libc is just too old, but it may mask other problems we'd want to 
> know about).
> 
> ```
> /* Scheduling algorithms.  */
> #define SCHED_OTHER     0
> #define SCHED_FIFO      1
> #define SCHED_RR        2
> #ifdef __USE_GNU
> # define SCHED_BATCH    3
> #endif
> ```
> I suppose SCHED_IDLE was added in some later version...
> 
> On
> 
> https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library
> it says that gcc 4.8 should work, but it doesn't now then?
> 
> 
> 
> Repository:
>    rL LLVM
> 
> https://reviews.llvm.org/D53651
> 
> 
> 

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

Re: [PATCH] D53651: [clangd] Use thread pool for background indexing.

[Mikael Holmén via cfe-commits]

On 11/7/18 11:31 AM, Sam McCall wrote:
> I'll send a patch shortly to unbreak this.
> 
> Is emitting a warning a problem for you? (i.e. do you build with -Werror)

Yes "unfortunately" we use -Werror.

> I'd like to do something like #ifdef SCHED_IDLE ... #else #warning "old 
> libc?" #endif
> That way if this isn't actually working we'll break in linux 
> configurations covered by -Werror bots, we'll notice.
> 

I can always remove the #warning locally if you want to give a warning 
about it but nicest for me would of course be if it was silent. :)

/Mikael

> On Wed, Nov 7, 2018 at 11:22 AM Mikael Holmén 
> mailto:mikael.hol...@ericsson.com>> wrote:
> 
> Hi,
> 
> On 11/7/18 11:03 AM, Sam McCall wrote:
>  > On Wed, Nov 7, 2018 at 10:32 AM Mikael Holmén via Phabricator
>  > mailto:revi...@reviews.llvm.org>
> >>
> wrote:
>  >
>  >     uabelho added a comment.
>  >
>  >     Hi,
>  >
>  >     I've got a post-review comment about the use of SCHED_IDLE vs the
>  >     needed gcc version.
>  >
>  >
>  >
>  >     
>  >     Comment at: clang-tools-extra/trunk/clangd/Threading.cpp:110
>  >     +      T.native_handle(),
>  >     +      Priority == ThreadPriority::Low ? SCHED_IDLE :
> SCHED_OTHER,
>  >     &priority);
>  >     +#endif
>  >     
>  >     I noticed that when I compile this with gcc 5.4.0, I get a
>  >     compilation error about SCHED_IDLE not being defined.
>  >     Indeed, if I look in sched.h used with gcc 5.4.0, these are the
>  >     SCHED_* definitions:
>  >
>  > Sorry for the breakage here!
>  >
>  > sched.h comes from glibc, rather than GCC.
>  > SCHED_IDLE was added in glibc 2.12, which is considerably older
> than any
>  > supported compiler (2010, vs 2013 for gcc 4.8 and 2016 for gcc 5.4).
>  >
>  > I don't think there's a documented policy on libc versions...
> what does
>  > this system look like? (e.g. glibc version, distribution?)
> 
> Ok, we're apparently using glibc 2.11.3. A bit too old then :/
> 
> We're cross-compiling llvm using rather old gcc and glibc versions so
> that it will work on a number of different machines with different OS
> versions that our users have.
> 
> /Mikael
> 
>  >
>  > (It seems like it would be OK to #ifdef SCHED_IDLE here and do
> nothing
>  > the libc is just too old, but it may mask other problems we'd
> want to
>  > know about).
>  >
>  >     ```
>  >     /* Scheduling algorithms.  */
>  >     #define SCHED_OTHER     0
>  >     #define SCHED_FIFO      1
>  >     #define SCHED_RR        2
>  >     #ifdef __USE_GNU
>  >     # define SCHED_BATCH    3
>  >     #endif
>  >     ```
>  >     I suppose SCHED_IDLE was added in some later version...
>  >
>  >     On
>  >
> 
> https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library
>  >     it says that gcc 4.8 should work, but it doesn't now then?
>  >
>  >
>  >
>  >     Repository:
>  >        rL LLVM
>  >
>  > https://reviews.llvm.org/D53651
>  >
>  >
>  >
> 

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

Re: r345099 - [analyzer] Trust summaries for OSObject::retain and OSObject::release

[Mikael Holmén via cfe-commits]

Hi George,

I noticed that valgrind started complaining in one case with this patch.

I've no idea if it's really due to something in the patch or if it's 
something old that surfaced or if it's a false flag.

Anyway, with this patch the following

  valgrind clang-tidy -checks='-*,clang-analyzer-*' 'memcpy.c' -- -O0

gives me

==18829== Memcheck, a memory error detector
==18829== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==18829== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==18829== Command: build-all/bin/clang-tidy -checks=-*,clang-analyzer-* 
memcpy.c -- -O0
==18829==
==18829== Conditional jump or move depends on uninitialised value(s)
==18829==at 0xE580DF: 
clang::ento::RetainSummaryManager::canEval(clang::CallExpr const*, 
clang::FunctionDecl const*, bool&) (in 
/data/repo/llvm-patch/build-all/bin/clang-tidy)
==18829==by 0xD034AA: 
clang::ento::retaincountchecker::RetainCountChecker::evalCall(clang::CallExpr 
const*, clang::ento::CheckerContext&) const (in 
/data/repo/llvm-patch/build-all/bin/clang-tidy)
==18829==by 0xDCBCD7: 
clang::ento::CheckerManager::runCheckersForEvalCall(clang::ento::ExplodedNodeSet&,
 
clang::ento::ExplodedNodeSet const&, clang::ento::CallEvent const&, 
clang::ento::ExprEngine&) (in 
/data/repo/llvm-patch/build-all/bin/clang-tidy)
==18829==by 0xE033D5: 
clang::ento::ExprEngine::evalCall(clang::ento::ExplodedNodeSet&, 
clang::ento::ExplodedNode*, clang::ento::CallEvent const&) (in 
/data/repo/llvm-patch/build-all/bin/clang-tidy)
==18829==by 0xE03165: 
clang::ento::ExprEngine::VisitCallExpr(clang::CallExpr const*, 
clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) (in 
/data/repo/llvm-patch/build-all/bin/clang-tidy)
==18829==by 0xDE3D9A: clang::ento::ExprEngine::Visit(clang::Stmt 
const*, clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) (in 
/data/repo/llvm-patch/build-all/bin/clang-tidy)
==18829==by 0xDDEFD1: 
clang::ento::ExprEngine::ProcessStmt(clang::Stmt const*, 
clang::ento::ExplodedNode*) (in 
/data/repo/llvm-patch/build-all/bin/clang-tidy)
==18829==by 0xDDEBBC: 
clang::ento::ExprEngine::processCFGElement(clang::CFGElement, 
clang::ento::ExplodedNode*, unsigned int, 
clang::ento::NodeBuilderContext*) (in 
/data/repo/llvm-patch/build-all/bin/clang-tidy)
==18829==by 0xDD3154: 
clang::ento::CoreEngine::HandlePostStmt(clang::CFGBlock const*, unsigned 
int, clang::ento::ExplodedNode*) (in 
/data/repo/llvm-patch/build-all/bin/clang-tidy)
==18829==by 0xDD24D3: 
clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*, 
unsigned int, llvm::IntrusiveRefCntPtr) 
(in /data/repo/llvm-patch/build-all/bin/clang-tidy)
==18829==by 0xB8E90E: (anonymous 
namespace)::AnalysisConsumer::HandleCode(clang::Decl*, unsigned int, 
clang::ento::ExprEngine::InliningModes, llvm::DenseSet >*) (in 
/data/repo/llvm-patch/build-all/bin/clang-tidy)
==18829==by 0xB89943: (anonymous 
namespace)::AnalysisConsumer::HandleTranslationUnit(clang::ASTContext&) 
(in /data/repo/llvm-patch/build-all/bin/clang-tidy)
==18829==

The call to

 const FunctionDecl* FDD = FD->getDefinition();

in RetainSummaryManager::canEval eventually ends up in

   bool isThisDeclarationADefinition() const {
 return isDeletedAsWritten() || isDefaulted() || Body || 
hasSkippedBody() ||
isLateTemplateParsed() || willHaveBody() || hasDefiningAttr();
   }

And here it seems to be the access of "Body" that valgrind complains on. 
If I simply comment out "Body" the complaint is gone.

I really have no clue about this code, but perhaps this makes some sense 
to you? Or perhaps to someone else?

Regards,
Mikael

On 10/24/18 1:11 AM, George Karpenkov via cfe-commits wrote:
> Author: george.karpenkov
> Date: Tue Oct 23 16:11:30 2018
> New Revision: 345099
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=345099&view=rev
> Log:
> [analyzer] Trust summaries for OSObject::retain and OSObject::release
> 
> Refactor the way in which summaries are consumed for safeMetaCast
> 
> Differential Revision: https://reviews.llvm.org/D53549
> 
> Modified:
>  
> cfe/trunk/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountChecker.cpp
>  cfe/trunk/lib/StaticAnalyzer/Core/RetainSummaryManager.cpp
>  cfe/trunk/test/Analysis/osobject-retain-release.cpp
> 
> Modified: 
> cfe/trunk/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountChecker.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountChecker.cpp?rev=345099&r1=345098&r2=345099&view=diff
> ==
> --- 
> cfe/trunk/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountChecker.cpp
>  (original)
> +++ 
> cfe/trunk/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountChecker.cpp
>  Tue Oct 23 16:11:30 2018
> @@ -776,31 +776,27 @@ bool RetainCountChecker::evalCall(const
>   
> const LocationContext 

Re: [clang-tools-extra] r347498 - [clangd] Add support for hierarchical documentSymbol

[Mikael Holmén via cfe-commits]

Hi Ilya,

This patch doesn't compile for me with clang 3.6.0. I get:

../tools/clang/tools/extra/clangd/Protocol.cpp:474:10: error: no viable 
conversion from 'json::Object' to 'llvm::json::Value'
   return Result;
  ^~
../include/llvm/Support/JSON.h:291:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'const 
llvm::json::Value &' for 1st argument
   Value(const Value &M) { copyFrom(M); }
   ^
../include/llvm/Support/JSON.h:292:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'llvm::json::Value 
&&' for 1st argument
   Value(Value &&M) { moveFrom(std::move(M)); }
   ^
../include/llvm/Support/JSON.h:293:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 
'std::initializer_list' for 1st argument
   Value(std::initializer_list Elements);
   ^
../include/llvm/Support/JSON.h:294:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'json::Array &&' for 
1st argument
   Value(json::Array &&Elements) : Type(T_Array) {
   ^
../include/llvm/Support/JSON.h:299:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'json::Object &&' for 
1st argument
   Value(json::Object &&Properties) : Type(T_Object) {
   ^
../include/llvm/Support/JSON.h:305:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'std::string' (aka 
'basic_string') for 1st argument
   Value(std::string V) : Type(T_String) {
   ^
../include/llvm/Support/JSON.h:312:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'const 
llvm::SmallVectorImpl &' for 1st argument
   Value(const llvm::SmallVectorImpl &V)
   ^
../include/llvm/Support/JSON.h:314:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'const 
llvm::formatv_object_base &' for 1st argument
   Value(const llvm::formatv_object_base &V) : Value(V.str()){};
   ^
../include/llvm/Support/JSON.h:316:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'llvm::StringRef' for 
1st argument
   Value(StringRef V) : Type(T_StringRef) {
   ^
../include/llvm/Support/JSON.h:323:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'const char *' for 
1st argument
   Value(const char *V) : Value(StringRef(V)) {}
   ^
../include/llvm/Support/JSON.h:324:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'std::nullptr_t' (aka 
'nullptr_t') for 1st argument
   Value(std::nullptr_t) : Type(T_Null) {}
   ^
../include/llvm/Support/JSON.h:298:3: note: candidate template ignored: 
could not match 'vector >' against 'llvm::json::Object'
   Value(const std::vector &C) : Value(json::Array(C)) {}
   ^
../include/llvm/Support/JSON.h:303:3: note: candidate template ignored: 
could not match 'map, type-parameter-0-0, 
std::less >, allocator, type-parameter-0-0> > >' against 
'llvm::json::Object'
   Value(const std::map &C) : Value(json::Object(C)) {}
   ^
../include/llvm/Support/JSON.h:329:42: note: candidate template ignored: 
disabled by 'enable_if' [with T = llvm::json::Object]
   typename = typename std::enable_if::value>::type,
  ^
../include/llvm/Support/JSON.h:337:42: note: candidate template ignored: 
disabled by 'enable_if' [with T = llvm::json::Object]
   typename = typename std::enable_if::value>::type,
  ^
../include/llvm/Support/JSON.h:345:41: note: candidate template ignored: 
disabled by 'enable_if' [with T = llvm::json::Object]
 typename 
std::enable_if::value>::type,
 ^
../include/llvm/Support/JSON.h:355:3: note: candidate template ignored: 
substitution failure [with T = llvm::json::Object]: no matching function 
for call to 'toJSON'
   Value(const T &V) : Value(toJSON(V)) {}
   ^
1 error generated.
ninja: build stopped: subcommand failed.
system(/proj/flexasic/app/ninja/1.8.2/SLED11-64/bin/ninja -j1 -C 
build-all  all) failed: child exited with value 1


A couple of the build bots fail the same way, see e.g:

 
http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/5512/steps/build%20stage%201/logs/stdio


-


This patch also causes a couple of new warnings:

../tools/clang/tools/extra/clangd/AST.cpp:98:13: error: unused variable 
'NS' [-Werror,-Wunused-variable]
   if (auto *NS = llvm::dyn_cast(&ND))
 ^
../tools/clang/tools/extra/clangd/AST.cpp:102:13: error: unused variable 
'En' [-Werror,-Wunused-variable]
   if (auto *En = llvm::dyn_cast(&ND))
 ^
2 errors generated.

/Mikael

On 11/23/18 4:21 PM, Ilya Biryukov via cfe-commits wrote:
> Author: ibiryukov
> Date: Fri Nov 23 07:21:19 2018
> New Revision: 347498
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=347498&view=rev
> Log:
> [clangd] Add support for hierarchical documentSym

Re: r345099 - [analyzer] Trust summaries for OSObject::retain and OSObject::release

[Mikael Holmén via cfe-commits]

Hi again,

Do you have any opinion about the below valgrind complaint that starts 
appearing with this patch?

valgrind still complains on it on current trunk.

I see it when compiling with clang 3.6.0. I've also tried gcc 5.4.0 but 
then I don't get it.

Regards,
Mikael

On 11/21/18 8:33 AM, Mikael Holmén via cfe-commits wrote:
> Hi George,
> 
> I noticed that valgrind started complaining in one case with this patch.
> 
> I've no idea if it's really due to something in the patch or if it's
> something old that surfaced or if it's a false flag.
> 
> Anyway, with this patch the following
> 
>valgrind clang-tidy -checks='-*,clang-analyzer-*' 'memcpy.c' -- -O0
> 
> gives me
> 
> ==18829== Memcheck, a memory error detector
> ==18829== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==18829== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
> ==18829== Command: build-all/bin/clang-tidy -checks=-*,clang-analyzer-*
> memcpy.c -- -O0
> ==18829==
> ==18829== Conditional jump or move depends on uninitialised value(s)
> ==18829==at 0xE580DF:
> clang::ento::RetainSummaryManager::canEval(clang::CallExpr const*,
> clang::FunctionDecl const*, bool&) (in
> /data/repo/llvm-patch/build-all/bin/clang-tidy)
> ==18829==by 0xD034AA:
> clang::ento::retaincountchecker::RetainCountChecker::evalCall(clang::CallExpr
> const*, clang::ento::CheckerContext&) const (in
> /data/repo/llvm-patch/build-all/bin/clang-tidy)
> ==18829==by 0xDCBCD7:
> clang::ento::CheckerManager::runCheckersForEvalCall(clang::ento::ExplodedNodeSet&,
> clang::ento::ExplodedNodeSet const&, clang::ento::CallEvent const&,
> clang::ento::ExprEngine&) (in
> /data/repo/llvm-patch/build-all/bin/clang-tidy)
> ==18829==by 0xE033D5:
> clang::ento::ExprEngine::evalCall(clang::ento::ExplodedNodeSet&,
> clang::ento::ExplodedNode*, clang::ento::CallEvent const&) (in
> /data/repo/llvm-patch/build-all/bin/clang-tidy)
> ==18829==by 0xE03165:
> clang::ento::ExprEngine::VisitCallExpr(clang::CallExpr const*,
> clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) (in
> /data/repo/llvm-patch/build-all/bin/clang-tidy)
> ==18829==by 0xDE3D9A: clang::ento::ExprEngine::Visit(clang::Stmt
> const*, clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) (in
> /data/repo/llvm-patch/build-all/bin/clang-tidy)
> ==18829==by 0xDDEFD1:
> clang::ento::ExprEngine::ProcessStmt(clang::Stmt const*,
> clang::ento::ExplodedNode*) (in
> /data/repo/llvm-patch/build-all/bin/clang-tidy)
> ==18829==by 0xDDEBBC:
> clang::ento::ExprEngine::processCFGElement(clang::CFGElement,
> clang::ento::ExplodedNode*, unsigned int,
> clang::ento::NodeBuilderContext*) (in
> /data/repo/llvm-patch/build-all/bin/clang-tidy)
> ==18829==by 0xDD3154:
> clang::ento::CoreEngine::HandlePostStmt(clang::CFGBlock const*, unsigned
> int, clang::ento::ExplodedNode*) (in
> /data/repo/llvm-patch/build-all/bin/clang-tidy)
> ==18829==by 0xDD24D3:
> clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*,
> unsigned int, llvm::IntrusiveRefCntPtr)
> (in /data/repo/llvm-patch/build-all/bin/clang-tidy)
> ==18829==by 0xB8E90E: (anonymous
> namespace)::AnalysisConsumer::HandleCode(clang::Decl*, unsigned int,
> clang::ento::ExprEngine::InliningModes, llvm::DenseSet const*, llvm::DenseMapInfo >*) (in
> /data/repo/llvm-patch/build-all/bin/clang-tidy)
> ==18829==by 0xB89943: (anonymous
> namespace)::AnalysisConsumer::HandleTranslationUnit(clang::ASTContext&)
> (in /data/repo/llvm-patch/build-all/bin/clang-tidy)
> ==18829==
> 
> The call to
> 
>   const FunctionDecl* FDD = FD->getDefinition();
> 
> in RetainSummaryManager::canEval eventually ends up in
> 
> bool isThisDeclarationADefinition() const {
>   return isDeletedAsWritten() || isDefaulted() || Body ||
> hasSkippedBody() ||
>  isLateTemplateParsed() || willHaveBody() || hasDefiningAttr();
> }
> 
> And here it seems to be the access of "Body" that valgrind complains on.
> If I simply comment out "Body" the complaint is gone.
> 
> I really have no clue about this code, but perhaps this makes some sense
> to you? Or perhaps to someone else?
> 
> Regards,
> Mikael
> 
> On 10/24/18 1:11 AM, George Karpenkov via cfe-commits wrote:
>> Author: george.karpenkov
>> Date: Tue Oct 23 16:11:30 2018
>> New Revision: 345099
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=345099&view=rev
>> Log:
>> [analyzer] Trust summaries for OSObject::retain and OSObject::release
>>
>> Refactor the way in which summaries are consu

Re: [clang-tools-extra] r347498 - [clangd] Add support for hierarchical documentSymbol

[Mikael Holmén via cfe-commits]

On 11/26/18 12:41 PM, Ilya Biryukov wrote:
> Sorry about that, should be fixed in r347539.
> 

Yep, thanks!

/Mikael

> On Mon, Nov 26, 2018 at 8:10 AM Mikael Holmén 
> mailto:mikael.hol...@ericsson.com>> wrote:
> 
> Hi Ilya,
> 
> This patch doesn't compile for me with clang 3.6.0. I get:
> 
> ../tools/clang/tools/extra/clangd/Protocol.cpp:474:10: error: no viable
> conversion from 'json::Object' to 'llvm::json::Value'
>     return Result;
>            ^~
> ../include/llvm/Support/JSON.h:291:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'const
> llvm::json::Value &' for 1st argument
>     Value(const Value &M) { copyFrom(M); }
>     ^
> ../include/llvm/Support/JSON.h:292:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'llvm::json::Value
> &&' for 1st argument
>     Value(Value &&M) { moveFrom(std::move(M)); }
>     ^
> ../include/llvm/Support/JSON.h:293:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to
> 'std::initializer_list' for 1st argument
>     Value(std::initializer_list Elements);
>     ^
> ../include/llvm/Support/JSON.h:294:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'json::Array &&' for
> 1st argument
>     Value(json::Array &&Elements) : Type(T_Array) {
>     ^
> ../include/llvm/Support/JSON.h:299:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'json::Object &&'
> for
> 1st argument
>     Value(json::Object &&Properties) : Type(T_Object) {
>     ^
> ../include/llvm/Support/JSON.h:305:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'std::string' (aka
> 'basic_string') for 1st argument
>     Value(std::string V) : Type(T_String) {
>     ^
> ../include/llvm/Support/JSON.h:312:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'const
> llvm::SmallVectorImpl &' for 1st argument
>     Value(const llvm::SmallVectorImpl &V)
>     ^
> ../include/llvm/Support/JSON.h:314:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'const
> llvm::formatv_object_base &' for 1st argument
>     Value(const llvm::formatv_object_base &V) : Value(V.str()){};
>     ^
> ../include/llvm/Support/JSON.h:316:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'llvm::StringRef'
> for
> 1st argument
>     Value(StringRef V) : Type(T_StringRef) {
>     ^
> ../include/llvm/Support/JSON.h:323:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'const char *' for
> 1st argument
>     Value(const char *V) : Value(StringRef(V)) {}
>     ^
> ../include/llvm/Support/JSON.h:324:3: note: candidate constructor not
> viable: no known conversion from 'json::Object' to 'std::nullptr_t'
> (aka
> 'nullptr_t') for 1st argument
>     Value(std::nullptr_t) : Type(T_Null) {}
>     ^
> ../include/llvm/Support/JSON.h:298:3: note: candidate template ignored:
> could not match 'vector allocator >' against 'llvm::json::Object'
>     Value(const std::vector &C) : Value(json::Array(C)) {}
>     ^
> ../include/llvm/Support/JSON.h:303:3: note: candidate template ignored:
> could not match 'map, type-parameter-0-0,
> std::less >, allocator std::basic_string, type-parameter-0-0> > >' against
> 'llvm::json::Object'
>     Value(const std::map &C) :
> Value(json::Object(C)) {}
>     ^
> ../include/llvm/Support/JSON.h:329:42: note: candidate template
> ignored:
> disabled by 'enable_if' [with T = llvm::json::Object]
>         typename = typename std::enable_if bool>::value>::type,
>                                            ^
> ../include/llvm/Support/JSON.h:337:42: note: candidate template
> ignored:
> disabled by 'enable_if' [with T = llvm::json::Object]
>         typename = typename
> std::enable_if::value>::type,
>                                            ^
> ../include/llvm/Support/JSON.h:345:41: note: candidate template
> ignored:
> disabled by 'enable_if' [with T = llvm::json::Object]
>                   typename
> std::enable_if::value>::type,
>                                           ^
> ../include/llvm/Support/JSON.h:355:3: note: candidate template ignored:
> substitution failure [with T = llvm::json::Object]: no matching
> function
> for call to 'toJSON'
>     Value(const T &V) : Value(toJSON(V)) {}
>     ^
> 1 error generated.
> ninja: build stopped: subcommand failed.
> system(/proj/flexasic/app/ninja/1.8.2/SLED11-64/bin/ninja -j1 -C
> build-all  

Re: [clang-tools-extra] r347675 - [clangd] textDocument/SymbolInfo extension

[Mikael Holmén via cfe-commits]

Hi Jan,

This code doesn't compile with clang 3.6.0:

../tools/clang/tools/extra/clangd/Protocol.cpp:456:10: error: no viable 
conversion from 'json::Object' to 'llvm::json::Value'
   return result;
  ^~
../include/llvm/Support/JSON.h:291:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'const 
llvm::json::Value &' for 1st argument
   Value(const Value &M) { copyFrom(M); }
   ^
../include/llvm/Support/JSON.h:292:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'llvm::json::Value 
&&' for 1st argument
   Value(Value &&M) { moveFrom(std::move(M)); }
   ^
../include/llvm/Support/JSON.h:293:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 
'std::initializer_list' for 1st argument
   Value(std::initializer_list Elements);
   ^
../include/llvm/Support/JSON.h:294:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'json::Array &&' for 
1st argument
   Value(json::Array &&Elements) : Type(T_Array) {
   ^
../include/llvm/Support/JSON.h:299:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'json::Object &&' for 
1st argument
   Value(json::Object &&Properties) : Type(T_Object) {
   ^
../include/llvm/Support/JSON.h:305:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'std::string' (aka 
'basic_string') for 1st argument
   Value(std::string V) : Type(T_String) {
   ^
../include/llvm/Support/JSON.h:312:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'const 
llvm::SmallVectorImpl &' for 1st argument
   Value(const llvm::SmallVectorImpl &V)
   ^
../include/llvm/Support/JSON.h:314:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'const 
llvm::formatv_object_base &' for 1st argument
   Value(const llvm::formatv_object_base &V) : Value(V.str()){};
   ^
../include/llvm/Support/JSON.h:316:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'llvm::StringRef' for 
1st argument
   Value(StringRef V) : Type(T_StringRef) {
   ^
../include/llvm/Support/JSON.h:323:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'const char *' for 
1st argument
   Value(const char *V) : Value(StringRef(V)) {}
   ^
../include/llvm/Support/JSON.h:324:3: note: candidate constructor not 
viable: no known conversion from 'json::Object' to 'std::nullptr_t' (aka 
'nullptr_t') for 1st argument
   Value(std::nullptr_t) : Type(T_Null) {}
   ^
../include/llvm/Support/JSON.h:298:3: note: candidate template ignored: 
could not match 'vector >' against 'llvm::json::Object'
   Value(const std::vector &C) : Value(json::Array(C)) {}
   ^
../include/llvm/Support/JSON.h:303:3: note: candidate template ignored: 
could not match 'map, type-parameter-0-0, 
std::less >, allocator, type-parameter-0-0> > >' against 
'llvm::json::Object'
   Value(const std::map &C) : Value(json::Object(C)) {}
   ^
../include/llvm/Support/JSON.h:329:42: note: candidate template ignored: 
disabled by 'enable_if' [with T = llvm::json::Object]
   typename = typename std::enable_if::value>::type,
  ^
../include/llvm/Support/JSON.h:337:42: note: candidate template ignored: 
disabled by 'enable_if' [with T = llvm::json::Object]
   typename = typename std::enable_if::value>::type,
  ^
../include/llvm/Support/JSON.h:345:41: note: candidate template ignored: 
disabled by 'enable_if' [with T = llvm::json::Object]
 typename 
std::enable_if::value>::type,
 ^
../include/llvm/Support/JSON.h:355:3: note: candidate template ignored: 
substitution failure [with T = llvm::json::Object]: no matching function 
for call to 'toJSON'
   Value(const T &V) : Value(toJSON(V)) {}
   ^
1 error generated.

---

It looks very similar to a problem that was fixed in r347539:

-  return Result;
+  // Older gcc cannot compile 'return Result', even though it is legal.
+  return json::Value(std::move(Result));

Regards,
Mikael

On 11/27/18 5:40 PM, Jan Korous via cfe-commits wrote:
> Author: jkorous
> Date: Tue Nov 27 08:40:46 2018
> New Revision: 347675
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=347675&view=rev
> Log:
> [clangd] textDocument/SymbolInfo extension
> 
> New method returning symbol info for given source position.
> 
> Differential Revision: https://reviews.llvm.org/D54799
> 
> rdar://problem/46050281
> 
> Added:
>  clang-tools-extra/trunk/test/clangd/symbol-info.test
>  clang-tools-extra/trunk/unittests/clangd/SymbolInfoTests.cpp
> Modified:
>  clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
>  clang-tools-extra/trunk/clangd/ClangdLSPServer.h
>  clang-tools-extra/trunk/clangd/ClangdServer.cpp
>  clang-tools-extra/trunk/clangd/ClangdServer.h
>  clang-tools-e

Re: r345099 - [analyzer] Trust summaries for OSObject::retain and OSObject::release

[Mikael Holmén via cfe-commits]

licy)2>'
warning: RTTI symbol not found for class 
'std::_Sp_counted_deleter, std::allocator, 
(__gnu_cxx::_Lock_policy)2>'
std::shared_ptr (count 2, weak 0) 0x644f910, Files=0x64529a0, 
PCHContainerOps=warning: RTTI symbol not found for class 
'std::_Sp_counted_deleter::_Deleter
 
 >, std::allocator, 
(__gnu_cxx::_Lock_policy)2>'
warning: RTTI symbol not found for class 
'std::_Sp_counted_deleter::_Deleter
 
 >, std::allocator, 
(__gnu_cxx::_Lock_policy)2>'
std::shared_ptr (count 3, weak 0) 0x644a270, 
DiagConsumer=0x7fffcb00) at 
../tools/clang/tools/extra/clang-tidy/ClangTidy.cpp:572
#30 0x018aa317 in clang::tooling::ToolInvocation::runInvocation 
(this=0x7fffc288, BinaryName=0x6440088 "clang-tool", 
Compilation=0x644eb80, Invocation=std::shared_ptr (empty) 0x0, 
PCHContainerOps=std::shared_ptr (empty) 0x0) at 
../tools/clang/lib/Tooling/Tooling.cpp:345
#31 0x018a8a59 in clang::tooling::ToolInvocation::run 
(this=0x7fffc288) at ../tools/clang/lib/Tooling/Tooling.cpp:330
#32 0x018ab924 in clang::tooling::ClangTool::run 
(this=0x7fffcc10, Action=0x7fffc760) at 
../tools/clang/lib/Tooling/Tooling.cpp:519
#33 0x0115d517 in clang::tidy::runClangTidy (Context=..., 
Compilations=..., InputFiles=llvm::ArrayRef of length 1 = {...}, 
BaseFS=..., EnableCheckProfile=false, StoreCheckProfile="") at 
../tools/clang/tools/extra/clang-tidy/ClangTidy.cpp:593
#34 0x0047a29f in clang::tidy::clangTidyMain (argc=3, 
argv=0x7fffda98) at 
../tools/clang/tools/extra/clang-tidy/tool/ClangTidyMain.cpp:428
#35 0x004796c2 in main (argc=5, argv=0x7fffda98) at 
../tools/clang/tools/extra/clang-tidy/tool/ClangTidyMain.cpp:581

/Mikael

> 
> Thanks,
> George
> 
>> On Nov 26, 2018, at 12:03 AM, Mikael Holmén 
>> mailto:mikael.hol...@ericsson.com>> wrote:
>>
>> Hi again,
>>
>> Do you have any opinion about the below valgrind complaint that starts
>> appearing with this patch?
>>
>> valgrind still complains on it on current trunk.
>>
>> I see it when compiling with clang 3.6.0. I've also tried gcc 5.4.0 but
>> then I don't get it.
>>
>> Regards,
>> Mikael
>>
>> On 11/21/18 8:33 AM, Mikael Holmén via cfe-commits wrote:
>>> Hi George,
>>>
>>> I noticed that valgrind started complaining in one case with this patch.
>>>
>>> I've no idea if it's really due to something in the patch or if it's
>>> something old that surfaced or if it's a false flag.
>>>
>>> Anyway, with this patch the following
>>>
>>>   valgrind clang-tidy -checks='-*,clang-analyzer-*' 'memcpy.c' -- -O0
>>>
>>> gives me
>>>
>>> ==18829== Memcheck, a memory error detector
>>> ==18829== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
>>> ==18829== Using Valgrind-3.10.1 and LibVEX; rerun with -h for 
>>> copyright info
>>> ==18829== Command: build-all/bin/clang-tidy -checks=-*,clang-analyzer-*
>>> memcpy.c -- -O0
>>> ==18829==
>>> ==18829== Conditional jump or move depends on uninitialised value(s)
>>> ==18829==    at 0xE580DF:
>>> clang::ento::RetainSummaryManager::canEval(clang::CallExpr const*,
>>> clang::FunctionDecl const*, bool&) (in
>>> /data/repo/llvm-patch/build-all/bin/clang-tidy)
>>> ==18829==    by 0xD034AA:
>>> clang::ento::retaincountchecker::RetainCountChecker::evalCall(clang::CallExpr
>>> const*, clang::ento::CheckerContext&) const (in
>>> /data/repo/llvm-patch/build-all/bin/clang-tidy)
>>> ==18829==    by 0xDCBCD7:
>>> clang::ento::CheckerManager::runCheckersForEvalCall(clang::ento::ExplodedNodeSet&,
>>> clang::ento::ExplodedNodeSet const&, clang::ento::CallEvent const&,
>>> clang::ento::ExprEngine&) (in
>>> /data/repo/llvm-patch/build-all/bin/clang-tidy)
>>> ==18829==    by 0xE033D5:
>>> clang::ento::ExprEngine::evalCall(clang::ento::ExplodedNodeSet&,
>>> clang::ento::ExplodedNode*, clang::ento::CallEvent const&) (in
>>> /data/repo/llvm-patch/build-all/bin/clang-tidy)
>>> ==18829==    by 0xE03165:
>>> clang::ento::ExprEngine::VisitCallExpr(clang::CallExpr const*,
>>> clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) (in
>>> /data/repo/llvm-patch/build-all/bin/clang-tidy)
>>> ==18829==    by 0xDE3D9A: clang::ento::ExprEngine::Visit(clang::Stmt
>>> const*, clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) (in
>>> /data/repo/llvm-patch/build-all/bin/clang-tidy)
>>> ==18

Re: [clang-tools-extra] r347675 - [clangd] textDocument/SymbolInfo extension

[Mikael Holmén via cfe-commits]

On 11/28/18 11:09 AM, Jan Korous wrote:
> Thanks for the notice and sorry for the delay! I somehow missed the 
> failure mails before I went offline yesterday.
> 
> I am just running tests on my fix now and hopefully pushing shortly.
> 
> Since I didn’t know we are using old compilers for these builds I am now 
> curious why. Is that intentional? For backward-compatibility?

I can't speak for the ARM bots, but I myself is doing my development on 
ubuntu 14.04 and there I get clang 3.6.0.

And

https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library

suggests that even clang 3.1 should work.

/Mikael

> 
> Thanks.
> 
> Jan
> 
>> On Nov 28, 2018, at 8:59 AM, Yvan Roux > <mailto:yvan.r...@linaro.org>> wrote:
>>
>> On Wed, 28 Nov 2018 at 09:56, Mikael Holmén via cfe-commits
>> mailto:cfe-commits@lists.llvm.org>> wrote:
>>>
>>> Hi Jan,
>>>
>>> This code doesn't compile with clang 3.6.0:
>>
>> And broke ARM bots, logs available here:
>>
>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/5582/steps/build%20stage%201/logs/stdio
>>
>> Cheers,
>> Yvan
>>
>>> ../tools/clang/tools/extra/clangd/Protocol.cpp:456:10: error: no viable
>>> conversion from 'json::Object' to 'llvm::json::Value'
>>>   return result;
>>>  ^~
>>> ../include/llvm/Support/JSON.h:291:3: note: candidate constructor not
>>> viable: no known conversion from 'json::Object' to 'const
>>> llvm::json::Value &' for 1st argument
>>>   Value(const Value &M) { copyFrom(M); }
>>>   ^
>>> ../include/llvm/Support/JSON.h:292:3: note: candidate constructor not
>>> viable: no known conversion from 'json::Object' to 'llvm::json::Value
>>> &&' for 1st argument
>>>   Value(Value &&M) { moveFrom(std::move(M)); }
>>>   ^
>>> ../include/llvm/Support/JSON.h:293:3: note: candidate constructor not
>>> viable: no known conversion from 'json::Object' to
>>> 'std::initializer_list' for 1st argument
>>>   Value(std::initializer_list Elements);
>>>   ^
>>> ../include/llvm/Support/JSON.h:294:3: note: candidate constructor not
>>> viable: no known conversion from 'json::Object' to 'json::Array &&' for
>>> 1st argument
>>>   Value(json::Array &&Elements) : Type(T_Array) {
>>>   ^
>>> ../include/llvm/Support/JSON.h:299:3: note: candidate constructor not
>>> viable: no known conversion from 'json::Object' to 'json::Object &&' for
>>> 1st argument
>>>   Value(json::Object &&Properties) : Type(T_Object) {
>>>   ^
>>> ../include/llvm/Support/JSON.h:305:3: note: candidate constructor not
>>> viable: no known conversion from 'json::Object' to 'std::string' (aka
>>> 'basic_string') for 1st argument
>>>   Value(std::string V) : Type(T_String) {
>>>   ^
>>> ../include/llvm/Support/JSON.h:312:3: note: candidate constructor not
>>> viable: no known conversion from 'json::Object' to 'const
>>> llvm::SmallVectorImpl &' for 1st argument
>>>   Value(const llvm::SmallVectorImpl &V)
>>>   ^
>>> ../include/llvm/Support/JSON.h:314:3: note: candidate constructor not
>>> viable: no known conversion from 'json::Object' to 'const
>>> llvm::formatv_object_base &' for 1st argument
>>>   Value(const llvm::formatv_object_base &V) : Value(V.str()){};
>>>   ^
>>> ../include/llvm/Support/JSON.h:316:3: note: candidate constructor not
>>> viable: no known conversion from 'json::Object' to 'llvm::StringRef' for
>>> 1st argument
>>>   Value(StringRef V) : Type(T_StringRef) {
>>>   ^
>>> ../include/llvm/Support/JSON.h:323:3: note: candidate constructor not
>>> viable: no known conversion from 'json::Object' to 'const char *' for
>>> 1st argument
>>>   Value(const char *V) : Value(StringRef(V)) {}
>>>   ^
>>> ../include/llvm/Support/JSON.h:324:3: note: candidate constructor not
>>> viable: no known conversion from 'json::Object' to 'std::nullptr_t' (aka
>>> 'nullptr_t') for 1st argument
>>>   Value(std::nullptr_t) : Type(T_Null) {}
>>>   ^
>>> ../include/llvm/Support/JSON.h:298:3: note: candidate template ignored:
>>

Re: r348276 - [AST][NFC] Make ArrayTypeTraitExpr non polymorphic

[Mikael Holmén via cfe-commits]

Hi Bruno,

I've no idea if this is really related to your change, but with this 
commit, the following starts crashing:

clang-tidy -allow-enabling-analyzer-alpha-checkers 
-checks='-*,clang-analyzer-*' ./reduced.c --

It seems like it recurses forever for some reason, and then we run out 
of stack and it crashes:

elxhw7c132-n7[llvm]: build-all-bbigcc/bin/clang-tidy 
-allow-enabling-analyzer-alpha-checkers -checks='-*,clang-analyzer-*' 
./reduced.c --
#0 0x0074fbda llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
(build-all-bbigcc/bin/clang-tidy+0x74fbda)
#1 0x0074e0aa llvm::sys::RunSignalHandlers() 
(build-all-bbigcc/bin/clang-tidy+0x74e0aa)
#2 0x0074e1d7 SignalHandler(int) 
(build-all-bbigcc/bin/clang-tidy+0x74e1d7)
#3 0x7f6cd7f84330 __restore_rt 
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#4 0x00f06c63 clang::StmtVisitorBase::Visit(clang::Stmt*) (build-all-bbigcc/bin/clang-tidy+0xf06c63)
#5 0x00f0a282 (anonymous 
namespace)::StringRefCheckerVisitor::VisitChildren(clang::Stmt*) 
(build-all-bbigcc/bin/clang-tidy+0xf0a282)
#6 0x00f0527f clang::StmtVisitorBase::Visit(clang::Stmt*) (.part.132) 
(build-all-bbigcc/bin/clang-tidy+0xf0527f)
#7 0x00f06c68 clang::StmtVisitorBase::Visit(clang::Stmt*) (build-all-bbigcc/bin/clang-tidy+0xf06c68)
#8 0x00f0a282 (anonymous 
namespace)::StringRefCheckerVisitor::VisitChildren(clang::Stmt*) 
(build-all-bbigcc/bin/clang-tidy+0xf0a282)
#9 0x00f03fcf clang::StmtVisitorBase::Visit(clang::Stmt*) (.part.132) 
(build-all-bbigcc/bin/clang-tidy+0xf03fcf)
#10 0x00f06c68 clang::StmtVisitorBase::Visit(clang::Stmt*) (build-all-bbigcc/bin/clang-tidy+0xf06c68)
#11 0x00f0a282 (anonymous 
namespace)::StringRefCheckerVisitor::VisitChildren(clang::Stmt*) 
(build-all-bbigcc/bin/clang-tidy+0xf0a282)
#12 0x00f03fcf clang::StmtVisitorBase::Visit(clang::Stmt*) (.part.132) 
(build-all-bbigcc/bin/clang-tidy+0xf03fcf)
#13 0x00f06c68 clang::StmtVisitorBase::Visit(clang::Stmt*) (build-all-bbigcc/bin/clang-tidy+0xf06c68)
#14 0x00f0a282 (anonymous 
namespace)::StringRefCheckerVisitor::VisitChildren(clang::Stmt*) 
(build-all-bbigcc/bin/clang-tidy+0xf0a282)
#15 0x00f03fcf clang::StmtVisitorBase::Visit(clang::Stmt*) (.part.132) 
(build-all-bbigcc/bin/clang-tidy+0xf03fcf)

etc

I've only seen this when I compile clang-tidy with gcc 5.4.0, assertions 
on, with optimizations. Simply turning on debug info when compiling 
clang-tidy makes the crash go away so it's quite fragile.

Regards,
Mikael

On 12/4/18 5:01 PM, Bruno Ricci via cfe-commits wrote:
> Author: brunoricci
> Date: Tue Dec  4 08:01:24 2018
> New Revision: 348276
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=348276&view=rev
> Log:
> [AST][NFC] Make ArrayTypeTraitExpr non polymorphic
> 
> ArrayTypeTraitExpr is the only expression class which is polymorphic.
> As far as I can tell this is completely pointless.
> 
> Differential Revision: https://reviews.llvm.org/D55221
> 
> Reviewed By: aaron.ballman
> 
> 
> Modified:
>  cfe/trunk/include/clang/AST/ExprCXX.h
>  cfe/trunk/lib/AST/ExprCXX.cpp
> 
> Modified: cfe/trunk/include/clang/AST/ExprCXX.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ExprCXX.h?rev=348276&r1=348275&r2=348276&view=diff
> ==
> --- cfe/trunk/include/clang/AST/ExprCXX.h (original)
> +++ cfe/trunk/include/clang/AST/ExprCXX.h Tue Dec  4 08:01:24 2018
> @@ -2455,8 +2455,6 @@ class ArrayTypeTraitExpr : public Expr {
> /// The type being queried.
> TypeSourceInfo *QueriedType = nullptr;
>   
> -  virtual void anchor();
> -
>   public:
> friend class ASTStmtReader;
>   
> @@ -2474,8 +2472,6 @@ public:
> explicit ArrayTypeTraitExpr(EmptyShell Empty)
> : Expr(ArrayTypeTraitExprClass, Empty), ATT(0) {}
>   
> -  virtual ~ArrayTypeTraitExpr() = default;
> -
> SourceLocation getBeginLoc() const LLVM_READONLY { return Loc; }
> SourceLocation getEndLoc() const LLVM_READONLY { return RParen; }
>   
> 
> Modified: cfe/trunk/lib/AST/ExprCXX.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprCXX.cpp?rev=348276&r1=348275&r2=348276&view=diff
> ==
> --- cfe/trunk/lib/AST/ExprCXX.cpp (original)
> +++ cfe/trunk/lib/AST/ExprCXX.cpp Tue Dec  4 08:01:24 2018
> @@ -1443,5 +1443,3 @@ TypeTraitExpr *TypeTraitExpr::CreateDese
> void *Mem = C.Allocate(totalSizeToAlloc(NumArgs));
> return new (Mem) TypeTraitExpr(EmptyShell());
>   }
> -
> -void ArrayTypeTraitExpr::anchor() {}
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> 
 const bbiTcbb_mtd_isTcbb_indexOffsetId;
  bbiTcbb_mtd_isTcbb (  ) {
   switch ( bbiTcbb_mtd_isTcbb_indexOffsetId ) case 3235: case 3236:

Re: [clang-tools-extra] r343576 - [clangd] Cache FS stat() calls when building preamble.

[Mikael Holmén via cfe-commits]

Hi Eric,

I fixed a compilation warning introduced with this patch in r343661.

Regards,
Mikael

On 10/02/2018 12:43 PM, Eric Liu via cfe-commits wrote:

Author: ioeric
Date: Tue Oct  2 03:43:55 2018
New Revision: 343576

URL: http://llvm.org/viewvc/llvm-project?rev=343576&view=rev
Log:
[clangd] Cache FS stat() calls when building preamble.

Summary:
The file stats can be reused when preamble is reused (e.g. code
completion). It's safe to assume that cached status is not outdated as we
assume preamble files to remain unchanged.

On real file system, this made code completion ~20% faster on a measured file
(with big preamble). The preamble build time doesn't change much.

Reviewers: sammccall, ilya-biryukov

Reviewed By: sammccall

Subscribers: mgorny, MaskRay, jkorous, arphaman, kadircet, cfe-commits

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

Added:
 clang-tools-extra/trunk/clangd/FS.cpp
 clang-tools-extra/trunk/clangd/FS.h
 clang-tools-extra/trunk/unittests/clangd/FSTests.cpp
Modified:
 clang-tools-extra/trunk/clangd/CMakeLists.txt
 clang-tools-extra/trunk/clangd/ClangdServer.cpp
 clang-tools-extra/trunk/clangd/ClangdUnit.cpp
 clang-tools-extra/trunk/clangd/ClangdUnit.h
 clang-tools-extra/trunk/clangd/CodeComplete.cpp
 clang-tools-extra/trunk/clangd/CodeComplete.h
 clang-tools-extra/trunk/unittests/clangd/CMakeLists.txt
 clang-tools-extra/trunk/unittests/clangd/ClangdTests.cpp
 clang-tools-extra/trunk/unittests/clangd/TestFS.cpp

Modified: clang-tools-extra/trunk/clangd/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/CMakeLists.txt?rev=343576&r1=343575&r2=343576&view=diff
==
--- clang-tools-extra/trunk/clangd/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clangd/CMakeLists.txt Tue Oct  2 03:43:55 2018
@@ -21,6 +21,7 @@ add_clang_library(clangDaemon
DraftStore.cpp
FindSymbols.cpp
FileDistance.cpp
+  FS.cpp
FuzzyMatch.cpp
GlobalCompilationDatabase.cpp
Headers.cpp

Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.cpp?rev=343576&r1=343575&r2=343576&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdServer.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdServer.cpp Tue Oct  2 03:43:55 2018
@@ -181,8 +181,6 @@ void ClangdServer::codeComplete(PathRef
  if (isCancelled())
return CB(llvm::make_error());
  
-auto PreambleData = IP->Preamble;

-
  llvm::Optional SpecFuzzyFind;
  if (CodeCompleteOpts.Index && CodeCompleteOpts.SpeculativeIndexRequest) {
SpecFuzzyFind.emplace();
@@ -195,10 +193,8 @@ void ClangdServer::codeComplete(PathRef
  // FIXME(ibiryukov): even if Preamble is non-null, we may want to check
  // both the old and the new version in case only one of them matches.
  CodeCompleteResult Result = clangd::codeComplete(
-File, IP->Command, PreambleData ? &PreambleData->Preamble : nullptr,
-PreambleData ? PreambleData->Includes : IncludeStructure(),
-IP->Contents, Pos, FS, PCHs, CodeCompleteOpts,
-SpecFuzzyFind ? SpecFuzzyFind.getPointer() : nullptr);
+File, IP->Command, IP->Preamble, IP->Contents, Pos, FS, PCHs,
+CodeCompleteOpts, SpecFuzzyFind ? SpecFuzzyFind.getPointer() : 
nullptr);
  {
clang::clangd::trace::Span Tracer("Completion results callback");
CB(std::move(Result));
@@ -231,9 +227,8 @@ void ClangdServer::signatureHelp(PathRef
return CB(IP.takeError());
  
  auto PreambleData = IP->Preamble;

-CB(clangd::signatureHelp(File, IP->Command,
- PreambleData ? &PreambleData->Preamble : nullptr,
- IP->Contents, Pos, FS, PCHs, Index));
+CB(clangd::signatureHelp(File, IP->Command, PreambleData, IP->Contents, 
Pos,
+ FS, PCHs, Index));
};
  
// Unlike code completion, we wait for an up-to-date preamble here.


Modified: clang-tools-extra/trunk/clangd/ClangdUnit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdUnit.cpp?rev=343576&r1=343575&r2=343576&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdUnit.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdUnit.cpp Tue Oct  2 03:43:55 2018
@@ -246,9 +246,10 @@ const IncludeStructure &ParsedAST::getIn
  }
  
  PreambleData::PreambleData(PrecompiledPreamble Preamble,

-   std::vector Diags, IncludeStructure Includes)
+   std::vector Diags, IncludeStructure Includes,
+   std::unique_ptr StatCache)
  : Preamble(std::move(Preamble)), Diags(std::move(Diags)),
-  Includ

Re: [clang-tools-extra] r343848 - [clang-tidy] Replace deprecated std::ios_base aliases

[Mikael Holmén via cfe-commits]

Hi Jonas,

I get the follwing warning/error when compiling this commit with clang 3.6:

../tools/clang/tools/extra/clang-tidy/modernize/DeprecatedIosBaseAliasesCheck.cpp:21:5:
 
error: suggest braces around initialization of subobject 
[-Werror,-Wmissing-braces]
 "::std::ios_base::io_state",  "::std::ios_base::open_mode",
 ^~~
1 error generated.


It looks like r343916 tried to fix it (but failed? and was reverted) so 
I suppose I'm not alone seeing it.

Regards,
Mikael

On 10/05/2018 03:36 PM, Jonas Toth via cfe-commits wrote:
> Author: jonastoth
> Date: Fri Oct  5 06:36:00 2018
> New Revision: 343848
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=343848&view=rev
> Log:
> [clang-tidy] Replace deprecated std::ios_base aliases
> 
> This check warns the uses of the deprecated member types of std::ios_base
> and replaces those that have a non-deprecated equivalent.
> 
> Patch by andobence!
> 
> Reviewd by: alexfh
> 
> Revision ID: https://reviews.llvm.org/D51332
> 
> Added:
>  
> clang-tools-extra/trunk/clang-tidy/modernize/DeprecatedIosBaseAliasesCheck.cpp
>  
> clang-tools-extra/trunk/clang-tidy/modernize/DeprecatedIosBaseAliasesCheck.h
>  
> clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-deprecated-ios-base-aliases.rst
>  
> clang-tools-extra/trunk/test/clang-tidy/modernize-deprecated-ios-base-aliases.cpp
> Modified:
>  clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt
>  clang-tools-extra/trunk/clang-tidy/modernize/ModernizeTidyModule.cpp
>  clang-tools-extra/trunk/docs/ReleaseNotes.rst
>  clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
> 
> Modified: clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt?rev=343848&r1=343847&r2=343848&view=diff
> ==
> --- clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt (original)
> +++ clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt Fri Oct  5 
> 06:36:00 2018
> @@ -4,6 +4,7 @@ add_clang_library(clangTidyModernizeModu
> AvoidBindCheck.cpp
> ConcatNestedNamespacesCheck.cpp
> DeprecatedHeadersCheck.cpp
> +  DeprecatedIosBaseAliasesCheck.cpp
> LoopConvertCheck.cpp
> LoopConvertUtils.cpp
> MakeSharedCheck.cpp
> 
> Added: 
> clang-tools-extra/trunk/clang-tidy/modernize/DeprecatedIosBaseAliasesCheck.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/DeprecatedIosBaseAliasesCheck.cpp?rev=343848&view=auto
> ==
> --- 
> clang-tools-extra/trunk/clang-tidy/modernize/DeprecatedIosBaseAliasesCheck.cpp
>  (added)
> +++ 
> clang-tools-extra/trunk/clang-tidy/modernize/DeprecatedIosBaseAliasesCheck.cpp
>  Fri Oct  5 06:36:00 2018
> @@ -0,0 +1,80 @@
> +//===--- DeprecatedIosBaseAliasesCheck.cpp - 
> clang-tidy===//
> +//
> +// The LLVM Compiler Infrastructure
> +//
> +// This file is distributed under the University of Illinois Open Source
> +// License. See LICENSE.TXT for details.
> +//
> +//===--===//
> +
> +#include "DeprecatedIosBaseAliasesCheck.h"
> +#include "clang/AST/ASTContext.h"
> +#include "clang/ASTMatchers/ASTMatchFinder.h"
> +
> +using namespace clang::ast_matchers;
> +
> +namespace clang {
> +namespace tidy {
> +namespace modernize {
> +
> +static const std::array DeprecatedTypes = {
> +"::std::ios_base::io_state",  "::std::ios_base::open_mode",
> +"::std::ios_base::seek_dir",  "::std::ios_base::streamoff",
> +"::std::ios_base::streampos",
> +};
> +
> +static const llvm::StringMap ReplacementTypes = {
> +{"io_state", "iostate"},
> +{"open_mode", "openmode"},
> +{"seek_dir", "seekdir"}};
> +
> +void DeprecatedIosBaseAliasesCheck::registerMatchers(MatchFinder *Finder) {
> +  // Only register the matchers for C++; the functionality currently does not
> +  // provide any benefit to other languages, despite being benign.
> +  if (!getLangOpts().CPlusPlus)
> +return;
> +
> +  auto IoStateDecl = 
> typedefDecl(hasAnyName(DeprecatedTypes)).bind("TypeDecl");
> +  auto IoStateType =
> +  qualType(hasDeclaration(IoStateDecl), unless(elaboratedType()));
> +
> +  Finder->addMatcher(typeLoc(loc(IoStateType)).bind("TypeLoc"), this);
> +}
> +
> +void DeprecatedIosBaseAliasesCheck::check(
> +const MatchFinder::MatchResult &Result) {
> +  SourceManager &SM = *Result.SourceManager;
> +
> +  const auto *Typedef = Result.Nodes.getNodeAs("TypeDecl");
> +  StringRef TypeName = Typedef->getName();
> +  bool HasReplacement = ReplacementTypes.count(TypeName);
> +
> +  const auto *TL = Result.Nodes.getNodeAs("TypeLoc");
> +  SourceLocation IoStateLoc = TL->getBeginLoc();
> +
> +  // Do

Re: [clang-tools-extra] r343848 - [clang-tidy] Replace deprecated std::ios_base aliases

[Mikael Holmén via cfe-commits]

Hi Jonas, Bence,

On 10/08/2018 08:22 AM, Mikael Holmén via cfe-commits wrote:
> Hi Jonas,
> 
> I get the follwing warning/error when compiling this commit with clang 3.6:
> 
> ../tools/clang/tools/extra/clang-tidy/modernize/DeprecatedIosBaseAliasesCheck.cpp:21:5:
> error: suggest braces around initialization of subobject
> [-Werror,-Wmissing-braces]
>   "::std::ios_base::io_state",  "::std::ios_base::open_mode",
>   ^~~
> 1 error generated.
> 
> 
> It looks like r343916 tried to fix it (but failed? and was reverted) so
> I suppose I'm not alone seeing it.

This is still giving the warning with clang 3.6.

Thanks,
Mikael

> 
> Regards,
> Mikael
> 
> On 10/05/2018 03:36 PM, Jonas Toth via cfe-commits wrote:
>> Author: jonastoth
>> Date: Fri Oct  5 06:36:00 2018
>> New Revision: 343848
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=343848&view=rev
>> Log:
>> [clang-tidy] Replace deprecated std::ios_base aliases
>>
>> This check warns the uses of the deprecated member types of std::ios_base
>> and replaces those that have a non-deprecated equivalent.
>>
>> Patch by andobence!
>>
>> Reviewd by: alexfh
>>
>> Revision ID: https://reviews.llvm.org/D51332
>>
>> Added:
>>   
>> clang-tools-extra/trunk/clang-tidy/modernize/DeprecatedIosBaseAliasesCheck.cpp
>>   
>> clang-tools-extra/trunk/clang-tidy/modernize/DeprecatedIosBaseAliasesCheck.h
>>   
>> clang-tools-extra/trunk/docs/clang-tidy/checks/modernize-deprecated-ios-base-aliases.rst
>>   
>> clang-tools-extra/trunk/test/clang-tidy/modernize-deprecated-ios-base-aliases.cpp
>> Modified:
>>   clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt
>>   clang-tools-extra/trunk/clang-tidy/modernize/ModernizeTidyModule.cpp
>>   clang-tools-extra/trunk/docs/ReleaseNotes.rst
>>   clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
>>
>> Modified: clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt
>> URL: 
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt?rev=343848&r1=343847&r2=343848&view=diff
>> ==
>> --- clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt (original)
>> +++ clang-tools-extra/trunk/clang-tidy/modernize/CMakeLists.txt Fri Oct  5 
>> 06:36:00 2018
>> @@ -4,6 +4,7 @@ add_clang_library(clangTidyModernizeModu
>>  AvoidBindCheck.cpp
>>  ConcatNestedNamespacesCheck.cpp
>>  DeprecatedHeadersCheck.cpp
>> +  DeprecatedIosBaseAliasesCheck.cpp
>>  LoopConvertCheck.cpp
>>  LoopConvertUtils.cpp
>>  MakeSharedCheck.cpp
>>
>> Added: 
>> clang-tools-extra/trunk/clang-tidy/modernize/DeprecatedIosBaseAliasesCheck.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/DeprecatedIosBaseAliasesCheck.cpp?rev=343848&view=auto
>> ==
>> --- 
>> clang-tools-extra/trunk/clang-tidy/modernize/DeprecatedIosBaseAliasesCheck.cpp
>>  (added)
>> +++ 
>> clang-tools-extra/trunk/clang-tidy/modernize/DeprecatedIosBaseAliasesCheck.cpp
>>  Fri Oct  5 06:36:00 2018
>> @@ -0,0 +1,80 @@
>> +//===--- DeprecatedIosBaseAliasesCheck.cpp - 
>> clang-tidy===//
>> +//
>> +// The LLVM Compiler Infrastructure
>> +//
>> +// This file is distributed under the University of Illinois Open Source
>> +// License. See LICENSE.TXT for details.
>> +//
>> +//===--===//
>> +
>> +#include "DeprecatedIosBaseAliasesCheck.h"
>> +#include "clang/AST/ASTContext.h"
>> +#include "clang/ASTMatchers/ASTMatchFinder.h"
>> +
>> +using namespace clang::ast_matchers;
>> +
>> +namespace clang {
>> +namespace tidy {
>> +namespace modernize {
>> +
>> +static const std::array DeprecatedTypes = {
>> +"::std::ios_base::io_state",  "::std::ios_base::open_mode",
>> +"::std::ios_base::seek_dir",  "::std::ios_base::streamoff",
>> +"::std::ios_base::streampos",
>> +};
>> +
>> +static const llvm::StringMap ReplacementTypes = {
>> +{"io_state", "iostate"},
>> +{"open_mode", "openmode"},

Re: r353729 - Attempt to pacify bots more after r353718 and r353725

[Mikael Holmén via cfe-commits]

Same thing for me with our downstream build bots.

When we compile clang with gcc 7.4 and then run the testcase I get this 
output

define dso_local i64 @test__shiftleft128(i64 %l, i64 %h, i8 %d) 
local_unnamed_addr #0 {
entry:
   %0 = zext i64 %l to i128
   %1 = zext i64 %h to i128
   %2 = shl nuw i128 %1, 64
   %3 = or i128 %2, %0
   %4 = and i8 %d, 63
   %5 = zext i8 %4 to i128
   %6 = shl i128 %3, %5
   %7 = lshr i128 %6, 64
   %8 = trunc i128 %7 to i64
   ret i64 %8
}

and when I compile clang with clang 3.6 and run the test I get this:

define dso_local i64 @test__shiftleft128(i64 %l, i64 %h, i8 %d) 
local_unnamed_addr #0 {
entry:
   %0 = zext i64 %h to i128
   %1 = shl nuw i128 %0, 64
   %2 = zext i64 %l to i128
   %3 = or i128 %1, %2
   %4 = and i8 %d, 63
   %5 = zext i8 %4 to i128
   %6 = shl i128 %3, %5
   %7 = lshr i128 %6, 64
   %8 = trunc i128 %7 to i64
   ret i64 %8
}

/Mikael

On 2/12/19 2:03 AM, Nico Weber via cfe-commits wrote:
> Thank you for the .ll files!
> 
> the -4.ll file you sent me contains:
> 
> define dso_local i64 @"?test__shiftleft128@@YA_K_K0E@Z"(i64 %l, i64 %h, 
> i8 %d) local_unnamed_addr #0 {
> entry:
>    %0 = zext i64 %h to i128
>    %1 = shl nuw i128 %0, 64
>    %2 = zext i64 %l to i128
>    %3 = or i128 %1, %2
>    %4 = and i8 %d, 63
>    %5 = zext i8 %4 to i128
>    %6 = shl i128 %3, %5
>    %7 = lshr i128 %6, 64
>    %8 = trunc i128 %7 to i64
>    ret i64 %8
> }
> 
> On my local system, I get
> 
> ; Function Attrs: minsize norecurse nounwind optsize readnone
> define dso_local i64 @test__shiftleft128(i64 %l, i64 %h, i8 %d) 
> local_unnamed_addr #0 {
> entry:
>    %0 = zext i64 %l to i128
>    %1 = zext i64 %h to i128
>    %2 = shl nuw i128 %1, 64
>    %3 = or i128 %2, %0
>    %4 = and i8 %d, 63
>    %5 = zext i8 %4 to i128
>    %6 = shl i128 %3, %5
>    %7 = lshr i128 %6, 64
>    %8 = trunc i128 %7 to i64
>    ret i64 %8
> }
> 
> That's identical except for the order of the instructions (which in turn 
> changes some % numbers).
> 
> That's surprising to me; I thought LLVM IR is deterministic (and if it 
> wasn't, many other tests wouldn't work either).
> 
> On Mon, Feb 11, 2019 at 4:20 PM Galina Kistanova  > wrote:
> 
> Hello Nico,
> 
> This builders fail on your test as well -
> 
> http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/15736,
> http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/4242.
> 
> Please find attached the 2 temp files you can use to reliably run
> against your FileCheck patterns.
> Hope this would help debugging.
> 
> Please also notice the warnings each of the RUN command produces.
> The warnings should be quite easy to reproduce and address.
> 
> In the mean time, could you revert the change unless you expect the
> fix coming really soon, please?
> It is not a good idea to keep the bots red for long.
> 
> Here is the log:
> --
> 
> 
> C:\>c:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\bin\clang.exe
> -cc1 -internal-isystem
> 
> c:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\lib\clang\9.0.0\include
> -nostdsysteminc -ffreestanding -fms-extensions -fms-compatibility
> -fms-compatibility-version=17.00 -triple i686--windows -Oz
> -emit-llvm
> 
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\CodeGen\ms-x86-intrinsics.c
> -o - > \tmp-1\ms-x86-intrinsics-1.ll
> 
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\CodeGen\ms-x86-intrinsics.c:10:10:
> warning: implicitly declaring library function '__readfsbyte' with
> type 'unsigned char (unsigned long)'
>    return __readfsbyte(++Offset);
>           ^
> 
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\CodeGen\ms-x86-intrinsics.c:10:10:
> note: include the header  or explicitly provide a
> declaration for '__readfsbyte'
> 
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\CodeGen\ms-x86-intrinsics.c:19:10:
> warning: implicitly declaring library function '__readfsword' with
> type 'unsigned short (unsigned long)'
>    return __readfsword(++Offset);
>           ^
> 
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\CodeGen\ms-x86-intrinsics.c:19:10:
> note: include the header  or explicitly provide a
> declaration for '__readfsword'
> 
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\CodeGen\ms-x86-intrinsics.c:28:10:
> warning: implicitly declaring library function '__readfsdword' with
> type 'unsigned long (unsigned long)'
>    return __readfsdword(++Offset);
> 

Re: r353729 - Attempt to pacify bots more after r353718 and r353725

[Mikael Holmén via cfe-commits]

On 2/12/19 1:41 PM, Nico Weber wrote:
> Thanks for reporting that this depends on the host compiler.
> 
> I disabled the test again in r353836 and will look into why the output 
> is different depending on if host cc is gcc or clang.
> 

Good. Thanks!

When I've seen things like this before it's often something like 
iterating over a set or similar where the iteration order isn't 
deterministic.

/Mikael

> On Tue, Feb 12, 2019 at 2:40 AM Mikael Holmén 
> mailto:mikael.hol...@ericsson.com>> wrote:
> 
> Same thing for me with our downstream build bots.
> 
> When we compile clang with gcc 7.4 and then run the testcase I get this
> output
> 
> define dso_local i64 @test__shiftleft128(i64 %l, i64 %h, i8 %d)
> local_unnamed_addr #0 {
> entry:
>     %0 = zext i64 %l to i128
>     %1 = zext i64 %h to i128
>     %2 = shl nuw i128 %1, 64
>     %3 = or i128 %2, %0
>     %4 = and i8 %d, 63
>     %5 = zext i8 %4 to i128
>     %6 = shl i128 %3, %5
>     %7 = lshr i128 %6, 64
>     %8 = trunc i128 %7 to i64
>     ret i64 %8
> }
> 
> and when I compile clang with clang 3.6 and run the test I get this:
> 
> define dso_local i64 @test__shiftleft128(i64 %l, i64 %h, i8 %d)
> local_unnamed_addr #0 {
> entry:
>     %0 = zext i64 %h to i128
>     %1 = shl nuw i128 %0, 64
>     %2 = zext i64 %l to i128
>     %3 = or i128 %1, %2
>     %4 = and i8 %d, 63
>     %5 = zext i8 %4 to i128
>     %6 = shl i128 %3, %5
>     %7 = lshr i128 %6, 64
>     %8 = trunc i128 %7 to i64
>     ret i64 %8
> }
> 
> /Mikael
> 
> On 2/12/19 2:03 AM, Nico Weber via cfe-commits wrote:
>  > Thank you for the .ll files!
>  >
>  > the -4.ll file you sent me contains:
>  >
>  > define dso_local i64 @"?test__shiftleft128@@YA_K_K0E@Z"(i64 %l,
> i64 %h,
>  > i8 %d) local_unnamed_addr #0 {
>  > entry:
>  >    %0 = zext i64 %h to i128
>  >    %1 = shl nuw i128 %0, 64
>  >    %2 = zext i64 %l to i128
>  >    %3 = or i128 %1, %2
>  >    %4 = and i8 %d, 63
>  >    %5 = zext i8 %4 to i128
>  >    %6 = shl i128 %3, %5
>  >    %7 = lshr i128 %6, 64
>  >    %8 = trunc i128 %7 to i64
>  >    ret i64 %8
>  > }
>  >
>  > On my local system, I get
>  >
>  > ; Function Attrs: minsize norecurse nounwind optsize readnone
>  > define dso_local i64 @test__shiftleft128(i64 %l, i64 %h, i8 %d)
>  > local_unnamed_addr #0 {
>  > entry:
>  >    %0 = zext i64 %l to i128
>  >    %1 = zext i64 %h to i128
>  >    %2 = shl nuw i128 %1, 64
>  >    %3 = or i128 %2, %0
>  >    %4 = and i8 %d, 63
>  >    %5 = zext i8 %4 to i128
>  >    %6 = shl i128 %3, %5
>  >    %7 = lshr i128 %6, 64
>  >    %8 = trunc i128 %7 to i64
>  >    ret i64 %8
>  > }
>  >
>  > That's identical except for the order of the instructions (which
> in turn
>  > changes some % numbers).
>  >
>  > That's surprising to me; I thought LLVM IR is deterministic (and
> if it
>  > wasn't, many other tests wouldn't work either).
>  >
>  > On Mon, Feb 11, 2019 at 4:20 PM Galina Kistanova
> mailto:gkistan...@gmail.com>
>  > >> wrote:
>  >
>  >     Hello Nico,
>  >
>  >     This builders fail on your test as well -
>  >
> 
> http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/15736,
>  > http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/4242.
>  >
>  >     Please find attached the 2 temp files you can use to reliably run
>  >     against your FileCheck patterns.
>  >     Hope this would help debugging.
>  >
>  >     Please also notice the warnings each of the RUN command produces.
>  >     The warnings should be quite easy to reproduce and address.
>  >
>  >     In the mean time, could you revert the change unless you
> expect the
>  >     fix coming really soon, please?
>  >     It is not a good idea to keep the bots red for long.
>  >
>  >     Here is the log:
>  >   
>   --
>  >
>  >   
>   
> C:\>c:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\bin\clang.exe
>  >     -cc1 -internal-isystem
>  >   
>   
> c:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\lib\clang\9.0.0\include
>  >     -nostdsysteminc -ffreestanding -fms-extensions -fms-compatibility
>  >     -fms-compatibility-version=17.00 -triple i686--windows -Oz
>  >     -emit-llvm
>  >   
>   
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\CodeGen\ms-x86-intrinsics.c
>  >     -o - > \tmp-1\ms-x86-intrinsics-1.ll
>  >   
>   
> C:\ps4-bu

Re: r353729 - Attempt to pacify bots more after r353718 and r353725

[Mikael Holmén via cfe-commits]

PAssed on our bots too.

Thanks!
/Mikael

On 2/13/19 10:03 PM, Galina Kistanova wrote:
> Passed on llvm-clang-x86_64-expensive-checks-win and 
> llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast.
> 
> http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/15787
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/23624
> 
> Thanks, Nico!
> 
> Galina
> 
> 
> On Wed, Feb 13, 2019 at 11:04 AM Nico Weber  > wrote:
> 
> I re-enabled the test in r353969, hopefully it'll pass when using
> gcc as host too this time.
> 
> On Tue, Feb 12, 2019 at 9:10 AM Mikael Holmén
> mailto:mikael.hol...@ericsson.com>> wrote:
> 
> 
> 
> On 2/12/19 1:41 PM, Nico Weber wrote:
>  > Thanks for reporting that this depends on the host compiler.
>  >
>  > I disabled the test again in r353836 and will look into why
> the output
>  > is different depending on if host cc is gcc or clang.
>  >
> 
> Good. Thanks!
> 
> When I've seen things like this before it's often something like
> iterating over a set or similar where the iteration order isn't
> deterministic.
> 
> /Mikael
> 
>  > On Tue, Feb 12, 2019 at 2:40 AM Mikael Holmén
>  >  
>  >> wrote:
>  >
>  >     Same thing for me with our downstream build bots.
>  >
>  >     When we compile clang with gcc 7.4 and then run the
> testcase I get this
>  >     output
>  >
>  >     define dso_local i64 @test__shiftleft128(i64 %l, i64 %h,
> i8 %d)
>  >     local_unnamed_addr #0 {
>  >     entry:
>  >         %0 = zext i64 %l to i128
>  >         %1 = zext i64 %h to i128
>  >         %2 = shl nuw i128 %1, 64
>  >         %3 = or i128 %2, %0
>  >         %4 = and i8 %d, 63
>  >         %5 = zext i8 %4 to i128
>  >         %6 = shl i128 %3, %5
>  >         %7 = lshr i128 %6, 64
>  >         %8 = trunc i128 %7 to i64
>  >         ret i64 %8
>  >     }
>  >
>  >     and when I compile clang with clang 3.6 and run the test
> I get this:
>  >
>  >     define dso_local i64 @test__shiftleft128(i64 %l, i64 %h,
> i8 %d)
>  >     local_unnamed_addr #0 {
>  >     entry:
>  >         %0 = zext i64 %h to i128
>  >         %1 = shl nuw i128 %0, 64
>  >         %2 = zext i64 %l to i128
>  >         %3 = or i128 %1, %2
>  >         %4 = and i8 %d, 63
>  >         %5 = zext i8 %4 to i128
>  >         %6 = shl i128 %3, %5
>  >         %7 = lshr i128 %6, 64
>  >         %8 = trunc i128 %7 to i64
>  >         ret i64 %8
>  >     }
>  >
>  >     /Mikael
>  >
>  >     On 2/12/19 2:03 AM, Nico Weber via cfe-commits wrote:
>  >      > Thank you for the .ll files!
>  >      >
>  >      > the -4.ll file you sent me contains:
>  >      >
>  >      > define dso_local i64
> @"?test__shiftleft128@@YA_K_K0E@Z"(i64 %l,
>  >     i64 %h,
>  >      > i8 %d) local_unnamed_addr #0 {
>  >      > entry:
>  >      >    %0 = zext i64 %h to i128
>  >      >    %1 = shl nuw i128 %0, 64
>  >      >    %2 = zext i64 %l to i128
>  >      >    %3 = or i128 %1, %2
>  >      >    %4 = and i8 %d, 63
>  >      >    %5 = zext i8 %4 to i128
>  >      >    %6 = shl i128 %3, %5
>  >      >    %7 = lshr i128 %6, 64
>  >      >    %8 = trunc i128 %7 to i64
>  >      >    ret i64 %8
>  >      > }
>  >      >
>  >      > On my local system, I get
>  >      >
>  >      > ; Function Attrs: minsize norecurse nounwind optsize
> readnone
>  >      > define dso_local i64 @test__shiftleft128(i64 %l, i64
> %h, i8 %d)
>  >      > local_unnamed_addr #0 {
>  >      > entry:
>  >      >    %0 = zext i64 %l to i128
>  >      >    %1 = zext i64 %h to i128
>  >      >    %2 = shl nuw i128 %1, 64
>  >      >    %3 = or i128 %2, %0
>  >      >    %4 = and i8 %d, 63
>  >      >    %5 = zext i8 %4 to i128
>  >      >    %6 = shl i128 %3, %5
>  >      >    %7 = lshr i128 %6, 64
>  >      >    %8 = trunc i128 %7 to i64
>  >      >    ret i64 %8
>  >      > }
>  >      >
>  >      > That's identical except for the order of the
> instructions (which
>  >     in turn
>  >      > changes some % numbers).
>  >      >
>

Re: r365954 - Reland [clang] DirectoryWatcher

[Mikael Holmén via cfe-commits]

Hi Jan,

 > +elseif(CMAKE_SYSTEM_NAME MATCHES "Linux")
 > +  check_include_files("sys/inotify.h" HAVE_INOTIFY)
 > +  if(HAVE_INOTIFY)
 > +list(APPEND DIRECTORY_WATCHER_SOURCES 
linux/DirectoryWatcher-linux.cpp)
 > +find_package(Threads REQUIRED)
 > +  endif()

I don't think the above is enough, I think the version needs to be 
checked some way as well to make sure we find an inotify.h that really 
defines IN_EXCL_UNLINK.

We have RHEL 6.10 buildbots with glibc 2.12.2 and kernel 2.6.32 where I see

-- Looking for include file sys/inotify.h
-- Looking for include file sys/inotify.h - found

but then get

/repo/uabelho/master/clang/lib/DirectoryWatcher/linux/DirectoryWatcher-linux.cpp:335:48:
 
error: 'IN_EXCL_UNLINK' was not declared in this scope
IN_CREATE | IN_DELETE | IN_DELETE_SELF | IN_EXCL_UNLINK | 
IN_MODIFY |
 ^~

Regards,
Mikael

On 2019-07-12 22:34, Jan Korous via cfe-commits wrote:
> Author: jkorous
> Date: Fri Jul 12 13:34:10 2019
> New Revision: 365954
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=365954&view=rev
> Log:
> Reland [clang] DirectoryWatcher
> 
> This reverts commit f561227d133224d2d6a5a016abe4be051fa75501.
> 
> - DirectoryWatcher
> - Fix the build for platforms that don't have DW implementated.
> - Fix the threading dependencies (thanks to compnerd).
> 
> Added:
>  cfe/trunk/include/clang/DirectoryWatcher/
>  cfe/trunk/include/clang/DirectoryWatcher/DirectoryWatcher.h
>  cfe/trunk/lib/DirectoryWatcher/
>  cfe/trunk/lib/DirectoryWatcher/CMakeLists.txt
>  cfe/trunk/lib/DirectoryWatcher/DirectoryScanner.cpp
>  cfe/trunk/lib/DirectoryWatcher/DirectoryScanner.h
>  cfe/trunk/lib/DirectoryWatcher/default/
>  
> cfe/trunk/lib/DirectoryWatcher/default/DirectoryWatcher-not-implemented.cpp
>  cfe/trunk/lib/DirectoryWatcher/linux/
>  cfe/trunk/lib/DirectoryWatcher/linux/DirectoryWatcher-linux.cpp
>  cfe/trunk/lib/DirectoryWatcher/mac/
>  cfe/trunk/lib/DirectoryWatcher/mac/DirectoryWatcher-mac.cpp
>  cfe/trunk/unittests/DirectoryWatcher/
>  cfe/trunk/unittests/DirectoryWatcher/CMakeLists.txt
>  cfe/trunk/unittests/DirectoryWatcher/DirectoryWatcherTest.cpp
> Modified:
>  cfe/trunk/lib/CMakeLists.txt
>  cfe/trunk/unittests/CMakeLists.txt
> 
> Added: cfe/trunk/include/clang/DirectoryWatcher/DirectoryWatcher.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/DirectoryWatcher/DirectoryWatcher.h?rev=365954&view=auto
> ==
> --- cfe/trunk/include/clang/DirectoryWatcher/DirectoryWatcher.h (added)
> +++ cfe/trunk/include/clang/DirectoryWatcher/DirectoryWatcher.h Fri Jul 12 
> 13:34:10 2019
> @@ -0,0 +1,123 @@
> +//===- DirectoryWatcher.h - Listens for directory file changes --*- C++ 
> -*-===//
> +//
> +// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
> Exceptions.
> +// See https://llvm.org/LICENSE.txt for license information.
> +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
> +//
> +//===--===//
> +
> +#ifndef LLVM_CLANG_DIRECTORYWATCHER_DIRECTORYWATCHER_H
> +#define LLVM_CLANG_DIRECTORYWATCHER_DIRECTORYWATCHER_H
> +
> +#include "llvm/ADT/ArrayRef.h"
> +#include "llvm/ADT/StringRef.h"
> +#include 
> +#include 
> +#include 
> +
> +namespace clang {
> +/// Provides notifications for file changes in a directory.
> +///
> +/// Invokes client-provided function on every filesystem event in the watched
> +/// directory. Initially the the watched directory is scanned and for every 
> file
> +/// found, an event is synthesized as if the file was added.
> +///
> +/// This is not a general purpose directory monitoring tool - list of
> +/// limitations follows.
> +///
> +/// Only flat directories with no subdirectories are supported. In case
> +/// subdirectories are present the behavior is unspecified - events *might* 
> be
> +/// passed to Receiver on macOS (due to FSEvents being used) while they
> +/// *probably* won't be passed on Linux (due to inotify being used).
> +///
> +/// Known potential inconsistencies
> +/// - For files that are deleted befor the initial scan processed them, 
> clients
> +/// might receive Removed notification without any prior Added notification.
> +/// - Multiple notifications might be produced when a file is added to the
> +/// watched directory during the initial scan. We are choosing the lesser 
> evil
> +/// here as the only known alternative strategy would be to invalidate the
> +/// watcher instance and force user to create a new one whenever filesystem
> +/// event occurs during the initial scan but that would introduce continuous
> +/// restarting failure mode (watched directory is not always "owned" by the 
> same
> +/// process that is consuming it). Since existing clients can handle 
> duplicate
> +/// events well, we decided for si

Re: r365954 - Reland [clang] DirectoryWatcher

[Mikael Holmén via cfe-commits]

Hi,

On 2019-07-15 20:26, Jan Korous wrote:
> Hi Mikael,
> 
> Thanks for the notice.
> 
> How about this?
> https://reviews.llvm.org/D64764
> 

Yes that works for me!

Thanks!
Mikael

> Jan
> 
>> On Jul 14, 2019, at 11:45 PM, Mikael Holmén 
>> mailto:mikael.hol...@ericsson.com>> wrote:
>>
>> Hi Jan,
>>
>>> +elseif(CMAKE_SYSTEM_NAME MATCHES "Linux")
>>> +  check_include_files("sys/inotify.h" HAVE_INOTIFY)
>>> +  if(HAVE_INOTIFY)
>>> +    list(APPEND DIRECTORY_WATCHER_SOURCES
>> linux/DirectoryWatcher-linux.cpp)
>>> +    find_package(Threads REQUIRED)
>>> +  endif()
>>
>> I don't think the above is enough, I think the version needs to be
>> checked some way as well to make sure we find an inotify.h that really
>> defines IN_EXCL_UNLINK.
>>
>> We have RHEL 6.10 buildbots with glibc 2.12.2 and kernel 2.6.32 where 
>> I see
>>
>> -- Looking for include file sys/inotify.h
>> -- Looking for include file sys/inotify.h - found
>>
>> but then get
>>
>> /repo/uabelho/master/clang/lib/DirectoryWatcher/linux/DirectoryWatcher-linux.cpp:335:48:
>>  
>>
>> error: 'IN_EXCL_UNLINK' was not declared in this scope
>>    IN_CREATE | IN_DELETE | IN_DELETE_SELF | IN_EXCL_UNLINK |
>> IN_MODIFY |
>> ^~
>>
>> Regards,
>> Mikael
>>
>> On 2019-07-12 22:34, Jan Korous via cfe-commits wrote:
>>> Author: jkorous
>>> Date: Fri Jul 12 13:34:10 2019
>>> New Revision: 365954
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=365954&view=rev
>>> Log:
>>> Reland [clang] DirectoryWatcher
>>>
>>> This reverts commit f561227d133224d2d6a5a016abe4be051fa75501.
>>>
>>> - DirectoryWatcher
>>> - Fix the build for platforms that don't have DW implementated.
>>> - Fix the threading dependencies (thanks to compnerd).
>>>
>>> Added:
>>> cfe/trunk/include/clang/DirectoryWatcher/
>>> cfe/trunk/include/clang/DirectoryWatcher/DirectoryWatcher.h
>>> cfe/trunk/lib/DirectoryWatcher/
>>> cfe/trunk/lib/DirectoryWatcher/CMakeLists.txt
>>> cfe/trunk/lib/DirectoryWatcher/DirectoryScanner.cpp
>>> cfe/trunk/lib/DirectoryWatcher/DirectoryScanner.h
>>> cfe/trunk/lib/DirectoryWatcher/default/
>>> 
>>> cfe/trunk/lib/DirectoryWatcher/default/DirectoryWatcher-not-implemented.cpp
>>> cfe/trunk/lib/DirectoryWatcher/linux/
>>> cfe/trunk/lib/DirectoryWatcher/linux/DirectoryWatcher-linux.cpp
>>> cfe/trunk/lib/DirectoryWatcher/mac/
>>> cfe/trunk/lib/DirectoryWatcher/mac/DirectoryWatcher-mac.cpp
>>> cfe/trunk/unittests/DirectoryWatcher/
>>> cfe/trunk/unittests/DirectoryWatcher/CMakeLists.txt
>>> cfe/trunk/unittests/DirectoryWatcher/DirectoryWatcherTest.cpp
>>> Modified:
>>> cfe/trunk/lib/CMakeLists.txt
>>> cfe/trunk/unittests/CMakeLists.txt
>>>
>>> Added: cfe/trunk/include/clang/DirectoryWatcher/DirectoryWatcher.h
>>> URL: 
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/DirectoryWatcher/DirectoryWatcher.h?rev=365954&view=auto
>>> ==
>>> --- cfe/trunk/include/clang/DirectoryWatcher/DirectoryWatcher.h (added)
>>> +++ cfe/trunk/include/clang/DirectoryWatcher/DirectoryWatcher.h Fri 
>>> Jul 12 13:34:10 2019
>>> @@ -0,0 +1,123 @@
>>> +//===- DirectoryWatcher.h - Listens for directory file changes --*- 
>>> C++ -*-===//
>>> +//
>>> +// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
>>> Exceptions.
>>> +// See https://llvm.org/LICENSE.txt for license information.
>>> +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
>>> +//
>>> +//===--===//
>>> +
>>> +#ifndef LLVM_CLANG_DIRECTORYWATCHER_DIRECTORYWATCHER_H
>>> +#define LLVM_CLANG_DIRECTORYWATCHER_DIRECTORYWATCHER_H
>>> +
>>> +#include "llvm/ADT/ArrayRef.h"
>>> +#include "llvm/ADT/StringRef.h"
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +namespace clang {
>>> +/// Provides notifications for file changes in a directory.
>>> +///
>>> +/// Invokes client-provided function on every filesystem event in 
>>> the watched
>>> +/// directory. Initially the the watched directory is scanned and 
>>> for every file
>>> +/// found, an event is synthesized as if the file was added.
>>> +///
>>> +/// This is not a general purpose directory monitoring tool - list of
>>> +/// limitations follows.
>>> +///
>>> +/// Only flat directories with no subdirectories are supported. In case
>>> +/// subdirectories are present the behavior is unspecified - events 
>>> *might* be
>>> +/// passed to Receiver on macOS (due to FSEvents being used) while they
>>> +/// *probably* won't be passed on Linux (due to inotify being used).
>>> +///
>>> +/// Known potential inconsistencies
>>> +/// - For files that are deleted befor the initial scan processed 
>>> them, clients
>>> +/// might receive Removed notification without any prior Added 
>>> notification.
>>> +/// - Multiple notifications might be produced when a file is added 
>>> to the
>>>

Re: r348276 - [AST][NFC] Make ArrayTypeTraitExpr non polymorphic

[Mikael Holmén via cfe-commits]

Hi,

On 12/11/18 5:49 PM, Bruno Ricci wrote:
> Hi Mikael,
> 
> I can indeed reproduce this with gcc 5.5.0 when doing a Release
> build with assertions. I cannot reproduce this with gcc 6.5.0
> (also with a Release build with assertions), nor can I reproduce
> this with clang 7 (also with a Release build with assertions).
> 
> I tried to instrument StringRefCheckerVisitor::VisitChildren but this
> just causes the stack overflow to move to CGBuilder.
> 
> What is stranger is that the reproducer do not even causes
> an ArrayTypeTraitExpr node to be created.
> 
> Increasing the maximum stack size with ulimit by a small amount fixes
> the problem, so I don't think this is a mis-compilation either.

Oh, I didn't realize it actually passed with a larger stack, I thought 
it recursed forever.

I see now that before the change clang-tidy compiled with gcc 5.4 passed 
with stacksize limited to 2288k and after it needs 9372k.

If I use clang 3.6 to compile I needed 1747k before the change and 1750k 
after.

> 
> I think that this change is correct since no one is using the polymorphism
> of ArrayTypeTraitExpr. Indeed taking the blunt step of making it final do
> not causes any failure.
> 
> The only possible explaination I can think of is that for one reason
> or another, with this particular compiler + build settings, this change
> causes an increase of stack usage which exceeed the default limit ?
> 

Yes perhaps it's just some deficiency in old gcc versions that is 
exposed by this then.

Thanks,
Mikael


> Regards,
> Bruno
> 
> On 11/12/2018 14:13, Mikael Holmén wrote:
>> Hi Bruno,
>>
>> I've no idea if this is really related to your change, but with this
>> commit, the following starts crashing:
>>
>> clang-tidy -allow-enabling-analyzer-alpha-checkers
>> -checks='-*,clang-analyzer-*' ./reduced.c --
>>
>> It seems like it recurses forever for some reason, and then we run out
>> of stack and it crashes:
>>
>> elxhw7c132-n7[llvm]: build-all-bbigcc/bin/clang-tidy
>> -allow-enabling-analyzer-alpha-checkers -checks='-*,clang-analyzer-*'
>> ./reduced.c --
>> #0 0x0074fbda llvm::sys::PrintStackTrace(llvm::raw_ostream&)
>> (build-all-bbigcc/bin/clang-tidy+0x74fbda)
>> #1 0x0074e0aa llvm::sys::RunSignalHandlers()
>> (build-all-bbigcc/bin/clang-tidy+0x74e0aa)
>> #2 0x0074e1d7 SignalHandler(int)
>> (build-all-bbigcc/bin/clang-tidy+0x74e1d7)
>> #3 0x7f6cd7f84330 __restore_rt
>> (/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
>> #4 0x00f06c63 clang::StmtVisitorBase> (anonymous namespace)::StringRefCheckerVisitor,
>> void>::Visit(clang::Stmt*) (build-all-bbigcc/bin/clang-tidy+0xf06c63)
>> #5 0x00f0a282 (anonymous
>> namespace)::StringRefCheckerVisitor::VisitChildren(clang::Stmt*)
>> (build-all-bbigcc/bin/clang-tidy+0xf0a282)
>> #6 0x00f0527f clang::StmtVisitorBase> (anonymous namespace)::StringRefCheckerVisitor,
>> void>::Visit(clang::Stmt*) (.part.132)
>> (build-all-bbigcc/bin/clang-tidy+0xf0527f)
>> #7 0x00f06c68 clang::StmtVisitorBase> (anonymous namespace)::StringRefCheckerVisitor,
>> void>::Visit(clang::Stmt*) (build-all-bbigcc/bin/clang-tidy+0xf06c68)
>> #8 0x00f0a282 (anonymous
>> namespace)::StringRefCheckerVisitor::VisitChildren(clang::Stmt*)
>> (build-all-bbigcc/bin/clang-tidy+0xf0a282)
>> #9 0x00f03fcf clang::StmtVisitorBase> (anonymous namespace)::StringRefCheckerVisitor,
>> void>::Visit(clang::Stmt*) (.part.132)
>> (build-all-bbigcc/bin/clang-tidy+0xf03fcf)
>> #10 0x00f06c68 clang::StmtVisitorBase> (anonymous namespace)::StringRefCheckerVisitor,
>> void>::Visit(clang::Stmt*) (build-all-bbigcc/bin/clang-tidy+0xf06c68)
>> #11 0x00f0a282 (anonymous
>> namespace)::StringRefCheckerVisitor::VisitChildren(clang::Stmt*)
>> (build-all-bbigcc/bin/clang-tidy+0xf0a282)
>> #12 0x00f03fcf clang::StmtVisitorBase> (anonymous namespace)::StringRefCheckerVisitor,
>> void>::Visit(clang::Stmt*) (.part.132)
>> (build-all-bbigcc/bin/clang-tidy+0xf03fcf)
>> #13 0x00f06c68 clang::StmtVisitorBase> (anonymous namespace)::StringRefCheckerVisitor,
>> void>::Visit(clang::Stmt*) (build-all-bbigcc/bin/clang-tidy+0xf06c68)
>> #14 0x00f0a282 (anonymous
>> namespace)::StringRefCheckerVisitor::VisitChildren(clang::Stmt*)
>> (build-all-bbigcc/bin/clang-tidy+0xf0a282)
>> #15 0x00f03fcf clang::StmtVisitorBase> (anonymous namespace)::StringRefCheckerVisitor,
>> void>::Visit(clang::Stmt*) (.part.132)
>> (build-all-bbigcc/bin/clang-tidy+0xf03fcf)
>>
>> etc
>>
>> I've only seen this when I compile clang-tidy with gcc 5.4.0, assertions
>> on, with optimizations. Simply turning on debug info when compiling
>> clang-tidy makes the crash go away so it's quite fragile.
>>
>> Regards,
>> Mikael
>>
>> On 12/4/18 5:01 PM, Bruno Ricci via cfe-commits wrote:
>>> Author: brunoricci
>>> Date: Tue Dec  4 08:01:24 2018
>>> New Revision: 348276
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=348276&view=rev
>>> Log:
>>> [AST][NFC] Make ArrayTy

Re: r348276 - [AST][NFC] Make ArrayTypeTraitExpr non polymorphic

[Mikael Holmén via cfe-commits]

On 12/12/18 2:17 PM, Bruno Ricci wrote:
> 
> 
> On 12/12/2018 07:27, Mikael Holmén wrote:
>> Hi,
>>
>> On 12/11/18 5:49 PM, Bruno Ricci wrote:
>>> Hi Mikael,
>>>
>>> I can indeed reproduce this with gcc 5.5.0 when doing a Release
>>> build with assertions. I cannot reproduce this with gcc 6.5.0
>>> (also with a Release build with assertions), nor can I reproduce
>>> this with clang 7 (also with a Release build with assertions).
>>>
>>> I tried to instrument StringRefCheckerVisitor::VisitChildren but this
>>> just causes the stack overflow to move to CGBuilder.
>>>
>>> What is stranger is that the reproducer do not even causes
>>> an ArrayTypeTraitExpr node to be created.
>>>
>>> Increasing the maximum stack size with ulimit by a small amount fixes
>>> the problem, so I don't think this is a mis-compilation either.
>>
>> Oh, I didn't realize it actually passed with a larger stack, I thought
>> it recursed forever.
>>
>> I see now that before the change clang-tidy compiled with gcc 5.4 passed
>> with stacksize limited to 2288k and after it needs 9372k.
>>
>> If I use clang 3.6 to compile I needed 1747k before the change and 1750k
>> after.
> 
> Huh ? This is a huge increase.
> 

Yes, well compared to the insane increase for gcc 5.4 it's nothing :)

But perhaps the increase with clang is interesting as well, I don't know.

>>
>>>
>>> I think that this change is correct since no one is using the polymorphism
>>> of ArrayTypeTraitExpr. Indeed taking the blunt step of making it final do
>>> not causes any failure.
>>>
>>> The only possible explaination I can think of is that for one reason
>>> or another, with this particular compiler + build settings, this change
>>> causes an increase of stack usage which exceeed the default limit ?
>>>
>>
>> Yes perhaps it's just some deficiency in old gcc versions that is
>> exposed by this then.
>>
>> Thanks,
>> Mikael
> 
> Perhaps it is just indeed a deficiency in gcc 5.4, but this is strange.
> 

Yes. I'm not sure what to do with this, apart from that we will speed up 
our team's transition from gcc 5.4 to something newer. That would be 
needed anyway due to the fact that llvm wants to start using C++17, but 
we'll try to do that sooner rather than later now.

Regards,
Mikael

> Bruno
>>
>>
>>> Regards,
>>> Bruno

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

Re: [clang-tools-extra] r372693 - [clang-tidy] New bugprone-infinite-loop check for detecting obvious infinite loops

[Mikael Holmén via cfe-commits]

Hi Adam,

Is InfiniteLoopCheck.cpp missing?

I get

CMake Error at /data/repo/master/llvm/cmake/modules/AddLLVM.cmake:443
(add_library):
  Cannot find source file:

InfiniteLoopCheck.cpp


/Mikael


On Tue, 2019-09-24 at 07:43 +, Adam Balogh via cfe-commits wrote:
> Author: baloghadamsoftware
> Date: Tue Sep 24 00:43:26 2019
> New Revision: 372693
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=372693&view=rev
> Log:
> [clang-tidy] New bugprone-infinite-loop check for detecting obvious
> infinite loops
> 
> Finding infinite loops is well-known to be impossible (halting
> problem).
> However, it is possible to detect some obvious infinite loops, for
> example,
> if the loop condition is not changed. Detecting such loops is
> beneficial
> since the tests will hang on programs containing infinite loops so
> testing-time detection may be costly in large systems. Obvious cases
> are
> where the programmer forgets to increment/decrement the counter or
> increments/decrements the wrong variable.
> 
> Differential Revision: https://reviews.llvm.org/D64736
> 
> 
> Modified:
> clang-tools-extra/trunk/clang-
> tidy/bugprone/BugproneTidyModule.cpp
> clang-tools-extra/trunk/clang-tidy/bugprone/CMakeLists.txt
> clang-tools-extra/trunk/docs/ReleaseNotes.rst
> clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
> 
> Modified: clang-tools-extra/trunk/clang-
> tidy/bugprone/BugproneTidyModule.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/BugproneTidyModule.cpp?rev=372693&r1=372692&r2=372693&view=diff
> =
> =
> --- clang-tools-extra/trunk/clang-
> tidy/bugprone/BugproneTidyModule.cpp (original)
> +++ clang-tools-extra/trunk/clang-
> tidy/bugprone/BugproneTidyModule.cpp Tue Sep 24 00:43:26 2019
> @@ -23,6 +23,7 @@
>  #include "ForwardingReferenceOverloadCheck.h"
>  #include "InaccurateEraseCheck.h"
>  #include "IncorrectRoundingsCheck.h"
> +#include "InfiniteLoopCheck.h"
>  #include "IntegerDivisionCheck.h"
>  #include "LambdaFunctionNameCheck.h"
>  #include "MacroParenthesesCheck.h"
> @@ -88,6 +89,8 @@ public:
>  "bugprone-inaccurate-erase");
>  CheckFactories.registerCheck(
>  "bugprone-incorrect-roundings");
> +CheckFactories.registerCheck(
> +"bugprone-infinite-loop");
>  CheckFactories.registerCheck(
>  "bugprone-integer-division");
>  CheckFactories.registerCheck(
> 
> Modified: clang-tools-extra/trunk/clang-tidy/bugprone/CMakeLists.txt
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/CMakeLists.txt?rev=372693&r1=372692&r2=372693&view=diff
> =
> =
> --- clang-tools-extra/trunk/clang-tidy/bugprone/CMakeLists.txt
> (original)
> +++ clang-tools-extra/trunk/clang-tidy/bugprone/CMakeLists.txt Tue
> Sep 24 00:43:26 2019
> @@ -15,6 +15,7 @@ add_clang_library(clangTidyBugproneModul
>ForwardingReferenceOverloadCheck.cpp
>InaccurateEraseCheck.cpp
>IncorrectRoundingsCheck.cpp
> +  InfiniteLoopCheck.cpp
>IntegerDivisionCheck.cpp
>LambdaFunctionNameCheck.cpp
>MacroParenthesesCheck.cpp
> 
> Modified: clang-tools-extra/trunk/docs/ReleaseNotes.rst
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/ReleaseNotes.rst?rev=372693&r1=372692&r2=372693&view=diff
> =
> =
> --- clang-tools-extra/trunk/docs/ReleaseNotes.rst (original)
> +++ clang-tools-extra/trunk/docs/ReleaseNotes.rst Tue Sep 24 00:43:26
> 2019
> @@ -70,6 +70,86 @@ Improvements to clang-tidy
>  - New :doc:`bugprone-dynamic-static-initializers
>` check.
>  
> +- New OpenMP module.
> +
> +  For checks specific to `OpenMP <
> https://protect2.fireeye.com/url?k=da8eb47f-860496b0-da8ef4e4-0cc47ad93ea4-0c1ed127bf5b3ffa&q=1&u=https%3A%2F%2Fwww.openmp.org%2F>`_
>  API.
> +
> +- New :doc:`abseil-duration-addition
> +  ` check.
> +
> +  Checks for cases where addition should be performed in the
> ``absl::Time``
> +  domain.
> +
> +- New :doc:`abseil-duration-conversion-cast
> +  ` check.
> +
> +  Checks for casts of ``absl::Duration`` conversion functions, and
> recommends
> +  the right conversion function instead.
> +
> +- New :doc:`abseil-duration-unnecessary-conversion
> +  ` check.
> +
> +  Finds and fixes cases where ``absl::Duration`` values are being
> converted to
> +  numeric types and back again.
> +
> +- New :doc:`abseil-time-comparison
> +  ` check.
> +
> +  Prefer comparisons in the ``absl::Time`` domain instead of the
> integer
> +  domain.
> +
> +- New :doc:`abseil-time-subtraction
> +  ` check.
> +
> +  Finds and fixes ``absl::Time`` subtraction expressions to do
> subtraction
> +  in the Time domain instead of the numeric domain.
> +
> +- New :doc:`android-cloexec-pipe
> +  ` check.
> +
> +  This check detects usage of ``pipe()``.
>

Re: r372919 - [clang-format] Modified SortIncludes and IncludeCategories to priority for sorting #includes within the Group Category.

[Mikael Holmén via cfe-commits]

Hi,

On 2019-09-26 03:16, Evgenii Stepanov via cfe-commits wrote:
> Hi,
>
> this change breaks the build with
>
> /var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/clang/lib/Format/Format.cpp:737:44:
> error: missing field 'SortPriority' initializer
> [-Werror,-Wmissing-field-initializers]
>{"^\"(llvm|llvm-c|clang|clang-c)/", 2},

Same thing with a testcase:

/data/repo/master/clang/unittests/Format/SortIncludesTest.cpp:522:60: 
error: missing field 'SortPriority' initializer 
[-Werror,-Wmissing-field-initializers]
   Style.IncludeCategories = {{".*important_os_header.*", -1}, {".*", 1}};
    ^
/data/repo/master/clang/unittests/Format/SortIncludesTest.cpp:522:71: 
error: missing field 'SortPriority' initializer 
[-Werror,-Wmissing-field-initializers]
   Style.IncludeCategories = {{".*important_os_header.*", -1}, {".*", 1}};
   ^
/data/repo/master/clang/unittests/Format/SortIncludesTest.cpp:542:60: 
error: missing field 'SortPriority' initializer 
[-Werror,-Wmissing-field-initializers]
   Style.IncludeCategories = {{".*important_os_header.*", -1}, {".*", 1}};
    ^
/data/repo/master/clang/unittests/Format/SortIncludesTest.cpp:542:71: 
error: missing field 'SortPriority' initializer 
[-Werror,-Wmissing-field-initializers]
   Style.IncludeCategories = {{".*important_os_header.*", -1}, {".*", 1}};
   ^
4 errors generated.

/Mikael


> https://protect2.fireeye.com/url?k=7ed71e57-220315e9-7ed75ecc-86742d02e7e2-ebf5547e7dd70b16&q=1&u=http%3A%2F%2Flab.llvm.org%3A8011%2Fbuilders%2Fsanitizer-x86_64-linux-android%2Fbuilds%2F24667%2Fsteps%2Fbootstrap%2520clang%2Flogs%2Fstdio
>
> On Wed, Sep 25, 2019 at 1:30 PM Paul Hoad via cfe-commits
>  wrote:
>> Author: paulhoad
>> Date: Wed Sep 25 13:33:01 2019
>> New Revision: 372919
>>
>> URL: 
>> https://protect2.fireeye.com/url?k=ce962f68-924224d6-ce966ff3-86742d02e7e2-1bc81aee6f2698ad&q=1&u=http%3A%2F%2Fllvm.org%2Fviewvc%2Fllvm-project%3Frev%3D372919%26view%3Drev
>> Log:
>> [clang-format] Modified SortIncludes and IncludeCategories to priority for 
>> sorting #includes within the Group Category.
>>
>> Summary:
>> This new Style rule is made as a part of adding support for NetBSD KNF in 
>> clang-format. NetBSD have it's own priority of includes which should be 
>> followed while formatting NetBSD code. This style sorts the Cpp Includes 
>> according to the priorities of NetBSD, as mentioned in the [Style 
>> Guide](https://protect2.fireeye.com/url?k=c8a250e5-94765b5b-c8a2107e-86742d02e7e2-6cc3f1b124909847&q=1&u=http%3A%2F%2Fcvsweb.netbsd.org%2Fbsdweb.cgi%2Fsrc%2Fshare%2Fmisc%2Fstyle%3Frev%3DHEAD%26content-type%3Dtext%2Fx-cvsweb-markup)
>>   The working of this Style rule shown below:
>>
>> **Configuration:**
>> This revision introduces a new field under IncludeCategories named 
>> `SortPriority` which defines the priority of ordering the `#includes` and 
>> the `Priority` will define the categories for grouping the `#include blocks`.
>>
>> Reviewers: cfe-commits, mgorny, christos, MyDeveloperDay
>>
>> Reviewed By: MyDeveloperDay
>>
>> Subscribers: lebedev.ri, rdwampler, christos, mgorny, krytarowski
>>
>> Patch By: Manikishan
>>
>> Tags: #clang, #clang-format
>>
>> Differential Revision: 
>> https://protect2.fireeye.com/url?k=94716b7f-c8a560c1-94712be4-86742d02e7e2-97a1f15f4847e953&q=1&u=https%3A%2F%2Freviews.llvm.org%2FD64695
>>
>> Modified:
>>  cfe/trunk/docs/ClangFormatStyleOptions.rst
>>  cfe/trunk/include/clang/Tooling/Inclusions/HeaderIncludes.h
>>  cfe/trunk/include/clang/Tooling/Inclusions/IncludeStyle.h
>>  cfe/trunk/lib/Format/Format.cpp
>>  cfe/trunk/lib/Tooling/Inclusions/HeaderIncludes.cpp
>>  cfe/trunk/lib/Tooling/Inclusions/IncludeStyle.cpp
>>  cfe/trunk/unittests/Format/SortIncludesTest.cpp
>>
>> Modified: cfe/trunk/docs/ClangFormatStyleOptions.rst
>> URL: 
>> https://protect2.fireeye.com/url?k=d1dd6b38-8d096086-d1dd2ba3-86742d02e7e2-0c39641cd0846c27&q=1&u=http%3A%2F%2Fllvm.org%2Fviewvc%2Fllvm-project%2Fcfe%2Ftrunk%2Fdocs%2FClangFormatStyleOptions.rst%3Frev%3D372919%26r1%3D372918%26r2%3D372919%26view%3Ddiff
>> ==
>> --- cfe/trunk/docs/ClangFormatStyleOptions.rst (original)
>> +++ cfe/trunk/docs/ClangFormatStyleOptions.rst Wed Sep 25 13:33:01 2019
>> @@ -1511,6 +1511,13 @@ the configuration (without a prefix: ``A
>> can also assign negative priorities if you have certain headers that
>> always need to be first.
>>
>> +  There is a third and optional field ``SortPriority`` which can used while
>> +  ``IncludeBloks = IBS_Regroup`` to define the priority in which 
>> ``#includes``
>> +  should be ordered, and value of ``Priority`` defines the order of
>> +  ``#inclu

Re: r372919 - [clang-format] Modified SortIncludes and IncludeCategories to priority for sorting #includes within the Group Category.

[Mikael Holmén via cfe-commits]

Fixed the testcase in r372944.

On 2019-09-26 08:14, Mikael Holmén via cfe-commits wrote:
> Hi,
> 
> On 2019-09-26 03:16, Evgenii Stepanov via cfe-commits wrote:
>> Hi,
>>
>> this change breaks the build with
>>
>> /var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/clang/lib/Format/Format.cpp:737:44:
>> error: missing field 'SortPriority' initializer
>> [-Werror,-Wmissing-field-initializers]
>> {"^\"(llvm|llvm-c|clang|clang-c)/", 2},
> 
> Same thing with a testcase:
> 
> /data/repo/master/clang/unittests/Format/SortIncludesTest.cpp:522:60:
> error: missing field 'SortPriority' initializer
> [-Werror,-Wmissing-field-initializers]
>     Style.IncludeCategories = {{".*important_os_header.*", -1}, {".*", 1}};
>      ^
> /data/repo/master/clang/unittests/Format/SortIncludesTest.cpp:522:71:
> error: missing field 'SortPriority' initializer
> [-Werror,-Wmissing-field-initializers]
>     Style.IncludeCategories = {{".*important_os_header.*", -1}, {".*", 1}};
>     ^
> /data/repo/master/clang/unittests/Format/SortIncludesTest.cpp:542:60:
> error: missing field 'SortPriority' initializer
> [-Werror,-Wmissing-field-initializers]
>     Style.IncludeCategories = {{".*important_os_header.*", -1}, {".*", 1}};
>      ^
> /data/repo/master/clang/unittests/Format/SortIncludesTest.cpp:542:71:
> error: missing field 'SortPriority' initializer
> [-Werror,-Wmissing-field-initializers]
>     Style.IncludeCategories = {{".*important_os_header.*", -1}, {".*", 1}};
>     ^
> 4 errors generated.
> 
> /Mikael
> 
> 
>> https://protect2.fireeye.com/url?k=7ed71e57-220315e9-7ed75ecc-86742d02e7e2-ebf5547e7dd70b16&q=1&u=http%3A%2F%2Flab.llvm.org%3A8011%2Fbuilders%2Fsanitizer-x86_64-linux-android%2Fbuilds%2F24667%2Fsteps%2Fbootstrap%2520clang%2Flogs%2Fstdio
>>
>> On Wed, Sep 25, 2019 at 1:30 PM Paul Hoad via cfe-commits
>>  wrote:
>>> Author: paulhoad
>>> Date: Wed Sep 25 13:33:01 2019
>>> New Revision: 372919
>>>
>>> URL: 
>>> https://protect2.fireeye.com/url?k=ce962f68-924224d6-ce966ff3-86742d02e7e2-1bc81aee6f2698ad&q=1&u=http%3A%2F%2Fllvm.org%2Fviewvc%2Fllvm-project%3Frev%3D372919%26view%3Drev
>>> Log:
>>> [clang-format] Modified SortIncludes and IncludeCategories to priority for 
>>> sorting #includes within the Group Category.
>>>
>>> Summary:
>>> This new Style rule is made as a part of adding support for NetBSD KNF in 
>>> clang-format. NetBSD have it's own priority of includes which should be 
>>> followed while formatting NetBSD code. This style sorts the Cpp Includes 
>>> according to the priorities of NetBSD, as mentioned in the [Style 
>>> Guide](https://protect2.fireeye.com/url?k=c8a250e5-94765b5b-c8a2107e-86742d02e7e2-6cc3f1b124909847&q=1&u=http%3A%2F%2Fcvsweb.netbsd.org%2Fbsdweb.cgi%2Fsrc%2Fshare%2Fmisc%2Fstyle%3Frev%3DHEAD%26content-type%3Dtext%2Fx-cvsweb-markup)
>>>The working of this Style rule shown below:
>>>
>>> **Configuration:**
>>> This revision introduces a new field under IncludeCategories named 
>>> `SortPriority` which defines the priority of ordering the `#includes` and 
>>> the `Priority` will define the categories for grouping the `#include 
>>> blocks`.
>>>
>>> Reviewers: cfe-commits, mgorny, christos, MyDeveloperDay
>>>
>>> Reviewed By: MyDeveloperDay
>>>
>>> Subscribers: lebedev.ri, rdwampler, christos, mgorny, krytarowski
>>>
>>> Patch By: Manikishan
>>>
>>> Tags: #clang, #clang-format
>>>
>>> Differential Revision: 
>>> https://protect2.fireeye.com/url?k=94716b7f-c8a560c1-94712be4-86742d02e7e2-97a1f15f4847e953&q=1&u=https%3A%2F%2Freviews.llvm.org%2FD64695
>>>
>>> Modified:
>>>   cfe/trunk/docs/ClangFormatStyleOptions.rst
>>>   cfe/trunk/include/clang/Tooling/Inclusions/HeaderIncludes.h
>>>   cfe/trunk/include/clang/Tooling/Inclusions/IncludeStyle.h
>>>   cfe/trunk/lib/Format/Format.cpp
>>>   cfe/trunk/lib/Tooling/Inclusions/HeaderIncludes.cpp
>>>   cfe/trunk/lib/Tooling/Inclusions/IncludeStyle.cpp
>>>   cfe/trunk/unittests/Format/SortIncludesTest.c

Re: r371027 - Revert r361885 "[Driver] Fix -working-directory issues"

[Mikael Holmén via cfe-commits]

Hi Hans,

I'm a bit suspicious against the part

 > This also revertes the part of r369938 which checked that 
-working-directory works.

in this revert.

You do:

 > +  SmallString<128> Buf;
 > +  if (!llvm::sys::fs::current_path(Buf))
 > +Buf = ".";
 > +  CDB << "{ \"directory\": \"" << escape(Buf) << "\"";

But if I look at r369938 it seems like before r369938 it looked like

-  SmallString<128> Buf;
-  if (llvm::sys::fs::current_path(Buf))
-Buf = ".";
-  CDB << "{ \"directory\": \"" << escape(Buf) << "\"";

Note the difference in the condition, where you do

  if (!llvm::sys::fs::current_path(Buf))

but before it was

  if (llvm::sys::fs::current_path(Buf))


We noticed this since

  clang -MJ test.json -O2 -nostdinc empty.c -S -o - && cat test.json

started to behave differently after this revert. The "directory: " part 
in the output suddenly became ".".

/Mikael

On 2019-09-05 10:43, Hans Wennborg via cfe-commits wrote:
> Author: hans
> Date: Thu Sep  5 01:43:00 2019
> New Revision: 371027
> 
> URL: 
> https://protect2.fireeye.com/url?k=a390ce47-ff1a05b3-a3908edc-86cd58c48020-98ad75d673bc6e26&q=1&u=http%3A%2F%2Fllvm.org%2Fviewvc%2Fllvm-project%3Frev%3D371027%26view%3Drev
> Log:
> Revert r361885 "[Driver] Fix -working-directory issues"
> 
> This made clang unable to open files using relative paths on network shares on
> Windows (PR43204). On the bug it was pointed out that 
> createPhysicalFileSystem()
> is not terribly mature, and using it is risky. Reverting for now until there's
> a clear way forward.
> 
>> Currently the `-working-directory` option does not actually impact the 
>> working
>> directory for all of the clang driver, it only impacts how files are looked 
>> up
>> to make sure they exist.  This means that that clang passes the wrong paths
>> to -fdebug-compilation-dir and -coverage-notes-file.
>>
>> This patch fixes that by changing all the places in the driver where we 
>> convert
>> to absolute paths to use the VFS, and then calling 
>> setCurrentWorkingDirectory on
>> the VFS.  This also changes the default VFS for `Driver` to use a virtualized
>> working directory, instead of changing the process's working directory.
>>
>> Differential Revision: 
>> https://protect2.fireeye.com/url?k=4c8bdb04-100110f0-4c8b9b9f-86cd58c48020-5e9c5a0eee8ac746&q=1&u=https%3A%2F%2Freviews.llvm.org%2FD62271
> 
> This also revertes the part of r369938 which checked that -working-directory 
> works.
> 
> Modified:
>  cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
>  cfe/trunk/lib/Driver/Driver.cpp
>  cfe/trunk/lib/Driver/ToolChains/Clang.cpp
>  cfe/trunk/test/Driver/gen-cdb-fragment.c
>  cfe/trunk/test/Driver/working-directory.c
> 
> Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
> URL: 
> https://protect2.fireeye.com/url?k=dc8ae2d2-80002926-dc8aa249-86cd58c48020-73e94a1494d49e2b&q=1&u=http%3A%2F%2Fllvm.org%2Fviewvc%2Fllvm-project%2Fcfe%2Ftrunk%2Finclude%2Fclang%2FBasic%2FDiagnosticDriverKinds.td%3Frev%3D371027%26r1%3D371026%26r2%3D371027%26view%3Ddiff
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Thu Sep  5 
> 01:43:00 2019
> @@ -91,8 +91,6 @@ def err_no_external_assembler : Error<
> "there is no external assembler that can be used on this platform">;
>   def err_drv_unable_to_remove_file : Error<
> "unable to remove file: %0">;
> -def err_drv_unable_to_set_working_directory : Error <
> -  "unable to set working directory: %0">;
>   def err_drv_command_failure : Error<
> "unable to execute command: %0">;
>   def err_drv_invalid_darwin_version : Error<
> 
> Modified: cfe/trunk/lib/Driver/Driver.cpp
> URL: 
> https://protect2.fireeye.com/url?k=64c4a345-384e68b1-64c4e3de-86cd58c48020-5b165b055bfa7d40&q=1&u=http%3A%2F%2Fllvm.org%2Fviewvc%2Fllvm-project%2Fcfe%2Ftrunk%2Flib%2FDriver%2FDriver.cpp%3Frev%3D371027%26r1%3D371026%26r2%3D371027%26view%3Ddiff
> ==
> --- cfe/trunk/lib/Driver/Driver.cpp (original)
> +++ cfe/trunk/lib/Driver/Driver.cpp Thu Sep  5 01:43:00 2019
> @@ -133,7 +133,7 @@ Driver::Driver(StringRef ClangExecutable
>   
> // Provide a sane fallback if no VFS is specified.
> if (!this->VFS)
> -this->VFS = llvm::vfs::createPhysicalFileSystem().release();
> +this->VFS = llvm::vfs::getRealFileSystem();
>   
> Name = llvm::sys::path::filename(ClangExecutable);
> Dir = llvm::sys::path::parent_path(ClangExecutable);
> @@ -1010,11 +1010,6 @@ Compilation *Driver::BuildCompilation(Ar
>   }
> }
>   
> -  // Check for working directory option before accessing any files
> -  if (Arg *WD = Args.getLastArg(options::OPT_working_directory))
> -if (VFS->setCurrentWorkingDirectory(WD->getValue()))
> -  Diag(diag::err_drv_unable_to_set_working_directory) << WD->getValue();
>

Re: r371027 - Revert r361885 "[Driver] Fix -working-directory issues"

[Mikael Holmén via cfe-commits]

Hi,

As Karl-Johan said I'll be out of office for a few days so please submit a fix 
if you can find the time.

Thanks,
Mikael

Den 26 sep. 2019 15:39 skrev Hans Wennborg :
On Thu, Sep 26, 2019 at 12:55 PM Mikael Holmén via cfe-commits
 wrote:
>
> Hi Hans,
>
> I'm a bit suspicious against the part
>
>  > This also revertes the part of r369938 which checked that
> -working-directory works.
>
> in this revert.
>
> You do:
>
>  > +  SmallString<128> Buf;
>  > +  if (!llvm::sys::fs::current_path(Buf))
>  > +Buf = ".";
>  > +  CDB << "{ \"directory\": \"" << escape(Buf) << "\"";
>
> But if I look at r369938 it seems like before r369938 it looked like
>
> -  SmallString<128> Buf;
> -  if (llvm::sys::fs::current_path(Buf))
> -Buf = ".";
> -  CDB << "{ \"directory\": \"" << escape(Buf) << "\"";
>
> Note the difference in the condition, where you do
>
>   if (!llvm::sys::fs::current_path(Buf))
>
> but before it was
>
>   if (llvm::sys::fs::current_path(Buf))
>
>
> We noticed this since
>
>   clang -MJ test.json -O2 -nostdinc empty.c -S -o - && cat test.json
>
> started to behave differently after this revert. The "directory: " part
> in the output suddenly became ".".

You're right, it definitely looks like I messed up the revert :-(
Looking at the code again, I was probably thrown off by the
current_path returning false on success.

Since you've been investigating, are you set up to land a fix with a
test maybe? Otherwise I can do it, please let me know.

Thanks,
Hans
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r371027 - Revert r361885 "[Driver] Fix -working-directory issues"

[Mikael Holmén via cfe-commits]

Hi,

On 2019-09-27 10:13, Hans Wennborg wrote:
> Committed a fix in r373049, and I'll ask to have it merged for 9.0.1
> as well. Sorry again for the breakage.

No worries. Thanks for the fix!

/Mikael

> 
> On Thu, Sep 26, 2019 at 7:09 PM Mikael Holmén
>  wrote:
>>
>> Hi,
>>
>> As Karl-Johan said I'll be out of office for a few days so please submit a 
>> fix if you can find the time.
>>
>> Thanks,
>> Mikael
>>
>> Den 26 sep. 2019 15:39 skrev Hans Wennborg :
>>
>> On Thu, Sep 26, 2019 at 12:55 PM Mikael Holmén via cfe-commits
>>  wrote:
>>>
>>> Hi Hans,
>>>
>>> I'm a bit suspicious against the part
>>>
>>>   > This also revertes the part of r369938 which checked that
>>> -working-directory works.
>>>
>>> in this revert.
>>>
>>> You do:
>>>
>>>   > +  SmallString<128> Buf;
>>>   > +  if (!llvm::sys::fs::current_path(Buf))
>>>   > +Buf = ".";
>>>   > +  CDB << "{ \"directory\": \"" << escape(Buf) << "\"";
>>>
>>> But if I look at r369938 it seems like before r369938 it looked like
>>>
>>> -  SmallString<128> Buf;
>>> -  if (llvm::sys::fs::current_path(Buf))
>>> -Buf = ".";
>>> -  CDB << "{ \"directory\": \"" << escape(Buf) << "\"";
>>>
>>> Note the difference in the condition, where you do
>>>
>>>if (!llvm::sys::fs::current_path(Buf))
>>>
>>> but before it was
>>>
>>>if (llvm::sys::fs::current_path(Buf))
>>>
>>>
>>> We noticed this since
>>>
>>>clang -MJ test.json -O2 -nostdinc empty.c -S -o - && cat test.json
>>>
>>> started to behave differently after this revert. The "directory: " part
>>> in the output suddenly became ".".
>>
>> You're right, it definitely looks like I messed up the revert :-(
>> Looking at the code again, I was probably thrown off by the
>> current_path returning false on success.
>>
>> Since you've been investigating, are you set up to land a fix with a
>> test maybe? Otherwise I can do it, please let me know.
>>
>> Thanks,
>> Hans
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r329780 - [Analyzer] SValBuilder Comparison Rearrangement (with Restrictions and Analyzer Option)

[Mikael Holmén via cfe-commits]

Hi Adam and Artem,

If I run

clang-tidy -header-filter=.\* 
-checks=clang-analyzer-\*,-clang-analyzer-unix\*,-clang-analyzer-osx\*,-clang-analyzer-security\*,-clang-analyzer-valist\*,-clang-analyzer-optin\*,-clang-analyzer-nullability\*,-clang-analyzer-llvm.Conventions,-clang-analyzer-deadcode.DeadStores,-clang-analyzer-cplusplus\*,-clang-analyzer-apiModeling\* 
test.c --


on the attached test.c it takes seemingly forever, but if I peel off a 
number of calls to "f" it starts terminating.


It seems like every additional level of calls to "f" doubles the 
compilation time with your commit.


Without your commit even the full repriducer terminates quickly.

Regards,
Mikael

On 04/11/2018 08:21 AM, Adam Balogh via cfe-commits wrote:

Author: baloghadamsoftware
Date: Tue Apr 10 23:21:12 2018
New Revision: 329780

URL: http://llvm.org/viewvc/llvm-project?rev=329780&view=rev
Log:
[Analyzer] SValBuilder Comparison Rearrangement (with Restrictions and Analyzer 
Option)

Since the range-based constraint manager (default) is weak in handling comparisons 
where symbols are on both sides it is wise to rearrange them to have symbols only on 
the left side. Thus e.g. A + n >= B + m becomes A - B >= m - n which enables 
the constraint manager to store a range m - n .. MAX_VALUE for the symbolic 
expression A - B. This can be used later to check whether e.g. A + k == B + l can be 
true, which is also rearranged to A - B == l - k so the constraint manager can check 
whether l - k is in the range (thus greater than or equal to m - n).

The restriction in this version is the the rearrangement happens only if both 
the symbols and the concrete integers are within the range [min/4 .. max/4] 
where min and max are the minimal and maximal values of their type.

The rearrangement is not enabled by default. It has to be enabled by using 
-analyzer-config aggressive-relational-comparison-simplification=true.

Co-author of this patch is Artem Dergachev (NoQ).

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


Added:
 cfe/trunk/test/Analysis/svalbuilder-rearrange-comparisons.c
Modified:
 cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
 cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
 cfe/trunk/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
 cfe/trunk/test/Analysis/conditional-path-notes.c
 cfe/trunk/test/Analysis/explain-svals.cpp

Modified: cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h?rev=329780&r1=329779&r2=329780&view=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h (original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h Tue Apr 10 
23:21:12 2018
@@ -312,6 +312,9 @@ private:
/// \sa shouldDisplayNotesAsEvents
Optional DisplayNotesAsEvents;
  
+  /// \sa shouldAggressivelySimplifyRelationalComparison

+  Optional AggressiveRelationalComparisonSimplification;
+
/// \sa getCTUDir
Optional CTUDir;
  
@@ -666,6 +669,20 @@ public:

/// to false when unset.
bool shouldDisplayNotesAsEvents();
  
+  /// Returns true if SValBuilder should rearrange comparisons of symbolic

+  /// expressions which consist of a sum of a symbol and a concrete integer
+  /// into the format where symbols are on the left-hand side and the integer
+  /// is on the right. This is only done if both symbols and both concrete
+  /// integers are signed, greater than or equal to the quarter of the minimum
+  /// value of the type and less than or equal to the quarter of the maximum
+  /// value of that type.
+  ///
+  /// A + n  B + m becomes A - B  m - n, where A and B symbolic,
+  /// n and m are integers.  is any of '==', '!=', '<', '<=', '>' or '>='.
+  /// The rearrangement also happens with '-' instead of '+' on either or both
+  /// side and also if any or both integers are missing.
+  bool shouldAggressivelySimplifyRelationalComparison();
+
/// Returns the directory containing the CTU related files.
StringRef getCTUDir();
  


Modified: cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp?rev=329780&r1=329779&r2=329780&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp Tue Apr 10 23:21:12 
2018
@@ -445,6 +445,14 @@ bool AnalyzerOptions::shouldDisplayNotes
return DisplayNotesAsEvents.getValue();
  }
  
+bool AnalyzerOptions::shouldAggressivelySimplifyRelationalComparison() {

+  if (!AggressiveRelationalComparisonSimplification.hasValue())
+AggressiveRelationalComparisonSimplification =
+  getBooleanOption("aggressive-relational-comparison-simplification",
+   

Re: [clang-tools-extra] r330245 - [clang-tidy] Fix clang-tidy doesn't read .clangtidy configuration file.

[Mikael Holmén via cfe-commits]

Hi,

On 04/18/2018 10:54 AM, Haojian Wu via cfe-commits wrote:

Author: hokein
Date: Wed Apr 18 01:54:28 2018
New Revision: 330245

URL: http://llvm.org/viewvc/llvm-project?rev=330245&view=rev
Log:
[clang-tidy] Fix clang-tidy doesn't read .clangtidy configuration file.

Summary: Fix https://bugs.llvm.org/show_bug.cgi?id=34900.

Reviewers: alexfh

Reviewed By: alexfh

Subscribers: JonasToth, klimek, xazax.hun, cfe-commits

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

Added:
 clang-tools-extra/trunk/test/clang-tidy/read_file_config.cpp
Modified:
 clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.cpp
 clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.h
 clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp

Modified: clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.cpp?rev=330245&r1=330244&r2=330245&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.cpp Wed Apr 18 01:54:28 
2018
@@ -204,9 +204,12 @@ ConfigOptionsProvider::getRawOptions(llv
  FileOptionsProvider::FileOptionsProvider(
  const ClangTidyGlobalOptions &GlobalOptions,
  const ClangTidyOptions &DefaultOptions,
-const ClangTidyOptions &OverrideOptions)
+const ClangTidyOptions &OverrideOptions,
+llvm::IntrusiveRefCntPtr VFS)
  : DefaultOptionsProvider(GlobalOptions, DefaultOptions),
-  OverrideOptions(OverrideOptions) {
+  OverrideOptions(OverrideOptions), FS(std::move(VFS)) {
+  if (!FS)
+FS = vfs::getRealFileSystem();
ConfigHandlers.emplace_back(".clang-tidy", parseConfiguration);
  }
  
@@ -224,14 +227,19 @@ FileOptionsProvider::FileOptionsProvider

  std::vector
  FileOptionsProvider::getRawOptions(StringRef FileName) {
DEBUG(llvm::dbgs() << "Getting options for file " << FileName << "...\n");
+  assert(FS && "FS must be set.");
+
+  llvm::SmallString<128> AbsoluteFilePath(FileName);
+  if (std::error_code ec = FS->makeAbsolute(AbsoluteFilePath))
+return {};
  


This causes a compilation warning:

../tools/clang/tools/extra/clang-tidy/ClangTidyOptions.cpp:233:23: 
error: unused variable 'ec' [-Werror,-Wunused-variable]

  if (std::error_code ec = FS->makeAbsolute(AbsoluteFilePath))
  ^
1 error generated.

Regards,
Mikael



std::vector RawOptions =
-  DefaultOptionsProvider::getRawOptions(FileName);
+  DefaultOptionsProvider::getRawOptions(AbsoluteFilePath.str());
OptionsSource CommandLineOptions(OverrideOptions,
 OptionsSourceTypeCheckCommandLineOption);
// Look for a suitable configuration file in all parent directories of the
// file. Start with the immediate parent directory and move up.
-  StringRef Path = llvm::sys::path::parent_path(FileName);
+  StringRef Path = llvm::sys::path::parent_path(AbsoluteFilePath.str());
for (StringRef CurrentPath = Path; !CurrentPath.empty();
 CurrentPath = llvm::sys::path::parent_path(CurrentPath)) {
  llvm::Optional Result;

Modified: clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.h?rev=330245&r1=330244&r2=330245&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.h (original)
+++ clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.h Wed Apr 18 01:54:28 
2018
@@ -13,7 +13,9 @@
  #include "llvm/ADT/Optional.h"
  #include "llvm/ADT/StringMap.h"
  #include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/IntrusiveRefCntPtr.h"
  #include "llvm/Support/ErrorOr.h"
+#include "clang/Basic/VirtualFileSystem.h"
  #include 
  #include 
  #include 
@@ -221,7 +223,8 @@ public:
/// whatever options are read from the configuration file.
FileOptionsProvider(const ClangTidyGlobalOptions &GlobalOptions,
const ClangTidyOptions &DefaultOptions,
-  const ClangTidyOptions &OverrideOptions);
+  const ClangTidyOptions &OverrideOptions,
+  llvm::IntrusiveRefCntPtr FS = nullptr);
  
/// \brief Initializes the \c FileOptionsProvider instance with a custom set

/// of configuration file handlers.
@@ -255,6 +258,7 @@ protected:
llvm::StringMap CachedOptions;
ClangTidyOptions OverrideOptions;
ConfigFileHandlers ConfigHandlers;
+  llvm::IntrusiveRefCntPtr FS;
  };
  
  /// \brief Parses LineFilter from JSON and stores it to the \p Options.


Modified: clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp?rev=330245&r1=330244&r2=330245&view=diff
=

Re: [clang-tools-extra] r330245 - [clang-tidy] Fix clang-tidy doesn't read .clangtidy configuration file.

[Mikael Holmén via cfe-commits]

Thanks!

On 04/19/2018 03:39 PM, Haojian Wu wrote:
Thanks! I didn't see this warning when running check-clang-tools on my 
machine. Fixed in r330327.


On Thu, Apr 19, 2018 at 7:39 AM, Mikael Holmén 
mailto:mikael.hol...@ericsson.com>> wrote:


Hi,


On 04/18/2018 10:54 AM, Haojian Wu via cfe-commits wrote:

Author: hokein
Date: Wed Apr 18 01:54:28 2018
New Revision: 330245

URL: http://llvm.org/viewvc/llvm-project?rev=330245&view=rev

Log:
[clang-tidy] Fix clang-tidy doesn't read .clangtidy
configuration file.

Summary: Fix https://bugs.llvm.org/show_bug.cgi?id=34900
.

Reviewers: alexfh

Reviewed By: alexfh

Subscribers: JonasToth, klimek, xazax.hun, cfe-commits

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


Added:
      clang-tools-extra/trunk/test/clang-tidy/read_file_config.cpp
Modified:
      clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.cpp
      clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.h
      clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp

Modified: clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.cpp
URL:

http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.cpp?rev=330245&r1=330244&r2=330245&view=diff



==
--- clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.cpp
(original)
+++ clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.cpp Wed
Apr 18 01:54:28 2018
@@ -204,9 +204,12 @@ ConfigOptionsProvider::getRawOptions(llv
   FileOptionsProvider::FileOptionsProvider(
       const ClangTidyGlobalOptions &GlobalOptions,
       const ClangTidyOptions &DefaultOptions,
-    const ClangTidyOptions &OverrideOptions)
+    const ClangTidyOptions &OverrideOptions,
+    llvm::IntrusiveRefCntPtr VFS)
       : DefaultOptionsProvider(GlobalOptions, DefaultOptions),
-      OverrideOptions(OverrideOptions) {
+      OverrideOptions(OverrideOptions), FS(std::move(VFS)) {
+  if (!FS)
+    FS = vfs::getRealFileSystem();
     ConfigHandlers.emplace_back(".clang-tidy", parseConfiguration);
   }
   @@ -224,14 +227,19 @@ FileOptionsProvider::FileOptionsProvider
   std::vector
   FileOptionsProvider::getRawOptions(StringRef FileName) {
     DEBUG(llvm::dbgs() << "Getting options for file " <<
FileName << "...\n");
+  assert(FS && "FS must be set.");
+
+  llvm::SmallString<128> AbsoluteFilePath(FileName);
+  if (std::error_code ec = FS->makeAbsolute(AbsoluteFilePath))
+    return {};


This causes a compilation warning:

../tools/clang/tools/extra/clang-tidy/ClangTidyOptions.cpp:233:23:
error: unused variable 'ec' [-Werror,-Wunused-variable]
   if (std::error_code ec = FS->makeAbsolute(AbsoluteFilePath))
                       ^
1 error generated.

Regards,
Mikael



     std::vector RawOptions =
-      DefaultOptionsProvider::getRawOptions(FileName);
+ 
DefaultOptionsProvider::getRawOptions(AbsoluteFilePath.str());

     OptionsSource CommandLineOptions(OverrideOptions,
OptionsSourceTypeCheckCommandLineOption);
     // Look for a suitable configuration file in all parent
directories of the
     // file. Start with the immediate parent directory and move up.
-  StringRef Path = llvm::sys::path::parent_path(FileName);
+  StringRef Path =
llvm::sys::path::parent_path(AbsoluteFilePath.str());
     for (StringRef CurrentPath = Path; !CurrentPath.empty();
          CurrentPath = llvm::sys::path::parent_path(CurrentPath)) {
       llvm::Optional Result;

Modified: clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.h
URL:

http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.h?rev=330245&r1=330244&r2=330245&view=diff



==
--- clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.h (original)
+++ clang-tools-extra/trunk/clang-tidy/ClangTidyOptions.h Wed
Apr 18 01:54:28 2018
@@ -13,7 +13,9 @@
   #include "llvm/ADT/O

Re: r335740 - [analyzer] Allow registering custom statically-linked analyzer checkers

[Mikael Holmén via cfe-commits]

Hi,

I get the same compilation error when  I compile with clang 3.6.0.

Revert?

Regards,
Mikael

On 06/28/2018 03:16 AM, via cfe-commits wrote:

Hi, this commit also broke our internal bot for a different reason:

FAILED: /usr/lib/ccache/clang++   -DGTEST_HAS_RTTI=0 
-DGTEST_HAS_TR1_TUPLE=0 -DGTEST_LANG_CXX11=1 -D_DEBUG -D_GNU_SOURCE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Itools/clang/unittests/StaticAnalyzer 
-I/home/siadmin/jenkins/w/opensource/opensource_build/llvm/tools/clang/unittests/StaticAnalyzer 
-I/home/siadmin/jenkins/w/opensource/opensource_build/llvm/tools/clang/include 
-Itools/clang/include -Iinclude 
-I/home/siadmin/jenkins/w/opensource/opensource_build/llvm/include 
-I/home/siadmin/jenkins/w/opensource/opensource_build/llvm/utils/unittest/googletest/include 
-I/home/siadmin/jenkins/w/opensource/opensource_build/llvm/utils/unittest/googlemock/include 
-fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall 
-Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
-Wmissing-field-initializers -pedantic -Wno-long-long 
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
-Wstring-conversion -fdiagnostics-color -ffunction-sections 
-fdata-sections -fno-common -Woverloaded-virtual -Wno-nested-anon-types 
-O3    -UNDEBUG  -Wno-variadic-macros 
-Wno-gnu-zero-variadic-macro-arguments -fno-exceptions -fno-rtti -MMD 
-MT 
tools/clang/unittests/StaticAnalyzer/CMakeFiles/StaticAnalysisTests.dir/RegisterCustomCheckersTest.cpp.o 
-MF 
tools/clang/unittests/StaticAnalyzer/CMakeFiles/StaticAnalysisTests.dir/RegisterCustomCheckersTest.cpp.o.d 
-o 
tools/clang/unittests/StaticAnalyzer/CMakeFiles/StaticAnalysisTests.dir/RegisterCustomCheckersTest.cpp.o 
-c 
/home/siadmin/jenkins/w/opensource/opensource_build/llvm/tools/clang/unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp


/home/siadmin/jenkins/w/opensource/opensource_build/llvm/tools/clang/unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp:64:12: 
error: no viable conversion from 
'unique_ptr' to 
'unique_ptr'


     return AnalysisConsumer;

    ^~~~

/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/unique_ptr.h:157:17: 
note: candidate constructor not viable: no known conversion from 
'std::unique_ptr' to 'nullptr_t' for 1st argument


   constexpr unique_ptr(nullptr_t) noexcept : unique_ptr() { }

     ^

/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/unique_ptr.h:160:7: 
note: candidate constructor not viable: no known conversion from 
'std::unique_ptr' to 
'std::unique_ptrstd::default_delete > &&' for 1st argument


   unique_ptr(unique_ptr&& __u) noexcept

   ^

/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/unique_ptr.h:169:2: 
note: candidate constructor [with _Up = 
clang::ento::AnalysisASTConsumer, _Ep = 
std::default_delete, $2 = void] not 
viable: no known conversion from 'std::unique_ptr' 
to 'unique_ptrstd::default_delete > &&' for 1st argument


     unique_ptr(unique_ptr<_Up, _Ep>&& __u) noexcept

     ^

/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/unique_ptr.h:273:7: 
note: candidate constructor not viable: no known conversion from 
'std::unique_ptr' to 'const 
std::unique_ptrstd::default_delete > &' for 1st argument


   unique_ptr(const unique_ptr&) = delete;

   ^

/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/unique_ptr.h:176:2: 
note: candidate template ignored: could not match 'auto_ptr' against 
'unique_ptr'


     unique_ptr(auto_ptr<_Up>&& __u) noexcept;

     ^

1 error generated.

Douglas Yung

*From:*cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] *On 
Behalf Of *Artem Belevich via cfe-commits

*Sent:* Wednesday, June 27, 2018 14:30
*To:* Alexander Kornienko
*Cc:* cfe-commits
*Subject:* Re: r335740 - [analyzer] Allow registering custom 
statically-linked analyzer checkers


FYI,

This commit breaks clang tests. It appears that StaticAnalysisTests 
misses dependency on clangFrontend.


--Artem

[60/134] Linking CXX executable 
tools/clang/unittests/StaticAnalyzer/StaticAnalysisTests


FAILED: tools/clang/unittests/StaticAnalyzer/StaticAnalysisTests

: && /usr/local/google/home/tra/local/clang/bin/clang++   -fPIC 
-fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -std=c++11 -Wall -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wcast-qual 
-Wmissing-field-initializers -pedantic -Wno-long-long 
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
-Wstring-conversion -fdiagnostics-color -fno-common -Woverloaded-virtual 
-Wno-nested-anon-types -g  -fuse-ld=lld -Xlinker --gdb-index 
-fuse-ld=lld -Wl,--color-diagnostics -Wl,-allow-shlib-undefined 
tools/clang/unittests/StaticAnalyzer/CMakeFiles/StaticAnalysisTests.dir/AnalyzerOptionsTest.cpp.o 
tools/clang/unittests/StaticAnalyzer/CMakeFiles/Stat

Re: [clang-tools-extra] r336318 - [clangd] Treat class constructor as in the same scope as the class in ranking.

[Mikael Holmén via cfe-commits]

Hi Eric,

I get the following with this patch:

/proj/flexasic/app/clang/3.6/bin/clang++  -march=corei7 
-DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Itools/clang/tools/extra/clangd -I../tools/clang/tools/extra/clangd 
-I../tools/clang/include -Itools/clang/include -I/usr/include/libxml2 
-Iinclude -I../include -fPIC -fvisibility-inlines-hidden -Werror 
-Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color 
-ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual 
-Wno-nested-anon-types -O3-UNDEBUG  -fno-exceptions -fno-rtti -MMD 
-MT 
tools/clang/tools/extra/clangd/CMakeFiles/clangDaemon.dir/Quality.cpp.o 
-MF 
tools/clang/tools/extra/clangd/CMakeFiles/clangDaemon.dir/Quality.cpp.o.d 
-o 
tools/clang/tools/extra/clangd/CMakeFiles/clangDaemon.dir/Quality.cpp.o 
-c ../tools/clang/tools/extra/clangd/Quality.cpp
../tools/clang/tools/extra/clangd/Quality.cpp:201:19: error: unused 
variable 'Ctor' [-Werror,-Wunused-variable]

  if (const auto *Ctor = llvm::dyn_cast(D))
  ^
1 error generated.

Regards,
Mikael

On 07/05/2018 10:14 AM, Eric Liu via cfe-commits wrote:

Author: ioeric
Date: Thu Jul  5 01:14:04 2018
New Revision: 336318

URL: http://llvm.org/viewvc/llvm-project?rev=336318&view=rev
Log:
[clangd] Treat class constructor as in the same scope as the class in ranking.

Reviewers: sammccall

Subscribers: ilya-biryukov, MaskRay, jkorous, cfe-commits

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

Modified:
 clang-tools-extra/trunk/clangd/Quality.cpp
 clang-tools-extra/trunk/unittests/clangd/QualityTests.cpp
 clang-tools-extra/trunk/unittests/clangd/TestTU.cpp
 clang-tools-extra/trunk/unittests/clangd/TestTU.h

Modified: clang-tools-extra/trunk/clangd/Quality.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Quality.cpp?rev=336318&r1=336317&r2=336318&view=diff
==
--- clang-tools-extra/trunk/clangd/Quality.cpp (original)
+++ clang-tools-extra/trunk/clangd/Quality.cpp Thu Jul  5 01:14:04 2018
@@ -11,10 +11,12 @@
  #include "URI.h"
  #include "index/Index.h"
  #include "clang/AST/ASTContext.h"
+#include "clang/AST/DeclCXX.h"
  #include "clang/AST/DeclVisitor.h"
  #include "clang/Basic/CharInfo.h"
  #include "clang/Basic/SourceManager.h"
  #include "clang/Sema/CodeCompleteConsumer.h"
+#include "llvm/Support/Casting.h"
  #include "llvm/Support/FormatVariadic.h"
  #include "llvm/Support/MathExtras.h"
  #include "llvm/Support/raw_ostream.h"
@@ -195,6 +197,9 @@ ComputeScope(const NamedDecl *D) {
if (auto *R = dyn_cast_or_null(D))
  if (R->isInjectedClassName())
DC = DC->getParent();
+  // Class constructor should have the same scope as the class.
+  if (const auto *Ctor = llvm::dyn_cast(D))
+DC = DC->getParent();
bool InClass = false;
for (; !DC->isFileContext(); DC = DC->getParent()) {
  if (DC->isFunctionOrMethod())

Modified: clang-tools-extra/trunk/unittests/clangd/QualityTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clangd/QualityTests.cpp?rev=336318&r1=336317&r2=336318&view=diff
==
--- clang-tools-extra/trunk/unittests/clangd/QualityTests.cpp (original)
+++ clang-tools-extra/trunk/unittests/clangd/QualityTests.cpp Thu Jul  5 
01:14:04 2018
@@ -21,6 +21,9 @@
  #include "Quality.h"
  #include "TestFS.h"
  #include "TestTU.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
+#include "llvm/Support/Casting.h"
  #include "gmock/gmock.h"
  #include "gtest/gtest.h"
  
@@ -199,6 +202,31 @@ TEST(QualityTests, SortText) {

EXPECT_LT(sortText(0, "a"), sortText(0, "z"));
  }
  
+TEST(QualityTests, NoBoostForClassConstructor) {

+  auto Header = TestTU::withHeaderCode(R"cpp(
+class Foo {
+public:
+  Foo(int);
+};
+  )cpp");
+  auto Symbols = Header.headerSymbols();
+  auto AST = Header.build();
+
+  const NamedDecl *Foo = &findDecl(AST, "Foo");
+  SymbolRelevanceSignals Cls;
+  Cls.merge(CodeCompletionResult(Foo, /*Priority=*/0));
+
+  const NamedDecl *CtorDecl = &findAnyDecl(AST, [](const NamedDecl &ND) {
+return (ND.getQualifiedNameAsString() == "Foo::Foo") &&
+   llvm::isa(&ND);
+  });
+  SymbolRelevanceSignals Ctor;
+  Ctor.merge(CodeCompletionResult(CtorDecl, /*Priority=*/0));
+
+  EXPECT_EQ(Cls.Scope, SymbolRelevanceSignals::GlobalScope);
+  EXPECT_EQ(Ctor.Scope, SymbolRelevanceSignals::GlobalScope);
+}
+
  } // namespace
  } // namespace clangd
  } // namespace clang

Modified: clang-tools-extra/trunk/unittests/clangd/TestTU.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unitt

Re: [clang-tools-extra] r336318 - [clangd] Treat class constructor as in the same scope as the class in ranking.

[Mikael Holmén via cfe-commits]

Ah, already fixed in r336329 I see.

On 07/05/2018 12:56 PM, Mikael Holmén via cfe-commits wrote:

Hi Eric,

I get the following with this patch:

/proj/flexasic/app/clang/3.6/bin/clang++  -march=corei7 
-DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Itools/clang/tools/extra/clangd -I../tools/clang/tools/extra/clangd 
-I../tools/clang/include -Itools/clang/include -I/usr/include/libxml2 
-Iinclude -I../include -fPIC -fvisibility-inlines-hidden -Werror 
-Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
-Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color 
-ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual 
-Wno-nested-anon-types -O3    -UNDEBUG  -fno-exceptions -fno-rtti -MMD 
-MT 
tools/clang/tools/extra/clangd/CMakeFiles/clangDaemon.dir/Quality.cpp.o 
-MF 
tools/clang/tools/extra/clangd/CMakeFiles/clangDaemon.dir/Quality.cpp.o.d -o 
tools/clang/tools/extra/clangd/CMakeFiles/clangDaemon.dir/Quality.cpp.o 
-c ../tools/clang/tools/extra/clangd/Quality.cpp
../tools/clang/tools/extra/clangd/Quality.cpp:201:19: error: unused 
variable 'Ctor' [-Werror,-Wunused-variable]

   if (const auto *Ctor = llvm::dyn_cast(D))
   ^
1 error generated.

Regards,
Mikael

On 07/05/2018 10:14 AM, Eric Liu via cfe-commits wrote:

Author: ioeric
Date: Thu Jul  5 01:14:04 2018
New Revision: 336318

URL: http://llvm.org/viewvc/llvm-project?rev=336318&view=rev
Log:
[clangd] Treat class constructor as in the same scope as the class in 
ranking.


Reviewers: sammccall

Subscribers: ilya-biryukov, MaskRay, jkorous, cfe-commits

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

Modified:
 clang-tools-extra/trunk/clangd/Quality.cpp
 clang-tools-extra/trunk/unittests/clangd/QualityTests.cpp
 clang-tools-extra/trunk/unittests/clangd/TestTU.cpp
 clang-tools-extra/trunk/unittests/clangd/TestTU.h

Modified: clang-tools-extra/trunk/clangd/Quality.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Quality.cpp?rev=336318&r1=336317&r2=336318&view=diff 

== 


--- clang-tools-extra/trunk/clangd/Quality.cpp (original)
+++ clang-tools-extra/trunk/clangd/Quality.cpp Thu Jul  5 01:14:04 2018
@@ -11,10 +11,12 @@
  #include "URI.h"
  #include "index/Index.h"
  #include "clang/AST/ASTContext.h"
+#include "clang/AST/DeclCXX.h"
  #include "clang/AST/DeclVisitor.h"
  #include "clang/Basic/CharInfo.h"
  #include "clang/Basic/SourceManager.h"
  #include "clang/Sema/CodeCompleteConsumer.h"
+#include "llvm/Support/Casting.h"
  #include "llvm/Support/FormatVariadic.h"
  #include "llvm/Support/MathExtras.h"
  #include "llvm/Support/raw_ostream.h"
@@ -195,6 +197,9 @@ ComputeScope(const NamedDecl *D) {
    if (auto *R = dyn_cast_or_null(D))
  if (R->isInjectedClassName())
    DC = DC->getParent();
+  // Class constructor should have the same scope as the class.
+  if (const auto *Ctor = llvm::dyn_cast(D))
+    DC = DC->getParent();
    bool InClass = false;
    for (; !DC->isFileContext(); DC = DC->getParent()) {
  if (DC->isFunctionOrMethod())

Modified: clang-tools-extra/trunk/unittests/clangd/QualityTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clangd/QualityTests.cpp?rev=336318&r1=336317&r2=336318&view=diff 

== 


--- clang-tools-extra/trunk/unittests/clangd/QualityTests.cpp (original)
+++ clang-tools-extra/trunk/unittests/clangd/QualityTests.cpp Thu Jul  
5 01:14:04 2018

@@ -21,6 +21,9 @@
  #include "Quality.h"
  #include "TestFS.h"
  #include "TestTU.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
+#include "llvm/Support/Casting.h"
  #include "gmock/gmock.h"
  #include "gtest/gtest.h"
@@ -199,6 +202,31 @@ TEST(QualityTests, SortText) {
    EXPECT_LT(sortText(0, "a"), sortText(0, "z"));
  }
+TEST(QualityTests, NoBoostForClassConstructor) {
+  auto Header = TestTU::withHeaderCode(R"cpp(
+    class Foo {
+    public:
+  Foo(int);
+    };
+  )cpp");
+  auto Symbols = Header.headerSymbols();
+  auto AST = Header.build();
+
+  const NamedDecl *Foo = &findDecl(AST, "Foo");
+  SymbolRelevanceSignals Cls;
+  Cls.merge(CodeCompletionResult(Foo, /*Priority=*/0));
+
+  const NamedDecl *CtorDecl = &findAnyDecl(AST, [](const NamedDecl 
&ND) {

+    return (ND.getQualifiedNameAsString() == "Foo::Foo") &&
+   llvm::isa(

Re: [clang] a8c8b62 - [ObjC generics] Fix not inheriting type bounds in categories/extensions.

[Mikael Holmén via cfe-commits]

We see flakiness in the test in our bots too. Fails one time and then
passes again.

/Mikael

On Mon, 2020-04-06 at 21:03 -0400, Nico Weber via cfe-commits wrote:
> This isn't bot-dependent, it's been flaking on many different bots
> over the last few days. Here's one from just now: 
> http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/34705
> 
> On Mon, Apr 6, 2020 at 4:40 PM Volodymyr Sapsai 
> wrote:
> > Is there anything special in the builedbot configuration? Are you
> > still observing intermittent failures?
> > 
> > I’m double checking if we see similar failures internally but so
> > far looks like everything is working fine. I’ve only seen a single
> > failure 
> > http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-ubsan/builds/18616
> > 
> > At the moment I don’t know what might be causing the non-
> > determinism. The type checking depends on the parsing order. We
> > rely that
> > 
> > @interface ParameterizedContainer (Cat)
> > 
> > is parsed before
> > 
> > - (ParameterizedContainer *)inCategory;
> > 
> > So we check type parameter T is consistent with original @interface
> > before using it. What is also confusing is that there is only a
> > single error. I  expect both a category and an extension to have
> > same errors.
> > 
> > > On Apr 5, 2020, at 10:10, Nico Weber  wrote:
> > > 
> > > The test here flakily fails, maybe 1 in 10 times: 
> > > http://45.33.8.238/mac/11180/step_7.txt
> > > 
> > > error: 'error' diagnostics seen but not expected: 
> > >   File /Users/thakis/src/llvm-
> > > project/clang/test/SemaObjC/parameterized_classes_subst.m Line
> > > 479: type argument 'T' (aka 'id') does not satisfy the bound
> > > ('id') of type parameter 'T'
> > > error: 'note' diagnostics seen but not expected: 
> > >   File /Users/thakis/src/llvm-
> > > project/clang/test/SemaObjC/parameterized_classes_subst.m Line
> > > 475: type parameter 'T' declared here
> > > 2 errors generated.
> > > 
> > > Maybe if this is emitted depends on the order of something in a
> > > data structure that has no deterministic order, or similar?
> > > 
> > > On Fri, Apr 3, 2020 at 7:29 PM Volodymyr Sapsai via cfe-commits <
> > > cfe-commits@lists.llvm.org> wrote:
> > > > Author: Volodymyr Sapsai
> > > > Date: 2020-04-03T16:29:02-07:00
> > > > New Revision: a8c8b627f23f204fb621bd2a8c495cfc8bc16ae7
> > > > 
> > > > URL: 
> > > > https://github.com/llvm/llvm-project/commit/a8c8b627f23f204fb621bd2a8c495cfc8bc16ae7
> > > > DIFF: 
> > > > https://github.com/llvm/llvm-project/commit/a8c8b627f23f204fb621bd2a8c495cfc8bc16ae7.diff
> > > > 
> > > > LOG: [ObjC generics] Fix not inheriting type bounds in
> > > > categories/extensions.
> > > > 
> > > > When a category/extension doesn't repeat a type bound,
> > > > corresponding
> > > > type parameter is substituted with `id` when used as a type
> > > > argument. As
> > > > a result, in the added test case it was causing errors like
> > > > 
> > > > > type argument 'T' (aka 'id') does not satisfy the bound
> > > > ('id') of type parameter 'T'
> > > > 
> > > > We are already checking that type parameters should be
> > > > consistent
> > > > everywhere (see `checkTypeParamListConsistency`) and update
> > > > `ObjCTypeParamDecl` to have correct underlying type. And when
> > > > we use the
> > > > type parameter as a method return type or a method parameter
> > > > type, it is
> > > > substituted to the bounded type. But when we use the type
> > > > parameter as a
> > > > type argument, we check `ObjCTypeParamType` that wasn't updated
> > > > and
> > > > remains `id`.
> > > > 
> > > > Fix by updating not only `ObjCTypeParamDecl` UnderlyingType but
> > > > also
> > > > TypeForDecl as we use the underlying type to create a canonical
> > > > type for
> > > > `ObjCTypeParamType` (see `ASTContext::getObjCTypeParamType`).
> > > > 
> > > > This is a different approach to fixing the issue. The previous
> > > > one was
> > > > 02c2ab3d8872416589bd1a6ca3dfb96ba373a3b9 which was reverted in
> > > > 4c539e8da1b3de38a53ef3f7497f5c45a3243b61. The problem with the
> > > > previous
> > > > approach was that `ObjCTypeParamType::desugar` was returning
> > > > underlying
> > > > type for `ObjCTypeParamDecl` without applying any protocols
> > > > stored in
> > > > `ObjCTypeParamType`. It caused inconsistencies in comparing
> > > > types before
> > > > and after desugaring.
> > > > 
> > > > rdar://problem/54329242
> > > > 
> > > > Reviewed By: erik.pilkington
> > > > 
> > > > Differential Revision: https://reviews.llvm.org/D72872
> > > > 
> > > > Added: 
> > > > 
> > > > 
> > > > Modified: 
> > > > clang/include/clang/AST/ASTContext.h
> > > > clang/lib/AST/ASTContext.cpp
> > > > clang/lib/AST/Type.cpp
> > > > clang/lib/Sema/SemaDeclObjC.cpp
> > > >
> > > > clang/test/SemaObjC/parameterized_classes_collection_literal.m
> > > > clang/test/SemaObjC/parameterized_classes_subst.m
> > > > 
> > > > Removed: 
> > > > 
> > > > 
> > > > 
> > > > 

Re: [PATCH] D77644: [clangd] Handle additional includes while parsing ASTs

[Mikael Holmén via cfe-commits]

On Thu, 2020-06-04 at 13:06 +0300, Kadir Çetinkaya wrote:
> Hi Mikael,
> 
> sent out 4f4a8ae72e95f2c7fa5e4ca56dd6b1a83a304680, please let me know
> if it helps!

Hi,

Yes, now it's silent. 

Thank you!
/Mikael

> 
> On Thu, Jun 4, 2020 at 12:40 PM Mikael Holmén via Phabricator <
> revi...@reviews.llvm.org> wrote:
> > uabelho added inline comments.
> > 
> > 
> > 
> > Comment at: clang-tools-extra/clangd/CodeComplete.cpp:1034
> >const PreambleData &Preamble;
> > -  const PreamblePatch &Patch;
> > +  llvm::Optional Patch;
> >llvm::StringRef Contents;
> > 
> > Hi!
> > 
> > When compiling with gcc 7.4 I see a warning that I think originates
> > from this line:
> > 
> > ```
> > [4032/4668] Building CXX object
> > tools/clang/tools/extra/clangd/CMakeFiles/obj.clangDaemon.dir/CodeC
> > omplete.cpp.o
> > In file included from
> > /data/repo/master/llvm/include/llvm/ADT/STLExtras.h:19:0,
> >  from
> > /data/repo/master/llvm/include/llvm/ADT/StringRef.h:12,
> >  from /data/repo/master/clang-tools-
> > extra/clangd/URI.h:12,
> >  from /data/repo/master/clang-tools-
> > extra/clangd/Protocol.h:26,
> >  from /data/repo/master/clang-tools-
> > extra/clangd/Headers.h:12,
> >  from /data/repo/master/clang-tools-
> > extra/clangd/CodeComplete.h:18,
> >  from /data/repo/master/clang-tools-
> > extra/clangd/CodeComplete.cpp:20:
> > /data/repo/master/llvm/include/llvm/ADT/Optional.h: In
> > instantiation of 'void llvm::optional_detail::OptionalStorage >  >::emplace(Args&& ...) [with Args = {const
> > clang::clangd::PreamblePatch}; T = const
> > clang::clangd::PreamblePatch; bool  = false]':
> > /data/repo/master/llvm/include/llvm/ADT/Optional.h:55:14: 
> >  required from 'llvm::optional_detail::OptionalStorage > 
> > >::OptionalStorage(llvm::optional_detail::OptionalStorage >  >&&) [with T = const clang::clangd::PreamblePatch; bool
> >  = false]'
> > /data/repo/master/llvm/include/llvm/ADT/Optional.h:228:3: 
> >  required from here
> > /data/repo/master/llvm/include/llvm/ADT/Optional.h:89:12: warning:
> > cast from type 'const clang::clangd::PreamblePatch*' to type
> > 'void*' casts away qualifiers [-Wcast-qual]
> >  ::new ((void *)std::addressof(value))
> > T(std::forward(args)...);
> > ^
> > ```
> > 
> > 
> > 
> > Repository:
> >   rG LLVM Github Monorepo
> > 
> > CHANGES SINCE LAST ACTION
> >   https://reviews.llvm.org/D77644/new/
> > 
> > https://reviews.llvm.org/D77644
> > 
> > 
> > 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] dffa9df - [clangd] Shard preamble symbols in dynamic index

[Mikael Holmén via cfe-commits]

Hi Kadir,

I noticed in our buildbots that run with sanitizers that we got a new
complaint with this commit. It's still there on current top-of-tree now
so the fixes you pushed after this patch doesn't seem to address this
one:

==89727==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 136 byte(s) in 1 object(s) allocated from:
#0 0x5b9838 in operator new(unsigned long)
/repo/uabkaka/tmp/llvm/projects/compiler-
rt/lib/asan/asan_new_delete.cc:106
#1 0xc50879 in make_unique
/proj/flexasic/app/llvm/8.0/bin/../include/c++/v1/memory:3132:28
#2 0xc50879 in refSlab /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../../clang-tools-extra/clangd/unittests/FileIndexTests.cpp:87
#3 0xc50879 in clang::clangd::(anonymous
namespace)::FileShardedIndexTest_Sharding_Test::TestBody()
/repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-sanitize-
asan/llvm/build-all-asan/../../clang-tools-
extra/clangd/unittests/FileIndexTests.cpp:535
#4 0x1620190 in HandleExceptionsInMethodIfSupported /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc
#5 0x1620190 in testing::Test::Run() /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:2474
#6 0x1623875 in testing::TestInfo::Run() /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:2656:11
#7 0x1624cf0 in testing::TestCase::Run() /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:2774:28
#8 0x1643714 in testing::internal::UnitTestImpl::RunAllTests()
/repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-sanitize-
asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:4649:43
#9 0x16428c0 in
HandleExceptionsInMethodIfSupported /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc
#10 0x16428c0 in testing::UnitTest::Run() /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:4257
#11 0x16048f0 in RUN_ALL_TESTS /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/include/gtest/gtest.h:2233:46
#12 0x16048f0 in main /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/UnitTestMain/TestMain.cpp:50
#13 0x7f558b333544 in __libc_start_main (/lib64/libc.so.6+0x22544)

SUMMARY: AddressSanitizer: 136 byte(s) leaked in 1 allocation(s).

/Mikael

On Wed, 2020-04-15 at 00:15 -0700, Kadir Cetinkaya via cfe-commits
wrote:
> Author: Kadir Cetinkaya
> Date: 2020-04-15T09:10:10+02:00
> New Revision: dffa9dfbda56820c02e357ad34c24ce8759b4d26
> 
> URL: 
> https://protect2.fireeye.com/v1/url?k=1ed901c9-4253d508-1ed94152-863d9bcb726f-37cce004cef08ce5&q=1&e=d51603fa-ef7d-4c66-99fd-b868e84ed659&u=https%3A%2F%2Fgithub.com%2Fllvm%2Fllvm-project%2Fcommit%2Fdffa9dfbda56820c02e357ad34c24ce8759b4d26
> DIFF: 
> https://protect2.fireeye.com/v1/url?k=27955bfa-7b1f8f3b-27951b61-863d9bcb726f-307938d8468e38e8&q=1&e=d51603fa-ef7d-4c66-99fd-b868e84ed659&u=https%3A%2F%2Fgithub.com%2Fllvm%2Fllvm-project%2Fcommit%2Fdffa9dfbda56820c02e357ad34c24ce8759b4d26.diff
> 
> LOG: [clangd] Shard preamble symbols in dynamic index
> 
> Summary:
> This reduces memory usage by dynamic index from more than 400MB to
> 32MB
> when all files in clang-tools-extra/clangd/*.cpp are active in
> clangd.
> 
> Reviewers: sammccall
> 
> Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95,
> cfe-commits
> 
> Tags: #clang
> 
> Differential Revision: https://reviews.llvm.org/D77732
> 
> Added: 
> 
> 
> Modified: 
> clang-tools-extra/clangd/index/Background.cpp
> clang-tools-extra/clangd/index/FileIndex.cpp
> clang-tools-extra/clangd/index/FileIndex.h
> clang-tools-extra/clangd/index/SymbolCollector.cpp
> clang-tools-extra/clangd/unittests/FileIndexTests.cpp
> clang-tools-extra/clangd/unittests/TestTU.cpp
> 
> Removed: 
> 
> 
> 
> #
> ###
> diff  --git a/clang-tools-extra/clangd/index/Background.cpp b/clang-
> tools-extra/clangd/index/Background.cpp
> index 1c26dd48093e..4c5719d0526c 100644
> --- a/clang-tools-extra/clangd/index/Background.cpp
> +++ b/clang-tools-extra/clangd/index/Background.cpp
> @@ -61,51 +61,6 @@ namespace clang {
>  namespace clangd {
>  namespace {
>  
> -// Resolves URI to file paths with cache.
> -class URIToFileCache {
> -public:
> -  URIToFileCache(llvm::StringRef HintPath) : HintPath(HintPath) {}
> -
> -  llvm::StringRef resolve(llvm::StringRe

Re: [clang-tools-extra] dffa9df - [clangd] Shard preamble symbols in dynamic index

[Mikael Holmén via cfe-commits]

On Fri, 2020-04-17 at 15:02 +0300, Kadir Çetinkaya wrote:
> Thanks Mikael,
> 
> 66b54d586fa73499714e2bfef3cedffeabb08f34 should fix this.
> 

Yep, now it runs without complaints.

Thanks!
/Mikael

> On Fri, Apr 17, 2020 at 2:42 PM Mikael Holmén <
> mikael.hol...@ericsson.com> wrote:
> > Hi Kadir,
> > 
> > I noticed in our buildbots that run with sanitizers that we got a
> > new
> > complaint with this commit. It's still there on current top-of-tree 
> > now
> > so the fixes you pushed after this patch doesn't seem to address
> > this
> > one:
> > 
> > ==89727==ERROR: LeakSanitizer: detected memory leaks
> > 
> > Direct leak of 136 byte(s) in 1 object(s) allocated from:
> > #0 0x5b9838 in operator new(unsigned long)
> > /repo/uabkaka/tmp/llvm/projects/compiler-
> > rt/lib/asan/asan_new_delete.cc:106
> > #1 0xc50879 in make_unique > clang::clangd::RefSlab>
> > /proj/flexasic/app/llvm/8.0/bin/../include/c++/v1/memory:3132:28
> > #2 0xc50879 in refSlab /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../../clang-tools-extra/clangd/unittests/FileIndexTests.cpp:87
> > #3 0xc50879 in clang::clangd::(anonymous
> > namespace)::FileShardedIndexTest_Sharding_Test::TestBody()
> > /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
> > sanitize-
> > asan/llvm/build-all-asan/../../clang-tools-
> > extra/clangd/unittests/FileIndexTests.cpp:535
> > #4 0x1620190 in
> > HandleExceptionsInMethodIfSupported > void> /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
> > sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc
> > #5 0x1620190 in testing::Test::Run() /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc:2474
> > #6 0x1623875 in testing::TestInfo::Run()
> > /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc:2656:11
> > #7 0x1624cf0 in testing::TestCase::Run()
> > /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc:2774:28
> > #8 0x1643714 in testing::internal::UnitTestImpl::RunAllTests()
> > /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
> > sanitize-
> > asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc:4649:43
> > #9 0x16428c0 in
> > HandleExceptionsInMethodIfSupported > ,
> > bool> /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
> > sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc
> > #10 0x16428c0 in testing::UnitTest::Run()
> > /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc:4257
> > #11 0x16048f0 in RUN_ALL_TESTS /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/include/gtest/gtest.h:2233:46
> > #12 0x16048f0 in main /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/UnitTestMain/TestMain.cpp:50
> > #13 0x7f558b333544 in __libc_start_main
> > (/lib64/libc.so.6+0x22544)
> > 
> > SUMMARY: AddressSanitizer: 136 byte(s) leaked in 1 allocation(s).
> > 
> > /Mikael
> > 
> > On Wed, 2020-04-15 at 00:15 -0700, Kadir Cetinkaya via cfe-commits
> > wrote:
> > > Author: Kadir Cetinkaya
> > > Date: 2020-04-15T09:10:10+02:00
> > > New Revision: dffa9dfbda56820c02e357ad34c24ce8759b4d26
> > > 
> > > URL: 
> > > 
> > https://protect2.fireeye.com/v1/url?k=1ed901c9-4253d508-1ed94152-863d9bcb726f-37cce004cef08ce5&q=1&e=d51603fa-ef7d-4c66-99fd-b868e84ed659&u=https%3A%2F%2Fgithub.com%2Fllvm%2Fllvm-project%2Fcommit%2Fdffa9dfbda56820c02e357ad34c24ce8759b4d26
> > > DIFF: 
> > > 
> > https://protect2.fireeye.com/v1/url?k=27955bfa-7b1f8f3b-27951b61-863d9bcb726f-307938d8468e38e8&q=1&e=d51603fa-ef7d-4c66-99fd-b868e84ed659&u=https%3A%2F%2Fgithub.com%2Fllvm%2Fllvm-project%2Fcommit%2Fdffa9dfbda56820c02e357ad34c24ce8759b4d26.diff
> > > 
> > > LOG: [clangd] Shard preamble symbols in dynamic index
> > > 
> > > Summary:
> > > This reduces memory usage by dynamic index from more than 400MB
> > to
> > > 32MB
> > > when all files in clang-tools-extra/clangd/*.cpp are active in
> > > clangd.
> > > 
> > > Reviewers: sammccall
> > > 
> > > Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman,
> > usaxena95,
> > > cfe-commits
> > > 
> > > Tags: #clang
> > > 
> > > Differential Revision: https://reviews.llvm.org/D77732
> > > 
> > > Added: 
> > > 
> > > 
> > > Modified: 
> > > clang-tools-extra/clangd/index/Background.cpp
> > > clang-tools-extra/clangd/index/FileIndex.cpp
> > > clang-tools-extra/clangd/index/FileIndex.h
> > > clang-tools-extra/clangd/index/SymbolCollector.cpp

Re: [clang] 2214b90 - [clangd] Make signatureHelp work with stale preambles

[Mikael Holmén via cfe-commits]

Hi Kadir,

I start seeing some sanitizer complaints with this commit for the
following two testcases:
  ./ClangdTests/PreamblePatchTest.ContainsNewIncludes
  ./ClangdTests/PreamblePatchTest.IncludeParsing

The complaints look like this:

=
==75126==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 369 byte(s) in 4 object(s) allocated from:
#0 0x5bbe40 in operator new(unsigned long, std::nothrow_t const&)
/repo/uabkaka/tmp/llvm/projects/compiler-
rt/lib/asan/asan_new_delete.cc:112
#1 0x149a3e9 in
llvm::WritableMemoryBuffer::getNewUninitMemBuffer(unsigned long,
llvm::Twine const&) /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../lib/Support/MemoryBuffer.cpp:298:34
#2 0x1498db3 in getMemBufferCopyImpl /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../lib/Support/MemoryBuffer.cpp:127:14
#3 0x1498db3 in
llvm::MemoryBuffer::getMemBufferCopy(llvm::StringRef, llvm::Twine
const&) /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
sanitize-asan/llvm/build-all-asan/../lib/Support/MemoryBuffer.cpp:136
#4 0x506012e in
clang::clangd::PreamblePatch::apply(clang::CompilerInvocation&) const
/repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-sanitize-
asan/llvm/build-all-asan/../../clang-tools-
extra/clangd/Preamble.cpp:337:7
#5 0xf910e6 in clang::clangd::(anonymous
namespace)::PreamblePatchTest_IncludeParsing_Test::TestBody()
/repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-sanitize-
asan/llvm/build-all-asan/../../clang-tools-
extra/clangd/unittests/PreambleTests.cpp:91:57
#6 0x164e8e0 in HandleExceptionsInMethodIfSupported /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc
#7 0x164e8e0 in testing::Test::Run() /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:2474
#8 0x1651fc5 in testing::TestInfo::Run() /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:2656:11
#9 0x1653440 in testing::TestCase::Run() /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:2774:28
#10 0x1671e64 in testing::internal::UnitTestImpl::RunAllTests()
/repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-sanitize-
asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:4649:43
#11 0x1671010 in
HandleExceptionsInMethodIfSupported /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc
#12 0x1671010 in testing::UnitTest::Run() /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:4257
#13 0x1633040 in RUN_ALL_TESTS /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/include/gtest/gtest.h:2233:46
#14 0x1633040 in main /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/UnitTestMain/TestMain.cpp:50
#15 0x7f7dfdfe6544 in __libc_start_main (/lib64/libc.so.6+0x22544)

SUMMARY: AddressSanitizer: 369 byte(s) leaked in 4 allocation(s).

Regards,
Mikael

On Tue, 2020-04-21 at 01:34 -0700, Kadir Cetinkaya via cfe-commits
wrote:
> Author: Kadir Cetinkaya
> Date: 2020-04-21T10:27:26+02:00
> New Revision: 2214b9076f1d3a4784820c4479e2417685e5c980
> 
> URL: 
> https://github.com/llvm/llvm-project/commit/2214b9076f1d3a4784820c4479e2417685e5c980
> DIFF: 
> https://github.com/llvm/llvm-project/commit/2214b9076f1d3a4784820c4479e2417685e5c980.diff
> 
> LOG: [clangd] Make signatureHelp work with stale preambles
> 
> Summary:
> This is achieved by calculating newly added includes and implicitly
> parsing them as if they were part of the main file.
> 
> This also gets rid of the need for consistent preamble reads.
> 
> Reviewers: sammccall
> 
> Subscribers: ilya-biryukov, javed.absar, MaskRay, jkorous, mgrang,
> arphaman, jfb, usaxena95, cfe-commits
> 
> Tags: #clang
> 
> Differential Revision: https://reviews.llvm.org/D77392
> 
> Added: 
> clang-tools-extra/clangd/unittests/PreambleTests.cpp
> 
> Modified: 
> clang-tools-extra/clangd/ClangdServer.cpp
> clang-tools-extra/clangd/CodeComplete.cpp
> clang-tools-extra/clangd/Preamble.cpp
> clang-tools-extra/clangd/Preamble.h
> clang-tools-extra/clangd/TUScheduler.cpp
> clang-tools-extra/clangd/TUScheduler.h
> clang-tools-extra/clangd/unittests/CMakeLists.txt
> clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
> clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp

Re: [clang] 2214b90 - [clangd] Make signatureHelp work with stale preambles

[Mikael Holmén via cfe-commits]

On Thu, 2020-04-23 at 17:46 +0300, Kadir Çetinkaya wrote:
> Thanks Mikael, sent out an ugly fix
> at 89cb5d558895706e053bc3af972aa5b15aa82863 to get sanitizer build
> bots running.
> 

Nice, thanks! Now our buildbots went silent again.

/Mikael

> Will change the testing scheme for a proper fix.
> 
> On Thu, Apr 23, 2020 at 4:53 PM Mikael Holmén <
> mikael.hol...@ericsson.com> wrote:
> > Hi Kadir,
> > 
> > I start seeing some sanitizer complaints with this commit for the
> > following two testcases:
> >   ./ClangdTests/PreamblePatchTest.ContainsNewIncludes
> >   ./ClangdTests/PreamblePatchTest.IncludeParsing
> > 
> > The complaints look like this:
> > 
> > =
> > ==75126==ERROR: LeakSanitizer: detected memory leaks
> > 
> > Direct leak of 369 byte(s) in 4 object(s) allocated from:
> > #0 0x5bbe40 in operator new(unsigned long, std::nothrow_t
> > const&)
> > /repo/uabkaka/tmp/llvm/projects/compiler-
> > rt/lib/asan/asan_new_delete.cc:112
> > #1 0x149a3e9 in
> > llvm::WritableMemoryBuffer::getNewUninitMemBuffer(unsigned long,
> > llvm::Twine const&) /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../lib/Support/MemoryBuffer.cpp:298:34
> > #2 0x1498db3 in getMemBufferCopyImpl /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../lib/Support/MemoryBuffer.cpp:127:14
> > #3 0x1498db3 in
> > llvm::MemoryBuffer::getMemBufferCopy(llvm::StringRef, llvm::Twine
> > const&) /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-
> > master-
> > sanitize-asan/llvm/build-all-
> > asan/../lib/Support/MemoryBuffer.cpp:136
> > #4 0x506012e in
> > clang::clangd::PreamblePatch::apply(clang::CompilerInvocation&)
> > const
> > /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
> > sanitize-
> > asan/llvm/build-all-asan/../../clang-tools-
> > extra/clangd/Preamble.cpp:337:7
> > #5 0xf910e6 in clang::clangd::(anonymous
> > namespace)::PreamblePatchTest_IncludeParsing_Test::TestBody()
> > /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
> > sanitize-
> > asan/llvm/build-all-asan/../../clang-tools-
> > extra/clangd/unittests/PreambleTests.cpp:91:57
> > #6 0x164e8e0 in
> > HandleExceptionsInMethodIfSupported > void> /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
> > sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc
> > #7 0x164e8e0 in testing::Test::Run() /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc:2474
> > #8 0x1651fc5 in testing::TestInfo::Run()
> > /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc:2656:11
> > #9 0x1653440 in testing::TestCase::Run()
> > /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc:2774:28
> > #10 0x1671e64 in testing::internal::UnitTestImpl::RunAllTests()
> > /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
> > sanitize-
> > asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc:4649:43
> > #11 0x1671010 in
> > HandleExceptionsInMethodIfSupported > ,
> > bool> /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
> > sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc
> > #12 0x1671010 in testing::UnitTest::Run()
> > /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc:4257
> > #13 0x1633040 in RUN_ALL_TESTS /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/include/gtest/gtest.h:2233:46
> > #14 0x1633040 in main /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/UnitTestMain/TestMain.cpp:50
> > #15 0x7f7dfdfe6544 in __libc_start_main
> > (/lib64/libc.so.6+0x22544)
> > 
> > SUMMARY: AddressSanitizer: 369 byte(s) leaked in 4 allocation(s).
> > 
> > Regards,
> > Mikael
> > 
> > On Tue, 2020-04-21 at 01:34 -0700, Kadir Cetinkaya via cfe-commits
> > wrote:
> > > Author: Kadir Cetinkaya
> > > Date: 2020-04-21T10:27:26+02:00
> > > New Revision: 2214b9076f1d3a4784820c4479e2417685e5c980
> > > 
> > > URL: 
> > > 
> > https://github.com/llvm/llvm-project/commit/2214b9076f1d3a4784820c4479e2417685e5c980
> > > DIFF: 
> > > 
> > https://github.com/llvm/llvm-project/commit/2214b9076f1d3a4784820c4479e2417685e5c980.diff
> > > 
> > > LOG: [clangd] Make signatureHelp work with stale preambles
> > > 
> > > Summary:
> > > This is achieved by calculating newly added includes and
> > implicitly
> > > parsing them as if they were part of the m

Re: r281785 - CodeGen: Add more checks to nobuiltin.c test, add a negative test.

[Mikael Holmén via cfe-commits]

Hi,

On 09/17/2016 12:05 AM, Peter Collingbourne via cfe-commits wrote:

Author: pcc
Date: Fri Sep 16 17:05:53 2016
New Revision: 281785

URL: http://llvm.org/viewvc/llvm-project?rev=281785&view=rev
Log:
CodeGen: Add more checks to nobuiltin.c test, add a negative test.

Modified:
cfe/trunk/test/CodeGen/nobuiltin.c

Modified: cfe/trunk/test/CodeGen/nobuiltin.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/nobuiltin.c?rev=281785&r1=281784&r2=281785&view=diff
==
--- cfe/trunk/test/CodeGen/nobuiltin.c (original)
+++ cfe/trunk/test/CodeGen/nobuiltin.c Fri Sep 16 17:05:53 2016
@@ -1,17 +1,19 @@
-// RUN: %clang_cc1 -fno-builtin -O1 -S -o - %s | FileCheck %s
-// RUN: %clang_cc1 -fno-builtin-memset -O1 -S -o - %s | FileCheck 
-check-prefix=MEMSET %s
+// RUN: %clang_cc1 -O1 -S -o - %s | FileCheck -check-prefix=STRCPY 
-check-prefix=MEMSET %s
+// RUN: %clang_cc1 -fno-builtin -O1 -S -o - %s | FileCheck 
-check-prefix=NOSTRCPY -check-prefix=NOMEMSET %s
+// RUN: %clang_cc1 -fno-builtin-memset -O1 -S -o - %s | FileCheck 
-check-prefix=STRCPY -check-prefix=NOMEMSET %s

 void PR13497() {
   char content[2];
   // make sure we don't optimize this call to strcpy()
-  // CHECK: __strcpy_chk
+  // STRCPY-NOT: __strcpy_chk
+  // NOSTRCPY: __strcpy_chk
   __builtin___strcpy_chk(content, "", 1);
 }

 void PR4941(char *s) {
   // Make sure we don't optimize this loop to a memset().
-  // MEMSET-LABEL: PR4941:
-  // MEMSET-NOT: memset
+  // NOMEMSET-NOT: memset
+  // MEMSET: memset


I suppose this is a general problem for CHECK-NOT:s, but I happened to 
have a repo with "memset" in the name, and then this NOMEMSET-NOT failed 
because it found "memset" in the file path.


So maybe change so it looks for "memset@" or something that might at 
least be less likely to appear in the path? Ideally the test should ofc 
be changed so it only looks for "memset" inside the PR4941 function but 
I'm too noobish on FileCheck to know if that's possible,


Regards,
Mikael


   for (unsigned i = 0; i < 8192; ++i)
 s[i] = 0;
 }


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


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

Re: [clang-tools-extra] r320486 - [clangd] Introduce a "Symbol" class.

[Mikael Holmén via cfe-commits]

On 12/13/2017 02:09 AM, Evgenii Stepanov via cfe-commits wrote:

Hi,

this does not compile for me because of a tag mismatch:
clang-tools-extra/clangd/index/Index.h:52:10: error: class
'DenseMapInfo' was previously declared as a struct
[-Werror,-Wmismatched-tags]
   friend class llvm::DenseMapInfo;



Yes, this doesn't compile for me either.

/Mikael


On Tue, Dec 12, 2017 at 7:42 AM, Haojian Wu via cfe-commits
 wrote:

Author: hokein
Date: Tue Dec 12 07:42:10 2017
New Revision: 320486

URL: http://llvm.org/viewvc/llvm-project?rev=320486&view=rev
Log:
[clangd] Introduce a "Symbol" class.

Summary:
* The "Symbol" class represents a C++ symbol in the codebase, containing all the
   information of a C++ symbol needed by clangd. clangd will use it in clangd's
   AST/dynamic index and global/static index (code completion and code
   navigation).
* The SymbolCollector (another IndexAction) will be used to recollect the
   symbols when the source file is changed (for ASTIndex), or to generate
   all C++ symbols for the whole project.

In the long term (when index-while-building is ready), clangd should share a
same "Symbol" structure and IndexAction with index-while-building, but
for now we want to have some stuff working in clangd.

Reviewers: ioeric, sammccall, ilya-biryukov, malaperle

Reviewed By: sammccall

Subscribers: malaperle, klimek, mgorny, cfe-commits

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

Added:
 clang-tools-extra/trunk/clangd/index/
 clang-tools-extra/trunk/clangd/index/Index.cpp
 clang-tools-extra/trunk/clangd/index/Index.h
 clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp
 clang-tools-extra/trunk/clangd/index/SymbolCollector.h
 clang-tools-extra/trunk/unittests/clangd/SymbolCollectorTests.cpp
Modified:
 clang-tools-extra/trunk/clangd/CMakeLists.txt
 clang-tools-extra/trunk/unittests/clangd/CMakeLists.txt

Modified: clang-tools-extra/trunk/clangd/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/CMakeLists.txt?rev=320486&r1=320485&r2=320486&view=diff
==
--- clang-tools-extra/trunk/clangd/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clangd/CMakeLists.txt Tue Dec 12 07:42:10 2017
@@ -19,6 +19,8 @@ add_clang_library(clangDaemon
Protocol.cpp
ProtocolHandlers.cpp
Trace.cpp
+  index/Index.cpp
+  index/SymbolCollector.cpp

LINK_LIBS
clangAST

Added: clang-tools-extra/trunk/clangd/index/Index.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/Index.cpp?rev=320486&view=auto
==
--- clang-tools-extra/trunk/clangd/index/Index.cpp (added)
+++ clang-tools-extra/trunk/clangd/index/Index.cpp Tue Dec 12 07:42:10 2017
@@ -0,0 +1,49 @@
+//===--- Index.cpp ---*- 
C++-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "Index.h"
+
+#include "llvm/Support/SHA1.h"
+
+namespace clang {
+namespace clangd {
+
+namespace {
+ArrayRef toArrayRef(StringRef S) {
+  return {reinterpret_cast(S.data()), S.size()};
+}
+} // namespace
+
+SymbolID::SymbolID(llvm::StringRef USR)
+: HashValue(llvm::SHA1::hash(toArrayRef(USR))) {}
+
+SymbolSlab::const_iterator SymbolSlab::begin() const {
+  return Symbols.begin();
+}
+
+SymbolSlab::const_iterator SymbolSlab::end() const {
+  return Symbols.end();
+}
+
+SymbolSlab::const_iterator SymbolSlab::find(const SymbolID& SymID) const {
+  return Symbols.find(SymID);
+}
+
+void SymbolSlab::freeze() {
+  Frozen = true;
+}
+
+void SymbolSlab::insert(Symbol S) {
+  assert(!Frozen &&
+ "Can't insert a symbol after the slab has been frozen!");
+  Symbols[S.ID] = std::move(S);
+}
+
+} // namespace clangd
+} // namespace clang

Added: clang-tools-extra/trunk/clangd/index/Index.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/Index.h?rev=320486&view=auto
==
--- clang-tools-extra/trunk/clangd/index/Index.h (added)
+++ clang-tools-extra/trunk/clangd/index/Index.h Tue Dec 12 07:42:10 2017
@@ -0,0 +1,136 @@
+//===--- Symbol.h ---*- 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_CLANGD_INDEX_INDEX_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANGD_INDEX_INDEX_H
+
+#include "clang/Index/IndexSymbol.h"
+#include "llvm/ADT/

Re: [clang] ec3060c - [AST] Refactor propagation of dependency bits. NFC

[Mikael Holmén via cfe-commits]

Hi Hokein, Ilya,

Clang warns on this code when compiled without asserts:

../../clang/lib/AST/TemplateName.cpp:189:3: error: unannotated fall-
through between switch labels [-Werror,-Wimplicit-fallthrough]
  default:
  ^
../../clang/lib/AST/TemplateName.cpp:189:3: note: insert 'break;' to
avoid fall-through
  default:
  ^
  break; 
1 error generated.


The code is

  case TemplateName::NameKind::OverloadedTemplate:
assert(false && "overloaded templates shouldn't survive to here.");
  default:

I'm not sure if there should be a break after the assert (not sure if
someone would warn about that) or should there be a LLVM_FALLTHROUGH;
or should the assert perhaps be an llvm_unreachable?

/Mikael

On Wed, 2020-03-04 at 02:25 -0800, Haojian Wu via cfe-commits wrote:
> Author: Ilya Biryukov
> Date: 2020-03-04T11:25:17+01:00
> New Revision: ec3060c72de6ab6992269318d92764199856e5fe
> 
> URL: 
> https://github.com/llvm/llvm-project/commit/ec3060c72de6ab6992269318d92764199856e5fe
> DIFF: 
> https://github.com/llvm/llvm-project/commit/ec3060c72de6ab6992269318d92764199856e5fe.diff
> 
> LOG: [AST] Refactor propagation of dependency bits. NFC
> 
> Summary:
> This changes introduces an enum to represent dependencies as a
> bitmask
> and extract common patterns from code that computes dependency bits
> into
> helper functions.
> 
> Reviewers: rsmith, martong, shafik, ilya-biryukov, hokein
> 
> Subscribers: hokein, sammccall, Mordante, riccibruno,
> merge_guards_bot, rnkovacs, cfe-commits
> 
> Tags: #clang
> 
> Differential Revision: https://reviews.llvm.org/D71920
> 
> Added: 
> clang/include/clang/AST/DependencyFlags.h
> 
> Modified: 
> clang/include/clang/AST/Expr.h
> clang/include/clang/AST/ExprConcepts.h
> clang/include/clang/AST/NestedNameSpecifier.h
> clang/include/clang/AST/Stmt.h
> clang/include/clang/AST/TemplateBase.h
> clang/include/clang/AST/TemplateName.h
> clang/include/clang/AST/Type.h
> clang/lib/AST/ASTImporter.cpp
> clang/lib/AST/Expr.cpp
> clang/lib/AST/ExprCXX.cpp
> clang/lib/AST/ExprConcepts.cpp
> clang/lib/AST/ExprObjC.cpp
> clang/lib/AST/NestedNameSpecifier.cpp
> clang/lib/AST/TemplateBase.cpp
> clang/lib/AST/TemplateName.cpp
> clang/lib/Sema/SemaOverload.cpp
> clang/lib/Serialization/ASTReaderStmt.cpp
> 
> Removed: 
> 
> 
> 
> #
> ###
> diff  --git a/clang/include/clang/AST/DependencyFlags.h
> b/clang/include/clang/AST/DependencyFlags.h
> new file mode 100644
> index ..c27016aa9aec
> --- /dev/null
> +++ b/clang/include/clang/AST/DependencyFlags.h
> @@ -0,0 +1,138 @@
> +//===--- DependencyFlags.h ---
> -===//
> +//
> +// Part of the LLVM Project, under the Apache License v2.0 with LLVM
> Exceptions.
> +// See https://llvm.org/LICENSE.txt for license information.
> +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
> +//
> +//===---
> ---===//
> +#ifndef LLVM_CLANG_AST_DEPENDENCYFLAGS_H
> +#define LLVM_CLANG_AST_DEPENDENCYFLAGS_H
> +
> +#include "clang/Basic/BitmaskEnum.h"
> +#include "llvm/ADT/BitmaskEnum.h"
> +#include 
> +
> +namespace clang {
> +struct ExprDependenceScope {
> +  enum ExprDependence : uint8_t {
> +UnexpandedPack = 1,
> +Instantiation = 2,
> +Type = 4,
> +Value = 8,
> +
> +None = 0,
> +All = 15,
> +
> +TypeInstantiation = Type | Instantiation,
> +ValueInstantiation = Value | Instantiation,
> +TypeValueInstantiation = Type | Value | Instantiation,
> +
> +LLVM_MARK_AS_BITMASK_ENUM(/*LargestValue=*/Value)
> +  };
> +};
> +using ExprDependence = ExprDependenceScope::ExprDependence;
> +static constexpr unsigned ExprDependenceBits = 4;
> +
> +struct TypeDependenceScope {
> +  enum TypeDependence : uint8_t {
> +/// Whether this type contains an unexpanded parameter pack
> +/// (for C++11 variadic templates)
> +UnexpandedPack = 1,
> +/// Whether this type somehow involves a template parameter,
> even
> +/// if the resolution of the type does not depend on a template
> parameter.
> +Instantiation = 2,
> +/// Whether this type is a dependent type (C++ [temp.dep.type]).
> +Dependent = 4,
> +/// Whether this type is a variably-modified type (C99 6.7.5).
> +VariablyModified = 8,
> +
> +None = 0,
> +All = 15,
> +
> +DependentInstantiation = Dependent | Instantiation,
> +
> +LLVM_MARK_AS_BITMASK_ENUM(/*LargestValue=*/VariablyModified)
> +  };
> +};
> +using TypeDependence = TypeDependenceScope::TypeDependence;
> +static constexpr unsigned TypeDependenceBits = 4;
> +
> +#define
> LLVM_COMMON_DEPENDENCE(NAME) 
>   \
> +  struct NAME##Scope
> { \
> +enum NAME : uint8_t
> {  \

Re: [clang-tools-extra] r328270 - [clang-doc] Reland "[clang-doc] Setup clang-doc frontend framework"

[Mikael Holmén via cfe-commits]

Hi Julie

If I compile without asserts this patch gives me

../tools/clang/tools/extra/clang-doc/BitcodeWriter.cpp:260:15: error: 
unused variable 'BlockIdName' [-Werror,-Wunused-variable]

  const auto &BlockIdName = BlockIdNameMap[BID];
  ^
1 error generated.

Regards,
Mikael

On 03/23/2018 12:34 AM, Julie Hockett via cfe-commits wrote:

Author: juliehockett
Date: Thu Mar 22 16:34:46 2018
New Revision: 328270

URL: http://llvm.org/viewvc/llvm-project?rev=328270&view=rev
Log:
[clang-doc] Reland "[clang-doc] Setup clang-doc frontend framework"

Fixed windows release build tests.

Added:
 clang-tools-extra/trunk/clang-doc/BitcodeWriter.cpp
 clang-tools-extra/trunk/clang-doc/BitcodeWriter.h
 clang-tools-extra/trunk/clang-doc/CMakeLists.txt
 clang-tools-extra/trunk/clang-doc/ClangDoc.cpp
 clang-tools-extra/trunk/clang-doc/ClangDoc.h
 clang-tools-extra/trunk/clang-doc/Mapper.cpp
 clang-tools-extra/trunk/clang-doc/Mapper.h
 clang-tools-extra/trunk/clang-doc/Representation.h
 clang-tools-extra/trunk/clang-doc/Serialize.cpp
 clang-tools-extra/trunk/clang-doc/Serialize.h
 clang-tools-extra/trunk/clang-doc/tool/CMakeLists.txt
 clang-tools-extra/trunk/clang-doc/tool/ClangDocMain.cpp
 clang-tools-extra/trunk/test/clang-doc/mapper-class-in-class.cpp
 clang-tools-extra/trunk/test/clang-doc/mapper-class-in-function.cpp
 clang-tools-extra/trunk/test/clang-doc/mapper-class.cpp
 clang-tools-extra/trunk/test/clang-doc/mapper-comments.cpp
 clang-tools-extra/trunk/test/clang-doc/mapper-enum.cpp
 clang-tools-extra/trunk/test/clang-doc/mapper-function.cpp
 clang-tools-extra/trunk/test/clang-doc/mapper-method.cpp
 clang-tools-extra/trunk/test/clang-doc/mapper-namespace.cpp
 clang-tools-extra/trunk/test/clang-doc/mapper-struct.cpp
 clang-tools-extra/trunk/test/clang-doc/mapper-union.cpp
Modified:
 clang-tools-extra/trunk/CMakeLists.txt
 clang-tools-extra/trunk/test/CMakeLists.txt

Modified: clang-tools-extra/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/CMakeLists.txt?rev=328270&r1=328269&r2=328270&view=diff
==
--- clang-tools-extra/trunk/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/CMakeLists.txt Thu Mar 22 16:34:46 2018
@@ -7,6 +7,7 @@ add_subdirectory(clang-tidy-vs)
  endif()
  
  add_subdirectory(change-namespace)

+add_subdirectory(clang-doc)
  add_subdirectory(clang-query)
  add_subdirectory(clang-move)
  add_subdirectory(clangd)

Added: clang-tools-extra/trunk/clang-doc/BitcodeWriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-doc/BitcodeWriter.cpp?rev=328270&view=auto
==
--- clang-tools-extra/trunk/clang-doc/BitcodeWriter.cpp (added)
+++ clang-tools-extra/trunk/clang-doc/BitcodeWriter.cpp Thu Mar 22 16:34:46 2018
@@ -0,0 +1,510 @@
+//===--  BitcodeWriter.cpp - ClangDoc Bitcode Writer *- C++ 
-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "BitcodeWriter.h"
+#include "llvm/ADT/IndexedMap.h"
+#include 
+
+namespace clang {
+namespace doc {
+
+// Since id enums are not zero-indexed, we need to transform the given id into
+// its associated index.
+struct BlockIdToIndexFunctor {
+  using argument_type = unsigned;
+  unsigned operator()(unsigned ID) const { return ID - BI_FIRST; }
+};
+
+struct RecordIdToIndexFunctor {
+  using argument_type = unsigned;
+  unsigned operator()(unsigned ID) const { return ID - RI_FIRST; }
+};
+
+using AbbrevDsc = void (*)(std::shared_ptr &Abbrev);
+
+static void AbbrevGen(std::shared_ptr &Abbrev,
+  const std::initializer_list Ops) {
+  for (const auto &Op : Ops)
+Abbrev->Add(Op);
+}
+
+static void BoolAbbrev(std::shared_ptr &Abbrev) {
+  AbbrevGen(Abbrev,
+{// 0. Boolean
+ llvm::BitCodeAbbrevOp(llvm::BitCodeAbbrevOp::Fixed,
+   BitCodeConstants::BoolSize)});
+}
+
+static void IntAbbrev(std::shared_ptr &Abbrev) {
+  AbbrevGen(Abbrev,
+{// 0. Fixed-size integer
+ llvm::BitCodeAbbrevOp(llvm::BitCodeAbbrevOp::Fixed,
+   BitCodeConstants::IntSize)});
+}
+
+static void SymbolIDAbbrev(std::shared_ptr &Abbrev) {
+  AbbrevGen(Abbrev,
+{// 0. Fixed-size integer (length of the sha1'd USR)
+ llvm::BitCodeAbbrevOp(llvm::BitCodeAbbrevOp::Fixed,
+   BitCodeConstants::USRLengthSize),
+ // 1. Fixed-size array of Char6 (USR)
+ llvm::BitCodeAbbrevOp(llvm::BitCodeAbbrevOp::Array),
+ llvm::BitCodeAbbrevOp(ll

Re: [clang-tools-extra] r329448 - [clang-tidy] Check if grand-..parent's virtual method was called instead of overridden parent's.

[Mikael Holmén via cfe-commits]

Hi Zivony,

From this patch:

> +void ParentVirtualCallCheck::check(const MatchFinder::MatchResult 
&Result) {
> +  const auto *MatchedDecl = 
Result.Nodes.getNodeAs("call");

> +  assert(MatchedDecl);
> +


The code above yields a warning when compiled without asserts since 
MatchedDecl is not used then:


../tools/clang/tools/extra/clang-tidy/bugprone/ParentVirtualCallCheck.cpp:101:15: 
error: unused variable 'MatchedDecl' [-Werror,-Wunused-variable]
  const auto *MatchedDecl = 
Result.Nodes.getNodeAs("call");

  ^
1 error generated.

Regards,
Mikael



On 04/06/2018 10:02 PM, Zinovy Nis via cfe-commits wrote:

Author: zinovy.nis
Date: Fri Apr  6 13:02:50 2018
New Revision: 329448

URL: http://llvm.org/viewvc/llvm-project?rev=329448&view=rev
Log:
[clang-tidy] Check if grand-..parent's virtual method was called instead of 
overridden parent's.

class A {...int virtual foo() {...}...};
class B: public A {...int foo() override {...}...};
class C: public B {...int foo() override {... A::foo()...}};
    warning: qualified name 
A::foo refers to a member overridden in subclass; did you mean 'B'? 
[bugprone-parent-virtual-call]

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

Added:
 clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp   
(with props)
 clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.h   
(with props)
 
clang-tools-extra/trunk/docs/clang-tidy/checks/bugprone-parent-virtual-call.rst 
  (with props)
 clang-tools-extra/trunk/test/clang-tidy/bugprone-parent-virtual-call.cpp   
(with props)
Modified:
 clang-tools-extra/trunk/clang-tidy/bugprone/BugproneTidyModule.cpp
 clang-tools-extra/trunk/clang-tidy/bugprone/CMakeLists.txt
 clang-tools-extra/trunk/docs/ReleaseNotes.rst
 clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/bugprone/BugproneTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/BugproneTidyModule.cpp?rev=329448&r1=329447&r2=329448&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/bugprone/BugproneTidyModule.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/bugprone/BugproneTidyModule.cpp Fri Apr  
6 13:02:50 2018
@@ -28,6 +28,7 @@
  #include "MisplacedWideningCastCheck.h"
  #include "MoveForwardingReferenceCheck.h"
  #include "MultipleStatementMacroCheck.h"
+#include "ParentVirtualCallCheck.h"
  #include "SizeofContainerCheck.h"
  #include "SizeofExpressionCheck.h"
  #include "StringConstructorCheck.h"
@@ -90,6 +91,8 @@ public:
  "bugprone-move-forwarding-reference");
  CheckFactories.registerCheck(
  "bugprone-multiple-statement-macro");
+CheckFactories.registerCheck(
+"bugprone-parent-virtual-call");
  CheckFactories.registerCheck(
  "bugprone-sizeof-container");
  CheckFactories.registerCheck(

Modified: clang-tools-extra/trunk/clang-tidy/bugprone/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/CMakeLists.txt?rev=329448&r1=329447&r2=329448&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/bugprone/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/bugprone/CMakeLists.txt Fri Apr  6 
13:02:50 2018
@@ -20,6 +20,7 @@ add_clang_library(clangTidyBugproneModul
MisplacedWideningCastCheck.cpp
MoveForwardingReferenceCheck.cpp
MultipleStatementMacroCheck.cpp
+  ParentVirtualCallCheck.cpp
SizeofContainerCheck.cpp
SizeofExpressionCheck.cpp
StringConstructorCheck.cpp

Added: clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp?rev=329448&view=auto
==
--- clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp 
(added)
+++ clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp Fri 
Apr  6 13:02:50 2018
@@ -0,0 +1,154 @@
+//===--- ParentVirtualCallCheck.cpp - 
clang-tidy---===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "ParentVirtualCallCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Tooling/FixIt.h"
+#include "llvm/ADT/STLExtras.h"
+#include "llvm/ADT/SmallVector.h"
+#include 
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace bugprone {
+
+using BasesVector = llvm::SmallVector;

Re: r292562 - clang-format: fix fallback style set to "none" not always formatting

[Mikael Holmén via cfe-commits]

Hi Antonio,

The test case

Clang :: Format/style-on-command-line.cpp

fails for me since this commit.

test/Format/style-on-command-line.cpp:40:13: error: expected string not 
found in input

// CHECK10: {{^int\* i;$}}
^
:1:1: note: scanning from here
// RUN: clang-format -style="{BasedOnStyle: Google, IndentWidth: 8}" %s |
^
:61:16: note: possible intended match here
  // CHECK10: {{^int\* i;$}}
   ^

I suppose it works for you... Any idea what the problem can be?

Regards,
Mikael

On 01/20/2017 02:22 AM, Antonio Maiorano via cfe-commits wrote:

Author: amaiorano
Date: Thu Jan 19 19:22:42 2017
New Revision: 292562

URL: http://llvm.org/viewvc/llvm-project?rev=292562&view=rev
Log:
clang-format: fix fallback style set to "none" not always formatting

This fixes clang-format not formatting if fallback-style is explicitly set to
"none", and either a config file is found or YAML is passed in without a
"BasedOnStyle". With this change, passing "none" in these cases will have no
affect, and LLVM style will be used as the base style.

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

Modified:
cfe/trunk/lib/Format/Format.cpp
cfe/trunk/test/Format/style-on-command-line.cpp
cfe/trunk/unittests/Format/FormatTest.cpp

Modified: cfe/trunk/lib/Format/Format.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/Format.cpp?rev=292562&r1=292561&r2=292562&view=diff
==
--- cfe/trunk/lib/Format/Format.cpp (original)
+++ cfe/trunk/lib/Format/Format.cpp Thu Jan 19 19:22:42 2017
@@ -1888,8 +1888,8 @@ static FormatStyle::LanguageKind getLang
 }

 llvm::Expected getStyle(StringRef StyleName, StringRef FileName,
- StringRef FallbackStyle, StringRef Code,
- vfs::FileSystem *FS) {
+ StringRef FallbackStyleName,
+ StringRef Code, vfs::FileSystem *FS) {
   if (!FS) {
 FS = vfs::getRealFileSystem().get();
   }
@@ -1903,9 +1903,9 @@ llvm::Expected getStyle(Str
   (Code.contains("\n- (") || Code.contains("\n+ (")))
 Style.Language = FormatStyle::LK_ObjC;

-  // FIXME: If FallbackStyle is explicitly "none", format is disabled.
-  if (!getPredefinedStyle(FallbackStyle, Style.Language, &Style))
-return make_string_error("Invalid fallback style \"" + 
FallbackStyle.str());
+  FormatStyle FallbackStyle = getNoStyle();
+  if (!getPredefinedStyle(FallbackStyleName, Style.Language, &FallbackStyle))
+return make_string_error("Invalid fallback style \"" + FallbackStyleName);

   if (StyleName.startswith("{")) {
 // Parse YAML/JSON style from the command line.
@@ -1977,7 +1977,7 @@ llvm::Expected getStyle(Str
 return make_string_error("Configuration file(s) do(es) not support " +
  getLanguageName(Style.Language) + ": " +
  UnsuitableConfigFiles);
-  return Style;
+  return FallbackStyle;
 }

 } // namespace format

Modified: cfe/trunk/test/Format/style-on-command-line.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Format/style-on-command-line.cpp?rev=292562&r1=292561&r2=292562&view=diff
==
--- cfe/trunk/test/Format/style-on-command-line.cpp (original)
+++ cfe/trunk/test/Format/style-on-command-line.cpp Thu Jan 19 19:22:42 2017
@@ -11,6 +11,21 @@
 // RUN: clang-format -style=file -assume-filename=%T/foo.cpp < %s | FileCheck 
-strict-whitespace -check-prefix=CHECK7 %s
 // RUN: clang-format -style="{BasedOnStyle: LLVM, PointerBindsToType: true}" 
%s | FileCheck -strict-whitespace -check-prefix=CHECK8 %s
 // RUN: clang-format -style="{BasedOnStyle: WebKit, PointerBindsToType: 
false}" %s | FileCheck -strict-whitespace -check-prefix=CHECK9 %s
+
+// Fallback style tests
+// RUN: rm %T/_clang-format
+// Test no config file found, WebKit fallback style is applied
+// RUN: clang-format -style=file -fallback-style=WebKit -assume-filename=%T/foo.cpp < 
%s 2>&1 | FileCheck -strict-whitespace -check-prefix=CHECK10 %s
+// Test no config file and no fallback style, LLVM style is applied
+// RUN: clang-format -style=file -assume-filename=%T/foo.cpp < %s 2>&1 | 
FileCheck -strict-whitespace -check-prefix=CHECK11 %s
+// Test no config file and fallback style "none", no formatting is applied
+// RUN: clang-format -style=file -fallback-style=none -assume-filename=%T/foo.cpp < 
%s 2>&1 | FileCheck -strict-whitespace -check-prefix=CHECK12 %s
+// Test config file with no based style, and fallback style "none", formatting 
is applied
+// RUN: printf "IndentWidth: 6\n" > %T/_clang-format
+// RUN: clang-format -style=file -fallback-style=none -assume-filename=%T/foo.cpp < 
%s 2>&1 | FileCheck -strict-whitespace -check-prefix=CHECK13 %s
+// Test yaml with no based style, and fallback style "none", LLVM formatting 
applied
+

Re: r292562 - clang-format: fix fallback style set to "none" not always formatting

[Mikael Holmén via cfe-commits]

Hi,

On 01/20/2017 02:20 PM, Antonio Maiorano wrote:

Hi Mikael,

Just to be sure, did you build clang-format before running this test?


Yes I did. I compiled a clean trunk, ran the test, got the failure.



Possibly related, one of the tests I added was just removed for being
redundant:
https://reviews.llvm.org/D28943


Aha. I can't say I understand what's going on there, I don't even know 
how to change the default fallback style or what it is :)


Regards,

Mikael




On Fri, Jan 20, 2017 at 7:50 AM Mikael Holmén
mailto:mikael.hol...@ericsson.com>> wrote:

Hi Antonio,



The test case



Clang :: Format/style-on-command-line.cpp



fails for me since this commit.



test/Format/style-on-command-line.cpp:40:13: error: expected string not

found in input

// CHECK10: {{^int\* i;$}}

 ^

:1:1: note: scanning from here

// RUN: clang-format -style="{BasedOnStyle: Google, IndentWidth: 8}"
%s |

^

:61:16: note: possible intended match here

   // CHECK10: {{^int\* i;$}}

^



I suppose it works for you... Any idea what the problem can be?



Regards,

Mikael


On 01/20/2017 02:22 AM, Antonio Maiorano via cfe-commits wrote:

> Author: amaiorano

> Date: Thu Jan 19 19:22:42 2017

> New Revision: 292562

>

> URL: http://llvm.org/viewvc/llvm-project?rev=292562&view=rev

> Log:

> clang-format: fix fallback style set to "none" not always formatting

>

> This fixes clang-format not formatting if fallback-style is
explicitly set to

> "none", and either a config file is found or YAML is passed in
without a

> "BasedOnStyle". With this change, passing "none" in these cases
will have no

> affect, and LLVM style will be used as the base style.

>

> Differential Revision: https://reviews.llvm.org/D28844

>

> Modified:

> cfe/trunk/lib/Format/Format.cpp

> cfe/trunk/test/Format/style-on-command-line.cpp

> cfe/trunk/unittests/Format/FormatTest.cpp

>

> Modified: cfe/trunk/lib/Format/Format.cpp

> URL:

http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/Format.cpp?rev=292562&r1=292561&r2=292562&view=diff

>

==

> --- cfe/trunk/lib/Format/Format.cpp (original)

> +++ cfe/trunk/lib/Format/Format.cpp Thu Jan 19 19:22:42 2017

> @@ -1888,8 +1888,8 @@ static FormatStyle::LanguageKind getLang

>  }

>

>  llvm::Expected getStyle(StringRef StyleName,
StringRef FileName,

> - StringRef FallbackStyle,
StringRef Code,

> - vfs::FileSystem *FS) {

> + StringRef FallbackStyleName,

> + StringRef Code,
vfs::FileSystem *FS) {

>if (!FS) {

>  FS = vfs::getRealFileSystem().get();

>}

> @@ -1903,9 +1903,9 @@ llvm::Expected getStyle(Str

>(Code.contains("\n- (") || Code.contains("\n+ (")))

>  Style.Language = FormatStyle::LK_ObjC;

>

> -  // FIXME: If FallbackStyle is explicitly "none", format is
disabled.

> -  if (!getPredefinedStyle(FallbackStyle, Style.Language, &Style))

> -return make_string_error("Invalid fallback style \"" +
FallbackStyle.str());

> +  FormatStyle FallbackStyle = getNoStyle();

> +  if (!getPredefinedStyle(FallbackStyleName, Style.Language,
&FallbackStyle))

> +return make_string_error("Invalid fallback style \"" +
FallbackStyleName);

>

>if (StyleName.startswith("{")) {

>  // Parse YAML/JSON style from the command line.

> @@ -1977,7 +1977,7 @@ llvm::Expected getStyle(Str

>  return make_string_error("Configuration file(s) do(es) not
support " +

>   getLanguageName(Style.Language) + ": " +

>   UnsuitableConfigFiles);

> -  return Style;

> +  return FallbackStyle;

>  }

>

>  } // namespace format

>

> Modified: cfe/trunk/test/Format/style-on-command-line.cpp

> URL:

http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Format/style-on-command-line.cpp?rev=292562&r1=292561&r2=292562&view=diff

>

==

> --- cfe/trunk/test/Format/style-on-command-line.cpp (original)

> +++ cfe/trunk/test/Format/style-on-command-line.cpp Thu Jan 19
19:22:42 2017

> @@ -11,6 +11,21 @@

>  // RUN: clang-format -style=file -assume-filename=%T/foo.cpp < %s
| FileCheck -strict-whitespace -check-prefix=CHECK7 %s

>  // RUN: clang-format -style="{BasedOnStyle: LLVM,
PointerBindsToType: true}" %s | FileCheck -strict-whitespace
-check-prefix=CHECK8 %s

>  // RUN: clan

Re: r295114 - Improve diagnostic reporting when using __declspec without enabling __declspec as a keyword.

[Mikael Holmén via cfe-commits]

Hi Aaron,


On 02/14/2017 11:47 PM, Aaron Ballman via cfe-commits wrote:

Author: aaronballman
Date: Tue Feb 14 16:47:20 2017
New Revision: 295114

URL: http://llvm.org/viewvc/llvm-project?rev=295114&view=rev
Log:
Improve diagnostic reporting when using __declspec without enabling __declspec 
as a keyword.

Fixes PR31936.

Added:
cfe/trunk/test/Parser/declspec-recovery.c
cfe/trunk/test/Parser/declspec-supported.c
Modified:
cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
cfe/trunk/lib/Parse/ParseDecl.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td?rev=295114&r1=295113&r2=295114&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td Tue Feb 14 16:47:20 
2017
@@ -176,6 +176,9 @@ def warn_gcc_attribute_location : Warnin
 def warn_attribute_no_decl : Warning<
   "attribute %0 ignored, because it is not attached to a declaration">,
   InGroup;
+def err_ms_attributes_not_enabled : Error<
+  "'__declspec' attributes are not enabled; use '-fdeclspec' or "
+  "'-fms-extensions' to enable support for __declspec attributes">;
 def err_expected_method_body : Error<"expected method body">;
 def err_declspec_after_virtspec : Error<
   "'%0' qualifier may not appear after the virtual specifier '%1'">;

Modified: cfe/trunk/lib/Parse/ParseDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseDecl.cpp?rev=295114&r1=295113&r2=295114&view=diff
==
--- cfe/trunk/lib/Parse/ParseDecl.cpp (original)
+++ cfe/trunk/lib/Parse/ParseDecl.cpp Tue Feb 14 16:47:20 2017
@@ -2966,6 +2966,31 @@ void Parser::ParseDeclarationSpecifiers(
   if (DS.hasTypeSpecifier())
 goto DoneWithDeclSpec;

+  // If the token is an identifier named "__declspec" and Microsoft
+  // extensions are not enabled, it is likely that there will be cascading
+  // parse errors if this really is a __declspec attribute. Attempt to
+  // recognize that scenario and recover gracefully.
+  if (!getLangOpts().DeclSpecKeyword && Tok.is(tok::identifier) &&
+  Tok.getIdentifierInfo()->getName().equals("__declspec")) {
+Diag(Loc, diag::err_ms_attributes_not_enabled);
+
+// The next token should be an open paren. If it is, eat the entire
+// attribute declaration and continue.
+if (NextToken().is(tok::l_paren)) {
+  // Consume the __declspec identifier.
+  SourceLocation Loc = ConsumeToken();


I get a warning about Loc not being used here:

../tools/clang/lib/Parse/ParseDecl.cpp:2981:26: error: unused variable 
'Loc' [-Werror,-Wunused-variable]

  SourceLocation Loc = ConsumeToken();

Regards,
Mikael


+
+  // Eat the parens and everything between them.
+  BalancedDelimiterTracker T(*this, tok::l_paren);
+  if (T.consumeOpen()) {
+assert(false && "Not a left paren?");
+return;
+  }
+  T.skipToEnd();
+  continue;
+}
+  }
+
   // In C++, check to see if this is a scope specifier like foo::bar::, if
   // so handle it as such.  This is important for ctor parsing.
   if (getLangOpts().CPlusPlus) {

Added: cfe/trunk/test/Parser/declspec-recovery.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/declspec-recovery.c?rev=295114&view=auto
==
--- cfe/trunk/test/Parser/declspec-recovery.c (added)
+++ cfe/trunk/test/Parser/declspec-recovery.c Tue Feb 14 16:47:20 2017
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -triple i386-pc-unknown -fsyntax-only -verify %s
+
+__declspec(naked) void f(void) {} // expected-error{{'__declspec' attributes 
are not enabled; use '-fdeclspec' or '-fms-extensions' to enable support for 
__declspec attributes}}
+
+struct S {
+  __declspec(property(get=Getter, put=Setter)) int X; // 
expected-error{{'__declspec' attributes are not enabled; use '-fdeclspec' or 
'-fms-extensions' to enable support for __declspec attributes}}
+  int Y;
+};

Added: cfe/trunk/test/Parser/declspec-supported.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/declspec-supported.c?rev=295114&view=auto
==
--- cfe/trunk/test/Parser/declspec-supported.c (added)
+++ cfe/trunk/test/Parser/declspec-supported.c Tue Feb 14 16:47:20 2017
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -triple i386-pc-unknown -fsyntax-only -fms-extensions 
-verify %s
+// RUN: %clang_cc1 -triple i386-pc-unknown -fsyntax-only -fdeclspec -verify %s
+// expected-no-diagnostics
+
+__declspec(naked) void f(void) {}
+
+struct S {
+  __declspec(property(get=Getter, put=Setter)) int X;

Re: r295114 - Improve diagnostic reporting when using __declspec without enabling __declspec as a keyword.

[Mikael Holmén via cfe-commits]

Hi,

Saw now that it's already been fixed. Sorry for the spam :/

Regards,
Mikael

On 02/15/2017 07:39 AM, Mikael Holmén wrote:

Hi Aaron,


On 02/14/2017 11:47 PM, Aaron Ballman via cfe-commits wrote:

Author: aaronballman
Date: Tue Feb 14 16:47:20 2017
New Revision: 295114

URL: http://llvm.org/viewvc/llvm-project?rev=295114&view=rev
Log:
Improve diagnostic reporting when using __declspec without enabling
__declspec as a keyword.

Fixes PR31936.

Added:
cfe/trunk/test/Parser/declspec-recovery.c
cfe/trunk/test/Parser/declspec-supported.c
Modified:
cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
cfe/trunk/lib/Parse/ParseDecl.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td?rev=295114&r1=295113&r2=295114&view=diff

==

--- cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td Tue Feb 14
16:47:20 2017
@@ -176,6 +176,9 @@ def warn_gcc_attribute_location : Warnin
 def warn_attribute_no_decl : Warning<
   "attribute %0 ignored, because it is not attached to a declaration">,
   InGroup;
+def err_ms_attributes_not_enabled : Error<
+  "'__declspec' attributes are not enabled; use '-fdeclspec' or "
+  "'-fms-extensions' to enable support for __declspec attributes">;
 def err_expected_method_body : Error<"expected method body">;
 def err_declspec_after_virtspec : Error<
   "'%0' qualifier may not appear after the virtual specifier '%1'">;

Modified: cfe/trunk/lib/Parse/ParseDecl.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseDecl.cpp?rev=295114&r1=295113&r2=295114&view=diff

==

--- cfe/trunk/lib/Parse/ParseDecl.cpp (original)
+++ cfe/trunk/lib/Parse/ParseDecl.cpp Tue Feb 14 16:47:20 2017
@@ -2966,6 +2966,31 @@ void Parser::ParseDeclarationSpecifiers(
   if (DS.hasTypeSpecifier())
 goto DoneWithDeclSpec;

+  // If the token is an identifier named "__declspec" and Microsoft
+  // extensions are not enabled, it is likely that there will be
cascading
+  // parse errors if this really is a __declspec attribute.
Attempt to
+  // recognize that scenario and recover gracefully.
+  if (!getLangOpts().DeclSpecKeyword && Tok.is(tok::identifier) &&
+  Tok.getIdentifierInfo()->getName().equals("__declspec")) {
+Diag(Loc, diag::err_ms_attributes_not_enabled);
+
+// The next token should be an open paren. If it is, eat the
entire
+// attribute declaration and continue.
+if (NextToken().is(tok::l_paren)) {
+  // Consume the __declspec identifier.
+  SourceLocation Loc = ConsumeToken();


I get a warning about Loc not being used here:

../tools/clang/lib/Parse/ParseDecl.cpp:2981:26: error: unused variable
'Loc' [-Werror,-Wunused-variable]
  SourceLocation Loc = ConsumeToken();

Regards,
Mikael


+
+  // Eat the parens and everything between them.
+  BalancedDelimiterTracker T(*this, tok::l_paren);
+  if (T.consumeOpen()) {
+assert(false && "Not a left paren?");
+return;
+  }
+  T.skipToEnd();
+  continue;
+}
+  }
+
   // In C++, check to see if this is a scope specifier like
foo::bar::, if
   // so handle it as such.  This is important for ctor parsing.
   if (getLangOpts().CPlusPlus) {

Added: cfe/trunk/test/Parser/declspec-recovery.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/declspec-recovery.c?rev=295114&view=auto

==

--- cfe/trunk/test/Parser/declspec-recovery.c (added)
+++ cfe/trunk/test/Parser/declspec-recovery.c Tue Feb 14 16:47:20 2017
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -triple i386-pc-unknown -fsyntax-only -verify %s
+
+__declspec(naked) void f(void) {} // expected-error{{'__declspec'
attributes are not enabled; use '-fdeclspec' or '-fms-extensions' to
enable support for __declspec attributes}}
+
+struct S {
+  __declspec(property(get=Getter, put=Setter)) int X; //
expected-error{{'__declspec' attributes are not enabled; use
'-fdeclspec' or '-fms-extensions' to enable support for __declspec
attributes}}
+  int Y;
+};

Added: cfe/trunk/test/Parser/declspec-supported.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/declspec-supported.c?rev=295114&view=auto

==

--- cfe/trunk/test/Parser/declspec-supported.c (added)
+++ cfe/trunk/test/Parser/declspec-supported.c Tue Feb 14 16:47:20 2017
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -triple i386-pc-unknown -fsyntax-only
-fms-extensions -verify %s
+// RUN: %clang_cc1 -triple i386-pc-unknown -fsyntax-only -fdeclspec
-verify %s
+// expect

Re: r302572 - Suppress all uses of LLVM_END_WITH_NULL. NFC.

[Mikael Holmén via cfe-commits]

Hi,

This commit gives a warning with clang 3.6:

In file included from 
../tools/clang/lib/StaticAnalyzer/Checkers/BasicObjCFoundationChecks.cpp:17:
../tools/clang/lib/StaticAnalyzer/Checkers/SelectorExtras.h:23:40: 
error: braces around scalar initializer [-Werror]

  SmallVector II{{&Ctx.Idents.get(IIs)...}};
   ^
../tools/clang/lib/StaticAnalyzer/Checkers/BasicObjCFoundationChecks.cpp:236:11: 
note: in instantiation of function template specialization 
'clang::ento::getKeywordSelector' requested here

  getKeywordSelector(Ctx, "caseInsensitiveCompare"),
  ^
1 error generated.

With 3.9 and 4.0 I don't see the warning. Is this a bug in 3.6 or what?

Are we supposed to not use an old clang as 3.6 to compile?

Regards,
Mikael


On 05/09/2017 09:31 PM, Serge Guelton via cfe-commits wrote:

Author: serge_sans_paille
Date: Tue May  9 14:31:30 2017
New Revision: 302572

URL: http://llvm.org/viewvc/llvm-project?rev=302572&view=rev
Log:
Suppress all uses of LLVM_END_WITH_NULL. NFC.

Use variadic templates instead of relying on  + sentinel.

This enforces better type checking and makes code more readable.

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

Modified:
cfe/trunk/lib/CodeGen/CGBlocks.cpp
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/CodeGen/CGCUDANV.cpp
cfe/trunk/lib/CodeGen/CGCleanup.cpp
cfe/trunk/lib/CodeGen/CGException.cpp
cfe/trunk/lib/CodeGen/CGExpr.cpp
cfe/trunk/lib/CodeGen/CGExprConstant.cpp
cfe/trunk/lib/CodeGen/CGObjCGNU.cpp
cfe/trunk/lib/CodeGen/CGObjCMac.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CodeGenTypes.cpp
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/lib/CodeGen/TargetInfo.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/BasicObjCFoundationChecks.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/NoReturnFunctionChecker.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/SelectorExtras.h

Modified: cfe/trunk/lib/CodeGen/CGBlocks.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBlocks.cpp?rev=302572&r1=302571&r2=302572&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBlocks.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBlocks.cpp Tue May  9 14:31:30 2017
@@ -961,9 +961,8 @@ llvm::Type *CodeGenModule::getBlockDescr
   //   const char *signature;   // the block signature
   //   const char *layout;  // reserved
   // };
-  BlockDescriptorType =
-llvm::StructType::create("struct.__block_descriptor",
- UnsignedLongTy, UnsignedLongTy, nullptr);
+  BlockDescriptorType = llvm::StructType::create(
+  "struct.__block_descriptor", UnsignedLongTy, UnsignedLongTy);

   // Now form a pointer to that.
   unsigned AddrSpace = 0;
@@ -987,9 +986,8 @@ llvm::Type *CodeGenModule::getGenericBlo
   //   struct __block_descriptor *__descriptor;
   // };
   GenericBlockLiteralType =
-llvm::StructType::create("struct.__block_literal_generic",
- VoidPtrTy, IntTy, IntTy, VoidPtrTy,
- BlockDescPtrTy, nullptr);
+  llvm::StructType::create("struct.__block_literal_generic", VoidPtrTy,
+   IntTy, IntTy, VoidPtrTy, BlockDescPtrTy);

   return GenericBlockLiteralType;
 }

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=302572&r1=302571&r2=302572&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Tue May  9 14:31:30 2017
@@ -4571,7 +4571,7 @@ Value *CodeGenFunction::EmitARMBuiltinEx
 Function *F = CGM.getIntrinsic(BuiltinID == ARM::BI__builtin_arm_stlex
? Intrinsic::arm_stlexd
: Intrinsic::arm_strexd);
-llvm::Type *STy = llvm::StructType::get(Int32Ty, Int32Ty, nullptr);
+llvm::Type *STy = llvm::StructType::get(Int32Ty, Int32Ty);

 Address Tmp = CreateMemTemp(E->getArg(0)->getType());
 Value *Val = EmitScalarExpr(E->getArg(0));
@@ -5401,7 +5401,7 @@ Value *CodeGenFunction::EmitAArch64Built
 Function *F = CGM.getIntrinsic(BuiltinID == AArch64::BI__builtin_arm_stlex
? Intrinsic::aarch64_stlxp
: Intrinsic::aarch64_stxp);
-llvm::Type *STy = llvm::StructType::get(Int64Ty, Int64Ty, nullptr);
+llvm::Type *STy = llvm::StructType::get(Int64Ty, Int64Ty);

 Address Tmp = CreateMemTemp(E->getArg(0)->getType());
 EmitAnyExprToMem(E->getArg(0), Tmp, Qualifiers(), /*init*/ true);
@@ -7373,8 +7373,8 @@ Value *CodeGenFunction::EmitX86BuiltinEx
 // unsigned i

Re: r302572 - Suppress all uses of LLVM_END_WITH_NULL. NFC.

[Mikael Holmén via cfe-commits]

On 05/10/2017 09:37 AM, Mikael Holmén via cfe-commits wrote:

Hi,

This commit gives a warning with clang 3.6:

In file included from
../tools/clang/lib/StaticAnalyzer/Checkers/BasicObjCFoundationChecks.cpp:17:

../tools/clang/lib/StaticAnalyzer/Checkers/SelectorExtras.h:23:40:
error: braces around scalar initializer [-Werror]
  SmallVector II{{&Ctx.Idents.get(IIs)...}};
   ^
../tools/clang/lib/StaticAnalyzer/Checkers/BasicObjCFoundationChecks.cpp:236:11:
note: in instantiation of function template specialization
'clang::ento::getKeywordSelector' requested here
  getKeywordSelector(Ctx, "caseInsensitiveCompare"),
  ^
1 error generated.

With 3.9 and 4.0 I don't see the warning. Is this a bug in 3.6 or what?

Are we supposed to not use an old clang as 3.6 to compile?



http://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library

The above link says clang 3.1 should work.

Could you make the code compile without warnings also for 3.6?

Regards,
Mikael


Regards,
Mikael


On 05/09/2017 09:31 PM, Serge Guelton via cfe-commits wrote:

Author: serge_sans_paille
Date: Tue May  9 14:31:30 2017
New Revision: 302572

URL: http://llvm.org/viewvc/llvm-project?rev=302572&view=rev
Log:
Suppress all uses of LLVM_END_WITH_NULL. NFC.

Use variadic templates instead of relying on  + sentinel.

This enforces better type checking and makes code more readable.

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

Modified:
cfe/trunk/lib/CodeGen/CGBlocks.cpp
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/CodeGen/CGCUDANV.cpp
cfe/trunk/lib/CodeGen/CGCleanup.cpp
cfe/trunk/lib/CodeGen/CGException.cpp
cfe/trunk/lib/CodeGen/CGExpr.cpp
cfe/trunk/lib/CodeGen/CGExprConstant.cpp
cfe/trunk/lib/CodeGen/CGObjCGNU.cpp
cfe/trunk/lib/CodeGen/CGObjCMac.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CodeGenTypes.cpp
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/lib/CodeGen/TargetInfo.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/BasicObjCFoundationChecks.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/NoReturnFunctionChecker.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/SelectorExtras.h

Modified: cfe/trunk/lib/CodeGen/CGBlocks.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBlocks.cpp?rev=302572&r1=302571&r2=302572&view=diff

==

--- cfe/trunk/lib/CodeGen/CGBlocks.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBlocks.cpp Tue May  9 14:31:30 2017
@@ -961,9 +961,8 @@ llvm::Type *CodeGenModule::getBlockDescr
   //   const char *signature;   // the block signature
   //   const char *layout;  // reserved
   // };
-  BlockDescriptorType =
-llvm::StructType::create("struct.__block_descriptor",
- UnsignedLongTy, UnsignedLongTy, nullptr);
+  BlockDescriptorType = llvm::StructType::create(
+  "struct.__block_descriptor", UnsignedLongTy, UnsignedLongTy);

   // Now form a pointer to that.
   unsigned AddrSpace = 0;
@@ -987,9 +986,8 @@ llvm::Type *CodeGenModule::getGenericBlo
   //   struct __block_descriptor *__descriptor;
   // };
   GenericBlockLiteralType =
-llvm::StructType::create("struct.__block_literal_generic",
- VoidPtrTy, IntTy, IntTy, VoidPtrTy,
- BlockDescPtrTy, nullptr);
+  llvm::StructType::create("struct.__block_literal_generic",
VoidPtrTy,
+   IntTy, IntTy, VoidPtrTy, BlockDescPtrTy);

   return GenericBlockLiteralType;
 }

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=302572&r1=302571&r2=302572&view=diff

==

--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Tue May  9 14:31:30 2017
@@ -4571,7 +4571,7 @@ Value *CodeGenFunction::EmitARMBuiltinEx
 Function *F = CGM.getIntrinsic(BuiltinID ==
ARM::BI__builtin_arm_stlex
? Intrinsic::arm_stlexd
: Intrinsic::arm_strexd);
-llvm::Type *STy = llvm::StructType::get(Int32Ty, Int32Ty, nullptr);
+llvm::Type *STy = llvm::StructType::get(Int32Ty, Int32Ty);

 Address Tmp = CreateMemTemp(E->getArg(0)->getType());
 Value *Val = EmitScalarExpr(E->getArg(0));
@@ -5401,7 +5401,7 @@ Value *CodeGenFunction::EmitAArch64Built
 Function *F = CGM.getIntrinsic(BuiltinID ==
AArch64::BI__builtin_arm_stlex
? Intrinsic::aarch64_stlxp
   

Re: r275368 - Add C++ dependencies to xray runtime

[Mikael Holmén via cfe-commits]

Hi,

Your commit

Add C++ dependencies to xray runtime

Doesn't compile with gcc. At least 5.3 and 4.8.4 complains about this 
change:


+  if (Args.hasArg(options::OPT_fxray_instrument,
+  options::OPT_fnoxray_instrument, false)) {
+CmdArgs.push_back("-fxray-instrument");
+if (Arg *A = Args.getLastArg(options::OPT_fxray_instruction_threshold_,
+ 
options::OPT_fxray_instruction_threshold_EQ)) {

+  CmdArgs.push_back("-fxray-instruction-threshold");
+  CmdArgs.push_back(A->getValue());
+}
+  }
+

../tools/clang/lib/Driver/Tools.cpp:4613:57: error: converting to 
'llvm::opt::OptSpecifier' from initializer list would use explicit 
constructor 'llvm::opt::OptSpecifier::OptSpecifier(bool)'

   options::OPT_fnoxray_instrument, false)) {
 ^
In file included from ../include/llvm/Option/OptTable.h:15:0,
 from ../include/llvm/Option/Option.h:15,
 from ../tools/clang/lib/Driver/Tools.h:19,
 from ../tools/clang/lib/Driver/Tools.cpp:10:
../include/llvm/Option/OptSpecifier.h:24:14: error: 
'llvm::opt::OptSpecifier::OptSpecifier(bool)' is private

 explicit OptSpecifier(bool) = delete;
  ^
../tools/clang/lib/Driver/Tools.cpp:4613:57: error: within this context
   options::OPT_fnoxray_instrument, false)) {
 ^
../tools/clang/lib/Driver/Tools.cpp:4613:57: error: use of deleted 
function 'llvm::opt::OptSpecifier::OptSpecifier(bool)'

In file included from ../include/llvm/Option/OptTable.h:15:0,
 from ../include/llvm/Option/Option.h:15,
 from ../tools/clang/lib/Driver/Tools.h:19,
 from ../tools/clang/lib/Driver/Tools.cpp:10:
../include/llvm/Option/OptSpecifier.h:24:14: error: declared here
 explicit OptSpecifier(bool) = delete;
  ^
In file included from 
../tools/clang/include/clang/Driver/SanitizerArgs.h:15:0,

 from ../tools/clang/lib/Driver/Tools.cpp:24:
../include/llvm/Option/ArgList.h:191:8: error:   initializing argument 3 
of 'bool llvm::opt::ArgList::hasArg(llvm::opt::OptSpecifier, 
llvm::opt::OptSpecifier, llvm::opt::OptSpecifier) const'
   bool hasArg(OptSpecifier Id0, OptSpecifier Id1, OptSpecifier Id2) 
const {

^
ninja: build stopped: subcommand failed.
system(/proj/flexasic/app/ninja/1.4/SLED11-64/bin/ninja -j1 -C 
build-all-gcc53 llc llvm-stress opt clang all) failed: child exited with 
value 1

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

Re: r275368 - Add C++ dependencies to xray runtime

[Mikael Holmén via cfe-commits]

On 07/14/2016 02:10 PM, Dean Michael Berris wrote:

Thanks Mikael -- this has been fixed in r275377
(http://reviews.llvm.org/rL275377).


Yes, now it compiled. Thank you!
/Mikael



On Thu, Jul 14, 2016 at 7:30 PM Mikael Holmén
mailto:mikael.hol...@ericsson.com>> wrote:

Hi,

Your commit

  Add C++ dependencies to xray runtime

Doesn't compile with gcc. At least 5.3 and 4.8.4 complains about this
change:

+  if (Args.hasArg(options::OPT_fxray_instrument,
+  options::OPT_fnoxray_instrument, false)) {
+CmdArgs.push_back("-fxray-instrument");
+if (Arg *A =
Args.getLastArg(options::OPT_fxray_instruction_threshold_,
+
options::OPT_fxray_instruction_threshold_EQ)) {
+  CmdArgs.push_back("-fxray-instruction-threshold");
+  CmdArgs.push_back(A->getValue());
+}
+  }
+

../tools/clang/lib/Driver/Tools.cpp:4613:57: error: converting to
'llvm::opt::OptSpecifier' from initializer list would use explicit
constructor 'llvm::opt::OptSpecifier::OptSpecifier(bool)'
 options::OPT_fnoxray_instrument, false)) {
   ^
In file included from ../include/llvm/Option/OptTable.h:15:0,
   from ../include/llvm/Option/Option.h:15,
   from ../tools/clang/lib/Driver/Tools.h:19,
   from ../tools/clang/lib/Driver/Tools.cpp:10:
../include/llvm/Option/OptSpecifier.h:24:14: error:
'llvm::opt::OptSpecifier::OptSpecifier(bool)' is private
   explicit OptSpecifier(bool) = delete;
^
../tools/clang/lib/Driver/Tools.cpp:4613:57: error: within this context
 options::OPT_fnoxray_instrument, false)) {
   ^
../tools/clang/lib/Driver/Tools.cpp:4613:57: error: use of deleted
function 'llvm::opt::OptSpecifier::OptSpecifier(bool)'
In file included from ../include/llvm/Option/OptTable.h:15:0,
   from ../include/llvm/Option/Option.h:15,
   from ../tools/clang/lib/Driver/Tools.h:19,
   from ../tools/clang/lib/Driver/Tools.cpp:10:
../include/llvm/Option/OptSpecifier.h:24:14: error: declared here
   explicit OptSpecifier(bool) = delete;
^
In file included from
../tools/clang/include/clang/Driver/SanitizerArgs.h:15:0,
   from ../tools/clang/lib/Driver/Tools.cpp:24:
../include/llvm/Option/ArgList.h:191:8: error:   initializing argument 3
of 'bool llvm::opt::ArgList::hasArg(llvm::opt::OptSpecifier,
llvm::opt::OptSpecifier, llvm::opt::OptSpecifier) const'
 bool hasArg(OptSpecifier Id0, OptSpecifier Id1, OptSpecifier Id2)
const {
  ^
ninja: build stopped: subcommand failed.
system(/proj/flexasic/app/ninja/1.4/SLED11-64/bin/ninja -j1 -C
build-all-gcc53 llc llvm-stress opt clang all) failed: child exited with
value 1



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

[clang] [-Wunsafe-buffer-usage] Warning Libc functions (PR #101583)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

We're seeing a crash with this patch when compiling with -Weverything.
```
clang: ../../clang/include/clang/AST/Expr.h:3026: const clang::Expr 
*clang::CallExpr::getArg(unsigned int) const: Assertion `Arg < getNumArgs() && 
"Arg access out of range!"' failed.
```
I'm working on extracting a reproducer.

https://github.com/llvm/llvm-project/pull/101583
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [-Wunsafe-buffer-usage] Warning Libc functions (PR #101583)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

> We're seeing a crash with this patch when compiling with -Weverything.
> 
> ```
> clang: ../../clang/include/clang/AST/Expr.h:3026: const clang::Expr 
> *clang::CallExpr::getArg(unsigned int) const: Assertion `Arg < getNumArgs() 
> && "Arg access out of range!"' failed.
> ```
> 
> I'm working on extracting a reproducer.

```clang -c -Weverything bbi-98867.c```
with bbi-98867.c being just
```
void printf() { printf(); }
```
(I've creduced the reproducer, I can't share the full one)

https://github.com/llvm/llvm-project/pull/101583
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [-Wunsafe-buffer-usage] Warning Libc functions (PR #101583)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

Btw a question about the new warning: So with 
-Wunsafe-buffer-usage-in-libc-call clang now warns on the following?
```
#include 

void foo(void) {
  char q[10];
  snprintf(q, 10, "%s", "hello");
}
```
It says
```
foo.c:5:3: warning: function 'snprintf' is unsafe 
[-Wunsafe-buffer-usage-in-libc-call]
5 |   snprintf(q, 10, "%s", "hello");
  |   ^~
foo.c:5:12: note:  buffer pointer and size may not match
5 |   snprintf(q, 10, "%s", "hello");
  |^
1 warning generated.
```
Is that as expected? If so, how should snprintf be used to avoid the warning?


https://github.com/llvm/llvm-project/pull/101583
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [-Wunsafe-buffer-usage] Warning Libc functions (PR #101583)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

> > Btw a question about the new warning: So with 
> > -Wunsafe-buffer-usage-in-libc-call clang now warns on the following?
> > ```
> > #include 
> > 
> > void foo(void) {
> >   char q[10];
> >   snprintf(q, 10, "%s", "hello");
> > }
> > ```
> > 
> > 
> > 
> >   
> > 
> > 
> >   
> > 
> > 
> > 
> >   
> > It says
> > ```
> > foo.c:5:3: warning: function 'snprintf' is unsafe 
> > [-Wunsafe-buffer-usage-in-libc-call]
> > 5 |   snprintf(q, 10, "%s", "hello");
> >   |   ^~
> > foo.c:5:12: note:  buffer pointer and size may not match
> > 5 |   snprintf(q, 10, "%s", "hello");
> >   |^
> > 1 warning generated.
> > ```
> > 
> > 
> > 
> >   
> > 
> > 
> >   
> > 
> > 
> > 
> >   
> > Is that as expected? If so, how should snprintf be used to avoid the 
> > warning?
> 
> Yes, this is expected. According to the C++ Safe Buffers programming model, 
> buffer pointers should be changed to `std::span`. Then `snprintf(span.data(), 
> span.size(), ...)` is considered safe and will not be warned. We may also 
> allow the use of the form `snprintf(span.first(10).data(), 10, ...)` later.

But as @bjope said, we get the warning also for C code, even if I explicitly 
say e.g. "-std=c11".
So 
```clang -Weverything foo.c -c -std=c11```
now yields the new warning.


https://github.com/llvm/llvm-project/pull/101583
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [lld] [llvm] [LTO] enable `ObjCARCContractPass` only on optimized build (PR #101114)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

I noticed that if I compile opt with UBSan enabled on this patch and then run
```
opt -passes=objc-arc-contract bbi-98007.ll -o /dev/null
```
we get an UBSan complaint like
```
../lib/Transforms/ObjCARC/ObjCARCContract.cpp:105:39: runtime error: load of 
value 255, which is not a valid value for type 'bool'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
../lib/Transforms/ObjCARC/ObjCARCContract.cpp:105:39 in 
```
And the bbi-98007.ll input is just
```
define void @a() {
entry:
  ret void
}
```

https://github.com/llvm/llvm-project/pull/101114
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] Add normalize builtins and normalize HLSL function to DirectX and SPIR-V backend (PR #102683)

[Mikael Holmén via cfe-commits]

@@ -0,0 +1,31 @@
+// RUN: %clang_cc1 -finclude-default-header -triple 
dxil-pc-shadermodel6.6-library %s -fnative-half-type -emit-llvm 
-disable-llvm-passes -verify -verify-ignore-unexpected

mikaelholmen wrote:

Hi @bob80905 
I think this "-emit-llvm -disable-llvm-passes" will make the test write to the 
local filesystem?
Can we try to avoid that, e.g. by just removing "-emit-llvm"?
See e.g. b7730a23efb2 which fixed a similar case recently.

https://github.com/llvm/llvm-project/pull/102683
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [lld] [llvm] [LTO] enable `ObjCARCContractPass` only on optimized build (PR #101114)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

> @mikaelholmen I can't reproduce this on commit 
> [e40915b](https://github.com/llvm/llvm-project/commit/e40915b7407eda4b370658da5c9606e310b55d19)
>  with `-DLLVM_USE_SANITIZER=Undefined`. Kindly let me know how to reproduce 
> this.
> 
> Looking from the code, I suspect that it's caused by uninitialized bool (
> 
> https://github.com/llvm/llvm-project/blob/539bf499615dbbfe98deaac1021f351eaad330ea/llvm/lib/Transforms/ObjCARC/ObjCARCContract.cpp#L553
> )

I think the problem is that the
```
Changed = CFGChanged = false; 
```
initialization done in
```
bool ObjCARCContract::run(Function &F, AAResults *A, DominatorTree *D) {
  if (!Run)
return false;

  if (!EnableARCOpts)
return false;

  Changed = CFGChanged = false;
```
is skipped if we bail out early due to "!Run" or "!EnableARCOpts".
But the pass always asks
```
  bool CFGChanged = OCAC.hasCFGChanged();
```
afterwards anyway.

https://github.com/llvm/llvm-project/pull/101114
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [analyzer][NFC] Reorganize Z3 report refutation (PR #95128)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

Hi @steakhal and @NagyDonat ,

Does this patch have requirements on the Z3 version?

I get
```LLVM ERROR: Z3 error: unknown parameter 'timeout'```
for the following testcases
```
Failed Tests (3):
  Clang-Unit :: StaticAnalyzer/./StaticAnalysisTests/24/188
  Clang-Unit :: StaticAnalyzer/./StaticAnalysisTests/25/188
  Clang-Unit :: StaticAnalyzer/./StaticAnalysisTests/26/188
```


https://github.com/llvm/llvm-project/pull/95128
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [analyzer][NFC] Reorganize Z3 report refutation (PR #95128)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

> > Hi @steakhal and @NagyDonat ,
> > Does this patch have requirements on the Z3 version?
> > I get
> > `LLVM ERROR: Z3 error: unknown parameter 'timeout'`
> > for the following testcases
> > ```
> > Failed Tests (3):
> >   Clang-Unit :: StaticAnalyzer/./StaticAnalysisTests/24/188
> >   Clang-Unit :: StaticAnalyzer/./StaticAnalysisTests/25/188
> >   Clang-Unit :: StaticAnalyzer/./StaticAnalysisTests/26/188
> > ```
> 
> I'm not aware. I used the latest Z3 when testing. I'll have a look.
> 
> Edit: Do you have a build bot link, such that I could checkout the exact 
> environment?

Unfortunately not, I'm on our internal servers.
From what I can see we're using Z3 4.8.8-1


https://github.com/llvm/llvm-project/pull/95128
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [analyzer][NFC] Reorganize Z3 report refutation (PR #95128)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

It seems to be the following tests
```
FalsePositiveRefutationBRVisitorTestBase.UnSatInTheMiddleNoReport
FalsePositiveRefutationBRVisitorTestBase.UnSatAtErrorNodeDueToRefinedConstraintNoReport
FalsePositiveRefutationBRVisitorTestBase.UnSatAtErrorNodeWithNewSymbolNoReport
```
and they fail like
```
[ RUN  ] 
FalsePositiveRefutationBRVisitorTestBase.UnSatAtErrorNodeWithNewSymbolNoReport
LLVM ERROR: Z3 error: unknown parameter 'timeout'
Legal parameters are:
  arith.auto_config_simplex (bool) (default: false)
  arith.bprop_on_pivoted_rows (bool) (default: true)
  arith.branch_cut_ratio (unsigned int) (default: 2)
  arith.dump_lemmas (bool) (default: false)
  arith.eager_eq_axioms (bool) (default: true)
  arith.enable_hnf (bool) (default: true)
  arith.greatest_error_pivot (bool) (default: false)
  arith.ignore_int (bool) (default: false)
  arith.int_eq_branch (bool) (default: false)
  arith.min (bool) (default: false)
  arith.nl (bool) (default: true)
  arith.nl.branching (bool) (default: true)
  arith.nl.gb (bool) (default: true)
  arith.nl.gr_q (unsigned int) (default: 10)
  arith.nl.grobner (bool) (default: true)
  arith.nl.grobner_cnfl_to_report (unsigned int) (default: 1)
  arith.nl.grobner_eqs_growth (unsigned int) (default: 10)
  arith.nl.grobner_expr_degree_growth (unsigned int) (default: 2)
  arith.nl.grobner_expr_size_growth (unsigned int) (default: 2)
  arith.nl.grobner_max_simplified (unsigned int) (default: 1)
  arith.nl.grobner_subs_fixed (unsigned int) (default: 2)
  arith.nl.horner (bool) (default: true)
  arith.nl.horner_frequency (unsigned int) (default: 4)
  arith.nl.horner_row_length_limit (unsigned int) (default: 10)
  arith.nl.horner_subs_fixed (unsigned int) (default: 2)
  arith.nl.order (bool) (default: true)
  arith.nl.rounds (unsigned int) (default: 1024)
  arith.nl.tangents (bool) (default: true)
  arith.print_ext_var_names (bool) (default: false)
  arith.print_stats (bool) (default: false)
  arith.propagate_eqs (bool) (default: true)
  arith.propagation_mode (unsigned int) (default: 2)
  arith.random_initial_value (bool) (default: false)
  arith.reflect (bool) (default: true)
  arith.rep_freq (unsigned int) (default: 0)
  arith.simplex_strategy (unsigned int) (default: 0)
  arith.solver (unsigned int) (default: 2)
  array.extensional (bool) (default: true)
  array.weak (bool) (default: false)
  auto_config (bool) (default: true)
  bv.enable_int2bv (bool) (default: true)
  bv.reflect (bool) (default: true)
  case_split (unsigned int) (default: 1)
  clause_proof (bool) (default: false)
  core.extend_nonlocal_patterns (bool) (default: false)
  core.extend_patterns (bool) (default: false)
  core.extend_patterns.max_distance (unsigned int) (default: 4294967295)
  core.minimize (bool) (default: false)
  core.validate (bool) (default: false)
  dack (unsigned int) (default: 1)
  dack.eq (bool) (default: false)
  dack.factor (double) (default: 0.1)
  dack.gc (unsigned int) (default: 2000)
  dack.gc_inv_decay (double) (default: 0.8)
  dack.threshold (unsigned int) (default: 10)
  delay_units (bool) (default: false)
  delay_units_threshold (unsigned int) (default: 32)
  dt_lazy_splits (unsigned int) (default: 1)
  ematching (bool) (default: true)
  induction (bool) (default: false)
  lemma_gc_strategy (unsigned int) (default: 0)
  logic (symbol) (default: )
  macro_finder (bool) (default: false)
  max_conflicts (unsigned int) (default: 4294967295)
  mbqi (bool) (default: true)
  mbqi.force_template (unsigned int) (default: 10)
  mbqi.id (string) (default: )
  mbqi.max_cexs (unsigned int) (default: 1)
  mbqi.max_cexs_incr (unsigned int) (default: 0)
  mbqi.max_iterations (unsigned int) (default: 1000)
  mbqi.trace (bool) (default: false)
  model (bool) (default: true)
  pb.conflict_frequency (unsigned int) (default: 1000)
  pb.learn_complements (bool) (default: true)
  phase_selection (unsigned int) (default: 3)
  proof (bool) (default: false)
  pull_nested_quantifiers (bool) (default: false)
  qi.cost (string) (default: (+ weight generation))
  qi.eager_threshold (double) (default: 10.0)
  qi.lazy_threshold (double) (default: 20.0)
  qi.max_instances (unsigned int) (default: 4294967295)
  qi.max_multi_patterns (unsigned int) (default: 0)
  qi.profile (bool) (default: false)
  qi.profile_freq (unsigned int) (default: 4294967295)
  qi.quick_checker (unsigned int) (default: 0)
  quasi_macros (bool) (default: false)
  random_seed (unsigned int) (default: 0)
  refine_inj_axioms (bool) (default: true)
  relevancy (unsigned int) (default: 2)
  restart.max (unsigned int) (default: 4294967295)
  restart_factor (double) (default: 1.1)
  restart_strategy (unsigned int) (default: 1)
  restricted_quasi_macros (bool) (default: false)
  seq.split_w_len (bool) (default: true)
  seq.validate (bool) (default: false)
  str.aggressive_length_testing (bool) (default: false)
  str.aggressive_unroll_testing (bool) (default: true)
  str.aggressive_value_testing (bool) (default: false)
 

[clang] [llvm] [analyzer][NFC] Reorganize Z3 report refutation (PR #95128)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

With the next patch eacc3b3504be061 it fails on rlimit for me, but on this 
patch it's on timeout.


https://github.com/llvm/llvm-project/pull/95128
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [analyzer][NFC] Reorganize Z3 report refutation (PR #95128)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

I don't know really, I just noticed that main suddenly broke for us and 
bisected to this patch.

https://github.com/llvm/llvm-project/pull/95128
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [analyzer][NFC] Reorganize Z3 report refutation (PR #95128)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

> > I don't know really, I just noticed that main suddenly broke for us and 
> > bisected to this patch.
> 
> If after the second patch the tests pass then I'm contemplated to say I'd go 
> for upgrading Z3 requirements to 4.8.9, and accept that with my first commit 
> would have failed the CI/tests with an old(er) Z3. On my system, all 
> `StaticAnalysisTests` pass with 4.8.9 on `main`. Are you okay with upgrading 
> Z3 to at least 4.8.9 or preferably to latest (4.13.0)?

The testcases fail botth on this and on the next patch. I just commented here 
because this is the first patch there are problems.

I have to check with my team why we are on 4.8.8 and what we can upgrade to. In 
any case that won't happen today.
But I'm surprised that requirements were suddenly raised without warning.

https://github.com/llvm/llvm-project/pull/95128
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [analyzer] Revert Z3 changes (PR #95916)

[Mikael Holmén via cfe-commits]

https://github.com/mikaelholmen approved this pull request.

Thanks!

https://github.com/llvm/llvm-project/pull/95916
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [analyzer][NFC] Reorganize Z3 report refutation (PR #95128)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

> @mikaelholmen Please approve the revert PR then.

Done. Thank you!

https://github.com/llvm/llvm-project/pull/95128
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Detect leaks of stack addresses via output params, indirect globals 3/3 (PR #105648)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

Hello,

The following starts crashing with this patch:
```
clang -cc1 -analyze -analyzer-checker=core bbi-98571.c
```
Result:
```
bbi-98571.c:2:14: warning: expected ';' at end of declaration list
2 |   struct a *b
  |  ^
  |  ;
bbi-98571.c:5:8: warning: expected ';' at end of declaration list
5 |   int d
  |^
  |;
bbi-98571.c:11:4: warning: passing arguments to 'f' without a prototype is 
deprecated in all versions of C and is not supported in C23 
[-Wdeprecated-non-prototype]
   11 |   f(h);
  |^
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and 
include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.  Program arguments: build-all/bin/clang -cc1 -analyze 
-analyzer-checker=core bbi-98571.c
1.   parser at end of file
2.  While analyzing stack: 
#0 Calling g
 #0 0x555c2d234d97 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
(build-all/bin/clang+0x7f7cd97)
 #1 0x555c2d2328fe llvm::sys::RunSignalHandlers() 
(build-all/bin/clang+0x7f7a8fe)
 #2 0x555c2d23545f SignalHandler(int) Signals.cpp:0:0
 #3 0x7f49e8845cf0 __restore_rt (/lib64/libpthread.so.0+0x12cf0)
 #4 0x555c2f3124a8 clang::ento::MemRegion::getBaseRegion() const 
(build-all/bin/clang+0xa05a4a8)
 #5 0x555c2f0f5d82 (anonymous 
namespace)::StackAddrEscapeChecker::checkEndFunction(clang::ReturnStmt const*, 
clang::ento::CheckerContext&) 
const::CallBack::HandleBinding(clang::ento::StoreManager&, void const*, 
clang::ento::MemRegion const*, clang::ento::SVal) StackAddrEscapeChecker.cpp:0:0
 #6 0x555c2f351937 (anonymous 
namespace)::RegionStoreManager::iterBindings(void const*, 
clang::ento::StoreManager::BindingsHandler&) RegionStore.cpp:0:0
 #7 0x555c2f0f51c5 void 
clang::ento::check::EndFunction::_checkEndFunction<(anonymous 
namespace)::StackAddrEscapeChecker>(void*, clang::ReturnStmt const*, 
clang::ento::CheckerContext&) StackAddrEscapeChecker.cpp:0:0
 #8 0x555c2f29ee6a 
clang::ento::CheckerManager::runCheckersForEndFunction(clang::ento::NodeBuilderContext&,
 clang::ento::ExplodedNodeSet&, clang::ento::ExplodedNode*, 
clang::ento::ExprEngine&, clang::ReturnStmt const*) 
(build-all/bin/clang+0x9fe6e6a)
 #9 0x555c2f2d3c96 
clang::ento::ExprEngine::processEndOfFunction(clang::ento::NodeBuilderContext&, 
clang::ento::ExplodedNode*, clang::ReturnStmt const*) 
(build-all/bin/clang+0xa01bc96)
#10 0x555c2f2a8e63 
clang::ento::CoreEngine::HandleBlockEdge(clang::BlockEdge const&, 
clang::ento::ExplodedNode*) (build-all/bin/clang+0x9ff0e63)
#11 0x555c2f2a870a 
clang::ento::CoreEngine::dispatchWorkItem(clang::ento::ExplodedNode*, 
clang::ProgramPoint, clang::ento::WorkListUnit const&) 
(build-all/bin/clang+0x9ff070a)
#12 0x555c2f2a801a 
clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*, 
unsigned int, llvm::IntrusiveRefCntPtr) 
(build-all/bin/clang+0x9ff001a)
#13 0x555c2ee23955 (anonymous 
namespace)::AnalysisConsumer::HandleCode(clang::Decl*, unsigned int, 
clang::ento::ExprEngine::InliningModes, llvm::DenseSet>*) AnalysisConsumer.cpp:0:0
#14 0x555c2edfc78b (anonymous 
namespace)::AnalysisConsumer::HandleTranslationUnit(clang::ASTContext&) 
AnalysisConsumer.cpp:0:0
#15 0x555c2f3a7ea7 clang::ParseAST(clang::Sema&, bool, bool) 
(build-all/bin/clang+0xa0efea7)
#16 0x555c2def1e80 clang::FrontendAction::Execute() 
(build-all/bin/clang+0x8c39e80)
#17 0x555c2de5e5bf 
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) 
(build-all/bin/clang+0x8ba65bf)
#18 0x555c2dfdfa8e 
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) 
(build-all/bin/clang+0x8d27a8e)
#19 0x555c2aaa0576 cc1_main(llvm::ArrayRef, char const*, 
void*) (build-all/bin/clang+0x57e8576)
#20 0x555c2aa9cd1d ExecuteCC1Tool(llvm::SmallVectorImpl&, 
llvm::ToolContext const&) driver.cpp:0:0
#21 0x555c2aa9ba64 clang_main(int, char**, llvm::ToolContext const&) 
(build-all/bin/clang+0x57e3a64)
#22 0x555c2aaad347 main (build-all/bin/clang+0x57f5347)
#23 0x7f49e63ead85 __libc_start_main (/lib64/libc.so.6+0x3ad85)
#24 0x555c2aa9a62e _start (build-all/bin/clang+0x57e262e)
Segmentation fault (core dumped)
```
[bbi-98571.c.gz](https://github.com/user-attachments/files/16796839/bbi-98571.c.gz)


https://github.com/llvm/llvm-project/pull/105648
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Do not reason about locations passed as inline asm input (PR #103714)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

Hi @pskrgag 

The following starts crashing with this patch:
```
clang -cc1 -analyze -analyzer-checker=core bbi-98183.c
```
It crashes like:
```
clang: 
../../clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h:1212: 
clang::ento::ElementRegion::ElementRegion(clang::QualType, clang::ento::NonLoc, 
const clang::ento::SubRegion *): Assertion `!elementType.isNull() && 
!elementType->isVoidType() && "Invalid region type!"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and 
include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.  Program arguments: build-all/bin/clang -cc1 -analyze 
-analyzer-checker=core bbi-98183.c
1.   parser at end of file
2.  While analyzing stack: 
#0 Calling b
3.  bbi-98183.c:2:12: Error evaluating statement
4.  bbi-98183.c:2:12: Error evaluating statement
 #0 0x557ee7401507 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
(build-all/bin/clang+0x7ed8507)
 #1 0x557ee73ff06e llvm::sys::RunSignalHandlers() 
(build-all/bin/clang+0x7ed606e)
 #2 0x557ee7401bcf SignalHandler(int) Signals.cpp:0:0
 #3 0x7f566e78acf0 __restore_rt (/lib64/libpthread.so.0+0x12cf0)
 #4 0x7f566c343acf raise (/lib64/libc.so.6+0x4eacf)
 #5 0x7f566c316ea5 abort (/lib64/libc.so.6+0x21ea5)
 #6 0x7f566c316d79 _nl_load_domain.cold.0 (/lib64/libc.so.6+0x21d79)
 #7 0x7f566c33c426 (/lib64/libc.so.6+0x47426)
 #8 0x557ee94c8881 
clang::ento::ElementRegion::ElementRegion(clang::QualType, clang::ento::NonLoc, 
clang::ento::SubRegion const*) MemRegion.cpp:0:0
 #9 0x557ee94c86a3 
clang::ento::MemRegionManager::getElementRegion(clang::QualType, 
clang::ento::NonLoc, clang::ento::SubRegion const*, clang::ASTContext const&) 
(build-all/bin/clang+0x9f9f6a3)
#10 0x557ee9509dba (anonymous 
namespace)::RegionStoreManager::bind((anonymous namespace)::RegionBindingsRef 
const&, clang::ento::Loc, clang::ento::SVal) RegionStore.cpp:0:0
#11 0x557ee94ffb49 (anonymous namespace)::RegionStoreManager::Bind(void 
const*, clang::ento::Loc, clang::ento::SVal) RegionStore.cpp:0:0
#12 0x557ee94d69a1 clang::ento::ProgramState::bindLoc(clang::ento::Loc, 
clang::ento::SVal, clang::LocationContext const*, bool) const 
(build-all/bin/clang+0x9fad9a1)
#13 0x557ee9481c55 
clang::ento::ExprEngine::VisitGCCAsmStmt(clang::GCCAsmStmt const*, 
clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) 
(build-all/bin/clang+0x9f58c55)
#14 0x557ee947d2b4 clang::ento::ExprEngine::Visit(clang::Stmt const*, 
clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) 
(build-all/bin/clang+0x9f542b4)
#15 0x557ee9479805 clang::ento::ExprEngine::ProcessStmt(clang::Stmt const*, 
clang::ento::ExplodedNode*) (build-all/bin/clang+0x9f50805)
#16 0x557ee9479539 
clang::ento::ExprEngine::processCFGElement(clang::CFGElement, 
clang::ento::ExplodedNode*, unsigned int, clang::ento::NodeBuilderContext*) 
(build-all/bin/clang+0x9f50539)
#17 0x557ee945cc7e clang::ento::CoreEngine::HandlePostStmt(clang::CFGBlock 
const*, unsigned int, clang::ento::ExplodedNode*) 
(build-all/bin/clang+0x9f33c7e)
#18 0x557ee945bb3a 
clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*, 
unsigned int, llvm::IntrusiveRefCntPtr) 
(build-all/bin/clang+0x9f32b3a)
#19 0x557ee8fd8255 (anonymous 
namespace)::AnalysisConsumer::HandleCode(clang::Decl*, unsigned int, 
clang::ento::ExprEngine::InliningModes, llvm::DenseSet>*) AnalysisConsumer.cpp:0:0
#20 0x557ee8fb10bb (anonymous 
namespace)::AnalysisConsumer::HandleTranslationUnit(clang::ASTContext&) 
AnalysisConsumer.cpp:0:0
#21 0x557ee955b927 clang::ParseAST(clang::Sema&, bool, bool) 
(build-all/bin/clang+0xa032927)
#22 0x557ee80b2390 clang::FrontendAction::Execute() 
(build-all/bin/clang+0x8b89390)
#23 0x557ee801d37f 
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) 
(build-all/bin/clang+0x8af437f)
#24 0x557ee81a017e 
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) 
(build-all/bin/clang+0x8c7717e)
#25 0x557ee4c83df6 cc1_main(llvm::ArrayRef, char const*, 
void*) (build-all/bin/clang+0x575adf6)
#26 0x557ee4c8059d ExecuteCC1Tool(llvm::SmallVectorImpl&, 
llvm::ToolContext const&) driver.cpp:0:0
#27 0x557ee4c7f2e4 clang_main(int, char**, llvm::ToolContext const&) 
(build-all/bin/clang+0x57562e4)
#28 0x557ee4c90ab7 main (build-all/bin/clang+0x5767ab7)
#29 0x7f566c32fd85 __libc_start_main (/lib64/libc.so.6+0x3ad85)
#30 0x557ee4c7deae _start (build-all/bin/clang+0x5754eae)
Abort (core dumped)
```
[bbi-98183.c.gz](https://github.com/user-attachments/files/16656552/bbi-98183.c.gz)


https://github.com/llvm/llvm-project/pull/103714
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Increase the default expression nesting limit (PR #104717)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

We also see the ASan complaints on ```Parser/parser_overflow.c``` in downstream 
bots for several days now.
A workaround would be appreciated if a real fix is hard.

https://github.com/llvm/llvm-project/pull/104717
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20] [Modules] Warn for duplicated decls in mutliple module units (PR #105799)

[Mikael Holmén via cfe-commits]

@@ -9955,6 +9955,45 @@ void ASTReader::finishPendingActions() {
   }
   PendingDefinitions.clear();
 
+  for (auto [D, Previous] : PendingWarningForDuplicatedDefsInModuleUnits) {
+auto hasDefinitionImpl = [this](Decl *D, auto hasDefinitionImpl) {
+  if (auto *VD = dyn_cast(D))
+return VD->isThisDeclarationADefinition() ||
+   VD->isThisDeclarationADemotedDefinition();
+
+  if (auto *TD = dyn_cast(D))
+return TD->isThisDeclarationADefinition() ||
+   TD->isThisDeclarationADemotedDefinition();
+
+  if (auto *FD = dyn_cast(D))
+return FD->isThisDeclarationADefinition() || PendingBodies.count(FD);
+
+  if (auto *RTD = dyn_cast(D))
+return hasDefinitionImpl(RTD->getTemplatedDecl(), hasDefinitionImpl);
+
+  // Conservatively return false here.
+  return false;
+};
+
+auto hasDefinition = [this, &hasDefinitionImpl](Decl *D) {

mikaelholmen wrote:

I get a clang warning here:
```
../../clang/lib/Serialization/ASTReader.cpp:9978:27: error: lambda capture 
'this' is not used [-Werror,-Wunused-lambda-capture]
auto hasDefinition = [this, &hasDefinitionImpl](Decl *D) {
  ^
1 error generated.
```

https://github.com/llvm/llvm-project/pull/105799
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [X86][AVX10.2] Support AVX10.2-SATCVT-DS new instructions. (PR #102592)

[Mikael Holmén via cfe-commits]

@@ -0,0 +1,52 @@
+// RUN: %clang_cc1 -flax-vector-conversions=none -ffreestanding %s 
-triple=i386-unknown-unknown -target-feature +avx10.2-512 -emit-llvm -Wall 
-Werror -verify

mikaelholmen wrote:

Can we remove "-emit-llvm" from this test (and others in this patch) since 
noone seems to look at the produced output anyway?
See e.g. b7730a23efb22
```
[test] Avoid writing to a potentially write-protected dir (#102073)
```
solving a similar problem.

https://github.com/llvm/llvm-project/pull/102592
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [flang] Reapply "[clang] Extend diagnose_if to accept more detailed warning information (#70976)" (PR #108453)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

Hello,

I noticed that before this patch
```clang empty.c -fsanitize=undefined -ffine-grained-bitfield-accesses -c 
-Werror```
(on empty file empty.c) resulted in
```warning: option '-ffine-grained-bitfield-accesses' cannot be enabled 
together with a sanitizer; flag ignored```
but with the patch it results in
```error: option '-ffine-grained-bitfield-accesses' cannot be enabled together 
with a sanitizer; flag ignored [-Werror]```

Is this on purpose?

https://github.com/llvm/llvm-project/pull/108453
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [IR] Allow fast math flags on calls with homogeneous FP struct types (PR #110506)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

Hi,

I bisected a crash to this patch. I can't share the C reproducer but it's 
instcombine that crashes and a reduced reproducer for that is
```opt -passes=instcombine bbi-99792.ll -o /dev/null```

[bbi-99792.ll.gz](https://github.com/user-attachments/files/17253640/bbi-99792.ll.gz)


https://github.com/llvm/llvm-project/pull/110506
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clang-include-cleaner] Fix -Wpessimizing-move warning introduced in 4cda28c1ada702a08f6960eb4c93919187c1d4d1 (PR #112684)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

Already fixed in 2954d1f7bc8f
```
[include-cleaner] Fix -Wpessimizing-move in IncludeCleaner.cpp (NFC)


/llvm-project/clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp:302:14:
error: moving a temporary object prevents copy elision 
[-Werror,-Wpessimizing-move]
  return std::move(llvm::errorCodeToError(Err));
 ^

/llvm-project/clang-tools-extra/include-cleaner/tool/IncludeCleaner.cpp:302:14: 
note: remove std::move call here
  return std::move(llvm::errorCodeToError(Err));
 ^~   ~
1 error generated.
```

https://github.com/llvm/llvm-project/pull/112684
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [compiler-rt] [llvm] [X86] Support MOVRS and AVX10.2 instructions. (PR #113274)

[Mikael Holmén via cfe-commits]

@@ -0,0 +1,50 @@
+// RUN: %clang_cc1 -ffreestanding %s -Wno-implicit-function-declaration 
-triple=i386-- -target-feature +movrs -target-feature +avx10.2-512 -emit-llvm 
-verify

mikaelholmen wrote:

Thanks!

https://github.com/llvm/llvm-project/pull/113274
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [compiler-rt] [llvm] [X86] Support MOVRS and AVX10.2 instructions. (PR #113274)

[Mikael Holmén via cfe-commits]

@@ -0,0 +1,50 @@
+// RUN: %clang_cc1 -ffreestanding %s -Wno-implicit-function-declaration 
-triple=i386-- -target-feature +movrs -target-feature +avx10.2-512 -emit-llvm 
-verify

mikaelholmen wrote:

Since we don't care about the actual output, can we remove "-emit-llvm" here to 
avoid writing to the local disc (which may be write-protected)?
See e.g. b7730a23ef
```[test] Avoid writing to a potentially write-protected dir (#102073)```
which solves a similar issue.


https://github.com/llvm/llvm-project/pull/113274
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [compiler-rt] [llvm] [X86] Support MOVRS and AVX10.2 instructions. (PR #113274)

[Mikael Holmén via cfe-commits]

@@ -0,0 +1,98 @@
+// RUN: %clang_cc1 -ffreestanding %s -Wno-implicit-function-declaration 
-triple=i386-unknown-unknown -target-feature +movrs -target-feature 
+avx10.2-256 -emit-llvm -verify

mikaelholmen wrote:

Same thing here, can we remove "-emit-llvm" since we don't care about the 
output anyway?

https://github.com/llvm/llvm-project/pull/113274
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Extend diagnose_if to accept more detailed warning information (PR #70976)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

Thanks @kadircet 

https://github.com/llvm/llvm-project/pull/70976
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-tools-extra] [clang] Extend diagnose_if to accept more detailed warning information (PR #70976)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

Hello,

I noticed that before this patch
```clang empty.c -fsanitize=undefined -ffine-grained-bitfield-accesses -c 
-Werror```
(on empty file empty.c) resulted in
```warning: option '-ffine-grained-bitfield-accesses' cannot be enabled 
together with a sanitizer; flag ignored```
but with the patch it results in
```error: option '-ffine-grained-bitfield-accesses' cannot be enabled together 
with a sanitizer; flag ignored [-Werror]```

Is this on purpose?

(I originally asked this in
 https://github.com/llvm/llvm-project/pull/108453#issuecomment-2352155766
but I suppose this PR has a bit wider audience.)

https://github.com/llvm/llvm-project/pull/70976
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Indicate UnarySymExpr is not supported by Z3 (PR #108900)

[Mikael Holmén via cfe-commits]

@@ -278,6 +278,13 @@ class SMTConstraintManager : public 
clang::ento::SimpleConstraintManager {
 if (const SymbolCast *SC = dyn_cast(Sym))
   return canReasonAbout(SVB.makeSymbolVal(SC->getOperand()));
 
+// If a UnarySymExpr is encountered, the Z3
+// wrapper does not support those. So indicate Z3 does not
+// support those and return.
+if (dyn_cast(Sym)) {

mikaelholmen wrote:

You can use "isa" here instead of dyn_cast since we're not really using the 
casted value anyway.

https://github.com/llvm/llvm-project/pull/108900
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang-format] Add test to ensure formatting options docs are updated (PR #118154)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

Thanks!

https://github.com/llvm/llvm-project/pull/118154
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [Darwin][Driver][clang] apple-none-macho orders the resource directory after internal-externc-isystem when nostdlibinc is used (PR #120507)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

Thanks @nico !

https://github.com/llvm/llvm-project/pull/120507
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [Darwin][Driver][clang] apple-none-macho orders the resource directory after internal-externc-isystem when nostdlibinc is used (PR #120507)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

> LLVM Buildbot has detected a new failure on builder `fuchsia-x86_64-linux` 
> running on `fuchsia-debian-64-us-central1-a-1` while building `clang,llvm` at 
> step 4 "annotate".
> 
> Full details are available at: 
> https://lab.llvm.org/buildbot/#/builders/11/builds/10589
> Here is the relevant piece of the build log for the reference
> 
> ```
> Step 4 (annotate) failure: 'python 
> ../llvm-zorg/zorg/buildbot/builders/annotated/fuchsia-linux.py ...' (failure)
> ...
> [846/1364] Linking CXX executable tools/clang/unittests/AST/ASTTests
> [846/1364] Running the Clang regression tests
> llvm-lit: 
> /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/llvm/utils/lit/lit/llvm/config.py:506:
>  note: using clang: 
> /var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-1zsna1lo/bin/clang
> llvm-lit: 
> /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/llvm/utils/lit/lit/llvm/subst.py:126:
>  note: Did not find clang-repl in 
> /var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-1zsna1lo/bin:/var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-1zsna1lo/bin
> llvm-lit: 
> /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/llvm/utils/lit/lit/llvm/config.py:506:
>  note: using ld.lld: 
> /var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-1zsna1lo/bin/ld.lld
> llvm-lit: 
> /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/llvm/utils/lit/lit/llvm/config.py:506:
>  note: using lld-link: 
> /var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-1zsna1lo/bin/lld-link
> llvm-lit: 
> /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/llvm/utils/lit/lit/llvm/config.py:506:
>  note: using ld64.lld: 
> /var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-1zsna1lo/bin/ld64.lld
> llvm-lit: 
> /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/llvm/utils/lit/lit/llvm/config.py:506:
>  note: using wasm-ld: 
> /var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-1zsna1lo/bin/wasm-ld
> -- Testing: 21759 tests, 60 workers --
> Testing:  0.. 10.. 20.. 30.. 40..
> FAIL: Clang :: Driver/darwin-embedded-search-paths.c (10812 of 21759)
>  TEST 'Clang :: Driver/darwin-embedded-search-paths.c' 
> FAILED 
> Exit Code: 1
> 
> Command Output (stderr):
> --
> RUN: at line 6: 
> /var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-1zsna1lo/bin/clang -x 
> c -target arm64-apple-none-macho -isysroot 
> /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/clang/test/Driver/Inputs/MacOSX15.1.sdk
>  -### -c 
> /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/clang/test/Driver/darwin-embedded-search-paths.c
>  2>&1  | 
> /var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-1zsna1lo/bin/FileCheck
>  --check-prefixes=CC1,NO-CXX,ULI,CI,UI,NO-FW 
> -DSDKROOT=/var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/clang/test/Driver/Inputs/MacOSX15.1.sdk
>  
> /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/clang/test/Driver/darwin-embedded-search-paths.c
> + 
> /var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-1zsna1lo/bin/FileCheck
>  --check-prefixes=CC1,NO-CXX,ULI,CI,UI,NO-FW 
> -DSDKROOT=/var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/clang/test/Driver/Inputs/MacOSX15.1.sdk
>  
> /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/clang/test/Driver/darwin-embedded-search-paths.c
> + /var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-1zsna1lo/bin/clang 
> -x c -target arm64-apple-none-macho -isysroot 
> /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/clang/test/Driver/Inputs/MacOSX15.1.sdk
>  -### -c 
> /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/clang/test/Driver/darwin-embedded-search-paths.c
> RUN: at line 10: 
> /var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-1zsna1lo/bin/clang -x 
> c++ -target arm64-apple-none-macho -isysroot 
> /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/clang/test/Driver/Inputs/MacOSX15.1.sdk
>  -### -c 
> /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/clang/test/Driver/darwin-embedded-search-paths.c
>  2>&1  | 
> /var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-1zsna1lo/bin/FileCheck
>  --check-prefixes=CC1,NO-CXX,ULI,CI,UI,NO-FW 
> -DSDKROOT=/var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/clang/test/Driver/Inputs/MacOSX15.1.sdk
>  
> /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/clang/test/Driver/darwin-embedded-search-paths.c
> + 
> /var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-1zsna1lo/bin/FileCheck
>  --check-prefixes=CC1,NO-CXX,ULI,CI,UI,NO-FW 
> -DSDKROOT=/var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/clang/test/Driver/Inputs/MacOSX15.1.sdk
>  
> /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/clang/test/Driver/darwin-embedded-search-paths.c
> + /var/lib/buildbot/fuchsia-x86_64-linux/build/llvm-build-1zsna1lo/bin/clang 
> -x c++ -target arm64-apple-none-macho -isysroot 
> /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/clang/test/Driver/Inputs/MacOSX15.1.sdk
>  -### -c 
> /var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/clang/test/D

[clang-tools-extra] [clangd] Support .clangd command line modifications for C++ modules (PR #122606)

[Mikael Holmén via cfe-commits]

@@ -830,6 +830,16 @@ bool OverlayCDB::setCompileCommand(PathRef File,
   return true;
 }
 
+std::unique_ptr
+OverlayCDB::getProjectModules(PathRef File) const {
+  auto MDB = DelegatingCDB::getProjectModules(File);
+  MDB->setCommandMangler([&Mangler = Mangler](tooling::CompileCommand &Command,
+  PathRef CommandPath) {
+Mangler(Command, CommandPath);
+  });
+  return std::move(MDB);

mikaelholmen wrote:

Hi @petr-polezhaev 

I see that clang (18.1.8) complains on this move:
```
12:29:43 
../llvm-project/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp:840:10: 
error: moving a local object in a return statement prevents copy elision 
[-Werror,-Wpessimizing-move]
12:29:43   840 |   return std::move(MDB);
12:29:43   |  ^
12:29:43 
../llvm-project/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp:840:10: 
note: remove std::move call here
12:29:43   840 |   return std::move(MDB);
12:29:43   |  ^~   ~
12:29:43 1 error generated.
```

https://github.com/llvm/llvm-project/pull/122606
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [clangd] Support .clangd command line modifications for C++ modules (PR #122606)

[Mikael Holmén via cfe-commits]

@@ -830,6 +830,16 @@ bool OverlayCDB::setCompileCommand(PathRef File,
   return true;
 }
 
+std::unique_ptr
+OverlayCDB::getProjectModules(PathRef File) const {
+  auto MDB = DelegatingCDB::getProjectModules(File);
+  MDB->setCommandMangler([&Mangler = Mangler](tooling::CompileCommand &Command,
+  PathRef CommandPath) {
+Mangler(Command, CommandPath);
+  });
+  return std::move(MDB);

mikaelholmen wrote:

Thanks!

https://github.com/llvm/llvm-project/pull/122606
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][analysis] Fix flaky clang/test/Analysis/live-stmts.cpp test (PR #126913)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

Unfortunately the test still seems to be flaky. With EXPENSIVE_CHECKS I often 
see it fail on the RHEL8 x86_64 machines I use.
E.g.
```
FAIL: Clang :: Analysis/live-stmts.cpp (1 of 1)
 TEST 'Clang :: Analysis/live-stmts.cpp' FAILED 

Exit Code: 1

Command Output (stderr):
--
RUN: at line 1: /repo/uabelho/main-github/llvm/build-all-expensive/bin/clang 
-cc1 -internal-isystem 
/repo/uabelho/main-github/llvm/build-all-expensive/lib/clang/21/include 
-nostdsysteminc -analyze -analyzer-constraints=range -setup-static-analyzer -w 
-analyzer-checker=debug.DumpLiveExprs 
/repo/uabelho/main-github/clang/test/Analysis/live-stmts.cpp 2>&1   | 
/repo/uabelho/main-github/llvm/build-all-expensive/bin/FileCheck 
/repo/uabelho/main-github/clang/test/Analysis/live-stmts.cpp
+ /repo/uabelho/main-github/llvm/build-all-expensive/bin/clang -cc1 
-internal-isystem 
/repo/uabelho/main-github/llvm/build-all-expensive/lib/clang/21/include 
-nostdsysteminc -analyze -analyzer-constraints=range -setup-static-analyzer -w 
-analyzer-checker=debug.DumpLiveExprs 
/repo/uabelho/main-github/clang/test/Analysis/live-stmts.cpp
+ /repo/uabelho/main-github/llvm/build-all-expensive/bin/FileCheck 
/repo/uabelho/main-github/clang/test/Analysis/live-stmts.cpp
/repo/uabelho/main-github/clang/test/Analysis/live-stmts.cpp:227:16: error: 
CHECK-EMPTY: is not on the line after the previous match
// CHECK-EMPTY:
   ^
:160:1: note: 'next' match was here

^
:157:81: note: previous match ended here
| `-DeclRefExpr 0x55e1600cec58 '_Bool' lvalue ParmVar 0x55e1600cead8 'b' '_Bool'

^
:158:1: note: non-matching line after previous match is here
`-ImplicitCastExpr 0x55e1600cecb0 '_Bool' 
^

Input file: 
Check file: /repo/uabelho/main-github/clang/test/Analysis/live-stmts.cpp

-dump-input=help explains the following input dump.

Input was:
<<
   .
   .
   .
 155: BinaryOperator 0x55e1600cecc8 '_Bool' '||' 
 156: |-ImplicitCastExpr 0x55e1600cec98 '_Bool'  
 157: | `-DeclRefExpr 0x55e1600cec58 '_Bool' lvalue ParmVar 
0x55e1600cead8 'b' '_Bool' 
 158: `-ImplicitCastExpr 0x55e1600cecb0 '_Bool'  
 159:  `-DeclRefExpr 0x55e1600cec78 '_Bool' lvalue ParmVar 
0x55e1600cead8 'b' '_Bool' 
 160:  
empty:227 ! error: match on wrong line
 161: ImplicitCastExpr 0x55e1600cec98 '_Bool'  
 162: `-DeclRefExpr 0x55e1600cec58 '_Bool' lvalue ParmVar 
0x55e1600cead8 'b' '_Bool' 
 163:  
 164: ImplicitCastExpr 0x55e1600cecb0 '_Bool'  
 165: `-DeclRefExpr 0x55e1600cec78 '_Bool' lvalue ParmVar 
0x55e1600cead8 'b' '_Bool' 
   .
   .
   .
>>

--



Failed Tests (1):
  Clang :: Analysis/live-stmts.cpp
```

https://github.com/llvm/llvm-project/pull/126913
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][analysis] Fix flaky clang/test/Analysis/live-stmts.cpp test (PR #126913)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

> > Unfortunately the test still seems to be flaky. With EXPENSIVE_CHECKS I 
> > often see it fail on the RHEL8 x86_64 machines I use.
> > E.g.
> > ```
> > FAIL: Clang :: Analysis/live-stmts.cpp (1 of 1)
> >  TEST 'Clang :: Analysis/live-stmts.cpp' FAILED 
> > 
> > Exit Code: 1
> > 
> > Command Output (stderr):
> > --
> > RUN: at line 1: 
> > /repo/uabelho/main-github/llvm/build-all-expensive/bin/clang -cc1 
> > -internal-isystem 
> > /repo/uabelho/main-github/llvm/build-all-expensive/lib/clang/21/include 
> > -nostdsysteminc -analyze -analyzer-constraints=range -setup-static-analyzer 
> > -w -analyzer-checker=debug.DumpLiveExprs 
> > /repo/uabelho/main-github/clang/test/Analysis/live-stmts.cpp 2>&1   | 
> > /repo/uabelho/main-github/llvm/build-all-expensive/bin/FileCheck 
> > /repo/uabelho/main-github/clang/test/Analysis/live-stmts.cpp
> > + /repo/uabelho/main-github/llvm/build-all-expensive/bin/clang -cc1 
> > -internal-isystem 
> > /repo/uabelho/main-github/llvm/build-all-expensive/lib/clang/21/include 
> > -nostdsysteminc -analyze -analyzer-constraints=range -setup-static-analyzer 
> > -w -analyzer-checker=debug.DumpLiveExprs 
> > /repo/uabelho/main-github/clang/test/Analysis/live-stmts.cpp
> > + /repo/uabelho/main-github/llvm/build-all-expensive/bin/FileCheck 
> > /repo/uabelho/main-github/clang/test/Analysis/live-stmts.cpp
> > /repo/uabelho/main-github/clang/test/Analysis/live-stmts.cpp:227:16: error: 
> > CHECK-EMPTY: is not on the line after the previous match
> > // CHECK-EMPTY:
> >^
> > :160:1: note: 'next' match was here
> > 
> > ^
> > :157:81: note: previous match ended here
> > | `-DeclRefExpr 0x55e1600cec58 '_Bool' lvalue ParmVar 0x55e1600cead8 'b' 
> > '_Bool'
> > 
> > ^
> > :158:1: note: non-matching line after previous match is here
> > `-ImplicitCastExpr 0x55e1600cecb0 '_Bool' 
> > ^
> > 
> > Input file: 
> > Check file: /repo/uabelho/main-github/clang/test/Analysis/live-stmts.cpp
> > 
> > -dump-input=help explains the following input dump.
> > 
> > Input was:
> > <<
> >.
> >.
> >.
> >  155: BinaryOperator 0x55e1600cecc8 '_Bool' '||' 
> >  156: |-ImplicitCastExpr 0x55e1600cec98 '_Bool'  
> >  157: | `-DeclRefExpr 0x55e1600cec58 '_Bool' lvalue ParmVar 
> > 0x55e1600cead8 'b' '_Bool' 
> >  158: `-ImplicitCastExpr 0x55e1600cecb0 '_Bool'  
> >  159:  `-DeclRefExpr 0x55e1600cec78 '_Bool' lvalue ParmVar 
> > 0x55e1600cead8 'b' '_Bool' 
> >  160:  
> > empty:227 ! error: match on wrong line
> >  161: ImplicitCastExpr 0x55e1600cec98 '_Bool'  
> >  162: `-DeclRefExpr 0x55e1600cec58 '_Bool' lvalue ParmVar 
> > 0x55e1600cead8 'b' '_Bool' 
> >  163:  
> >  164: ImplicitCastExpr 0x55e1600cecb0 '_Bool'  
> >  165: `-DeclRefExpr 0x55e1600cec78 '_Bool' lvalue ParmVar 
> > 0x55e1600cead8 'b' '_Bool' 
> >.
> >.
> >.
> > >>
> > 
> > --
> > 
> > 
> > 
> > Failed Tests (1):
> >   Clang :: Analysis/live-stmts.cpp
> > ```
> 
> Oh cmmon. :( Could you send me your nonpassing output, the whole one? 
> @mikaelholmen

Yep 
[out.log](https://github.com/user-attachments/files/18779754/out.log)


https://github.com/llvm/llvm-project/pull/126913
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [CaptureTracking][FunctionAttrs] Add support for CaptureInfo (PR #125880)

[Mikael Holmén via cfe-commits]

mikaelholmen wrote:

Hi,

Heads up that I see a miscompile with this patch where a needed store is 
removed. I'll try to extract some kind of reproducer.

https://github.com/llvm/llvm-project/pull/125880
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [analyzer] Disable a flaky test while triaging why its flaky (PR #127034)

[Mikael Holmén via cfe-commits]

https://github.com/mikaelholmen approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/127034
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits