[PATCH] D58091: Customize warnings for missing built-in type

[Johannes Doerfert via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367387: [Fix] Customize warnings for missing built-in types 
(authored by jdoerfert, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D58091?vs=212500=212503#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58091/new/

https://reviews.llvm.org/D58091

Files:
  cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
  cfe/trunk/lib/Sema/SemaDecl.cpp
  cfe/trunk/test/Analysis/retain-release.m
  cfe/trunk/test/Sema/builtin-setjmp.c
  cfe/trunk/test/Sema/implicit-builtin-decl.c

Index: cfe/trunk/lib/Sema/SemaDecl.cpp
===
--- cfe/trunk/lib/Sema/SemaDecl.cpp
+++ cfe/trunk/lib/Sema/SemaDecl.cpp
@@ -1983,10 +1983,27 @@
   ASTContext::GetBuiltinTypeError Error;
   QualType R = Context.GetBuiltinType(ID, Error);
   if (Error) {
-if (ForRedeclaration)
-  Diag(Loc, diag::warn_implicit_decl_requires_sysheader)
-  << getHeaderName(Context.BuiltinInfo, ID, Error)
+if (!ForRedeclaration)
+  return nullptr;
+
+// If we have a builtin without an associated type we should not emit a
+// warning when we were not able to find a type for it.
+if (Error == ASTContext::GE_Missing_type)
+  return nullptr;
+
+// If we could not find a type for setjmp it is because the jmp_buf type was
+// not defined prior to the setjmp declaration.
+if (Error == ASTContext::GE_Missing_setjmp) {
+  Diag(Loc, diag::warn_implicit_decl_no_jmp_buf)
   << Context.BuiltinInfo.getName(ID);
+  return nullptr;
+}
+
+// Generally, we emit a warning that the declaration requires the
+// appropriate header.
+Diag(Loc, diag::warn_implicit_decl_requires_sysheader)
+<< getHeaderName(Context.BuiltinInfo, ID, Error)
+<< Context.BuiltinInfo.getName(ID);
 return nullptr;
   }
 
Index: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
@@ -598,6 +598,10 @@
 def note_include_header_or_declare : Note<
   "include the header <%0> or explicitly provide a declaration for '%1'">;
 def note_previous_builtin_declaration : Note<"%0 is a builtin with type %1">;
+def warn_implicit_decl_no_jmp_buf
+: Warning<"declaration of built-in function '%0' requires the declaration"
+" of the 'jmp_buf' type, commonly provided in the header .">,
+  InGroup>;
 def warn_implicit_decl_requires_sysheader : Warning<
   "declaration of built-in function '%1' requires inclusion of the header <%0>">,
   InGroup;
Index: cfe/trunk/test/Sema/builtin-setjmp.c
===
--- cfe/trunk/test/Sema/builtin-setjmp.c
+++ cfe/trunk/test/Sema/builtin-setjmp.c
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -verify -DNO_JMP_BUF %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -verify %s
+
+#ifdef NO_JMP_BUF
+extern long setjmp(long *);   // expected-warning {{declaration of built-in function 'setjmp' requires the declaration of the 'jmp_buf' type, commonly provided in the header .}}
+#else
+typedef long jmp_buf;
+extern int setjmp(char);  // expected-warning@8 {{incompatible redeclaration of library function 'setjmp'}}
+  // expected-note@8{{'setjmp' is a builtin with type 'int (jmp_buf)' (aka 'int (long)')}}
+#endif
Index: cfe/trunk/test/Sema/implicit-builtin-decl.c
===
--- cfe/trunk/test/Sema/implicit-builtin-decl.c
+++ cfe/trunk/test/Sema/implicit-builtin-decl.c
@@ -55,14 +55,17 @@
 
 void snprintf() { }
 
-// PR8316
-void longjmp(); // expected-warning{{declaration of built-in function 'longjmp' requires inclusion of the header }}
+// PR8316 & PR40692
+void longjmp(); // expected-warning{{declaration of built-in function 'longjmp' requires the declaration of the 'jmp_buf' type, commonly provided in the header .}}
 
 extern float fmaxf(float, float);
 
 struct __jmp_buf_tag {};
-void sigsetjmp(struct __jmp_buf_tag[1], int); // expected-warning{{declaration of built-in function 'sigsetjmp' requires inclusion of the header }}
+void sigsetjmp(struct __jmp_buf_tag[1], int); // expected-warning{{declaration of built-in function 'sigsetjmp' requires the declaration of the 'jmp_buf' type, commonly provided in the header .}}
 
 // CHECK: FunctionDecl {{.*}}  col:6 sigsetjmp '
 // CHECK-NOT: FunctionDecl
 // CHECK: ReturnsTwiceAttr {{.*}} <{{.*}}> Implicit
+
+// PR40692
+void pthread_create(); // no warning expected
Index: cfe/trunk/test/Analysis/retain-release.m
===
--- 

r367387 - [Fix] Customize warnings for missing built-in types

[Johannes Doerfert via cfe-commits]

Author: jdoerfert
Date: Tue Jul 30 22:16:38 2019
New Revision: 367387

URL: http://llvm.org/viewvc/llvm-project?rev=367387=rev
Log:
[Fix] Customize warnings for missing built-in types

If we detect a built-in declaration for which we cannot derive a type
matching the pattern in the Builtins.def file, we currently emit a
warning that the respective header is needed. However, this is not
necessarily the behavior we want as it has no connection to the location
of the declaration (which can actually be in the header in question).
Instead, this warning is generated
  - if we could not build the type for the pattern on file (for some
reason). Here we should make the reason explicit. The actual problem
is otherwise circumvented as the warning is misleading, see [0] for
an example.
  - if we could not build the type for the pattern because we do not
have a type on record, possible since D55483, we should not emit any
warning. See [1] for a legitimate problem.

This patch address both cases. For the "setjmp" family a new warning is
introduced and for built-ins without type on record, so far
"pthread_create", we do not emit the warning anymore.

Also see: PR40692

[0] https://lkml.org/lkml/2019/1/11/718
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235583

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

Added:
cfe/trunk/test/Sema/builtin-setjmp.c
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/Analysis/retain-release.m
cfe/trunk/test/Sema/implicit-builtin-decl.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=367387=367386=367387=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue Jul 30 22:16:38 
2019
@@ -598,6 +598,10 @@ def ext_implicit_lib_function_decl : Ext
 def note_include_header_or_declare : Note<
   "include the header <%0> or explicitly provide a declaration for '%1'">;
 def note_previous_builtin_declaration : Note<"%0 is a builtin with type %1">;
+def warn_implicit_decl_no_jmp_buf
+: Warning<"declaration of built-in function '%0' requires the declaration"
+" of the 'jmp_buf' type, commonly provided in the header .">,
+  InGroup>;
 def warn_implicit_decl_requires_sysheader : Warning<
   "declaration of built-in function '%1' requires inclusion of the header 
<%0>">,
   InGroup;

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=367387=367386=367387=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Tue Jul 30 22:16:38 2019
@@ -1983,10 +1983,27 @@ NamedDecl *Sema::LazilyCreateBuiltin(Ide
   ASTContext::GetBuiltinTypeError Error;
   QualType R = Context.GetBuiltinType(ID, Error);
   if (Error) {
-if (ForRedeclaration)
-  Diag(Loc, diag::warn_implicit_decl_requires_sysheader)
-  << getHeaderName(Context.BuiltinInfo, ID, Error)
+if (!ForRedeclaration)
+  return nullptr;
+
+// If we have a builtin without an associated type we should not emit a
+// warning when we were not able to find a type for it.
+if (Error == ASTContext::GE_Missing_type)
+  return nullptr;
+
+// If we could not find a type for setjmp it is because the jmp_buf type 
was
+// not defined prior to the setjmp declaration.
+if (Error == ASTContext::GE_Missing_setjmp) {
+  Diag(Loc, diag::warn_implicit_decl_no_jmp_buf)
   << Context.BuiltinInfo.getName(ID);
+  return nullptr;
+}
+
+// Generally, we emit a warning that the declaration requires the
+// appropriate header.
+Diag(Loc, diag::warn_implicit_decl_requires_sysheader)
+<< getHeaderName(Context.BuiltinInfo, ID, Error)
+<< Context.BuiltinInfo.getName(ID);
 return nullptr;
   }
 

Modified: cfe/trunk/test/Analysis/retain-release.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/retain-release.m?rev=367387=367386=367387=diff
==
--- cfe/trunk/test/Analysis/retain-release.m (original)
+++ cfe/trunk/test/Analysis/retain-release.m Tue Jul 30 22:16:38 2019
@@ -2,7 +2,7 @@
 // RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10\
 // RUN: -analyzer-checker=core,osx.coreFoundation.CFRetainRelease\
 // RUN: -analyzer-checker=osx.cocoa.ClassRelease,osx.cocoa.RetainCount\
-// RUN: -analyzer-checker=debug.ExprInspection -fblocks -verify=expected,C 
%s\
+// RUN: -analyzer-checker=debug.ExprInspection -fblocks -verify %s\
 // RUN: -Wno-objc-root-class -analyzer-output=plist -o %t.objc.plist
 // RUN: 

[PATCH] D58091: Customize warnings for missing built-in type

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert updated this revision to Diff 212500.
jdoerfert added a comment.

Fix spelling in tests


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58091/new/

https://reviews.llvm.org/D58091

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDecl.cpp
  clang/test/Analysis/retain-release.m
  clang/test/Sema/builtin-setjmp.c
  clang/test/Sema/implicit-builtin-decl.c

Index: clang/test/Sema/implicit-builtin-decl.c
===
--- clang/test/Sema/implicit-builtin-decl.c
+++ clang/test/Sema/implicit-builtin-decl.c
@@ -55,14 +55,17 @@
 
 void snprintf() { }
 
-// PR8316
-void longjmp(); // expected-warning{{declaration of built-in function 'longjmp' requires inclusion of the header }}
+// PR8316 & PR40692
+void longjmp(); // expected-warning{{declaration of built-in function 'longjmp' requires the declaration of the 'jmp_buf' type, commonly provided in the header .}}
 
 extern float fmaxf(float, float);
 
 struct __jmp_buf_tag {};
-void sigsetjmp(struct __jmp_buf_tag[1], int); // expected-warning{{declaration of built-in function 'sigsetjmp' requires inclusion of the header }}
+void sigsetjmp(struct __jmp_buf_tag[1], int); // expected-warning{{declaration of built-in function 'sigsetjmp' requires the declaration of the 'jmp_buf' type, commonly provided in the header .}}
 
 // CHECK: FunctionDecl {{.*}}  col:6 sigsetjmp '
 // CHECK-NOT: FunctionDecl
 // CHECK: ReturnsTwiceAttr {{.*}} <{{.*}}> Implicit
+
+// PR40692
+void pthread_create(); // no warning expected
Index: clang/test/Sema/builtin-setjmp.c
===
--- /dev/null
+++ clang/test/Sema/builtin-setjmp.c
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -verify -DNO_JMP_BUF %s
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -verify %s
+
+#ifdef NO_JMP_BUF
+extern long setjmp(long *);   // expected-warning {{declaration of built-in function 'setjmp' requires the declaration of the 'jmp_buf' type, commonly provided in the header .}}
+#else
+typedef long jmp_buf;
+extern int setjmp(char);  // expected-warning@8 {{incompatible redeclaration of library function 'setjmp'}}
+  // expected-note@8{{'setjmp' is a builtin with type 'int (jmp_buf)' (aka 'int (long)')}}
+#endif
Index: clang/test/Analysis/retain-release.m
===
--- clang/test/Analysis/retain-release.m
+++ clang/test/Analysis/retain-release.m
@@ -2,7 +2,7 @@
 // RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10\
 // RUN: -analyzer-checker=core,osx.coreFoundation.CFRetainRelease\
 // RUN: -analyzer-checker=osx.cocoa.ClassRelease,osx.cocoa.RetainCount\
-// RUN: -analyzer-checker=debug.ExprInspection -fblocks -verify=expected,C %s\
+// RUN: -analyzer-checker=debug.ExprInspection -fblocks -verify %s\
 // RUN: -Wno-objc-root-class -analyzer-output=plist -o %t.objc.plist
 // RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10\
 // RUN: -analyzer-checker=core,osx.coreFoundation.CFRetainRelease\
@@ -1231,7 +1231,7 @@
 typedef unsigned long __darwin_pthread_key_t;
 typedef __darwin_pthread_key_t pthread_key_t;
 
-int pthread_create(pthread_t *, const pthread_attr_t *,  // C-warning{{declaration of built-in function 'pthread_create' requires inclusion of the header }}
+int pthread_create(pthread_t *, const pthread_attr_t *,
void *(*)(void *), void *);
 
 int pthread_setspecific(pthread_key_t key, const void *value);
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -1983,10 +1983,27 @@
   ASTContext::GetBuiltinTypeError Error;
   QualType R = Context.GetBuiltinType(ID, Error);
   if (Error) {
-if (ForRedeclaration)
-  Diag(Loc, diag::warn_implicit_decl_requires_sysheader)
-  << getHeaderName(Context.BuiltinInfo, ID, Error)
+if (!ForRedeclaration)
+  return nullptr;
+
+// If we have a builtin without an associated type we should not emit a
+// warning when we were not able to find a type for it.
+if (Error == ASTContext::GE_Missing_type)
+  return nullptr;
+
+// If we could not find a type for setjmp it is because the jmp_buf type was
+// not defined prior to the setjmp declaration.
+if (Error == ASTContext::GE_Missing_setjmp) {
+  Diag(Loc, diag::warn_implicit_decl_no_jmp_buf)
   << Context.BuiltinInfo.getName(ID);
+  return nullptr;
+}
+
+// Generally, we emit a warning that the declaration requires the
+// appropriate header.
+Diag(Loc, diag::warn_implicit_decl_requires_sysheader)
+<< getHeaderName(Context.BuiltinInfo, ID, Error)
+<< Context.BuiltinInfo.getName(ID);
 return nullptr;
   }
 
Index: 

[PATCH] D65458: [NFC] Remove LLVM_ALIGNAS

[JF Bastien via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367383: [NFC] Remove LLVM_ALIGNAS (authored by jfb, 
committed by ).
Herald added a subscriber: kristina.

Changed prior to commit:
  https://reviews.llvm.org/D65458?vs=212368=212496#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65458/new/

https://reviews.llvm.org/D65458

Files:
  cfe/trunk/docs/doxygen.cfg.in
  clang-tools-extra/trunk/docs/doxygen.cfg.in
  llvm/trunk/cmake/modules/HandleLLVMOptions.cmake
  llvm/trunk/docs/doxygen.cfg.in
  llvm/trunk/include/llvm/Support/Compiler.h
  llvm/trunk/unittests/Support/AlignOfTest.cpp

Index: cfe/trunk/docs/doxygen.cfg.in
===
--- cfe/trunk/docs/doxygen.cfg.in
+++ cfe/trunk/docs/doxygen.cfg.in
@@ -1925,7 +1925,7 @@
 # recursively expanded use the := operator instead of the = operator.
 # This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
 
-PREDEFINED = LLVM_ALIGNAS(x)=
+PREDEFINED =
 
 # If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
 # tag can be used to specify a list of macro names that should be expanded. The
Index: llvm/trunk/include/llvm/Support/Compiler.h
===
--- llvm/trunk/include/llvm/Support/Compiler.h
+++ llvm/trunk/include/llvm/Support/Compiler.h
@@ -338,14 +338,6 @@
 # define LLVM_ASSUME_ALIGNED(p, a) (p)
 #endif
 
-/// \macro LLVM_ALIGNAS
-/// Used to specify a minimum alignment for a structure or variable.
-#if __GNUC__ && !__has_feature(cxx_alignas) && !LLVM_GNUC_PREREQ(4, 8, 1)
-# define LLVM_ALIGNAS(x) __attribute__((aligned(x)))
-#else
-# define LLVM_ALIGNAS(x) alignas(x)
-#endif
-
 /// \macro LLVM_PACKED
 /// Used to specify a packed structure.
 /// LLVM_PACKED(
@@ -376,8 +368,8 @@
 
 /// \macro LLVM_PTR_SIZE
 /// A constant integer equivalent to the value of sizeof(void*).
-/// Generally used in combination with LLVM_ALIGNAS or when doing computation in
-/// the preprocessor.
+/// Generally used in combination with alignas or when doing computation in the
+/// preprocessor.
 #ifdef __SIZEOF_POINTER__
 # define LLVM_PTR_SIZE __SIZEOF_POINTER__
 #elif defined(_WIN64)
Index: llvm/trunk/cmake/modules/HandleLLVMOptions.cmake
===
--- llvm/trunk/cmake/modules/HandleLLVMOptions.cmake
+++ llvm/trunk/cmake/modules/HandleLLVMOptions.cmake
@@ -530,14 +530,6 @@
   # is fixed.
   -wd4709 # Suppress comma operator within array index expression
 
-  # Ideally, we'd like this warning to be enabled, but MSVC 2013 doesn't
-  # support the 'aligned' attribute in the way that clang sources requires (for
-  # any code that uses the LLVM_ALIGNAS macro), so this is must be disabled to
-  # avoid unwanted alignment warnings.
-  # When we switch to requiring a version of MSVC that supports the 'alignas'
-  # specifier (MSVC 2015?) this warning can be re-enabled.
-  -wd4324 # Suppress 'structure was padded due to __declspec(align())'
-
   # Promoted warnings.
   -w14062 # Promote 'enumerator in switch of enum is not handled' to level 1 warning.
 
Index: llvm/trunk/unittests/Support/AlignOfTest.cpp
===
--- llvm/trunk/unittests/Support/AlignOfTest.cpp
+++ llvm/trunk/unittests/Support/AlignOfTest.cpp
@@ -38,10 +38,10 @@
 #endif
 
 // Define some fixed alignment types to use in these tests.
-struct LLVM_ALIGNAS(1) A1 {};
-struct LLVM_ALIGNAS(2) A2 {};
-struct LLVM_ALIGNAS(4) A4 {};
-struct LLVM_ALIGNAS(8) A8 {};
+struct alignas(1) A1 {};
+struct alignas(2) A2 {};
+struct alignas(4) A4 {};
+struct alignas(8) A8 {};
 
 struct S1 {};
 struct S2 { char a; };
Index: llvm/trunk/docs/doxygen.cfg.in
===
--- llvm/trunk/docs/doxygen.cfg.in
+++ llvm/trunk/docs/doxygen.cfg.in
@@ -1926,7 +1926,7 @@
 # recursively expanded use the := operator instead of the = operator.
 # This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
 
-PREDEFINED = LLVM_ALIGNAS(x)=
+PREDEFINED =
 
 # If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
 # tag can be used to specify a list of macro names that should be expanded. The
Index: clang-tools-extra/trunk/docs/doxygen.cfg.in
===
--- clang-tools-extra/trunk/docs/doxygen.cfg.in
+++ clang-tools-extra/trunk/docs/doxygen.cfg.in
@@ -1937,7 +1937,7 @@
 # recursively expanded use the := operator instead of the = operator.
 # This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
 
-PREDEFINED = LLVM_ALIGNAS(x)=
+PREDEFINED =
 
 # If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
 # tag can be used to specify a list of 

r367383 - [NFC] Remove LLVM_ALIGNAS

[JF Bastien via cfe-commits]

Author: jfb
Date: Tue Jul 30 20:22:08 2019
New Revision: 367383

URL: http://llvm.org/viewvc/llvm-project?rev=367383=rev
Log:
[NFC] Remove LLVM_ALIGNAS

Summary: The minimum compilers support all have alignas, and we don't use 
LLVM_ALIGNAS anywhere anymore. This also removes an MSVC diagnostic which, 
according to the comment above, isn't relevant anymore.

Reviewers: rnk

Subscribers: mgorny, jkorous, dexonsmith, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

Modified:
cfe/trunk/docs/doxygen.cfg.in

Modified: cfe/trunk/docs/doxygen.cfg.in
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/doxygen.cfg.in?rev=367383=367382=367383=diff
==
--- cfe/trunk/docs/doxygen.cfg.in (original)
+++ cfe/trunk/docs/doxygen.cfg.in Tue Jul 30 20:22:08 2019
@@ -1925,7 +1925,7 @@ INCLUDE_FILE_PATTERNS  =
 # recursively expanded use the := operator instead of the = operator.
 # This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
 
-PREDEFINED = LLVM_ALIGNAS(x)=
+PREDEFINED =
 
 # If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
 # tag can be used to specify a list of macro names that should be expanded. The


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

[clang-tools-extra] r367383 - [NFC] Remove LLVM_ALIGNAS

[JF Bastien via cfe-commits]

Author: jfb
Date: Tue Jul 30 20:22:08 2019
New Revision: 367383

URL: http://llvm.org/viewvc/llvm-project?rev=367383=rev
Log:
[NFC] Remove LLVM_ALIGNAS

Summary: The minimum compilers support all have alignas, and we don't use 
LLVM_ALIGNAS anywhere anymore. This also removes an MSVC diagnostic which, 
according to the comment above, isn't relevant anymore.

Reviewers: rnk

Subscribers: mgorny, jkorous, dexonsmith, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

Modified:
clang-tools-extra/trunk/docs/doxygen.cfg.in

Modified: clang-tools-extra/trunk/docs/doxygen.cfg.in
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/doxygen.cfg.in?rev=367383=367382=367383=diff
==
--- clang-tools-extra/trunk/docs/doxygen.cfg.in (original)
+++ clang-tools-extra/trunk/docs/doxygen.cfg.in Tue Jul 30 20:22:08 2019
@@ -1937,7 +1937,7 @@ INCLUDE_FILE_PATTERNS  =
 # recursively expanded use the := operator instead of the = operator.
 # This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
 
-PREDEFINED = LLVM_ALIGNAS(x)=
+PREDEFINED =
 
 # If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
 # tag can be used to specify a list of macro names that should be expanded. The


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

[PATCH] D65300: [clang] [CodeGen] clang-misexpect prototype for compiler warnings

[Leonard Chan via Phabricator via cfe-commits]

leonardchan accepted this revision.
leonardchan added a comment.
This revision is now accepted and ready to land.

LGTM but I'd wait a day to see if anyone else has comments they'd like to add 
before landing.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65300/new/

https://reviews.llvm.org/D65300



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

[PATCH] D65300: [clang] [CodeGen] clang-misexpect prototype for compiler warnings

[Petr Hosek via Phabricator via cfe-commits]

phosek added inline comments.



Comment at: clang/lib/CodeGen/MisExpect.cpp:29
+
+void DebugPrintMisExpectSwitchInfo(SmallVector *SwitchWeights,
+   llvm::DenseMap *CaseMap);

It seems like `DebugPrintMisExpectSwitchInfo` and `EmitMisExpectWarning` is 
only used within this file, so I'd move them to anonymous namespace.



Comment at: clang/lib/CodeGen/MisExpect.cpp:74
+  LLVM_DEBUG(llvm::dbgs() << "Expected Value:\t" << ExpectedVal << "\n");
+  LLVM_DEBUG(llvm::dbgs() << "Current Count: \t" << CurrProfCount << "\n");
+  LLVM_DEBUG(llvm::dbgs() << "True Count: \t" << TrueCount << "\n");

No space between `:` and `\t` here and below.



Comment at: clang/lib/CodeGen/MisExpect.cpp:82
+  if (ExpectedTrueBranch) {
+const llvm::BranchProbability HotFunctionThreshold(1, 100);
+Scaled = HotFunctionThreshold.scale(CurrProfCount);

Are these thresholds defined anywhere as constants?



Comment at: clang/lib/CodeGen/MisExpect.cpp:94
+
+  if (IncorrectPerfCounters) {
+EmitMisExpectWarning(Call, CGM);

No need for `{` and `}`.



Comment at: clang/lib/CodeGen/MisExpect.cpp:122
+  uint64_t Index;
+  if (MapIndex != CaseMap->end()) {
+Index = MapIndex->second;

No need for { and }, in this case you can probably just use ternary expression.



Comment at: clang/lib/CodeGen/MisExpect.cpp:133
+
+  if (TakenCount < Max) {
+EmitMisExpectWarning(Call, CGM);

No need for { and }.



Comment at: clang/lib/CodeGen/MisExpect.h:10
+// This contains code to emit warnings for potentially incorrect usage of
+// __builtin_expect(). It uses PGO profiles to validation.
+//

`for validation` or `to validate`?



Comment at: clang/lib/CodeGen/MisExpect.h:34
+/// CheckMisExpectBranch - check if a branch is annotated with
+/// __builting_expect and when using profiling data, verify that the profile
+/// agrees with the use of the annotation

s/__builting_expect/__builtin_expect/



Comment at: clang/lib/CodeGen/MisExpect.h:36
+/// agrees with the use of the annotation
+
+void CheckMisExpectBranch(const Expr *Cond, uint64_t TrueCount,

extra empty line



Comment at: clang/lib/CodeGen/MisExpect.h:40
+
+/// CheckMisExpect - check if a branch is annotated with __builting_expect and
+/// when using profiling data, verify that the profile agrees with the use of

s/__builting_expect/__builtin_expect/


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65300/new/

https://reviews.llvm.org/D65300



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

[PATCH] D65300: [clang] [CodeGen] clang-misexpect prototype for compiler warnings

[Paul Kirth via Phabricator via cfe-commits]

paulkirth updated this revision to Diff 212492.
paulkirth added a comment.

Update diff to have proper context on Phabricator


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65300/new/

https://reviews.llvm.org/D65300

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CMakeLists.txt
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/CodeGen/MisExpect.cpp
  clang/lib/CodeGen/MisExpect.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Profile/Inputs/misexpect-branch-nonconst-expect-arg.proftext
  clang/test/Profile/Inputs/misexpect-branch.proftext
  clang/test/Profile/Inputs/misexpect-switch-default-only.proftext
  clang/test/Profile/Inputs/misexpect-switch.proftext
  clang/test/Profile/misexpect-branch-cold.c
  clang/test/Profile/misexpect-branch-nonconst-expected-val.c
  clang/test/Profile/misexpect-branch.c
  clang/test/Profile/misexpect-no-warning-without-flag.c
  clang/test/Profile/misexpect-switch-default.c
  clang/test/Profile/misexpect-switch-nonconst.c
  clang/test/Profile/misexpect-switch-only-default-case.c
  clang/test/Profile/misexpect-switch.c

Index: clang/test/Profile/misexpect-switch.c
===
--- /dev/null
+++ clang/test/Profile/misexpect-switch.c
@@ -0,0 +1,68 @@
+// Test that misexpect detects mis-annotated switch statements
+
+// RUN: llvm-profdata merge %S/Inputs/misexpect-switch.proftext -o %t.profdata
+// RUN: %clang_cc1 %s -O2 -o - -disable-llvm-passes -emit-llvm -fprofile-instrument-use-path=%t.profdata -verify -fmisexpect
+
+int sum(int *buff, int size);
+int random_sample(int *buff, int size);
+int rand();
+
+const int inner_loop = 1000;
+const int outer_loop = 20;
+const int arry_size = 25;
+
+int arry[arry_size] = {0};
+
+void init_arry() {
+  int i;
+  for (i = 0; i < arry_size; ++i) {
+arry[i] = rand() % 10;
+  }
+}
+
+int main() {
+  init_arry();
+  int val = 0;
+
+  int j, k;
+  for (j = 0; j < outer_loop; ++j) {
+for (k = 0; k < inner_loop; ++k) {
+  unsigned condition = rand() % 1;
+  switch (__builtin_expect(condition, 0)) { //expected-warning {{Current PGO counters disagree with the use of __builtin_expect().}}
+  case 0:
+val += sum(arry, arry_size);
+break;
+  case 1:
+  case 2:
+  case 3:
+  case 4:
+val += random_sample(arry, arry_size);
+break;
+  default:
+__builtin_unreachable();
+  } // end switch
+}   // end inner_loop
+  } // end outer_loop
+
+  return 0;
+}
+
+int sum(int *buff, int size) {
+  int total = 0;
+  int i = 0;
+  for (i = 0; i < size; ++i) {
+total += buff[i];
+  }
+  return total;
+}
+
+int random_sample(int *buff, int size) {
+  int total = 0;
+  int i;
+  for (i = 0; i < size; ++i) {
+if (rand() % 5 == 0)
+  total += buff[i];
+  }
+
+  return total;
+}
Index: clang/test/Profile/misexpect-switch-only-default-case.c
===
--- /dev/null
+++ clang/test/Profile/misexpect-switch-only-default-case.c
@@ -0,0 +1,62 @@
+// Test that misexpect detects mis-annotated switch statements
+
+// RUN: llvm-profdata merge %S/Inputs/misexpect-switch-default-only.proftext -o %t.profdata
+// RUN: %clang_cc1 %s -O2 -o - -disable-llvm-passes -emit-llvm -fprofile-instrument-use-path=%t.profdata -verify -fmisexpect
+
+// expected-no-diagnostics
+int sum(int *buff, int size);
+int random_sample(int *buff, int size);
+int rand();
+
+const int inner_loop = 1000;
+const int outer_loop = 20;
+const int arry_size = 25;
+
+int arry[arry_size] = {0};
+
+void init_arry() {
+  int i;
+  for (i = 0; i < arry_size; ++i) {
+arry[i] = rand() % 10;
+  }
+}
+
+int main()
+{
+init_arry();
+int val = 0;
+
+int j, k;
+for (j = 0; j < outer_loop; ++j) {
+for (k = 0; k < inner_loop; ++k) {
+unsigned condition = rand() % 1;
+switch (__builtin_expect(condition, 0)) {
+default:
+val += random_sample(arry, arry_size);
+break;
+}; // end switch
+}  // end inner_loop
+}  // end outer_loop
+
+return 0;
+}
+
+int sum(int *buff, int size) {
+  int total = 0;
+  int i = 0;
+  for (i = 0; i < size; ++i) {
+total += buff[i];
+  }
+  return total;
+}
+
+int random_sample(int *buff, int size) {
+  int total = 0;
+  int i;
+  for (i = 0; i < size; ++i) {
+if (rand() % 5 == 0)
+  total += buff[i];
+  }
+
+  return total;
+}
Index: clang/test/Profile/misexpect-switch-nonconst.c
===
--- /dev/null
+++ clang/test/Profile/misexpect-switch-nonconst.c
@@ -0,0 +1,69 @@
+// Test that misexpect detects mis-annotated switch statements
+
+// RUN: 

[PATCH] D65483: [clang-doc] Add link to source code in file definitions

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added a comment.

It'll be reasonable to mention new command-line arguments in documentation and 
Release Notes.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65483/new/

https://reviews.llvm.org/D65483



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

[PATCH] D65493: Modernize atomic detection and usage

[JF Bastien via Phabricator via cfe-commits]

jfb updated this revision to Diff 212479.
jfb added a comment.

- Remove from cmake


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65493/new/

https://reviews.llvm.org/D65493

Files:
  clang-tools-extra/clangd/CMakeLists.txt
  lldb/source/Utility/CMakeLists.txt
  llvm/cmake/modules/CheckAtomic.cmake
  llvm/include/llvm/Support/Atomic.h
  llvm/include/llvm/Support/Threading.h
  llvm/lib/Support/Atomic.cpp
  llvm/lib/Support/CMakeLists.txt
  llvm/lib/Support/Windows/Threading.inc

Index: llvm/lib/Support/Windows/Threading.inc
===
--- llvm/lib/Support/Windows/Threading.inc
+++ llvm/lib/Support/Windows/Threading.inc
@@ -16,11 +16,6 @@
 #include "WindowsSupport.h"
 #include 
 
-// Windows will at times define MemoryFence.
-#ifdef MemoryFence
-#undef MemoryFence
-#endif
-
 namespace {
   struct ThreadInfo {
 void(*func)(void*);
Index: llvm/lib/Support/CMakeLists.txt
===
--- llvm/lib/Support/CMakeLists.txt
+++ llvm/lib/Support/CMakeLists.txt
@@ -165,7 +165,6 @@
   Z3Solver.cpp
 
 # System
-  Atomic.cpp
   DynamicLibrary.cpp
   Errno.cpp
   Host.cpp
Index: llvm/lib/Support/Atomic.cpp
===
--- llvm/lib/Support/Atomic.cpp
+++ /dev/null
@@ -1,59 +0,0 @@
-//===-- Atomic.cpp - Atomic Operations --*- 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
-//
-//===--===//
-//
-//  This file implements atomic operations.
-//
-//===--===//
-
-#include "llvm/Support/Atomic.h"
-#include "llvm/Config/llvm-config.h"
-
-using namespace llvm;
-
-#if defined(_MSC_VER)
-#include 
-
-// We must include windows.h after intrin.h.
-#include 
-#undef MemoryFence
-#endif
-
-#if defined(__GNUC__) || (defined(__IBMCPP__) && __IBMCPP__ >= 1210)
-#define GNU_ATOMICS
-#endif
-
-void sys::MemoryFence() {
-#if LLVM_HAS_ATOMICS == 0
-  return;
-#else
-#  if defined(GNU_ATOMICS)
-  __sync_synchronize();
-#  elif defined(_MSC_VER)
-  MemoryBarrier();
-#  else
-# error No memory fence implementation for your platform!
-#  endif
-#endif
-}
-
-sys::cas_flag sys::CompareAndSwap(volatile sys::cas_flag* ptr,
-  sys::cas_flag new_value,
-  sys::cas_flag old_value) {
-#if LLVM_HAS_ATOMICS == 0
-  sys::cas_flag result = *ptr;
-  if (result == old_value)
-*ptr = new_value;
-  return result;
-#elif defined(GNU_ATOMICS)
-  return __sync_val_compare_and_swap(ptr, old_value, new_value);
-#elif defined(_MSC_VER)
-  return InterlockedCompareExchange(ptr, new_value, old_value);
-#else
-#  error No compare-and-swap implementation for your platform!
-#endif
-}
Index: llvm/include/llvm/Support/Threading.h
===
--- llvm/include/llvm/Support/Threading.h
+++ llvm/include/llvm/Support/Threading.h
@@ -17,6 +17,7 @@
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/Config/llvm-config.h" // for LLVM_ON_UNIX
 #include "llvm/Support/Compiler.h"
+#include 
 #include  // So we can check the C++ standard lib macros.
 #include 
 
@@ -41,8 +42,6 @@
 
 #if LLVM_THREADING_USE_STD_CALL_ONCE
 #include 
-#else
-#include "llvm/Support/Atomic.h"
 #endif
 
 namespace llvm {
@@ -69,7 +68,7 @@
 
 #if LLVM_THREADING_USE_STD_CALL_ONCE
 
-  typedef std::once_flag once_flag;
+  using once_flag = std::once_flag;
 
 #else
 
@@ -81,7 +80,7 @@
   /// This structure must be used as an opaque object. It is a struct to force
   /// autoinitialization and behave like std::once_flag.
   struct once_flag {
-volatile sys::cas_flag status = Uninitialized;
+std::atomic status = ATOMIC_VAR_INIT(Uninitialized);
   };
 
 #endif
@@ -104,23 +103,22 @@
 std::call_once(flag, std::forward(F),
std::forward(ArgList)...);
 #else
-// For other platforms we use a generic (if brittle) version based on our
-// atomics.
-sys::cas_flag old_val = sys::CompareAndSwap(, Wait, Uninitialized);
-if (old_val == Uninitialized) {
+InitStatus Expect = Uninitialized;
+bool Success = flag.status.compare_exchange_strong(Expect, Wait);
+if (Success) {
   std::forward(F)(std::forward(ArgList)...);
-  sys::MemoryFence();
+  std::atomic_thread_fence(std::memory_order_seq_cst);
   TsanIgnoreWritesBegin();
   TsanHappensBefore();
   flag.status = Done;
   TsanIgnoreWritesEnd();
 } else {
   // Wait until any thread doing the call has finished.
-  sys::cas_flag tmp = flag.status;
-  sys::MemoryFence();
+  InitStatus tmp = flag.status;
+  

[PATCH] D65493: Modernize atomic detection and usage

[JF Bastien via Phabricator via cfe-commits]

jfb created this revision.
jfb added reviewers: rnk, Bigcheese, __simt__.
Herald added subscribers: llvm-commits, lldb-commits, cfe-commits, kadircet, 
arphaman, dexonsmith, jkorous, hiraditya, mgorny.
Herald added projects: clang, LLDB, LLVM.

Some of the cmake checks are obsolete and make bootstrapping an LLVM build 
painful: we only need to check for libatomic which we can do in pure C, no need 
for C++ . That leads us to Atomic.h which we can get rid of.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65493

Files:
  clang-tools-extra/clangd/CMakeLists.txt
  lldb/source/Utility/CMakeLists.txt
  llvm/cmake/modules/CheckAtomic.cmake
  llvm/include/llvm/Support/Atomic.h
  llvm/include/llvm/Support/Threading.h
  llvm/lib/Support/Atomic.cpp
  llvm/lib/Support/Windows/Threading.inc

Index: llvm/lib/Support/Windows/Threading.inc
===
--- llvm/lib/Support/Windows/Threading.inc
+++ llvm/lib/Support/Windows/Threading.inc
@@ -16,11 +16,6 @@
 #include "WindowsSupport.h"
 #include 
 
-// Windows will at times define MemoryFence.
-#ifdef MemoryFence
-#undef MemoryFence
-#endif
-
 namespace {
   struct ThreadInfo {
 void(*func)(void*);
Index: llvm/lib/Support/Atomic.cpp
===
--- llvm/lib/Support/Atomic.cpp
+++ /dev/null
@@ -1,59 +0,0 @@
-//===-- Atomic.cpp - Atomic Operations --*- 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
-//
-//===--===//
-//
-//  This file implements atomic operations.
-//
-//===--===//
-
-#include "llvm/Support/Atomic.h"
-#include "llvm/Config/llvm-config.h"
-
-using namespace llvm;
-
-#if defined(_MSC_VER)
-#include 
-
-// We must include windows.h after intrin.h.
-#include 
-#undef MemoryFence
-#endif
-
-#if defined(__GNUC__) || (defined(__IBMCPP__) && __IBMCPP__ >= 1210)
-#define GNU_ATOMICS
-#endif
-
-void sys::MemoryFence() {
-#if LLVM_HAS_ATOMICS == 0
-  return;
-#else
-#  if defined(GNU_ATOMICS)
-  __sync_synchronize();
-#  elif defined(_MSC_VER)
-  MemoryBarrier();
-#  else
-# error No memory fence implementation for your platform!
-#  endif
-#endif
-}
-
-sys::cas_flag sys::CompareAndSwap(volatile sys::cas_flag* ptr,
-  sys::cas_flag new_value,
-  sys::cas_flag old_value) {
-#if LLVM_HAS_ATOMICS == 0
-  sys::cas_flag result = *ptr;
-  if (result == old_value)
-*ptr = new_value;
-  return result;
-#elif defined(GNU_ATOMICS)
-  return __sync_val_compare_and_swap(ptr, old_value, new_value);
-#elif defined(_MSC_VER)
-  return InterlockedCompareExchange(ptr, new_value, old_value);
-#else
-#  error No compare-and-swap implementation for your platform!
-#endif
-}
Index: llvm/include/llvm/Support/Threading.h
===
--- llvm/include/llvm/Support/Threading.h
+++ llvm/include/llvm/Support/Threading.h
@@ -17,6 +17,7 @@
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/Config/llvm-config.h" // for LLVM_ON_UNIX
 #include "llvm/Support/Compiler.h"
+#include 
 #include  // So we can check the C++ standard lib macros.
 #include 
 
@@ -41,8 +42,6 @@
 
 #if LLVM_THREADING_USE_STD_CALL_ONCE
 #include 
-#else
-#include "llvm/Support/Atomic.h"
 #endif
 
 namespace llvm {
@@ -69,7 +68,7 @@
 
 #if LLVM_THREADING_USE_STD_CALL_ONCE
 
-  typedef std::once_flag once_flag;
+  using once_flag = std::once_flag;
 
 #else
 
@@ -81,7 +80,7 @@
   /// This structure must be used as an opaque object. It is a struct to force
   /// autoinitialization and behave like std::once_flag.
   struct once_flag {
-volatile sys::cas_flag status = Uninitialized;
+std::atomic status = ATOMIC_VAR_INIT(Uninitialized);
   };
 
 #endif
@@ -104,23 +103,22 @@
 std::call_once(flag, std::forward(F),
std::forward(ArgList)...);
 #else
-// For other platforms we use a generic (if brittle) version based on our
-// atomics.
-sys::cas_flag old_val = sys::CompareAndSwap(, Wait, Uninitialized);
-if (old_val == Uninitialized) {
+InitStatus Expect = Uninitialized;
+bool Success = flag.status.compare_exchange_strong(Expect, Wait);
+if (Success) {
   std::forward(F)(std::forward(ArgList)...);
-  sys::MemoryFence();
+  std::atomic_thread_fence(std::memory_order_seq_cst);
   TsanIgnoreWritesBegin();
   TsanHappensBefore();
   flag.status = Done;
   TsanIgnoreWritesEnd();
 } else {
   // Wait until any thread doing the call has finished.
-  sys::cas_flag tmp = flag.status;
-  sys::MemoryFence();
+  InitStatus tmp = flag.status;
+  

r367371 - NFCI, optimize layout of FileEntry

[Alex Lorenz via cfe-commits]

Author: arphaman
Date: Tue Jul 30 17:12:00 2019
New Revision: 367371

URL: http://llvm.org/viewvc/llvm-project?rev=367371=rev
Log:
NFCI, optimize layout of FileEntry

The reordering of the UID field makes the size of a
FileEntry 8 bytes smaller on 64bit platforms.

Modified:
cfe/trunk/include/clang/Basic/FileManager.h

Modified: cfe/trunk/include/clang/Basic/FileManager.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/FileManager.h?rev=367371=367370=367371=diff
==
--- cfe/trunk/include/clang/Basic/FileManager.h (original)
+++ cfe/trunk/include/clang/Basic/FileManager.h Tue Jul 30 17:12:00 2019
@@ -64,8 +64,8 @@ class FileEntry {
   off_t Size; // File size in bytes.
   time_t ModTime; // Modification time of file.
   const DirectoryEntry *Dir;  // Directory file lives in.
-  unsigned UID;   // A unique (small) ID for the file.
   llvm::sys::fs::UniqueID UniqueID;
+  unsigned UID;   // A unique (small) ID for the file.
   bool IsNamedPipe;
   bool IsValid;   // Is this \c FileEntry initialized and valid?
 


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

[PATCH] D65022: [Sema] Always instantiate the initializer of a variable template with undeduced type (8.0 regression)

[Erik Pilkington via Phabricator via cfe-commits]

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

Rebase on top of r367367.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65022/new/

https://reviews.llvm.org/D65022

Files:
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprMember.cpp
  clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp


Index: clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
===
--- clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
+++ clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
@@ -424,3 +424,34 @@
 }
 }
 #endif
+
+#ifndef PRECXX11
+namespace auto_variable_instantiate_initializer {
+template  struct S {
+  template  static constexpr auto v = 1;
+  template  static constexpr auto v2 = T{};
+
+  template >
+  void implicit() {
+double d = v2;
+int i2 = v;
+  }
+
+  void implicit_nondep() {
+int i = v;
+double d = v2;
+  }
+};
+
+void useit() {
+  S x;
+  // We used to fail to instantiate the initializer, leading to an auto type
+  // leaking through here.
+  int i = x.v;
+  float j = x.v2;
+
+  x.implicit();
+  x.implicit_nondep();
+}
+}
+ #endif
Index: clang/lib/Sema/SemaExprMember.cpp
===
--- clang/lib/Sema/SemaExprMember.cpp
+++ clang/lib/Sema/SemaExprMember.cpp
@@ -1160,11 +1160,17 @@
   }
   if (VarTemplateDecl *VarTempl = dyn_cast(MemberDecl)) {
 if (VarDecl *Var = getVarTemplateSpecialization(
-VarTempl, TemplateArgs, MemberNameInfo, TemplateKWLoc))
-  return BuildMemberExpr(
+VarTempl, TemplateArgs, MemberNameInfo, TemplateKWLoc)) {
+  MemberExpr *ME = BuildMemberExpr(
   BaseExpr, IsArrow, OpLoc, , TemplateKWLoc, Var, FoundDecl,
   /*HadMultipleCandidates=*/false, MemberNameInfo,
   Var->getType().getNonReferenceType(), VK_LValue, OK_Ordinary);
+
+  // BuildMemberExpr may have deduced an auto variable's type. Patch back
+  // that type to avoid forming an expression with undeduced type.
+  ME->setType(Var->getType().getNonReferenceType());
+  return ME;
+}
 return ExprError();
   }
 
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -3163,9 +3163,15 @@
   break;
 }
 
-return BuildDeclRefExpr(VD, type, valueKind, NameInfo, , FoundD,
-/*FIXME: TemplateKWLoc*/ SourceLocation(),
-TemplateArgs);
+DeclRefExpr *DRE = BuildDeclRefExpr(
+VD, type, valueKind, NameInfo, , FoundD,
+/*FIXME: TemplateKWLoc*/ SourceLocation(), TemplateArgs);
+
+// BuildDeclRefExpr may have deduced an auto variable's type. Patch back
+// that type to avoid forming an expression with undeduced type.
+if (isa(VD))
+  DRE->setType(VD->getType().getNonReferenceType());
+return DRE;
   }
 }
 


Index: clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
===
--- clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
+++ clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
@@ -424,3 +424,34 @@
 }
 }
 #endif
+
+#ifndef PRECXX11
+namespace auto_variable_instantiate_initializer {
+template  struct S {
+  template  static constexpr auto v = 1;
+  template  static constexpr auto v2 = T{};
+
+  template >
+  void implicit() {
+double d = v2;
+int i2 = v;
+  }
+
+  void implicit_nondep() {
+int i = v;
+double d = v2;
+  }
+};
+
+void useit() {
+  S x;
+  // We used to fail to instantiate the initializer, leading to an auto type
+  // leaking through here.
+  int i = x.v;
+  float j = x.v2;
+
+  x.implicit();
+  x.implicit_nondep();
+}
+}
+ #endif
Index: clang/lib/Sema/SemaExprMember.cpp
===
--- clang/lib/Sema/SemaExprMember.cpp
+++ clang/lib/Sema/SemaExprMember.cpp
@@ -1160,11 +1160,17 @@
   }
   if (VarTemplateDecl *VarTempl = dyn_cast(MemberDecl)) {
 if (VarDecl *Var = getVarTemplateSpecialization(
-VarTempl, TemplateArgs, MemberNameInfo, TemplateKWLoc))
-  return BuildMemberExpr(
+VarTempl, TemplateArgs, MemberNameInfo, TemplateKWLoc)) {
+  MemberExpr *ME = BuildMemberExpr(
   BaseExpr, IsArrow, OpLoc, , TemplateKWLoc, Var, FoundDecl,
   /*HadMultipleCandidates=*/false, MemberNameInfo,
   Var->getType().getNonReferenceType(), VK_LValue, OK_Ordinary);
+
+  // BuildMemberExpr may have deduced an auto variable's type. Patch back
+  // that type to avoid forming an expression with undeduced type.
+  ME->setType(Var->getType().getNonReferenceType());
+  return ME;
+}
 return ExprError();
   }
 
Index: clang/lib/Sema/SemaExpr.cpp
===
--- 

[PATCH] D65359: [Sema] Map from a variable template specialization in a pattern to a variable template specialization in an instantiation properly

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367367: [Sema] Actually map a variable template 
specialization from pattern to… (authored by epilk, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65359?vs=212027=212468#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65359/new/

https://reviews.llvm.org/D65359

Files:
  cfe/trunk/include/clang/Sema/Sema.h
  cfe/trunk/lib/Sema/SemaExprMember.cpp
  cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
  cfe/trunk/test/SemaCXX/cxx1y-variable-templates_in_class.cpp

Index: cfe/trunk/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
===
--- cfe/trunk/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
+++ cfe/trunk/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
@@ -395,3 +395,32 @@
   }
   int  = B::template n; // expected-error {{use of variable template 'n' requires template arguments}}
 }
+
+#ifndef PRECXX11
+namespace template_vars_in_template {
+template  struct TakesInt {};
+
+template 
+struct S {
+  template 
+  static constexpr int v = 42;
+
+  template 
+  void mf() {
+constexpr int val = v;
+  }
+
+  void mf2() {
+constexpr int val = v;
+TakesInt ti;
+(void)ti.x; // expected-error{{no member named 'x' in 'template_vars_in_template::TakesInt<42>'}}
+  }
+};
+
+void useit() {
+  S x;
+  x.mf();
+  x.mf2(); // expected-note{{in instantiation of member function 'template_vars_in_template::S::mf2' requested here}}
+}
+}
+#endif
Index: cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -5217,11 +5217,11 @@
 /// template struct X;
 /// \endcode
 ///
-/// In the instantiation of X::getKind(), we need to map the
-/// \p EnumConstantDecl for \p KnownValue (which refers to
-/// XKnownValue) to its instantiation
-/// (XKnownValue). \p FindInstantiatedDecl performs
-/// this mapping from within the instantiation of X.
+/// In the instantiation of X::getKind(), we need to map the \p
+/// EnumConstantDecl for \p KnownValue (which refers to
+/// XKnownValue) to its instantiation (XKnownValue).
+/// \p FindInstantiatedDecl performs this mapping from within the instantiation
+/// of X.
 NamedDecl *Sema::FindInstantiatedDecl(SourceLocation Loc, NamedDecl *D,
   const MultiLevelTemplateArgumentList ,
   bool FindingInstantiatedContext) {
@@ -5312,20 +5312,6 @@
 return cast(Inst);
   }
 
-  // For variable template specializations, update those that are still
-  // type-dependent.
-  if (VarTemplateSpecializationDecl *VarSpec =
-  dyn_cast(D)) {
-bool InstantiationDependent = false;
-const TemplateArgumentListInfo  =
-VarSpec->getTemplateArgsInfo();
-if (TemplateSpecializationType::anyDependentTemplateArguments(
-VarTemplateArgs, InstantiationDependent))
-  D = cast(
-  SubstDecl(D, VarSpec->getDeclContext(), TemplateArgs));
-return D;
-  }
-
   if (CXXRecordDecl *Record = dyn_cast(D)) {
 if (!Record->isDependentContext())
   return D;
@@ -5450,11 +5436,23 @@
 // find it. Does that ever matter?
 if (auto Name = D->getDeclName()) {
   DeclarationNameInfo NameInfo(Name, D->getLocation());
-  Name = SubstDeclarationNameInfo(NameInfo, TemplateArgs).getName();
+  DeclarationNameInfo NewNameInfo =
+  SubstDeclarationNameInfo(NameInfo, TemplateArgs);
+  Name = NewNameInfo.getName();
   if (!Name)
 return nullptr;
   DeclContext::lookup_result Found = ParentDC->lookup(Name);
-  Result = findInstantiationOf(Context, D, Found.begin(), Found.end());
+
+  if (auto *VTSD = dyn_cast(D)) {
+VarTemplateDecl *Templ = cast_or_null(
+findInstantiationOf(Context, VTSD->getSpecializedTemplate(),
+Found.begin(), Found.end()));
+if (!Templ)
+  return nullptr;
+Result = getVarTemplateSpecialization(
+Templ, >getTemplateArgsInfo(), NewNameInfo, SourceLocation());
+  } else
+Result = findInstantiationOf(Context, D, Found.begin(), Found.end());
 } else {
   // Since we don't have a name for the entity we're looking for,
   // our only option is to walk through all of the declarations to
Index: cfe/trunk/lib/Sema/SemaExprMember.cpp
===
--- cfe/trunk/lib/Sema/SemaExprMember.cpp
+++ cfe/trunk/lib/Sema/SemaExprMember.cpp
@@ -934,19 +934,19 @@
   return false;
 }
 
-static VarDecl *
-getVarTemplateSpecialization(Sema , VarTemplateDecl *VarTempl,
+VarDecl *
+Sema::getVarTemplateSpecialization(VarTemplateDecl *VarTempl,
 

r367367 - [Sema] Actually map a variable template specialization from pattern to instantiation

[Erik Pilkington via cfe-commits]

Author: epilk
Date: Tue Jul 30 16:38:18 2019
New Revision: 367367

URL: http://llvm.org/viewvc/llvm-project?rev=367367=rev
Log:
[Sema] Actually map a variable template specialization from pattern to 
instantiation

We were previously just using a specialization in the class template instead of
creating a new specialization in the class instantiation.

Fixes llvm.org/PR42779.

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

Modified:
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaExprMember.cpp
cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
cfe/trunk/test/SemaCXX/cxx1y-variable-templates_in_class.cpp

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=367367=367366=367367=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Tue Jul 30 16:38:18 2019
@@ -8191,6 +8191,11 @@ public:
  LocalInstantiationScope *StartingScope,
  bool InstantiatingVarTemplate = false,
  VarTemplateSpecializationDecl *PrevVTSD = 
nullptr);
+
+  VarDecl *getVarTemplateSpecialization(
+  VarTemplateDecl *VarTempl, const TemplateArgumentListInfo *TemplateArgs,
+  const DeclarationNameInfo , SourceLocation TemplateKWLoc);
+
   void InstantiateVariableInitializer(
   VarDecl *Var, VarDecl *OldVar,
   const MultiLevelTemplateArgumentList );

Modified: cfe/trunk/lib/Sema/SemaExprMember.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExprMember.cpp?rev=367367=367366=367367=diff
==
--- cfe/trunk/lib/Sema/SemaExprMember.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExprMember.cpp Tue Jul 30 16:38:18 2019
@@ -934,19 +934,19 @@ static bool IsInFnTryBlockHandler(const
   return false;
 }
 
-static VarDecl *
-getVarTemplateSpecialization(Sema , VarTemplateDecl *VarTempl,
+VarDecl *
+Sema::getVarTemplateSpecialization(VarTemplateDecl *VarTempl,
   const TemplateArgumentListInfo *TemplateArgs,
   const DeclarationNameInfo ,
   SourceLocation TemplateKWLoc) {
   if (!TemplateArgs) {
-S.diagnoseMissingTemplateArguments(TemplateName(VarTempl),
-   MemberNameInfo.getBeginLoc());
+diagnoseMissingTemplateArguments(TemplateName(VarTempl),
+ MemberNameInfo.getBeginLoc());
 return nullptr;
   }
 
-  DeclResult VDecl = S.CheckVarTemplateId(
-  VarTempl, TemplateKWLoc, MemberNameInfo.getLoc(), *TemplateArgs);
+  DeclResult VDecl = CheckVarTemplateId(VarTempl, TemplateKWLoc,
+MemberNameInfo.getLoc(), 
*TemplateArgs);
   if (VDecl.isInvalid())
 return nullptr;
   VarDecl *Var = cast(VDecl.get());
@@ -1095,7 +1095,7 @@ Sema::BuildMemberReferenceExpr(Expr *Bas
  "How did we get template arguments here sans a variable 
template");
   if (isa(MemberDecl)) {
 MemberDecl = getVarTemplateSpecialization(
-*this, cast(MemberDecl), TemplateArgs,
+cast(MemberDecl), TemplateArgs,
 R.getLookupNameInfo(), TemplateKWLoc);
 if (!MemberDecl)
   return ExprError();
@@ -1160,7 +1160,7 @@ Sema::BuildMemberReferenceExpr(Expr *Bas
   }
   if (VarTemplateDecl *VarTempl = dyn_cast(MemberDecl)) {
 if (VarDecl *Var = getVarTemplateSpecialization(
-*this, VarTempl, TemplateArgs, MemberNameInfo, TemplateKWLoc))
+VarTempl, TemplateArgs, MemberNameInfo, TemplateKWLoc))
   return BuildMemberExpr(
   BaseExpr, IsArrow, OpLoc, , TemplateKWLoc, Var, FoundDecl,
   /*HadMultipleCandidates=*/false, MemberNameInfo,

Modified: cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp?rev=367367=367366=367367=diff
==
--- cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp Tue Jul 30 16:38:18 2019
@@ -5217,11 +5217,11 @@ DeclContext *Sema::FindInstantiatedConte
 /// template struct X;
 /// \endcode
 ///
-/// In the instantiation of X::getKind(), we need to map the
-/// \p EnumConstantDecl for \p KnownValue (which refers to
-/// XKnownValue) to its instantiation
-/// (XKnownValue). \p FindInstantiatedDecl performs
-/// this mapping from within the instantiation of X.
+/// In the instantiation of X::getKind(), we need to map the \p
+/// EnumConstantDecl for \p KnownValue (which refers to
+/// XKnownValue) to its instantiation 
(XKnownValue).
+/// \p FindInstantiatedDecl performs this mapping from within the instantiation
+/// of 

[PATCH] D65486: [clangd] Ignore semicolons, whitespace, and comments in SelectionTree.

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

It occurs to me that `claim` is `O(node_tokens + log total_tokens)` which is 
bad when the nodes are large.

Indeed for an input like `namespace { namespace { namespace { ... } } }` time 
is quadratic.

I think this is probably fine in practice. Against adversarial input clang 
certainly can take exponential time, and easily crash too.

If we do need to fix it my best idea is to give each "uninteresting" TokInfo 
(that is, !selected || claimed) a pointer to the next TokInfo with different 
flags. This would allow iteration to quickly skip over contiguous ranges one 
they had been traversed once.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65486/new/

https://reviews.llvm.org/D65486



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

[PATCH] D65485: Revert "[NFC][clang] Refactor getCompilationPhases()+Types.def step 3."

[Sam McCall via Phabricator via cfe-commits]

sammccall abandoned this revision.
sammccall added a comment.

Please ignore this, I messed up with git/arc


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65485/new/

https://reviews.llvm.org/D65485



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

[PATCH] D65487: [analyzer][NFC] Refactoring BugReporter.cpp P6.: Completely get rid of interestingness propagation

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus created this revision.
Szelethus added reviewers: NoQ, xazax.hun, rnkovacs, baloghadamsoftware, 
Charusso, dcoughlin.
Szelethus added a project: clang.
Herald added subscribers: cfe-commits, gamesh411, dkrupp, donat.nagy, 
mikhail.ramalho, a.sidorin, szepet, whisperity.

Do you remember the teaser in D65378 ?

When you think about this, it makes sense. If something is really important, 
we're tracking it anyways, and that system is sophisticated enough to mark 
actually interesting statements as such. I wouldn't say that it's even 
//likely// that subexpressions are also interesting (`array[10 - x + x]`), so I 
guess even if this produced any effects, its probably undesirable.

---

I originally started working on this refactoring effort to dig from the point 
where diagnostics construction starts, down to this part of the code. Turns out 
it doesn't do anything. In fact, after the analysis ends, only visitors may 
mark objects as interesting (which has any actual effect), which is AMAZING to 
know, because `ConditionBRVisitor` only has interestiness to work with when it 
constructs a diagnostics piece.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65487

Files:
  clang/lib/StaticAnalyzer/Core/BugReporter.cpp

Index: clang/lib/StaticAnalyzer/Core/BugReporter.cpp
===
--- clang/lib/StaticAnalyzer/Core/BugReporter.cpp
+++ clang/lib/StaticAnalyzer/Core/BugReporter.cpp
@@ -98,8 +98,6 @@
 using VisitorsDiagnosticsTy =
 llvm::DenseMap>;
 
-using InterestingExprs = llvm::DenseSet;
-
 /// A map from PathDiagnosticPiece to the LocationContext of the inlined
 /// function call it represents.
 using LocationContextMap =
@@ -125,7 +123,6 @@
   /// TODO: PathDiagnostic has a stack doing the same thing, shouldn't we use
   /// that instead?
   StackDiagVector CallStack;
-  InterestingExprs IE;
   /// The bug report we're constructing. For ease of use, this field is kept
   /// public, though some "shortcut" getters are provided for commonly used
   /// methods of PathDiagnostic.
@@ -942,74 +939,6 @@
   }
 }
 
-// Cone-of-influence: support the reverse propagation of "interesting" symbols
-// and values by tracing interesting calculations backwards through evaluated
-// expressions along a path.  This is probably overly complicated, but the idea
-// is that if an expression computed an "interesting" value, the child
-// expressions are also likely to be "interesting" as well (which then
-// propagates to the values they in turn compute).  This reverse propagation
-// is needed to track interesting correlations across function call boundaries,
-// where formal arguments bind to actual arguments, etc.  This is also needed
-// because the constraint solver sometimes simplifies certain symbolic values
-// into constants when appropriate, and this complicates reasoning about
-// interesting values.
-
-static void reversePropagateIntererstingSymbols(BugReport ,
-InterestingExprs ,
-const ProgramState *State,
-const Expr *Ex,
-const LocationContext *LCtx) {
-  SVal V = State->getSVal(Ex, LCtx);
-  if (!(R.isInteresting(V) || IE.count(Ex)))
-return;
-
-  switch (Ex->getStmtClass()) {
-default:
-  if (!isa(Ex))
-break;
-  LLVM_FALLTHROUGH;
-case Stmt::BinaryOperatorClass:
-case Stmt::UnaryOperatorClass: {
-  for (const Stmt *SubStmt : Ex->children()) {
-if (const auto *child = dyn_cast_or_null(SubStmt)) {
-  IE.insert(child);
-  SVal ChildV = State->getSVal(child, LCtx);
-  R.markInteresting(ChildV);
-}
-  }
-  break;
-}
-  }
-
-  R.markInteresting(V);
-}
-
-static void reversePropagateInterestingSymbols(BugReport ,
-   InterestingExprs ,
-   const ProgramState *State,
-   const LocationContext *CalleeCtx)
-{
-  // FIXME: Handle non-CallExpr-based CallEvents.
-  const StackFrameContext *Callee = CalleeCtx->getStackFrame();
-  const Stmt *CallSite = Callee->getCallSite();
-  if (const auto *CE = dyn_cast_or_null(CallSite)) {
-if (const auto *FD = dyn_cast(CalleeCtx->getDecl())) {
-  FunctionDecl::param_const_iterator PI = FD->param_begin(),
- PE = FD->param_end();
-  CallExpr::const_arg_iterator AI = CE->arg_begin(), AE = CE->arg_end();
-  for (; AI != AE && PI != PE; ++AI, ++PI) {
-if (const Expr *ArgE = *AI) {
-  if (const ParmVarDecl *PD = *PI) {
-Loc LV = State->getLValue(PD, CalleeCtx);
-if (R.isInteresting(LV) || R.isInteresting(State->getRawSVal(LV)))
-  IE.insert(ArgE);
-  }

[PATCH] D65486: [clangd] Ignore semicolons, whitespace, and comments in SelectionTree.

[Sam McCall via Phabricator via cfe-commits]

sammccall created this revision.
sammccall added reviewers: SureYeaah, kadircet.
Herald added subscribers: cfe-commits, arphaman, jkorous, MaskRay.
Herald added a project: clang.

Whitespace and comments are a clear bugfix: selecting some
comments/space near a statement doesn't mean you're selecting the
surrounding block.

Semicolons are less obvious, but for similar reasons: these tokens
aren't actually claimed by any AST node (usually), so an AST-based model
like SelectionTree shouldn't take them into account.

Callers may still sometimes care about semis of course:

- when the selection is an expr with a non-expr parent, selection of the 
semicolon indicates intent to select the statement.
- when a statement with a trailing semi is selected, we need to know its range 
to ensure it can be removed.

SelectionTree may or may not play a role here, but these are separate questions
from its core function of describing which AST nodes were selected.

The mechanism here is the TokenBuffer from syntax-trees. We use it in a
fairly low-level way (just to get boundaries of raw spelled tokens). The
actual mapping of AST nodes to coordinates continues to use the (fairly
mature) SourceLocation based logic. TokenBuffer/Syntax trees
don't currently offer an alternative to getFileRange(), I think.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65486

Files:
  clang-tools-extra/clangd/Selection.cpp
  clang-tools-extra/clangd/Selection.h
  clang-tools-extra/clangd/refactor/Tweak.cpp
  clang-tools-extra/clangd/unittests/SelectionTests.cpp

Index: clang-tools-extra/clangd/unittests/SelectionTests.cpp
===
--- clang-tools-extra/clangd/unittests/SelectionTests.cpp
+++ clang-tools-extra/clangd/unittests/SelectionTests.cpp
@@ -23,16 +23,16 @@
   Annotations Test(MarkedCode);
   switch (Test.points().size()) {
   case 1: // Point selection.
-return SelectionTree(AST.getASTContext(),
+return SelectionTree(AST.getASTContext(), AST.getTokens(),
  cantFail(positionToOffset(Test.code(), Test.point(;
   case 2: // Range selection.
 return SelectionTree(
-AST.getASTContext(),
+AST.getASTContext(), AST.getTokens(),
 cantFail(positionToOffset(Test.code(), Test.points()[0])),
 cantFail(positionToOffset(Test.code(), Test.points()[1])));
   default:
 ADD_FAILURE() << "Expected 1-2 points for selection.\n" << MarkedCode;
-return SelectionTree(AST.getASTContext(), 0u, 0u);
+return SelectionTree(AST.getASTContext(), AST.getTokens(), 0u, 0u);
   }
 }
 
@@ -219,6 +219,9 @@
   {"void foo() { [[foo^]] (); }", "DeclRefExpr"},
   {"int bar; void foo() [[{ foo (); }]]^", "CompoundStmt"},
 
+  // Ignores whitespace, comments, and semicolons in the selection.
+  {"void foo() { [[foo^()]]; /*comment*/^}", "CallExpr"},
+
   // Tricky case: FunctionTypeLoc in FunctionDecl has a hole in it.
   {"[[^void]] foo();", "BuiltinTypeLoc"},
   {"[[void foo^()]];", "FunctionProtoTypeLoc"},
Index: clang-tools-extra/clangd/refactor/Tweak.cpp
===
--- clang-tools-extra/clangd/refactor/Tweak.cpp
+++ clang-tools-extra/clangd/refactor/Tweak.cpp
@@ -41,7 +41,7 @@
 Tweak::Selection::Selection(ParsedAST , unsigned RangeBegin,
 unsigned RangeEnd)
 : AST(AST), SelectionBegin(RangeBegin), SelectionEnd(RangeEnd),
-  ASTSelection(AST.getASTContext(), RangeBegin, RangeEnd) {
+  ASTSelection(AST.getASTContext(), AST.getTokens(), RangeBegin, RangeEnd) {
   auto  = AST.getSourceManager();
   Code = SM.getBufferData(SM.getMainFileID());
   Cursor = SM.getComposedLoc(SM.getMainFileID(), RangeBegin);
Index: clang-tools-extra/clangd/Selection.h
===
--- clang-tools-extra/clangd/Selection.h
+++ clang-tools-extra/clangd/Selection.h
@@ -35,6 +35,7 @@
 #define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SELECTION_H
 #include "clang/AST/ASTTypeTraits.h"
 #include "clang/AST/PrettyPrinter.h"
+#include "clang/Tooling/Syntax/Tokens.h"
 #include "llvm/ADT/SmallVector.h"
 
 namespace clang {
@@ -56,8 +57,9 @@
 //
 // SelectionTree tries to behave sensibly in the presence of macros, but does
 // not model any preprocessor concepts: the output is a subset of the AST.
-// Currently comments, directives etc are treated as part of the lexically
-// containing AST node, (though we may want to change this in future).
+//
+// Comments, directives and whitespace are completely ignored.
+// Semicolons are also ignored, as the AST generally does not model them well.
 //
 // The SelectionTree owns the Node structures, but the ASTNode attributes
 // point back into the AST it was constructed with.
@@ -66,11 +68,13 @@
   // Creates a selection tree at the given byte offset in the main file.
   // This is approximately equivalent to a range of one character.
   // 

[PATCH] D65485: Revert "[NFC][clang] Refactor getCompilationPhases()+Types.def step 3."

[Sam McCall via Phabricator via cfe-commits]

sammccall created this revision.
Herald added subscribers: cfe-commits, kadircet, arphaman, jkorous.
Herald added a project: clang.

This reverts commit d2254dbf21a3243233b75294ef901086199df1b9 
.
This (unintentionally?) changed behavior, disallowing e.g. -x 
objective-c++-header


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65485

Files:
  clang-tools-extra/clangd/Selection.cpp
  clang-tools-extra/clangd/Selection.h
  clang-tools-extra/clangd/refactor/Tweak.cpp
  clang-tools-extra/clangd/unittests/SelectionTests.cpp
  clang/include/clang/Driver/Types.def
  clang/include/clang/Driver/Types.h
  clang/lib/Driver/Types.cpp

Index: clang/lib/Driver/Types.cpp
===
--- clang/lib/Driver/Types.cpp
+++ clang/lib/Driver/Types.cpp
@@ -18,14 +18,15 @@
 
 struct TypeInfo {
   const char *Name;
+  const char *Flags;
   const char *TempSuffix;
   ID PreprocessedType;
   const llvm::SmallVector Phases;
 };
 
 static const TypeInfo TypeInfos[] = {
-#define TYPE(NAME, ID, PP_TYPE, TEMP_SUFFIX, ...) \
-  { NAME, TEMP_SUFFIX, TY_##PP_TYPE, { __VA_ARGS__ }, },
+#define TYPE(NAME, ID, PP_TYPE, TEMP_SUFFIX, FLAGS, ...) \
+  { NAME, FLAGS, TEMP_SUFFIX, TY_##PP_TYPE, { __VA_ARGS__ }, },
 #include "clang/Driver/Types.def"
 #undef TYPE
 };
@@ -89,15 +90,7 @@
 }
 
 bool types::canTypeBeUserSpecified(ID Id) {
-  static const clang::driver::types::ID kStaticLangageTypes[] = {
-  TY_CUDA_DEVICE,   TY_HIP_DEVICE,TY_PP_CHeader,
-  TY_PP_ObjCHeader, TY_PP_CXXHeader,  TY_ObjCXXHeader,
-  TY_PP_CXXModule,  TY_LTO_IR,TY_LTO_BC,
-  TY_Plist, TY_RewrittenObjC, TY_RewrittenLegacyObjC,
-  TY_Remap, TY_PCH,   TY_Object,
-  TY_Image, TY_dSYM,  TY_Dependencies,
-  TY_CUDA_FATBIN,   TY_HIP_FATBIN};
-  return !llvm::is_contained(kStaticLangageTypes, Id);
+  return strchr(getInfo(Id).Flags, 'u');
 }
 
 bool types::appendSuffixForType(ID Id) {
Index: clang/include/clang/Driver/Types.h
===
--- clang/include/clang/Driver/Types.h
+++ clang/include/clang/Driver/Types.h
@@ -20,7 +20,7 @@
 namespace types {
   enum ID {
 TY_INVALID,
-#define TYPE(NAME, ID, PP_TYPE, TEMP_SUFFIX, ...) TY_##ID,
+#define TYPE(NAME, ID, PP_TYPE, TEMP_SUFFIX, FLAGS, ...) TY_##ID,
 #include "clang/Driver/Types.def"
 #undef TYPE
 TY_LAST
Index: clang/include/clang/Driver/Types.def
===
--- clang/include/clang/Driver/Types.def
+++ clang/include/clang/Driver/Types.def
@@ -29,73 +29,76 @@
 // The fourth value is the suffix to use when creating temporary files
 // of this type, or null if unspecified.
 
-// The final value is a variadic list of phases for each type. Eventually the
+// The fifth value is a string containing option flags. Valid values:
+//  u - The type can be user specified (with -x).
+
+// The sixth value is a variadic list of phases for each type. Eventually the
 // options flag string will be replaced with this variadic list.
 // Most of the options in Flags have been removed in favor of subsuming their
 // meaning from the phases list.
 
 // C family source language (with and without preprocessing).
-TYPE("cpp-output",   PP_C, INVALID, "i",  phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("c",C,PP_C,"c",  phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cl",   CL,   PP_C,"cl", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cuda-cpp-output",  PP_CUDA,  INVALID, "cui",phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cuda", CUDA, PP_CUDA, "cu", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cuda", CUDA_DEVICE,  PP_CUDA, "cu", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("hip-cpp-output",   PP_HIP,   INVALID, "cui",phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("hip",  HIP,  PP_HIP,  "cu", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("hip",  HIP_DEVICE,   PP_HIP,  "cu", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objective-c-cpp-output",   PP_ObjC,  INVALID, "mi", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objc-cpp-output",  PP_ObjC_Alias, INVALID,"mi", phases::Compile, phases::Backend, 

[PATCH] D65484: [analyzer][NFC] Refactoring BugReporter.cpp P5.: Compact mile long function invocations into objects

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus created this revision.
Szelethus added reviewers: NoQ, xazax.hun, baloghadamsoftware, Charusso, 
dcoughlin, rnkovacs.
Szelethus added a project: clang.
Herald added subscribers: cfe-commits, gamesh411, dkrupp, donat.nagy, 
mikhail.ramalho, a.sidorin, szepet, whisperity.

This patch is scary big, I'm aware, but I genuinely didn't find a satisfying 
splitting point. To my defense, its also brain dead refactoring for the most 
part!

---

In D65379 , I briefly described the 
construction of bug paths from an `ExplodedGraph`. This patch is about 
refactoring the code processing the bug path into a bug report.

A part of finding a valid bug report was running all visitors on the bug path, 
so we already have a (possibly empty) set of diagnostics for each 
`ExplodedNode` in it.
Then, for each diagnostic consumer, we construct non-visitor diagnostic pieces.

- We first construct the final diagnostic piece (the warning), then
- We start ascending the bug path from the error node's predecessor (since the 
error node itself was used to construct the warning event). For each node
  - We check the location (whether its a `CallEnter`, `CallExit`) etc. We 
simultaneously keep track of where we are with the execution by pushing 
`CallStack` when we see a `CallExit` (keep in mind that everything is happening 
in reverse!), popping it when we find a `CallEnter`, compacting them into a 
single `PathDiagnosticCallEvent`.

  void f() {
bar();
  }
  
  void g() {
f();
error(); // warning
  }
  
  === The bug path ===
  
  (root) -> f's CallEnter -> bar() -> f's CallExit -> (error node)
  
  
  === Constructed report ===
  
f's CallEnter -> bar() -> f's CallExit
 ^   /
  \ V
  (root) --->  f's CallEvent --> (error node)

  - We also keep track of different `PathPieces` different location contexts 
(`CallEvent::path` in the above example has `f`'s `LocationContext`, while the 
`CallEvent` itself is in `g`'s context) in a `LocationContextMap` object.
  - Construct whatever piece, if any, is needed for the note.
  - If we need to generate edges (or arrows) do so. Make sure to also connect 
these pieces with the ones that visitors emitted.
- Clean up the constructed `PathDiagnostic` by making arrows nicer, pruning 
function calls, etc.

---

So I complained about mile long function invocations with seemingly the same 
parameters being passed around. This problem, as I see it, a natural candidate 
for creating classes and tying them all together.

I tried very hard to make the implementation //feel// natural, like, rolling 
off the tongue. I introduced 2 new classes: `PathDiagnosticBuilder` (I mean, I 
kept the name but changed almost everything in it) contains every contextual 
information (owns the bug path, the diagnostics constructed but the visitors, 
the `BugReport` itself, etc) needed for constructing a `PathDiagnostic` object, 
and is pretty much completely immutable. `BugReportContruct` is the object 
containing every non-contextual information (the `PathDiagnostic` object we're 
constructing, the current location in the bug path, the location context map 
and the call stack I meantioned earlier), and is passed around all over the 
place as a single entity instead of who knows how many parameters.

I tried to used constness, asserts, limiting visibility of fields to my 
advantage to clean up the code big time and dramatically improve safety. Also, 
whenever I found the code difficult to understand, I added comments and/or 
examples.

Here's a complete list of changes and my design philosophy behind it:

- Instead of construcing a `ReportInfo` object (added by D65379 
) after finding a valid bug report, simply 
return an optional `PathDiagnosticBuilder` object straight away. Move 
`findValidReport` into the class as a static method. I find 
`GRBugReporter::generatePathDiagnostics` a joy to look at now.
- Rename `generatePathDiagnosticForConsumer` to `generate` (maybe not needed, 
but felt that way in the moment) and moved it to `PathDiagnosticBuilder`. If we 
don't need to generate diagnostics, bail out straight away, like we always 
should have. After that, construct a `BugReportConstruct` object, leaving the 
rest of the logic untouched.
- Move all static methods that would use contextual information into 
`PathDiagnosticBuilder`, reduce their parameter count drastically by simply 
passing around a `BugReportConstruct` object.
- Glance at the code I removed: Could you tell what the original 
`PathDiagnosticBuilder::LC` object was for? It took a gd long while for me 
to realize that nothing really. It is always equal with the `LocationContext` 
associated with our current position in the bug path. Remove it completely.
- The original code contains the following expression quite a bit: 
`LCM[()]`, so what does it mean? I said that we collect the 
contexts associated with different 

[PATCH] D65483: [clang-format] Add link to source code in file definitions

[Diego Astiazarán via Phabricator via cfe-commits]

DiegoAstiazaran created this revision.
DiegoAstiazaran added reviewers: juliehockett, jakehehrlich, lebedev.ri.
DiegoAstiazaran added a project: clang-tools-extra.
Herald added subscribers: kadircet, arphaman.

Two command line options have been added to clang-doc.

  --repository=   - URL of repository that hosts code; used for 
links to definition locations.
  --root-directory=   - Directory where processed files are stored. 
Links to definition locations will only be generated if the file is in this dir.

If the file is in the root-directory and a repository options is passed; a link 
to the source code will be rendered by the HTML generator.


https://reviews.llvm.org/D65483

Files:
  clang-tools-extra/clang-doc/BitcodeReader.cpp
  clang-tools-extra/clang-doc/BitcodeWriter.cpp
  clang-tools-extra/clang-doc/HTMLGenerator.cpp
  clang-tools-extra/clang-doc/Mapper.cpp
  clang-tools-extra/clang-doc/Mapper.h
  clang-tools-extra/clang-doc/Representation.h
  clang-tools-extra/clang-doc/Serialize.cpp
  clang-tools-extra/clang-doc/Serialize.h
  clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
  clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
  clang-tools-extra/unittests/clang-doc/SerializeTest.cpp

Index: clang-tools-extra/unittests/clang-doc/SerializeTest.cpp
===
--- clang-tools-extra/unittests/clang-doc/SerializeTest.cpp
+++ clang-tools-extra/unittests/clang-doc/SerializeTest.cpp
@@ -37,7 +37,7 @@
 
   template  bool mapDecl(const T *D) {
 auto I = serialize::emitInfo(D, getComment(D), /*Line=*/0,
- /*File=*/"test.cpp", Public);
+ /*File=*/"test.cpp", true, Public);
 if (I.first)
   EmittedInfos.emplace_back(std::move(I.first));
 if (I.second)
Index: clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
===
--- clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
+++ clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
@@ -22,12 +22,14 @@
 }
 
 ClangDocContext
-getClangDocContext(std::vector UserStylesheets = {}) {
+getClangDocContext(std::vector UserStylesheets = {},
+   StringRef RepositoryUrl = "") {
   ClangDocContext CDCtx;
   CDCtx.UserStylesheets = {UserStylesheets.begin(), UserStylesheets.end()};
   CDCtx.UserStylesheets.insert(
   CDCtx.UserStylesheets.begin(),
   "../share/clang/clang-doc-default-stylesheet.css");
+  CDCtx.RepositoryUrl = RepositoryUrl;
   return CDCtx;
 }
 
@@ -87,7 +89,7 @@
   I.Path = "X/Y/Z";
   I.Namespace.emplace_back(EmptySID, "A", InfoType::IT_namespace);
 
-  I.DefLoc = Location(10, llvm::SmallString<16>{"test.cpp"});
+  I.DefLoc = Location(10, llvm::SmallString<16>{"dir/test.cpp"}, true);
   I.Loc.emplace_back(12, llvm::SmallString<16>{"test.cpp"});
 
   SmallString<16> PathTo;
@@ -107,7 +109,7 @@
   assert(G);
   std::string Buffer;
   llvm::raw_string_ostream Actual(Buffer);
-  ClangDocContext CDCtx = getClangDocContext();
+  ClangDocContext CDCtx = getClangDocContext({}, "https://www.repository.com;);
   auto Err = G->generateDocForInfo(, Actual, CDCtx);
   assert(!Err);
   std::string Expected = R"raw(
@@ -116,7 +118,12 @@
 
 
   class r
-  Defined at line 10 of test.cpp
+  
+Defined at line 
+https://www.repository.com/dir/test.cpp#10;>10
+ of file 
+https://www.repository.com/dir/test.cpp;>test.cpp
+  
   
 Inherits from 
 F
@@ -154,7 +161,7 @@
   I.Name = "f";
   I.Namespace.emplace_back(EmptySID, "A", InfoType::IT_namespace);
 
-  I.DefLoc = Location(10, llvm::SmallString<16>{"test.cpp"});
+  I.DefLoc = Location(10, llvm::SmallString<16>{"dir/test.cpp"}, false);
   I.Loc.emplace_back(12, llvm::SmallString<16>{"test.cpp"});
 
   SmallString<16> PathTo;
@@ -168,7 +175,7 @@
   assert(G);
   std::string Buffer;
   llvm::raw_string_ostream Actual(Buffer);
-  ClangDocContext CDCtx = getClangDocContext();
+  ClangDocContext CDCtx = getClangDocContext({}, "https://www.repository.com;);
   auto Err = G->generateDocForInfo(, Actual, CDCtx);
   assert(!Err);
   std::string Expected = R"raw(
@@ -183,7 +190,7 @@
 int
  P)
   
-  Defined at line 10 of test.cpp
+  Defined at line 10 of file dir/test.cpp
 
 )raw";
 
@@ -217,7 +224,7 @@
   
 X
   
-  Defined at line 10 of test.cpp
+  Defined at line 10 of file test.cpp
 
 )raw";
 
@@ -284,7 +291,7 @@
 
   f
   void f(int I, int J)
-  Defined at line 10 of test.cpp
+  Defined at line 10 of file test.cpp
   
 
Brief description.
Index: clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
===
--- clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
+++ clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
@@ -67,6 +67,19 @@
 llvm::cl::desc("CSS stylesheets to extend the default styles."),
 llvm::cl::cat(ClangDocCategory));
 
+static llvm::cl::opt RootDirectory(

[PATCH] D65481: NFCI: Simplify SourceManager::translateFile by removing code path that should never be taken

[Alex Lorenz via Phabricator via cfe-commits]

arphaman created this revision.
arphaman added reviewers: rsmith, bruno, Bigcheese.
Herald added subscribers: dexonsmith, jkorous.
Herald added a project: clang.

I noticed that `SourceManager::translateFile` has code that doesn't really make 
sense. In particular, if it fails to find a `FileID` by comparing `FileEntry *` 
values, it tries to look through files that have the same filename, to see if 
they have a matching inode to try to find the right `FileID`. However, the 
inode comparison seem redundant, as Clang's `FileManager` already deduplicates 
`FileEntry *` values by inode. Thus the comparisons between inodes should never 
actually succeed, and the comparison between `FileEntry *` values should be 
sufficient here.

This observation is supported by the code coverage report that shows that we 
never actually reach the case where the INODE comparison succeeds:
http://lab.llvm.org:8080/coverage/coverage-reports/clang/coverage/Users/buildslave/jenkins/workspace/clang-stage2-coverage-R/llvm/tools/clang/lib/Basic/SourceManager.cpp.html#L1595


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65481

Files:
  clang/lib/Basic/SourceManager.cpp

Index: clang/lib/Basic/SourceManager.cpp
===
--- clang/lib/Basic/SourceManager.cpp
+++ clang/lib/Basic/SourceManager.cpp
@@ -1558,22 +1558,6 @@
 // Other miscellaneous methods.
 //===--===//
 
-/// Retrieve the inode for the given file entry, if possible.
-///
-/// This routine involves a system call, and therefore should only be used
-/// in non-performance-critical code.
-static Optional
-getActualFileUID(const FileEntry *File) {
-  if (!File)
-return None;
-
-  llvm::sys::fs::UniqueID ID;
-  if (llvm::sys::fs::getUniqueID(File->getName(), ID))
-return None;
-
-  return ID;
-}
-
 /// Get the source location for the given file:line:col triplet.
 ///
 /// If the source file is included multiple times, the source location will
@@ -1595,13 +1579,8 @@
 FileID SourceManager::translateFile(const FileEntry *SourceFile) const {
   assert(SourceFile && "Null source file!");
 
-  // Find the first file ID that corresponds to the given file.
-  FileID FirstFID;
-
   // First, check the main file ID, since it is common to look for a
   // location in the main file.
-  Optional SourceFileUID;
-  Optional SourceFileName;
   if (MainFileID.isValid()) {
 bool Invalid = false;
 const SLocEntry  = getSLocEntry(MainFileID, );
@@ -1609,100 +1588,35 @@
   return FileID();
 
 if (MainSLoc.isFile()) {
-  const ContentCache *MainContentCache
-= MainSLoc.getFile().getContentCache();
-  if (!MainContentCache || !MainContentCache->OrigEntry) {
-// Can't do anything
-  } else if (MainContentCache->OrigEntry == SourceFile) {
-FirstFID = MainFileID;
-  } else {
-// Fall back: check whether we have the same base name and inode
-// as the main file.
-const FileEntry *MainFile = MainContentCache->OrigEntry;
-SourceFileName = llvm::sys::path::filename(SourceFile->getName());
-if (*SourceFileName == llvm::sys::path::filename(MainFile->getName())) {
-  SourceFileUID = getActualFileUID(SourceFile);
-  if (SourceFileUID) {
-if (Optional MainFileUID =
-getActualFileUID(MainFile)) {
-  if (*SourceFileUID == *MainFileUID) {
-FirstFID = MainFileID;
-SourceFile = MainFile;
-  }
-}
-  }
-}
-  }
+  const ContentCache *MainContentCache =
+  MainSLoc.getFile().getContentCache();
+  if (MainContentCache && MainContentCache->OrigEntry == SourceFile)
+return MainFileID;
 }
   }
 
-  if (FirstFID.isInvalid()) {
-// The location we're looking for isn't in the main file; look
-// through all of the local source locations.
-for (unsigned I = 0, N = local_sloc_entry_size(); I != N; ++I) {
-  bool Invalid = false;
-  const SLocEntry  = getLocalSLocEntry(I, );
-  if (Invalid)
-return FileID();
+  // The location we're looking for isn't in the main file; look
+  // through all of the local source locations.
+  for (unsigned I = 0, N = local_sloc_entry_size(); I != N; ++I) {
+bool Invalid = false;
+const SLocEntry  = getLocalSLocEntry(I, );
+if (Invalid)
+  return FileID();
 
-  if (SLoc.isFile() &&
-  SLoc.getFile().getContentCache() &&
-  SLoc.getFile().getContentCache()->OrigEntry == SourceFile) {
-FirstFID = FileID::get(I);
-break;
-  }
-}
-// If that still didn't help, try the modules.
-if (FirstFID.isInvalid()) {
-  for (unsigned I = 0, N = loaded_sloc_entry_size(); I != N; ++I) {
-const SLocEntry  = getLoadedSLocEntry(I);
-if (SLoc.isFile() &&
-SLoc.getFile().getContentCache() 

[clang-tools-extra] r367361 - [clangd][NFC] Fix typo in comment

[Jan Korous via cfe-commits]

Author: jkorous
Date: Tue Jul 30 15:18:04 2019
New Revision: 367361

URL: http://llvm.org/viewvc/llvm-project?rev=367361=rev
Log:
[clangd][NFC] Fix typo in comment

Modified:
clang-tools-extra/trunk/clangd/ClangdUnit.cpp

Modified: clang-tools-extra/trunk/clangd/ClangdUnit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdUnit.cpp?rev=367361=367360=367361=diff
==
--- clang-tools-extra/trunk/clangd/ClangdUnit.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdUnit.cpp Tue Jul 30 15:18:04 2019
@@ -374,7 +374,7 @@ ParsedAST::build(std::unique_ptr FixIncludes;
   auto BuildDir = VFS->getCurrentWorkingDirectory();


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

[PATCH] D64448: gsl::Owner/gsl::Pointer: Add implicit annotations for some std types

[Matthias Gehre via Phabricator via cfe-commits]

mgehre updated this revision to Diff 212446.
mgehre added a comment.

- Fix crash


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64448/new/

https://reviews.llvm.org/D64448

Files:
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaAttr.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/SemaCXX/attr-gsl-owner-pointer-std.cpp

Index: clang/test/SemaCXX/attr-gsl-owner-pointer-std.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/attr-gsl-owner-pointer-std.cpp
@@ -0,0 +1,129 @@
+// RUN: %clang_cc1 -ast-dump %s | \
+// RUN: FileCheck --implicit-check-not OwnerAttr --implicit-check-not PointerAttr %s
+
+// Test attribute inference for types in the standard library.
+namespace std {
+// Attributes are inferred for a (complete) class.
+class any {
+  // CHECK: CXXRecordDecl {{.*}} any
+  // CHECK: OwnerAttr {{.*}}
+};
+
+// Attributes are inferred for instantiations of a complete template.
+template 
+class vector {
+public:
+  class iterator {};
+  // CHECK: ClassTemplateDecl {{.*}} vector
+  // CHECK: OwnerAttr {{.*}}
+  // CHECK: CXXRecordDecl {{.*}} iterator
+  // CHECK: PointerAttr {{.*}}
+  // CHECK: ClassTemplateSpecializationDecl {{.*}} vector
+  // CHECK: TemplateArgument type 'int'
+  // CHECK: OwnerAttr
+  // CHECK: CXXRecordDecl {{.*}} iterator
+  // CHECK: PointerAttr {{.*}}
+};
+static_assert(sizeof(vector), "");   // Force instantiation.
+static_assert(sizeof(vector::iterator), ""); // Force instantiation.
+
+// If std::container::iterator is a using declaration, attributes are inferred
+// for the underlying class.
+template 
+class __set_iterator {};
+// CHECK: ClassTemplateDecl {{.*}} __set_iterator
+// CHECK: PointerAttr
+// CHECK: ClassTemplateSpecializationDecl {{.*}} __set_iterator
+// CHECK: TemplateArgument type 'int'
+// CHECK: PointerAttr
+
+template 
+class set {
+  // CHECK: ClassTemplateDecl {{.*}} set
+  // CHECK: OwnerAttr {{.*}}
+  // CHECK: ClassTemplateSpecializationDecl {{.*}} set
+  // CHECK: OwnerAttr {{.*}}
+public:
+  using iterator = __set_iterator;
+};
+static_assert(sizeof(set::iterator), ""); // Force instantiation.
+
+// If std::container::iterator is a typedef, attributes are inferred for the
+// underlying class.
+template 
+class __map_iterator {};
+// CHECK: ClassTemplateDecl {{.*}} __map_iterator
+// CHECK: PointerAttr
+// CHECK: ClassTemplateSpecializationDecl {{.*}} __map_iterator
+// CHECK: TemplateArgument type 'int'
+// CHECK: PointerAttr
+
+template 
+class map {
+  // CHECK: ClassTemplateDecl {{.*}} map
+  // CHECK: OwnerAttr {{.*}}
+  // CHECK: ClassTemplateSpecializationDecl {{.*}} map
+  // CHECK: OwnerAttr {{.*}}
+public:
+  typedef __map_iterator iterator;
+};
+static_assert(sizeof(map::iterator), ""); // Force instantiation.
+
+// Inline namespaces are ignored when checking if
+// the class lives in the std namespace.
+inline namespace inlinens {
+template 
+class __unordered_map_iterator {};
+// CHECK: ClassTemplateDecl {{.*}} __unordered_map_iterator
+// CHECK: PointerAttr
+// CHECK: ClassTemplateSpecializationDecl {{.*}} __unordered_map_iterator
+// CHECK: TemplateArgument type 'int'
+// CHECK: PointerAttr
+
+template 
+class unordered_map {
+  // CHECK: ClassTemplateDecl {{.*}} unordered_map
+  // CHECK: OwnerAttr {{.*}}
+  // CHECK: ClassTemplateSpecializationDecl {{.*}} unordered_map
+  // CHECK: OwnerAttr {{.*}}
+public:
+  typedef __unordered_map_iterator iterator;
+};
+static_assert(sizeof(unordered_map::iterator), ""); // Force instantiation.
+} // namespace inlinens
+
+// std::list has an implicit gsl::Owner attribute,
+// but explicit attributes take precedence.
+template 
+class [[gsl::Pointer]] list{};
+// CHECK: ClassTemplateDecl {{.*}} list
+// CHECK: PointerAttr {{.*}}
+// CHECK: ClassTemplateSpecializationDecl {{.*}} list
+// CHECK: PointerAttr {{.*}}
+
+static_assert(sizeof(list), ""); // Force instantiation.
+
+// Forward declared template (Owner).
+template <
+class CharT,
+class Traits>
+class basic_regex;
+// CHECK: ClassTemplateDecl {{.*}} basic_regex
+// CHECK: OwnerAttr {{.*}}
+
+// Forward declared template (Pointer).
+template 
+class reference_wrapper;
+// CHECK: ClassTemplateDecl {{.*}} reference_wrapper
+// CHECK: PointerAttr {{.*}}
+
+class some_unknown_type;
+// CHECK: CXXRecordDecl {{.*}} some_unknown_type
+
+} // namespace std
+
+namespace user {
+// If a class is not in the std namespace, we don't infer the attributes.
+class any {
+};
+} // namespace user
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -1690,6 +1690,7 @@
 mergeDeclAttributes(NewClass, PrevClassTemplate->getTemplatedDecl());
 
   AddPushedVisibilityAttribute(NewClass);
+  addDefaultGslOwnerPointerAttribute(NewClass);
 
  

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 marked 2 inline comments as done.
xbolva00 added inline comments.



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:5609
+def warn_mul_in_bool_context : Warning<
+  "'*' in bool context, maybe you mean '&&'?">,
+  InGroup;

jfb wrote:
> xbolva00 wrote:
> > jfb wrote:
> > > aaron.ballman wrote:
> > > > xbolva00 wrote:
> > > > > aaron.ballman wrote:
> > > > > > I would appreciate seeing some motivating examples for this case, 
> > > > > > because it seems like the `&&` suggestion is misleading more often 
> > > > > > than it's helpful in the current test cases.
> > > > > > 
> > > > > > Also, what is a "bool context"?
> > > > > Bool context - places where we expect boolean expressions.
> > > > > 
> > > > > If you have idea for better terminology, I am happy to apply it.
> > > > > 
> > > > > Yeah, I will remove “&&” suggestion.. 
> > > > I don't have a good recommendation for a replacement for "boolean 
> > > > context", so I suppose we can leave it.
> > > IMO it's clearer to say "assigning the result of a multiplication to a 
> > > boolean variable always yields {true|false}"
> > But it is very specific.. cannot be used for example here:
> > 
> > bool t() { return 0 * x; } 
> > 
> > In the place where the check is performed we know nothing whether expr is 
> > assigned/returned/etc.
> > 
> > I don’t believe we have to produce message with such details.
> All I'm saying is that "boolean context" ins't something people will 
> understand.
> Maybe "converting the result of a multiplication to a boolean always yields 
> {true|false}"?
+1, like it



Comment at: test/SemaCXX/warn-int-in-bool-context.cpp:96
+
+  if (f == apple || orange) // expected-warning {{enum constant in boolean 
context}}
+return a;

jfb wrote:
> xbolva00 wrote:
> > jfb wrote:
> > > xbolva00 wrote:
> > > > xbolva00 wrote:
> > > > > @aaron.ballman : In C (but not in C++ ugh?) mode we have: 'use of 
> > > > > logical '||' with constant operand' here..
> > > > > 
> > > > > /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:18:
> > > > >  warning: use of logical '||' with constant operand
> > > > >   if (f == apple || orange) // expected-warning {{enum constant in 
> > > > > boolean context}}
> > > > >  ^  ~~
> > > > > /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:18:
> > > > >  note: use '|' for a bitwise operation
> > > > >   if (f == apple || orange) // expected-warning {{enum constant in 
> > > > > boolean context}}
> > > > >  ^~
> > > > >  |
> > > > > /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:21:
> > > > >  warning: enum constant in boolean context
> > > > >   if (f == apple || orange) // expected-warning {{enum constant in 
> > > > > boolean context}}
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > What is your opinion here (^^) , @jfb ?
> > > > 
> > > > Thanks.
> > > C, C++, ObjC, and ObjC++ should emit different diagnostics here. That 
> > > being said, none of these diagnostics are particular easy to understand. 
> > > I don't think we should ever say "boolean context" anywhere.
> > So I will make this as it was - C++ only.
> It'll work in the other languages though, right?
Sight, making it C++ only leaves C with not diagnosed case:

_Bool f() { return orange; }

And I don’t know why ‘use of logical || with constant operand’ is C only :/..


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63082/new/

https://reviews.llvm.org/D63082



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

[PATCH] D65184: [Sema] Thread Safety Analysis: Fix negative capability's LockKind representation.

[Aaron Puchert via Phabricator via cfe-commits]

aaronpuchert added inline comments.



Comment at: clang/test/SemaCXX/warn-thread-safety-negative.cpp:135-140
+  if (condition) {
+assertNotHeld(); // expected-warning {{mutex '!mu' is acquired exclusively 
and shared in the same scope}}
+  } else {
+mu.Lock();
+mu.Unlock(); // expected-warning {{the other acquisition of mutex '!mu' is 
here}}
+  }

ziangwan wrote:
> aaronpuchert wrote:
> > ziangwan wrote:
> > > aaronpuchert wrote:
> > > > ziangwan wrote:
> > > > > aaronpuchert wrote:
> > > > > > Why would I want these warnings here? This code seems fine to me.
> > > > > > 
> > > > > > However, I don't see why we don't get `acquiring mutex 'mu' 
> > > > > > requires negative capability '!mu'` at line 138, or does that 
> > > > > > disappear because of the assertion?
> > > > > Showing `acquiring mutex 'mu' requires negative capability '!mu'` is 
> > > > > not in the scope of this patch. Please notice thread safety analysis 
> > > > > is still under development.
> > > > > 
> > > > > The reason is that, in one path we have 
> > > > > `ASSERT_SHARED_CAPABILITY(!mu)`, and in the other path we have 
> > > > > `RELEASE(mu)`. The assertion leads to negative shared capability but 
> > > > > the release leads to negative exclusive capability. A merge of the 
> > > > > two capabilities (merging "I am not trying to read" versus "I am not 
> > > > > trying to write") leads to a warning.
> > > > > 
> > > > > Without my patch, clang will issue a warning for the merge point in 
> > > > > test1() but not the merge point in test2().
> > > > But `ASSERT_SHARED_CAPABILITY(!mu)` implies that we also don't have an 
> > > > exclusive lock (an exclusive lock is stronger than a shared lock), and 
> > > > `RELEASE(mu)` without `ACQUIRE_SHARED(mu)` implies that we have neither 
> > > > a shared nor an exclusive lock as well.
> > > > 
> > > > In the end, I have the same question as above: Why do we want two kinds 
> > > > of negative capabilities? Isn't the idea that negative capabilities 
> > > > express the lock not being held at all?
> > > The problem is: by the current state of the thread safety analysis, 
> > > ASSERT_SHARED_CAPABILTIY(!mu) introduces a shared negative capability, 
> > > whereas RELEASE(mu) and RELEASE_SHARED(mu) introduce an exclusive 
> > > negative capability, and UNLOCK_FUNCTION(mu) introduces a generic 
> > > negative capability. All three are different. At merge points, warnings 
> > > will be issued if different types of negative capability are merged. The 
> > > current thread safety analysis produces bogus false positive in our code 
> > > base.
> > > 
> > > The solution I propose is that we should at least make RELEASE_SHARED(mu) 
> > > produce a shared negative capability.
> > > 
> > > Regarding why we should have types for negative capability, thinking 
> > > about "exclusive !mu" in a reader-writer lock situation, which means "I 
> > > am not trying to write". However, the code can still read. In other 
> > > words, "exclusive !mu" does not imply "shared !mu", and the code can 
> > > still hold the lock in shared state. Without the types of negative 
> > > capability, we wouldn't be able to express the situation described above.
> > I'm not doubting that there is a bug, but I don't think this is the right 
> > solution.
> > 
> > > ASSERT_SHARED_CAPABILTIY(!mu) introduces a shared negative capability
> > We should disallow using "shared" attributes with negative capabilities, 
> > and I'm surprised this isn't already the case.
> > 
> > > whereas RELEASE(mu) and RELEASE_SHARED(mu) introduce an exclusive 
> > > negative capability [...] The solution I propose is that we should at 
> > > least make RELEASE_SHARED(mu) produce a shared negative capability.
> > Clearly both leave `mu` in the same (unlocked) state, so why distinguish 
> > between them? After the lock is released, whichever mode it has been in 
> > before is ancient history. We want to track the **current** state of the 
> > lock.
> > 
> > > Regarding why we should have types for negative capability, thinking 
> > > about "exclusive !mu" in a reader-writer lock situation, which means "I 
> > > am not trying to write". However, the code can still read.
> > Negative capabilites aren't about what you are not doing with protected 
> > resources, in fact nothing is checked about that. Their purpose is to 
> > answer this question: can I draw this lock, or might it already been held? 
> > If you are holding a negative capability, that means you can acquire the 
> > lock. And when you can acquire the lock, you can do so in either mode. If 
> > the lock is currently held in any mode (and hence you're not holding a 
> > negative capability), then you can't acquire it in any mode, you have to 
> > release it first.
> > 
> > So there is no use in having two kinds of negative capabilities. An 
> > "exclusive !mu" should be either "!mu" or "shared(mu)", depending on what 
> > the functions expects. The 

[PATCH] D63907: [clang-scan-deps] Implementation of dependency scanner over minimized sources

[Alex Lorenz via Phabricator via cfe-commits]

arphaman updated this revision to Diff 212442.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63907/new/

https://reviews.llvm.org/D63907

Files:
  clang/include/clang/Basic/FileManager.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningFilesystem.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningService.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
  clang/lib/Tooling/DependencyScanning/CMakeLists.txt
  clang/lib/Tooling/DependencyScanning/DependencyScanningFilesystem.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningService.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
  
clang/test/ClangScanDeps/Inputs/frameworks/Framework.framework/Headers/Framework.h
  
clang/test/ClangScanDeps/Inputs/frameworks/Framework.framework/PrivateHeaders/PrivateHeader.h
  clang/test/ClangScanDeps/Inputs/header_stat_before_open_cdb.json
  clang/test/ClangScanDeps/Inputs/vfsoverlay.yaml
  clang/test/ClangScanDeps/Inputs/vfsoverlay_cdb.json
  clang/test/ClangScanDeps/header_stat_before_open.m
  clang/test/ClangScanDeps/regular_cdb.cpp
  clang/test/ClangScanDeps/vfsoverlay.cpp
  clang/tools/clang-scan-deps/ClangScanDeps.cpp

Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -8,6 +8,7 @@
 
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Tooling/CommonOptionsParser.h"
+#include "clang/Tooling/DependencyScanning/DependencyScanningService.h"
 #include "clang/Tooling/DependencyScanning/DependencyScanningWorker.h"
 #include "clang/Tooling/JSONCompilationDatabase.h"
 #include "llvm/Support/InitLLVM.h"
@@ -45,9 +46,10 @@
   ///
   /// \param Compilations The reference to the compilation database that's
   /// used by the clang tool.
-  DependencyScanningTool(const tooling::CompilationDatabase ,
+  DependencyScanningTool(DependencyScanningService ,
+ const tooling::CompilationDatabase ,
  SharedStream , SharedStream )
-  : Compilations(Compilations), OS(OS), Errs(Errs) {}
+  : Worker(Service), Compilations(Compilations), OS(OS), Errs(Errs) {}
 
   /// Computes the dependencies for the given file and prints them out.
   ///
@@ -80,6 +82,20 @@
 
 llvm::cl::OptionCategory DependencyScannerCategory("Tool options");
 
+static llvm::cl::opt ScanMode(
+"mode",
+llvm::cl::desc("The preprocessing mode used to compute the dependencies"),
+llvm::cl::values(
+clEnumValN(ScanningMode::MinimizedSourcePreprocessing,
+   "preprocess-minimized-sources",
+   "The set of dependencies is computed by preprocessing the "
+   "source files that were minimized to only include the "
+   "contents that might affect the dependencies"),
+clEnumValN(ScanningMode::CanonicalPreprocessing, "preprocess",
+   "The set of dependencies is computed by preprocessing the "
+   "unmodified source files")),
+llvm::cl::init(ScanningMode::MinimizedSourcePreprocessing));
+
 llvm::cl::opt
 NumThreads("j", llvm::cl::Optional,
llvm::cl::desc("Number of worker threads to use (default: use "
@@ -136,12 +152,14 @@
   SharedStream Errs(llvm::errs());
   // Print out the dependency results to STDOUT by default.
   SharedStream DependencyOS(llvm::outs());
+
+  DependencyScanningService Service(ScanMode);
   unsigned NumWorkers =
   NumThreads == 0 ? llvm::hardware_concurrency() : NumThreads;
   std::vector> WorkerTools;
   for (unsigned I = 0; I < NumWorkers; ++I)
 WorkerTools.push_back(llvm::make_unique(
-*AdjustingCompilations, DependencyOS, Errs));
+Service, *AdjustingCompilations, DependencyOS, Errs));
 
   std::vector WorkerThreads;
   std::atomic HadErrors(false);
Index: clang/test/ClangScanDeps/vfsoverlay.cpp
===
--- /dev/null
+++ clang/test/ClangScanDeps/vfsoverlay.cpp
@@ -0,0 +1,17 @@
+// RUN: rm -rf %t.dir
+// RUN: rm -rf %t.cdb
+// RUN: mkdir -p %t.dir
+// RUN: cp %s %t.dir/vfsoverlay.cpp
+// RUN: sed -e "s|DIR|%/t.dir|g" %S/Inputs/vfsoverlay.yaml > %t.dir/vfsoverlay.yaml
+// RUN: mkdir %t.dir/Inputs
+// RUN: cp %S/Inputs/header.h %t.dir/Inputs/header.h
+// RUN: sed -e "s|DIR|%/t.dir|g" %S/Inputs/vfsoverlay_cdb.json > %t.cdb
+//
+// RUN: clang-scan-deps -compilation-database %t.cdb -j 1 | \
+// RUN:   FileCheck %s
+
+#include "not_real.h"
+
+// CHECK: clang-scan-deps dependency
+// CHECK-NEXT: vfsoverlay.cpp
+// CHECK-NEXT: Inputs{{/|\\}}header.h
Index: clang/test/ClangScanDeps/regular_cdb.cpp
===
--- clang/test/ClangScanDeps/regular_cdb.cpp
+++ clang/test/ClangScanDeps/regular_cdb.cpp
@@ -8,7 +8,9 @@
 // RUN: cp 

[PATCH] D65184: [Sema] Thread Safety Analysis: Fix negative capability's LockKind representation.

[Aaron Puchert via Phabricator via cfe-commits]

aaronpuchert added a comment.

The primary purpose of Thread Safety Analysis is to make sure that accesses to 
shared resources are protected. That's why we only track whether a lock is 
available by default (i.e. without -Wthread-safety-negative), locks that we 
don't know anything about are assumed to be unlocked. As a side effect, we can 
detect double unlocks and lock/unlock-kind mismatches.

But we cannot detect double locks (and deadlocks) over function boundaries. 
This is why negative capabilities were introduced. But because not everybody 
cares about that enough to warrant more annotations, it's not on by default.

> Regarding why we should have types for negative capability, thinking about 
> "exclusive !mu" in a reader-writer lock situation, which means "I am not 
> trying to write". However, the code can still read.

Negative capabilities don't declare that we're not reading/writing: we can't do 
that without holding the actual (positive) capability anyway!

Having the capability `!mu` just means that we can assume `mu` is not locked. 
We will then usually acquire the `mu` (otherwise the annotation wouldn't be 
needed).


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65184/new/

https://reviews.llvm.org/D65184



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

[PATCH] D65239: [analyzer] RangeConstraintManager: Apply constraint ranges of bitwise operations

[Csaba Dabis via Phabricator via cfe-commits]

Charusso added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:496
+  // as a bitwise operation result could be null.
+  if (RS.getConcreteValue() && RS.getConcreteValue()->getExtValue() == 0)
+return State;

NoQ wrote:
> Instead of "we know that the value is null", we should write "we //don't// 
> know that the value is //non-//null". I.e. if we're not sure, we must still 
> do an early return.
Oh, fail. Thanks!



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:507
+  ConstraintRangeTy Constraints = State->get();
+  for (const SymbolRef CurrentSym : SIE->symbols()) {
+if (CurrentSym == SIE)

NoQ wrote:
> This loop doesn't make sense. When your expression looks like `(((a + b) + c) 
> + d) & (e + f)`, you don't want to iterate separately over `a`, `b`, `c`, 
> `d`, `e`, `f`; but that's what this loop would do. You should only look at 
> the LHS and the RHS. If you want to descend further, do so recursively, so 
> that to keep track of the overall structure of the symbolic expression as 
> you're traversing it, rather than traversing sub-expressions in an 
> essentially random order.
It is rather sequential in the bitwise world, but I think if you would look 
only at the LHS `SymExpr`, it should be enough. Also I would like to avoid 
extra overhead, that `symbols()` business was large enough. Thanks!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65239/new/

https://reviews.llvm.org/D65239



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

[PATCH] D64448: gsl::Owner/gsl::Pointer: Add implicit annotations for some std types

[Matthias Gehre via Phabricator via cfe-commits]

mgehre updated this revision to Diff 212441.
mgehre added a comment.

- Add missing check


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64448/new/

https://reviews.llvm.org/D64448

Files:
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaAttr.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/SemaCXX/attr-gsl-owner-pointer-std.cpp

Index: clang/test/SemaCXX/attr-gsl-owner-pointer-std.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/attr-gsl-owner-pointer-std.cpp
@@ -0,0 +1,129 @@
+// RUN: %clang_cc1 -ast-dump %s | \
+// RUN: FileCheck --implicit-check-not OwnerAttr --implicit-check-not PointerAttr %s
+
+// Test attribute inference for types in the standard library.
+namespace std {
+// Attributes are inferred for a (complete) class.
+class any {
+  // CHECK: CXXRecordDecl {{.*}} any
+  // CHECK: OwnerAttr {{.*}}
+};
+
+// Attributes are inferred for instantiations of a complete template.
+template 
+class vector {
+public:
+  class iterator {};
+  // CHECK: ClassTemplateDecl {{.*}} vector
+  // CHECK: OwnerAttr {{.*}}
+  // CHECK: CXXRecordDecl {{.*}} iterator
+  // CHECK: PointerAttr {{.*}}
+  // CHECK: ClassTemplateSpecializationDecl {{.*}} vector
+  // CHECK: TemplateArgument type 'int'
+  // CHECK: OwnerAttr
+  // CHECK: CXXRecordDecl {{.*}} iterator
+  // CHECK: PointerAttr {{.*}}
+};
+static_assert(sizeof(vector), "");   // Force instantiation.
+static_assert(sizeof(vector::iterator), ""); // Force instantiation.
+
+// If std::container::iterator is a using declaration, attributes are inferred
+// for the underlying class.
+template 
+class __set_iterator {};
+// CHECK: ClassTemplateDecl {{.*}} __set_iterator
+// CHECK: PointerAttr
+// CHECK: ClassTemplateSpecializationDecl {{.*}} __set_iterator
+// CHECK: TemplateArgument type 'int'
+// CHECK: PointerAttr
+
+template 
+class set {
+  // CHECK: ClassTemplateDecl {{.*}} set
+  // CHECK: OwnerAttr {{.*}}
+  // CHECK: ClassTemplateSpecializationDecl {{.*}} set
+  // CHECK: OwnerAttr {{.*}}
+public:
+  using iterator = __set_iterator;
+};
+static_assert(sizeof(set::iterator), ""); // Force instantiation.
+
+// If std::container::iterator is a typedef, attributes are inferred for the
+// underlying class.
+template 
+class __map_iterator {};
+// CHECK: ClassTemplateDecl {{.*}} __map_iterator
+// CHECK: PointerAttr
+// CHECK: ClassTemplateSpecializationDecl {{.*}} __map_iterator
+// CHECK: TemplateArgument type 'int'
+// CHECK: PointerAttr
+
+template 
+class map {
+  // CHECK: ClassTemplateDecl {{.*}} map
+  // CHECK: OwnerAttr {{.*}}
+  // CHECK: ClassTemplateSpecializationDecl {{.*}} map
+  // CHECK: OwnerAttr {{.*}}
+public:
+  typedef __map_iterator iterator;
+};
+static_assert(sizeof(map::iterator), ""); // Force instantiation.
+
+// Inline namespaces are ignored when checking if
+// the class lives in the std namespace.
+inline namespace inlinens {
+template 
+class __unordered_map_iterator {};
+// CHECK: ClassTemplateDecl {{.*}} __unordered_map_iterator
+// CHECK: PointerAttr
+// CHECK: ClassTemplateSpecializationDecl {{.*}} __unordered_map_iterator
+// CHECK: TemplateArgument type 'int'
+// CHECK: PointerAttr
+
+template 
+class unordered_map {
+  // CHECK: ClassTemplateDecl {{.*}} unordered_map
+  // CHECK: OwnerAttr {{.*}}
+  // CHECK: ClassTemplateSpecializationDecl {{.*}} unordered_map
+  // CHECK: OwnerAttr {{.*}}
+public:
+  typedef __unordered_map_iterator iterator;
+};
+static_assert(sizeof(unordered_map::iterator), ""); // Force instantiation.
+} // namespace inlinens
+
+// std::list has an implicit gsl::Owner attribute,
+// but explicit attributes take precedence.
+template 
+class [[gsl::Pointer]] list{};
+// CHECK: ClassTemplateDecl {{.*}} list
+// CHECK: PointerAttr {{.*}}
+// CHECK: ClassTemplateSpecializationDecl {{.*}} list
+// CHECK: PointerAttr {{.*}}
+
+static_assert(sizeof(list), ""); // Force instantiation.
+
+// Forward declared template (Owner).
+template <
+class CharT,
+class Traits>
+class basic_regex;
+// CHECK: ClassTemplateDecl {{.*}} basic_regex
+// CHECK: OwnerAttr {{.*}}
+
+// Forward declared template (Pointer).
+template 
+class reference_wrapper;
+// CHECK: ClassTemplateDecl {{.*}} reference_wrapper
+// CHECK: PointerAttr {{.*}}
+
+class some_unknown_type;
+// CHECK: CXXRecordDecl {{.*}} some_unknown_type
+
+} // namespace std
+
+namespace user {
+// If a class is not in the std namespace, we don't infer the attributes.
+class any {
+};
+} // namespace user
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -1690,6 +1690,7 @@
 mergeDeclAttributes(NewClass, PrevClassTemplate->getTemplatedDecl());
 
   AddPushedVisibilityAttribute(NewClass);
+  

[PATCH] D65239: [analyzer] RangeConstraintManager: Apply constraint ranges of bitwise operations

[Csaba Dabis via Phabricator via cfe-commits]

Charusso updated this revision to Diff 212440.
Charusso marked 6 inline comments as done.
Charusso added a comment.

- Fix.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65239/new/

https://reviews.llvm.org/D65239

Files:
  clang/include/clang/AST/Expr.h
  
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/bitwise-nullability.cpp
  clang/test/Analysis/bitwise-ranges.cpp

Index: clang/test/Analysis/bitwise-ranges.cpp
===
--- /dev/null
+++ clang/test/Analysis/bitwise-ranges.cpp
@@ -0,0 +1,38 @@
+// RUN: %clang_analyze_cc1 \
+// RUN:  -analyzer-checker=core,debug.ExprInspection \
+// RUN:  -verify %s
+
+void clang_analyzer_eval(int);
+
+void test_range(unsigned int X) {
+  if (X < 2 || X > 3)
+return;
+
+  clang_analyzer_eval(X >= 2 && X <= 3);
+  // expected-warning@-1 {{TRUE}}
+
+  // We have no non-null constraint range information available for 'A'.
+  unsigned int A = X | 8;
+  clang_analyzer_eval((A > 0 && A < 0) || A == 0);
+  // expected-warning@-1 {{FALSE}}
+
+  unsigned int B = X & 8;
+  clang_analyzer_eval((B >= 1 && B <= 8) || B == 0);
+  // expected-warning@-1 {{TRUE}}
+
+  unsigned int C = X & 1;
+  clang_analyzer_eval((C >= 1 && C <= 1) || C == 0);
+  // expected-warning@-1 {{TRUE}}
+
+  unsigned int D = X << 1;
+  clang_analyzer_eval((D >= 1 && D <= 4294967295) || D == 0);
+  // expected-warning@-1 {{TRUE}}
+
+  unsigned int E = X >> 1;
+  clang_analyzer_eval((E >= 1 && E <= 4294967295) || E == 0);
+  // expected-warning@-1 {{TRUE}}
+
+  void(X / 0);
+  // expected-warning@-1 {{division by zero is undefined}}
+  // expected-warning@-2 {{Division by zero}}
+}
Index: clang/test/Analysis/bitwise-nullability.cpp
===
--- /dev/null
+++ clang/test/Analysis/bitwise-nullability.cpp
@@ -0,0 +1,38 @@
+// RUN: %clang_analyze_cc1 \
+// RUN:  -analyzer-checker=core \
+// RUN:  -analyzer-output=text -verify %s
+
+typedef unsigned long long uint64_t;
+
+void test_null_lhs_range_to_non_null_result_infeasible(uint64_t Magic) {
+  uint64_t MaskedMagic = Magic & (0xULL >> 13);
+
+  if (Magic) {
+// no-note: 'Assuming 'Magic' is 0' was here.
+return;
+  }
+
+  if (MaskedMagic) {
+// no-note: 'Assuming 'MaskedMagic' is not equal to 0' was here.
+(void)(1 / Magic); // no-warning
+  }
+}
+
+void test_non_null_lhs_range_to_null_result_feasible(uint64_t Magic) {
+  uint64_t MaskedMagic = Magic & (0xULL >> 13);
+
+  if (!Magic) {
+// expected-note@-1 {{Assuming 'Magic' is not equal to 0}}
+// expected-note@-2 {{Taking false branch}}
+return;
+  }
+
+  if (!MaskedMagic) {
+// expected-note@-1 {{Assuming 'MaskedMagic' is 0}}
+// expected-note@-2 {{Taking true branch}}
+(void)(1 / !Magic);
+// expected-note@-1 {{'Magic' is not equal to 0}}
+// expected-note@-2 {{Division by zero}}
+// expected-warning@-3 {{Division by zero}}
+  }
+}
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -476,6 +476,51 @@
   return Input;
 }
 
+// We do not support evaluating bitwise operations, so that when we check for
+// their results being null we create a new assumption whether the current new
+// symbol is null or non-null. If we are on the non-null assumption's branch
+// we need to check the left-hand side operand's constraint range informations:
+// - It if contradicts with the forming new range 'RS' then it returns a null
+//   state as it is an impossible condition.
+// - Otherwise it removes the nullability from its ranges as we know that it
+//   cannot be null on that branch.
+static ProgramStateRef applyBitwiseRanges(ProgramStateRef State,
+  BasicValueFactory ,
+  RangeSet::Factory , RangeSet RS,
+  SymbolRef Sym) {
+  if (RS.isEmpty())
+return State;
+
+  // If we cannot be sure whether the value is non-null, do nothing.
+  const llvm::APSInt  = BV.getAPSIntType(Sym->getType()).getZeroValue();
+  if (!RS.Intersect(BV, F, Zero, Zero).isEmpty())
+return State;
+
+  const SymIntExpr *SIE = dyn_cast(Sym);
+  if (!SIE)
+return State;
+
+  if (!BinaryOperator::isBitwiseOrShiftOp(SIE->getOpcode()))
+return State;
+
+  ConstraintRangeTy Constraints = State->get();
+  const SymExpr *CurrentSym = SIE->getLHS();
+  if (const RangeSet *CurrentRS = Constraints.lookup(CurrentSym)) {
+const RangeSet NewRS = assumeNonZero(BV, F, CurrentSym, *CurrentRS);
+
+// If the 'NewRS' is not empty it means the 'CurrentSym' is not assumed
+// to be concrete zero, so it does 

[PATCH] D64448: gsl::Owner/gsl::Pointer: Add implicit annotations for some std types

[Matthias Gehre via Phabricator via cfe-commits]

mgehre added inline comments.



Comment at: clang/include/clang/Sema/Sema.h:6097
+
+  /// Add [[gsl::Owner]] and [[gsl::Pointer]] attributes for std:: types.
+  void addDefaultGslPointerAttribute(TypedefNameDecl *TD);

gribozavr wrote:
> It seems like this function does not add gsl::Owner.
Fixed comment



Comment at: clang/lib/Sema/SemaTemplate.cpp:1689
   AddPushedVisibilityAttribute(NewClass);
+  addDefaultGslOwnerPointerAttribute(NewClass);
 

gribozavr wrote:
> It shouldn't be necessary to perform inference here, instead, the attributes 
> should be instantiated, see `instantiateDependentAlignedAttr` in 
> SemaTemplateInstantiateDecl.cpp for an example.
From what I understand, here the attribute is put on the `ClassTemplateDecl`. 
Without this, there would be no attribute to instantiate from?
The instantiation of OwnerAttr/PointerAttr is auto-generated into 
instantiateTemplateAttribute() in 
`build/tools/clang/include/clang/Sema/AttrTemplateInstantiate.inc`.



Comment at: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:702
   SemaRef.InstantiateAttrs(TemplateArgs, D, Typedef);
+  SemaRef.addDefaultGslPointerAttribute(Typedef);
 

gribozavr wrote:
> Ditto, should not be necessary to perform inference here.
I'll move this to already act on the typedef in the ClassTemplateDecl (instead 
of the instantiation here).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64448/new/

https://reviews.llvm.org/D64448



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

[PATCH] D64448: gsl::Owner/gsl::Pointer: Add implicit annotations for some std types

[Matthias Gehre via Phabricator via cfe-commits]

mgehre updated this revision to Diff 212439.
mgehre marked 6 inline comments as done.
mgehre added a comment.

- Fix comments
- Add Pointer via typedef on ClassTemplateDecl


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64448/new/

https://reviews.llvm.org/D64448

Files:
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaAttr.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/SemaCXX/attr-gsl-owner-pointer-std.cpp

Index: clang/test/SemaCXX/attr-gsl-owner-pointer-std.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/attr-gsl-owner-pointer-std.cpp
@@ -0,0 +1,129 @@
+// RUN: %clang_cc1 -ast-dump %s | \
+// RUN: FileCheck --implicit-check-not OwnerAttr --implicit-check-not PointerAttr %s
+
+// Test attribute inference for types in the standard library.
+namespace std {
+// Attributes are inferred for a (complete) class.
+class any {
+  // CHECK: CXXRecordDecl {{.*}} any
+  // CHECK: OwnerAttr {{.*}}
+};
+
+// Attributes are inferred for instantiations of a complete template.
+template 
+class vector {
+public:
+  class iterator {};
+  // CHECK: ClassTemplateDecl {{.*}} vector
+  // CHECK: OwnerAttr {{.*}}
+  // CHECK: CXXRecordDecl {{.*}} iterator
+  // CHECK: PointerAttr {{.*}}
+  // CHECK: ClassTemplateSpecializationDecl {{.*}} vector
+  // CHECK: TemplateArgument type 'int'
+  // CHECK: OwnerAttr
+  // CHECK: CXXRecordDecl {{.*}} iterator
+  // CHECK: PointerAttr {{.*}}
+};
+static_assert(sizeof(vector), "");   // Force instantiation.
+static_assert(sizeof(vector::iterator), ""); // Force instantiation.
+
+// If std::container::iterator is a using declaration, attributes are inferred
+// for the underlying class.
+template 
+class __set_iterator {};
+// CHECK: ClassTemplateDecl {{.*}} __set_iterator
+// CHECK: PointerAttr
+// CHECK: ClassTemplateSpecializationDecl {{.*}} __set_iterator
+// CHECK: TemplateArgument type 'int'
+// CHECK: PointerAttr
+
+template 
+class set {
+  // CHECK: ClassTemplateDecl {{.*}} set
+  // CHECK: OwnerAttr {{.*}}
+  // CHECK: ClassTemplateSpecializationDecl {{.*}} set
+  // CHECK: OwnerAttr {{.*}}
+public:
+  using iterator = __set_iterator;
+};
+static_assert(sizeof(set::iterator), ""); // Force instantiation.
+
+// If std::container::iterator is a typedef, attributes are inferred for the
+// underlying class.
+template 
+class __map_iterator {};
+// CHECK: ClassTemplateDecl {{.*}} __map_iterator
+// CHECK: PointerAttr
+// CHECK: ClassTemplateSpecializationDecl {{.*}} __map_iterator
+// CHECK: TemplateArgument type 'int'
+// CHECK: PointerAttr
+
+template 
+class map {
+  // CHECK: ClassTemplateDecl {{.*}} map
+  // CHECK: OwnerAttr {{.*}}
+  // CHECK: ClassTemplateSpecializationDecl {{.*}} map
+  // CHECK: OwnerAttr {{.*}}
+public:
+  typedef __map_iterator iterator;
+};
+static_assert(sizeof(map::iterator), ""); // Force instantiation.
+
+// Inline namespaces are ignored when checking if
+// the class lives in the std namespace.
+inline namespace inlinens {
+template 
+class __unordered_map_iterator {};
+// CHECK: ClassTemplateDecl {{.*}} __unordered_map_iterator
+// CHECK: PointerAttr
+// CHECK: ClassTemplateSpecializationDecl {{.*}} __unordered_map_iterator
+// CHECK: TemplateArgument type 'int'
+// CHECK: PointerAttr
+
+template 
+class unordered_map {
+  // CHECK: ClassTemplateDecl {{.*}} unordered_map
+  // CHECK: OwnerAttr {{.*}}
+  // CHECK: ClassTemplateSpecializationDecl {{.*}} unordered_map
+  // CHECK: OwnerAttr {{.*}}
+public:
+  typedef __unordered_map_iterator iterator;
+};
+static_assert(sizeof(unordered_map::iterator), ""); // Force instantiation.
+} // namespace inlinens
+
+// std::list has an implicit gsl::Owner attribute,
+// but explicit attributes take precedence.
+template 
+class [[gsl::Pointer]] list{};
+// CHECK: ClassTemplateDecl {{.*}} list
+// CHECK: PointerAttr {{.*}}
+// CHECK: ClassTemplateSpecializationDecl {{.*}} list
+// CHECK: PointerAttr {{.*}}
+
+static_assert(sizeof(list), ""); // Force instantiation.
+
+// Forward declared template (Owner).
+template <
+class CharT,
+class Traits>
+class basic_regex;
+// CHECK: ClassTemplateDecl {{.*}} basic_regex
+// CHECK: OwnerAttr {{.*}}
+
+// Forward declared template (Pointer).
+template 
+class reference_wrapper;
+// CHECK: ClassTemplateDecl {{.*}} reference_wrapper
+// CHECK: PointerAttr {{.*}}
+
+class some_unknown_type;
+// CHECK: CXXRecordDecl {{.*}} some_unknown_type
+
+} // namespace std
+
+namespace user {
+// If a class is not in the std namespace, we don't infer the attributes.
+class any {
+};
+} // namespace user
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -1690,6 +1690,7 @@
 mergeDeclAttributes(NewClass, PrevClassTemplate->getTemplatedDecl());
 
   

[PATCH] D65184: [Sema] Thread Safety Analysis: Fix negative capability's LockKind representation.

[Ziang Wan via Phabricator via cfe-commits]

ziangwan marked 2 inline comments as done.
ziangwan added inline comments.



Comment at: clang/test/SemaCXX/thread-safety-annotations.h:47
+// Enable thread safety attributes only with clang.
+// The attributes can be safely erased when compiling with other compilers.
+#if defined(__clang__) && (!defined(SWIG))

aaronpuchert wrote:
> ziangwan wrote:
> > aaronpuchert wrote:
> > > ziangwan wrote:
> > > > nickdesaulniers wrote:
> > > > > Is this test suite run with other compilers? If not, I think we can 
> > > > > remove the case?
> > > > Yeah, you are right. I just copied the header definitions from clang 
> > > > thread safety analysis doc.
> > > Why aren't you using the existing macros? The idea was to run the tests 
> > > with both old and new terminology, and for the time being, I think we 
> > > should maintain both.
> > There are already tests on existing macros. I want to introduce tests about 
> > the new macros as well.
> There are no old and new macros, there are only old and new **attributes**. 
> The existing macros use both sets of attributes, depending on the value of 
> `USE_CAPABILITY` with which the tests are run. Using other macro names is 
> just window dressing.
Gotcha.



Comment at: clang/test/SemaCXX/warn-thread-safety-negative.cpp:135-140
+  if (condition) {
+assertNotHeld(); // expected-warning {{mutex '!mu' is acquired exclusively 
and shared in the same scope}}
+  } else {
+mu.Lock();
+mu.Unlock(); // expected-warning {{the other acquisition of mutex '!mu' is 
here}}
+  }

aaronpuchert wrote:
> ziangwan wrote:
> > aaronpuchert wrote:
> > > ziangwan wrote:
> > > > aaronpuchert wrote:
> > > > > Why would I want these warnings here? This code seems fine to me.
> > > > > 
> > > > > However, I don't see why we don't get `acquiring mutex 'mu' requires 
> > > > > negative capability '!mu'` at line 138, or does that disappear 
> > > > > because of the assertion?
> > > > Showing `acquiring mutex 'mu' requires negative capability '!mu'` is 
> > > > not in the scope of this patch. Please notice thread safety analysis is 
> > > > still under development.
> > > > 
> > > > The reason is that, in one path we have 
> > > > `ASSERT_SHARED_CAPABILITY(!mu)`, and in the other path we have 
> > > > `RELEASE(mu)`. The assertion leads to negative shared capability but 
> > > > the release leads to negative exclusive capability. A merge of the two 
> > > > capabilities (merging "I am not trying to read" versus "I am not trying 
> > > > to write") leads to a warning.
> > > > 
> > > > Without my patch, clang will issue a warning for the merge point in 
> > > > test1() but not the merge point in test2().
> > > But `ASSERT_SHARED_CAPABILITY(!mu)` implies that we also don't have an 
> > > exclusive lock (an exclusive lock is stronger than a shared lock), and 
> > > `RELEASE(mu)` without `ACQUIRE_SHARED(mu)` implies that we have neither a 
> > > shared nor an exclusive lock as well.
> > > 
> > > In the end, I have the same question as above: Why do we want two kinds 
> > > of negative capabilities? Isn't the idea that negative capabilities 
> > > express the lock not being held at all?
> > The problem is: by the current state of the thread safety analysis, 
> > ASSERT_SHARED_CAPABILTIY(!mu) introduces a shared negative capability, 
> > whereas RELEASE(mu) and RELEASE_SHARED(mu) introduce an exclusive negative 
> > capability, and UNLOCK_FUNCTION(mu) introduces a generic negative 
> > capability. All three are different. At merge points, warnings will be 
> > issued if different types of negative capability are merged. The current 
> > thread safety analysis produces bogus false positive in our code base.
> > 
> > The solution I propose is that we should at least make RELEASE_SHARED(mu) 
> > produce a shared negative capability.
> > 
> > Regarding why we should have types for negative capability, thinking about 
> > "exclusive !mu" in a reader-writer lock situation, which means "I am not 
> > trying to write". However, the code can still read. In other words, 
> > "exclusive !mu" does not imply "shared !mu", and the code can still hold 
> > the lock in shared state. Without the types of negative capability, we 
> > wouldn't be able to express the situation described above.
> I'm not doubting that there is a bug, but I don't think this is the right 
> solution.
> 
> > ASSERT_SHARED_CAPABILTIY(!mu) introduces a shared negative capability
> We should disallow using "shared" attributes with negative capabilities, and 
> I'm surprised this isn't already the case.
> 
> > whereas RELEASE(mu) and RELEASE_SHARED(mu) introduce an exclusive negative 
> > capability [...] The solution I propose is that we should at least make 
> > RELEASE_SHARED(mu) produce a shared negative capability.
> Clearly both leave `mu` in the same (unlocked) state, so why distinguish 
> between them? After the lock is released, whichever mode it has been in 
> before is 

[PATCH] D63139: [Diagnostics] Implement -Wswitch-unreachable

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 accepted this revision.
xbolva00 added a comment.
This revision is now accepted and ready to land.

Since motivation examples are already handled by -Wunreachable-code, I will 
close this revision.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63139/new/

https://reviews.llvm.org/D63139



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

[PATCH] D63907: [clang-scan-deps] Implementation of dependency scanner over minimized sources

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added inline comments.



Comment at: 
clang/include/clang/Tooling/DependencyScanning/DependencyScanningFilesystem.h:1
+//===- DependencyScanningFilesystem.h - clang-scan-deps fs ===---*- C++ 
-*-===//
+//

aganea wrote:
> General comment for this file and the implementation: it seems there's 
> nothing specific to the dependency scanning, except for replacing the content 
> with minimized content? This cached FS could be very well used to compile a 
> project with parallel workers. Could this be part of the `VirtualFileSystem` 
> infrastructure? ( `llvm/include/llvm/Support/VirtualFileSystem.h`) If yes, 
> can you possibly create a separate patch for this? @JDevlieghere @sammccall 
I think it could be possible to separate out the cache, but we definitely need 
a subclass of a VFS to handle some Clang specific logic for how to determine 
how to deal with module files for instance. I wouldn't be opposed to factoring 
it out if people are interested. I think that can be done as a follow-up if 
there's an interest though.




Comment at: 
clang/lib/Tooling/DependencyScanning/DependencyScanningFilesystem.cpp:84
+DependencyScanningFilesystemSharedCache() {
+  NumShards = 8;
+  CacheShards = llvm::make_unique(NumShards);

aganea wrote:
> This line needs a comment. Is this value based on empirical results across 
> different hardwares? (I can't recall your answer at the LLVM conf) I am 
> wondering what would be the good strategy here? The more cores/HT in your PC, 
> the more chances that you'll hit the same shard, thus locking. But the bigger 
> we make this value, the more `StringMaps` we will have, and more cache misses 
> possibly.
> Should it be something like `llvm::hardware_concurrency() / some_fudge`? It'd 
> be interesting to subsequently profile on high core count machines (or maybe 
> you have done that).
I rewrote it to use a heuristic we settled on after doing empirical testing on 
an 18 core / 36 thread machine ( max(2, thread_count / 4) ), and added a 
comment. This was the number `9` (36 / 4) I mentioned at the talk, so we only 
got to it because of a heuristic. I think now after some SDK/OS updates the 
effect from adding more shards is less pronounced, so it mostly flatlines past 
some number between 5-10. A better heuristic would probably be OS specific to 
take the cost of lock contention into account.

Note that the increased number of shards does not increase the number of cache 
misses, because the shard # is determined by the filename (we don't actually 
have global cache misses, as the cache is designed to have only one miss per 
file when it's first accessed)! It's just that an increased number of shards 
doesn't improve performance after hitting some specific limit, so we want to 
find a point where we can taper it off.

It would still be definitely interesting to profile it on other high core 
machines with different OSes to see if it's a reasonable heuristic for those 
scenarios too.



Comment at: 
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp:148
+  RealFS = new ProxyFileSystemWithoutChdir(llvm::vfs::getRealFileSystem());
+  if (Service.getMode() == ScanningMode::MinimizedSourcePreprocessing)
+DepFS = new DependencyScanningFilesystem(Service.getSharedCache(), RealFS);

aganea wrote:
> Can we not use caching all the time?
We want to have a mode where it's as close to the regular `clang -E` invocation 
as possible for correctness CI and testing. We also haven't evaluated if the 
cost of keeping non-minimized sources in memory, so it might be too expensive 
for practical use? I can add a third option that caches but doesn't minimize 
though as a follow-up patch though 



Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63907/new/

https://reviews.llvm.org/D63907



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

[PATCH] D63907: [clang-scan-deps] Implementation of dependency scanner over minimized sources

[Alex Lorenz via Phabricator via cfe-commits]

arphaman updated this revision to Diff 212435.
arphaman marked 7 inline comments as done.

Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63907/new/

https://reviews.llvm.org/D63907

Files:
  clang/include/clang/Basic/FileManager.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningFilesystem.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningService.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
  clang/lib/Tooling/DependencyScanning/CMakeLists.txt
  clang/lib/Tooling/DependencyScanning/DependencyScanningFilesystem.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningService.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
  
clang/test/ClangScanDeps/Inputs/frameworks/Framework.framework/Headers/Framework.h
  
clang/test/ClangScanDeps/Inputs/frameworks/Framework.framework/PrivateHeaders/PrivateHeader.h
  clang/test/ClangScanDeps/Inputs/header_stat_before_open_cdb.json
  clang/test/ClangScanDeps/Inputs/vfsoverlay.yaml
  clang/test/ClangScanDeps/Inputs/vfsoverlay_cdb.json
  clang/test/ClangScanDeps/header_stat_before_open.m
  clang/test/ClangScanDeps/regular_cdb.cpp
  clang/test/ClangScanDeps/vfsoverlay.cpp
  clang/tools/clang-scan-deps/ClangScanDeps.cpp

Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -8,6 +8,7 @@
 
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Tooling/CommonOptionsParser.h"
+#include "clang/Tooling/DependencyScanning/DependencyScanningService.h"
 #include "clang/Tooling/DependencyScanning/DependencyScanningWorker.h"
 #include "clang/Tooling/JSONCompilationDatabase.h"
 #include "llvm/Support/InitLLVM.h"
@@ -45,9 +46,10 @@
   ///
   /// \param Compilations The reference to the compilation database that's
   /// used by the clang tool.
-  DependencyScanningTool(const tooling::CompilationDatabase ,
+  DependencyScanningTool(DependencyScanningService ,
+ const tooling::CompilationDatabase ,
  SharedStream , SharedStream )
-  : Compilations(Compilations), OS(OS), Errs(Errs) {}
+  : Worker(Service), Compilations(Compilations), OS(OS), Errs(Errs) {}
 
   /// Computes the dependencies for the given file and prints them out.
   ///
@@ -80,6 +82,20 @@
 
 llvm::cl::OptionCategory DependencyScannerCategory("Tool options");
 
+static llvm::cl::opt ScanMode(
+"mode",
+llvm::cl::desc("The preprocessing mode used to compute the dependencies"),
+llvm::cl::values(
+clEnumValN(ScanningMode::MinimizedSourcePreprocessing,
+   "preprocess-minimized-sources",
+   "The set of dependencies is computed by preprocessing the "
+   "source files that were minimized to only include the "
+   "contents that might affect the dependencies"),
+clEnumValN(ScanningMode::CanonicalPreprocessing, "preprocess",
+   "The set of dependencies is computed by preprocessing the "
+   "unmodified source files")),
+llvm::cl::init(ScanningMode::MinimizedSourcePreprocessing));
+
 llvm::cl::opt
 NumThreads("j", llvm::cl::Optional,
llvm::cl::desc("Number of worker threads to use (default: use "
@@ -136,12 +152,14 @@
   SharedStream Errs(llvm::errs());
   // Print out the dependency results to STDOUT by default.
   SharedStream DependencyOS(llvm::outs());
+
+  DependencyScanningService Service(ScanMode);
   unsigned NumWorkers =
   NumThreads == 0 ? llvm::hardware_concurrency() : NumThreads;
   std::vector> WorkerTools;
   for (unsigned I = 0; I < NumWorkers; ++I)
 WorkerTools.push_back(llvm::make_unique(
-*AdjustingCompilations, DependencyOS, Errs));
+Service, *AdjustingCompilations, DependencyOS, Errs));
 
   std::vector WorkerThreads;
   std::atomic HadErrors(false);
Index: clang/test/ClangScanDeps/vfsoverlay.cpp
===
--- /dev/null
+++ clang/test/ClangScanDeps/vfsoverlay.cpp
@@ -0,0 +1,17 @@
+// RUN: rm -rf %t.dir
+// RUN: rm -rf %t.cdb
+// RUN: mkdir -p %t.dir
+// RUN: cp %s %t.dir/vfsoverlay.cpp
+// RUN: sed -e "s|DIR|%/t.dir|g" %S/Inputs/vfsoverlay.yaml > %t.dir/vfsoverlay.yaml
+// RUN: mkdir %t.dir/Inputs
+// RUN: cp %S/Inputs/header.h %t.dir/Inputs/header.h
+// RUN: sed -e "s|DIR|%/t.dir|g" %S/Inputs/vfsoverlay_cdb.json > %t.cdb
+//
+// RUN: clang-scan-deps -compilation-database %t.cdb -j 1 | \
+// RUN:   FileCheck %s
+
+#include "not_real.h"
+
+// CHECK: clang-scan-deps dependency
+// CHECK-NEXT: vfsoverlay.cpp
+// CHECK-NEXT: Inputs{{/|\\}}header.h
Index: clang/test/ClangScanDeps/regular_cdb.cpp
===
--- clang/test/ClangScanDeps/regular_cdb.cpp
+++ 

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

[JF Bastien via Phabricator via cfe-commits]

jfb added inline comments.



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:5609
+def warn_mul_in_bool_context : Warning<
+  "'*' in bool context, maybe you mean '&&'?">,
+  InGroup;

xbolva00 wrote:
> jfb wrote:
> > aaron.ballman wrote:
> > > xbolva00 wrote:
> > > > aaron.ballman wrote:
> > > > > I would appreciate seeing some motivating examples for this case, 
> > > > > because it seems like the `&&` suggestion is misleading more often 
> > > > > than it's helpful in the current test cases.
> > > > > 
> > > > > Also, what is a "bool context"?
> > > > Bool context - places where we expect boolean expressions.
> > > > 
> > > > If you have idea for better terminology, I am happy to apply it.
> > > > 
> > > > Yeah, I will remove “&&” suggestion.. 
> > > I don't have a good recommendation for a replacement for "boolean 
> > > context", so I suppose we can leave it.
> > IMO it's clearer to say "assigning the result of a multiplication to a 
> > boolean variable always yields {true|false}"
> But it is very specific.. cannot be used for example here:
> 
> bool t() { return 0 * x; } 
> 
> In the place where the check is performed we know nothing whether expr is 
> assigned/returned/etc.
> 
> I don’t believe we have to produce message with such details.
All I'm saying is that "boolean context" ins't something people will understand.
Maybe "converting the result of a multiplication to a boolean always yields 
{true|false}"?



Comment at: test/SemaCXX/warn-int-in-bool-context.cpp:96
+
+  if (f == apple || orange) // expected-warning {{enum constant in boolean 
context}}
+return a;

xbolva00 wrote:
> jfb wrote:
> > xbolva00 wrote:
> > > xbolva00 wrote:
> > > > @aaron.ballman : In C (but not in C++ ugh?) mode we have: 'use of 
> > > > logical '||' with constant operand' here..
> > > > 
> > > > /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:18:
> > > >  warning: use of logical '||' with constant operand
> > > >   if (f == apple || orange) // expected-warning {{enum constant in 
> > > > boolean context}}
> > > >  ^  ~~
> > > > /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:18:
> > > >  note: use '|' for a bitwise operation
> > > >   if (f == apple || orange) // expected-warning {{enum constant in 
> > > > boolean context}}
> > > >  ^~
> > > >  |
> > > > /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:21:
> > > >  warning: enum constant in boolean context
> > > >   if (f == apple || orange) // expected-warning {{enum constant in 
> > > > boolean context}}
> > > > 
> > > > 
> > > > 
> > > > 
> > > What is your opinion here (^^) , @jfb ?
> > > 
> > > Thanks.
> > C, C++, ObjC, and ObjC++ should emit different diagnostics here. That being 
> > said, none of these diagnostics are particular easy to understand. I don't 
> > think we should ever say "boolean context" anywhere.
> So I will make this as it was - C++ only.
It'll work in the other languages though, right?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63082/new/

https://reviews.llvm.org/D63082



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

[PATCH] D65337: [clangd] Disallow extraction of expression-statements.

[Sam McCall via Phabricator via cfe-commits]

sammccall marked 6 inline comments as done.
sammccall added a comment.

In D65337#1604324 , @SureYeaah wrote:

> What was the bug in getCallExpr() ?


It could find calls where the DeclRef was an arbitrary subexpression of the 
callee, not exactly the callee (modulo implicit nodes).

It allowed extraction of `[[t]].bar(t.z)`, because it recognized `t` as a 
DeclRefExpr (maybe a function we're calling!) and then walked up the stack 
looking for a call.
It found one, and verified that the callee was the top of the stack (which was 
`[[t.bar]](t.z)` at that point).

In the previous version of the code, this was filtered out by one of the 
redundant checks, but after removing them the problem showed up. Once here I 
decided to remove the stack (only the top element was ever used) and reuse 
outerImplicit since we had it anyway and it avoided explicit looping.




Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:445
+
+  // FIXME: ban extracting the RHS of an assignment: `a = [[foo()]]`
   return true;

SureYeaah wrote:
> Check if parent is an assignment binaryoperator or a vardecl?
Right. I want to keep that out of this patch though: more tests, more changes 
to existing tests, more risk that it's not exactly what we want (e.g. 
extraction of *constants* to a named variable might be fine...)



Comment at: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp:461
+  // For function and member function DeclRefs, extract the whole call.
+  if (const DeclRefExpr *DeclRef = dyn_cast_or_null(SelectedExpr))
 TargetNode = getCallExpr(N);

SureYeaah wrote:
> Can we combine both these IFs and remove the unused assignment?
Done. Also removed the clobbering of TargetNode if there's no call, this 
decision is already covered by  eligibleForExtraction. And then cleaned up some 
widely-scoped variables and impossible conditions here.



Comment at: clang-tools-extra/clangd/unittests/TweakTests.cpp:329
   while(a < [[1]])
-[[a++]];
+a++;
   // do while

SureYeaah wrote:
> Change to a=[[1]];?
Sure, though the next patch may disallow this too :-)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65337/new/

https://reviews.llvm.org/D65337



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

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 marked 2 inline comments as done and an inline comment as not done.
xbolva00 added inline comments.



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:5609
+def warn_mul_in_bool_context : Warning<
+  "'*' in bool context, maybe you mean '&&'?">,
+  InGroup;

jfb wrote:
> aaron.ballman wrote:
> > xbolva00 wrote:
> > > aaron.ballman wrote:
> > > > I would appreciate seeing some motivating examples for this case, 
> > > > because it seems like the `&&` suggestion is misleading more often than 
> > > > it's helpful in the current test cases.
> > > > 
> > > > Also, what is a "bool context"?
> > > Bool context - places where we expect boolean expressions.
> > > 
> > > If you have idea for better terminology, I am happy to apply it.
> > > 
> > > Yeah, I will remove “&&” suggestion.. 
> > I don't have a good recommendation for a replacement for "boolean context", 
> > so I suppose we can leave it.
> IMO it's clearer to say "assigning the result of a multiplication to a 
> boolean variable always yields {true|false}"
But it is very specific.. cannot be used for example here:

bool t() { return 0 * x; } 

In the place where the check is performed we know nothing whether expr is 
assigned/returned/etc.

I don’t believe we have to produce message with such details.



Comment at: test/SemaCXX/warn-int-in-bool-context.cpp:96
+
+  if (f == apple || orange) // expected-warning {{enum constant in boolean 
context}}
+return a;

jfb wrote:
> xbolva00 wrote:
> > xbolva00 wrote:
> > > @aaron.ballman : In C (but not in C++ ugh?) mode we have: 'use of logical 
> > > '||' with constant operand' here..
> > > 
> > > /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:18:
> > >  warning: use of logical '||' with constant operand
> > >   if (f == apple || orange) // expected-warning {{enum constant in 
> > > boolean context}}
> > >  ^  ~~
> > > /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:18:
> > >  note: use '|' for a bitwise operation
> > >   if (f == apple || orange) // expected-warning {{enum constant in 
> > > boolean context}}
> > >  ^~
> > >  |
> > > /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:21:
> > >  warning: enum constant in boolean context
> > >   if (f == apple || orange) // expected-warning {{enum constant in 
> > > boolean context}}
> > > 
> > > 
> > > 
> > > 
> > What is your opinion here (^^) , @jfb ?
> > 
> > Thanks.
> C, C++, ObjC, and ObjC++ should emit different diagnostics here. That being 
> said, none of these diagnostics are particular easy to understand. I don't 
> think we should ever say "boolean context" anywhere.
So I will make this as it was - C++ only.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63082/new/

https://reviews.llvm.org/D63082



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

[PATCH] D65337: [clangd] Disallow extraction of expression-statements.

[Sam McCall via Phabricator via cfe-commits]

sammccall updated this revision to Diff 212433.
sammccall added a comment.

Add basic test for outerImplicit.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65337/new/

https://reviews.llvm.org/D65337

Files:
  clang-tools-extra/clangd/Selection.cpp
  clang-tools-extra/clangd/Selection.h
  clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
  clang-tools-extra/clangd/unittests/SelectionTests.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -326,7 +326,7 @@
 a = [[2]];
   // while
   while(a < [[1]])
-[[a++]];
+a = [[1]];
   // do while
   do
 a = [[1]];
@@ -370,11 +370,14 @@
   // lambda
   auto lamb = [&[[a]], &[[b]]](int r = [[1]]) {return 1;}
   // assigment
-  [[a = 5]];
-  [[a >>= 5]];
-  [[a *= 5]];
+  xyz([[a = 5]]);
+  xyz([[a *= 5]]);
   // Variable DeclRefExpr
   a = [[b]];
+  // statement expression
+  [[xyz()]];
+  while (a)
+[[++a]];
   // label statement
   goto label;
   label:
@@ -417,11 +420,11 @@
   // Macros
   {R"cpp(#define PLUS(x) x++
  void f(int a) {
-   PLUS([[1+a]]);
+   int y = PLUS([[1+a]]);
  })cpp",
R"cpp(#define PLUS(x) x++
  void f(int a) {
-   auto dummy = PLUS(1+a); dummy;
+   auto dummy = PLUS(1+a); int y = dummy;
  })cpp"},
   // ensure InsertionPoint isn't inside a macro
   {R"cpp(#define LOOP(x) while (1) {a = x;}
Index: clang-tools-extra/clangd/unittests/SelectionTests.cpp
===
--- clang-tools-extra/clangd/unittests/SelectionTests.cpp
+++ clang-tools-extra/clangd/unittests/SelectionTests.cpp
@@ -358,6 +358,8 @@
   EXPECT_EQ("CXXConstructExpr", nodeKind(Str->Parent->Parent));
   EXPECT_EQ(Str, >Parent->Parent->ignoreImplicit())
   << "Didn't unwrap " << nodeKind(>Parent->Parent->ignoreImplicit());
+
+  EXPECT_EQ("CXXConstructExpr", nodeKind(>outerImplicit()));
 }
 
 } // namespace
Index: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
@@ -368,32 +368,80 @@
   return Effect::applyEdit(Result);
 }
 
-// Find the CallExpr whose callee is an ancestor of the DeclRef
+// Find the CallExpr whose callee is the (possibly wrapped) DeclRef
 const SelectionTree::Node *getCallExpr(const SelectionTree::Node *DeclRef) {
-  // we maintain a stack of all exprs encountered while traversing the
-  // selectiontree because the callee of the callexpr can be an ancestor of the
-  // DeclRef. e.g. Callee can be an ImplicitCastExpr.
-  std::vector ExprStack;
-  for (auto *CurNode = DeclRef; CurNode; CurNode = CurNode->Parent) {
-const Expr *CurExpr = CurNode->ASTNode.get();
-if (const CallExpr *CallPar = CurNode->ASTNode.get()) {
-  // check whether the callee of the callexpr is present in Expr stack.
-  if (std::find(ExprStack.begin(), ExprStack.end(), CallPar->getCallee()) !=
-  ExprStack.end())
-return CurNode;
-  return nullptr;
-}
-ExprStack.push_back(CurExpr);
-  }
-  return nullptr;
+  const SelectionTree::Node  = DeclRef->outerImplicit();
+  const SelectionTree::Node *MaybeCall = MaybeCallee.Parent;
+  if (!MaybeCall)
+return nullptr;
+  const CallExpr *CE =
+  llvm::dyn_cast_or_null(MaybeCall->ASTNode.get());
+  if (!CE)
+return nullptr;
+  if (CE->getCallee() != MaybeCallee.ASTNode.get())
+return nullptr;
+  return MaybeCall;
 }
 
-// check if Expr can be assigned to a variable i.e. is non-void type
-bool canBeAssigned(const SelectionTree::Node *ExprNode) {
-  const clang::Expr *Expr = ExprNode->ASTNode.get();
-  if (const Type *ExprType = Expr->getType().getTypePtrOrNull())
-// FIXME: check if we need to cover any other types
-return !ExprType->isVoidType();
+// Returns true if Inner (which is a direct child of Outer) is appearing as
+// a statement rather than an expression whose value can be used.
+bool childExprIsStmt(const Stmt *Outer, const Expr *Inner) {
+  if (!Outer || !Inner)
+return false;
+  // Blacklist the most common places where an expr can appear but be unused.
+  if (llvm::isa(Outer))
+return true;
+  if (llvm::isa(Outer))
+return true;
+  // Control flow statements use condition etc, but not the body.
+  if (const auto* WS = llvm::dyn_cast(Outer))
+return Inner == WS->getBody();
+  if (const auto* DS = llvm::dyn_cast(Outer))
+ 

[PATCH] D65337: [clangd] Disallow extraction of expression-statements.

[Sam McCall via Phabricator via cfe-commits]

sammccall updated this revision to Diff 212432.
sammccall marked 2 inline comments as done.
sammccall added a comment.

Address review comments.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65337/new/

https://reviews.llvm.org/D65337

Files:
  clang-tools-extra/clangd/Selection.cpp
  clang-tools-extra/clangd/Selection.h
  clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -326,7 +326,7 @@
 a = [[2]];
   // while
   while(a < [[1]])
-[[a++]];
+a = [[1]];
   // do while
   do
 a = [[1]];
@@ -370,11 +370,14 @@
   // lambda
   auto lamb = [&[[a]], &[[b]]](int r = [[1]]) {return 1;}
   // assigment
-  [[a = 5]];
-  [[a >>= 5]];
-  [[a *= 5]];
+  xyz([[a = 5]]);
+  xyz([[a *= 5]]);
   // Variable DeclRefExpr
   a = [[b]];
+  // statement expression
+  [[xyz()]];
+  while (a)
+[[++a]];
   // label statement
   goto label;
   label:
@@ -417,11 +420,11 @@
   // Macros
   {R"cpp(#define PLUS(x) x++
  void f(int a) {
-   PLUS([[1+a]]);
+   int y = PLUS([[1+a]]);
  })cpp",
R"cpp(#define PLUS(x) x++
  void f(int a) {
-   auto dummy = PLUS(1+a); dummy;
+   auto dummy = PLUS(1+a); int y = dummy;
  })cpp"},
   // ensure InsertionPoint isn't inside a macro
   {R"cpp(#define LOOP(x) while (1) {a = x;}
Index: clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
@@ -368,32 +368,80 @@
   return Effect::applyEdit(Result);
 }
 
-// Find the CallExpr whose callee is an ancestor of the DeclRef
+// Find the CallExpr whose callee is the (possibly wrapped) DeclRef
 const SelectionTree::Node *getCallExpr(const SelectionTree::Node *DeclRef) {
-  // we maintain a stack of all exprs encountered while traversing the
-  // selectiontree because the callee of the callexpr can be an ancestor of the
-  // DeclRef. e.g. Callee can be an ImplicitCastExpr.
-  std::vector ExprStack;
-  for (auto *CurNode = DeclRef; CurNode; CurNode = CurNode->Parent) {
-const Expr *CurExpr = CurNode->ASTNode.get();
-if (const CallExpr *CallPar = CurNode->ASTNode.get()) {
-  // check whether the callee of the callexpr is present in Expr stack.
-  if (std::find(ExprStack.begin(), ExprStack.end(), CallPar->getCallee()) !=
-  ExprStack.end())
-return CurNode;
-  return nullptr;
-}
-ExprStack.push_back(CurExpr);
-  }
-  return nullptr;
+  const SelectionTree::Node  = DeclRef->outerImplicit();
+  const SelectionTree::Node *MaybeCall = MaybeCallee.Parent;
+  if (!MaybeCall)
+return nullptr;
+  const CallExpr *CE =
+  llvm::dyn_cast_or_null(MaybeCall->ASTNode.get());
+  if (!CE)
+return nullptr;
+  if (CE->getCallee() != MaybeCallee.ASTNode.get())
+return nullptr;
+  return MaybeCall;
 }
 
-// check if Expr can be assigned to a variable i.e. is non-void type
-bool canBeAssigned(const SelectionTree::Node *ExprNode) {
-  const clang::Expr *Expr = ExprNode->ASTNode.get();
-  if (const Type *ExprType = Expr->getType().getTypePtrOrNull())
-// FIXME: check if we need to cover any other types
-return !ExprType->isVoidType();
+// Returns true if Inner (which is a direct child of Outer) is appearing as
+// a statement rather than an expression whose value can be used.
+bool childExprIsStmt(const Stmt *Outer, const Expr *Inner) {
+  if (!Outer || !Inner)
+return false;
+  // Blacklist the most common places where an expr can appear but be unused.
+  if (llvm::isa(Outer))
+return true;
+  if (llvm::isa(Outer))
+return true;
+  // Control flow statements use condition etc, but not the body.
+  if (const auto* WS = llvm::dyn_cast(Outer))
+return Inner == WS->getBody();
+  if (const auto* DS = llvm::dyn_cast(Outer))
+return Inner == DS->getBody();
+  if (const auto* FS = llvm::dyn_cast(Outer))
+return Inner == FS->getBody();
+  if (const auto* FS = llvm::dyn_cast(Outer))
+return Inner == FS->getBody();
+  if (const auto* IS = llvm::dyn_cast(Outer))
+return Inner == IS->getThen() || Inner == IS->getElse();
+  // Assume all other cases may be actual expressions.
+  // This includes the important case of subexpressions (where Outer is Expr).
+  return false;
+}
+
+// check if N can and should be extracted (e.g. is not void-typed).
+bool 

[PATCH] D65050: [SemaTemplate] Mark a function type as dependent when its parameter list contains pack expansion

[S. B. Tam via Phabricator via cfe-commits]

cpplearner added a comment.

In D65050#1606022 , @aaron.ballman 
wrote:

> The noexcept specifier is part of the type these days, is that also handled 
> properly?


I believe that it's properly handled in this section of 
`FunctionProtoType::FunctionProtoType`:

  // If this is a canonical type, and its exception specification is dependent,
  // then it's a dependent type. This only happens in C++17 onwards.
  if (isCanonicalUnqualified()) {
if (getExceptionSpecType() == EST_Dynamic ||
getExceptionSpecType() == EST_DependentNoexcept) {
  assert(hasDependentExceptionSpec() && "type should not be canonical");
  setDependent();
}
  } else if (getCanonicalTypeInternal()->isDependentType()) {
// Ask our canonical type whether our exception specification was dependent.
setDependent();
  }


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65050/new/

https://reviews.llvm.org/D65050



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

[clang-tools-extra] r367354 - [clangd][NFC] Typo in comment

[Jan Korous via cfe-commits]

Author: jkorous
Date: Tue Jul 30 13:39:39 2019
New Revision: 367354

URL: http://llvm.org/viewvc/llvm-project?rev=367354=rev
Log:
[clangd][NFC] Typo in comment

Modified:
clang-tools-extra/trunk/clangd/Headers.h

Modified: clang-tools-extra/trunk/clangd/Headers.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Headers.h?rev=367354=367353=367354=diff
==
--- clang-tools-extra/trunk/clangd/Headers.h (original)
+++ clang-tools-extra/trunk/clangd/Headers.h Tue Jul 30 13:39:39 2019
@@ -125,7 +125,7 @@ public:
 private:
   // Identifying files in a way that persists from preamble build to subsequent
   // builds is surprisingly hard. FileID is unavailable in 
InclusionDirective(),
-  // and RealPathName and UniqueID are not preseved in the preamble.
+  // and RealPathName and UniqueID are not preserved in the preamble.
   // We use the FileEntry::Name, which is stable, interned into a "file index".
   // The paths we want to expose are the RealPathName, so store those too.
   std::vector RealPathNames; // In file index order.


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

[PATCH] D65184: [Sema] Thread Safety Analysis: Fix negative capability's LockKind representation.

[Aaron Puchert via Phabricator via cfe-commits]

aaronpuchert added inline comments.



Comment at: clang/test/SemaCXX/thread-safety-annotations.h:47
+// Enable thread safety attributes only with clang.
+// The attributes can be safely erased when compiling with other compilers.
+#if defined(__clang__) && (!defined(SWIG))

ziangwan wrote:
> aaronpuchert wrote:
> > ziangwan wrote:
> > > nickdesaulniers wrote:
> > > > Is this test suite run with other compilers? If not, I think we can 
> > > > remove the case?
> > > Yeah, you are right. I just copied the header definitions from clang 
> > > thread safety analysis doc.
> > Why aren't you using the existing macros? The idea was to run the tests 
> > with both old and new terminology, and for the time being, I think we 
> > should maintain both.
> There are already tests on existing macros. I want to introduce tests about 
> the new macros as well.
There are no old and new macros, there are only old and new **attributes**. The 
existing macros use both sets of attributes, depending on the value of 
`USE_CAPABILITY` with which the tests are run. Using other macro names is just 
window dressing.



Comment at: clang/test/SemaCXX/warn-thread-safety-negative.cpp:135-140
+  if (condition) {
+assertNotHeld(); // expected-warning {{mutex '!mu' is acquired exclusively 
and shared in the same scope}}
+  } else {
+mu.Lock();
+mu.Unlock(); // expected-warning {{the other acquisition of mutex '!mu' is 
here}}
+  }

ziangwan wrote:
> aaronpuchert wrote:
> > ziangwan wrote:
> > > aaronpuchert wrote:
> > > > Why would I want these warnings here? This code seems fine to me.
> > > > 
> > > > However, I don't see why we don't get `acquiring mutex 'mu' requires 
> > > > negative capability '!mu'` at line 138, or does that disappear because 
> > > > of the assertion?
> > > Showing `acquiring mutex 'mu' requires negative capability '!mu'` is not 
> > > in the scope of this patch. Please notice thread safety analysis is still 
> > > under development.
> > > 
> > > The reason is that, in one path we have `ASSERT_SHARED_CAPABILITY(!mu)`, 
> > > and in the other path we have `RELEASE(mu)`. The assertion leads to 
> > > negative shared capability but the release leads to negative exclusive 
> > > capability. A merge of the two capabilities (merging "I am not trying to 
> > > read" versus "I am not trying to write") leads to a warning.
> > > 
> > > Without my patch, clang will issue a warning for the merge point in 
> > > test1() but not the merge point in test2().
> > But `ASSERT_SHARED_CAPABILITY(!mu)` implies that we also don't have an 
> > exclusive lock (an exclusive lock is stronger than a shared lock), and 
> > `RELEASE(mu)` without `ACQUIRE_SHARED(mu)` implies that we have neither a 
> > shared nor an exclusive lock as well.
> > 
> > In the end, I have the same question as above: Why do we want two kinds of 
> > negative capabilities? Isn't the idea that negative capabilities express 
> > the lock not being held at all?
> The problem is: by the current state of the thread safety analysis, 
> ASSERT_SHARED_CAPABILTIY(!mu) introduces a shared negative capability, 
> whereas RELEASE(mu) and RELEASE_SHARED(mu) introduce an exclusive negative 
> capability, and UNLOCK_FUNCTION(mu) introduces a generic negative capability. 
> All three are different. At merge points, warnings will be issued if 
> different types of negative capability are merged. The current thread safety 
> analysis produces bogus false positive in our code base.
> 
> The solution I propose is that we should at least make RELEASE_SHARED(mu) 
> produce a shared negative capability.
> 
> Regarding why we should have types for negative capability, thinking about 
> "exclusive !mu" in a reader-writer lock situation, which means "I am not 
> trying to write". However, the code can still read. In other words, 
> "exclusive !mu" does not imply "shared !mu", and the code can still hold the 
> lock in shared state. Without the types of negative capability, we wouldn't 
> be able to express the situation described above.
I'm not doubting that there is a bug, but I don't think this is the right 
solution.

> ASSERT_SHARED_CAPABILTIY(!mu) introduces a shared negative capability
We should disallow using "shared" attributes with negative capabilities, and 
I'm surprised this isn't already the case.

> whereas RELEASE(mu) and RELEASE_SHARED(mu) introduce an exclusive negative 
> capability [...] The solution I propose is that we should at least make 
> RELEASE_SHARED(mu) produce a shared negative capability.
Clearly both leave `mu` in the same (unlocked) state, so why distinguish 
between them? After the lock is released, whichever mode it has been in before 
is ancient history. We want to track the **current** state of the lock.

> Regarding why we should have types for negative capability, thinking about 
> "exclusive !mu" in a reader-writer lock situation, which means "I am not 
> trying to write". 

r367353 - Revert "[NFC][clang] Refactor getCompilationPhases()+Types.def step 3."

[Sam McCall via cfe-commits]

Author: sammccall
Date: Tue Jul 30 13:38:11 2019
New Revision: 367353

URL: http://llvm.org/viewvc/llvm-project?rev=367353=rev
Log:
Revert "[NFC][clang] Refactor getCompilationPhases()+Types.def step 3."

This reverts commit d2254dbf21a3243233b75294ef901086199df1b9.
This (unintentionally?) changed behavior, disallowing e.g. -x 
objective-c++-header

Modified:
cfe/trunk/include/clang/Driver/Types.def
cfe/trunk/include/clang/Driver/Types.h
cfe/trunk/lib/Driver/Types.cpp

Modified: cfe/trunk/include/clang/Driver/Types.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Types.def?rev=367353=367352=367353=diff
==
--- cfe/trunk/include/clang/Driver/Types.def (original)
+++ cfe/trunk/include/clang/Driver/Types.def Tue Jul 30 13:38:11 2019
@@ -29,73 +29,76 @@
 // The fourth value is the suffix to use when creating temporary files
 // of this type, or null if unspecified.
 
-// The final value is a variadic list of phases for each type. Eventually the
+// The fifth value is a string containing option flags. Valid values:
+//  u - The type can be user specified (with -x).
+
+// The sixth value is a variadic list of phases for each type. Eventually the
 // options flag string will be replaced with this variadic list.
 // Most of the options in Flags have been removed in favor of subsuming their
 // meaning from the phases list.
 
 // C family source language (with and without preprocessing).
-TYPE("cpp-output",   PP_C, INVALID, "i",  
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("c",C,PP_C,"c",  
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("cl",   CL,   PP_C,"cl", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("cuda-cpp-output",  PP_CUDA,  INVALID, "cui",
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cuda", CUDA, PP_CUDA, "cu", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("cuda", CUDA_DEVICE,  PP_CUDA, "cu", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("hip-cpp-output",   PP_HIP,   INVALID, "cui",
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("hip",  HIP,  PP_HIP,  "cu", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("hip",  HIP_DEVICE,   PP_HIP,  "cu", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("objective-c-cpp-output",   PP_ObjC,  INVALID, "mi", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objc-cpp-output",  PP_ObjC_Alias, INVALID,"mi", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objective-c",  ObjC, PP_ObjC, "m",  
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("c++-cpp-output",   PP_CXX,   INVALID, "ii", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("c++",  CXX,  PP_CXX,  "cpp",
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("objective-c++-cpp-output", PP_ObjCXX,INVALID, "mii",
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objc++-cpp-output",PP_ObjCXX_Alias, INVALID,  "mii",
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objective-c++",ObjCXX,   PP_ObjCXX,   "mm", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("renderscript", RenderScript, PP_C,"rs", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
+TYPE("cpp-output",   PP_C, INVALID, "i", "u", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
+TYPE("c",C,PP_C,"c", "u", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
+TYPE("cl",   CL,   PP_C,"cl","u", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
+TYPE("cuda-cpp-output",  PP_CUDA,  INVALID, "cui",   "u", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
+TYPE("cuda", CUDA, PP_CUDA, "cu","u", 

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

[JF Bastien via Phabricator via cfe-commits]

jfb added inline comments.



Comment at: test/Sema/warn-int-in-bool-context.c:26
+  r = a << 7;   // expected-warning {{'<<' in boolean context; did you mean 
'<'?}}
+  r = ONE << b; // expected-warning {{'<<' in boolean context; did you mean 
'<'?}}
+

xbolva00 wrote:
> jfb wrote:
> > xbolva00 wrote:
> > > jfb wrote:
> > > > I'm not sure the "did you mean" part is helpful. Do we have data 
> > > > showing that this is what people actually mean?
> > > No, no data, just what GCC suggests.
> > I would drop it without knowing that it's actually what people usually mean.
> Leave just “<<' in boolean context“ seems not ideal for me as a diag message. 
> 
> Or is it ok for you?
As [I said above](https://reviews.llvm.org/D63082#inline-585063), I don't think 
you should say "boolean context". It's not something people will understand. 
Here we're assigning to a boolean, say that.



Comment at: test/Sema/warn-unreachable.c:147
+  // expected-warning@+1 {{'*' in boolean context, the expression will always 
evaluate to 'false'}}
   if (0 * x) calledFun(); // expected-warning {{will never be executed}}
 }

xbolva00 wrote:
> jfb wrote:
> > xbolva00 wrote:
> > > jfb wrote:
> > > > It seems like here the "will never be executed" warning is more useful. 
> > > > Do we want to emit both?
> > > Useful but -Wunreachable-code is disabled by default (not part of -Wall).
> > I don't think we want two diagnostics when one will do.
> I will drop mul handling then..
No, my feedback isn't about multiplication in particular. My feedback is that 
it's not useful to have both warnings. We should just emit a single warning, 
and it should be maximally helpful. Here it's useful to say that `calledFunc() 
will never be executed because 0*x is always false`.



Comment at: test/SemaCXX/warn-int-in-bool-context.cpp:96
+
+  if (f == apple || orange) // expected-warning {{enum constant in boolean 
context}}
+return a;

xbolva00 wrote:
> xbolva00 wrote:
> > @aaron.ballman : In C (but not in C++ ugh?) mode we have: 'use of logical 
> > '||' with constant operand' here..
> > 
> > /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:18:
> >  warning: use of logical '||' with constant operand
> >   if (f == apple || orange) // expected-warning {{enum constant in boolean 
> > context}}
> >  ^  ~~
> > /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:18:
> >  note: use '|' for a bitwise operation
> >   if (f == apple || orange) // expected-warning {{enum constant in boolean 
> > context}}
> >  ^~
> >  |
> > /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:21:
> >  warning: enum constant in boolean context
> >   if (f == apple || orange) // expected-warning {{enum constant in boolean 
> > context}}
> > 
> > 
> > 
> > 
> What is your opinion here (^^) , @jfb ?
> 
> Thanks.
C, C++, ObjC, and ObjC++ should emit different diagnostics here. That being 
said, none of these diagnostics are particular easy to understand. I don't 
think we should ever say "boolean context" anywhere.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63082/new/

https://reviews.llvm.org/D63082



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

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 marked 4 inline comments as done and an inline comment as not done.
xbolva00 added inline comments.



Comment at: test/Sema/warn-int-in-bool-context.c:26
+  r = a << 7;   // expected-warning {{'<<' in boolean context; did you mean 
'<'?}}
+  r = ONE << b; // expected-warning {{'<<' in boolean context; did you mean 
'<'?}}
+

jfb wrote:
> xbolva00 wrote:
> > jfb wrote:
> > > I'm not sure the "did you mean" part is helpful. Do we have data showing 
> > > that this is what people actually mean?
> > No, no data, just what GCC suggests.
> I would drop it without knowing that it's actually what people usually mean.
Leave just “<<' in boolean context“ seems not ideal for me as a diag message. 

Or is it ok for you?



Comment at: test/Sema/warn-int-in-bool-context.c:33
+  r = a ? 3 : -2;
+  r = a ? 0 : TWO; // expected-warning {{'?:' with integer constants in 
boolean context}}
+  r = a ? 3 : ONE; // expected-warning {{'?:' with integer constants in 
boolean context, the expression will always evaluate to 'true'}}

jfb wrote:
> xbolva00 wrote:
> > jfb wrote:
> > > Why does this one warn? It doesn't always yield the same result.
> > GCC warns here..
> Our goal isn't to achieve GCC warning parity. I like warnings that fire when 
> it's extremely likely a bug. Here the diagnostic seems to be inconsistent 
> with other instances of this diagnostic. Maybe this should warn, but then 
> other cases should as well (such as `a?3:-2` above). Or maybe it shouldn't 
> warn at all.
I will drop it and leave only 
“warn_integer_constants_in_conditional_always_true” diag.



Comment at: test/Sema/warn-unreachable.c:147
+  // expected-warning@+1 {{'*' in boolean context, the expression will always 
evaluate to 'false'}}
   if (0 * x) calledFun(); // expected-warning {{will never be executed}}
 }

jfb wrote:
> xbolva00 wrote:
> > jfb wrote:
> > > It seems like here the "will never be executed" warning is more useful. 
> > > Do we want to emit both?
> > Useful but -Wunreachable-code is disabled by default (not part of -Wall).
> I don't think we want two diagnostics when one will do.
I will drop mul handling then..



Comment at: test/SemaCXX/warn-int-in-bool-context.cpp:96
+
+  if (f == apple || orange) // expected-warning {{enum constant in boolean 
context}}
+return a;

xbolva00 wrote:
> @aaron.ballman : In C (but not in C++ ugh?) mode we have: 'use of logical 
> '||' with constant operand' here..
> 
> /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:18:
>  warning: use of logical '||' with constant operand
>   if (f == apple || orange) // expected-warning {{enum constant in boolean 
> context}}
>  ^  ~~
> /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:18:
>  note: use '|' for a bitwise operation
>   if (f == apple || orange) // expected-warning {{enum constant in boolean 
> context}}
>  ^~
>  |
> /home/xbolva00/LLVM/llvm/tools/clang/test/SemaCXX/warn-int-in-bool-context.cpp:106:21:
>  warning: enum constant in boolean context
>   if (f == apple || orange) // expected-warning {{enum constant in boolean 
> context}}
> 
> 
> 
> 
What is your opinion here (^^) , @jfb ?

Thanks.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63082/new/

https://reviews.llvm.org/D63082



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

[PATCH] D64488: [Driver] Support -fsanitize=function on Solaris/x86

[Rainer Orth via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367351: [Driver] Support -fsanitize=function on Solaris/x86 
(authored by ro, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D64488?vs=212393=212420#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64488/new/

https://reviews.llvm.org/D64488

Files:
  cfe/trunk/lib/Driver/ToolChains/Solaris.cpp
  cfe/trunk/test/Driver/fsanitize.c


Index: cfe/trunk/test/Driver/fsanitize.c
===
--- cfe/trunk/test/Driver/fsanitize.c
+++ cfe/trunk/test/Driver/fsanitize.c
@@ -727,6 +727,9 @@
 // RUN: %clang -target x86_64--netbsd -fsanitize=scudo %s -### 2>&1 | 
FileCheck %s -check-prefix=SCUDO-NETBSD
 // SCUDO-NETBSD: "-fsanitize=scudo"
 
+// RUN: %clang -target i386--solaris -fsanitize=function %s -### 2>&1 | 
FileCheck %s -check-prefix=FUNCTION-SOLARIS
+// RUN: %clang -target x86_64--solaris -fsanitize=function %s -### 2>&1 | 
FileCheck %s -check-prefix=FUNCTION-SOLARIS
+// FUNCTION-SOLARIS: "-fsanitize=function"
 
 
 // RUN: %clang -target x86_64-scei-ps4 -fsanitize=function 
-fsanitize=undefined %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-FSAN-UBSAN-PS4
Index: cfe/trunk/lib/Driver/ToolChains/Solaris.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Solaris.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Solaris.cpp
@@ -177,6 +177,7 @@
 
 SanitizerMask Solaris::getSupportedSanitizers() const {
   const bool IsX86 = getTriple().getArch() == llvm::Triple::x86;
+  const bool IsX86_64 = getTriple().getArch() == llvm::Triple::x86_64;
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
   // FIXME: Omit X86_64 until 64-bit support is figured out.
   if (IsX86) {
@@ -184,6 +185,8 @@
 Res |= SanitizerKind::PointerCompare;
 Res |= SanitizerKind::PointerSubtract;
   }
+  if (IsX86 || IsX86_64)
+Res |= SanitizerKind::Function;
   Res |= SanitizerKind::Vptr;
   return Res;
 }


Index: cfe/trunk/test/Driver/fsanitize.c
===
--- cfe/trunk/test/Driver/fsanitize.c
+++ cfe/trunk/test/Driver/fsanitize.c
@@ -727,6 +727,9 @@
 // RUN: %clang -target x86_64--netbsd -fsanitize=scudo %s -### 2>&1 | FileCheck %s -check-prefix=SCUDO-NETBSD
 // SCUDO-NETBSD: "-fsanitize=scudo"
 
+// RUN: %clang -target i386--solaris -fsanitize=function %s -### 2>&1 | FileCheck %s -check-prefix=FUNCTION-SOLARIS
+// RUN: %clang -target x86_64--solaris -fsanitize=function %s -### 2>&1 | FileCheck %s -check-prefix=FUNCTION-SOLARIS
+// FUNCTION-SOLARIS: "-fsanitize=function"
 
 
 // RUN: %clang -target x86_64-scei-ps4 -fsanitize=function -fsanitize=undefined %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-FSAN-UBSAN-PS4
Index: cfe/trunk/lib/Driver/ToolChains/Solaris.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Solaris.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Solaris.cpp
@@ -177,6 +177,7 @@
 
 SanitizerMask Solaris::getSupportedSanitizers() const {
   const bool IsX86 = getTriple().getArch() == llvm::Triple::x86;
+  const bool IsX86_64 = getTriple().getArch() == llvm::Triple::x86_64;
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
   // FIXME: Omit X86_64 until 64-bit support is figured out.
   if (IsX86) {
@@ -184,6 +185,8 @@
 Res |= SanitizerKind::PointerCompare;
 Res |= SanitizerKind::PointerSubtract;
   }
+  if (IsX86 || IsX86_64)
+Res |= SanitizerKind::Function;
   Res |= SanitizerKind::Vptr;
   return Res;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r367351 - [Driver] Support -fsanitize=function on Solaris/x86

[Rainer Orth via cfe-commits]

Author: ro
Date: Tue Jul 30 13:04:53 2019
New Revision: 367351

URL: http://llvm.org/viewvc/llvm-project?rev=367351=rev
Log:
[Driver] Support -fsanitize=function on Solaris/x86

UBSan-Standalone-x86_64 :: TestCases/TypeCheck/Function/function.cpp currently
FAILs on Solaris/x86_64:

  clang-9: error: unsupported option '-fsanitize=function' for target 
'x86_64-pc-solaris2.11'

AFAICS, there's nothing more to do then enable that sanitizer in the driver 
(for x86 only),
which is what this patch does, together with updating another testcase.

Tested on x86_64-pc-solaris2.11.

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

Modified:
cfe/trunk/lib/Driver/ToolChains/Solaris.cpp
cfe/trunk/test/Driver/fsanitize.c

Modified: cfe/trunk/lib/Driver/ToolChains/Solaris.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Solaris.cpp?rev=367351=367350=367351=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Solaris.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Solaris.cpp Tue Jul 30 13:04:53 2019
@@ -177,6 +177,7 @@ Solaris::Solaris(const Driver , const
 
 SanitizerMask Solaris::getSupportedSanitizers() const {
   const bool IsX86 = getTriple().getArch() == llvm::Triple::x86;
+  const bool IsX86_64 = getTriple().getArch() == llvm::Triple::x86_64;
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
   // FIXME: Omit X86_64 until 64-bit support is figured out.
   if (IsX86) {
@@ -184,6 +185,8 @@ SanitizerMask Solaris::getSupportedSanit
 Res |= SanitizerKind::PointerCompare;
 Res |= SanitizerKind::PointerSubtract;
   }
+  if (IsX86 || IsX86_64)
+Res |= SanitizerKind::Function;
   Res |= SanitizerKind::Vptr;
   return Res;
 }

Modified: cfe/trunk/test/Driver/fsanitize.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/fsanitize.c?rev=367351=367350=367351=diff
==
--- cfe/trunk/test/Driver/fsanitize.c (original)
+++ cfe/trunk/test/Driver/fsanitize.c Tue Jul 30 13:04:53 2019
@@ -727,6 +727,9 @@
 // RUN: %clang -target x86_64--netbsd -fsanitize=scudo %s -### 2>&1 | 
FileCheck %s -check-prefix=SCUDO-NETBSD
 // SCUDO-NETBSD: "-fsanitize=scudo"
 
+// RUN: %clang -target i386--solaris -fsanitize=function %s -### 2>&1 | 
FileCheck %s -check-prefix=FUNCTION-SOLARIS
+// RUN: %clang -target x86_64--solaris -fsanitize=function %s -### 2>&1 | 
FileCheck %s -check-prefix=FUNCTION-SOLARIS
+// FUNCTION-SOLARIS: "-fsanitize=function"
 
 
 // RUN: %clang -target x86_64-scei-ps4 -fsanitize=function 
-fsanitize=undefined %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-FSAN-UBSAN-PS4


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

[PATCH] D55895: NFC: simplify Darwin environment handling

[JF Bastien via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG42c9f3c9116c: [NFC] simplify Darwin environment handling 
(authored by jfb).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55895/new/

https://reviews.llvm.org/D55895

Files:
  clang/lib/Driver/ToolChains/Darwin.cpp


Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -1480,22 +1480,6 @@
   Targets[I.index()] = Env;
   }
 
-  // Do not allow conflicts with the watchOS target.
-  if (!Targets[Darwin::WatchOS].empty() &&
-  (!Targets[Darwin::IPhoneOS].empty() || !Targets[Darwin::TvOS].empty())) {
-TheDriver.Diag(diag::err_drv_conflicting_deployment_targets)
-<< "WATCHOS_DEPLOYMENT_TARGET"
-<< (!Targets[Darwin::IPhoneOS].empty() ? "IPHONEOS_DEPLOYMENT_TARGET"
-   : "TVOS_DEPLOYMENT_TARGET");
-  }
-
-  // Do not allow conflicts with the tvOS target.
-  if (!Targets[Darwin::TvOS].empty() && !Targets[Darwin::IPhoneOS].empty()) {
-TheDriver.Diag(diag::err_drv_conflicting_deployment_targets)
-<< "TVOS_DEPLOYMENT_TARGET"
-<< "IPHONEOS_DEPLOYMENT_TARGET";
-  }
-
   // Allow conflicts among OSX and iOS for historical reasons, but choose the
   // default platform.
   if (!Targets[Darwin::MacOS].empty() &&
@@ -1508,6 +1492,18 @@
 else
   Targets[Darwin::IPhoneOS] = Targets[Darwin::WatchOS] =
   Targets[Darwin::TvOS] = "";
+  } else {
+// Don't allow conflicts in any other platform.
+int FirstTarget = llvm::array_lengthof(Targets);
+for (int I = 0; I != llvm::array_lengthof(Targets); ++I) {
+  if (Targets[I].empty())
+continue;
+  if (FirstTarget == llvm::array_lengthof(Targets))
+FirstTarget = I;
+  else
+TheDriver.Diag(diag::err_drv_conflicting_deployment_targets)
+<< Targets[FirstTarget] << Targets[I];
+}
   }
 
   for (const auto  : llvm::enumerate(llvm::makeArrayRef(Targets))) {


Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -1480,22 +1480,6 @@
   Targets[I.index()] = Env;
   }
 
-  // Do not allow conflicts with the watchOS target.
-  if (!Targets[Darwin::WatchOS].empty() &&
-  (!Targets[Darwin::IPhoneOS].empty() || !Targets[Darwin::TvOS].empty())) {
-TheDriver.Diag(diag::err_drv_conflicting_deployment_targets)
-<< "WATCHOS_DEPLOYMENT_TARGET"
-<< (!Targets[Darwin::IPhoneOS].empty() ? "IPHONEOS_DEPLOYMENT_TARGET"
-   : "TVOS_DEPLOYMENT_TARGET");
-  }
-
-  // Do not allow conflicts with the tvOS target.
-  if (!Targets[Darwin::TvOS].empty() && !Targets[Darwin::IPhoneOS].empty()) {
-TheDriver.Diag(diag::err_drv_conflicting_deployment_targets)
-<< "TVOS_DEPLOYMENT_TARGET"
-<< "IPHONEOS_DEPLOYMENT_TARGET";
-  }
-
   // Allow conflicts among OSX and iOS for historical reasons, but choose the
   // default platform.
   if (!Targets[Darwin::MacOS].empty() &&
@@ -1508,6 +1492,18 @@
 else
   Targets[Darwin::IPhoneOS] = Targets[Darwin::WatchOS] =
   Targets[Darwin::TvOS] = "";
+  } else {
+// Don't allow conflicts in any other platform.
+int FirstTarget = llvm::array_lengthof(Targets);
+for (int I = 0; I != llvm::array_lengthof(Targets); ++I) {
+  if (Targets[I].empty())
+continue;
+  if (FirstTarget == llvm::array_lengthof(Targets))
+FirstTarget = I;
+  else
+TheDriver.Diag(diag::err_drv_conflicting_deployment_targets)
+<< Targets[FirstTarget] << Targets[I];
+}
   }
 
   for (const auto  : llvm::enumerate(llvm::makeArrayRef(Targets))) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D55895: NFC: simplify Darwin environment handling

[JF Bastien via Phabricator via cfe-commits]

jfb updated this revision to Diff 212417.
jfb added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55895/new/

https://reviews.llvm.org/D55895

Files:
  clang/lib/Driver/ToolChains/Darwin.cpp


Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -1480,22 +1480,6 @@
   Targets[I.index()] = Env;
   }
 
-  // Do not allow conflicts with the watchOS target.
-  if (!Targets[Darwin::WatchOS].empty() &&
-  (!Targets[Darwin::IPhoneOS].empty() || !Targets[Darwin::TvOS].empty())) {
-TheDriver.Diag(diag::err_drv_conflicting_deployment_targets)
-<< "WATCHOS_DEPLOYMENT_TARGET"
-<< (!Targets[Darwin::IPhoneOS].empty() ? "IPHONEOS_DEPLOYMENT_TARGET"
-   : "TVOS_DEPLOYMENT_TARGET");
-  }
-
-  // Do not allow conflicts with the tvOS target.
-  if (!Targets[Darwin::TvOS].empty() && !Targets[Darwin::IPhoneOS].empty()) {
-TheDriver.Diag(diag::err_drv_conflicting_deployment_targets)
-<< "TVOS_DEPLOYMENT_TARGET"
-<< "IPHONEOS_DEPLOYMENT_TARGET";
-  }
-
   // Allow conflicts among OSX and iOS for historical reasons, but choose the
   // default platform.
   if (!Targets[Darwin::MacOS].empty() &&
@@ -1508,6 +1492,18 @@
 else
   Targets[Darwin::IPhoneOS] = Targets[Darwin::WatchOS] =
   Targets[Darwin::TvOS] = "";
+  } else {
+// Don't allow conflicts in any other platform.
+int FirstTarget = llvm::array_lengthof(Targets);
+for (int I = 0; I != llvm::array_lengthof(Targets); ++I) {
+  if (Targets[I].empty())
+continue;
+  if (FirstTarget == llvm::array_lengthof(Targets))
+FirstTarget = I;
+  else
+TheDriver.Diag(diag::err_drv_conflicting_deployment_targets)
+<< Targets[FirstTarget] << Targets[I];
+}
   }
 
   for (const auto  : llvm::enumerate(llvm::makeArrayRef(Targets))) {


Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -1480,22 +1480,6 @@
   Targets[I.index()] = Env;
   }
 
-  // Do not allow conflicts with the watchOS target.
-  if (!Targets[Darwin::WatchOS].empty() &&
-  (!Targets[Darwin::IPhoneOS].empty() || !Targets[Darwin::TvOS].empty())) {
-TheDriver.Diag(diag::err_drv_conflicting_deployment_targets)
-<< "WATCHOS_DEPLOYMENT_TARGET"
-<< (!Targets[Darwin::IPhoneOS].empty() ? "IPHONEOS_DEPLOYMENT_TARGET"
-   : "TVOS_DEPLOYMENT_TARGET");
-  }
-
-  // Do not allow conflicts with the tvOS target.
-  if (!Targets[Darwin::TvOS].empty() && !Targets[Darwin::IPhoneOS].empty()) {
-TheDriver.Diag(diag::err_drv_conflicting_deployment_targets)
-<< "TVOS_DEPLOYMENT_TARGET"
-<< "IPHONEOS_DEPLOYMENT_TARGET";
-  }
-
   // Allow conflicts among OSX and iOS for historical reasons, but choose the
   // default platform.
   if (!Targets[Darwin::MacOS].empty() &&
@@ -1508,6 +1492,18 @@
 else
   Targets[Darwin::IPhoneOS] = Targets[Darwin::WatchOS] =
   Targets[Darwin::TvOS] = "";
+  } else {
+// Don't allow conflicts in any other platform.
+int FirstTarget = llvm::array_lengthof(Targets);
+for (int I = 0; I != llvm::array_lengthof(Targets); ++I) {
+  if (Targets[I].empty())
+continue;
+  if (FirstTarget == llvm::array_lengthof(Targets))
+FirstTarget = I;
+  else
+TheDriver.Diag(diag::err_drv_conflicting_deployment_targets)
+<< Targets[FirstTarget] << Targets[I];
+}
   }
 
   for (const auto  : llvm::enumerate(llvm::makeArrayRef(Targets))) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r367350 - [NFC] simplify Darwin environment handling

[JF Bastien via cfe-commits]

Author: jfb
Date: Tue Jul 30 13:01:46 2019
New Revision: 367350

URL: http://llvm.org/viewvc/llvm-project?rev=367350=rev
Log:
[NFC] simplify Darwin environment handling

The previous code detected conflicts through copy-pasta, this versions
uses a 'loop'.

Modified:
cfe/trunk/lib/Driver/ToolChains/Darwin.cpp

Modified: cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Darwin.cpp?rev=367350=367349=367350=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Darwin.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Darwin.cpp Tue Jul 30 13:01:46 2019
@@ -1480,22 +1480,6 @@ getDeploymentTargetFromEnvironmentVariab
   Targets[I.index()] = Env;
   }
 
-  // Do not allow conflicts with the watchOS target.
-  if (!Targets[Darwin::WatchOS].empty() &&
-  (!Targets[Darwin::IPhoneOS].empty() || !Targets[Darwin::TvOS].empty())) {
-TheDriver.Diag(diag::err_drv_conflicting_deployment_targets)
-<< "WATCHOS_DEPLOYMENT_TARGET"
-<< (!Targets[Darwin::IPhoneOS].empty() ? "IPHONEOS_DEPLOYMENT_TARGET"
-   : "TVOS_DEPLOYMENT_TARGET");
-  }
-
-  // Do not allow conflicts with the tvOS target.
-  if (!Targets[Darwin::TvOS].empty() && !Targets[Darwin::IPhoneOS].empty()) {
-TheDriver.Diag(diag::err_drv_conflicting_deployment_targets)
-<< "TVOS_DEPLOYMENT_TARGET"
-<< "IPHONEOS_DEPLOYMENT_TARGET";
-  }
-
   // Allow conflicts among OSX and iOS for historical reasons, but choose the
   // default platform.
   if (!Targets[Darwin::MacOS].empty() &&
@@ -1508,6 +1492,18 @@ getDeploymentTargetFromEnvironmentVariab
 else
   Targets[Darwin::IPhoneOS] = Targets[Darwin::WatchOS] =
   Targets[Darwin::TvOS] = "";
+  } else {
+// Don't allow conflicts in any other platform.
+int FirstTarget = llvm::array_lengthof(Targets);
+for (int I = 0; I != llvm::array_lengthof(Targets); ++I) {
+  if (Targets[I].empty())
+continue;
+  if (FirstTarget == llvm::array_lengthof(Targets))
+FirstTarget = I;
+  else
+TheDriver.Diag(diag::err_drv_conflicting_deployment_targets)
+<< Targets[FirstTarget] << Targets[I];
+}
   }
 
   for (const auto  : llvm::enumerate(llvm::makeArrayRef(Targets))) {


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

[PATCH] D64488: [Driver] Support -fsanitize=function on Solaris/x86

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

In D64488#1606758 , @ro wrote:

> In D64488#1606716 , @krytarowski 
> wrote:
>
> > Something is broken between reviews. and my mailbox as I am not receiving 
> > any e-mails so pinging does not make any effect... no LLVM admin replied to 
> > my questions on this to validate whether my mail was blacklisted or 
> > similar. I have decided  to change server of my mailbox and workaround it.
>
>
> Maybe this is related to other reviews.llvm.org issues during the weekend 
> where you couldn't update reviews with strange table full
>  errors?


I don't know. It lasts for a month or so. I wouldn't have noted this review 
without checking the phabricator page.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64488/new/

https://reviews.llvm.org/D64488



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

[PATCH] D61466: [Rewrite][NFC] Add FIXMEs and tests for RemoveLineIfEmpty bug

[Jan Korous via Phabricator via cfe-commits]

jkorous added a comment.

In D61466#1602928 , @jdenny wrote:

> In D61466#1602917 , @jkorous wrote:
>
> >
>
>
> In an inline comment, you also mentioned the alternative of replacing 
> `EXPECT_EQ` with `EXPECT_NE`.  Neither solution is the XFAIL I'm used to 
> (from lit for example).


I'm not aware of any assertion with this semantics in Google Test.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61466/new/

https://reviews.llvm.org/D61466



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

[PATCH] D55895: NFC: simplify Darwin environment handling

[Alex Lorenz via Phabricator via cfe-commits]

arphaman accepted this revision.
arphaman added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55895/new/

https://reviews.llvm.org/D55895



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

[PATCH] D62739: AMDGPU: Always emit amdgpu-flat-work-group-size

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

ping


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62739/new/

https://reviews.llvm.org/D62739



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

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

[JF Bastien via Phabricator via cfe-commits]

jfb added inline comments.



Comment at: test/Sema/warn-int-in-bool-context.c:26
+  r = a << 7;   // expected-warning {{'<<' in boolean context; did you mean 
'<'?}}
+  r = ONE << b; // expected-warning {{'<<' in boolean context; did you mean 
'<'?}}
+

xbolva00 wrote:
> jfb wrote:
> > I'm not sure the "did you mean" part is helpful. Do we have data showing 
> > that this is what people actually mean?
> No, no data, just what GCC suggests.
I would drop it without knowing that it's actually what people usually mean.



Comment at: test/Sema/warn-int-in-bool-context.c:33
+  r = a ? 3 : -2;
+  r = a ? 0 : TWO; // expected-warning {{'?:' with integer constants in 
boolean context}}
+  r = a ? 3 : ONE; // expected-warning {{'?:' with integer constants in 
boolean context, the expression will always evaluate to 'true'}}

xbolva00 wrote:
> jfb wrote:
> > Why does this one warn? It doesn't always yield the same result.
> GCC warns here..
Our goal isn't to achieve GCC warning parity. I like warnings that fire when 
it's extremely likely a bug. Here the diagnostic seems to be inconsistent with 
other instances of this diagnostic. Maybe this should warn, but then other 
cases should as well (such as `a?3:-2` above). Or maybe it shouldn't warn at 
all.



Comment at: test/Sema/warn-unreachable.c:147
+  // expected-warning@+1 {{'*' in boolean context, the expression will always 
evaluate to 'false'}}
   if (0 * x) calledFun(); // expected-warning {{will never be executed}}
 }

xbolva00 wrote:
> jfb wrote:
> > It seems like here the "will never be executed" warning is more useful. Do 
> > we want to emit both?
> Useful but -Wunreachable-code is disabled by default (not part of -Wall).
I don't think we want two diagnostics when one will do.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63082/new/

https://reviews.llvm.org/D63082



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

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 marked an inline comment as done.
xbolva00 added inline comments.



Comment at: test/Sema/warn-int-in-bool-context.c:32
+  r = a ? -2 : 0;
+  r = a ? 3 : -2;
+  r = a ? 0 : TWO; // expected-warning {{'?:' with integer constants in 
boolean context}}

jfb wrote:
> Why wouldn't think one warn?
Ah, right. Thanks ! 

I forgot there is an unary minus operator..

Will fix it.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63082/new/

https://reviews.llvm.org/D63082



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

[PATCH] D63082: [Diagnostics] Added support for -Wint-in-bool-context

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 marked 3 inline comments as done.
xbolva00 added inline comments.



Comment at: test/Sema/warn-int-in-bool-context.c:26
+  r = a << 7;   // expected-warning {{'<<' in boolean context; did you mean 
'<'?}}
+  r = ONE << b; // expected-warning {{'<<' in boolean context; did you mean 
'<'?}}
+

jfb wrote:
> I'm not sure the "did you mean" part is helpful. Do we have data showing that 
> this is what people actually mean?
No, no data, just what GCC suggests.



Comment at: test/Sema/warn-int-in-bool-context.c:33
+  r = a ? 3 : -2;
+  r = a ? 0 : TWO; // expected-warning {{'?:' with integer constants in 
boolean context}}
+  r = a ? 3 : ONE; // expected-warning {{'?:' with integer constants in 
boolean context, the expression will always evaluate to 'true'}}

jfb wrote:
> Why does this one warn? It doesn't always yield the same result.
GCC warns here..



Comment at: test/Sema/warn-unreachable.c:147
+  // expected-warning@+1 {{'*' in boolean context, the expression will always 
evaluate to 'false'}}
   if (0 * x) calledFun(); // expected-warning {{will never be executed}}
 }

jfb wrote:
> It seems like here the "will never be executed" warning is more useful. Do we 
> want to emit both?
Useful but -Wunreachable-code is disabled by default (not part of -Wall).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63082/new/

https://reviews.llvm.org/D63082



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

[PATCH] D65387: [clangd] Add a callback mechanism for handling responses from client.

[Sam McCall via Phabricator via cfe-commits]

sammccall added inline comments.



Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:150
+// Log the reply.
+log("<-- reply({0})", ID);
+Server.onReply(std::move(ID), std::move(Result));

We want to keep logging errors (not just at verbose level).

If you need a non-destructive way to get the error message for logging, I think 
it's unfortunately:
```
if (Result) {
  log();
  handle(move(Result));
} else {
  err = Result.takeError();
  log(err);
  handle(move(err));
}
```

Note I think our logging function has support for printing both rvalue errors 
(consuming them) and lvalue errors (not consuming them). But failing that, 
operator<< doesn't consume the error.



Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:314
   auto ID = NextCallID++;
+  auto StrID = llvm::to_string(ID);
+  {

we know the underlying ID is an integer (because we generate it above), so why 
not just key on the integer directly?
In Reply, if the ID isn't an integer then we know there's no callback.



Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:317
+std::lock_guard Lock(ReplyCallbacksMutex);
+ReplyCallbacks[StrID] = std::move(CB);
+  }

jkorous wrote:
> Should we care if there's already another callback registered for this 
> `StrID`?
I think we should assert on this. NextCallID should never overflow.



Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:317
+std::lock_guard Lock(ReplyCallbacksMutex);
+ReplyCallbacks[StrID] = std::move(CB);
+  }

sammccall wrote:
> jkorous wrote:
> > Should we care if there's already another callback registered for this 
> > `StrID`?
> I think we should assert on this. NextCallID should never overflow.
as Jan points out, this is an unbounded leak if the client never replies to 
requests.

the most obvious approach to fix this is to bound the size and drop e.g. oldest 
pending query if we overflow. (we can exploit that IDs are sequential integers, 
if that's useful)

I mention this because if the size is bounded to say 100 and small in practice, 
you might end up wanting to use deque or (linked) list



Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:336
+if (Result)
+  log("no corresponding callback for the reply ({0})", ID);
+else

elog, this is a protocol error

The message is too low level, it describes the implementation rather than the 
protocol. Prefer e.g. `received a reply with ID {0}, but there was no such call`

No need to handle error vs non-error here, it should be logged generally above 
(whether there was a missing callback or not)



Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:526
 Edit.edit = std::move(WE);
 // Ideally, we would wait for the response and if there is no error, we
 // would reply success/failure to the original RPC.

While I like keeping the scope small, it's not really possible to evaluate this 
change without using it at least once.

Can you use the new facility to address this comment?
This would look something like:
 - ApplyEdit takes a Callback
 - callsites look like this
```
ApplyEdit(*Params.workspaceEdit, bind(std::move(Reply), [](decltype(Reply) 
Reply, Expected Response) {
  if (!Response)
return Reply(Response.takeError());
  if (!Response->applied)
return Reply(makeStringError("edits not applied: " + 
Response->failureReason));
  return Reply("Fix applied");
});
```

(This is pretty verbose, but seems realistic for what we're actually going to 
do).

This function is a bit of a complicated monster, so feel free to just handle 
apply fix, or (better) to factor the code differently so it's reasonable to 
handle both.



Comment at: clang-tools-extra/clangd/ClangdLSPServer.h:152
+  // request.
+  using ReplyCallback = std::function)>;
+  std::mutex ReplyCallbacksMutex;

this type is just `clangd::Callback()`. (modulo supporting 
move-only captures, which we want I think)
I'm not sure that's worth abbreviating.



Comment at: clang-tools-extra/clangd/ClangdLSPServer.h:155
+  // Request ID => reply Callbacks
+  llvm::StringMap ReplyCallbacks;
+

the corresponding state for request cancellation lives in MessageHandler, I 
think this one should too.

Similarly, onReply fits better in MessageHandler than here. `call()` belongs 
here though, so I guess `call()` needs to call something like 
`MessageHandler::bindReply(ID, Callback)` or so



Comment at: clang-tools-extra/clangd/ClangdLSPServer.h:157
+
+  void call(StringRef Method, llvm::json::Value Params, ReplyCallback CB);
+  void onReply(llvm::json::Value ID, llvm::Expected Result);

This API makes the caller of `call()` responsible for dealing with converting 
the arbitrary JSON returned by the client into the 

[PATCH] D63954: Add lifetime categories attributes

[Matthias Gehre via Phabricator via cfe-commits]

mgehre added a comment.

I will include your latest comments into D64448 



Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63954/new/

https://reviews.llvm.org/D63954



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

[PATCH] D62648: [Sema][Typo] Fix assertion failure for expressions with multiple typos

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

I don't think you need to change the `TreeTranform` base class to support this; 
`TreeTransform::TransformExpr` is an extension point which you can override 
from `TransformTypos` to inject the custom logic you need. But I also don't 
think this `TreeTransform::TransformExpr` approach works in general anyway, as 
noted below.




Comment at: lib/Sema/TreeTransform.h:3485-3489
+  // If the transformed Expr is valid, check if it's a TypoExpr so we can keep
+  // track of them. Otherwise, if the transform result is invalid, clear any
+  // TypoExprs that might have been created recursively (TODO: verify that
+  // this can happen in practice here instead of via an error trap).
+  if (Res.isUsable()) {

It's not safe to assume that all created `TypoExpr`s will be produced by 
`TransformExpr`. We might (for example) produce a new `TypoExpr` for the callee 
expression while transforming a `CallExpr`, and you won't catch that here.

It would seem cleaner and more robust to me to collect the typos produced 
during typo correction from within `Sema::createDelayedTypo`. (Eg, set some 
state on `Sema` for the duration of typo correction, and use that state to 
communicate any created typos back from `createDelayedTypo` to typo correction.)


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62648/new/

https://reviews.llvm.org/D62648



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

[PATCH] D62960: Add SVE opaque built-in types

[Richard Sandiford via Phabricator via cfe-commits]

rsandifo-arm marked 10 inline comments as done.
rsandifo-arm added a comment.

Thanks.  I think the current version of the patch addresses all review comments 
so far and the last set of comments seemed positive.  Does the patch look OK to 
land?

(I was waiting until Clang 9 branched, and then was away last week, hence the 
long delay...)


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62960/new/

https://reviews.llvm.org/D62960



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

[PATCH] D64488: [Driver] Support -fsanitize=function on Solaris/x86

[Rainer Orth via Phabricator via cfe-commits]

ro updated this revision to Diff 212393.
ro added a comment.

Test i386--solaris instead of x86_64--solaris twice.

Retested on x86_64-pc-solaris2.11.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64488/new/

https://reviews.llvm.org/D64488

Files:
  lib/Driver/ToolChains/Solaris.cpp
  test/Driver/fsanitize.c


Index: test/Driver/fsanitize.c
===
--- test/Driver/fsanitize.c
+++ test/Driver/fsanitize.c
@@ -727,6 +727,9 @@
 // RUN: %clang -target x86_64--netbsd -fsanitize=scudo %s -### 2>&1 | 
FileCheck %s -check-prefix=SCUDO-NETBSD
 // SCUDO-NETBSD: "-fsanitize=scudo"
 
+// RUN: %clang -target i386--solaris -fsanitize=function %s -### 2>&1 | 
FileCheck %s -check-prefix=FUNCTION-SOLARIS
+// RUN: %clang -target x86_64--solaris -fsanitize=function %s -### 2>&1 | 
FileCheck %s -check-prefix=FUNCTION-SOLARIS
+// FUNCTION-SOLARIS: "-fsanitize=function"
 
 
 // RUN: %clang -target x86_64-scei-ps4 -fsanitize=function 
-fsanitize=undefined %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-FSAN-UBSAN-PS4
Index: lib/Driver/ToolChains/Solaris.cpp
===
--- lib/Driver/ToolChains/Solaris.cpp
+++ lib/Driver/ToolChains/Solaris.cpp
@@ -177,6 +177,7 @@
 
 SanitizerMask Solaris::getSupportedSanitizers() const {
   const bool IsX86 = getTriple().getArch() == llvm::Triple::x86;
+  const bool IsX86_64 = getTriple().getArch() == llvm::Triple::x86_64;
   const bool IsSparc = getTriple().getArch() == llvm::Triple::sparc;
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
   // FIXME: Omit X86_64 and SPARCv9 until 64-bit support is figured out.
@@ -185,6 +186,8 @@
 Res |= SanitizerKind::PointerCompare;
 Res |= SanitizerKind::PointerSubtract;
   }
+  if (IsX86 || IsX86_64)
+Res |= SanitizerKind::Function;
   Res |= SanitizerKind::Vptr;
   return Res;
 }


Index: test/Driver/fsanitize.c
===
--- test/Driver/fsanitize.c
+++ test/Driver/fsanitize.c
@@ -727,6 +727,9 @@
 // RUN: %clang -target x86_64--netbsd -fsanitize=scudo %s -### 2>&1 | FileCheck %s -check-prefix=SCUDO-NETBSD
 // SCUDO-NETBSD: "-fsanitize=scudo"
 
+// RUN: %clang -target i386--solaris -fsanitize=function %s -### 2>&1 | FileCheck %s -check-prefix=FUNCTION-SOLARIS
+// RUN: %clang -target x86_64--solaris -fsanitize=function %s -### 2>&1 | FileCheck %s -check-prefix=FUNCTION-SOLARIS
+// FUNCTION-SOLARIS: "-fsanitize=function"
 
 
 // RUN: %clang -target x86_64-scei-ps4 -fsanitize=function -fsanitize=undefined %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-FSAN-UBSAN-PS4
Index: lib/Driver/ToolChains/Solaris.cpp
===
--- lib/Driver/ToolChains/Solaris.cpp
+++ lib/Driver/ToolChains/Solaris.cpp
@@ -177,6 +177,7 @@
 
 SanitizerMask Solaris::getSupportedSanitizers() const {
   const bool IsX86 = getTriple().getArch() == llvm::Triple::x86;
+  const bool IsX86_64 = getTriple().getArch() == llvm::Triple::x86_64;
   const bool IsSparc = getTriple().getArch() == llvm::Triple::sparc;
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
   // FIXME: Omit X86_64 and SPARCv9 until 64-bit support is figured out.
@@ -185,6 +186,8 @@
 Res |= SanitizerKind::PointerCompare;
 Res |= SanitizerKind::PointerSubtract;
   }
+  if (IsX86 || IsX86_64)
+Res |= SanitizerKind::Function;
   Res |= SanitizerKind::Vptr;
   return Res;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r367346 - [Parser] Lambda capture lists can start with '*'

[Erik Pilkington via cfe-commits]

Author: epilk
Date: Tue Jul 30 12:21:20 2019
New Revision: 367346

URL: http://llvm.org/viewvc/llvm-project?rev=367346=rev
Log:
[Parser] Lambda capture lists can start with '*'

Fixes llvm.org/PR42778

Modified:
cfe/trunk/lib/Parse/ParseInit.cpp
cfe/trunk/test/Parser/cxx0x-lambda-expressions.cpp

Modified: cfe/trunk/lib/Parse/ParseInit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseInit.cpp?rev=367346=367345=367346=diff
==
--- cfe/trunk/lib/Parse/ParseInit.cpp (original)
+++ cfe/trunk/lib/Parse/ParseInit.cpp Tue Jul 30 12:21:20 2019
@@ -45,6 +45,7 @@ bool Parser::MayBeDesignationStart() {
 
 case tok::amp:
 case tok::kw_this:
+case tok::star:
 case tok::identifier:
   // We have to do additional analysis, because these could be the
   // start of a constant expression or a lambda capture list.

Modified: cfe/trunk/test/Parser/cxx0x-lambda-expressions.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/cxx0x-lambda-expressions.cpp?rev=367346=367345=367346=diff
==
--- cfe/trunk/test/Parser/cxx0x-lambda-expressions.cpp (original)
+++ cfe/trunk/test/Parser/cxx0x-lambda-expressions.cpp Tue Jul 30 12:21:20 2019
@@ -126,6 +126,19 @@ void PR22122() {
 
 template void PR22122();
 
+namespace PR42778 {
+struct A {
+  template  A(F&&) {}
+};
+
+struct S {
+  void mf() { A{[*this]{}}; }
+#if __cplusplus < 201703L
+  // expected-warning@-2 {{C++17 extension}}
+#endif
+};
+}
+
 struct S {
   template 
   void m (T x =[0); // expected-error{{expected variable name or 'this' in 
lambda capture list}}


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

[PATCH] D65308: [NFC][clang] Refactor getCompilationPhases()+Types.def step 3.

[Puyan Lotfi via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367345: [NFC][clang] Refactor 
getCompilationPhases()+Types.def step 3. (authored by zer0, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65308?vs=211981=212405#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65308/new/

https://reviews.llvm.org/D65308

Files:
  cfe/trunk/include/clang/Driver/Types.def
  cfe/trunk/include/clang/Driver/Types.h
  cfe/trunk/lib/Driver/Types.cpp

Index: cfe/trunk/include/clang/Driver/Types.def
===
--- cfe/trunk/include/clang/Driver/Types.def
+++ cfe/trunk/include/clang/Driver/Types.def
@@ -29,76 +29,73 @@
 // The fourth value is the suffix to use when creating temporary files
 // of this type, or null if unspecified.
 
-// The fifth value is a string containing option flags. Valid values:
-//  u - The type can be user specified (with -x).
-
-// The sixth value is a variadic list of phases for each type. Eventually the
+// The final value is a variadic list of phases for each type. Eventually the
 // options flag string will be replaced with this variadic list.
 // Most of the options in Flags have been removed in favor of subsuming their
 // meaning from the phases list.
 
 // C family source language (with and without preprocessing).
-TYPE("cpp-output",   PP_C, INVALID, "i", "u", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("c",C,PP_C,"c", "u", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cl",   CL,   PP_C,"cl","u", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cuda-cpp-output",  PP_CUDA,  INVALID, "cui",   "u", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cuda", CUDA, PP_CUDA, "cu","u", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cuda", CUDA_DEVICE,  PP_CUDA, "cu","" , phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("hip-cpp-output",   PP_HIP,   INVALID, "cui",   "u", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("hip",  HIP,  PP_HIP,  "cu","u", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("hip",  HIP_DEVICE,   PP_HIP,  "cu","" , phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objective-c-cpp-output",   PP_ObjC,  INVALID, "mi","u", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objc-cpp-output",  PP_ObjC_Alias, INVALID,"mi","u", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objective-c",  ObjC, PP_ObjC, "m", "u", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("c++-cpp-output",   PP_CXX,   INVALID, "ii","u", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("c++",  CXX,  PP_CXX,  "cpp",   "u", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objective-c++-cpp-output", PP_ObjCXX,INVALID, "mii",   "u", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objc++-cpp-output",PP_ObjCXX_Alias, INVALID,  "mii",   "u", phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objective-c++",ObjCXX,   PP_ObjCXX,   "mm","u", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("renderscript", RenderScript, PP_C,"rs","u", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
+TYPE("cpp-output",   PP_C, INVALID, "i",  phases::Compile, phases::Backend, phases::Assemble, phases::Link)
+TYPE("c",C,PP_C,"c",  phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
+TYPE("cl",   CL,   PP_C,"cl", phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, phases::Link)
+TYPE("cuda-cpp-output",  PP_CUDA,  INVALID, "cui",phases::Compile, phases::Backend, phases::Assemble, phases::Link)
+TYPE("cuda", CUDA, PP_CUDA, "cu", phases::Preprocess, phases::Compile, 

[PATCH] D64666: [Sema] Enable -Wimplicit-float-conversion for integral to floating point precision loss

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:11656
+  IsListInit =
+  IsListInit || (isa(OrigE) && S.getLangOpts().CPlusPlus);
+

ziangwan wrote:
> aaron.ballman wrote:
> > ziangwan wrote:
> > > aaron.ballman wrote:
> > > > Do you want to perform the `isa<>` on `OrigE` or on `E` which has had 
> > > > paren and implicit casts stripped?
> > > When we are dealing with Initialization list syntax expression, the 
> > > out-most expression will be of type `InitListExpr`. Since the out-most 
> > > expression is not `ImplicitCastExpr`, `IgnoreParenImpCasts()` has no 
> > > effect on the `OrigE` object. In other words, `OrigE` and `E` will be the 
> > > same when `isa(OrigE)` evaluates to true.
> > > 
> > > In this case, I personally prefer `OrigE` since it is the "non-processed" 
> > > object. However, the rest of the function uses `E` only. I can change it 
> > > to `E`.
> > Ah, I was thinking we had to contend with a case like `({1, 2, 3})` where 
> > there's a `ParenExpr` involved, but I am not certain that's a case we have 
> > to worry about.
> I think `({1,2,3})` is not a valid initializer.
> ```
> implicit-int-float-narrowing.cpp:6:16: warning: expression result unused 
> [-Wunused-value]
>   int a[3] = ({1,2,3});
>^
> implicit-int-float-narrowing.cpp:6:18: warning: expression result unused 
> [-Wunused-value]
>   int a[3] = ({1,2,3});
>  ^
> implicit-int-float-narrowing.cpp:6:21: error: expected ';' after expression
>   int a[3] = ({1,2,3});
> ^
> implicit-int-float-narrowing.cpp:6:7: error: array initializer must be an 
> initializer list
>   int a[3] = ({1,2,3});
>   ^
> ```
> If so, I don think we need to worry about there's a `ParenExpr` involved.
> 
Agreed. :-)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64666/new/

https://reviews.llvm.org/D64666



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

r367345 - [NFC][clang] Refactor getCompilationPhases()+Types.def step 3.

[Puyan Lotfi via cfe-commits]

Author: zer0
Date: Tue Jul 30 12:03:17 2019
New Revision: 367345

URL: http://llvm.org/viewvc/llvm-project?rev=367345=rev
Log:
[NFC][clang] Refactor getCompilationPhases()+Types.def step 3.

Dropping the 'u' entry and the entire Flags table from Types.def.
Now it'll be a bit easier to tablegenify this.

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

Modified:
cfe/trunk/include/clang/Driver/Types.def
cfe/trunk/include/clang/Driver/Types.h
cfe/trunk/lib/Driver/Types.cpp

Modified: cfe/trunk/include/clang/Driver/Types.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Types.def?rev=367345=367344=367345=diff
==
--- cfe/trunk/include/clang/Driver/Types.def (original)
+++ cfe/trunk/include/clang/Driver/Types.def Tue Jul 30 12:03:17 2019
@@ -29,76 +29,73 @@
 // The fourth value is the suffix to use when creating temporary files
 // of this type, or null if unspecified.
 
-// The fifth value is a string containing option flags. Valid values:
-//  u - The type can be user specified (with -x).
-
-// The sixth value is a variadic list of phases for each type. Eventually the
+// The final value is a variadic list of phases for each type. Eventually the
 // options flag string will be replaced with this variadic list.
 // Most of the options in Flags have been removed in favor of subsuming their
 // meaning from the phases list.
 
 // C family source language (with and without preprocessing).
-TYPE("cpp-output",   PP_C, INVALID, "i", "u", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("c",C,PP_C,"c", "u", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("cl",   CL,   PP_C,"cl","u", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("cuda-cpp-output",  PP_CUDA,  INVALID, "cui",   "u", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("cuda", CUDA, PP_CUDA, "cu","u", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("cuda", CUDA_DEVICE,  PP_CUDA, "cu","" , 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("hip-cpp-output",   PP_HIP,   INVALID, "cui",   "u", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("hip",  HIP,  PP_HIP,  "cu","u", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("hip",  HIP_DEVICE,   PP_HIP,  "cu","" , 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("objective-c-cpp-output",   PP_ObjC,  INVALID, "mi","u", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objc-cpp-output",  PP_ObjC_Alias, INVALID,"mi","u", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objective-c",  ObjC, PP_ObjC, "m", "u", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("c++-cpp-output",   PP_CXX,   INVALID, "ii","u", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("c++",  CXX,  PP_CXX,  "cpp",   "u", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("objective-c++-cpp-output", PP_ObjCXX,INVALID, "mii",   "u", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objc++-cpp-output",PP_ObjCXX_Alias, INVALID,  "mii",   "u", 
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
-TYPE("objective-c++",ObjCXX,   PP_ObjCXX,   "mm","u", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
-TYPE("renderscript", RenderScript, PP_C,"rs","u", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
+TYPE("cpp-output",   PP_C, INVALID, "i",  
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
+TYPE("c",C,PP_C,"c",  
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
+TYPE("cl",   CL,   PP_C,"cl", 
phases::Preprocess, phases::Compile, phases::Backend, phases::Assemble, 
phases::Link)
+TYPE("cuda-cpp-output",  PP_CUDA,  INVALID, "cui",
phases::Compile, phases::Backend, phases::Assemble, phases::Link)
+TYPE("cuda",

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

Thanks, looks good.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474



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

[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

[Lingda Li via Phabricator via cfe-commits]

lildmh updated this revision to Diff 212399.
lildmh marked an inline comment as done.
lildmh added a comment.

Change mapper function argument checking


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59474/new/

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,414 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: 

[PATCH] D65184: [Sema] Thread Safety Analysis: Fix negative capability's LockKind representation.

[Ziang Wan via Phabricator via cfe-commits]

ziangwan marked an inline comment as done.
ziangwan added inline comments.



Comment at: clang/test/SemaCXX/warn-thread-safety-negative.cpp:135-140
+  if (condition) {
+assertNotHeld(); // expected-warning {{mutex '!mu' is acquired exclusively 
and shared in the same scope}}
+  } else {
+mu.Lock();
+mu.Unlock(); // expected-warning {{the other acquisition of mutex '!mu' is 
here}}
+  }

aaronpuchert wrote:
> ziangwan wrote:
> > aaronpuchert wrote:
> > > Why would I want these warnings here? This code seems fine to me.
> > > 
> > > However, I don't see why we don't get `acquiring mutex 'mu' requires 
> > > negative capability '!mu'` at line 138, or does that disappear because of 
> > > the assertion?
> > Showing `acquiring mutex 'mu' requires negative capability '!mu'` is not in 
> > the scope of this patch. Please notice thread safety analysis is still 
> > under development.
> > 
> > The reason is that, in one path we have `ASSERT_SHARED_CAPABILITY(!mu)`, 
> > and in the other path we have `RELEASE(mu)`. The assertion leads to 
> > negative shared capability but the release leads to negative exclusive 
> > capability. A merge of the two capabilities (merging "I am not trying to 
> > read" versus "I am not trying to write") leads to a warning.
> > 
> > Without my patch, clang will issue a warning for the merge point in test1() 
> > but not the merge point in test2().
> But `ASSERT_SHARED_CAPABILITY(!mu)` implies that we also don't have an 
> exclusive lock (an exclusive lock is stronger than a shared lock), and 
> `RELEASE(mu)` without `ACQUIRE_SHARED(mu)` implies that we have neither a 
> shared nor an exclusive lock as well.
> 
> In the end, I have the same question as above: Why do we want two kinds of 
> negative capabilities? Isn't the idea that negative capabilities express the 
> lock not being held at all?
The problem is: by the current state of the thread safety analysis, 
ASSERT_SHARED_CAPABILTIY(!mu) introduces a shared negative capability, whereas 
RELEASE(mu) and RELEASE_SHARED(mu) introduce an exclusive negative capability, 
and UNLOCK_FUNCTION(mu) introduces a generic negative capability. All three are 
different. At merge points, warnings will be issued if different types of 
negative capability are merged. The current thread safety analysis produces 
bogus false positive in our code base.

The solution I propose is that we should at least make RELEASE_SHARED(mu) 
produce a shared negative capability.

Regarding why we should have types for negative capability, thinking about 
"exclusive !mu" in a reader-writer lock situation, which means "I am not trying 
to write". However, the code can still read. In other words, "exclusive !mu" 
does not imply "shared !mu", and the code can still hold the lock in shared 
state. Without the types of negative capability, we wouldn't be able to express 
the situation described above.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65184/new/

https://reviews.llvm.org/D65184



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

[PATCH] D65184: [Sema] Thread Safety Analysis: Fix negative capability's LockKind representation.

[Ziang Wan via Phabricator via cfe-commits]

ziangwan marked an inline comment as done.
ziangwan added inline comments.



Comment at: clang/test/SemaCXX/thread-safety-annotations.h:47
+// Enable thread safety attributes only with clang.
+// The attributes can be safely erased when compiling with other compilers.
+#if defined(__clang__) && (!defined(SWIG))

aaronpuchert wrote:
> ziangwan wrote:
> > nickdesaulniers wrote:
> > > Is this test suite run with other compilers? If not, I think we can 
> > > remove the case?
> > Yeah, you are right. I just copied the header definitions from clang thread 
> > safety analysis doc.
> Why aren't you using the existing macros? The idea was to run the tests with 
> both old and new terminology, and for the time being, I think we should 
> maintain both.
There are already tests on existing macros. I want to introduce tests about the 
new macros as well.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65184/new/

https://reviews.llvm.org/D65184



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

[PATCH] D65184: [Sema] Thread Safety Analysis: Fix negative capability's LockKind representation.

[Ziang Wan via Phabricator via cfe-commits]

ziangwan added a comment.

The problem is: by the current state of the thread safety analysis, 
`ASSERT_SHARED_CAPABILTIY(!mu)` introduces a shared negative capability, 
whereas `RELEASE(mu)` **and `RELEASE_SHARED(mu)`**  introduce an exclusive 
negative capability, and `UNLOCK_FUNCTION(mu)` introduces a generic negative 
capability. All three are different. At merge points, warnings will be issued 
if different types of negative capability are merged. The current thread safety 
analysis produces bogus false positive in our code base.

The solution I propose is that we should at least make `RELEASE_SHARED(mu)` 
produce a shared negative capability.

Regarding why we should have types for negative capability, thinking about 
"exclusive !mu" in a reader-writer lock situation, which means "I am not trying 
to write". However, the code can still read. In other words, "exclusive !mu" 
does not imply "shared !mu", and the code can still hold the lock in shared 
state. Without the types of negative capability, we wouldn't be able to express 
the situation described above.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65184/new/

https://reviews.llvm.org/D65184



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

[PATCH] D65387: [clangd] Add a callback mechanism for handling responses from client.

[Jan Korous via Phabricator via cfe-commits]

jkorous added a comment.

Hi @hokein,
Do you have any thoughts on how to handle situation when client registers 
callback but doesn't send a request with registered ID later?




Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:317
+std::lock_guard Lock(ReplyCallbacksMutex);
+ReplyCallbacks[StrID] = std::move(CB);
+  }

Should we care if there's already another callback registered for this `StrID`?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65387/new/

https://reviews.llvm.org/D65387



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

[PATCH] D65462: gn build: Fix check-clang-tools after r362702.

[Mirko Bonadei via Phabricator via cfe-commits]

mbonadei added a comment.

LGTM.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65462/new/

https://reviews.llvm.org/D65462



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

[PATCH] D65462: gn build: Fix check-clang-tools after r362702.

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367340: gn build: Fix check-clang-tools after r362702. 
(authored by nico, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D65462?vs=212387=212391#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65462/new/

https://reviews.llvm.org/D65462

Files:
  
llvm/trunk/utils/gn/secondary/clang-tools-extra/clang-include-fixer/plugin/BUILD.gn
  llvm/trunk/utils/gn/secondary/clang-tools-extra/clang-tidy/plugin/BUILD.gn
  llvm/trunk/utils/gn/secondary/clang/tools/libclang/BUILD.gn


Index: llvm/trunk/utils/gn/secondary/clang/tools/libclang/BUILD.gn
===
--- llvm/trunk/utils/gn/secondary/clang/tools/libclang/BUILD.gn
+++ llvm/trunk/utils/gn/secondary/clang/tools/libclang/BUILD.gn
@@ -39,8 +39,22 @@
 deps += [ "//clang/lib/ARCMigrate" ]
   }
 
+  defines = []
+
+  # FIXME: Once the GN build has a way to select which bits to build,
+  # only include this dependency if clang-tools-extra is part of the build.
+  # FIXME: libclang depending on anything in clang-tools-extra seems like
+  # a layering violation.
+  if (true) {
+defines += [ "CLANG_TOOL_EXTRA_BUILD" ]
+deps += [
+  "//clang-tools-extra/clang-include-fixer/plugin",
+  "//clang-tools-extra/clang-tidy/plugin",
+]
+  }
+
   if (host_os == "win") {
-defines = [ "_CINDEX_LIB_" ]
+defines += [ "_CINDEX_LIB_" ]
   }
 
   sources = [
Index: 
llvm/trunk/utils/gn/secondary/clang-tools-extra/clang-include-fixer/plugin/BUILD.gn
===
--- 
llvm/trunk/utils/gn/secondary/clang-tools-extra/clang-include-fixer/plugin/BUILD.gn
+++ 
llvm/trunk/utils/gn/secondary/clang-tools-extra/clang-include-fixer/plugin/BUILD.gn
@@ -0,0 +1,18 @@
+static_library("plugin") {
+  output_name = "clangIncludeFixerPlugin"
+  configs += [ "//llvm/utils/gn/build:clang_code" ]
+  deps = [
+"//clang-tools-extra/clang-include-fixer",
+"//clang/lib/AST",
+"//clang/lib/Basic",
+"//clang/lib/Frontend",
+"//clang/lib/Parse",
+"//clang/lib/Sema",
+"//clang/lib/Tooling",
+"//llvm/utils/gn/build/libs/pthread",
+  ]
+
+  sources = [
+"IncludeFixerPlugin.cpp",
+  ]
+}
Index: 
llvm/trunk/utils/gn/secondary/clang-tools-extra/clang-tidy/plugin/BUILD.gn
===
--- llvm/trunk/utils/gn/secondary/clang-tools-extra/clang-tidy/plugin/BUILD.gn
+++ llvm/trunk/utils/gn/secondary/clang-tools-extra/clang-tidy/plugin/BUILD.gn
@@ -1,3 +1,5 @@
+import("//clang/lib/StaticAnalyzer/Frontend/enable.gni")
+
 static_library("plugin") {
   output_name = "clangTidyPlugin"
   configs += [ "//llvm/utils/gn/build:clang_code" ]
@@ -12,10 +14,12 @@
 "//clang-tools-extra/clang-tidy/fuchsia",
 "//clang-tools-extra/clang-tidy/google",
 "//clang-tools-extra/clang-tidy/hicpp",
+"//clang-tools-extra/clang-tidy/linuxkernel",
 "//clang-tools-extra/clang-tidy/llvm",
 "//clang-tools-extra/clang-tidy/misc",
 "//clang-tools-extra/clang-tidy/modernize",
 "//clang-tools-extra/clang-tidy/objc",
+"//clang-tools-extra/clang-tidy/openmp",
 "//clang-tools-extra/clang-tidy/performance",
 "//clang-tools-extra/clang-tidy/portability",
 "//clang-tools-extra/clang-tidy/readability",


Index: llvm/trunk/utils/gn/secondary/clang/tools/libclang/BUILD.gn
===
--- llvm/trunk/utils/gn/secondary/clang/tools/libclang/BUILD.gn
+++ llvm/trunk/utils/gn/secondary/clang/tools/libclang/BUILD.gn
@@ -39,8 +39,22 @@
 deps += [ "//clang/lib/ARCMigrate" ]
   }
 
+  defines = []
+
+  # FIXME: Once the GN build has a way to select which bits to build,
+  # only include this dependency if clang-tools-extra is part of the build.
+  # FIXME: libclang depending on anything in clang-tools-extra seems like
+  # a layering violation.
+  if (true) {
+defines += [ "CLANG_TOOL_EXTRA_BUILD" ]
+deps += [
+  "//clang-tools-extra/clang-include-fixer/plugin",
+  "//clang-tools-extra/clang-tidy/plugin",
+]
+  }
+
   if (host_os == "win") {
-defines = [ "_CINDEX_LIB_" ]
+defines += [ "_CINDEX_LIB_" ]
   }
 
   sources = [
Index: llvm/trunk/utils/gn/secondary/clang-tools-extra/clang-include-fixer/plugin/BUILD.gn
===
--- llvm/trunk/utils/gn/secondary/clang-tools-extra/clang-include-fixer/plugin/BUILD.gn
+++ llvm/trunk/utils/gn/secondary/clang-tools-extra/clang-include-fixer/plugin/BUILD.gn
@@ -0,0 +1,18 @@
+static_library("plugin") {
+  output_name = "clangIncludeFixerPlugin"
+  configs += [ "//llvm/utils/gn/build:clang_code" ]
+  deps = [
+"//clang-tools-extra/clang-include-fixer",
+"//clang/lib/AST",
+"//clang/lib/Basic",
+"//clang/lib/Frontend",
+"//clang/lib/Parse",
+

[PATCH] D64564: Loop pragma parsing. NFC.

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer marked an inline comment as done.
SjoerdMeijer added inline comments.



Comment at: lib/Parse/ParsePragma.cpp:1011
+  Str = llvm::StringSwitch(Str)
+   .Case("loop", "clang loop " + Str.str())
+   .Case("unroll_and_jam", Str)

Meinersbur wrote:
> [serious] I know I already accepted the patch, but I just noticed something:
> `"clang loop " + Str.str()` will allocate a temporary std::string, `Str` will 
> potentially point to it, then the temporary string will be released. `Str` 
> will then point to released memory and returned by this function, i.e. a 
> use-after-free.
> 
Oopsy, thanks for spotting this! Will fix this!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64564/new/

https://reviews.llvm.org/D64564



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

[PATCH] D64666: [Sema] Enable -Wimplicit-float-conversion for integral to floating point precision loss

[Ziang Wan via Phabricator via cfe-commits]

ziangwan marked an inline comment as done.
ziangwan added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:11656
+  IsListInit =
+  IsListInit || (isa(OrigE) && S.getLangOpts().CPlusPlus);
+

aaron.ballman wrote:
> ziangwan wrote:
> > aaron.ballman wrote:
> > > Do you want to perform the `isa<>` on `OrigE` or on `E` which has had 
> > > paren and implicit casts stripped?
> > When we are dealing with Initialization list syntax expression, the 
> > out-most expression will be of type `InitListExpr`. Since the out-most 
> > expression is not `ImplicitCastExpr`, `IgnoreParenImpCasts()` has no effect 
> > on the `OrigE` object. In other words, `OrigE` and `E` will be the same 
> > when `isa(OrigE)` evaluates to true.
> > 
> > In this case, I personally prefer `OrigE` since it is the "non-processed" 
> > object. However, the rest of the function uses `E` only. I can change it to 
> > `E`.
> Ah, I was thinking we had to contend with a case like `({1, 2, 3})` where 
> there's a `ParenExpr` involved, but I am not certain that's a case we have to 
> worry about.
I think `({1,2,3})` is not a valid initializer.
```
implicit-int-float-narrowing.cpp:6:16: warning: expression result unused 
[-Wunused-value]
  int a[3] = ({1,2,3});
   ^
implicit-int-float-narrowing.cpp:6:18: warning: expression result unused 
[-Wunused-value]
  int a[3] = ({1,2,3});
 ^
implicit-int-float-narrowing.cpp:6:21: error: expected ';' after expression
  int a[3] = ({1,2,3});
^
implicit-int-float-narrowing.cpp:6:7: error: array initializer must be an 
initializer list
  int a[3] = ({1,2,3});
  ^
```
If so, I don think we need to worry about there's a `ParenExpr` involved.



CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64666/new/

https://reviews.llvm.org/D64666



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

[PATCH] D64488: [Driver] Support -fsanitize=function on Solaris/x86

[Rainer Orth via Phabricator via cfe-commits]

ro added a comment.

In D64488#1606716 , @krytarowski wrote:

> Something is broken between reviews. and my mailbox as I am not receiving any 
> e-mails so pinging does not make any effect... no LLVM admin replied to my 
> questions on this to validate whether my mail was blacklisted or similar. I 
> have decided  to change server of my mailbox and workaround it.


Maybe this is related to other reviews.llvm.org issues during the weekend where 
you couldn't update reviews with strange table full
errors?




Comment at: test/Driver/fsanitize.c:721
+// RUN: %clang -target x86_64--solaris -fsanitize=function %s -### 2>&1 | 
FileCheck %s -check-prefix=FUNCTION-SOLARIS
+// RUN: %clang -target x86_64--solaris -fsanitize=function %s -### 2>&1 | 
FileCheck %s -check-prefix=FUNCTION-SOLARIS
+// FUNCTION-SOLARIS: "-fsanitize=function"

krytarowski wrote:
> Is twice x86_64 expected?
No, one of those should be i386.  Will fix.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64488/new/

https://reviews.llvm.org/D64488



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

[PATCH] D65462: gn build: Fix check-clang-tools after r362702.

[Hans Wennborg via Phabricator via cfe-commits]

hans accepted this revision.
hans added a comment.
This revision is now accepted and ready to land.

Seems good to me


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65462/new/

https://reviews.llvm.org/D65462



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

[PATCH] D65462: gn build: Fix check-clang-tools after r362702.

[Nico Weber via Phabricator via cfe-commits]

thakis created this revision.
thakis added reviewers: hans, pcc, mbonadei.
Herald added subscribers: llvm-commits, jfb.
Herald added a reviewer: jdoerfert.
Herald added a project: LLVM.

r362702 added a test that requires clang-tidy to be linked
into libclang, so add that to the gn build.


https://reviews.llvm.org/D65462

Files:
  llvm/utils/gn/secondary/clang-tools-extra/clang-include-fixer/plugin/BUILD.gn
  llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/plugin/BUILD.gn
  llvm/utils/gn/secondary/clang/tools/libclang/BUILD.gn


Index: llvm/utils/gn/secondary/clang/tools/libclang/BUILD.gn
===
--- llvm/utils/gn/secondary/clang/tools/libclang/BUILD.gn
+++ llvm/utils/gn/secondary/clang/tools/libclang/BUILD.gn
@@ -39,8 +39,22 @@
 deps += [ "//clang/lib/ARCMigrate" ]
   }
 
+  defines = []
+
+  # FIXME: Once the GN build has a way to select which bits to build,
+  # only include this dependency if clang-tools-extra is part of the build.
+  # FIXME: libclang depending on anything in clang-tools-extra seems like
+  # a layering violation.
+  if (true) {
+defines += [ "CLANG_TOOL_EXTRA_BUILD" ]
+deps += [
+  "//clang-tools-extra/clang-include-fixer/plugin",
+  "//clang-tools-extra/clang-tidy/plugin",
+]
+  }
+
   if (host_os == "win") {
-defines = [ "_CINDEX_LIB_" ]
+defines += [ "_CINDEX_LIB_" ]
   }
 
   sources = [
Index: llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/plugin/BUILD.gn
===
--- llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/plugin/BUILD.gn
+++ llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/plugin/BUILD.gn
@@ -1,3 +1,5 @@
+import("//clang/lib/StaticAnalyzer/Frontend/enable.gni")
+
 static_library("plugin") {
   output_name = "clangTidyPlugin"
   configs += [ "//llvm/utils/gn/build:clang_code" ]
@@ -12,10 +14,12 @@
 "//clang-tools-extra/clang-tidy/fuchsia",
 "//clang-tools-extra/clang-tidy/google",
 "//clang-tools-extra/clang-tidy/hicpp",
+"//clang-tools-extra/clang-tidy/linuxkernel",
 "//clang-tools-extra/clang-tidy/llvm",
 "//clang-tools-extra/clang-tidy/misc",
 "//clang-tools-extra/clang-tidy/modernize",
 "//clang-tools-extra/clang-tidy/objc",
+"//clang-tools-extra/clang-tidy/openmp",
 "//clang-tools-extra/clang-tidy/performance",
 "//clang-tools-extra/clang-tidy/portability",
 "//clang-tools-extra/clang-tidy/readability",
Index: 
llvm/utils/gn/secondary/clang-tools-extra/clang-include-fixer/plugin/BUILD.gn
===
--- /dev/null
+++ 
llvm/utils/gn/secondary/clang-tools-extra/clang-include-fixer/plugin/BUILD.gn
@@ -0,0 +1,18 @@
+static_library("plugin") {
+  output_name = "clangIncludeFixerPlugin"
+  configs += [ "//llvm/utils/gn/build:clang_code" ]
+  deps = [
+"//llvm/utils/gn/build/libs/pthread",
+"//clang-tools-extra/clang-include-fixer",
+"//clang/lib/AST",
+"//clang/lib/Basic",
+"//clang/lib/Frontend",
+"//clang/lib/Parse",
+"//clang/lib/Sema",
+"//clang/lib/Tooling",
+  ]
+
+  sources = [
+"IncludeFixerPlugin.cpp",
+  ]
+}


Index: llvm/utils/gn/secondary/clang/tools/libclang/BUILD.gn
===
--- llvm/utils/gn/secondary/clang/tools/libclang/BUILD.gn
+++ llvm/utils/gn/secondary/clang/tools/libclang/BUILD.gn
@@ -39,8 +39,22 @@
 deps += [ "//clang/lib/ARCMigrate" ]
   }
 
+  defines = []
+
+  # FIXME: Once the GN build has a way to select which bits to build,
+  # only include this dependency if clang-tools-extra is part of the build.
+  # FIXME: libclang depending on anything in clang-tools-extra seems like
+  # a layering violation.
+  if (true) {
+defines += [ "CLANG_TOOL_EXTRA_BUILD" ]
+deps += [
+  "//clang-tools-extra/clang-include-fixer/plugin",
+  "//clang-tools-extra/clang-tidy/plugin",
+]
+  }
+
   if (host_os == "win") {
-defines = [ "_CINDEX_LIB_" ]
+defines += [ "_CINDEX_LIB_" ]
   }
 
   sources = [
Index: llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/plugin/BUILD.gn
===
--- llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/plugin/BUILD.gn
+++ llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/plugin/BUILD.gn
@@ -1,3 +1,5 @@
+import("//clang/lib/StaticAnalyzer/Frontend/enable.gni")
+
 static_library("plugin") {
   output_name = "clangTidyPlugin"
   configs += [ "//llvm/utils/gn/build:clang_code" ]
@@ -12,10 +14,12 @@
 "//clang-tools-extra/clang-tidy/fuchsia",
 "//clang-tools-extra/clang-tidy/google",
 "//clang-tools-extra/clang-tidy/hicpp",
+"//clang-tools-extra/clang-tidy/linuxkernel",
 "//clang-tools-extra/clang-tidy/llvm",
 "//clang-tools-extra/clang-tidy/misc",
 "//clang-tools-extra/clang-tidy/modernize",
 "//clang-tools-extra/clang-tidy/objc",
+

[PATCH] D64488: [Driver] Support -fsanitize=function on Solaris/x86

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

Something is broken between reviews. and my mailbox as I am not receiving any 
e-mails so pinging does not make any effect... no LLVM admin replied to my 
questions on this to validate whether my mail was blacklisted or similar. I 
have decided  to change server of my mailbox and workaround it.




Comment at: test/Driver/fsanitize.c:721
+// RUN: %clang -target x86_64--solaris -fsanitize=function %s -### 2>&1 | 
FileCheck %s -check-prefix=FUNCTION-SOLARIS
+// RUN: %clang -target x86_64--solaris -fsanitize=function %s -### 2>&1 | 
FileCheck %s -check-prefix=FUNCTION-SOLARIS
+// FUNCTION-SOLARIS: "-fsanitize=function"

Is twice x86_64 expected?


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64488/new/

https://reviews.llvm.org/D64488



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

[PATCH] D65428: Remove cache for macro arg stringization

[Reid Kleckner via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367337: Remove cache for macro arg stringization (authored 
by rnk, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65428?vs=212261=212384#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65428/new/

https://reviews.llvm.org/D65428

Files:
  cfe/trunk/include/clang/Lex/MacroArgs.h
  cfe/trunk/lib/Lex/MacroArgs.cpp
  cfe/trunk/lib/Lex/TokenLexer.cpp
  cfe/trunk/test/CoverageMapping/macro-stringize-twice.cpp
  cfe/trunk/unittests/Lex/LexerTest.cpp

Index: cfe/trunk/include/clang/Lex/MacroArgs.h
===
--- cfe/trunk/include/clang/Lex/MacroArgs.h
+++ cfe/trunk/include/clang/Lex/MacroArgs.h
@@ -48,10 +48,6 @@
   /// stream.
   std::vector > PreExpArgTokens;
 
-  /// StringifiedArgs - This contains arguments in 'stringified' form.  If the
-  /// stringified form of an argument has not yet been computed, this is empty.
-  std::vector StringifiedArgs;
-
   /// ArgCache - This is a linked list of MacroArgs objects that the
   /// Preprocessor owns which we use to avoid thrashing malloc/free.
   MacroArgs *ArgCache;
@@ -94,12 +90,6 @@
   const std::vector &
 getPreExpArgument(unsigned Arg, Preprocessor );
 
-  /// getStringifiedArgument - Compute, cache, and return the specified argument
-  /// that has been 'stringified' as required by the # operator.
-  const Token (unsigned ArgNo, Preprocessor ,
-  SourceLocation ExpansionLocStart,
-  SourceLocation ExpansionLocEnd);
-
   /// getNumMacroArguments - Return the number of arguments the invoked macro
   /// expects.
   unsigned getNumMacroArguments() const { return NumMacroArgs; }
Index: cfe/trunk/test/CoverageMapping/macro-stringize-twice.cpp
===
--- cfe/trunk/test/CoverageMapping/macro-stringize-twice.cpp
+++ cfe/trunk/test/CoverageMapping/macro-stringize-twice.cpp
@@ -0,0 +1,30 @@
+// RUN: %clang_cc1 -triple %itanium_abi_triple -fprofile-instrument=clang -fcoverage-mapping -dump-coverage-mapping -emit-llvm-only %s | FileCheck %s
+
+// PR39942
+
+class a;
+template  a <<(b &, const char *);
+int c;
+#define d(l) l(__FILE__, __LINE__, c)
+#define COMPACT_GOOGLE_LOG_ERROR d(e)
+#define f(g, cond) cond ? (void)0 : h() & g
+#define i(j) COMPACT_GOOGLE_LOG_##j.g()
+#define k(j) f(i(j), 0)
+class e {
+public:
+  e(const char *, int, int);
+  a ();
+};
+class h {
+public:
+  void operator&(a &);
+};
+void use_str(const char *);
+
+#define m(func)\
+  use_str(#func);  \
+  k(ERROR) << #func;   \
+  return 0; // CHECK: File 1, [[@LINE-1]]:4 -> [[@LINE-1]]:16 = (#0 - #1)
+int main() {
+  m(asdf);
+}
Index: cfe/trunk/lib/Lex/TokenLexer.cpp
===
--- cfe/trunk/lib/Lex/TokenLexer.cpp
+++ cfe/trunk/lib/Lex/TokenLexer.cpp
@@ -383,18 +383,10 @@
   SourceLocation ExpansionLocEnd =
   getExpansionLocForMacroDefLoc(Tokens[I+1].getLocation());
 
-  Token Res;
-  if (CurTok.is(tok::hash))  // Stringify
-Res = ActualArgs->getStringifiedArgument(ArgNo, PP,
- ExpansionLocStart,
- ExpansionLocEnd);
-  else {
-// 'charify': don't bother caching these.
-Res = MacroArgs::StringifyArgument(ActualArgs->getUnexpArgument(ArgNo),
-   PP, true,
-   ExpansionLocStart,
-   ExpansionLocEnd);
-  }
+  bool Charify = CurTok.is(tok::hashat);
+  const Token *UnexpArg = ActualArgs->getUnexpArgument(ArgNo);
+  Token Res = MacroArgs::StringifyArgument(
+  UnexpArg, PP, Charify, ExpansionLocStart, ExpansionLocEnd);
   Res.setFlag(Token::StringifiedInMacro);
 
   // The stringified/charified string leading space flag gets set to match
Index: cfe/trunk/lib/Lex/MacroArgs.cpp
===
--- cfe/trunk/lib/Lex/MacroArgs.cpp
+++ cfe/trunk/lib/Lex/MacroArgs.cpp
@@ -76,8 +76,6 @@
 /// destroy - Destroy and deallocate the memory for this object.
 ///
 void MacroArgs::destroy(Preprocessor ) {
-  StringifiedArgs.clear();
-
   // Don't clear PreExpArgTokens, just clear the entries.  Clearing the entries
   // would deallocate the element vectors.
   for (unsigned i = 0, e = PreExpArgTokens.size(); i != e; ++i)
@@ -307,21 +305,3 @@
   ExpansionLocStart, ExpansionLocEnd);
   return Tok;
 }
-
-/// 

[PATCH] D65127: Even more warnings utilizing gsl::Owner/gsl::Pointer annotations

[Matthias Gehre via Phabricator via cfe-commits]

mgehre added inline comments.



Comment at: clang/lib/Sema/SemaInit.cpp:6581
+if (!Callee->getIdentifier()) {
+  auto OO = Callee->getOverloadedOperator();
+  return OO == OverloadedOperatorKind::OO_Subscript ||

xazax.hun wrote:
> If we want to relax the warnings to give more results we could extend the 
> checking of these overloaded operators for annotated types. But this would 
> imply that the user need to have the expected semantics for those types and 
> can only suppress false positives by removing some gsl:::owner/poinnter 
> annotations.
I see those options:
- Either gsl::Owner implies some specific form of those operators (and if that 
does not hold for a class, then one should not annotate it with gsl::Owner)
- or gsl::Owner only implies some specific behavior for the "gsl::Pointer 
constructed from gsl::Owner" case and everything else requires additional 
annotation
I expect that we will experiment a bit in the future to see what works well for 
real-world code.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65127/new/

https://reviews.llvm.org/D65127



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

[PATCH] D65428: Remove cache for macro arg stringization

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

Thanks for looking into it as well, I would not have seen the issue without 
reviewing the test case again. :)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65428/new/

https://reviews.llvm.org/D65428



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

r367337 - Remove cache for macro arg stringization

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Tue Jul 30 10:58:22 2019
New Revision: 367337

URL: http://llvm.org/viewvc/llvm-project?rev=367337=rev
Log:
Remove cache for macro arg stringization

Summary:
The cache recorded the wrong expansion location for all but the first
stringization. It seems uncommon to stringize the same macro argument
multiple times, so this cache doesn't seem that important.

Fixes PR39942

Reviewers: vsk, rsmith

Subscribers: cfe-commits

Tags: #clang

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

Added:
cfe/trunk/test/CoverageMapping/macro-stringize-twice.cpp
Modified:
cfe/trunk/include/clang/Lex/MacroArgs.h
cfe/trunk/lib/Lex/MacroArgs.cpp
cfe/trunk/lib/Lex/TokenLexer.cpp
cfe/trunk/unittests/Lex/LexerTest.cpp

Modified: cfe/trunk/include/clang/Lex/MacroArgs.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/MacroArgs.h?rev=367337=367336=367337=diff
==
--- cfe/trunk/include/clang/Lex/MacroArgs.h (original)
+++ cfe/trunk/include/clang/Lex/MacroArgs.h Tue Jul 30 10:58:22 2019
@@ -48,10 +48,6 @@ class MacroArgs final
   /// stream.
   std::vector > PreExpArgTokens;
 
-  /// StringifiedArgs - This contains arguments in 'stringified' form.  If the
-  /// stringified form of an argument has not yet been computed, this is empty.
-  std::vector StringifiedArgs;
-
   /// ArgCache - This is a linked list of MacroArgs objects that the
   /// Preprocessor owns which we use to avoid thrashing malloc/free.
   MacroArgs *ArgCache;
@@ -94,12 +90,6 @@ public:
   const std::vector &
 getPreExpArgument(unsigned Arg, Preprocessor );
 
-  /// getStringifiedArgument - Compute, cache, and return the specified 
argument
-  /// that has been 'stringified' as required by the # operator.
-  const Token (unsigned ArgNo, Preprocessor ,
-  SourceLocation ExpansionLocStart,
-  SourceLocation ExpansionLocEnd);
-
   /// getNumMacroArguments - Return the number of arguments the invoked macro
   /// expects.
   unsigned getNumMacroArguments() const { return NumMacroArgs; }

Modified: cfe/trunk/lib/Lex/MacroArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/MacroArgs.cpp?rev=367337=367336=367337=diff
==
--- cfe/trunk/lib/Lex/MacroArgs.cpp (original)
+++ cfe/trunk/lib/Lex/MacroArgs.cpp Tue Jul 30 10:58:22 2019
@@ -76,8 +76,6 @@ MacroArgs *MacroArgs::create(const Macro
 /// destroy - Destroy and deallocate the memory for this object.
 ///
 void MacroArgs::destroy(Preprocessor ) {
-  StringifiedArgs.clear();
-
   // Don't clear PreExpArgTokens, just clear the entries.  Clearing the entries
   // would deallocate the element vectors.
   for (unsigned i = 0, e = PreExpArgTokens.size(); i != e; ++i)
@@ -307,21 +305,3 @@ Token MacroArgs::StringifyArgument(const
   ExpansionLocStart, ExpansionLocEnd);
   return Tok;
 }
-
-/// getStringifiedArgument - Compute, cache, and return the specified argument
-/// that has been 'stringified' as required by the # operator.
-const Token ::getStringifiedArgument(unsigned ArgNo,
-   Preprocessor ,
-   SourceLocation 
ExpansionLocStart,
-   SourceLocation ExpansionLocEnd) 
{
-  assert(ArgNo < getNumMacroArguments() && "Invalid argument number!");
-  if (StringifiedArgs.empty())
-StringifiedArgs.resize(getNumMacroArguments(), {});
-
-  if (StringifiedArgs[ArgNo].isNot(tok::string_literal))
-StringifiedArgs[ArgNo] = StringifyArgument(getUnexpArgument(ArgNo), PP,
-   /*Charify=*/false,
-   ExpansionLocStart,
-   ExpansionLocEnd);
-  return StringifiedArgs[ArgNo];
-}

Modified: cfe/trunk/lib/Lex/TokenLexer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/TokenLexer.cpp?rev=367337=367336=367337=diff
==
--- cfe/trunk/lib/Lex/TokenLexer.cpp (original)
+++ cfe/trunk/lib/Lex/TokenLexer.cpp Tue Jul 30 10:58:22 2019
@@ -383,18 +383,10 @@ void TokenLexer::ExpandFunctionArguments
   SourceLocation ExpansionLocEnd =
   getExpansionLocForMacroDefLoc(Tokens[I+1].getLocation());
 
-  Token Res;
-  if (CurTok.is(tok::hash))  // Stringify
-Res = ActualArgs->getStringifiedArgument(ArgNo, PP,
- ExpansionLocStart,
- ExpansionLocEnd);
-  else {
-// 'charify': don't bother caching these.
-Res = MacroArgs::StringifyArgument(ActualArgs->getUnexpArgument(ArgNo),
-   PP, true,
- 

[PATCH] D65458: [NFC] Remove LLVM_ALIGNAS

[Reid Kleckner via Phabricator via cfe-commits]

rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.

lgtm


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65458/new/

https://reviews.llvm.org/D65458



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

[PATCH] D65426: [Coverage] Hide coverage for regions with incorrect end locations (PR39942)

[Vedant Kumar via Phabricator via cfe-commits]

vsk abandoned this revision.
vsk added a comment.

Thanks Reid!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65426/new/

https://reviews.llvm.org/D65426



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

[PATCH] D65428: Remove cache for macro arg stringization

[Vedant Kumar via Phabricator via cfe-commits]

vsk accepted this revision.
vsk added a comment.
This revision is now accepted and ready to land.

Thanks, lgtm.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65428/new/

https://reviews.llvm.org/D65428



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

[PATCH] D65461: [OPENMP]Add support for analysis of linear variables and step.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev created this revision.
ABataev added a reviewer: NoQ.
Herald added a subscriber: guansong.
Herald added a project: clang.

Added support for basic analysis of the linear variables and linear step
expression. Linear loop iteration variables must be excluded from this
analysis, only non-loop iteration variables must be analyzed.


Repository:
  rC Clang

https://reviews.llvm.org/D65461

Files:
  include/clang/AST/OpenMPClause.h
  lib/AST/OpenMPClause.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/Analysis/cfg-openmp.cpp
  test/OpenMP/distribute_parallel_for_simd_linear_messages.cpp
  test/OpenMP/distribute_simd_linear_messages.cpp
  test/OpenMP/for_linear_messages.cpp
  test/OpenMP/for_simd_linear_messages.cpp
  test/OpenMP/parallel_for_linear_messages.cpp
  test/OpenMP/parallel_for_simd_linear_messages.cpp
  test/OpenMP/simd_linear_messages.cpp
  test/OpenMP/target_parallel_for_linear_messages.cpp
  test/OpenMP/target_parallel_for_simd_linear_messages.cpp
  test/OpenMP/target_simd_linear_messages.cpp
  test/OpenMP/target_teams_distribute_parallel_for_simd_linear_messages.cpp
  test/OpenMP/target_teams_distribute_simd_linear_messages.cpp
  test/OpenMP/taskloop_simd_linear_messages.cpp
  test/OpenMP/teams_distribute_parallel_for_simd_linear_messages.cpp
  test/OpenMP/teams_distribute_simd_linear_messages.cpp

Index: test/OpenMP/teams_distribute_simd_linear_messages.cpp
===
--- test/OpenMP/teams_distribute_simd_linear_messages.cpp
+++ test/OpenMP/teams_distribute_simd_linear_messages.cpp
@@ -3,6 +3,14 @@
 // RUN: %clang_cc1 -verify -fopenmp-simd %s -Wuninitialized
 
 extern int omp_default_mem_alloc;
+void xxx(int argc) {
+  int i, step; // expected-note {{initialize the variable 'step' to silence this warning}} expected-note {{initialize the variable 'i' to silence this warning}}
+#pragma omp target
+#pragma omp teams distribute simd linear(i : step) // expected-warning {{variable 'i' is uninitialized when used here}} expected-warning {{variable 'step' is uninitialized when used here}}
+  for (i = 0; i < 10; ++i)
+;
+}
+
 namespace X {
   int x;
 };
Index: test/OpenMP/teams_distribute_parallel_for_simd_linear_messages.cpp
===
--- test/OpenMP/teams_distribute_parallel_for_simd_linear_messages.cpp
+++ test/OpenMP/teams_distribute_parallel_for_simd_linear_messages.cpp
@@ -3,6 +3,14 @@
 // RUN: %clang_cc1 -verify -fopenmp-simd %s -Wuninitialized
 
 extern int omp_default_mem_alloc;
+void xxx(int argc) {
+  int i, step; // expected-note {{initialize the variable 'step' to silence this warning}} expected-note {{initialize the variable 'i' to silence this warning}}
+#pragma omp target
+#pragma omp teams distribute parallel for simd linear(i : step) // expected-warning {{variable 'i' is uninitialized when used here}} expected-warning {{variable 'step' is uninitialized when used here}}
+  for (i = 0; i < 10; ++i)
+;
+}
+
 namespace X {
   int x;
 };
Index: test/OpenMP/taskloop_simd_linear_messages.cpp
===
--- test/OpenMP/taskloop_simd_linear_messages.cpp
+++ test/OpenMP/taskloop_simd_linear_messages.cpp
@@ -12,6 +12,13 @@
 extern const omp_allocator_handle_t omp_pteam_mem_alloc;
 extern const omp_allocator_handle_t omp_thread_mem_alloc;
 
+void xxx(int argc) {
+  int i, lin, step; // expected-note {{initialize the variable 'lin' to silence this warning}} expected-note {{initialize the variable 'step' to silence this warning}}
+#pragma omp taskloop simd linear(i, lin : step) // expected-warning {{variable 'lin' is uninitialized when used here}} expected-warning {{variable 'step' is uninitialized when used here}}
+  for (i = 0; i < 10; ++i)
+;
+}
+
 namespace X {
   int x;
 };
Index: test/OpenMP/target_teams_distribute_simd_linear_messages.cpp
===
--- test/OpenMP/target_teams_distribute_simd_linear_messages.cpp
+++ test/OpenMP/target_teams_distribute_simd_linear_messages.cpp
@@ -12,6 +12,13 @@
 extern const omp_allocator_handle_t omp_pteam_mem_alloc;
 extern const omp_allocator_handle_t omp_thread_mem_alloc;
 
+void xxx(int argc) {
+  int i, step; // expected-note {{initialize the variable 'step' to silence this warning}}
+#pragma omp target teams distribute simd linear(i : step) // expected-warning {{variable 'step' is uninitialized when used here}}
+  for (i = 0; i < 10; ++i)
+;
+}
+
 namespace X {
   int x;
 };
Index: test/OpenMP/target_teams_distribute_parallel_for_simd_linear_messages.cpp
===
--- test/OpenMP/target_teams_distribute_parallel_for_simd_linear_messages.cpp
+++ test/OpenMP/target_teams_distribute_parallel_for_simd_linear_messages.cpp
@@ -12,6 +12,13 @@
 extern const omp_allocator_handle_t 

[PATCH] D63932: [GlobalDCE] Dead Virtual Function Elimination

[Peter Collingbourne via Phabricator via cfe-commits]

pcc added a comment.

In D63932#1606248 , @ostannard wrote:

> In that example, with everything having default ELF visibility, all of the 
> vtables will get vcall_visibility public, which can't be optimised by VFE, 
> and won't ever be relaxed to one of the tighter visibilities.
>
> The cases which can be optimised are (assuming "visibility" means visibility 
> of the most-visible dynamic base class):
>
> - Classes in an anonymous namespace, which aren't visible outside their 
> translation unit. Probably doesn't happen very often, but can be optimised 
> without LTO.
> - Classes visible outside the translation unit, but not outside the LTO unit. 
> This generally means hidden ELF visibility, unless the lto_visibility_public 
> attribute is used. These can't be optimised without LTO, but can be with it.
>
>   I implemented the second case by adding the LinkageUnit visibility, which 
> can't be optimised by VFE, but can be reduced to TranslationUnit when LTO 
> internalisation happens. This could also have been done by not changing the 
> visibility at LTO time, and instead leting GlobalDCE know if it is running 
> post-LTO. Both of these should give the same results, but the way I used 
> represents the visibility fully in the IR, without having the extra state of 
> "are we doing LTO?".


Okay, I somehow missed that the relaxation to TranslationUnit was guarded on it 
being LinkageUnit to start with. So at least from that perspective I don't see 
any soundness issues. It still doesn't seem like a good idea to do the 
relaxation in LTO though, since the visibility-outside-of-LTO of the vtable 
symbols is not a reliable indicator whether the type is used externally (I 
think that's what confused me to begin with). Here are a couple of cases where 
things might go wrong:

- Take the example from my earlier message, give the "main executable" and 
"DSO" hidden visibility, build the "main executable" with LTO and the "DSO" 
without LTO, and statically link them both into the same executable. We run 
into the same problem where the `Plugin1` vtable is potentially not referenced 
and thus misoptimised. Yes, this is a violation of the LTO visibility rules, 
but the example shows that we only detect it sometimes. I think that if we did 
want to detect cases where the LTO visibility rules are clearly being violated, 
the outcome should be to issue a diagnostic and not to silently proceed with 
optimizations disabled, since the violation might be masking other undetected 
issues. That really seems orthogonal to this patch, though.
- Imagine linking part of a program with `ld -r` with LTO -- all symbols 
including vtable symbols will appear to be externally visible, which is not 
necessarily a violation of the LTO visibility rules because they may not be 
used externally in the final link. So we end up pessimising unnecessarily.

I gave this some more thought and it seems that the frontend has all of the 
information required to make a determination about whether to allow VFE, 
without needing to teach LTO to relax visibility. We can make the frontend do 
this:

- If `-flto` was passed (see `CodeGenOptions::PrepareForLTO`), attach "allow 
VFE" metadata if class has hidden LTO visibility.
- Otherwise, attach "allow VFE" metadata if class is not `isExternallyVisible`.

Now the behaviour of GlobalDCE can be made conditional on the "allow VFE" 
metadata alone. This also has the advantage of simplifying the IR by making 
"allow VFE" a boolean rather than a tri-state as it is now.




Comment at: llvm/lib/Transforms/IPO/GlobalDCE.cpp:183
+// unit, we know that we can see all virtual functions which might use it,
+// so VFE is safe.
+if (auto GO = dyn_cast()) {

ostannard wrote:
> pcc wrote:
> > Not necessarily, at least in this implementation, because "vtable symbol 
> > can be internalized" doesn't imply "all vcalls are visible". See main 
> > response.
> This is checking the vcall_visibility, which will only be 
> VCallVisibilityTranslationUnit if all base classes which contain virtual 
> functions are private to this translation unit, which does imply "all vcalls 
> are visible".
Ack.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63932/new/

https://reviews.llvm.org/D63932



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

[PATCH] D62574: Initial draft of target-configurable address spaces.

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added inline comments.



Comment at: include/clang/AST/ASTContext.h:2598
+  /// Returns true if address space A overlaps with B.
+  bool isAddressSpaceOverlapping(LangAS A, LangAS B) const {
+// A overlaps with B if either is a superset of the other.

ebevhan wrote:
> Anastasia wrote:
> > ebevhan wrote:
> > > Anastasia wrote:
> > > > Is there any advantage of keeping superset concept? Amd if yes, 
> > > > how do we position the new functionality with explicit cast?
> > > > 
> > > > I think I am missing a bit conceptual view... because I think we 
> > > > originally discussed to switch to implicit/explicit conversion model. 
> > > > Perhaps there is no reason to do it but I would just like to understand 
> > > > why? 
> > > Yes, I know the original discussion was regarding the implicit/explicit 
> > > model, but I came to realize during the implementation that all that was 
> > > needed to get the superspace model to work generically with the current 
> > > behavior was an override on the explicit conversion.
> > > 
> > > The implicit/explicit model also has the drawback that it's a bit too 
> > > expressive. You can express semantics that just don't really make sense, 
> > > like permitting implicit conversion but not explicit conversion. The 
> > > superspace model doesn't let you do that, and the additions I've made 
> > > here still don't: If implicit conversion is allowed, explicit conversion 
> > > must also be allowed. It just becomes possible to allow explicit 
> > > conversion for ASes that don't overlap.
> > > 
> > > Since the superspace model is what OpenCL and Embedded-C use in their 
> > > specification, it's probably better to use that anyway.
> > > The implicit/explicit model also has the drawback that it's a bit too 
> > > expressive. You can express semantics that just don't really make sense, 
> > > like permitting implicit conversion but not explicit conversion. The 
> > > superspace model doesn't let you do that, and the additions I've made 
> > > here still don't: If implicit conversion is allowed, explicit conversion 
> > > must also be allowed. It just becomes possible to allow explicit 
> > > conversion for ASes that don't overlap.
> > 
> > Ok, I think we could define the new model something like - explicit 
> > conversions are automatically allowed for all implicit conversions... 
> > targets won't have to specify those but only extra comversions that are not 
> > allowed implicitly. 
> > 
> > Just to understand in the current patch when are we supposed to use 
> > `isAddressSpaceOverlapping` and when `isExplicitAddrSpaceConversionLegal`. 
> > Can't we just always use `isExplicitAddrSpaceConversionLegal`?
> > 
> > > 
> > > Since the superspace model is what OpenCL and Embedded-C use in their 
> > > specification, it's probably better to use that anyway.
> > 
> > I agree the advantage of following spec is really huge. However, Clang is 
> > already broken for Emdedded C isn't it? Because it allows any explicit 
> > conversions?
> > 
> > As for OpenCL it might be reasonable to provide new documentation if needed 
> > as soon as the new rules don't invalidate all behavior.
> > 
> > 
> > Ok, I think we could define the new model something like - explicit 
> > conversions are automatically allowed for all implicit conversions... 
> > targets won't have to specify those but only extra comversions that are not 
> > allowed implicitly.
> 
> Yes, this is how it's defined. Converting explicitly between two ASes where 
> either one is a superset of the other is always legal.
> 
> > Just to understand in the current patch when are we supposed to use 
> > isAddressSpaceOverlapping and when isExplicitAddrSpaceConversionLegal. 
> > Can't we just always use isExplicitAddrSpaceConversionLegal?
> 
> I guess the distinction between `isAddressSpaceOverlapping` and 
> `isExplicitAddrSpaceConversionLegal` is pretty subtle. You would want the 
> former when you need to know if **implicit conversion A->B or B->A** is 
> permitted, and the latter when you need to know if **explicit conversion 
> A->B** is permitted.
> 
> Though in most cases, I think the latter is probably the most common.
> 
> > I agree the advantage of following spec is really huge. However, Clang is 
> > already broken for Emdedded C isn't it? Because it allows any explicit 
> > conversions?
> 
> No, the current behavior of permitting all explicit conversions is according 
> to spec: "A non-null pointer into an address space A can be cast to a pointer 
> into another address space B, but such a cast is undefined if the source 
> pointer does not point to a location in B." The addition of 
> `isExplicitAddrSpaceConversionLegal` lets targets override this behavior and 
> make such casts non-legal.
I see so we are making the new rules then. I guess it should be fine. However 
we might want to document this better and explain the difference between two 
types of API provided.

[PATCH] D65343: [clang-tidy] Fix the documentation for linuxkernel-must-use-errs.

[Tom Roeder via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367333: [clang-tidy] Fix the documentation for 
linuxkernel-must-use-errs. (authored by tmroeder, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65343?vs=212201=212373#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65343/new/

https://reviews.llvm.org/D65343

Files:
  clang-tools-extra/trunk/docs/ReleaseNotes.rst
  clang-tools-extra/trunk/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst


Index: clang-tools-extra/trunk/docs/ReleaseNotes.rst
===
--- clang-tools-extra/trunk/docs/ReleaseNotes.rst
+++ clang-tools-extra/trunk/docs/ReleaseNotes.rst
@@ -71,15 +71,7 @@
   ` check.
 
   Checks Linux kernel code to see if it uses the results from the functions in
-  ``linux/err.h``. Also checks to see if code uses the results from functions 
that
-  directly return a value from one of these error functions.
-
-  This is important in the Linux kernel because ``ERR_PTR``, ``PTR_ERR``,
-  ``IS_ERR``, ``IS_ERR_OR_NULL``, ``ERR_CAST``, and ``PTR_ERR_OR_ZERO`` return
-  values must be checked, since positive pointers and negative error codes are
-  being used in the same context. These functions are marked with
-  ``__attribute__((warn_unused_result))``, but some kernel versions do not have
-  this warning enabled for clang.
+  ``linux/err.h``.
 
 - New :doc:`google-upgrade-googletest-case
   ` check.
Index: 
clang-tools-extra/trunk/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst
===
--- clang-tools-extra/trunk/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst
+++ clang-tools-extra/trunk/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst
@@ -3,14 +3,16 @@
 linuxkernel-must-use-errs
 =
 
-Checks for cases where the kernel error functions ``ERR_PTR``,
-``PTR_ERR``, ``IS_ERR``, ``IS_ERR_OR_NULL``, ``ERR_CAST``, and
-``PTR_ERR_OR_ZERO`` are called but the results are not used. These
-functions are marked with ``__attribute__((warn_unused_result))``, but
-the compiler warning for this attribute is not always enabled.
-
-This also checks for unused values returned by functions that return
-``ERR_PTR``.
+Checks Linux kernel code to see if it uses the results from the functions in
+``linux/err.h``. Also checks to see if code uses the results from functions 
that
+directly return a value from one of these error functions.
+
+This is important in the Linux kernel because ``ERR_PTR``, ``PTR_ERR``,
+``IS_ERR``, ``IS_ERR_OR_NULL``, ``ERR_CAST``, and ``PTR_ERR_OR_ZERO`` return
+values must be checked, since positive pointers and negative error codes are
+being used in the same context. These functions are marked with
+``__attribute__((warn_unused_result))``, but some kernel versions do not have
+this warning enabled for clang.
 
 Examples:
 


Index: clang-tools-extra/trunk/docs/ReleaseNotes.rst
===
--- clang-tools-extra/trunk/docs/ReleaseNotes.rst
+++ clang-tools-extra/trunk/docs/ReleaseNotes.rst
@@ -71,15 +71,7 @@
   ` check.
 
   Checks Linux kernel code to see if it uses the results from the functions in
-  ``linux/err.h``. Also checks to see if code uses the results from functions that
-  directly return a value from one of these error functions.
-
-  This is important in the Linux kernel because ``ERR_PTR``, ``PTR_ERR``,
-  ``IS_ERR``, ``IS_ERR_OR_NULL``, ``ERR_CAST``, and ``PTR_ERR_OR_ZERO`` return
-  values must be checked, since positive pointers and negative error codes are
-  being used in the same context. These functions are marked with
-  ``__attribute__((warn_unused_result))``, but some kernel versions do not have
-  this warning enabled for clang.
+  ``linux/err.h``.
 
 - New :doc:`google-upgrade-googletest-case
   ` check.
Index: clang-tools-extra/trunk/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst
===
--- clang-tools-extra/trunk/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst
+++ clang-tools-extra/trunk/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst
@@ -3,14 +3,16 @@
 linuxkernel-must-use-errs
 =
 
-Checks for cases where the kernel error functions ``ERR_PTR``,
-``PTR_ERR``, ``IS_ERR``, ``IS_ERR_OR_NULL``, ``ERR_CAST``, and
-``PTR_ERR_OR_ZERO`` are called but the results are not used. These
-functions are marked with ``__attribute__((warn_unused_result))``, but
-the compiler warning for this attribute is not always enabled.
-
-This also checks for unused values returned by functions that return
-``ERR_PTR``.
+Checks Linux kernel code to see if it uses the results from the functions in
+``linux/err.h``. Also checks to see if code uses the results from functions that

[clang-tools-extra] r367333 - [clang-tidy] Fix the documentation for linuxkernel-must-use-errs.

[Tom Roeder via cfe-commits]

Author: tmroeder
Date: Tue Jul 30 09:49:28 2019
New Revision: 367333

URL: http://llvm.org/viewvc/llvm-project?rev=367333=rev
Log:
[clang-tidy] Fix the documentation for linuxkernel-must-use-errs.

Summary:
This changes ReleaseNotes.txt to have the first sentence of the full
documentation from linuxkernel-must-use-errs.rst.

This addresses a comment from the review of rL367071 in
https://reviews.llvm.org/D59963.

Reviewers: Eugene.Zelenko

Subscribers: xazax.hun, cfe-commits

Tags: #clang

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

Modified:
clang-tools-extra/trunk/docs/ReleaseNotes.rst
clang-tools-extra/trunk/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst

Modified: clang-tools-extra/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/ReleaseNotes.rst?rev=367333=367332=367333=diff
==
--- clang-tools-extra/trunk/docs/ReleaseNotes.rst (original)
+++ clang-tools-extra/trunk/docs/ReleaseNotes.rst Tue Jul 30 09:49:28 2019
@@ -71,15 +71,7 @@ Improvements to clang-tidy
   ` check.
 
   Checks Linux kernel code to see if it uses the results from the functions in
-  ``linux/err.h``. Also checks to see if code uses the results from functions 
that
-  directly return a value from one of these error functions.
-
-  This is important in the Linux kernel because ``ERR_PTR``, ``PTR_ERR``,
-  ``IS_ERR``, ``IS_ERR_OR_NULL``, ``ERR_CAST``, and ``PTR_ERR_OR_ZERO`` return
-  values must be checked, since positive pointers and negative error codes are
-  being used in the same context. These functions are marked with
-  ``__attribute__((warn_unused_result))``, but some kernel versions do not have
-  this warning enabled for clang.
+  ``linux/err.h``.
 
 - New :doc:`google-upgrade-googletest-case
   ` check.

Modified: 
clang-tools-extra/trunk/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst?rev=367333=367332=367333=diff
==
--- 
clang-tools-extra/trunk/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst 
(original)
+++ 
clang-tools-extra/trunk/docs/clang-tidy/checks/linuxkernel-must-use-errs.rst 
Tue Jul 30 09:49:28 2019
@@ -3,14 +3,16 @@
 linuxkernel-must-use-errs
 =
 
-Checks for cases where the kernel error functions ``ERR_PTR``,
-``PTR_ERR``, ``IS_ERR``, ``IS_ERR_OR_NULL``, ``ERR_CAST``, and
-``PTR_ERR_OR_ZERO`` are called but the results are not used. These
-functions are marked with ``__attribute__((warn_unused_result))``, but
-the compiler warning for this attribute is not always enabled.
+Checks Linux kernel code to see if it uses the results from the functions in
+``linux/err.h``. Also checks to see if code uses the results from functions 
that
+directly return a value from one of these error functions.
 
-This also checks for unused values returned by functions that return
-``ERR_PTR``.
+This is important in the Linux kernel because ``ERR_PTR``, ``PTR_ERR``,
+``IS_ERR``, ``IS_ERR_OR_NULL``, ``ERR_CAST``, and ``PTR_ERR_OR_ZERO`` return
+values must be checked, since positive pointers and negative error codes are
+being used in the same context. These functions are marked with
+``__attribute__((warn_unused_result))``, but some kernel versions do not have
+this warning enabled for clang.
 
 Examples:
 


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

[PATCH] D63932: [GlobalDCE] Dead Virtual Function Elimination

[Oliver Stannard (Linaro) via Phabricator via cfe-commits]

ostannard updated this revision to Diff 212370.
ostannard marked 2 inline comments as done.
ostannard added a comment.

- Rebase
- Don't emit llvm.assume when not necessary (we already weren't checking for 
it's presence in GlobalDCE)
- s/"public"/"default"/ in IR docs


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63932/new/

https://reviews.llvm.org/D63932

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/CodeGen/CGClass.cpp
  clang/lib/CodeGen/CGVTables.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGenCXX/vcall-visibility-metadata.cpp
  clang/test/CodeGenCXX/virtual-function-elimination.cpp
  clang/test/Driver/virtual-function-elimination.cpp
  llvm/docs/LangRef.rst
  llvm/docs/TypeMetadata.rst
  llvm/include/llvm/Analysis/TypeMetadataUtils.h
  llvm/include/llvm/IR/FixedMetadataKinds.def
  llvm/include/llvm/IR/GlobalObject.h
  llvm/include/llvm/Transforms/IPO/GlobalDCE.h
  llvm/lib/Analysis/TypeMetadataUtils.cpp
  llvm/lib/IR/Metadata.cpp
  llvm/lib/LTO/LTO.cpp
  llvm/lib/Transforms/IPO/GlobalDCE.cpp
  llvm/lib/Transforms/IPO/Internalize.cpp
  llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp
  llvm/test/LTO/ARM/vcall-visibility.ll
  llvm/test/ThinLTO/X86/lazyload_metadata.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions-base-call.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions-base-pointer-call.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions-derived-call.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions-derived-pointer-call.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions.ll
  llvm/test/Transforms/Internalize/vcall-visibility.ll

Index: llvm/test/Transforms/Internalize/vcall-visibility.ll
===
--- /dev/null
+++ llvm/test/Transforms/Internalize/vcall-visibility.ll
@@ -0,0 +1,64 @@
+; RUN: opt < %s -internalize -S | FileCheck %s
+
+%struct.A = type { i32 (...)** }
+%struct.B = type { i32 (...)** }
+%struct.C = type { i32 (...)** }
+
+; Class A has default visibility, so has no !vcall_visibility metadata before
+; or after LTO.
+; CHECK-NOT: @_ZTV1A = {{.*}}!vcall_visibility
+@_ZTV1A = dso_local unnamed_addr constant { [3 x i8*] } { [3 x i8*] [i8* null, i8* null, i8* bitcast (void (%struct.A*)* @_ZN1A3fooEv to i8*)] }, align 8, !type !0, !type !1
+
+; Class B has hidden visibility but public LTO visibility, so has no
+; !vcall_visibility metadata before or after LTO.
+; CHECK-NOT: @_ZTV1B = {{.*}}!vcall_visibility
+@_ZTV1B = hidden unnamed_addr constant { [3 x i8*] } { [3 x i8*] [i8* null, i8* null, i8* bitcast (void (%struct.B*)* @_ZN1B3fooEv to i8*)] }, align 8, !type !2, !type !3
+
+; Class C has hidden visibility, so the !vcall_visibility metadata is set to 1
+; (linkage unit) before LTO, and 2 (translation unit) after LTO.
+; CHECK: @_ZTV1C ={{.*}}!vcall_visibility [[MD_TU_VIS:![0-9]+]]
+@_ZTV1C = hidden unnamed_addr constant { [3 x i8*] } { [3 x i8*] [i8* null, i8* null, i8* bitcast (void (%struct.C*)* @_ZN1C3fooEv to i8*)] }, align 8, !type !4, !type !5, !vcall_visibility !6
+
+; Class D has translation unit visibility before LTO, and this is not changed
+; by LTO.
+; CHECK: @_ZTVN12_GLOBAL__N_11DE = {{.*}}!vcall_visibility [[MD_TU_VIS:![0-9]+]]
+@_ZTVN12_GLOBAL__N_11DE = internal unnamed_addr constant { [3 x i8*] } zeroinitializer, align 8, !type !7, !type !9, !vcall_visibility !11
+
+define dso_local void @_ZN1A3fooEv(%struct.A* nocapture %this) {
+entry:
+  ret void
+}
+
+define hidden void @_ZN1B3fooEv(%struct.B* nocapture %this) {
+entry:
+  ret void
+}
+
+define hidden void @_ZN1C3fooEv(%struct.C* nocapture %this) {
+entry:
+  ret void
+}
+
+define hidden noalias nonnull i8* @_Z6make_dv() {
+entry:
+  %call = tail call i8* @_Znwm(i64 8) #3
+  %0 = bitcast i8* %call to i32 (...)***
+  store i32 (...)** bitcast (i8** getelementptr inbounds ({ [3 x i8*] }, { [3 x i8*] }* @_ZTVN12_GLOBAL__N_11DE, i64 0, inrange i32 0, i64 2) to i32 (...)**), i32 (...)*** %0, align 8
+  ret i8* %call
+}
+
+declare dso_local noalias nonnull i8* @_Znwm(i64)
+
+; CHECK: [[MD_TU_VIS]] = !{i64 2}
+!0 = !{i64 16, !"_ZTS1A"}
+!1 = !{i64 16, !"_ZTSM1AFvvE.virtual"}
+!2 = !{i64 16, !"_ZTS1B"}
+!3 = !{i64 16, !"_ZTSM1BFvvE.virtual"}
+!4 = !{i64 16, !"_ZTS1C"}
+!5 = !{i64 16, !"_ZTSM1CFvvE.virtual"}
+!6 = !{i64 1}
+!7 = !{i64 16, !8}
+!8 = distinct !{}
+!9 = !{i64 16, !10}
+!10 = distinct !{}
+!11 = !{i64 2}
Index: llvm/test/Transforms/GlobalDCE/virtual-functions.ll
===
--- /dev/null
+++ llvm/test/Transforms/GlobalDCE/virtual-functions.ll
@@ -0,0 +1,55 @@
+; RUN: opt < %s -globaldce -S | FileCheck %s
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+
+declare dso_local noalias nonnull i8* 

[PATCH] D65456: [OpenCL] Add generic type handling for builtin functions

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh added a comment.

Main changes since D63434 :

- Rename List* to Vec*.
- Rename TLnn -> TLAll, TLInt, TLFloat.
- Apply clang-format.
- Improve/update documentation.
- Factor out renaming of base types into separate commit.
- Change return type of OCL2Qual.
- Remove default case from OCL2Qual switch statement: it should be fully 
covering the enum.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65456/new/

https://reviews.llvm.org/D65456



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

[PATCH] D65458: [NFC] Remove LLVM_ALIGNAS

[JF Bastien via Phabricator via cfe-commits]

jfb created this revision.
jfb added a reviewer: rnk.
Herald added subscribers: llvm-commits, cfe-commits, dexonsmith, jkorous, 
mgorny.
Herald added projects: clang, LLVM.

The minimum compilers support all have alignas, and we don't use LLVM_ALIGNAS 
anywhere anymore. This also removes an MSVC diagnostic which, according to the 
comment above, isn't relevant anymore.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65458

Files:
  clang-tools-extra/docs/doxygen.cfg.in
  clang/docs/doxygen.cfg.in
  llvm/cmake/modules/HandleLLVMOptions.cmake
  llvm/docs/doxygen.cfg.in
  llvm/include/llvm/Support/Compiler.h
  llvm/unittests/Support/AlignOfTest.cpp

Index: llvm/unittests/Support/AlignOfTest.cpp
===
--- llvm/unittests/Support/AlignOfTest.cpp
+++ llvm/unittests/Support/AlignOfTest.cpp
@@ -38,10 +38,10 @@
 #endif
 
 // Define some fixed alignment types to use in these tests.
-struct LLVM_ALIGNAS(1) A1 {};
-struct LLVM_ALIGNAS(2) A2 {};
-struct LLVM_ALIGNAS(4) A4 {};
-struct LLVM_ALIGNAS(8) A8 {};
+struct alignas(1) A1 {};
+struct alignas(2) A2 {};
+struct alignas(4) A4 {};
+struct alignas(8) A8 {};
 
 struct S1 {};
 struct S2 { char a; };
Index: llvm/include/llvm/Support/Compiler.h
===
--- llvm/include/llvm/Support/Compiler.h
+++ llvm/include/llvm/Support/Compiler.h
@@ -338,14 +338,6 @@
 # define LLVM_ASSUME_ALIGNED(p, a) (p)
 #endif
 
-/// \macro LLVM_ALIGNAS
-/// Used to specify a minimum alignment for a structure or variable.
-#if __GNUC__ && !__has_feature(cxx_alignas) && !LLVM_GNUC_PREREQ(4, 8, 1)
-# define LLVM_ALIGNAS(x) __attribute__((aligned(x)))
-#else
-# define LLVM_ALIGNAS(x) alignas(x)
-#endif
-
 /// \macro LLVM_PACKED
 /// Used to specify a packed structure.
 /// LLVM_PACKED(
@@ -376,8 +368,8 @@
 
 /// \macro LLVM_PTR_SIZE
 /// A constant integer equivalent to the value of sizeof(void*).
-/// Generally used in combination with LLVM_ALIGNAS or when doing computation in
-/// the preprocessor.
+/// Generally used in combination with alignas or when doing computation in the
+/// preprocessor.
 #ifdef __SIZEOF_POINTER__
 # define LLVM_PTR_SIZE __SIZEOF_POINTER__
 #elif defined(_WIN64)
Index: llvm/docs/doxygen.cfg.in
===
--- llvm/docs/doxygen.cfg.in
+++ llvm/docs/doxygen.cfg.in
@@ -1926,7 +1926,7 @@
 # recursively expanded use the := operator instead of the = operator.
 # This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
 
-PREDEFINED = LLVM_ALIGNAS(x)=
+PREDEFINED =
 
 # If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
 # tag can be used to specify a list of macro names that should be expanded. The
Index: llvm/cmake/modules/HandleLLVMOptions.cmake
===
--- llvm/cmake/modules/HandleLLVMOptions.cmake
+++ llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -542,14 +542,6 @@
   # is fixed.
   -wd4709 # Suppress comma operator within array index expression
 
-  # Ideally, we'd like this warning to be enabled, but MSVC 2013 doesn't
-  # support the 'aligned' attribute in the way that clang sources requires (for
-  # any code that uses the LLVM_ALIGNAS macro), so this is must be disabled to
-  # avoid unwanted alignment warnings.
-  # When we switch to requiring a version of MSVC that supports the 'alignas'
-  # specifier (MSVC 2015?) this warning can be re-enabled.
-  -wd4324 # Suppress 'structure was padded due to __declspec(align())'
-
   # Promoted warnings.
   -w14062 # Promote 'enumerator in switch of enum is not handled' to level 1 warning.
 
Index: clang/docs/doxygen.cfg.in
===
--- clang/docs/doxygen.cfg.in
+++ clang/docs/doxygen.cfg.in
@@ -1925,7 +1925,7 @@
 # recursively expanded use the := operator instead of the = operator.
 # This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
 
-PREDEFINED = LLVM_ALIGNAS(x)=
+PREDEFINED =
 
 # If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
 # tag can be used to specify a list of macro names that should be expanded. The
Index: clang-tools-extra/docs/doxygen.cfg.in
===
--- clang-tools-extra/docs/doxygen.cfg.in
+++ clang-tools-extra/docs/doxygen.cfg.in
@@ -1937,7 +1937,7 @@
 # recursively expanded use the := operator instead of the = operator.
 # This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
 
-PREDEFINED = LLVM_ALIGNAS(x)=
+PREDEFINED =
 
 # If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
 # tag can be used to specify a list of macro names that should be expanded. The
___