r350459 - [CMake][Fuchsia] Enable --build-id linker flag by default

[Petr Hosek via cfe-commits]

Author: phosek
Date: Fri Jan  4 23:57:38 2019
New Revision: 350459

URL: http://llvm.org/viewvc/llvm-project?rev=350459&view=rev
Log:
[CMake][Fuchsia] Enable --build-id linker flag by default

This enables passing --build-id to linker by default.

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

Modified:
cfe/trunk/cmake/caches/Fuchsia-stage2.cmake

Modified: cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/Fuchsia-stage2.cmake?rev=350459&r1=350458&r2=350459&view=diff
==
--- cfe/trunk/cmake/caches/Fuchsia-stage2.cmake (original)
+++ cfe/trunk/cmake/caches/Fuchsia-stage2.cmake Fri Jan  4 23:57:38 2019
@@ -14,6 +14,8 @@ set(LLVM_ENABLE_ZLIB ON CACHE BOOL "")
 set(LLVM_EXTERNALIZE_DEBUGINFO ON CACHE BOOL "")
 set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "")
 
+set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
+
 set(LLVM_ENABLE_LTO ON CACHE BOOL "")
 if(NOT APPLE)
   set(LLVM_ENABLE_LLD ON CACHE BOOL "")


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

r350461 - [CMake][Fuchsia] Enable experimental new pass manager by default

[Petr Hosek via cfe-commits]

Author: phosek
Date: Fri Jan  4 23:57:53 2019
New Revision: 350461

URL: http://llvm.org/viewvc/llvm-project?rev=350461&view=rev
Log:
[CMake][Fuchsia] Enable experimental new pass manager by default

This change enableds experimental new pass manager.

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

Modified:
cfe/trunk/cmake/caches/Fuchsia-stage2.cmake

Modified: cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/Fuchsia-stage2.cmake?rev=350461&r1=350460&r2=350461&view=diff
==
--- cfe/trunk/cmake/caches/Fuchsia-stage2.cmake (original)
+++ cfe/trunk/cmake/caches/Fuchsia-stage2.cmake Fri Jan  4 23:57:53 2019
@@ -16,6 +16,7 @@ set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL
 
 set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
 set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
+set(ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER ON CACHE BOOL "")
 
 set(LLVM_ENABLE_LTO ON CACHE BOOL "")
 if(NOT APPLE)


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

[PATCH] D56348: [CMake][Fuchsia] Enable --build-id linker flag by default

[Petr Hosek via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL350459: [CMake][Fuchsia] Enable --build-id linker flag by 
default (authored by phosek, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D56348?vs=180355&id=180358#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D56348

Files:
  cfe/trunk/cmake/caches/Fuchsia-stage2.cmake


Index: cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
===
--- cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
+++ cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
@@ -14,6 +14,8 @@
 set(LLVM_EXTERNALIZE_DEBUGINFO ON CACHE BOOL "")
 set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "")
 
+set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
+
 set(LLVM_ENABLE_LTO ON CACHE BOOL "")
 if(NOT APPLE)
   set(LLVM_ENABLE_LLD ON CACHE BOOL "")


Index: cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
===
--- cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
+++ cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
@@ -14,6 +14,8 @@
 set(LLVM_EXTERNALIZE_DEBUGINFO ON CACHE BOOL "")
 set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "")
 
+set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
+
 set(LLVM_ENABLE_LTO ON CACHE BOOL "")
 if(NOT APPLE)
   set(LLVM_ENABLE_LLD ON CACHE BOOL "")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r350460 - [CMake][Fuchsia] Enable x86 relaxation by default

[Petr Hosek via cfe-commits]

Author: phosek
Date: Fri Jan  4 23:57:46 2019
New Revision: 350460

URL: http://llvm.org/viewvc/llvm-project?rev=350460&view=rev
Log:
[CMake][Fuchsia] Enable x86 relaxation by default

This enables x86 relaxation by default. This depends on a linker new
enough to support the new reloc types but since we default to lld we
don't worry about host system linkers that might be too old to support
the new reloc types.

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

Modified:
cfe/trunk/cmake/caches/Fuchsia-stage2.cmake

Modified: cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/Fuchsia-stage2.cmake?rev=350460&r1=350459&r2=350460&view=diff
==
--- cfe/trunk/cmake/caches/Fuchsia-stage2.cmake (original)
+++ cfe/trunk/cmake/caches/Fuchsia-stage2.cmake Fri Jan  4 23:57:46 2019
@@ -15,6 +15,7 @@ set(LLVM_EXTERNALIZE_DEBUGINFO ON CACHE
 set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "")
 
 set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
+set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
 
 set(LLVM_ENABLE_LTO ON CACHE BOOL "")
 if(NOT APPLE)


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

[PATCH] D56349: [CMake][Fuchsia] Enable x86 relaxation by default

[Petr Hosek via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC350460: [CMake][Fuchsia] Enable x86 relaxation by default 
(authored by phosek, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D56349?vs=180356&id=180359#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D56349

Files:
  cmake/caches/Fuchsia-stage2.cmake


Index: cmake/caches/Fuchsia-stage2.cmake
===
--- cmake/caches/Fuchsia-stage2.cmake
+++ cmake/caches/Fuchsia-stage2.cmake
@@ -15,6 +15,7 @@
 set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "")
 
 set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
+set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
 
 set(LLVM_ENABLE_LTO ON CACHE BOOL "")
 if(NOT APPLE)


Index: cmake/caches/Fuchsia-stage2.cmake
===
--- cmake/caches/Fuchsia-stage2.cmake
+++ cmake/caches/Fuchsia-stage2.cmake
@@ -15,6 +15,7 @@
 set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "")
 
 set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
+set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
 
 set(LLVM_ENABLE_LTO ON CACHE BOOL "")
 if(NOT APPLE)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56350: [CMake][Fuchsia] Enable experimental new pass manager by default

[Petr Hosek via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC350461: [CMake][Fuchsia] Enable experimental new pass 
manager by default (authored by phosek, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D56350?vs=180357&id=180360#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D56350

Files:
  cmake/caches/Fuchsia-stage2.cmake


Index: cmake/caches/Fuchsia-stage2.cmake
===
--- cmake/caches/Fuchsia-stage2.cmake
+++ cmake/caches/Fuchsia-stage2.cmake
@@ -16,6 +16,7 @@
 
 set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
 set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
+set(ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER ON CACHE BOOL "")
 
 set(LLVM_ENABLE_LTO ON CACHE BOOL "")
 if(NOT APPLE)


Index: cmake/caches/Fuchsia-stage2.cmake
===
--- cmake/caches/Fuchsia-stage2.cmake
+++ cmake/caches/Fuchsia-stage2.cmake
@@ -16,6 +16,7 @@
 
 set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
 set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
+set(ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER ON CACHE BOOL "")
 
 set(LLVM_ENABLE_LTO ON CACHE BOOL "")
 if(NOT APPLE)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56341: [python] Make the collections import future-proof

[serge via Phabricator via cfe-commits]

serge-sans-paille accepted this revision.
serge-sans-paille added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rC Clang

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

https://reviews.llvm.org/D56341



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

[PATCH] D56341: [python] Make the collections import future-proof

[Jakub Stasiak via Phabricator via cfe-commits]

jstasiak added a comment.

Thanks. If you could commit this on my behalf I'd appreciate it (I don't have 
commit access).


Repository:
  rC Clang

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

https://reviews.llvm.org/D56341



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

[clang-tools-extra] r350466 - [Documentation] fix order of checks in checks/list.rst

[Jonas Toth via cfe-commits]

Author: jonastoth
Date: Sat Jan  5 03:40:05 2019
New Revision: 350466

URL: http://llvm.org/viewvc/llvm-project?rev=350466&view=rev
Log:
[Documentation] fix order of checks in checks/list.rst

Modified:
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst?rev=350466&r1=350465&r2=350466&view=diff
==
--- clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst (original)
+++ clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst Sat Jan  5 03:40:05 
2019
@@ -13,8 +13,8 @@ Clang-Tidy Checks
abseil-no-internal-dependencies
abseil-no-namespace
abseil-redundant-strcat-calls
-   abseil-string-find-startswith
abseil-str-cat-append
+   abseil-string-find-startswith
abseil-upgrade-duration-conversions
android-cloexec-accept
android-cloexec-accept4
@@ -91,8 +91,8 @@ Clang-Tidy Checks
cert-msc50-cpp
cert-msc51-cpp
cert-oop11-cpp (redirects to performance-move-constructor-init) 

-   cppcoreguidelines-avoid-goto
cppcoreguidelines-avoid-c-arrays (redirects to modernize-avoid-c-arrays) 

+   cppcoreguidelines-avoid-goto
cppcoreguidelines-avoid-magic-numbers (redirects to 
readability-magic-numbers) 
cppcoreguidelines-c-copy-assignment-signature (redirects to 
misc-unconventional-assign-operator) 

cppcoreguidelines-interfaces-global-init
@@ -159,6 +159,7 @@ Clang-Tidy Checks
hicpp-special-member-functions (redirects to 
cppcoreguidelines-special-member-functions) 
hicpp-static-assert (redirects to misc-static-assert) 
hicpp-undelegated-constructor (redirects to 
bugprone-undelegated-constructor) 
+   hicpp-uppercase-literal-suffix (redirects to 
readability-uppercase-literal-suffix) 
hicpp-use-auto (redirects to modernize-use-auto) 
hicpp-use-emplace (redirects to modernize-use-emplace) 
hicpp-use-equals-default (redirects to modernize-use-equals-default) 

@@ -167,7 +168,6 @@ Clang-Tidy Checks
hicpp-use-nullptr (redirects to modernize-use-nullptr) 
hicpp-use-override (redirects to modernize-use-override) 

hicpp-vararg (redirects to cppcoreguidelines-pro-type-vararg) 
-   hicpp-uppercase-literal-suffix (redirects to 
readability-uppercase-literal-suffix) 
llvm-header-guard
llvm-include-order
llvm-namespace-comment


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

r350467 - [python] Make the collections import future-proof

[Serge Guelton via cfe-commits]

Author: serge_sans_paille
Date: Sat Jan  5 04:07:36 2019
New Revision: 350467

URL: http://llvm.org/viewvc/llvm-project?rev=350467&view=rev
Log:
[python] Make the collections import future-proof

On Python 3.7 the old code raises a warning:

DeprecationWarning: Using or importing the ABCs from 'collections' 
instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
class ArgumentsIterator(collections.Sequence):

On Python 3.8 it wouldn't work anymore.

Commited on behalf of Jakub Stasiak.

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

Modified:
cfe/trunk/bindings/python/clang/cindex.py

Modified: cfe/trunk/bindings/python/clang/cindex.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/bindings/python/clang/cindex.py?rev=350467&r1=350466&r2=350467&view=diff
==
--- cfe/trunk/bindings/python/clang/cindex.py (original)
+++ cfe/trunk/bindings/python/clang/cindex.py Sat Jan  5 04:07:36 2019
@@ -64,7 +64,6 @@ from __future__ import absolute_import,
 # o implement additional SourceLocation, SourceRange, and File methods.
 
 from ctypes import *
-import collections
 
 import clang.enumerations
 
@@ -123,6 +122,14 @@ elif sys.version_info[0] == 2:
 def b(x):
 return x
 
+# Importing ABC-s directly from collections is deprecated since Python 3.7,
+# will stop working in Python 3.8.
+# See: https://docs.python.org/dev/whatsnew/3.7.html#id3
+if sys.version_info[:2] >= (3, 7):
+from collections import abc as collections_abc
+else:
+import collections as collections_abc
+
 # We only support PathLike objects on Python version with os.fspath present
 # to be consistent with the Python standard library. On older Python versions
 # we only support strings and we have dummy fspath to just pass them through.
@@ -2181,7 +2188,7 @@ class Type(Structure):
 The returned object is iterable and indexable. Each item in the
 container is a Type instance.
 """
-class ArgumentsIterator(collections.Sequence):
+class ArgumentsIterator(collections_abc.Sequence):
 def __init__(self, parent):
 self.parent = parent
 self.length = None


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

[PATCH] D56341: [python] Make the collections import future-proof

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC350467: [python] Make the collections import future-proof 
(authored by serge_sans_paille, committed by ).

Repository:
  rC Clang

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

https://reviews.llvm.org/D56341

Files:
  bindings/python/clang/cindex.py


Index: bindings/python/clang/cindex.py
===
--- bindings/python/clang/cindex.py
+++ bindings/python/clang/cindex.py
@@ -64,7 +64,6 @@
 # o implement additional SourceLocation, SourceRange, and File methods.
 
 from ctypes import *
-import collections
 
 import clang.enumerations
 
@@ -123,6 +122,14 @@
 def b(x):
 return x
 
+# Importing ABC-s directly from collections is deprecated since Python 3.7,
+# will stop working in Python 3.8.
+# See: https://docs.python.org/dev/whatsnew/3.7.html#id3
+if sys.version_info[:2] >= (3, 7):
+from collections import abc as collections_abc
+else:
+import collections as collections_abc
+
 # We only support PathLike objects on Python version with os.fspath present
 # to be consistent with the Python standard library. On older Python versions
 # we only support strings and we have dummy fspath to just pass them through.
@@ -2181,7 +2188,7 @@
 The returned object is iterable and indexable. Each item in the
 container is a Type instance.
 """
-class ArgumentsIterator(collections.Sequence):
+class ArgumentsIterator(collections_abc.Sequence):
 def __init__(self, parent):
 self.parent = parent
 self.length = None


Index: bindings/python/clang/cindex.py
===
--- bindings/python/clang/cindex.py
+++ bindings/python/clang/cindex.py
@@ -64,7 +64,6 @@
 # o implement additional SourceLocation, SourceRange, and File methods.
 
 from ctypes import *
-import collections
 
 import clang.enumerations
 
@@ -123,6 +122,14 @@
 def b(x):
 return x
 
+# Importing ABC-s directly from collections is deprecated since Python 3.7,
+# will stop working in Python 3.8.
+# See: https://docs.python.org/dev/whatsnew/3.7.html#id3
+if sys.version_info[:2] >= (3, 7):
+from collections import abc as collections_abc
+else:
+import collections as collections_abc
+
 # We only support PathLike objects on Python version with os.fspath present
 # to be consistent with the Python standard library. On older Python versions
 # we only support strings and we have dummy fspath to just pass them through.
@@ -2181,7 +2188,7 @@
 The returned object is iterable and indexable. Each item in the
 container is a Type instance.
 """
-class ArgumentsIterator(collections.Sequence):
+class ArgumentsIterator(collections_abc.Sequence):
 def __init__(self, parent):
 self.parent = parent
 self.length = None
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56353: Replace cc1 options '-mdisable-fp-elim' and '-momit-leaf-frame-pointer' with'-mframe-pointer='

[Yuanfang Chen via Phabricator via cfe-commits]

tabloid.adroit created this revision.
tabloid.adroit added reviewers: chandlerc, rnk, t.p.northover.
Herald added a subscriber: cfe-commits.

set cc1 '-mframe-pointer=' according to driver options 
m(no-)omit-leaf-frame-pointer
and f(no-)omit-frame-pointer

This makes -fomit-frame-pointer imply -momit-leaf-frame-pointer.
This matches GCC's behavior. PR9825

following up
https://reviews.llvm.org/D56351

related:
https://reviews.llvm.org/D55915


Repository:
  rC Clang

https://reviews.llvm.org/D56353

Files:
  include/clang/Basic/CodeGenOptions.def
  include/clang/Basic/CodeGenOptions.h
  include/clang/Driver/CC1Options.td
  include/clang/Driver/Options.td
  lib/CodeGen/CGCall.cpp
  lib/Driver/ToolChains/Clang.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/CodeGen/x86_64-profiling-keep-fp.c
  test/CodeGenCXX/global-init.cpp
  test/CodeGenObjCXX/msabi-stret.mm
  test/Driver/cl-options.c
  test/Driver/clang-translation.c
  test/Driver/frame-pointer-elim.c
  test/Driver/frame-pointer.c
  test/Driver/woa-fp.c
  test/Driver/xcore-opts.c

Index: test/Driver/xcore-opts.c
===
--- test/Driver/xcore-opts.c
+++ test/Driver/xcore-opts.c
@@ -3,9 +3,8 @@
 // RUN: %clang -target xcore -x c++ %s -fexceptions -### -o %t.o 2>&1 | FileCheck -check-prefix CHECK-EXCEP %s
 // RUN: %clang -target xcore %s -g0 -### -o %t.o 2>&1 | FileCheck -check-prefix CHECK-G0 %s
 
+// CHECK: "-mframe-pointer=none"
 // CHECK: "-nostdsysteminc"
-// CHECK: "-momit-leaf-frame-pointer"
-// CHECK-NOT: "-mdisable-fp-elim"
 // CHECK: "-fno-signed-char"
 // CHECK: "-fno-use-cxa-atexit"
 // CHECK-NOT: "-fcxx-exceptions"
Index: test/Driver/woa-fp.c
===
--- test/Driver/woa-fp.c
+++ test/Driver/woa-fp.c
@@ -34,7 +34,7 @@
 // RUN: %clang -target armv7-windows-itanium -fno-omit-frame-pointer -### -S %s -O3 -o /dev/null 2>&1 | FileCheck %s -check-prefix CHECK-NO-FPO
 // RUN: %clang -target armv7-windows-itanium -fno-omit-frame-pointer -### -S %s -Os -o /dev/null 2>&1 | FileCheck %s -check-prefix CHECK-NO-FPO
 
-// CHECK-DEFAULT: "-mdisable-fp-elim"
-// CHECK-FPO-NOT: "-mdisable-fp-elim"
-// CHECK-NO-FPO: "-mdisable-fp-elim"
+// CHECK-DEFAULT: "-mframe-pointer=all"
+// CHECK-FPO-NOT: "-mframe-pointer=all"
+// CHECK-NO-FPO: "-mframe-pointer=all"
 
Index: test/Driver/frame-pointer.c
===
--- test/Driver/frame-pointer.c
+++ test/Driver/frame-pointer.c
@@ -57,15 +57,15 @@
 // RUN: %clang -target riscv64-unknown-linux-gnu -### -S -O3 %s -o %t.s 2>&1 | FileCheck -check-prefix=CHECK3-64 %s
 // RUN: %clang -target riscv64-unknown-linux-gnu -### -S -Os %s -o %t.s 2>&1 | FileCheck -check-prefix=CHECKs-64 %s
 
-// CHECK0-32: -mdisable-fp-elim
-// CHECK1-32-NOT: -mdisable-fp-elim
-// CHECK2-32-NOT: -mdisable-fp-elim
-// CHECK3-32-NOT: -mdisable-fp-elim
-// CHECKs-32-NOT: -mdisable-fp-elim
+// CHECK0-32: -mframe-pointer=all
+// CHECK1-32-NOT: -mframe-pointer=all
+// CHECK2-32-NOT: -mframe-pointer=all
+// CHECK3-32-NOT: -mframe-pointer=all
+// CHECKs-32-NOT: -mframe-pointer=all
 
-// CHECK0-64: -mdisable-fp-elim
-// CHECK1-64-NOT: -mdisable-fp-elim
-// CHECK2-64-NOT: -mdisable-fp-elim
-// CHECK3-64-NOT: -mdisable-fp-elim
-// CHECKs-64-NOT: -mdisable-fp-elim
-// CHECK-MACHO-64: -mdisable-fp-elim
+// CHECK0-64: -mframe-pointer=all
+// CHECK1-64-NOT: -mframe-pointer=all
+// CHECK2-64-NOT: -mframe-pointer=all
+// CHECK3-64-NOT: -mframe-pointer=all
+// CHECKs-64-NOT: -mframe-pointer=all
+// CHECK-MACHO-64: -mframe-pointer=all
Index: test/Driver/frame-pointer-elim.c
===
--- test/Driver/frame-pointer-elim.c
+++ test/Driver/frame-pointer-elim.c
@@ -2,65 +2,62 @@
 // pointer, for unoptimized we should have a leaf frame pointer.
 // RUN: %clang -### -target i386-pc-linux-gnu -S -O1 %s 2>&1 | \
 // RUN:   FileCheck --check-prefix=LINUX-OPT %s
-// LINUX-OPT: "-momit-leaf-frame-pointer"
+// LINUX-OPT: "-mframe-pointer=none"
 
 // RUN: %clang -### -target i386-pc-linux-gnu -S %s 2>&1 | \
 // RUN:   FileCheck --check-prefix=LINUX %s
-// LINUX-NOT: "-momit-leaf-frame-pointer"
+// LINUX: "-mframe-pointer=all"
 
 // CloudABI follows the same rules as Linux.
 // RUN: %clang -### -target x86_64-unknown-cloudabi -S -O1 %s 2>&1 | \
 // RUN:   FileCheck --check-prefix=CLOUDABI-OPT %s
-// CLOUDABI-OPT: "-momit-leaf-frame-pointer"
+// CLOUDABI-OPT: "-mframe-pointer=none"
 
 // RUN: %clang -### -target x86_64-unknown-cloudabi -S %s 2>&1 | \
 // RUN:   FileCheck --check-prefix=CLOUDABI %s
-// CLOUDABI-NOT: "-momit-leaf-frame-pointer"
+// CLOUDABI: "-mframe-pointer=all"
 
 // NetBSD follows the same rules as Linux.
 // RUN: %clang -### -target x86_64-unknown-netbsd -S -O1 %s 2>&1 | \
 // RUN:   FileCheck --check-prefix=NETBSD-OPT %s
-// NETBSD-OPT: "-momit-leaf-frame-pointer"
+// NETBSD-OPT: "-mframe-pointer=none"
 
 // RUN: %clang -### -target x86_6

[PATCH] D55915: [Driver] Make -fno-omit-frame-pointer imply -mno-omit-leaf-frame-pointer

[Yuanfang Chen via Phabricator via cfe-commits]

tabloid.adroit added a comment.

https://reviews.llvm.org/D56351
https://reviews.llvm.org/D56353


Repository:
  rC Clang

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

https://reviews.llvm.org/D55915



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

[PATCH] D56323: [clang-tidy] Handle member variables in readability-simplify-boolean-expr

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added a comment.

Thanks for the patch. Is this revision dependent on D56303 
 (or other way around)?




Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:464
   bool Value, StringRef Id) {
-  auto SimpleThen = binaryOperator(
-  hasOperatorName("="),
-  hasLHS(declRefExpr(hasDeclaration(decl().bind(IfAssignObjId,
-  hasLHS(expr().bind(IfAssignVariableId)),
-  hasRHS(cxxBoolLiteral(equals(Value)).bind(IfAssignLocId)));
-  auto Then = anyOf(SimpleThen, compoundStmt(statementCountIs(1),
- hasAnySubstatement(SimpleThen)));
-  auto SimpleElse = binaryOperator(
-  hasOperatorName("="),
-  hasLHS(declRefExpr(hasDeclaration(equalsBoundNode(IfAssignObjId,
-  hasRHS(cxxBoolLiteral(equals(!Value;
-  auto Else = anyOf(SimpleElse, compoundStmt(statementCountIs(1),
- hasAnySubstatement(SimpleElse)));
+  const auto VarAssign =
+  declRefExpr(hasDeclaration(decl().bind(IfAssignVarId)));

The `const` for these locals in uncommon in clang-tidy, given its a value type. 
I am not strongly against them, but would prefer consistency.



Comment at: test/clang-tidy/readability-simplify-bool-expr-members.cpp:4
+struct X {
+  explicit operator bool();
+};

I didn't see a test that utilized this struct, did I overlook it?

Implicit conversion to `bool`-cases would be interesting as well. Maybe 
implicit conversion to integral in general.



Comment at: test/clang-tidy/readability-simplify-bool-expr-members.cpp:35
+  bool m_b3 = false;
+  bool m_b4 = false;
+  int *m_p = nullptr;

Would bitfields with a single bit be of interest as well?



Comment at: test/clang-tidy/readability-simplify-bool-expr-members.cpp:160
+  // CHECK-MESSAGES: :[[@LINE-1]]:21: warning: {{.*}} in ternary expression 
result
+  // CHECK-FIXES: {{^  m_b2 = i <= 20;$}}
+

For this case the logical inversion is simple an obviously `<=`, but what if 
the condition is more complex?

I would personally prefer `!(i < 20)` instead + complex logical expressions as 
additional test. They would be interesting for the `if` cases, too.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56323



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

[PATCH] D56354: Replace asserts with if() in SourceLocation accessors

[Stephen Kelly via Phabricator via cfe-commits]

steveire created this revision.
steveire added a reviewer: aaron.ballman.
Herald added a subscriber: cfe-commits.

Nowhere else in the AST classes assert on these kinds of accessors.

This way, we can call the accessors and check the validity of the result
instead of externally duplicating the conditions.  This generality will
make it possible to introspect instances for source locations:

http://ec2-18-191-7-3.us-east-2.compute.amazonaws.com:10240/z/iiaWhw


Repository:
  rC Clang

https://reviews.llvm.org/D56354

Files:
  include/clang/AST/DeclarationName.h
  include/clang/AST/TemplateBase.h
  lib/AST/NestedNameSpecifier.cpp


Index: lib/AST/NestedNameSpecifier.cpp
===
--- lib/AST/NestedNameSpecifier.cpp
+++ lib/AST/NestedNameSpecifier.cpp
@@ -462,9 +462,9 @@
 }
 
 TypeLoc NestedNameSpecifierLoc::getTypeLoc() const {
-  assert((Qualifier->getKind() == NestedNameSpecifier::TypeSpec ||
-  Qualifier->getKind() == NestedNameSpecifier::TypeSpecWithTemplate) &&
- "Nested-name-specifier location is not a type");
+  if ((Qualifier->getKind() != NestedNameSpecifier::TypeSpec &&
+  Qualifier->getKind() != NestedNameSpecifier::TypeSpecWithTemplate))
+return TypeLoc();
 
   // The "void*" that points at the TypeLoc data.
   unsigned Offset = getDataLength(Qualifier->getPrefix());
Index: include/clang/AST/TemplateBase.h
===
--- include/clang/AST/TemplateBase.h
+++ include/clang/AST/TemplateBase.h
@@ -530,19 +530,22 @@
   }
 
   NestedNameSpecifierLoc getTemplateQualifierLoc() const {
-assert(Argument.getKind() == TemplateArgument::Template ||
-   Argument.getKind() == TemplateArgument::TemplateExpansion);
+if (Argument.getKind() != TemplateArgument::Template &&
+   Argument.getKind() != TemplateArgument::TemplateExpansion)
+  return NestedNameSpecifierLoc();
 return LocInfo.getTemplateQualifierLoc();
   }
 
   SourceLocation getTemplateNameLoc() const {
-assert(Argument.getKind() == TemplateArgument::Template ||
-   Argument.getKind() == TemplateArgument::TemplateExpansion);
+if(Argument.getKind() != TemplateArgument::Template &&
+   Argument.getKind() != TemplateArgument::TemplateExpansion)
+  return SourceLocation();
 return LocInfo.getTemplateNameLoc();
   }
 
   SourceLocation getTemplateEllipsisLoc() const {
-assert(Argument.getKind() == TemplateArgument::TemplateExpansion);
+if(Argument.getKind() != TemplateArgument::TemplateExpansion)
+  return SourceLocation();
 return LocInfo.getTemplateEllipsisLoc();
   }
 };
Index: include/clang/AST/DeclarationName.h
===
--- include/clang/AST/DeclarationName.h
+++ include/clang/AST/DeclarationName.h
@@ -729,9 +729,10 @@
   /// getNamedTypeInfo - Returns the source type info associated to
   /// the name. Assumes it is a constructor, destructor or conversion.
   TypeSourceInfo *getNamedTypeInfo() const {
-assert(Name.getNameKind() == DeclarationName::CXXConstructorName ||
-   Name.getNameKind() == DeclarationName::CXXDestructorName ||
-   Name.getNameKind() == DeclarationName::CXXConversionFunctionName);
+if (Name.getNameKind() != DeclarationName::CXXConstructorName &&
+   Name.getNameKind() != DeclarationName::CXXDestructorName &&
+   Name.getNameKind() != DeclarationName::CXXConversionFunctionName)
+  return nullptr;
 return LocInfo.NamedType.TInfo;
   }
 
@@ -747,7 +748,8 @@
   /// getCXXOperatorNameRange - Gets the range of the operator name
   /// (without the operator keyword). Assumes it is a (non-literal) operator.
   SourceRange getCXXOperatorNameRange() const {
-assert(Name.getNameKind() == DeclarationName::CXXOperatorName);
+if (Name.getNameKind() != DeclarationName::CXXOperatorName)
+  return SourceRange();
 return SourceRange(
  
SourceLocation::getFromRawEncoding(LocInfo.CXXOperatorName.BeginOpNameLoc),
  SourceLocation::getFromRawEncoding(LocInfo.CXXOperatorName.EndOpNameLoc)
@@ -766,7 +768,8 @@
   /// operator name (not the operator keyword).
   /// Assumes it is a literal operator.
   SourceLocation getCXXLiteralOperatorNameLoc() const {
-assert(Name.getNameKind() == DeclarationName::CXXLiteralOperatorName);
+if (Name.getNameKind() != DeclarationName::CXXLiteralOperatorName)
+  return SourceLocation();
 return SourceLocation::
   getFromRawEncoding(LocInfo.CXXLiteralOperatorName.OpNameLoc);
   }


Index: lib/AST/NestedNameSpecifier.cpp
===
--- lib/AST/NestedNameSpecifier.cpp
+++ lib/AST/NestedNameSpecifier.cpp
@@ -462,9 +462,9 @@
 }
 
 TypeLoc NestedNameSpecifierLoc::getTypeLoc() const {
-  assert((Qualifier->getKind() == NestedNameSpecifier::TypeSpec ||
-  Qualifier->getKind() == NestedNameSpecifier::

[PATCH] D56303: [clang-tidy] Handle case/default statements when simplifying boolean expressions

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added inline comments.



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:386
 
-  bool BoolValue = Bool->getValue();
+  const bool BoolValue = Bool->getValue();
 

`const` on values is uncommon in clang-tidy code. Please keep that consistent.



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:743
+  // if the next statement after the if contains a return statement of
+  // the correct form.  Ideally we'd be able to express this with the
+  // matchers, but that is currently impossible.

double space



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:745
+  // matchers, but that is currently impossible.
+  //
+  const auto *If = dyn_cast(SwitchCase->getSubStmt());

redundant empty comment line



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:747
+  const auto *If = dyn_cast(SwitchCase->getSubStmt());
+  assert(If != nullptr);
+  const CXXBoolLiteralExpr *Lit = stmtReturnsBool(If, Negated);

I think this assertion does not hold true from the matcher.
The matcher requires only `hasDescendent(ifStmt())`, but that does not ensure 
the first stmt is the `ifStmt`.

e.g.
```
case 10: {
  loggingCall();
  if(foo) ...
```

Is this excluded?
}


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56303



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

[PATCH] D56343: [clang-tidy] Refactor: Compose Method on check_clang_tidy.py

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added inline comments.



Comment at: test/clang-tidy/check_clang_tidy.py:112
+process_output = e.output.decode()
+print('%s failed:\n%s' % (' '.join(args), process_output))
+if raise_error:

Its better to use `.format()` instead of `%` syntax



Comment at: test/clang-tidy/check_clang_tidy.py:206
 
-  if has_check_fixes:
-try:
-  subprocess.check_output(
-  ['FileCheck', '-input-file=' + temp_file_name, input_file_name,
-   '-check-prefixes=' + ','.join(check_fixes_prefixes),
-   '-strict-whitespace'],
-  stderr=subprocess.STDOUT)
-except subprocess.CalledProcessError as e:
-  print('FileCheck failed:\n' + e.output.decode())
-  raise
-
-  if has_check_messages:
-messages_file = temp_file_name + '.msg'
-write_file(messages_file, clang_tidy_output)
-try:
-  subprocess.check_output(
-  ['FileCheck', '-input-file=' + messages_file, input_file_name,
-   '-check-prefixes=' + ','.join(check_messages_prefixes),
-   '-implicit-check-not={{warning|error}}:'],
-  stderr=subprocess.STDOUT)
-except subprocess.CalledProcessError as e:
-  print('FileCheck failed:\n' + e.output.decode())
-  raise
-
-  if has_check_notes:
-notes_file = temp_file_name + '.notes'
-filtered_output = [line for line in clang_tidy_output.splitlines()
-   if not "note: FIX-IT applied" in line]
-write_file(notes_file, '\n'.join(filtered_output))
-try:
-  subprocess.check_output(
-  ['FileCheck', '-input-file=' + notes_file, input_file_name,
-   '-check-prefixes=' + ','.join(check_notes_prefixes),
-   '-implicit-check-not={{note|warning|error}}:'],
-  stderr=subprocess.STDOUT)
-except subprocess.CalledProcessError as e:
-  print('FileCheck failed:\n' + e.output.decode())
-  raise
+  check_fixes(check_fixes_prefixes, has_check_fixes, input_file_name, 
temp_file_name)
+  check_messages(check_messages_prefixes, has_check_messages, 
clang_tidy_output, input_file_name, temp_file_name)

If would prefer keeping the `if check_notes` outside of the function call and 
remove that one argument. Same for the other `check_...` functions


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56343



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

[PATCH] D55433: [clang-tidy] Adding a new modernize use nodiscard checker

[Jonas Toth via Phabricator via cfe-commits]

JonasToth accepted this revision.
JonasToth added a comment.

LGTM.

If you have the time please rerun this latest (final?) version over LLVM or any 
other bigger project and check if there are any issues left and ensure the code 
still compiles after code-transformation.


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

https://reviews.llvm.org/D55433



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

[PATCH] D56090: Add a matcher for members of an initializer list expression

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM! Thanks, both!


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

https://reviews.llvm.org/D56090



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

Re: r350404 - Refactor the way we handle diagnosing unused expression results.

[Aaron Ballman via cfe-commits]

On Fri, Jan 4, 2019 at 8:41 PM Richard Smith  wrote:
>
> On Fri, 4 Jan 2019 at 17:33, Nico Weber via cfe-commits 
>  wrote:
>>
>> Nice, this is finding bugs: 
>> https://bugs.chromium.org/p/chromium/issues/detail?id=919262
>>
>> However, I noticed that for that case, the same warning is printed twice:
>>
>> ../../third_party/crashpad/crashpad/util/win/process_info.cc(227,36):  
>> error: expression result unused [-Werror,-Wunused-value]
>>   NTSTATUS_LOG(ERROR, status), "NtQueryInformationProcess";
>>^~~
>> ../../third_party/crashpad/crashpad/util/win/process_info.cc(227,36):  
>> error: expression result unused [-Werror,-Wunused-value]
>>   NTSTATUS_LOG(ERROR, status), "NtQueryInformationProcess";
>>
>>
>> Is that expected?

Yes and no. It's not unexpected, but it's not super helpful either. As
Richard points out below, this happens because of template
instantiation.

> The first diagnostic appears when parsing the template, the second one 
> appears when instantiating it. In the complete diagnostic output:
>
> ../../third_party/crashpad/crashpad/util/win/process_info.cc(227,36):  error: 
> expression result unused [-Werror,-Wunused-value]
>   NTSTATUS_LOG(ERROR, status), "NtQueryInformationProcess";
>^~~
>
> ../../third_party/crashpad/crashpad/util/win/process_info.cc(227,36):  error: 
> expression result unused [-Werror,-Wunused-value]
>   NTSTATUS_LOG(ERROR, status), "NtQueryInformationProcess";
>^~~
> ../../third_party/crashpad/crashpad/util/win/process_info.cc(531,17):  note: 
> in instantiation of function template specialization 
> 'crashpad::GetProcessBasicInformation'
>  requested here
>   bool result = GetProcessBasicInformation(
> ^
>
> It'd be nice to suppress the diagnostic during instantiation if it appeared 
> during the initial parse (generally, not with something specific to this 
> warning).

Agreed, though I don't have the time to work on that currently.
Hopefully the behavior here isn't too onerous for Chromium (or other
projects)?

~Aaron

>
>> Code is here:
>> https://cs.chromium.org/chromium/src/third_party/crashpad/crashpad/util/win/process_info.cc?q=crashpad/util/win/process_info.cc&sq=package:chromium&g=0&l=227
>> https://cs.chromium.org/chromium/src/third_party/crashpad/crashpad/util/win/ntstatus_logging.h?type=cs&q=NTSTATUS_LOG&sq=package:chromium&g=0&l=63
>>
>>
>> On Fri, Jan 4, 2019 at 12:01 PM Aaron Ballman via cfe-commits 
>>  wrote:
>>>
>>> Author: aaronballman
>>> Date: Fri Jan  4 08:58:14 2019
>>> New Revision: 350404
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=350404&view=rev
>>> Log:
>>> Refactor the way we handle diagnosing unused expression results.
>>>
>>> Rather than sprinkle calls to DiagnoseUnusedExprResult() around in places 
>>> where we want diagnostics, we now diagnose unused expression statements and 
>>> full expressions in a more generic way when acting on the final expression 
>>> statement. This results in more appropriate diagnostics for [[nodiscard]] 
>>> where we were previously lacking them, such as when the body of a for loop 
>>> is not a compound statement.
>>>
>>> This patch fixes PR39837.
>>>
>>> Modified:
>>> cfe/trunk/include/clang/Parse/Parser.h
>>> cfe/trunk/include/clang/Sema/Sema.h
>>> cfe/trunk/lib/Parse/ParseObjc.cpp
>>> cfe/trunk/lib/Parse/ParseOpenMP.cpp
>>> cfe/trunk/lib/Parse/ParseStmt.cpp
>>> cfe/trunk/lib/Sema/SemaCoroutine.cpp
>>> cfe/trunk/lib/Sema/SemaDecl.cpp
>>> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
>>> cfe/trunk/lib/Sema/SemaExpr.cpp
>>> cfe/trunk/lib/Sema/SemaExprCXX.cpp
>>> cfe/trunk/lib/Sema/SemaLambda.cpp
>>> cfe/trunk/lib/Sema/SemaOpenMP.cpp
>>> cfe/trunk/lib/Sema/SemaStmt.cpp
>>> cfe/trunk/lib/Sema/TreeTransform.h
>>> cfe/trunk/test/CXX/stmt.stmt/stmt.select/p3.cpp
>>> cfe/trunk/test/CodeCompletion/pragma-macro-token-caching.c
>>> cfe/trunk/test/Parser/cxx1z-init-statement.cpp
>>> cfe/trunk/test/Parser/switch-recovery.cpp
>>> cfe/trunk/test/SemaCXX/cxx1z-init-statement.cpp
>>> cfe/trunk/test/SemaCXX/for-range-examples.cpp
>>> cfe/trunk/test/SemaCXX/warn-unused-result.cpp
>>>
>>> Modified: cfe/trunk/include/clang/Parse/Parser.h
>>> URL: 
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Parse/Parser.h?rev=350404&r1=350403&r2=350404&view=diff
>>> ==
>>> --- cfe/trunk/include/clang/Parse/Parser.h (original)
>>> +++ cfe/trunk/include/clang/Parse/Parser.h Fri Jan  4 08:58:14 2019
>>> @@ -360,6 +360,11 @@ class Parser : public CodeCompletionHand
>>>/// just a regular sub-expression.
>>>SourceLocation ExprStatementTokLoc;
>>>
>>> +  /// Tests whether an expression value is discarded based on token 
>>> lookahead.
>>> +  /// It will re

r350470 - Improve MSVC type visualizations

[Mike Spertus via cfe-commits]

Author: mps
Date: Sat Jan  5 09:01:34 2019
New Revision: 350470

URL: http://llvm.org/viewvc/llvm-project?rev=350470&view=rev
Log:
Improve MSVC type visualizations

Display TypeBits in a single line. 
Fix bit rot in template visualizations
Rudimentary support for deduced types


Modified:
cfe/trunk/utils/ClangVisualizers/clang.natvis

Modified: cfe/trunk/utils/ClangVisualizers/clang.natvis
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/ClangVisualizers/clang.natvis?rev=350470&r1=350469&r2=350470&view=diff
==
--- cfe/trunk/utils/ClangVisualizers/clang.natvis (original)
+++ cfe/trunk/utils/ClangVisualizers/clang.natvis Sat Jan  5 09:01:34 2019
@@ -34,16 +34,37 @@ For later versions of Visual Studio, no
 {*(clang::RecordType *)this,view(cpp)}
 {*(clang::FunctionProtoType *)this}
 {*(clang::TemplateSpecializationType *)this}
+{*(clang::DeducedTemplateSpecializationType 
*)this}
 {*(clang::InjectedClassNameType *)this}
 {*(clang::PackExpansionType *)this}
 {*(clang::LocInfoType *)this}
 {*this,view(poly)}
 No visualizer yet for 
{(clang::Type::TypeClass)TypeBits.TC,en}Type 
+Dependent
+
+InstantiationDependent
+
+VariablyModified
+
+ContainsUnexpandedParameterPack
+
+CachedLinkage: 
{(clang::Linkage)TypeBits.CachedLinkage,en} CachedLocalOrUnnamed
+CachedLinkage: 
{(clang::Linkage)TypeBits.CachedLinkage,en}
+
+FromAST
+
+
+  No TypeBits set beyond TypeClass
+
+
+{*this, view(Dependent)}{*this, view(InstantiationDependent)}{*this, 
view(VariablyModified)}
+{*this, view(ContainsUnexpandedParameterPack)}{*this, view(Cache)}{*this, 
view(FromAST)}
 {*this,view(cmn)}  {{{*this,view(poly)}}}
 
   (clang::Type::TypeClass)TypeBits.TC
-  TypeBits
+  *this,view(flags)
   CanonicalType
+  CanonicalType.Value.Value == this
   *(clang::BuiltinType 
*)this
   *(clang::PointerType 
*)this
   *(clang::LValueReferenceType
 *)this
@@ -54,6 +75,7 @@ For later versions of Visual Studio, no
   (clang::RecordType 
*)this
   (clang::FunctionProtoType
 *)this
   (clang::TemplateSpecializationType
 *)this
+  (clang::DeducedTemplateSpecializationType
 *)this
   (clang::InjectedClassNameType
 *)this
   (clang::PackExpansionType
 *)this
   (clang::LocInfoType 
*)this
@@ -125,7 +147,13 @@ For later versions of Visual Studio, no
 {*this,view(TorC)} 
{*this,view(MaybeEllipses)}{Name,view(cpp)} 
   
   
-template{*TemplateParams} {*TemplatedDecl};
+template{TemplateParams,view(deref)} 
{*TemplatedDecl};
+  
+  
+{Storage,view(deref)}
+
+  Storage
+
   
   
 {Name,view(cpp)}
@@ -136,11 +164,11 @@ For later versions of Visual Studio, no
 
 {*this,view(implicit)}
 {*this,view(modifiers)}{Name,view(cpp)}
-{*this,view(modifiers)}struct
 {Name,view(cpp)}
-{*this,view(modifiers)}interface
 {Name,view(cpp)}
-{*this,view(modifiers)}union
 {Name,view(cpp)}
-{*this,view(modifiers)}class
 {Name,view(cpp)}
-{*this,view(modifiers)}enum
 {Name,view(cpp)}
+{*this,view(modifiers)}struct
 {Name,view(cpp)}
+{*this,view(modifiers)}interface
 {Name,view(cpp)}
+{*this,view(modifiers)}union
 {Name,view(cpp)}
+{*this,view(modifiers)}class
 {Name,view(cpp)}
+{*this,view(modifiers)}enum
 {Name,view(cpp)}
 
   (clang::DeclContext *)this
 
@@ -381,6 +409,18 @@ For later versions of Visual Studio, no
   
 
   
+  
+
+  (CanonicalType.Value.Value != this) || 
TypeBits.Dependent
+  *(clang::Type *)this,view(cmn)
+
+  
+  
+{Template}
+
+  *(clang::DeducedType *)this
+
+  
   
 {((llvm::StringMapEntry*)Entry)+1,sb}
 


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

[PATCH] D48342: [libcxx] Optimize vectors construction of trivial types from an iterator range with const-ness mismatch.

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added inline comments.



Comment at: 
libcxx/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp:196
   test_ctor_under_alloc();
+  test_ctor_with_different_value_type();
 }

vsapsai wrote:
> Quuxplusone wrote:
> > I suggest that interesting test cases include "array of `int` to vector of 
> > `unsigned int`" (trivial, but unimplemented in this patch) and "array of 
> > `iostream*` to vector of `ostream*`" (non-trivial because each pointer must 
> > be adjusted).
> What is that supposed to test? My `float/int` test is to make sure we have 
> `is_same<_RawSourceTp, _RawDestTp>::value` and don't try to `memcpy` 
> unrelated types. I've chosen `float` and `int` because it is easier for a 
> human to reason about them.
> 
> `int` and `unsigned int` are interested for testing for values that are 
> outside of common range. But in this case you pay more attention to 
> conversion between ints, not to the behaviour of the constructor. That's my 
> interpretation but maybe I've missed some of your intentions.
> My `float/int` test is to make sure we [...] don't try to `memcpy` unrelated 
> types [when it's unsafe to do so].

Right. I suggest two additional tests. The first additional test, `int/unsigned 
int`, is to verify whether we `memcpy` unrelated types when it //is// safe to 
do so. The second test, `iostream*/ostream*`, is to verify whether we `memcpy` 
unrelated types when it is unsafe to `memcpy` them even though they are both of 
the same "kind" (both pointer types).

These will act as regression tests, to make sure that future changes to the 
memcpy criteria don't break these cases' behavior (although the first 
additional test //is// expected to get more efficient).


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

https://reviews.llvm.org/D48342



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

[PATCH] D56343: [clang-tidy] Refactor: Compose Method on check_clang_tidy.py

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood added a comment.

I really want to get these reviewed quickly.  Otherwise, I will run out of 
available time to complete them and get them submitted.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56343



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

[PATCH] D56323: [clang-tidy] Handle member variables in readability-simplify-boolean-expr

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood added a comment.

I really want to get these reviewed quickly.  Otherwise, I will run out of 
available time to complete them and get them submitted.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56323



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

[PATCH] D56323: [clang-tidy] Handle member variables in readability-simplify-boolean-expr

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood marked 4 inline comments as done.
LegalizeAdulthood added inline comments.



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:464
   bool Value, StringRef Id) {
-  auto SimpleThen = binaryOperator(
-  hasOperatorName("="),
-  hasLHS(declRefExpr(hasDeclaration(decl().bind(IfAssignObjId,
-  hasLHS(expr().bind(IfAssignVariableId)),
-  hasRHS(cxxBoolLiteral(equals(Value)).bind(IfAssignLocId)));
-  auto Then = anyOf(SimpleThen, compoundStmt(statementCountIs(1),
- hasAnySubstatement(SimpleThen)));
-  auto SimpleElse = binaryOperator(
-  hasOperatorName("="),
-  hasLHS(declRefExpr(hasDeclaration(equalsBoundNode(IfAssignObjId,
-  hasRHS(cxxBoolLiteral(equals(!Value;
-  auto Else = anyOf(SimpleElse, compoundStmt(statementCountIs(1),
- hasAnySubstatement(SimpleElse)));
+  const auto VarAssign =
+  declRefExpr(hasDeclaration(decl().bind(IfAssignVarId)));

JonasToth wrote:
> The `const` for these locals in uncommon in clang-tidy, given its a value 
> type. I am not strongly against them, but would prefer consistency.
I can undo the const.



Comment at: test/clang-tidy/readability-simplify-bool-expr-members.cpp:4
+struct X {
+  explicit operator bool();
+};

JonasToth wrote:
> I didn't see a test that utilized this struct, did I overlook it?
> 
> Implicit conversion to `bool`-cases would be interesting as well. Maybe 
> implicit conversion to integral in general.
Leftover from copy/paste of readability-simplify-bool-expr.cpp, I'll remove it.

Implicit conversion cases are covered by the other file.  Here, I'm just 
testing the cases that interact with member variables because the matcher needs 
to use memberExpr() and not just declRefExpr()



Comment at: test/clang-tidy/readability-simplify-bool-expr-members.cpp:35
+  bool m_b3 = false;
+  bool m_b4 = false;
+  int *m_p = nullptr;

JonasToth wrote:
> Would bitfields with a single bit be of interest as well?
That could be an enhancement, but it's not addressed by this patch.



Comment at: test/clang-tidy/readability-simplify-bool-expr-members.cpp:160
+  // CHECK-MESSAGES: :[[@LINE-1]]:21: warning: {{.*}} in ternary expression 
result
+  // CHECK-FIXES: {{^  m_b2 = i <= 20;$}}
+

JonasToth wrote:
> For this case the logical inversion is simple an obviously `<=`, but what if 
> the condition is more complex?
> 
> I would personally prefer `!(i < 20)` instead + complex logical expressions 
> as additional test. They would be interesting for the `if` cases, too.
If you have complex conditions, you can run the check repeatedly until you 
reach a fixed point.

Using !(x) instead of the reverse operator could be added as an enhancement, 
but it is not covered by this patch.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56323



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

[PATCH] D55337: NFC: Move dumpDeclRef to NodeDumper

[Stephen Kelly via Phabricator via cfe-commits]

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



Comment at: include/clang/AST/TextNodeDumper.h:28
const comments::FullComment *> {
+  TextTreeStructure &TreeStructure;
   raw_ostream &OS;

aaron.ballman wrote:
> steveire wrote:
> > aaron.ballman wrote:
> > > This makes me a bit wary because you create a node dumper in the same 
> > > situations you make a tree structure object, but now there's a strict 
> > > ordering between the two object creations. If you're doing this 
> > > construction local to a function, you wind up with a dangling reference 
> > > unless you're careful (which is unfortunate, but not the end of the 
> > > world). If you're doing this construction as part of a constructor's 
> > > initializer list, you now have to properly order the member declarations 
> > > within the class and that is also unfortunate. Given that those are the 
> > > two common scenarios for how I envision constructing an ast dump of some 
> > > kind, I worry about the fragility. e.g.,
> > > ```
> > > unique_ptr createASTDumper(...) {
> > >   TextTreeStructure TreeStructure;
> > >   TextNodeDumper NodeDumper(TreeStructure); // Oops, dangling reference
> > >   return make_unique(TreeStructure, NodeDumper, 
> > > ...);
> > > }
> > > 
> > > // vs
> > > 
> > > struct MySuperAwesomeASTDumper : ... {
> > >   MySuperAwesomeASTDumper() : TreeStructure(...), 
> > > NodeDumper(TreeStructure, ...) {}
> > > private:
> > >   TextTreeStructure TreeStructure; // This order is now SUPER important
> > >   TextNodeDumper NodeDumper;
> > > };
> > > ```
> > > There's a part of me that wonders if a better approach is to have this 
> > > object passed to the `dumpFoo()` calls as a reference parameter. This 
> > > way, the caller is still responsible for creating an object, but the 
> > > creation order between the tree and the node dumper isn't as fragile.
> > In your first snippet there is a dangling reference because the author of 
> > `MySuperAwesomeASTDumper` decided to make the members references. If the 
> > members are references, code like your first snippet will cause dangling 
> > references and nothing can prevent that. Adding `TreeStructure&` to Visit 
> > methods as you suggested does not prevent it.
> > 
> > The only solution is make the `MySuperAwesomeASTDumper` not use member 
> > references (ie your second snippet). The order is then in fact not 
> > problematic because "taking a reference to an uninitialized object is 
> > legal".
> >  The order is then in fact not problematic because "taking a reference to 
> > an uninitialized object is legal".
> 
> This presumes that the constructors aren't using those references to the 
> uninitialized object, which would be illegal. That's what I mean about this 
> being very fragile -- if the stars line up correctly, everything works fine, 
> but if the stars aren't aligned just right, you get really hard problems to 
> track down.
Actually 'the stars would have to line up in a particular way' in order to 
reach the scenario you are concerned about. What would have to happen is:

* This patch gets in as-is
* Someone in the future reorders the members 
* But they don't reorder the init-list
* They build on a platform without -Wreorder (only MSVC?) enabled in the build.
* That passes review
* Other users update their checkout and everyone else also ignores the 
-Wreorder warning.

That is a vanishingly likely scenario. It's just unreasonable to consider that 
as a reason to create a broken interface.

And it would be a broken interface.

After the refactoring is complete, we have something like 

```
class ASTDumper
: public ASTDumpTraverser {
  TextTreeStructure TreeStructure;
  TextNodeDumper NodeDumper;
public:
  TextTreeStructure &getTreeStructure() { return TreeStructure; }
  TextNodeDumper &getNodeDumper() { return NodeDumper; }

  ASTDumper(raw_ostream &OS, const SourceManager *SM)
  : TreeStructure(OS),
NodeDumper(TreeStructure, OS, SM) {}
};

```

In the case, of the `ASTDumper`, the `TextNodeDumper` uses the 
`TextTreeStructure`.

However, in the case of any other subclass of `ASTDumpTraverser`, the 
`NodeDumper` type does not depend on the `TreeStructure` type. The 
`ASTDumpTraverser` should not pass the `TreeStructure` to the 
`NodeDumper`because the `ASTDumpTraverser` should not assume the `NodeDumper` 
needs the `ASTDumpTraverser`. 

That is true in one concrete case (the `TextNodeDumper`), but not in general. 
You would be encoding an assumption about a concrete `NodeDumper` 
implementation in the generic `ASTDumpTraverser`.

That is an interface violation which is definitely not justified by your 
far-fetched scenario of someone re-ordering the members in the future and 
ignoring `-Wreorder`.


Repository:
  rC Clang

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

https://reviews.llvm.org/D55337



___

[PATCH] D55337: NFC: Move dumpDeclRef to NodeDumper

[Stephen Kelly via Phabricator via cfe-commits]

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



Comment at: include/clang/AST/TextNodeDumper.h:28
const comments::FullComment *> {
+  TextTreeStructure &TreeStructure;
   raw_ostream &OS;

steveire wrote:
> aaron.ballman wrote:
> > steveire wrote:
> > > aaron.ballman wrote:
> > > > This makes me a bit wary because you create a node dumper in the same 
> > > > situations you make a tree structure object, but now there's a strict 
> > > > ordering between the two object creations. If you're doing this 
> > > > construction local to a function, you wind up with a dangling reference 
> > > > unless you're careful (which is unfortunate, but not the end of the 
> > > > world). If you're doing this construction as part of a constructor's 
> > > > initializer list, you now have to properly order the member 
> > > > declarations within the class and that is also unfortunate. Given that 
> > > > those are the two common scenarios for how I envision constructing an 
> > > > ast dump of some kind, I worry about the fragility. e.g.,
> > > > ```
> > > > unique_ptr createASTDumper(...) {
> > > >   TextTreeStructure TreeStructure;
> > > >   TextNodeDumper NodeDumper(TreeStructure); // Oops, dangling reference
> > > >   return make_unique(TreeStructure, 
> > > > NodeDumper, ...);
> > > > }
> > > > 
> > > > // vs
> > > > 
> > > > struct MySuperAwesomeASTDumper : ... {
> > > >   MySuperAwesomeASTDumper() : TreeStructure(...), 
> > > > NodeDumper(TreeStructure, ...) {}
> > > > private:
> > > >   TextTreeStructure TreeStructure; // This order is now SUPER important
> > > >   TextNodeDumper NodeDumper;
> > > > };
> > > > ```
> > > > There's a part of me that wonders if a better approach is to have this 
> > > > object passed to the `dumpFoo()` calls as a reference parameter. This 
> > > > way, the caller is still responsible for creating an object, but the 
> > > > creation order between the tree and the node dumper isn't as fragile.
> > > In your first snippet there is a dangling reference because the author of 
> > > `MySuperAwesomeASTDumper` decided to make the members references. If the 
> > > members are references, code like your first snippet will cause dangling 
> > > references and nothing can prevent that. Adding `TreeStructure&` to Visit 
> > > methods as you suggested does not prevent it.
> > > 
> > > The only solution is make the `MySuperAwesomeASTDumper` not use member 
> > > references (ie your second snippet). The order is then in fact not 
> > > problematic because "taking a reference to an uninitialized object is 
> > > legal".
> > >  The order is then in fact not problematic because "taking a reference to 
> > > an uninitialized object is legal".
> > 
> > This presumes that the constructors aren't using those references to the 
> > uninitialized object, which would be illegal. That's what I mean about this 
> > being very fragile -- if the stars line up correctly, everything works 
> > fine, but if the stars aren't aligned just right, you get really hard 
> > problems to track down.
> Actually 'the stars would have to line up in a particular way' in order to 
> reach the scenario you are concerned about. What would have to happen is:
> 
> * This patch gets in as-is
> * Someone in the future reorders the members 
> * But they don't reorder the init-list
> * They build on a platform without -Wreorder (only MSVC?) enabled in the 
> build.
> * That passes review
> * Other users update their checkout and everyone else also ignores the 
> -Wreorder warning.
> 
> That is a vanishingly likely scenario. It's just unreasonable to consider 
> that as a reason to create a broken interface.
> 
> And it would be a broken interface.
> 
> After the refactoring is complete, we have something like 
> 
> ```
> class ASTDumper
> : public ASTDumpTraverser {
>   TextTreeStructure TreeStructure;
>   TextNodeDumper NodeDumper;
> public:
>   TextTreeStructure &getTreeStructure() { return TreeStructure; }
>   TextNodeDumper &getNodeDumper() { return NodeDumper; }
> 
>   ASTDumper(raw_ostream &OS, const SourceManager *SM)
>   : TreeStructure(OS),
> NodeDumper(TreeStructure, OS, SM) {}
> };
> 
> ```
> 
> In the case, of the `ASTDumper`, the `TextNodeDumper` uses the 
> `TextTreeStructure`.
> 
> However, in the case of any other subclass of `ASTDumpTraverser`, the 
> `NodeDumper` type does not depend on the `TreeStructure` type. The 
> `ASTDumpTraverser` should not pass the `TreeStructure` to the 
> `NodeDumper`because the `ASTDumpTraverser` should not assume the `NodeDumper` 
> needs the `ASTDumpTraverser`. 
> 
> That is true in one concrete case (the `TextNodeDumper`), but not in general. 
> You would be encoding an assumption about a concrete `NodeDumper` 
> implementation in the generic `ASTDumpTraverser`.
> 
> That is an interface violation which is definitely not justified by your 
> far-fetched scenario of some

[PATCH] D56343: [clang-tidy] Refactor: Compose Method on check_clang_tidy.py

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added a comment.

In D56343#1347352 , @LegalizeAdulthood 
wrote:

> I really want to get these reviewed quickly.  Otherwise, I will run out of 
> available time to complete them and get them submitted.


I will give my best to be available this weekend but the review takes time 
until the patch is in an acceptable state, same for the other revision.
This process is required to keep good quality and catch bugs, even subtile ones 
early. Breaking code is the worst of all options.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56343



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

[PATCH] D56323: [clang-tidy] Handle member variables in readability-simplify-boolean-expr

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added inline comments.



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:464
   bool Value, StringRef Id) {
-  auto SimpleThen = binaryOperator(
-  hasOperatorName("="),
-  hasLHS(declRefExpr(hasDeclaration(decl().bind(IfAssignObjId,
-  hasLHS(expr().bind(IfAssignVariableId)),
-  hasRHS(cxxBoolLiteral(equals(Value)).bind(IfAssignLocId)));
-  auto Then = anyOf(SimpleThen, compoundStmt(statementCountIs(1),
- hasAnySubstatement(SimpleThen)));
-  auto SimpleElse = binaryOperator(
-  hasOperatorName("="),
-  hasLHS(declRefExpr(hasDeclaration(equalsBoundNode(IfAssignObjId,
-  hasRHS(cxxBoolLiteral(equals(!Value;
-  auto Else = anyOf(SimpleElse, compoundStmt(statementCountIs(1),
- hasAnySubstatement(SimpleElse)));
+  const auto VarAssign =
+  declRefExpr(hasDeclaration(decl().bind(IfAssignVarId)));

LegalizeAdulthood wrote:
> JonasToth wrote:
> > The `const` for these locals in uncommon in clang-tidy, given its a value 
> > type. I am not strongly against them, but would prefer consistency.
> I can undo the const.
Ok, that would be great.



Comment at: test/clang-tidy/readability-simplify-bool-expr-members.cpp:4
+struct X {
+  explicit operator bool();
+};

LegalizeAdulthood wrote:
> JonasToth wrote:
> > I didn't see a test that utilized this struct, did I overlook it?
> > 
> > Implicit conversion to `bool`-cases would be interesting as well. Maybe 
> > implicit conversion to integral in general.
> Leftover from copy/paste of readability-simplify-bool-expr.cpp, I'll remove 
> it.
> 
> Implicit conversion cases are covered by the other file.  Here, I'm just 
> testing the cases that interact with member variables because the matcher 
> needs to use memberExpr() and not just declRefExpr()
Which other file? The other revision?



Comment at: test/clang-tidy/readability-simplify-bool-expr-members.cpp:160
+  // CHECK-MESSAGES: :[[@LINE-1]]:21: warning: {{.*}} in ternary expression 
result
+  // CHECK-FIXES: {{^  m_b2 = i <= 20;$}}
+

LegalizeAdulthood wrote:
> JonasToth wrote:
> > For this case the logical inversion is simple an obviously `<=`, but what 
> > if the condition is more complex?
> > 
> > I would personally prefer `!(i < 20)` instead + complex logical expressions 
> > as additional test. They would be interesting for the `if` cases, too.
> If you have complex conditions, you can run the check repeatedly until you 
> reach a fixed point.
> 
> Using !(x) instead of the reverse operator could be added as an enhancement, 
> but it is not covered by this patch.
But the current version is the enhancement.
The complex condition, like `i < 20 && i > 0` will be the common case, so the 
inversion (with parens) should always be used (`!(i < 20 && i > 0)`) and 
specializations can be done later.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56323



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

r350472 - CodeGen: switch iteration to range based for loop (NFC)

[Saleem Abdulrasool via cfe-commits]

Author: compnerd
Date: Sat Jan  5 10:39:32 2019
New Revision: 350472

URL: http://llvm.org/viewvc/llvm-project?rev=350472&view=rev
Log:
CodeGen: switch iteration to range based for loop (NFC)

Change a loop to range based instead while working on cleaning up some
modules autolinking issues on Linux.  NFC.

Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=350472&r1=350471&r2=350472&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Sat Jan  5 10:39:32 2019
@@ -1746,16 +1746,14 @@ void CodeGenModule::EmitModuleLinkOption
 bool AnyChildren = false;
 
 // Visit the submodules of this module.
-for (clang::Module::submodule_iterator Sub = Mod->submodule_begin(),
-SubEnd = Mod->submodule_end();
- Sub != SubEnd; ++Sub) {
+for (const auto &SM : Mod->submodules()) {
   // Skip explicit children; they need to be explicitly imported to be
   // linked against.
-  if ((*Sub)->IsExplicit)
+  if (SM->IsExplicit)
 continue;
 
-  if (Visited.insert(*Sub).second) {
-Stack.push_back(*Sub);
+  if (Visited.insert(SM).second) {
+Stack.push_back(SM);
 AnyChildren = true;
   }
 }


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

[PATCH] D56303: [clang-tidy] Handle case/default statements when simplifying boolean expressions

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:511
+  StringRef Id) {
+  // binding to the returnStmt matched is pointless because we can't guarantee
+  // anything about the ordering of the return statement and the case 
statement.

binding -> Binding



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:529
+ StringRef Id) {
+  // binding to the returnStmt matched is pointless because we can't guarantee
+  // anything about the ordering of the return statement and the case 
statement.

binding -> Binding

Also, there is no "case statement" involved here. ;-)



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:533-540
+  switchStmt(has(
+  compoundStmt(
+  has(defaultStmt(hasDescendant(ifStmt(hasThen(returnsBool(Value)),
+   unless(hasElse(stmt(
+.bind(CompoundIfId)))
+  .bind(DefaultId)),
+  has(returnStmt(has(cxxBoolLiteral(equals(!Value))

The check duplication here is unfortunate -- can you factor out the 
`hasDescendant()` bits into a variable that is reused, and perhaps use 
`anyOf(caseStmt(stuff()), defaultStmt(stuff()))` rather than separate functions?



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:718
+const MatchFinder::MatchResult &Result, const CompoundStmt *Compound,
+bool Negated, const SwitchCase *SwitchCase) {
+  assert(SwitchCase != nullptr);

Don't use an identifier with the same name as a type, please.



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:719
+bool Negated, const SwitchCase *SwitchCase) {
+  assert(SwitchCase != nullptr);
+

Add a message to the assertion (same with the other ones).


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56303



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

r350476 - CodeGen: fix autolink emission on ELF

[Saleem Abdulrasool via cfe-commits]

Author: compnerd
Date: Sat Jan  5 11:27:12 2019
New Revision: 350476

URL: http://llvm.org/viewvc/llvm-project?rev=350476&view=rev
Log:
CodeGen: fix autolink emission on ELF

The autolinking extension for ELF uses a slightly different format for
encoding the autolink information compared to COFF and MachO.  Account
for this in the CGM to ensure that we do not assert when emitting
assembly or an object file.

Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/test/Modules/autolink.m

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=350476&r1=350475&r2=350476&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Sat Jan  5 11:27:12 2019
@@ -1692,6 +1692,8 @@ static void addLinkOptionsPostorder(Code
   // Add linker options to link against the libraries/frameworks
   // described by this module.
   llvm::LLVMContext &Context = CGM.getLLVMContext();
+  bool IsELF = CGM.getTarget().getTriple().isOSBinFormatELF();
+  bool IsPS4 = CGM.getTarget().getTriple().isPS4();
 
   // For modules that use export_as for linking, use that module
   // name instead.
@@ -1711,11 +1713,19 @@ static void addLinkOptionsPostorder(Code
 }
 
 // Link against a library.
-llvm::SmallString<24> Opt;
-CGM.getTargetCodeGenInfo().getDependentLibraryOption(
-  Mod->LinkLibraries[I-1].Library, Opt);
-auto *OptString = llvm::MDString::get(Context, Opt);
-Metadata.push_back(llvm::MDNode::get(Context, OptString));
+if (IsELF && !IsPS4) {
+  llvm::Metadata *Args[2] = {
+  llvm::MDString::get(Context, "lib"),
+  llvm::MDString::get(Context, Mod->LinkLibraries[I - 1].Library),
+  };
+  Metadata.push_back(llvm::MDNode::get(Context, Args));
+} else {
+  llvm::SmallString<24> Opt;
+  CGM.getTargetCodeGenInfo().getDependentLibraryOption(
+  Mod->LinkLibraries[I - 1].Library, Opt);
+  auto *OptString = llvm::MDString::get(Context, Opt);
+  Metadata.push_back(llvm::MDNode::get(Context, OptString));
+}
   }
 }
 

Modified: cfe/trunk/test/Modules/autolink.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/autolink.m?rev=350476&r1=350475&r2=350476&view=diff
==
--- cfe/trunk/test/Modules/autolink.m (original)
+++ cfe/trunk/test/Modules/autolink.m Sat Jan  5 11:27:12 2019
@@ -37,9 +37,9 @@ int use_autolink_sub3() {
 // NOTE: "autolink_sub" is intentionally not linked.
 
 // CHECK: !llvm.linker.options = !{![[AUTOLINK_PCH:[0-9]+]], 
![[AUTOLINK_FRAMEWORK:[0-9]+]], ![[AUTOLINK:[0-9]+]], 
![[DEPENDSONMODULE:[0-9]+]], ![[MODULE:[0-9]+]], ![[NOUMBRELLA:[0-9]+]]}
-// CHECK: ![[AUTOLINK_PCH]] = 
!{!"{{(\\01|-l|/DEFAULTLIB:)}}autolink_from_pch{{(\.lib)?}}"}
+// CHECK: ![[AUTOLINK_PCH]] = !{!"{{(\\01|-l|/DEFAULTLIB:|lib", 
!")}}autolink_from_pch{{(\.lib)?}}"}
 // CHECK: ![[AUTOLINK_FRAMEWORK]] = !{!"-framework", !"autolink_framework"}
-// CHECK: ![[AUTOLINK]] = !{!"{{(\\01|-l|/DEFAULTLIB:)}}autolink{{(\.lib)?}}"}
+// CHECK: ![[AUTOLINK]] = !{!"{{(\\01|-l|/DEFAULTLIB:|lib", 
!")}}autolink{{(\.lib)?}}"}
 // CHECK: ![[DEPENDSONMODULE]] = !{!"-framework", !"DependsOnModule"}
 // CHECK: ![[MODULE]] = !{!"-framework", !"Module"}
 // CHECK: ![[NOUMBRELLA]] = !{!"-framework", !"NoUmbrella"}


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

[PATCH] D56215: [lld] [ELF] Include default search paths for NetBSD driver

[Kamil Rytarowski via Phabricator via cfe-commits]

krytarowski added a comment.

I've grepped FreeBSD, OpenBSD and pkgsrc.

OpenBSD ports
=

Total 2 packages there have issues with LLD.

  $ grep -r USE_LLD .
  ./devel/libcoap/Makefile:USE_LLD=   No
  ./sysutils/firmware/vmm/Makefile:USE_LLD=   No



FreeBSD ports
=

There is a list of 140-150 unsafe (LLD_UNSAFE) packages with LLD. A
part of the entries on the list are magnified by the same
framework/piece-of-software, but different component of version.

6 ports have documented issues with search paths:

1. pdcurses
2. libds
3. evangeline
4. rexx-regutil
5. otpw
6. installwatch

The list might be incomplete.. but "thousands of monkeys fixing
packages" mentioned is strong overestimation.

pkgsrc
==

It was mentioned in 2017 (!) that rejecting teaching the driver because of 
packages
in pkgsrc that use `LINKER_RPATH_FLAG` (but probably not limited to this
option).

All of that looks like restricted to:

1. GCC,
2. Mercury,
3. GPS,
4. sather,
5. wmutils-core
6. aws

Most of that is probably about unneeded direct call of a linker.
Probably the list might be longer for trickier examples like emacs. (But
emacs seems to have no issues on OpenBSD and FreeBSD).


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

https://reviews.llvm.org/D56215



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

[PATCH] D56358: [AST] Move back BasePathSize to the bit-fields of CastExpr

[Bruno Ricci via Phabricator via cfe-commits]

riccibruno created this revision.
riccibruno added a reviewer: lebedev.ri.
riccibruno added a project: clang.
Herald added a subscriber: cfe-commits.

Background:

The number of trailing `CXXBaseSpecifiers` in `CastExpr` was moved from
`CastExprBitfields` to a trailing object in r338489 (D50050 
). At this time these bit-fields
classes were only 32 bits wide. However later r345459 widened these bit-field 
classes to 64 bits.

The reason for this change was that on 64 bit archs alignment requirements 
caused 4 bytes of
padding after the `Stmt` sub-object in nearly all expression classes. Reusing 
this padding yielded
an >10% reduction in the size used by all statement/expressions when parsing 
all of Boost (on a
64 bit arch). This increased the size of statement/expressions for 32 bits 
archs, but this can be
mitigated by moving more data to the bit-fields of `Stmt` (and moreover most 
people now care
about 64 bits archs as a host).

Therefore move back the number of `CXXBaseSpecifiers` in `CastExpr` to the 
bit-fields of `Stmt`.
This in effect mostly revert r338489 while keeping the added test.


Repository:
  rC Clang

https://reviews.llvm.org/D56358

Files:
  include/clang/AST/Expr.h
  include/clang/AST/ExprCXX.h
  include/clang/AST/ExprObjC.h
  include/clang/AST/Stmt.h
  lib/AST/Expr.cpp
  lib/AST/ExprCXX.cpp

Index: lib/AST/ExprCXX.cpp
===
--- lib/AST/ExprCXX.cpp
+++ lib/AST/ExprCXX.cpp
@@ -694,9 +694,7 @@
  SourceLocation RParenLoc,
  SourceRange AngleBrackets) {
   unsigned PathSize = (BasePath ? BasePath->size() : 0);
-  void *Buffer =
-  C.Allocate(totalSizeToAlloc(
-  PathSize ? 1 : 0, PathSize));
+  void *Buffer = C.Allocate(totalSizeToAlloc(PathSize));
   auto *E =
   new (Buffer) CXXStaticCastExpr(T, VK, K, Op, PathSize, WrittenTy, L,
  RParenLoc, AngleBrackets);
@@ -708,9 +706,7 @@
 
 CXXStaticCastExpr *CXXStaticCastExpr::CreateEmpty(const ASTContext &C,
   unsigned PathSize) {
-  void *Buffer =
-  C.Allocate(totalSizeToAlloc(
-  PathSize ? 1 : 0, PathSize));
+  void *Buffer = C.Allocate(totalSizeToAlloc(PathSize));
   return new (Buffer) CXXStaticCastExpr(EmptyShell(), PathSize);
 }
 
@@ -723,9 +719,7 @@
SourceLocation RParenLoc,
SourceRange AngleBrackets) {
   unsigned PathSize = (BasePath ? BasePath->size() : 0);
-  void *Buffer =
-  C.Allocate(totalSizeToAlloc(
-  PathSize ? 1 : 0, PathSize));
+  void *Buffer = C.Allocate(totalSizeToAlloc(PathSize));
   auto *E =
   new (Buffer) CXXDynamicCastExpr(T, VK, K, Op, PathSize, WrittenTy, L,
   RParenLoc, AngleBrackets);
@@ -737,9 +731,7 @@
 
 CXXDynamicCastExpr *CXXDynamicCastExpr::CreateEmpty(const ASTContext &C,
 unsigned PathSize) {
-  void *Buffer =
-  C.Allocate(totalSizeToAlloc(
-  PathSize ? 1 : 0, PathSize));
+  void *Buffer = C.Allocate(totalSizeToAlloc(PathSize));
   return new (Buffer) CXXDynamicCastExpr(EmptyShell(), PathSize);
 }
 
@@ -784,9 +776,7 @@
SourceLocation RParenLoc,
SourceRange AngleBrackets) {
   unsigned PathSize = (BasePath ? BasePath->size() : 0);
-  void *Buffer =
-  C.Allocate(totalSizeToAlloc(
-  PathSize ? 1 : 0, PathSize));
+  void *Buffer = C.Allocate(totalSizeToAlloc(PathSize));
   auto *E =
   new (Buffer) CXXReinterpretCastExpr(T, VK, K, Op, PathSize, WrittenTy, L,
   RParenLoc, AngleBrackets);
@@ -798,9 +788,7 @@
 
 CXXReinterpretCastExpr *
 CXXReinterpretCastExpr::CreateEmpty(const ASTContext &C, unsigned PathSize) {
-  void *Buffer =
-  C.Allocate(totalSizeToAlloc(
-  PathSize ? 1 : 0, PathSize));
+  void *Buffer = C.Allocate(totalSizeToAlloc(PathSize));
   return new (Buffer) CXXReinterpretCastExpr(EmptyShell(), PathSize);
 }
 
@@ -823,9 +811,7 @@
   const CXXCastPath *BasePath,
   SourceLocation L, SourceLocation R) {
   unsigned PathSize = (BasePath ? BasePath->size() : 0);
-  void *Buffer =
-  C.Allocate(totalSizeToAlloc(
-  PathSize ? 1 : 0, PathSize));
+  void *Buffer = C.Allocate(totalSizeToAlloc(PathSize));
   auto *E =
   new (Buffer) CXXFunctionalCastExpr(T, VK, Written, K, Op, PathSize, L, R);
   if (PathSize)
@@ -836,9 +822,7 @@
 
 CXXFunctionalCastExpr *
 CXXFunctionalCastExpr::CreateEmpty(const ASTContext &C, unsigned PathSize) {
-  void *Buffer =
-  C.Allocate(totalSizeToAlloc(
-  PathSize ? 1 : 0, PathSize));
+  void *Buffer = C.Allocate(totalSizeToAlloc(PathSize));
   return new

[PATCH] D56358: [AST] Move back BasePathSize to the bit-fields of CastExpr

[Bruno Ricci via Phabricator via cfe-commits]

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



Comment at: include/clang/AST/Expr.h:3029
+assert((CastExprBits.BasePathSize == BasePathSize) &&
+   "BasePathSize overflow!");
 assert(CastConsistency());

It cannot overflow now, but someone in the future is going
to shrink `CastExprBitfields::BasePathSize`.



Comment at: include/clang/AST/Stmt.h:487
+/// here. ([implimits] Direct and indirect base classes [16384]).
+unsigned BasePathSize;
   };

Feel free to find a better comment here.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56358



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

[PATCH] D56358: [AST] Move back BasePathSize to the bit-fields of CastExpr

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added inline comments.



Comment at: include/clang/AST/Expr.h:3029
+assert((CastExprBits.BasePathSize == BasePathSize) &&
+   "BasePathSize overflow!");
 assert(CastConsistency());

riccibruno wrote:
> It cannot overflow now, but someone in the future is going
> to shrink `CastExprBitfields::BasePathSize`.
Can you move that static assert here instead of deleting it?


Repository:
  rC Clang

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

https://reviews.llvm.org/D56358



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

[PATCH] D56358: [AST] Move back BasePathSize to the bit-fields of CastExpr

[Bruno Ricci via Phabricator via cfe-commits]

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



Comment at: include/clang/AST/Expr.h:3029
+assert((CastExprBits.BasePathSize == BasePathSize) &&
+   "BasePathSize overflow!");
 assert(CastConsistency());

lebedev.ri wrote:
> riccibruno wrote:
> > It cannot overflow now, but someone in the future is going
> > to shrink `CastExprBitfields::BasePathSize`.
> Can you move that static assert here instead of deleting it?
I am not sure it is really useful since when someone will want to
shrink it, it will be stored as `unsigned BasePathSite : x;`. What we
don't want is having `x` too small. However `numeric_limits` will
be based on the underlying type of the bit-field and so will never fail.

Storing it as something other than an unsigned, say a short, would work,
but it will pack poorly with MSVC.

Hopefully the comment in `CastExprBitfields` will tell people to not shrink it
mindlessly.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56358



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

[PATCH] D56323: [clang-tidy] Handle member variables in readability-simplify-boolean-expr

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood marked 5 inline comments as done.
LegalizeAdulthood added inline comments.



Comment at: test/clang-tidy/readability-simplify-bool-expr-members.cpp:4
+struct X {
+  explicit operator bool();
+};

JonasToth wrote:
> LegalizeAdulthood wrote:
> > JonasToth wrote:
> > > I didn't see a test that utilized this struct, did I overlook it?
> > > 
> > > Implicit conversion to `bool`-cases would be interesting as well. Maybe 
> > > implicit conversion to integral in general.
> > Leftover from copy/paste of readability-simplify-bool-expr.cpp, I'll remove 
> > it.
> > 
> > Implicit conversion cases are covered by the other file.  Here, I'm just 
> > testing the cases that interact with member variables because the matcher 
> > needs to use memberExpr() and not just declRefExpr()
> Which other file? The other revision?
I based this new file off readability-simplify-bool-expr.cpp that is already 
there.  It has all the main test cases for this check.



Comment at: test/clang-tidy/readability-simplify-bool-expr-members.cpp:160
+  // CHECK-MESSAGES: :[[@LINE-1]]:21: warning: {{.*}} in ternary expression 
result
+  // CHECK-FIXES: {{^  m_b2 = i <= 20;$}}
+

JonasToth wrote:
> LegalizeAdulthood wrote:
> > JonasToth wrote:
> > > For this case the logical inversion is simple an obviously `<=`, but what 
> > > if the condition is more complex?
> > > 
> > > I would personally prefer `!(i < 20)` instead + complex logical 
> > > expressions as additional test. They would be interesting for the `if` 
> > > cases, too.
> > If you have complex conditions, you can run the check repeatedly until you 
> > reach a fixed point.
> > 
> > Using !(x) instead of the reverse operator could be added as an 
> > enhancement, but it is not covered by this patch.
> But the current version is the enhancement.
> The complex condition, like `i < 20 && i > 0` will be the common case, so the 
> inversion (with parens) should always be used (`!(i < 20 && i > 0)`) and 
> specializations can be done later.
No, the current version is a bug fix.  The simplification of boolean 
expressions was already there, but it didn't handle member variables properly.

You're asking for an additional enhancement about the way boolean expressions 
are simplified.  That's fine for an additional enhancement of the check, but it 
is not the point of this patch.

The complex expression you're discussing in your comment is not changed by this 
change, nor is it changed by the existing check.


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

https://reviews.llvm.org/D56323



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

[PATCH] D56323: [clang-tidy] Handle member variables in readability-simplify-boolean-expr

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood updated this revision to Diff 180379.
LegalizeAdulthood marked 2 inline comments as done.
LegalizeAdulthood added a comment.

Update from review comments


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

https://reviews.llvm.org/D56323

Files:
  clang-tidy/readability/SimplifyBooleanExprCheck.cpp
  test/clang-tidy/readability-simplify-bool-expr-members.cpp

Index: test/clang-tidy/readability-simplify-bool-expr-members.cpp
===
--- /dev/null
+++ test/clang-tidy/readability-simplify-bool-expr-members.cpp
@@ -0,0 +1,356 @@
+// RUN: %check_clang_tidy %s readability-simplify-boolean-expr %t
+
+class A {
+public:
+  int m;
+};
+
+struct S {
+  S() : m_ar(s_a) {}
+
+  void operator_equals();
+  void operator_or();
+  void operator_and();
+  void ternary_operator();
+  void operator_not_equal();
+  void simple_conditional_assignment_statements();
+  void complex_conditional_assignment_statements();
+  void chained_conditional_assignment();
+  bool non_null_pointer_condition();
+  bool null_pointer_condition();
+  bool negated_non_null_pointer_condition();
+  bool negated_null_pointer_condition();
+  bool integer_not_zero();
+  bool member_pointer_nullptr();
+  bool integer_member_implicit_cast();
+  bool expr_with_cleanups();
+
+  bool m_b1 = false;
+  bool m_b2 = false;
+  bool m_b3 = false;
+  bool m_b4 = false;
+  int *m_p = nullptr;
+  int A::*m_m = nullptr;
+  int m_i = 0;
+  A *m_a = nullptr;
+  static A s_a;
+  A &m_ar;
+};
+
+void S::operator_equals() {
+  int i = 0;
+  m_b1 = (i > 2);
+  if (m_b1 == true) {
+// CHECK-MESSAGES: :[[@LINE-1]]:15: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{^  if \(m_b1\) {$}}
+i = 5;
+  } else {
+i = 6;
+  }
+  m_b2 = (i > 4);
+  if (m_b2 == false) {
+// CHECK-MESSAGES: :[[@LINE-1]]:15: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{^  if \(!m_b2\) {$}}
+i = 7;
+  } else {
+i = 9;
+  }
+  m_b3 = (i > 6);
+  if (true == m_b3) {
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{^  if \(m_b3\) {$}}
+i = 10;
+  } else {
+i = 11;
+  }
+  m_b4 = (i > 8);
+  if (false == m_b4) {
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{^  if \(!m_b4\) {$}}
+i = 12;
+  } else {
+i = 13;
+  }
+}
+
+void S::operator_or() {
+  int i = 0;
+  m_b1 = (i > 10);
+  if (m_b1 || false) {
+// CHECK-MESSAGES: :[[@LINE-1]]:15: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{^  if \(m_b1\) {$}}
+i = 14;
+  } else {
+i = 15;
+  }
+  m_b2 = (i > 10);
+  if (m_b2 || true) {
+// CHECK-MESSAGES: :[[@LINE-1]]:15: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{^  if \(true\) {$}}
+i = 16;
+  } else {
+i = 17;
+  }
+  m_b3 = (i > 10);
+  if (false || m_b3) {
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{^  if \(m_b3\) {$}}
+i = 18;
+  } else {
+i = 19;
+  }
+  m_b4 = (i > 10);
+  if (true || m_b4) {
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{^  if \(true\) {$}}
+i = 20;
+  } else {
+i = 21;
+  }
+}
+
+void S::operator_and() {
+  int i = 0;
+  m_b1 = (i > 20);
+  if (m_b1 && false) {
+// CHECK-MESSAGES: :[[@LINE-1]]:15: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{^  if \(false\) {$}}
+i = 22;
+  } else {
+i = 23;
+  }
+  m_b2 = (i > 20);
+  if (m_b2 && true) {
+// CHECK-MESSAGES: :[[@LINE-1]]:15: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{^  if \(m_b2\) {$}}
+i = 24;
+  } else {
+i = 25;
+  }
+  m_b3 = (i > 20);
+  if (false && m_b3) {
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{^  if \(false\) {$}}
+i = 26;
+  } else {
+i = 27;
+  }
+  m_b4 = (i > 20);
+  if (true && m_b4) {
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{^  if \(m_b4\) {$}}
+i = 28;
+  } else {
+i = 29;
+  }
+}
+
+void S::ternary_operator() {
+  int i = 0;
+  m_b1 = (i > 20) ? true : false;
+  // CHECK-MESSAGES: :[[@LINE-1]]:21: warning: {{.*}} in ternary expression result
+  // CHECK-FIXES: {{^  m_b1 = i > 20;$}}
+
+  m_b2 = (i > 20) ? false : true;
+  // CHECK-MESSAGES: :[[@LINE-1]]:21: warning: {{.*}} in ternary expression result
+  // CHECK-FIXES: {{^  m_b2 = i <= 20;$}}
+
+  m_b3 = ((i > 20)) ? false : true;
+  // CHECK-MESSAGES: :[[@LINE-1]]:23: warning: {{.*}} in ternary expression result
+  // CHECK-FIXES: {{^  m_b3 = i <= 20;$}}
+}
+
+void S::operator_not_equal() {
+  int i = 0;
+  m_b1 = (i > 20);
+  if (false != m_b1) {
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{^  if \(m_b1\) {$}}
+i = 30;
+  } else {
+i = 31;
+  }
+  m_b2 = (i > 20);
+  if (true != m_b2) {
+// CHE

[PATCH] D56323: [clang-tidy] Handle member variables in readability-simplify-boolean-expr

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added inline comments.



Comment at: test/clang-tidy/readability-simplify-bool-expr-members.cpp:160
+  // CHECK-MESSAGES: :[[@LINE-1]]:21: warning: {{.*}} in ternary expression 
result
+  // CHECK-FIXES: {{^  m_b2 = i <= 20;$}}
+

LegalizeAdulthood wrote:
> JonasToth wrote:
> > LegalizeAdulthood wrote:
> > > JonasToth wrote:
> > > > For this case the logical inversion is simple an obviously `<=`, but 
> > > > what if the condition is more complex?
> > > > 
> > > > I would personally prefer `!(i < 20)` instead + complex logical 
> > > > expressions as additional test. They would be interesting for the `if` 
> > > > cases, too.
> > > If you have complex conditions, you can run the check repeatedly until 
> > > you reach a fixed point.
> > > 
> > > Using !(x) instead of the reverse operator could be added as an 
> > > enhancement, but it is not covered by this patch.
> > But the current version is the enhancement.
> > The complex condition, like `i < 20 && i > 0` will be the common case, so 
> > the inversion (with parens) should always be used (`!(i < 20 && i > 0)`) 
> > and specializations can be done later.
> No, the current version is a bug fix.  The simplification of boolean 
> expressions was already there, but it didn't handle member variables properly.
> 
> You're asking for an additional enhancement about the way boolean expressions 
> are simplified.  That's fine for an additional enhancement of the check, but 
> it is not the point of this patch.
> 
> The complex expression you're discussing in your comment is not changed by 
> this change, nor is it changed by the existing check.
I see, then I did misunderstand these changes.


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

https://reviews.llvm.org/D56323



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

[PATCH] D56323: [clang-tidy] Handle member variables in readability-simplify-boolean-expr

[Jonas Toth via Phabricator via cfe-commits]

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

Did you check if the changes actually fix the problematic behaviour? Did you 
run it over any project and did the code-transformation break the code, false 
positives, ...?

Otherwise LGTM


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

https://reviews.llvm.org/D56323



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

[PATCH] D56303: [clang-tidy] Handle case/default statements when simplifying boolean expressions

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood marked 10 inline comments as done.
LegalizeAdulthood added inline comments.



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:386
 
-  bool BoolValue = Bool->getValue();
+  const bool BoolValue = Bool->getValue();
 

JonasToth wrote:
> `const` on values is uncommon in clang-tidy code. Please keep that consistent.
I can change the code, but I don't understand the push back.

"That's the way it's done elsewhere" just doesn't seem like good reasoning.

I write const on values to signify that they are computed once and only once.  
What is gained by removing that statement of once-and-only-once?



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:533-540
+  switchStmt(has(
+  compoundStmt(
+  has(defaultStmt(hasDescendant(ifStmt(hasThen(returnsBool(Value)),
+   unless(hasElse(stmt(
+.bind(CompoundIfId)))
+  .bind(DefaultId)),
+  has(returnStmt(has(cxxBoolLiteral(equals(!Value))

aaron.ballman wrote:
> The check duplication here is unfortunate -- can you factor out the 
> `hasDescendant()` bits into a variable that is reused, and perhaps use 
> `anyOf(caseStmt(stuff()), defaultStmt(stuff()))` rather than separate 
> functions?
I'm not a fan of duplication, either.

However, I have to know if it's a CaseStmt or DefaultStmt in the replacement 
code and that's tied to the id, so I'm not sure how to collapse it further.



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:719
+bool Negated, const SwitchCase *SwitchCase) {
+  assert(SwitchCase != nullptr);
+

aaron.ballman wrote:
> Add a message to the assertion (same with the other ones).
I'm not sure what you're asking for.  I based these asserts off the existing 
assert in the file.



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:743
+  // if the next statement after the if contains a return statement of
+  // the correct form.  Ideally we'd be able to express this with the
+  // matchers, but that is currently impossible.

JonasToth wrote:
> double space
What exactly is the problem?



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:745
+  // matchers, but that is currently impossible.
+  //
+  const auto *If = dyn_cast(SwitchCase->getSubStmt());

JonasToth wrote:
> redundant empty comment line
Meh, it's not redundant.  It's there to aid readability of a big block of text 
by visually separating it from the associated code.

Why is this a problem?



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:747
+  const auto *If = dyn_cast(SwitchCase->getSubStmt());
+  assert(If != nullptr);
+  const CXXBoolLiteralExpr *Lit = stmtReturnsBool(If, Negated);

JonasToth wrote:
> I think this assertion does not hold true from the matcher.
> The matcher requires only `hasDescendent(ifStmt())`, but that does not ensure 
> the first stmt is the `ifStmt`.
> 
> e.g.
> ```
> case 10: {
>   loggingCall();
>   if(foo) ...
> ```
> 
> Is this excluded?
> }
Look more carefully at the AST.  CaseStmt has exactly one child.  That child 
can either be a compound statement block (which was already correctly handled 
by the check) or it can be a single statement.  This change enhances the check 
to handle the single statement child of the CaseStmt and DefaultStmt.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56303



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

[PATCH] D56303: [clang-tidy] Handle case/default statements when simplifying boolean expressions

[Bruno Ricci via Phabricator via cfe-commits]

riccibruno added inline comments.



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:719
+bool Negated, const SwitchCase *SwitchCase) {
+  assert(SwitchCase != nullptr);
+

LegalizeAdulthood wrote:
> aaron.ballman wrote:
> > Add a message to the assertion (same with the other ones).
> I'm not sure what you're asking for.  I based these asserts off the existing 
> assert in the file.
Something like `assert((SwitchCase != nullptr) && "Some appropriate message 
blablabla!");`
Keep the parentheses around the operands of `!=` even if they are not strictly 
needed
since otherwise some bots will complain.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56303



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

[PATCH] D56303: [clang-tidy] Handle case/default statements when simplifying boolean expressions

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood updated this revision to Diff 180380.
LegalizeAdulthood marked an inline comment as done.
LegalizeAdulthood added a comment.

Update from review comments


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

https://reviews.llvm.org/D56303

Files:
  clang-tidy/readability/SimplifyBooleanExprCheck.cpp
  clang-tidy/readability/SimplifyBooleanExprCheck.h
  test/clang-tidy/readability-simplify-bool-expr-case.cpp

Index: test/clang-tidy/readability-simplify-bool-expr-case.cpp
===
--- /dev/null
+++ test/clang-tidy/readability-simplify-bool-expr-case.cpp
@@ -0,0 +1,586 @@
+// RUN: %check_clang_tidy %s readability-simplify-boolean-expr %t
+
+bool switch_stmt(int i, int j, bool b) {
+  switch (i) {
+  case 0:
+if (b == true)
+  j = 10;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(b\)}}
+// CHECK-FIXES-NEXT: {{j = 10;}}
+
+  case 1:
+if (b == false)
+  j = -20;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(!b\)}}
+// CHECK-FIXES-NEXT: {{j = -20;}}
+
+  case 2:
+if (b && true)
+  j = 10;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(b\)}}
+// CHECK-FIXES-NEXT: {{j = 10;}}
+
+  case 3:
+if (b && false)
+  j = -20;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(false\)}}
+// CHECK-FIXES-NEXT: {{j = -20;}}
+
+  case 4:
+if (b || true)
+  j = 10;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(true\)}}
+// CHECK-FIXES-NEXT: {{j = 10;}}
+// CHECK-FIXES-NEXT: {{break;}}
+
+  case 5:
+if (b || false)
+  j = -20;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(b\)}}
+// CHECK-FIXES-NEXT: {{j = -20;}}
+
+  case 6:
+return i > 0 ? true : false;
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: {{.*}} in ternary expression result
+// CHECK-FIXES: {{return i > 0;}}
+
+  case 7:
+return i > 0 ? false : true;
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: {{.*}} in ternary expression result
+// CHECK-FIXES: {{return i <= 0;}}
+
+  case 8:
+if (true)
+  j = 10;
+else
+  j = -20;
+break;
+// CHECK-MESSAGES: :[[@LINE-5]]:9: warning: {{.*}} in if statement condition
+// CHECK-FIXES:  {{j = 10;$}}
+// CHECK-FIXES-NEXT: {{break;$}}
+
+  case 9:
+if (false)
+  j = -20;
+else
+  j = 10;
+break;
+// CHECK-MESSAGES: :[[@LINE-5]]:9: warning: {{.*}} in if statement condition
+// CHECK-FIXES: {{j = 10;}}
+// CHECK-FIXES-NEXT: {{break;}}
+
+  case 10:
+if (j > 10)
+  return true;
+else
+  return false;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} in conditional return statement
+// CHECK-FIXES: {{return j > 10;}}
+
+  case 11:
+if (j > 10)
+  return false;
+else
+  return true;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} in conditional return statement
+// CHECK-FIXES: {{return j <= 10;}}
+
+  case 12:
+if (j > 10)
+  b = true;
+else
+  b = false;
+return b;
+// CHECK-MESSAGES: :[[@LINE-4]]:11: warning: {{.*}} in conditional assignment
+// CHECK-FIXES: {{b = j > 10;}}
+// CHECK-FIXES-NEXT: {{return b;}}
+
+  case 13:
+if (j > 10)
+  b = false;
+else
+  b = true;
+return b;
+// CHECK-MESSAGES: :[[@LINE-4]]:11: warning: {{.*}} in conditional assignment
+// CHECK-FIXES: {{b = j <= 10;}}
+// CHECK-FIXES-NEXT: {{return b;}}
+
+  case 14:
+if (j > 10)
+  return true;
+return false;
+// CHECK-MESSAGES: :[[@LINE-2]]:14: warning: {{.*}} in conditional return
+// FIXES: {{return j > 10;}}
+
+  case 15:
+if (j > 10)
+  return false;
+return true;
+// CHECK-MESSAGES: :[[@LINE-2]]:14: warning: {{.*}} in conditional return
+// FIXES: {{return j <= 10;}}
+
+  case 16:
+if (j > 10)
+  return true;
+return true;
+return false;
+
+  case 17:
+if (j > 10)
+  return false;
+return false;
+return true;
+
+  case 100: {
+if (b == true)
+  j = 10;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(b\)}}
+// CHECK-FIXES-NEXT: {{j = 10;}}
+  }
+
+  case 101: {
+if (b == false)
+  j = -20;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(!b\)}}
+// CHECK-FIXES-NEXT: {{j = -20;}}
+  }
+
+  case 102: {
+if (b && true)
+  j = 10;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(

[PATCH] D56323: [clang-tidy] Handle member variables in readability-simplify-boolean-expr

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood marked an inline comment as done.
LegalizeAdulthood added a comment.

In D56323#1347450 , @JonasToth wrote:

> Did you check if the changes actually fix the problematic behaviour? Did you 
> run it over any project and did the code-transformation break the code, false 
> positives, ...?
>
> Otherwise LGTM


The test cases that I added covered the behavior described in the bug report.  
I didn't run it over clang to see if it introduced any false positives, I can 
do that.  However, when I originally wrote this check it was pretty well tested 
and I have confidence that I haven't regressed. However, it's still worth 
testing, so I will do that.


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

https://reviews.llvm.org/D56323



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

r350482 - Fix MSVC Visualization for TemplateTypeParmType and TemplateTypeParmDecl

[Mike Spertus via cfe-commits]

Author: mps
Date: Sat Jan  5 15:15:30 2019
New Revision: 350482

URL: http://llvm.org/viewvc/llvm-project?rev=350482&view=rev
Log:
Fix MSVC Visualization for TemplateTypeParmType and TemplateTypeParmDecl

Modified:
cfe/trunk/utils/ClangVisualizers/clang.natvis

Modified: cfe/trunk/utils/ClangVisualizers/clang.natvis
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/ClangVisualizers/clang.natvis?rev=350482&r1=350481&r2=350482&view=diff
==
--- cfe/trunk/utils/ClangVisualizers/clang.natvis (original)
+++ cfe/trunk/utils/ClangVisualizers/clang.natvis Sat Jan  5 15:15:30 2019
@@ -57,14 +57,13 @@ For later versions of Visual Studio, no
   No TypeBits set beyond TypeClass
 
 
-{*this, view(Dependent)}{*this, view(InstantiationDependent)}{*this, 
view(VariablyModified)}
-{*this, view(ContainsUnexpandedParameterPack)}{*this, view(Cache)}{*this, 
view(FromAST)}
+{*this, view(Dependent)}{*this, view(InstantiationDependent)}{*this, 
view(VariablyModified)}
+{*this, view(ContainsUnexpandedParameterPack)}{*this, view(Cache)}{*this, 
view(FromAST)}
 {*this,view(cmn)}  {{{*this,view(poly)}}}
 
   (clang::Type::TypeClass)TypeBits.TC
   *this,view(flags)
   CanonicalType
-  CanonicalType.Value.Value == this
   *(clang::BuiltinType 
*)this
   *(clang::PointerType 
*)this
   *(clang::LValueReferenceType
 *)this
@@ -142,8 +141,9 @@ For later versions of Visual Studio, no
   
 typename
 class
-...
-
+(not yet known if parameter pack) 
+...
+
 {*this,view(TorC)} 
{*this,view(MaybeEllipses)}{Name,view(cpp)} 
   
   
@@ -227,8 +227,10 @@ For later versions of Visual Studio, no
 
   
   
-{*TTPDecl,view(cpp)}
-{*TTPDecl}
+Non-canonical: {*TTPDecl}
+Canonical: {CanTTPTInfo}
+
+
   
   
 {*Decl,view(cpp)}
@@ -261,6 +263,7 @@ For later versions of Visual Studio, no
 {" ",sb}volatile restrict
 {" ",sb}const volatile restrict
 Cannot visualize non-fast 
qualifiers
+Null
 {*((clang::ExtQualsTypeCommonBase 
*)(((uintptr_t)Value.Value) & ~(uintptr_t)((1 << 4) - 
1)))->BaseType}{*this,view(fastQuals)}
 
   *this,view(fastQuals)


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

r350484 - Revert "[CMake][Fuchsia] Enable experimental new pass manager by default"

[Petr Hosek via cfe-commits]

Author: phosek
Date: Sat Jan  5 15:45:31 2019
New Revision: 350484

URL: http://llvm.org/viewvc/llvm-project?rev=350484&view=rev
Log:
Revert "[CMake][Fuchsia] Enable experimental new pass manager by default"

This reverts commit r350461 as it causes many of the Clang tests to fail.

Modified:
cfe/trunk/cmake/caches/Fuchsia-stage2.cmake

Modified: cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/Fuchsia-stage2.cmake?rev=350484&r1=350483&r2=350484&view=diff
==
--- cfe/trunk/cmake/caches/Fuchsia-stage2.cmake (original)
+++ cfe/trunk/cmake/caches/Fuchsia-stage2.cmake Sat Jan  5 15:45:31 2019
@@ -16,7 +16,6 @@ set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL
 
 set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
 set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
-set(ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER ON CACHE BOOL "")
 
 set(LLVM_ENABLE_LTO ON CACHE BOOL "")
 if(NOT APPLE)


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

[PATCH] D56303: [clang-tidy] Handle case/default statements when simplifying boolean expressions

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood updated this revision to Diff 180384.
LegalizeAdulthood marked an inline comment as done.
LegalizeAdulthood added a comment.

Update from review comments


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

https://reviews.llvm.org/D56303

Files:
  clang-tidy/readability/SimplifyBooleanExprCheck.cpp
  clang-tidy/readability/SimplifyBooleanExprCheck.h
  test/clang-tidy/readability-simplify-bool-expr-case.cpp

Index: test/clang-tidy/readability-simplify-bool-expr-case.cpp
===
--- /dev/null
+++ test/clang-tidy/readability-simplify-bool-expr-case.cpp
@@ -0,0 +1,586 @@
+// RUN: %check_clang_tidy %s readability-simplify-boolean-expr %t
+
+bool switch_stmt(int i, int j, bool b) {
+  switch (i) {
+  case 0:
+if (b == true)
+  j = 10;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(b\)}}
+// CHECK-FIXES-NEXT: {{j = 10;}}
+
+  case 1:
+if (b == false)
+  j = -20;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(!b\)}}
+// CHECK-FIXES-NEXT: {{j = -20;}}
+
+  case 2:
+if (b && true)
+  j = 10;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(b\)}}
+// CHECK-FIXES-NEXT: {{j = 10;}}
+
+  case 3:
+if (b && false)
+  j = -20;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(false\)}}
+// CHECK-FIXES-NEXT: {{j = -20;}}
+
+  case 4:
+if (b || true)
+  j = 10;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(true\)}}
+// CHECK-FIXES-NEXT: {{j = 10;}}
+// CHECK-FIXES-NEXT: {{break;}}
+
+  case 5:
+if (b || false)
+  j = -20;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(b\)}}
+// CHECK-FIXES-NEXT: {{j = -20;}}
+
+  case 6:
+return i > 0 ? true : false;
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: {{.*}} in ternary expression result
+// CHECK-FIXES: {{return i > 0;}}
+
+  case 7:
+return i > 0 ? false : true;
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: {{.*}} in ternary expression result
+// CHECK-FIXES: {{return i <= 0;}}
+
+  case 8:
+if (true)
+  j = 10;
+else
+  j = -20;
+break;
+// CHECK-MESSAGES: :[[@LINE-5]]:9: warning: {{.*}} in if statement condition
+// CHECK-FIXES:  {{j = 10;$}}
+// CHECK-FIXES-NEXT: {{break;$}}
+
+  case 9:
+if (false)
+  j = -20;
+else
+  j = 10;
+break;
+// CHECK-MESSAGES: :[[@LINE-5]]:9: warning: {{.*}} in if statement condition
+// CHECK-FIXES: {{j = 10;}}
+// CHECK-FIXES-NEXT: {{break;}}
+
+  case 10:
+if (j > 10)
+  return true;
+else
+  return false;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} in conditional return statement
+// CHECK-FIXES: {{return j > 10;}}
+
+  case 11:
+if (j > 10)
+  return false;
+else
+  return true;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} in conditional return statement
+// CHECK-FIXES: {{return j <= 10;}}
+
+  case 12:
+if (j > 10)
+  b = true;
+else
+  b = false;
+return b;
+// CHECK-MESSAGES: :[[@LINE-4]]:11: warning: {{.*}} in conditional assignment
+// CHECK-FIXES: {{b = j > 10;}}
+// CHECK-FIXES-NEXT: {{return b;}}
+
+  case 13:
+if (j > 10)
+  b = false;
+else
+  b = true;
+return b;
+// CHECK-MESSAGES: :[[@LINE-4]]:11: warning: {{.*}} in conditional assignment
+// CHECK-FIXES: {{b = j <= 10;}}
+// CHECK-FIXES-NEXT: {{return b;}}
+
+  case 14:
+if (j > 10)
+  return true;
+return false;
+// CHECK-MESSAGES: :[[@LINE-2]]:14: warning: {{.*}} in conditional return
+// FIXES: {{return j > 10;}}
+
+  case 15:
+if (j > 10)
+  return false;
+return true;
+// CHECK-MESSAGES: :[[@LINE-2]]:14: warning: {{.*}} in conditional return
+// FIXES: {{return j <= 10;}}
+
+  case 16:
+if (j > 10)
+  return true;
+return true;
+return false;
+
+  case 17:
+if (j > 10)
+  return false;
+return false;
+return true;
+
+  case 100: {
+if (b == true)
+  j = 10;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(b\)}}
+// CHECK-FIXES-NEXT: {{j = 10;}}
+  }
+
+  case 101: {
+if (b == false)
+  j = -20;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(!b\)}}
+// CHECK-FIXES-NEXT: {{j = -20;}}
+  }
+
+  case 102: {
+if (b && true)
+  j = 10;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(

[PATCH] D56303: [clang-tidy] Handle case/default statements when simplifying boolean expressions

[Richard via Phabricator via cfe-commits]

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



Comment at: clang-tidy/readability/SimplifyBooleanExprCheck.cpp:719
+bool Negated, const SwitchCase *SwitchCase) {
+  assert(SwitchCase != nullptr);
+

riccibruno wrote:
> LegalizeAdulthood wrote:
> > aaron.ballman wrote:
> > > Add a message to the assertion (same with the other ones).
> > I'm not sure what you're asking for.  I based these asserts off the 
> > existing assert in the file.
> Something like `assert((SwitchCase != nullptr) && "Some appropriate message 
> blablabla!");`
> Keep the parentheses around the operands of `!=` even if they are not 
> strictly needed
> since otherwise some bots will complain.
OK, I can do that; I wasn't sure if it was being suggested that I use some 
custom assert macro that took the message as a parameter.


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

https://reviews.llvm.org/D56303



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

[PATCH] D56303: [clang-tidy] Handle case/default statements when simplifying boolean expressions

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood updated this revision to Diff 180385.
LegalizeAdulthood added a comment.

No really, update from review comments `:)`


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

https://reviews.llvm.org/D56303

Files:
  clang-tidy/readability/SimplifyBooleanExprCheck.cpp
  clang-tidy/readability/SimplifyBooleanExprCheck.h
  test/clang-tidy/readability-simplify-bool-expr-case.cpp

Index: test/clang-tidy/readability-simplify-bool-expr-case.cpp
===
--- /dev/null
+++ test/clang-tidy/readability-simplify-bool-expr-case.cpp
@@ -0,0 +1,586 @@
+// RUN: %check_clang_tidy %s readability-simplify-boolean-expr %t
+
+bool switch_stmt(int i, int j, bool b) {
+  switch (i) {
+  case 0:
+if (b == true)
+  j = 10;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(b\)}}
+// CHECK-FIXES-NEXT: {{j = 10;}}
+
+  case 1:
+if (b == false)
+  j = -20;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(!b\)}}
+// CHECK-FIXES-NEXT: {{j = -20;}}
+
+  case 2:
+if (b && true)
+  j = 10;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(b\)}}
+// CHECK-FIXES-NEXT: {{j = 10;}}
+
+  case 3:
+if (b && false)
+  j = -20;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(false\)}}
+// CHECK-FIXES-NEXT: {{j = -20;}}
+
+  case 4:
+if (b || true)
+  j = 10;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(true\)}}
+// CHECK-FIXES-NEXT: {{j = 10;}}
+// CHECK-FIXES-NEXT: {{break;}}
+
+  case 5:
+if (b || false)
+  j = -20;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(b\)}}
+// CHECK-FIXES-NEXT: {{j = -20;}}
+
+  case 6:
+return i > 0 ? true : false;
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: {{.*}} in ternary expression result
+// CHECK-FIXES: {{return i > 0;}}
+
+  case 7:
+return i > 0 ? false : true;
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: {{.*}} in ternary expression result
+// CHECK-FIXES: {{return i <= 0;}}
+
+  case 8:
+if (true)
+  j = 10;
+else
+  j = -20;
+break;
+// CHECK-MESSAGES: :[[@LINE-5]]:9: warning: {{.*}} in if statement condition
+// CHECK-FIXES:  {{j = 10;$}}
+// CHECK-FIXES-NEXT: {{break;$}}
+
+  case 9:
+if (false)
+  j = -20;
+else
+  j = 10;
+break;
+// CHECK-MESSAGES: :[[@LINE-5]]:9: warning: {{.*}} in if statement condition
+// CHECK-FIXES: {{j = 10;}}
+// CHECK-FIXES-NEXT: {{break;}}
+
+  case 10:
+if (j > 10)
+  return true;
+else
+  return false;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} in conditional return statement
+// CHECK-FIXES: {{return j > 10;}}
+
+  case 11:
+if (j > 10)
+  return false;
+else
+  return true;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} in conditional return statement
+// CHECK-FIXES: {{return j <= 10;}}
+
+  case 12:
+if (j > 10)
+  b = true;
+else
+  b = false;
+return b;
+// CHECK-MESSAGES: :[[@LINE-4]]:11: warning: {{.*}} in conditional assignment
+// CHECK-FIXES: {{b = j > 10;}}
+// CHECK-FIXES-NEXT: {{return b;}}
+
+  case 13:
+if (j > 10)
+  b = false;
+else
+  b = true;
+return b;
+// CHECK-MESSAGES: :[[@LINE-4]]:11: warning: {{.*}} in conditional assignment
+// CHECK-FIXES: {{b = j <= 10;}}
+// CHECK-FIXES-NEXT: {{return b;}}
+
+  case 14:
+if (j > 10)
+  return true;
+return false;
+// CHECK-MESSAGES: :[[@LINE-2]]:14: warning: {{.*}} in conditional return
+// FIXES: {{return j > 10;}}
+
+  case 15:
+if (j > 10)
+  return false;
+return true;
+// CHECK-MESSAGES: :[[@LINE-2]]:14: warning: {{.*}} in conditional return
+// FIXES: {{return j <= 10;}}
+
+  case 16:
+if (j > 10)
+  return true;
+return true;
+return false;
+
+  case 17:
+if (j > 10)
+  return false;
+return false;
+return true;
+
+  case 100: {
+if (b == true)
+  j = 10;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(b\)}}
+// CHECK-FIXES-NEXT: {{j = 10;}}
+  }
+
+  case 101: {
+if (b == false)
+  j = -20;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(!b\)}}
+// CHECK-FIXES-NEXT: {{j = -20;}}
+  }
+
+  case 102: {
+if (b && true)
+  j = 10;
+break;
+// CHECK-MESSAGES: :[[@LINE-3]]:14: warning: {{.*}} to boolean operator
+// CHECK-FIXES: {{if \(b\)}}
+// CHECK-FIXES-NEXT: {{j 

[PATCH] D56323: [clang-tidy] Handle member variables in readability-simplify-boolean-expr

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood added a comment.

Uh... I'm developing on Windows, which doesn't have a solution for generating 
compile_commands.json, so I can't easily test this on the entire clang 
codebase.  I will test on a source file based on the original bug report.


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

https://reviews.llvm.org/D56323



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

[PATCH] D56359: [CMake][Fuchsia] Enable build ID, relaxations for first stage

[Petr Hosek via Phabricator via cfe-commits]

phosek created this revision.
phosek added a reviewer: mcgrathr.
Herald added subscribers: cfe-commits, mgorny.

We want these to be used for the second stage compiler as well.


Repository:
  rC Clang

https://reviews.llvm.org/D56359

Files:
  clang/cmake/caches/Fuchsia.cmake


Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -14,6 +14,9 @@
 set(CLANG_INCLUDE_TESTS OFF CACHE BOOL "")
 set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "")
 
+set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
+set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
+
 set(LLVM_ENABLE_ASSERTIONS ON CACHE BOOL "")
 set(CMAKE_BUILD_TYPE Release CACHE STRING "")
 


Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -14,6 +14,9 @@
 set(CLANG_INCLUDE_TESTS OFF CACHE BOOL "")
 set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "")
 
+set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
+set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
+
 set(LLVM_ENABLE_ASSERTIONS ON CACHE BOOL "")
 set(CMAKE_BUILD_TYPE Release CACHE STRING "")
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56323: [clang-tidy] Handle member variables in readability-simplify-boolean-expr

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood added a comment.

I managed to do some limited testing on the original source file from the bug 
report in lldb and verified that the correct fix was applied there.  I also 
tried a few other files and verified no false positives.


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

https://reviews.llvm.org/D56323



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

[PATCH] D37035: Implement __builtin_LINE() et. al. to support source location capture.

[Eric Fiselier via Phabricator via cfe-commits]

EricWF added a comment.

Ping! I would like to land this before the next release.


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

https://reviews.llvm.org/D37035



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

[PATCH] D55500: [Builtins] Implement __builtin_is_constant_evaluated for use in C++2a

[Eric Fiselier via Phabricator via cfe-commits]

EricWF marked an inline comment as done.
EricWF added a comment.

Ping! I would like to land this before the next release.

@rsmith, what sorts of additional tests are needed?




Comment at: include/clang/Basic/Builtins.def:759
+// Random C++ builtins.
+LANGBUILTIN(__builtin_is_constant_evaluated, "b", "ncu", CXX_LANG)
+

EricWF wrote:
> bruno wrote:
> > Name bikeshedding : perhaps the builtin name could be detached from the 
> > std:: name? Suggestion: `__builtin_in_constant_evaluation_context`
> I'm not sure detaching it from the `std::` name is desirable. Most 
> importantly it should match w/e GCC does/decides to do.
> 
> But if it is, we should name in deference to the standardese it implements. 
> Specifically weither an expression or conversion is //manifestly 
> constant-evaluated// [[expr.const](http://eel.is/c++draft/expr.const#11)]p11.
> 
> Therefore I proffer  `__builtin_is_manifestly_constant_evaluated()` or 
> `__builtin_is_being_manifestly_constant_evaluated()`.
> 
> 
Actually, GCC has `__builtin_is_constant_evaluated` so we should use that name 
too.


Repository:
  rC Clang

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

https://reviews.llvm.org/D55500



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

[PATCH] D56359: [CMake][Fuchsia] Enable build ID, relaxations for first stage

[Roland McGrath via Phabricator via cfe-commits]

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

lgtm


Repository:
  rC Clang

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

https://reviews.llvm.org/D56359



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

[PATCH] D56314: [clangd] Don't store completion info if the symbol is not used for code completion.

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

Might we want to keep some of this information for `workspace/symbol`? I mean, 
surely not "documentation", but perhaps "signature" and "return type"?

For example, when cquery responds to `workspace/symbol`, it puts into 
`SymbolInformation.name` a "detailed name" 

 that includes the return type and signature for functions, allowing clients to 
display these in their "Open Element" dropdown. This is in turn useful for e.g. 
selecting the correct one among multiple overloads of a function to jump to.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56314



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

r350486 - [CMake][Fuchsia] Enable build ID, relaxations for first stage

[Petr Hosek via cfe-commits]

Author: phosek
Date: Sat Jan  5 20:14:51 2019
New Revision: 350486

URL: http://llvm.org/viewvc/llvm-project?rev=350486&view=rev
Log:
[CMake][Fuchsia] Enable build ID, relaxations for first stage

We want these to be used for the second stage compiler as well.

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

Modified:
cfe/trunk/cmake/caches/Fuchsia.cmake

Modified: cfe/trunk/cmake/caches/Fuchsia.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/Fuchsia.cmake?rev=350486&r1=350485&r2=350486&view=diff
==
--- cfe/trunk/cmake/caches/Fuchsia.cmake (original)
+++ cfe/trunk/cmake/caches/Fuchsia.cmake Sat Jan  5 20:14:51 2019
@@ -14,6 +14,9 @@ set(LLVM_ENABLE_ZLIB OFF CACHE BOOL "")
 set(CLANG_INCLUDE_TESTS OFF CACHE BOOL "")
 set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "")
 
+set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
+set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
+
 set(LLVM_ENABLE_ASSERTIONS ON CACHE BOOL "")
 set(CMAKE_BUILD_TYPE Release CACHE STRING "")
 


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

[PATCH] D56359: [CMake][Fuchsia] Enable build ID, relaxations for first stage

[Petr Hosek via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL350486: [CMake][Fuchsia] Enable build ID, relaxations for 
first stage (authored by phosek, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D56359?vs=180386&id=180388#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D56359

Files:
  cfe/trunk/cmake/caches/Fuchsia.cmake


Index: cfe/trunk/cmake/caches/Fuchsia.cmake
===
--- cfe/trunk/cmake/caches/Fuchsia.cmake
+++ cfe/trunk/cmake/caches/Fuchsia.cmake
@@ -14,6 +14,9 @@
 set(CLANG_INCLUDE_TESTS OFF CACHE BOOL "")
 set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "")
 
+set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
+set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
+
 set(LLVM_ENABLE_ASSERTIONS ON CACHE BOOL "")
 set(CMAKE_BUILD_TYPE Release CACHE STRING "")
 


Index: cfe/trunk/cmake/caches/Fuchsia.cmake
===
--- cfe/trunk/cmake/caches/Fuchsia.cmake
+++ cfe/trunk/cmake/caches/Fuchsia.cmake
@@ -14,6 +14,9 @@
 set(CLANG_INCLUDE_TESTS OFF CACHE BOOL "")
 set(CLANG_PLUGIN_SUPPORT OFF CACHE BOOL "")
 
+set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
+set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
+
 set(LLVM_ENABLE_ASSERTIONS ON CACHE BOOL "")
 set(CMAKE_BUILD_TYPE Release CACHE STRING "")
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r350487 - Have MSVC Visualizer for DeducedTemplateSpecializationType show both the original template and deduced specialization

[Mike Spertus via cfe-commits]

Author: mps
Date: Sat Jan  5 20:58:48 2019
New Revision: 350487

URL: http://llvm.org/viewvc/llvm-project?rev=350487&view=rev
Log:
Have MSVC Visualizer for DeducedTemplateSpecializationType show both the 
original template and deduced specialization

Now appears in the Autos window something like

- MyTypeDeducedTemplateSpecializationType  {struct Y}
|- Template template struct Y;
|- Deduced As   struct Y
|- isDeducedtruebool
|- TypeClassDeducedTemplateSpecialization (36)
|- FlagsNo TypeBits set beyond TypeClass
|- CanonicalRecordType  {struct Y}

Also changed QualType visualization to auto-expand the BaseType


Modified:
cfe/trunk/utils/ClangVisualizers/clang.natvis

Modified: cfe/trunk/utils/ClangVisualizers/clang.natvis
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/ClangVisualizers/clang.natvis?rev=350487&r1=350486&r2=350487&view=diff
==
--- cfe/trunk/utils/ClangVisualizers/clang.natvis (original)
+++ cfe/trunk/utils/ClangVisualizers/clang.natvis Sat Jan  5 20:58:48 2019
@@ -40,16 +40,16 @@ For later versions of Visual Studio, no
 {*(clang::LocInfoType *)this}
 {*this,view(poly)}
 No visualizer yet for 
{(clang::Type::TypeClass)TypeBits.TC,en}Type 
-Dependent
+Dependent{" ",sb}
 
-InstantiationDependent
+InstantiationDependent{" 
",sb}
 
-VariablyModified
+VariablyModified{" ",sb}
 
-ContainsUnexpandedParameterPack
+ContainsUnexpandedParameterPack{"
 ",sb}
 
 CachedLinkage: 
{(clang::Linkage)TypeBits.CachedLinkage,en} CachedLocalOrUnnamed
-CachedLinkage: 
{(clang::Linkage)TypeBits.CachedLinkage,en}
+CachedLinkage: 
{(clang::Linkage)TypeBits.CachedLinkage,en}{" ",sb}
 
 FromAST
 
@@ -162,13 +162,13 @@ For later versions of Visual Studio, no
   
 implicit{" 
",sb}
 
-{*this,view(implicit)}
+{*this,view(implicit)nd}
 {*this,view(modifiers)}{Name,view(cpp)}
-{*this,view(modifiers)}struct
 {Name,view(cpp)}
-{*this,view(modifiers)}interface
 {Name,view(cpp)}
-{*this,view(modifiers)}union
 {Name,view(cpp)}
-{*this,view(modifiers)}class
 {Name,view(cpp)}
-{*this,view(modifiers)}enum
 {Name,view(cpp)}
+{*this,view(modifiers)nd}struct
 {Name,view(cpp)}
+{*this,view(modifiers)nd}interface
 {Name,view(cpp)}
+{*this,view(modifiers)nd}union
 {Name,view(cpp)}
+{*this,view(modifiers)nd}class
 {Name,view(cpp)}
+{*this,view(modifiers)nd}enum
 {Name,view(cpp)}
 
   (clang::DeclContext *)this
 
@@ -227,6 +227,7 @@ For later versions of Visual Studio, no
 
   
   
+{*TTPDecl}
 Non-canonical: {*TTPDecl}
 Canonical: {CanTTPTInfo}
 
@@ -267,7 +268,7 @@ For later versions of Visual Studio, no
 {*((clang::ExtQualsTypeCommonBase 
*)(((uintptr_t)Value.Value) & ~(uintptr_t)((1 << 4) - 
1)))->BaseType}{*this,view(fastQuals)}
 
   *this,view(fastQuals)
-  *((clang::ExtQualsTypeCommonBase 
*)(((uintptr_t)Value.Value) & ~(uintptr_t)((1 << 4) - 
1)))->BaseType
+  *((clang::ExtQualsTypeCommonBase 
*)(((uintptr_t)Value.Value) & ~(uintptr_t)((1 << 4) - 
1)))->BaseType
 
   
   
@@ -419,9 +420,20 @@ For later versions of Visual Studio, no
 
   
   
+{CanonicalType,view(cpp)}
 {Template}
 
+  Template
+  CanonicalType,view(cpp)
   *(clang::DeducedType *)this
+  Template
+
+  
+  
+{*(CXXRecordDecl *)this,nd}{*TemplateArgs}
+
+  (CXXRecordDecl *)this,nd
+  TemplateArgs
 
   
   
@@ -532,7 +544,6 @@ For later versions of Visual Studio, no
   
 
   
-  *(clang::Type *)this, view(cmn)
 
   
   


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