[PATCH] D133092: [clang] fix generation of .debug_aranges with LTO

[Azat Khuzhin via Phabricator via cfe-commits]

azat updated this revision to Diff 458663.
azat added a comment.

Adjust comments as suggested by @dblaikie


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133092

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/Driver/debug-options.c


Index: clang/test/Driver/debug-options.c
===
--- clang/test/Driver/debug-options.c
+++ clang/test/Driver/debug-options.c
@@ -246,7 +246,11 @@
 // RUN: %clang -### -c -glldb %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 // RUN: %clang -### -c -glldb -gno-pubnames %s 2>&1 | FileCheck 
-check-prefix=NOPUB %s
 //
-// RUN: %clang -### -c -gdwarf-aranges %s 2>&1 | FileCheck 
-check-prefix=GARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -c -gdwarf-aranges %s 2>&1 | 
FileCheck -check-prefix=GARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -flto -gdwarf-aranges %s 2>&1 
| FileCheck -check-prefix=LDGARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -flto=thin -gdwarf-aranges %s 
2>&1 | FileCheck -check-prefix=LDGARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -fuse-ld=lld -flto 
-gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=LLDGARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -fuse-ld=lld -flto=thin 
-gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=LLDGARANGE %s
 //
 // RUN: %clang -### -fdebug-types-section -target x86_64-unknown-linux %s 2>&1 
\
 // RUN:| FileCheck -check-prefix=FDTS %s
@@ -371,6 +375,8 @@
 // NORNGBSE-NOT: -fdebug-ranges-base-address
 //
 // GARANGE-DAG: -generate-arange-section
+// LDGARANGE-NOT: {{".*lld.*"}} {{.*}} "-generate-arange-section"
+// LLDGARANGE: {{".*lld.*"}} {{.*}} "-generate-arange-section"
 //
 // FDTS: "-mllvm" "-generate-type-units"
 // FDTSE: error: unsupported option '-fdebug-types-section' for target 
'x86_64-apple-darwin'
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -506,6 +506,19 @@
 Suffix,
 Plugin);
 CmdArgs.push_back(Args.MakeArgString(Plugin));
+  } else {
+// NOTE:
+// - it is not possible to use lld for PS4
+// - addLTOOptions() is not used for PS5
+// Hence no need to handle SCE (like in Clang.cpp::renderDebugOptions()).
+//
+// And as @dblaikie noted, this solution is far from perfert, better to
+// encode it into IR metadata, but this may not worth it, since looks like
+// aranges on the way out.
+if (Args.hasArg(options::OPT_gdwarf_aranges)) {
+  CmdArgs.push_back(Args.MakeArgString("-mllvm"));
+  CmdArgs.push_back(Args.MakeArgString("-generate-arange-section"));
+}
   }
 
   // Try to pass driver level flags relevant to LTO code generation down to


Index: clang/test/Driver/debug-options.c
===
--- clang/test/Driver/debug-options.c
+++ clang/test/Driver/debug-options.c
@@ -246,7 +246,11 @@
 // RUN: %clang -### -c -glldb %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 // RUN: %clang -### -c -glldb -gno-pubnames %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 //
-// RUN: %clang -### -c -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=GARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -c -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=GARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -flto -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=LDGARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -flto=thin -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=LDGARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -fuse-ld=lld -flto -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=LLDGARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -fuse-ld=lld -flto=thin -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=LLDGARANGE %s
 //
 // RUN: %clang -### -fdebug-types-section -target x86_64-unknown-linux %s 2>&1 \
 // RUN:| FileCheck -check-prefix=FDTS %s
@@ -371,6 +375,8 @@
 // NORNGBSE-NOT: -fdebug-ranges-base-address
 //
 // GARANGE-DAG: -generate-arange-section
+// LDGARANGE-NOT: {{".*lld.*"}} {{.*}} "-generate-arange-section"
+// LLDGARANGE: {{".*lld.*"}} {{.*}} "-generate-arange-section"
 //
 // FDTS: "-mllvm" "-generate-type-units"
 // FDTSE: error: unsupported option '-fdebug-types-section' for target 'x86_64-apple-darwin'
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -506,6 +506,19 @@
 Suffix,
 Plugin);
 CmdArgs.push_back(Args.MakeArgString(Plugin));
+  } else {
+// NOTE:
+// - it is not possible to use lld for PS4
+// - addLTOOptions() is not used for PS5
+ 

[PATCH] D133092: [clang] fix generation of .debug_aranges with LTO

[Azat Khuzhin via Phabricator via cfe-commits]

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

@dblaikie Rebased. Brief of you comment had been added into the code, and the 
whole comment included into the commit message. Thanks for taking a look!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133092

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

[clang] fd24750 - Revert "C++/ObjC++: switch to gnu++17 as the default standard"

[Nikita Popov via cfe-commits]

Author: Nikita Popov
Date: 2022-09-08T09:45:50+02:00
New Revision: fd2475049e882e6c70a745cbe0799749ba184910

URL: 
https://github.com/llvm/llvm-project/commit/fd2475049e882e6c70a745cbe0799749ba184910
DIFF: 
https://github.com/llvm/llvm-project/commit/fd2475049e882e6c70a745cbe0799749ba184910.diff

LOG: Revert "C++/ObjC++: switch to gnu++17 as the default standard"

This reverts commit e321c8dd2cea8365045ed44ae1c3c00c6a977d2e.

This causes many failures in llvm-test-suite, for example:

/home/npopov/repos/llvm-test-suite/build-O3/tools/timeit --summary 
MultiSource/Applications/lambda-0.1.3/CMakeFiles/lambda.dir/token_stream.cc.o.time
 /home/npopov/repos/llvm-project/build/bin/clang++ -DNDEBUG 
-I/home/npopov/repos/llvm-test-suite/MultiSource/Applications/lambda-0.1.3 -O3  
 -w -Werror=date-time -MD -MT 
MultiSource/Applications/lambda-0.1.3/CMakeFiles/lambda.dir/token_stream.cc.o 
-MF 
MultiSource/Applications/lambda-0.1.3/CMakeFiles/lambda.dir/token_stream.cc.o.d 
-o 
MultiSource/Applications/lambda-0.1.3/CMakeFiles/lambda.dir/token_stream.cc.o 
-c 
/home/npopov/repos/llvm-test-suite/MultiSource/Applications/lambda-0.1.3/token_stream.cc

/home/npopov/repos/llvm-test-suite/MultiSource/Applications/lambda-0.1.3/token_stream.cc:192:2:
 error: ISO C++17 does not allow 'register' storage class specifier [-Wregister]
register char chr;
^

Added: 
clang/test/Preprocessor/lang-std.cu

Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/Basic/LangStandards.cpp
clang/test/lit.cfg.py
clang/test/lit.site.cfg.py.in

Removed: 
clang/test/Preprocessor/lang-std.cpp



diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 425135d746b99..b370d23856c21 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -200,10 +200,6 @@ C++ Language Changes in Clang
 
 - Implemented DR692, DR1395 and DR1432. Use the ``-fclang-abi-compat=15`` 
option
   to get the old partial ordering behavior regarding packs.
-- Clang's default C++/ObjC++ standard is now ``gnu++17`` instead of 
``gnu++14``.
-  This means Clang will by default accept code using features from C++17 and
-  conforming GNU extensions. Projects incompatible with C++17 can add
-  ``-std=gnu++14`` to their build settings to restore the previous behaviour.
 
 C++20 Feature Support
 ^

diff  --git a/clang/lib/Basic/LangStandards.cpp 
b/clang/lib/Basic/LangStandards.cpp
index 92e8ab347dda1..a21898dd3c627 100644
--- a/clang/lib/Basic/LangStandards.cpp
+++ b/clang/lib/Basic/LangStandards.cpp
@@ -75,9 +75,10 @@ LangStandard::Kind 
clang::getDefaultLanguageStandard(clang::Language Lang,
 if (CLANG_DEFAULT_STD_CXX != LangStandard::lang_unspecified)
   return CLANG_DEFAULT_STD_CXX;
 
-if (T.isPS())
+if (T.isDriverKit())
+  return LangStandard::lang_gnucxx17;
+else
   return LangStandard::lang_gnucxx14;
-return LangStandard::lang_gnucxx17;
   case Language::RenderScript:
 return LangStandard::lang_c99;
   case Language::HIP:

diff  --git a/clang/test/Preprocessor/lang-std.cpp 
b/clang/test/Preprocessor/lang-std.cpp
deleted file mode 100644
index 538f1b1976dad..0
--- a/clang/test/Preprocessor/lang-std.cpp
+++ /dev/null
@@ -1,14 +0,0 @@
-// UNSUPPORTED: default-std-cxx, ps4, ps5
-/// Test default standards when CLANG_DEFAULT_STD_CXX is unspecified.
-/// PS4/PS5 default to gnu++14.
-
-// RUN: %clang_cc1 -dM -E %s | FileCheck --check-prefix=CXX17 %s
-// RUN: %clang_cc1 -dM -E -x cuda %s | FileCheck --check-prefix=CXX14 %s
-// RUN: %clang_cc1 -dM -E -x hip %s | FileCheck --check-prefix=CXX14 %s
-
-// RUN: %clang_cc1 -dM -E -x cuda -std=c++14 %s | FileCheck 
--check-prefix=CXX14 %s
-// RUN: %clang_cc1 -dM -E -x hip -std=c++98 %s | FileCheck 
--check-prefix=CXX98 %s
-
-// CXX98: #define __cplusplus 199711L
-// CXX14: #define __cplusplus 201402L
-// CXX17: #define __cplusplus 201703L

diff  --git a/clang/test/Preprocessor/lang-std.cu 
b/clang/test/Preprocessor/lang-std.cu
new file mode 100644
index 0..4f35af01aaf5f
--- /dev/null
+++ b/clang/test/Preprocessor/lang-std.cu
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -dM -E -x hip %s | FileCheck -check-prefix=CXX14 %s
+// RUN: %clang_cc1 -dM -E %s | FileCheck -check-prefix=CXX14 %s
+// RUN: %clang_cc1 -dM -E -std=c++98 -x hip %s | FileCheck -check-prefix=CXX98 
%s
+// RUN: %clang_cc1 -dM -E -std=c++98 %s | FileCheck -check-prefix=CXX98 %s
+
+// CXX98: #define __cplusplus 199711L
+// CXX14: #define __cplusplus 201402L

diff  --git a/clang/test/lit.cfg.py b/clang/test/lit.cfg.py
index 7fa46e3d99fca..792216595d3fe 100644
--- a/clang/test/lit.cfg.py
+++ b/clang/test/lit.cfg.py
@@ -131,9 +131,6 @@ def have_host_jit_feature_support(feature_name):
 if config.clang_enable_opaque_pointers:
 config.available_features.add('enable-opaque-pointers')
 
-if config.clang_default_std_cxx != '':
-config.

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

I've reverted this change because it causes major llvm-test-suite breakage. You 
likely need to pin many tests to use `-std=c++14`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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

[clang] 8627179 - [clang][Interp] Only initialize initmaps for primitive arrays

[Timm Bäder via cfe-commits]

Author: Timm Bäder
Date: 2022-09-08T10:03:06+02:00
New Revision: 86271798e51a7866dd2af44e0ee183d1331089e6

URL: 
https://github.com/llvm/llvm-project/commit/86271798e51a7866dd2af44e0ee183d1331089e6
DIFF: 
https://github.com/llvm/llvm-project/commit/86271798e51a7866dd2af44e0ee183d1331089e6.diff

LOG: [clang][Interp] Only initialize initmaps for primitive arrays

As the comment states, this code should only run for primitive arrays.

This should fix the memory sanitize builds.

Added: 


Modified: 
clang/lib/AST/Interp/Pointer.cpp

Removed: 




diff  --git a/clang/lib/AST/Interp/Pointer.cpp 
b/clang/lib/AST/Interp/Pointer.cpp
index cb687377e97b..1dfb8f4b18eb 100644
--- a/clang/lib/AST/Interp/Pointer.cpp
+++ b/clang/lib/AST/Interp/Pointer.cpp
@@ -156,7 +156,7 @@ void Pointer::initialize() const {
   Descriptor *Desc = getFieldDesc();
 
   if (Desc->isArray()) {
-if (!Pointee->IsStatic) {
+if (Desc->isPrimitiveArray() && !Pointee->IsStatic) {
   // Primitive array initializer.
   InitMap *&Map = getInitMap();
   if (Map == (InitMap *)-1)



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

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D131465#3776515 , @nikic wrote:

> I've reverted this change because it causes major llvm-test-suite breakage. 
> You likely need to pin many tests to use `-std=c++14`.

https://github.com/llvm/llvm-test-suite/commit/b3a89445dc4aed7ee9825e024c32d417e36a3f13
 should fix llvm-test-suite.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[David Spickett via Phabricator via cfe-commits]

DavidSpickett added a comment.

If it helps here is a failed build from our bots:
https://lab.llvm.org/buildbot/#/builders/179/builds/4420

There are others but just combinations of the same tests.

Example error from the hexxagon build:

  
/home/tcwg-buildbot/worker/clang-armv8-lld-2stage/test/test-suite/MultiSource/Applications/hexxagon/hexxagonboard.cpp:254:10:
 error: reference to 'empty' is ambiguous
  return empty;
 ^
  
/home/tcwg-buildbot/worker/clang-armv8-lld-2stage/test/test-suite/MultiSource/Applications/hexxagon/hexxagonboard.h:42:2:
 note: candidate found by name lookup is 'empty'
  empty,
  ^


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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

[clang] 3e99b8d - C++/ObjC++: switch to gnu++17 as the default standard

[Fangrui Song via cfe-commits]

Author: Fangrui Song
Date: 2022-09-08T08:22:04Z
New Revision: 3e99b8d947ac024831e59be2b604ac67a24fed94

URL: 
https://github.com/llvm/llvm-project/commit/3e99b8d947ac024831e59be2b604ac67a24fed94
DIFF: 
https://github.com/llvm/llvm-project/commit/3e99b8d947ac024831e59be2b604ac67a24fed94.diff

LOG: C++/ObjC++: switch to gnu++17 as the default standard

Clang's default C++ standard is now `gnu++17` instead of `gnu++14`:
https://discourse.llvm.org/t/c-objc-switch-to-gnu-17-as-the-default-standard/64360

* CUDA/HIP are unchanged: C++14 from D103221.
* Sony PS4/PS5 are unchanged: 
https://discourse.llvm.org/t/c-objc-switch-to-gnu-17-as-the-default-standard/64360/6
* lit feature `default-std-cxx` is added to keep CLANG_DEFAULT_STD_CXX=xxx 
tests working.
  Whether the cmake variable should be retained is disccused in D133375.

Depends on D131464

Reviewed By: #clang-language-wg, aaron.ballman

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

Added: 
clang/test/Preprocessor/lang-std.cpp

Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/Basic/LangStandards.cpp
clang/test/lit.cfg.py
clang/test/lit.site.cfg.py.in

Removed: 
clang/test/Preprocessor/lang-std.cu



diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index b370d23856c21..425135d746b99 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -200,6 +200,10 @@ C++ Language Changes in Clang
 
 - Implemented DR692, DR1395 and DR1432. Use the ``-fclang-abi-compat=15`` 
option
   to get the old partial ordering behavior regarding packs.
+- Clang's default C++/ObjC++ standard is now ``gnu++17`` instead of 
``gnu++14``.
+  This means Clang will by default accept code using features from C++17 and
+  conforming GNU extensions. Projects incompatible with C++17 can add
+  ``-std=gnu++14`` to their build settings to restore the previous behaviour.
 
 C++20 Feature Support
 ^

diff  --git a/clang/lib/Basic/LangStandards.cpp 
b/clang/lib/Basic/LangStandards.cpp
index a21898dd3c627..92e8ab347dda1 100644
--- a/clang/lib/Basic/LangStandards.cpp
+++ b/clang/lib/Basic/LangStandards.cpp
@@ -75,10 +75,9 @@ LangStandard::Kind 
clang::getDefaultLanguageStandard(clang::Language Lang,
 if (CLANG_DEFAULT_STD_CXX != LangStandard::lang_unspecified)
   return CLANG_DEFAULT_STD_CXX;
 
-if (T.isDriverKit())
-  return LangStandard::lang_gnucxx17;
-else
+if (T.isPS())
   return LangStandard::lang_gnucxx14;
+return LangStandard::lang_gnucxx17;
   case Language::RenderScript:
 return LangStandard::lang_c99;
   case Language::HIP:

diff  --git a/clang/test/Preprocessor/lang-std.cpp 
b/clang/test/Preprocessor/lang-std.cpp
new file mode 100644
index 0..538f1b1976dad
--- /dev/null
+++ b/clang/test/Preprocessor/lang-std.cpp
@@ -0,0 +1,14 @@
+// UNSUPPORTED: default-std-cxx, ps4, ps5
+/// Test default standards when CLANG_DEFAULT_STD_CXX is unspecified.
+/// PS4/PS5 default to gnu++14.
+
+// RUN: %clang_cc1 -dM -E %s | FileCheck --check-prefix=CXX17 %s
+// RUN: %clang_cc1 -dM -E -x cuda %s | FileCheck --check-prefix=CXX14 %s
+// RUN: %clang_cc1 -dM -E -x hip %s | FileCheck --check-prefix=CXX14 %s
+
+// RUN: %clang_cc1 -dM -E -x cuda -std=c++14 %s | FileCheck 
--check-prefix=CXX14 %s
+// RUN: %clang_cc1 -dM -E -x hip -std=c++98 %s | FileCheck 
--check-prefix=CXX98 %s
+
+// CXX98: #define __cplusplus 199711L
+// CXX14: #define __cplusplus 201402L
+// CXX17: #define __cplusplus 201703L

diff  --git a/clang/test/Preprocessor/lang-std.cu 
b/clang/test/Preprocessor/lang-std.cu
deleted file mode 100644
index 4f35af01aaf5f..0
--- a/clang/test/Preprocessor/lang-std.cu
+++ /dev/null
@@ -1,7 +0,0 @@
-// RUN: %clang_cc1 -dM -E -x hip %s | FileCheck -check-prefix=CXX14 %s
-// RUN: %clang_cc1 -dM -E %s | FileCheck -check-prefix=CXX14 %s
-// RUN: %clang_cc1 -dM -E -std=c++98 -x hip %s | FileCheck -check-prefix=CXX98 
%s
-// RUN: %clang_cc1 -dM -E -std=c++98 %s | FileCheck -check-prefix=CXX98 %s
-
-// CXX98: #define __cplusplus 199711L
-// CXX14: #define __cplusplus 201402L

diff  --git a/clang/test/lit.cfg.py b/clang/test/lit.cfg.py
index 792216595d3fe..7fa46e3d99fca 100644
--- a/clang/test/lit.cfg.py
+++ b/clang/test/lit.cfg.py
@@ -131,6 +131,9 @@ def have_host_jit_feature_support(feature_name):
 if config.clang_enable_opaque_pointers:
 config.available_features.add('enable-opaque-pointers')
 
+if config.clang_default_std_cxx != '':
+config.available_features.add('default-std-cxx')
+
 # Set available features we allow tests to conditionalize on.
 #
 if config.clang_default_cxx_stdlib != '':

diff  --git a/clang/test/lit.site.cfg.py.in b/clang/test/lit.site.cfg.py.in
index 9c903b2d31cb8..8c62d61c57b40 100644
--- a/clang/test/lit.site.cfg.py.in
+++ b/clang/test/lit.site.cfg.py.in
@@ -24,6 +24,7 @@ config.have_zlib = @LLVM_ENABLE_ZLIB@
 config.clang_arcmt = @CLANG_ENABLE_AR

[clang] a0365ab - [Driver] Support -gz=zstd

[Fangrui Song via cfe-commits]

Author: Fangrui Song
Date: 2022-09-08T01:39:06-07:00
New Revision: a0365abad8113d7e60294c5e581c24ec06ba037e

URL: 
https://github.com/llvm/llvm-project/commit/a0365abad8113d7e60294c5e581c24ec06ba037e
DIFF: 
https://github.com/llvm/llvm-project/commit/a0365abad8113d7e60294c5e581c24ec06ba037e.diff

LOG: [Driver] Support -gz=zstd

The driver option translates to --compress-debug-sections=zstd cc1/cc1as/GNU
assembler/linker options.

`clang -g -gz=zstd -c a.c` generates ELFCOMPRESS_ZSTD compressed debug info
sections if compression decreases size.

Added: 
clang/test/Driver/compress-unavailable.s
clang/test/Driver/compress-zstd.c

Modified: 
clang/include/clang/Basic/DiagnosticDriverKinds.td
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/lib/Driver/ToolChains/Gnu.cpp
clang/test/CMakeLists.txt
clang/test/Misc/cc1as-compress.s
clang/test/lit.site.cfg.py.in

Removed: 
clang/test/Driver/nozlibcompress.c



diff  --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td 
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index df85139c3ca22..1717a2ef71f1e 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -406,7 +406,7 @@ def warn_missing_sysroot : Warning<"no such sysroot 
directory: '%0'">,
   InGroup>;
 def warn_incompatible_sysroot : Warning<"using sysroot for '%0' but targeting 
'%1'">,
   InGroup>;
-def warn_debug_compression_unavailable : Warning<"cannot compress debug 
sections (zlib not enabled)">,
+def warn_debug_compression_unavailable : Warning<"cannot compress debug 
sections (%0 not enabled)">,
   InGroup>;
 def warn_drv_disabling_vptr_no_rtti_default : Warning<
   "implicitly disabling vptr sanitizer because rtti wasn't enabled">,

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index cfc0994d69d4e..4c95e3c4cae38 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5273,8 +5273,8 @@ def record_command_line : Separate<["-"], 
"record-command-line">,
   HelpText<"The string to embed in the .LLVM.command.line section.">,
   MarshallingInfoString>;
 def compress_debug_sections_EQ : Joined<["-", "--"], 
"compress-debug-sections=">,
-HelpText<"DWARF debug sections compression type">, Values<"none,zlib">,
-NormalizedValuesScope<"llvm::DebugCompressionType">, 
NormalizedValues<["None", "Z"]>,
+HelpText<"DWARF debug sections compression type">, 
Values<"none,zlib,zstd">,
+NormalizedValuesScope<"llvm::DebugCompressionType">, 
NormalizedValues<["None", "Z", "Zstd"]>,
 MarshallingInfoEnum, "None">;
 def compress_debug_sections : Flag<["-", "--"], "compress-debug-sections">,
   Alias, AliasArgs<["zlib"]>;

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 837486971d112..45a71be97acd0 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -1146,7 +1146,14 @@ static void RenderDebugInfoCompressionArgs(const ArgList 
&Args,
 CmdArgs.push_back(
 Args.MakeArgString("--compress-debug-sections=" + Twine(Value)));
   } else {
-D.Diag(diag::warn_debug_compression_unavailable);
+D.Diag(diag::warn_debug_compression_unavailable) << "zlib";
+  }
+} else if (Value == "zstd") {
+  if (llvm::compression::zstd::isAvailable()) {
+CmdArgs.push_back(
+Args.MakeArgString("--compress-debug-sections=" + Twine(Value)));
+  } else {
+D.Diag(diag::warn_debug_compression_unavailable) << "zstd";
   }
 } else {
   D.Diag(diag::err_drv_unsupported_option_argument)

diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index 4760a6f528627..22025d95e7c8f 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -285,7 +285,7 @@ void tools::addLinkerCompressDebugSectionsOption(
   // argument.
   if (const Arg *A = Args.getLastArg(options::OPT_gz_EQ)) {
 StringRef V = A->getValue();
-if (V == "none" || V == "zlib")
+if (V == "none" || V == "zlib" || V == "zstd")
   CmdArgs.push_back(Args.MakeArgString("--compress-debug-sections=" + V));
 else
   TC.getDriver().Diag(diag::err_drv_unsupported_option_argument)

diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 047ec67f95e12..e153f86334aae 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -730,7 +730,7 @@ void tools::gnutools::Assembler::ConstructJob(Compilation 
&C,
   CmdArgs.push_back("--compress-debug-sections");
 } else {
   StringRef Value = A->getValue();
-  if (Value == "none" || Value == "zlib") {
+ 

[PATCH] D132962: [clangd][ObjC] Improve completions for protocols + category names

[Kadir Cetinkaya via Phabricator via cfe-commits]

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

thanks!




Comment at: clang-tools-extra/clangd/CodeComplete.cpp:1731
 SymbolSlab::Builder ResultsBuilder;
-if (Opts.Index->fuzzyFind(Req, [&](const Symbol &Sym) {
-  if (includeSymbolFromIndex(Sym))
-ResultsBuilder.insert(Sym);
-}))
+if (Opts.Index->fuzzyFind(
+Req, [&](const Symbol &Sym) { ResultsBuilder.insert(Sym); }))

nit: while here can you change this to read as:
`Incomplete ||= Opts.Index->fuzzyFind(...);`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132962

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

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

In D131465#3776537 , @MaskRay wrote:

> In D131465#3776515 , @nikic wrote:
>
>> I've reverted this change because it causes major llvm-test-suite breakage. 
>> You likely need to pin many tests to use `-std=c++14`.
>
> https://github.com/llvm/llvm-test-suite/commit/b3a89445dc4aed7ee9825e024c32d417e36a3f13
>  should fix llvm-test-suite.

Thanks!

It looks like the switch to `-std=c++17` has some major compile-time impact: 
http://llvm-compile-time-tracker.com/compare.php?from=047c7aa96dadf8a2c71a29e2df610d628d9e7e3e&to=3e99b8d947ac024831e59be2b604ac67a24fed94&stat=instructions
 The `O0` build of 7zip becomes 80% slower (without codegen changes).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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

[PATCH] D133479: [clangd] Set Incompleteness for spec fuzzyfind requests

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet created this revision.
kadircet added reviewers: sammccall, dgoldman.
Herald added a subscriber: arphaman.
Herald added a project: All.
kadircet requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133479

Files:
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/CodeComplete.h
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -2589,7 +2589,8 @@
   Opts.Index = &Requests;
 
   auto CompleteAtPoint = [&](StringRef P) {
-cantFail(runCodeComplete(Server, File, Test.point(P), Opts));
+auto CCR = cantFail(runCodeComplete(Server, File, Test.point(P), Opts));
+EXPECT_TRUE(CCR.HasMore);
   };
 
   CompleteAtPoint("1");
Index: clang-tools-extra/clangd/CodeComplete.h
===
--- clang-tools-extra/clangd/CodeComplete.h
+++ clang-tools-extra/clangd/CodeComplete.h
@@ -31,6 +31,7 @@
 #include "llvm/ADT/StringRef.h"
 #include 
 #include 
+#include 
 
 namespace clang {
 class NamedDecl;
@@ -262,7 +263,7 @@
   llvm::Optional NewReq;
   /// The result is consumed by `codeComplete()` if speculation succeeded.
   /// NOTE: the destructor will wait for the async call to finish.
-  std::future Result;
+  std::future> Result;
 };
 
 /// Gets code completions at a specified \p Pos in \p FileName.
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -70,6 +70,7 @@
 #include 
 #include 
 #include 
+#include 
 
 // We log detailed candidate here if you run with -debug-only=codecomplete.
 #define DEBUG_TYPE "CodeComplete"
@@ -1343,13 +1344,14 @@
   llvm_unreachable("invalid NestedNameSpecifier kind");
 }
 
-std::future startAsyncFuzzyFind(const SymbolIndex &Index,
-const FuzzyFindRequest &Req) {
-  return runAsync([&Index, Req]() {
+std::future>
+startAsyncFuzzyFind(const SymbolIndex &Index, const FuzzyFindRequest &Req) {
+  return runAsync>([&Index, Req]() {
 trace::Span Tracer("Async fuzzyFind");
 SymbolSlab::Builder Syms;
-Index.fuzzyFind(Req, [&Syms](const Symbol &Sym) { Syms.insert(Sym); });
-return std::move(Syms).build();
+bool Incomplete =
+Index.fuzzyFind(Req, [&Syms](const Symbol &Sym) { Syms.insert(Sym); });
+return std::make_pair(Incomplete, std::move(Syms).build());
   });
 }
 
@@ -1678,7 +1680,7 @@
   bool includeSymbolFromIndex(const Symbol &Sym) {
 if (CCContextKind == CodeCompletionContext::CCC_ObjCProtocolName) {
   return Sym.SymInfo.Lang == index::SymbolLanguage::ObjC &&
-  Sym.SymInfo.Kind == index::SymbolKind::Protocol;
+ Sym.SymInfo.Kind == index::SymbolKind::Protocol;
 }
 return true;
   }
@@ -1709,7 +1711,9 @@
   SPAN_ATTACH(Tracer, "Speculative results", true);
 
   trace::Span WaitSpec("Wait speculative results");
-  return SpecFuzzyFind->Result.get();
+  auto SpecRes = SpecFuzzyFind->Result.get();
+  Incomplete |= SpecRes.first;
+  return std::move(SpecRes.second);
 }
 
 SPAN_ATTACH(Tracer, "Speculative results", false);


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -2589,7 +2589,8 @@
   Opts.Index = &Requests;
 
   auto CompleteAtPoint = [&](StringRef P) {
-cantFail(runCodeComplete(Server, File, Test.point(P), Opts));
+auto CCR = cantFail(runCodeComplete(Server, File, Test.point(P), Opts));
+EXPECT_TRUE(CCR.HasMore);
   };
 
   CompleteAtPoint("1");
Index: clang-tools-extra/clangd/CodeComplete.h
===
--- clang-tools-extra/clangd/CodeComplete.h
+++ clang-tools-extra/clangd/CodeComplete.h
@@ -31,6 +31,7 @@
 #include "llvm/ADT/StringRef.h"
 #include 
 #include 
+#include 
 
 namespace clang {
 class NamedDecl;
@@ -262,7 +263,7 @@
   llvm::Optional NewReq;
   /// The result is consumed by `codeComplete()` if speculation succeeded.
   /// NOTE: the destructor will wait for the async call to finish.
-  std::future Result;
+  std::future> Result;
 };
 
 /// Gets code completions at a specified \p Pos in \p FileName.
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.c

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

[Richard Sandiford via Phabricator via cfe-commits]

rsandifo-arm added a comment.

I can see at least three ways of handling this:

1. @paulwalker-arm's suggestion to allow `-march=` without a base architecture 
(or with a dummy base architecture that means “no change”)
2. a single new option `-mfoo=` that applies on top of `-march` and can be used 
to add or remove architecture features
3. individual `-m` and `-mno-` options for each ISA feature.

I think all three achieve the same objective.

I assume for (1) that `-march=` options would apply in-order, so that an 
`-march=` without a base architecture would apply on top of any previous 
`-march=`, whereas an `-march=` with a base architecture would override all 
previous `-march=` options (both old-style and new-style).  This behaviour 
might be an advantage in some situations and a disadvantage in others.  Build 
systems would need to be careful about where in the command line the extra 
features go (but most probably are).

For (2) we could say that all `-mfoo=` options apply (cumulatively, in order) 
to the final `-march` option, even if the `-march` option comes later than some 
of the `-mfoo=` options.  This too could be an advantage in some situations and 
a disadvantage in others (as a reversal of the situation for (1)).

The architecture can already be set by two options rather than one: `-march=` 
and `-mcpu=`.  Currently (at least in GCC), `-march=` trumps the architecture 
effects of `-mcpu=`, even if `-mcpu=` is specified after `-march=`.  I suppose 
the difficulty for (1) is then deciding what should happen if an `-march=` 
without a base architecture is specified alongside an `-mcpu=`.  Does the 
`-march=` option apply to the `-mcpu=` choice of architecture even if the 
`-mcpu=` appears later?  If so, `-march=` options without a base architecture 
would sometimes have a cumulative effect with later (`-mcpu=`) options as well 
as earlier (`-march=` or `-mcpu=`) ones.  This might be non-intuitive and would 
be another way in which `-mcpu=` is not exactly equivalent to the associated 
`-march=` and `-mtune=` options.

So perhaps one advantage of (2) over (1) is that the semantics are easier to 
describe.  `-mfoo=` options apply cumulatively to the command line's final 
choice of base architecture, however that choice is specified.

Personally I'm not very keen on (3).  Reasons:

- (1) and (2) collect the (subtle) semantics about option precedence in a 
single place.  (3) distributes it among many individual options.
- There are a lot of supported ISA features, so there would be a lot of `-m` 
and `-mno-` options to document.  It would become harder to separate out `-m` 
options related to architecture selection from `-m` options that do other 
things.
- With (3) it becomes much harder to check that every supported feature has an 
associated option.  With (1) and (2) this would be guaranteed by construction.
- The `+feature` and `+nofeature` style is also used in things like `#pragma 
GCC target`, which is another mechanism for changing ISA features without 
changing the base architecture.  It feels like the new options are equivalent 
to sticking such pragmas at the start of the translation unit, so it would be 
good for them to use a consistent style.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113779

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

[PATCH] D132003: [clang][ARM][NFC] Clean up signed conversion and undefined macros in builtin header

[Tomas Matheson via Phabricator via cfe-commits]

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

LGTM, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132003

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

[PATCH] D133109: [LLVM][ARM] Remove options for armv2, 2A, 3 and 3M

[David Spickett via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGe428baf0019e: [LLVM][ARM] Remove options for armv2, 2A, 3 
and 3M (authored by DavidSpickett).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133109

Files:
  clang/docs/ReleaseNotes.rst
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm/Support/ARMTargetParser.def
  llvm/lib/Support/ARMTargetParser.cpp
  llvm/lib/Target/ARM/ARM.td
  llvm/lib/Target/ARM/ARMSubtarget.h
  llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
  llvm/test/MC/ARM/directive-arch-armv2.s
  llvm/test/MC/ARM/directive-arch-armv2a.s
  llvm/test/MC/ARM/directive-arch-armv3.s
  llvm/test/MC/ARM/directive-arch-armv3m.s
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -20,21 +20,20 @@
 
 namespace {
 const char *ARMArch[] = {
-"armv2",   "armv2a", "armv3",   "armv3m","armv4",
-"armv4t",  "armv5",  "armv5t",  "armv5e","armv5te",
-"armv5tej","armv6",  "armv6j",  "armv6k","armv6hl",
-"armv6t2", "armv6kz","armv6z",  "armv6zk",   "armv6-m",
-"armv6m",  "armv6sm","armv6s-m","armv7-a",   "armv7",
-"armv7a",  "armv7ve","armv7hl", "armv7l","armv7-r",
-"armv7r",  "armv7-m","armv7m",  "armv7k","armv7s",
-"armv7e-m","armv7em","armv8-a", "armv8", "armv8a",
-"armv8l",  "armv8.1-a",  "armv8.1a","armv8.2-a", "armv8.2a",
-"armv8.3-a",   "armv8.3a",   "armv8.4-a",   "armv8.4a",  "armv8.5-a",
-"armv8.5a","armv8.6-a",  "armv8.6a","armv8.7-a", "armv8.7a",
-"armv8.8-a",   "armv8.8a",   "armv8-r", "armv8r","armv8-m.base",
-"armv8m.base", "armv8-m.main",   "armv8m.main", "iwmmxt","iwmmxt2",
-"xscale",  "armv8.1-m.main", "armv9-a", "armv9", "armv9a",
-"armv9.1-a",   "armv9.1a",   "armv9.2-a",   "armv9.2a",
+"armv4","armv4t",  "armv5",  "armv5t",  "armv5e",
+"armv5te",  "armv5tej","armv6",  "armv6j",  "armv6k",
+"armv6hl",  "armv6t2", "armv6kz","armv6z",  "armv6zk",
+"armv6-m",  "armv6m",  "armv6sm","armv6s-m","armv7-a",
+"armv7","armv7a",  "armv7ve","armv7hl", "armv7l",
+"armv7-r",  "armv7r",  "armv7-m","armv7m",  "armv7k",
+"armv7s",   "armv7e-m","armv7em","armv8-a", "armv8",
+"armv8a",   "armv8l",  "armv8.1-a",  "armv8.1a","armv8.2-a",
+"armv8.2a", "armv8.3-a",   "armv8.3a",   "armv8.4-a",   "armv8.4a",
+"armv8.5-a","armv8.5a","armv8.6-a",  "armv8.6a","armv8.7-a",
+"armv8.7a", "armv8.8-a",   "armv8.8a",   "armv8-r", "armv8r",
+"armv8-m.base", "armv8m.base", "armv8-m.main",   "armv8m.main", "iwmmxt",
+"iwmmxt2",  "xscale",  "armv8.1-m.main", "armv9-a", "armv9",
+"armv9a",   "armv9.1-a",   "armv9.1a",   "armv9.2-a",   "armv9.2a",
 };
 
 template 
@@ -438,14 +437,6 @@
 }
 
 TEST(TargetParserTest, testARMArch) {
-  EXPECT_TRUE(
-  testARMArch("armv2", "generic", "v2", ARMBuildAttrs::CPUArch::Pre_v4));
-  EXPECT_TRUE(
-  testARMArch("armv2a", "generic", "v2a", ARMBuildAttrs::CPUArch::Pre_v4));
-  EXPECT_TRUE(
-  testARMArch("armv3", "generic", "v3", ARMBuildAttrs::CPUArch::Pre_v4));
-  EXPECT_TRUE(
-  testARMArch("armv3m", "generic", "v3m", ARMBuildAttrs::CPUArch::Pre_v4));
   EXPECT_TRUE(
   testARMArch("armv4", "strongarm", "v4",
   ARMBuildAttrs::CPUArch::v4));
@@ -603,10 +594,6 @@
   EXPECT_FALSE(testARMExtension("xscale", ARM::ArchKind::INVALID, "crc"));
   EXPECT_FALSE(testARMExtension("swift", ARM::ArchKind::INVALID, "crc"));
 
-  EXPECT_FALSE(testARMExtension("generic", ARM::ArchKind::ARMV2, "thumb"));
-  EXPECT_FALSE(testARMExtension("generic", ARM::ArchKind::ARMV2A, "thumb"));
-  EXPECT_FALSE(testARMExtension("generic", ARM::ArchKind::ARMV3, "thumb"));
-  EXPECT_FALSE(testARMExtension("generic", ARM::ArchKind::ARMV3M, "thumb"));
   EXPECT_FALSE(testARMExtension("generic", ARM::ArchKind::ARMV4, "dsp"));
   EXPECT_FALSE(testARMExtension("generic", ARM::ArchKind::ARMV4T, "dsp"));
   EXPECT_FALSE(testARMExtension("generic", ARM::ArchKind::ARMV5T, "simd"));
Index: llvm/test/MC/ARM/directive-arch-armv3m.s
===
--- llvm/test/MC/ARM/directive-arch-armv3m.s
+++ /dev/null
@@ -1,30 +0,0 @@
-@ Test the .arch directive for armv3m
-
-@ This test case will check the default .ARM.attributes value for the
-@ armv3m architecture.
-
-@ RUN: llvm-m

[clang] e428baf - [LLVM][ARM] Remove options for armv2, 2A, 3 and 3M

[David Spickett via cfe-commits]

Author: David Spickett
Date: 2022-09-08T09:49:48Z
New Revision: e428baf0019e5292d943a8e37bf08f1192a1870c

URL: 
https://github.com/llvm/llvm-project/commit/e428baf0019e5292d943a8e37bf08f1192a1870c
DIFF: 
https://github.com/llvm/llvm-project/commit/e428baf0019e5292d943a8e37bf08f1192a1870c.diff

LOG: [LLVM][ARM] Remove options for armv2, 2A, 3 and 3M

Fixes #57486

These pre v4 architectures are not specifically supported
by codegen. As demonstrated in the linked issue.

GCC has not supported 3M since GCC 9 and presumably
2 and 2A earlier than that. So we are aligned in that sense.

(see 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2abd6e34fcf3bd9f9ffafcaa47cdc3ed443f9add)

This removes the options and associated testing.

The Pre_v4 build attribute remains mainly because its absence
would be more confusing. It will not be used other than to
complete the list of build attributes as shown in the ABI.

https://github.com/ARM-software/abi-aa/blob/main/addenda32/addenda32.rst#3352the-target-related-attributes

Reviewed By: nickdesaulniers, peter.smith, rengolin

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
llvm/docs/ReleaseNotes.rst
llvm/include/llvm/Support/ARMTargetParser.def
llvm/lib/Support/ARMTargetParser.cpp
llvm/lib/Target/ARM/ARM.td
llvm/lib/Target/ARM/ARMSubtarget.h
llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
llvm/unittests/Support/TargetParserTest.cpp

Removed: 
llvm/test/MC/ARM/directive-arch-armv2.s
llvm/test/MC/ARM/directive-arch-armv2a.s
llvm/test/MC/ARM/directive-arch-armv3.s
llvm/test/MC/ARM/directive-arch-armv3m.s



diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 425135d746b99..5bd812aca97f4 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -284,6 +284,10 @@ DWARF Support in Clang
 Arm and AArch64 Support in Clang
 
 
+- `-march` values for targeting armv2, armv2A, armv3 and armv3M have been 
removed.
+  Their presence gave the impression that Clang can correctly generate code for
+  them, which it cannot.
+
 Floating Point Support in Clang
 ---
 

diff  --git a/llvm/docs/ReleaseNotes.rst b/llvm/docs/ReleaseNotes.rst
index 7660f3059c531..b5592aae0af5f 100644
--- a/llvm/docs/ReleaseNotes.rst
+++ b/llvm/docs/ReleaseNotes.rst
@@ -82,6 +82,10 @@ Changes to the AMDGPU Backend
 Changes to the ARM Backend
 --
 
+* Support for targeting armv2, armv2A, armv3 and armv3M has been removed.
+  LLVM did not, and was not ever likely to generate correct code for those
+  architecture versions so their presence was misleading.
+
 Changes to the AVR Backend
 --
 

diff  --git a/llvm/include/llvm/Support/ARMTargetParser.def 
b/llvm/include/llvm/Support/ARMTargetParser.def
index 645c3b8963f54..ad498047b0885 100644
--- a/llvm/include/llvm/Support/ARMTargetParser.def
+++ b/llvm/include/llvm/Support/ARMTargetParser.def
@@ -47,14 +47,6 @@ ARM_FPU("softvfp", FK_SOFTVFP, FPUVersion::NONE, 
NeonSupportLevel::None, FPURest
 #endif
 ARM_ARCH("invalid", INVALID, "", "",
   ARMBuildAttrs::CPUArch::Pre_v4, FK_NONE, ARM::AEK_NONE)
-ARM_ARCH("armv2", ARMV2, "2", "v2", ARMBuildAttrs::CPUArch::Pre_v4,
-  FK_NONE, ARM::AEK_NONE)
-ARM_ARCH("armv2a", ARMV2A, "2A", "v2a", ARMBuildAttrs::CPUArch::Pre_v4,
-  FK_NONE, ARM::AEK_NONE)
-ARM_ARCH("armv3", ARMV3, "3", "v3", ARMBuildAttrs::CPUArch::Pre_v4,
-  FK_NONE, ARM::AEK_NONE)
-ARM_ARCH("armv3m", ARMV3M, "3M", "v3m", ARMBuildAttrs::CPUArch::Pre_v4,
-  FK_NONE, ARM::AEK_NONE)
 ARM_ARCH("armv4", ARMV4, "4", "v4", ARMBuildAttrs::CPUArch::v4,
   FK_NONE, ARM::AEK_NONE)
 ARM_ARCH("armv4t", ARMV4T, "4T", "v4t", ARMBuildAttrs::CPUArch::v4T,

diff  --git a/llvm/lib/Support/ARMTargetParser.cpp 
b/llvm/lib/Support/ARMTargetParser.cpp
index d7294b5b10744..e4c6bcb028acb 100644
--- a/llvm/lib/Support/ARMTargetParser.cpp
+++ b/llvm/lib/Support/ARMTargetParser.cpp
@@ -39,12 +39,6 @@ ARM::ArchKind ARM::parseArch(StringRef Arch) {
 unsigned ARM::parseArchVersion(StringRef Arch) {
   Arch = getCanonicalArchName(Arch);
   switch (parseArch(Arch)) {
-  case ArchKind::ARMV2:
-  case ArchKind::ARMV2A:
-return 2;
-  case ArchKind::ARMV3:
-  case ArchKind::ARMV3M:
-return 3;
   case ArchKind::ARMV4:
   case ArchKind::ARMV4T:
 return 4;
@@ -125,10 +119,6 @@ ARM::ProfileKind ARM::parseArchProfile(StringRef Arch) {
   case ArchKind::ARMV9_2A:
   case ArchKind::ARMV9_3A:
 return ProfileKind::A;
-  case ArchKind::ARMV2:
-  case ArchKind::ARMV2A:
-  case ArchKind::ARMV3:
-  case ArchKind::ARMV3M:
   case ArchKind::ARMV4:
   case ArchKind::ARMV4T:
   case ArchKind::ARMV5T:

diff  --git a/llvm/lib/Target/ARM/ARM.td b/llvm/lib/Target/ARM/ARM.td
index 4da91e1166c

[PATCH] D130265: [clangd] resolve forwarded parameters in Hover

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

This looks like a nice idea, but i think we definitely need annotations to 
prevent confusion. I'd prefer something like:
assume `foo(int x, Args... args);`

  function foo
  -> void
  Parameters:
  - int x
  - int a : forwarded to [bar:a](it'd be great if we could have location links 
here)
  - int b : forwarded to [bar:b](again location links)

There's https://github.com/microsoft/language-server-protocol/issues/379 for 
asking to support links in hover, maybe we just need a way to point at a range 
inside a file


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130265

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

[PATCH] D133440: [clangd] Allow programmatically disabling rename of virtual method hierarchies.

[Kadir Cetinkaya via Phabricator via cfe-commits]

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

thanks, lgtm!




Comment at: clang-tools-extra/clangd/refactor/Rename.cpp:217
 return ReasonToReject::NonIndexable;
+  if (!Opts.RenameVirtual) {
+if (const auto *S = llvm::dyn_cast(&RenameDecl)) {

nit: maybe do the check near the top, where the rest of the unsupportedsymbols 
are checked (+ it gives us a early bail out and skip a bunch of file/location 
conversions).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133440

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

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

[David Spickett via Phabricator via cfe-commits]

DavidSpickett added a comment.

For (1) and (2) is there a need to be able to reset the architecture setting no 
matter the previous `march` and `` are?

Currently we're talking about *not* wanting having to use `-march=armv8-a+crc` 
but would you still want a way to reset the architecture no matter what the 
previous options are?

That said, applying the extra extensions to the last `-march` gives you a way 
to bump the base architecture which could be useful. `-march=armv8-a 
-add-extension=+crc -march=armv8.4-a` => armv8.4-a+crc.

For (3) I agree with your concern.

> There are a lot of supported ISA features, so there would be a lot of -m and 
> -mno- options to document. It would become harder to separate out -m options 
> related to architecture selection from -m options that do other things.

A rough count:

  $ clang --help | grep " \-m" | wc -l
  108

I also wouldn't want to get into a situation where we name an extension such 
that `-mextension` looks more like it's a general compiler option. E.g.

  -mnvj   Enable generation of new-value jumps

"nvj" isn't far off what our extensions end up being called.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113779

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

[PATCH] D133405: [Linux] Hack around Linux/sparc

[Rainer Orth via Phabricator via cfe-commits]

ro added a comment.

In D133405#3776096 , @MaskRay wrote:

> It's not a compiler's job to define this workaround...

Yes and no: GCC successfully does it via its `fixincludes` mechanism.  
Unfortunately, LLVM doesn't provide something similar and doesn't even known 
about the GCC `include-fixed` directory, which could be used as a fallback.  
Sometimes OS headers **are** broken and remain so for a long time.  While one 
can throw hands up in disgust, this doesn't make the problem go away.  If I own 
the machine, I can patch/hack system headers as need be, but that's not an 
option on shared systems where I have to live with what's installed.

> If a platform want to provide a built-in macro, you can use 
> https://clang.llvm.org/docs/UsersManual.html#configuration-files and add 
> `-D__NO_INLINE__` there.
> To avoid magic behaviors, `${triple}-clang` loads `${triple}.cfg` while 
> `clang` doesn't (see 
> https://discourse.llvm.org/t/configuration-files/42529/24)

That's nice in some controlled circumstances where I can control e.g. the 
`clang` command used, but doesn't help in others like a release build with 
`test-release.sh` where I don't have that control.  I fully understand Jörg's 
argument in that thread that implicit changes from some hidden config 
file/environment variable are a maintenance nightmare and to be avoided at all 
cost.

> See also 
> https://discourse.llvm.org/t/rfc-adding-a-default-file-location-to-config-file-support/63606
>  (I am somewhat concerned with `clang` loading a config).
> But if you make `clang` a shell script that executes 
> `sparc64-pc-linux-gnu-clang` or the like, I think it should be fine.

Again, that would be ok for an installed `clang`, but while doing a release 
build, such a script wouldn't be used at all.

On top of all that, defining `__NO_INLINE__` globally to hack around a header 
bug is way too large a hammer: it has more effects than it should, which is why 
I called it a hack to allow making some progess at all, nothing to be included 
upstream.  I merely wanted to document what I'd changed in the Linux/sparc64 
release builds rather than only vaguely referring to my hack.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133405

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

[PATCH] D127284: [clang-repl] Support statements on global scope in incremental mode.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D127284#3776036 , @rsmith wrote:

> In terms of the high-level direction here, I think it would make sense to 
> approach this by adding a full-fledged language extension to Clang to allow 
> statements at the top level (with a `-f` flag to enable it), and then enable 
> that extension in the interpreter. The major change that shift in viewpoint 
> provides is that we should have explicit modeling of these top-level 
> statements in the AST, rather than having them only transiently exist until 
> they get passed off to the AST consumer. I think I'd want to see something 
> like `TopLevelStmtDecl` added to explicitly model the case where we parse a 
> statement at the top level. You can then extend the various parts of Clang 
> that deal with global variable initializers to also handle 
> `TopLevelStmtDecl`s.

Thank you for the suggestion! I actually have a different view on this that I 
was thinking about last night, but it's somewhat similar to yours in that it 
involves a flag to opt into behavior.

I don't think we should add a feature flag for this to Clang or support this 
functionality in Clang's AST -- it does not meet our language extension 
requirements (this won't be proposed to any standards body, etc). Further, I 
don't think Clang maintainers should have to play cognitive whack-a-mole as new 
statements and features are added to C and C++, wondering how they should 
behave if at the top level. Instead, I think it would make sense to add a flag 
to clang-repl so the user can decide whether they want their REPL experience to 
be "whole TU" or "pretend we're wrapped in a function". For users who want 
their experience to be both at the same time: that's an interesting idea, but 
it is not a C or C++ REPL experience; I think those users can go with the 
"whole TU" approach and write an extra line of code + some braces, as needed.

The reason I'm so uncomfortable with putting this into Clang is because neither 
language is designed to expect this sort of behavior and the resulting code 
will misbehave in mysterious ways when we guess wrong and it will be very 
difficult to address them all. I expect some things to be easy to recognize 
(see the `template` keyword and you know you can't be within a function scope), 
other things will require a bit of token lookahead (`unsigned long long 
_Thread_local i = 12;` cannot appear at local scope), and still others will 
require looking ahead through a potentially arbitrary number of statements 
(like with a VLA). I think the user should know explicitly which context 
they're in given that it matters to the source languages (and this is before we 
start to think about REPL over something like ObjC/OpenCL/HLSL/etc which may 
have even more interesting situations to worry about).


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

https://reviews.llvm.org/D127284

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

[PATCH] D124244: [analyzer] add StoreToImmutable and ModelConstQualifiedReturn checkers

[Zurab Tsinadze via Phabricator via cfe-commits]

zukatsinadze added a comment.

@NoQ gentle ping.


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

https://reviews.llvm.org/D124244

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

[PATCH] D131465: C++/ObjC++: switch to gnu++17 as the default standard

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

In D131465#3776599 , @nikic wrote:

> It looks like the switch to `-std=c++17` has some major compile-time impact: 
> http://llvm-compile-time-tracker.com/compare.php?from=047c7aa96dadf8a2c71a29e2df610d628d9e7e3e&to=3e99b8d947ac024831e59be2b604ac67a24fed94&stat=instructions
>  The `O0` build of 7zip becomes 80% slower (without codegen changes).

I suspect this is due to increased STL size in in C++17. Taking one sample 
file, preprocessed source is 289149 bytes with `-std=gnu++14` and 654888 with 
`-std=gnu++17`. The source size increased by more than a factor of two, so it's 
not very surprising that the parsing time also increased by the same factor.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131465

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

[PATCH] D133202: [Clang] Avoid __builtin_assume_aligned crash when the 1st arg is array type

[Lin Yurong via Phabricator via cfe-commits]

yronglin added a comment.

Thanks a lot for your comments @rsmith @rjmccall .

Firstly, as far as I know, turning on the `-fsanitizer=alignment` options when 
calling `__builtin_assume_aligned` in C code, Clang will emit `call void 
@__ubsan_handle_alignment_assumption(...)` in CodeGen,  and CodeGen need 
`user-written-type` to generate correct `TypeDescriptor` (this class in 
compiler-rt/UBSan).

Secondly, before this patch, 
`clang::CodeGen::CodeGenFunction::emitAlignmentAssumption` use 
`CastExpr->getSubExprAsWritten` to get `user-written-type` in CodeGen,  In 
`Diff 457643` , with John's comments, we use custom sema checking. we  just use 
`DefaultFunctionArrayLvalueConversion` to convert 1st arg, but not implicit 
cast 1st arg to `const void *`(We expect pass `user-written-type` to CodeGen).

Unfortunately,  `Diff 457643` broken windows sanitize test, because there have 
a forward declaration `__MACHINE(void * __cdecl __builtin_assume_aligned(const 
void *, size_t, ...) noexcept)`in `intrin0.inl.h`, I think the reason for this 
problem is we use `nct` in `BUILTIN(__builtin_assume_aligned, "v*vC*z.", 
"nct")`, I try to find a solution based on `Diff 457643`, what do you all think 
about?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133202

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

[PATCH] D133092: [clang] fix generation of .debug_aranges with LTO

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

I'm happy if @dblaikie is happy.




Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:515
+//
+// And as @dblaikie noted, this solution is far from perfert, better to
+// encode it into IR metadata, but this may not worth it, since looks like

We don't usually cite people by name in code comments.  Credit for the thought 
is clear in the review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133092

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

[PATCH] D132131: [clang-format] Adds a formatter for aligning trailing comments over empty lines

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

an example of the exact reason why we should not reuse the same struct...   
https://github.com/llvm/llvm-project/issues/57464


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132131

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

[PATCH] D133092: [clang] fix generation of .debug_aranges with LTO

[Azat Khuzhin via Phabricator via cfe-commits]

azat updated this revision to Diff 458717.
azat added a comment.

Update comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133092

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/Driver/debug-options.c


Index: clang/test/Driver/debug-options.c
===
--- clang/test/Driver/debug-options.c
+++ clang/test/Driver/debug-options.c
@@ -246,7 +246,11 @@
 // RUN: %clang -### -c -glldb %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 // RUN: %clang -### -c -glldb -gno-pubnames %s 2>&1 | FileCheck 
-check-prefix=NOPUB %s
 //
-// RUN: %clang -### -c -gdwarf-aranges %s 2>&1 | FileCheck 
-check-prefix=GARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -c -gdwarf-aranges %s 2>&1 | 
FileCheck -check-prefix=GARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -flto -gdwarf-aranges %s 2>&1 
| FileCheck -check-prefix=LDGARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -flto=thin -gdwarf-aranges %s 
2>&1 | FileCheck -check-prefix=LDGARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -fuse-ld=lld -flto 
-gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=LLDGARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -fuse-ld=lld -flto=thin 
-gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=LLDGARANGE %s
 //
 // RUN: %clang -### -fdebug-types-section -target x86_64-unknown-linux %s 2>&1 
\
 // RUN:| FileCheck -check-prefix=FDTS %s
@@ -371,6 +375,8 @@
 // NORNGBSE-NOT: -fdebug-ranges-base-address
 //
 // GARANGE-DAG: -generate-arange-section
+// LDGARANGE-NOT: {{".*lld.*"}} {{.*}} "-generate-arange-section"
+// LLDGARANGE: {{".*lld.*"}} {{.*}} "-generate-arange-section"
 //
 // FDTS: "-mllvm" "-generate-type-units"
 // FDTSE: error: unsupported option '-fdebug-types-section' for target 
'x86_64-apple-darwin'
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -506,6 +506,19 @@
 Suffix,
 Plugin);
 CmdArgs.push_back(Args.MakeArgString(Plugin));
+  } else {
+// NOTE:
+// - it is not possible to use lld for PS4
+// - addLTOOptions() is not used for PS5
+// Hence no need to handle SCE (like in Clang.cpp::renderDebugOptions()).
+//
+// But note, this solution is far from perfert, better to encode it into IR
+// metadata, but this may not worth it, since looks like aranges on the way
+// out.
+if (Args.hasArg(options::OPT_gdwarf_aranges)) {
+  CmdArgs.push_back(Args.MakeArgString("-mllvm"));
+  CmdArgs.push_back(Args.MakeArgString("-generate-arange-section"));
+}
   }
 
   // Try to pass driver level flags relevant to LTO code generation down to


Index: clang/test/Driver/debug-options.c
===
--- clang/test/Driver/debug-options.c
+++ clang/test/Driver/debug-options.c
@@ -246,7 +246,11 @@
 // RUN: %clang -### -c -glldb %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 // RUN: %clang -### -c -glldb -gno-pubnames %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 //
-// RUN: %clang -### -c -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=GARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -c -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=GARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -flto -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=LDGARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -flto=thin -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=LDGARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -fuse-ld=lld -flto -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=LLDGARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -fuse-ld=lld -flto=thin -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=LLDGARANGE %s
 //
 // RUN: %clang -### -fdebug-types-section -target x86_64-unknown-linux %s 2>&1 \
 // RUN:| FileCheck -check-prefix=FDTS %s
@@ -371,6 +375,8 @@
 // NORNGBSE-NOT: -fdebug-ranges-base-address
 //
 // GARANGE-DAG: -generate-arange-section
+// LDGARANGE-NOT: {{".*lld.*"}} {{.*}} "-generate-arange-section"
+// LLDGARANGE: {{".*lld.*"}} {{.*}} "-generate-arange-section"
 //
 // FDTS: "-mllvm" "-generate-type-units"
 // FDTSE: error: unsupported option '-fdebug-types-section' for target 'x86_64-apple-darwin'
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -506,6 +506,19 @@
 Suffix,
 Plugin);
 CmdArgs.push_back(Args.MakeArgString(Plugin));
+  } else {
+// NOTE:
+// - it is not possible to use lld for PS4
+// - addLTOOptions() is not used for PS5
+// Hence no need to handle SCE (like i

[PATCH] D133092: [clang] fix generation of .debug_aranges with LTO

[Paul Robinson via Phabricator via cfe-commits]

probinson added inline comments.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:515
+//
+// But note, this solution is far from perfert, better to encode it into IR
+// metadata, but this may not worth it, since looks like aranges on the way

Typo, perfert -> perfect



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:516
+// But note, this solution is far from perfert, better to encode it into IR
+// metadata, but this may not worth it, since looks like aranges on the way
+// out.

...this may not _be_ worth it, since _it_ looks like aranges _is_ on the way 
out.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133092

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

[PATCH] D133488: [clang][PowerPC][NFC] Add base test case for PPC64 VAArg aggregate smaller than a slot

[Ting Wang via Phabricator via cfe-commits]

tingwang created this revision.
tingwang added reviewers: uweigand, wschmidt, PowerPC.
tingwang added a project: clang.
Herald added subscribers: shchenz, kbarton, nemanjai.
Herald added a project: All.
tingwang requested review of this revision.
Herald added a subscriber: cfe-commits.

Add base test case for https://reviews.llvm.org/D18.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133488

Files:
  clang/test/CodeGen/PowerPC/ppc64-align-struct.c


Index: clang/test/CodeGen/PowerPC/ppc64-align-struct.c
===
--- clang/test/CodeGen/PowerPC/ppc64-align-struct.c
+++ clang/test/CodeGen/PowerPC/ppc64-align-struct.c
@@ -9,6 +9,7 @@
 struct test5 { int x[17]; };
 struct test6 { int x[17]; } __attribute__((aligned (16)));
 struct test7 { int x[17]; } __attribute__((aligned (32)));
+struct test8 { char x; };
 
 // CHECK: define{{.*}} void @test1(i32 noundef signext %x, i64 %y.coerce)
 void test1 (int x, struct test1 y)
@@ -128,6 +129,25 @@
   return y;
 }
 
+// Error pattern will be fixed in https://reviews.llvm.org/D18
+// CHECK: define{{.*}} void @test8va(%struct.test8* noalias 
sret(%struct.test8) align 1 %[[AGG_RESULT:.*]], i32 noundef signext %x, ...)
+// CHECK: %[[CUR:[^ ]+]] = load i8*, i8** %ap
+// CHECK: %[[NEXT:[^ ]+]] = getelementptr inbounds i8, i8* %[[CUR]], i64 8
+// CHECK: store i8* %[[NEXT]], i8** %ap
+// CHECK: [[T0:%.*]] = bitcast i8* %[[CUR]] to %struct.test8*
+// CHECK: [[DEST:%.*]] = bitcast %struct.test8* %[[AGG_RESULT]] to i8*
+// CHECK: [[SRC:%.*]] = bitcast %struct.test8* [[T0]] to i8*
+// CHECK: call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 1 [[DEST]], i8* align 
8 [[SRC]], i64 1, i1 false)
+struct test8 test8va (int x, ...)
+{
+  struct test8 y;
+  va_list ap;
+  va_start(ap, x);
+  y = va_arg (ap, struct test8);
+  va_end(ap);
+  return y;
+}
+
 // CHECK: define{{.*}} void @testva_longdouble(%struct.test_longdouble* 
noalias sret(%struct.test_longdouble) align 16 %[[AGG_RESULT:.*]], i32 noundef 
signext %x, ...)
 // CHECK: %[[CUR:[^ ]+]] = load i8*, i8** %ap
 // CHECK: %[[NEXT:[^ ]+]] = getelementptr inbounds i8, i8* %[[CUR]], i64 16


Index: clang/test/CodeGen/PowerPC/ppc64-align-struct.c
===
--- clang/test/CodeGen/PowerPC/ppc64-align-struct.c
+++ clang/test/CodeGen/PowerPC/ppc64-align-struct.c
@@ -9,6 +9,7 @@
 struct test5 { int x[17]; };
 struct test6 { int x[17]; } __attribute__((aligned (16)));
 struct test7 { int x[17]; } __attribute__((aligned (32)));
+struct test8 { char x; };
 
 // CHECK: define{{.*}} void @test1(i32 noundef signext %x, i64 %y.coerce)
 void test1 (int x, struct test1 y)
@@ -128,6 +129,25 @@
   return y;
 }
 
+// Error pattern will be fixed in https://reviews.llvm.org/D18
+// CHECK: define{{.*}} void @test8va(%struct.test8* noalias sret(%struct.test8) align 1 %[[AGG_RESULT:.*]], i32 noundef signext %x, ...)
+// CHECK: %[[CUR:[^ ]+]] = load i8*, i8** %ap
+// CHECK: %[[NEXT:[^ ]+]] = getelementptr inbounds i8, i8* %[[CUR]], i64 8
+// CHECK: store i8* %[[NEXT]], i8** %ap
+// CHECK: [[T0:%.*]] = bitcast i8* %[[CUR]] to %struct.test8*
+// CHECK: [[DEST:%.*]] = bitcast %struct.test8* %[[AGG_RESULT]] to i8*
+// CHECK: [[SRC:%.*]] = bitcast %struct.test8* [[T0]] to i8*
+// CHECK: call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 1 [[DEST]], i8* align 8 [[SRC]], i64 1, i1 false)
+struct test8 test8va (int x, ...)
+{
+  struct test8 y;
+  va_list ap;
+  va_start(ap, x);
+  y = va_arg (ap, struct test8);
+  va_end(ap);
+  return y;
+}
+
 // CHECK: define{{.*}} void @testva_longdouble(%struct.test_longdouble* noalias sret(%struct.test_longdouble) align 16 %[[AGG_RESULT:.*]], i32 noundef signext %x, ...)
 // CHECK: %[[CUR:[^ ]+]] = load i8*, i8** %ap
 // CHECK: %[[NEXT:[^ ]+]] = getelementptr inbounds i8, i8* %[[CUR]], i64 16
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133092: [clang] fix generation of .debug_aranges with LTO

[Azat Khuzhin via Phabricator via cfe-commits]

azat updated this revision to Diff 458723.
azat marked an inline comment as done.
azat added a comment.

Update comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133092

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/Driver/debug-options.c


Index: clang/test/Driver/debug-options.c
===
--- clang/test/Driver/debug-options.c
+++ clang/test/Driver/debug-options.c
@@ -246,7 +246,11 @@
 // RUN: %clang -### -c -glldb %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 // RUN: %clang -### -c -glldb -gno-pubnames %s 2>&1 | FileCheck 
-check-prefix=NOPUB %s
 //
-// RUN: %clang -### -c -gdwarf-aranges %s 2>&1 | FileCheck 
-check-prefix=GARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -c -gdwarf-aranges %s 2>&1 | 
FileCheck -check-prefix=GARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -flto -gdwarf-aranges %s 2>&1 
| FileCheck -check-prefix=LDGARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -flto=thin -gdwarf-aranges %s 
2>&1 | FileCheck -check-prefix=LDGARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -fuse-ld=lld -flto 
-gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=LLDGARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -fuse-ld=lld -flto=thin 
-gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=LLDGARANGE %s
 //
 // RUN: %clang -### -fdebug-types-section -target x86_64-unknown-linux %s 2>&1 
\
 // RUN:| FileCheck -check-prefix=FDTS %s
@@ -371,6 +375,8 @@
 // NORNGBSE-NOT: -fdebug-ranges-base-address
 //
 // GARANGE-DAG: -generate-arange-section
+// LDGARANGE-NOT: {{".*lld.*"}} {{.*}} "-generate-arange-section"
+// LLDGARANGE: {{".*lld.*"}} {{.*}} "-generate-arange-section"
 //
 // FDTS: "-mllvm" "-generate-type-units"
 // FDTSE: error: unsupported option '-fdebug-types-section' for target 
'x86_64-apple-darwin'
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -506,6 +506,19 @@
 Suffix,
 Plugin);
 CmdArgs.push_back(Args.MakeArgString(Plugin));
+  } else {
+// NOTE:
+// - it is not possible to use lld for PS4
+// - addLTOOptions() is not used for PS5
+// Hence no need to handle SCE (like in Clang.cpp::renderDebugOptions()).
+//
+// But note, this solution is far from perfect, better to encode it into IR
+// metadata, but this may not be worth it, since it looks like aranges is
+// on the way out.
+if (Args.hasArg(options::OPT_gdwarf_aranges)) {
+  CmdArgs.push_back(Args.MakeArgString("-mllvm"));
+  CmdArgs.push_back(Args.MakeArgString("-generate-arange-section"));
+}
   }
 
   // Try to pass driver level flags relevant to LTO code generation down to


Index: clang/test/Driver/debug-options.c
===
--- clang/test/Driver/debug-options.c
+++ clang/test/Driver/debug-options.c
@@ -246,7 +246,11 @@
 // RUN: %clang -### -c -glldb %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 // RUN: %clang -### -c -glldb -gno-pubnames %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 //
-// RUN: %clang -### -c -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=GARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -c -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=GARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -flto -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=LDGARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -flto=thin -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=LDGARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -fuse-ld=lld -flto -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=LLDGARANGE %s
+// RUN: %clang -### -target x86_64-unknown-linux -fuse-ld=lld -flto=thin -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=LLDGARANGE %s
 //
 // RUN: %clang -### -fdebug-types-section -target x86_64-unknown-linux %s 2>&1 \
 // RUN:| FileCheck -check-prefix=FDTS %s
@@ -371,6 +375,8 @@
 // NORNGBSE-NOT: -fdebug-ranges-base-address
 //
 // GARANGE-DAG: -generate-arange-section
+// LDGARANGE-NOT: {{".*lld.*"}} {{.*}} "-generate-arange-section"
+// LLDGARANGE: {{".*lld.*"}} {{.*}} "-generate-arange-section"
 //
 // FDTS: "-mllvm" "-generate-type-units"
 // FDTSE: error: unsupported option '-fdebug-types-section' for target 'x86_64-apple-darwin'
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -506,6 +506,19 @@
 Suffix,
 Plugin);
 CmdArgs.push_back(Args.MakeArgString(Plugin));
+  } else {
+// NOTE:
+// - it is not possible to use lld for PS4
+// - addLTOOptions() is not used for

[PATCH] D132962: [clangd][ObjC] Improve completions for protocols + category names

[David Goldman via Phabricator via cfe-commits]

dgoldman updated this revision to Diff 458724.
dgoldman added a comment.

Address comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132962

Files:
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang-tools-extra/clangd/unittests/TestIndex.cpp
  clang-tools-extra/clangd/unittests/TestIndex.h

Index: clang-tools-extra/clangd/unittests/TestIndex.h
===
--- clang-tools-extra/clangd/unittests/TestIndex.h
+++ clang-tools-extra/clangd/unittests/TestIndex.h
@@ -39,6 +39,8 @@
llvm::StringRef USRPrefix);
 // Create an @interface or @implementation.
 Symbol objcClass(llvm::StringRef Name);
+// Create an @interface or @implementation category.
+Symbol objcCategory(llvm::StringRef Name, llvm::StringRef CategoryName);
 // Create an @protocol.
 Symbol objcProtocol(llvm::StringRef Name);
 
Index: clang-tools-extra/clangd/unittests/TestIndex.cpp
===
--- clang-tools-extra/clangd/unittests/TestIndex.cpp
+++ clang-tools-extra/clangd/unittests/TestIndex.cpp
@@ -99,6 +99,11 @@
   return objcSym(Name, index::SymbolKind::Class, "objc(cs)");
 }
 
+Symbol objcCategory(llvm::StringRef Name, llvm::StringRef CategoryName) {
+  std::string USRPrefix = ("objc(cy)" + Name + "@").str();
+  return objcSym(CategoryName, index::SymbolKind::Extension, USRPrefix);
+}
+
 Symbol objcProtocol(llvm::StringRef Name) {
   return objcSym(Name, index::SymbolKind::Protocol, "objc(pl)");
 }
Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -1493,12 +1493,16 @@
 
 class IndexRequestCollector : public SymbolIndex {
 public:
+  IndexRequestCollector(std::vector Syms = {}) : Symbols(Syms) {}
+
   bool
   fuzzyFind(const FuzzyFindRequest &Req,
 llvm::function_ref Callback) const override {
 std::unique_lock Lock(Mut);
 Requests.push_back(Req);
 ReceivedRequestCV.notify_one();
+for (const auto &Sym : Symbols)
+  Callback(Sym);
 return true;
   }
 
@@ -1533,6 +1537,7 @@
   }
 
 private:
+  std::vector Symbols;
   // We need a mutex to handle async fuzzy find requests.
   mutable std::condition_variable ReceivedRequestCV;
   mutable std::mutex Mut;
@@ -3208,14 +3213,74 @@
   Symbol FoodClass = objcClass("FoodClass");
   Symbol SymFood = objcProtocol("Food");
   Symbol SymFooey = objcProtocol("Fooey");
+  auto Results = completions("id", {SymFood, FoodClass, SymFooey},
+ /*Opts=*/{}, "Foo.m");
+
+  // Should only give protocols for ObjC protocol completions.
+  EXPECT_THAT(Results.Completions,
+  UnorderedElementsAre(
+  AllOf(named("Food"), kind(CompletionItemKind::Interface)),
+  AllOf(named("Fooey"), kind(CompletionItemKind::Interface;
+
+  Results = completions("Fo^", {SymFood, FoodClass, SymFooey},
+/*Opts=*/{}, "Foo.m");
+  // Shouldn't give protocols for non protocol completions.
+  EXPECT_THAT(
+  Results.Completions,
+  ElementsAre(AllOf(named("FoodClass"), kind(CompletionItemKind::Class;
+}
+
+TEST(CompletionTest, ObjectiveCProtocolFromIndexSpeculation) {
+  MockFS FS;
+  MockCompilationDatabase CDB;
+  ClangdServer Server(CDB, FS, ClangdServer::optsForTest());
+
+  auto File = testPath("Foo.m");
+  Annotations Test(R"cpp(
+  @protocol Food
+  @end
+  id foo;
+  Foo$2^ bar;
+  )cpp");
+  runAddDocument(Server, File, Test.code());
+  clangd::CodeCompleteOptions Opts = {};
+
+  Symbol FoodClass = objcClass("FoodClass");
+  IndexRequestCollector Requests({FoodClass});
+  Opts.Index = &Requests;
+
+  auto CompleteAtPoint = [&](StringRef P) {
+return cantFail(runCodeComplete(Server, File, Test.point(P), Opts))
+.Completions;
+  };
+
+  auto C = CompleteAtPoint("1");
+  auto Reqs1 = Requests.consumeRequests(1);
+  ASSERT_EQ(Reqs1.size(), 1u);
+  EXPECT_THAT(C, ElementsAre(AllOf(named("Food"),
+   kind(CompletionItemKind::Interface;
+
+  C = CompleteAtPoint("2");
+  auto Reqs2 = Requests.consumeRequests(1);
+  // Speculation succeeded. Used speculative index result, but filtering now to
+  // now include FoodClass.
+  ASSERT_EQ(Reqs2.size(), 1u);
+  EXPECT_EQ(Reqs2[0], Reqs1[0]);
+  EXPECT_THAT(C, ElementsAre(AllOf(named("FoodClass"),
+   kind(CompletionItemKind::Class;
+}
+
+TEST(CompletionTest, ObjectiveCCategoryFromIndexIgnored) {
+  Symbol FoodCategory = objcCategory("FoodClass", "Extension");
   auto Results = completions(R"objc(
-  id
+  @interface Foo
+  @end
+  @interface Foo (^)
+  @end
 )objc

[PATCH] D132962: [clangd][ObjC] Improve completions for protocols + category names

[David Goldman via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/clangd/CodeComplete.cpp:1731
 SymbolSlab::Builder ResultsBuilder;
-if (Opts.Index->fuzzyFind(Req, [&](const Symbol &Sym) {
-  if (includeSymbolFromIndex(Sym))
-ResultsBuilder.insert(Sym);
-}))
+if (Opts.Index->fuzzyFind(
+Req, [&](const Symbol &Sym) { ResultsBuilder.insert(Sym); }))

kadircet wrote:
> nit: while here can you change this to read as:
> `Incomplete ||= Opts.Index->fuzzyFind(...);`
Done, but there's no ||= and we wouldn't want to short circuit, so used |= 
instead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132962

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

[PATCH] D132131: [clang-format] Adds a formatter for aligning trailing comments over empty lines

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

another reason for using a struct, is that we might want to say something like 
"AlignNamespaceTrainingComments:false" 
https://github.com/llvm/llvm-project/issues/57504


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132131

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

[PATCH] D133338: [clang][PowerPC] PPC64 VAArg use coerced integer type for direct aggregate fits in register

[Ting Wang via Phabricator via cfe-commits]

tingwang updated this revision to Diff 458721.
tingwang added a comment.

Update according to comments:
(1) The argument type is not touched.
(2) Add flag in APIs to force right-adjust the parameter for this issue.
(3) One change on if check logic: now use CoerceTy->getIntegerBitWidth() 
directly compare with GPRBits, previously used 
llvm::alignTo(CoerceTy->getIntegerBitWidth(), 8). I think `llvm::alignTo()` is 
redundant here.
(4) Created NFC patch to pre-commit the test case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D18

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/PowerPC/ppc64-align-struct.c

Index: clang/test/CodeGen/PowerPC/ppc64-align-struct.c
===
--- clang/test/CodeGen/PowerPC/ppc64-align-struct.c
+++ clang/test/CodeGen/PowerPC/ppc64-align-struct.c
@@ -129,15 +129,15 @@
   return y;
 }
 
-// Error pattern will be fixed in https://reviews.llvm.org/D18
 // CHECK: define{{.*}} void @test8va(%struct.test8* noalias sret(%struct.test8) align 1 %[[AGG_RESULT:.*]], i32 noundef signext %x, ...)
 // CHECK: %[[CUR:[^ ]+]] = load i8*, i8** %ap
 // CHECK: %[[NEXT:[^ ]+]] = getelementptr inbounds i8, i8* %[[CUR]], i64 8
 // CHECK: store i8* %[[NEXT]], i8** %ap
-// CHECK: [[T0:%.*]] = bitcast i8* %[[CUR]] to %struct.test8*
+// CHECK: [[T0:%.*]] = getelementptr inbounds i8, i8* %[[CUR]], i64 7
+// CHECK: [[T1:%.*]] = bitcast i8* [[T0]] to %struct.test8*
 // CHECK: [[DEST:%.*]] = bitcast %struct.test8* %[[AGG_RESULT]] to i8*
-// CHECK: [[SRC:%.*]] = bitcast %struct.test8* [[T0]] to i8*
-// CHECK: call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 1 [[DEST]], i8* align 8 [[SRC]], i64 1, i1 false)
+// CHECK: [[SRC:%.*]] = bitcast %struct.test8* [[T1]] to i8*
+// CHECK: call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 1 [[DEST]], i8* align 1 [[SRC]], i64 1, i1 false)
 struct test8 test8va (int x, ...)
 {
   struct test8 y;
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -322,13 +322,17 @@
 ///   leaving one or more empty slots behind as padding.  If this
 ///   is false, the returned address might be less-aligned than
 ///   DirectAlign.
+/// \param ForceRightAdjust - Default is false. On big-endian platform and
+///   if the argument is smaller than a slot, set this flag will force
+///   right-adjust the argument in its slot irrespective of the type.
 static Address emitVoidPtrDirectVAArg(CodeGenFunction &CGF,
   Address VAListAddr,
   llvm::Type *DirectTy,
   CharUnits DirectSize,
   CharUnits DirectAlign,
   CharUnits SlotSize,
-  bool AllowHigherAlign) {
+  bool AllowHigherAlign,
+  bool ForceRightAdjust = false) {
   // Cast the element type to i8* if necessary.  Some platforms define
   // va_list as a struct containing an i8* instead of just an i8*.
   if (VAListAddr.getElementType() != CGF.Int8PtrTy)
@@ -354,7 +358,7 @@
   // If the argument is smaller than a slot, and this is a big-endian
   // target, the argument will be right-adjusted in its slot.
   if (DirectSize < SlotSize && CGF.CGM.getDataLayout().isBigEndian() &&
-  !DirectTy->isStructTy()) {
+  (!DirectTy->isStructTy() || ForceRightAdjust)) {
 Addr = CGF.Builder.CreateConstInBoundsByteGEP(Addr, SlotSize - DirectSize);
   }
 
@@ -375,11 +379,15 @@
 ///   an argument type with an alignment greater than the slot size
 ///   will be emitted on a higher-alignment address, potentially
 ///   leaving one or more empty slots behind as padding.
+/// \param ForceRightAdjust - Default is false. On big-endian platform and
+///   if the argument is smaller than a slot, set this flag will force
+///   right-adjust the argument in its slot irrespective of the type.
 static Address emitVoidPtrVAArg(CodeGenFunction &CGF, Address VAListAddr,
 QualType ValueTy, bool IsIndirect,
 TypeInfoChars ValueInfo,
 CharUnits SlotSizeAndAlign,
-bool AllowHigherAlign) {
+bool AllowHigherAlign,
+bool ForceRightAdjust = false) {
   // The size and alignment of the value that was passed directly.
   CharUnits DirectSize, DirectAlign;
   if (IsIndirect) {
@@ -395,9 +403,9 @@
   if (IsIndirect)
 DirectTy = DirectTy->getPointerTo(0);
 
-  Address Addr =
-  emitVoidPtrDirectVAArg(CGF, VAListAddr, DirectTy, DirectSize, DirectAlign,
- SlotSizeAndAlign, AllowHighe

[PATCH] D129755: Thread safety analysis: Support copy-elided production of scoped capabilities through arbitrary calls

[Aaron Puchert via Phabricator via cfe-commits]

aaronpuchert added a comment.

I was under the impression that we've already switched to C++17, but the 
Windows pre-submit build failed with:

  
C:\ws\w9\llvm-project\premerge-checks\clang\lib\Analysis\ThreadSafety.cpp(2107):
 error C2429: language feature 'init-statements in if/switch' requires compiler 
flag '/std:c++17'
  
C:\ws\w9\llvm-project\premerge-checks\clang\lib\Analysis\ThreadSafety.cpp(2120):
 error C2429: language feature 'init-statements in if/switch' requires compiler 
flag '/std:c++17'
  
C:\ws\w9\llvm-project\premerge-checks\clang\lib\Analysis\ThreadSafety.cpp(2418):
 error C2429: language feature 'init-statements in if/switch' requires compiler 
flag '/std:c++17'

Perhaps I should move the init statements out again?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129755

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

[PATCH] D133202: [Clang] Avoid __builtin_assume_aligned crash when the 1st arg is array type

[Lin Yurong via Phabricator via cfe-commits]

yronglin added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:7651-7652
+  Expr *FirstArg = TheCall->getArg(0);
+  if (auto *CE = dyn_cast(FirstArg))
+FirstArg = CE->getSubExprAsWritten();
 

rjmccall wrote:
> rsmith wrote:
> > This looks very suspicious to me: this will remove a cast expression that 
> > was written in the source code from the AST. That loses source fidelity, 
> > can give the wrong answer if the cast changed the value (such as a C++ 
> > derived-to-base conversion to a non-primary base class), and in any case 
> > this is only done once where there could be multiple explicit casts written 
> > on an argument to the builtin, so if it's necessary, then it's not being 
> > done fully.
> > 
> > Can this be removed?
> Somehow I missed this in my review.  Yes, this line should be unnecessary, 
> and as you say, it is definitely wrong.
CodeGen need real `user-written-type` to generate 
`__ubsan_handle_alignment_assumption ` 's arg, but not `const void *`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133202

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

[PATCH] D133338: [clang][PowerPC] PPC64 VAArg use coerced integer type for direct aggregate fits in register

[Ulrich Weigand via Phabricator via cfe-commits]

uweigand added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:5471
+if (CoerceTy->isIntegerTy() && CoerceTy->getIntegerBitWidth() < 
GPRBits)
+  ForceRightAdjust = true;
+  }

Are all these checks really necessary here?  This seems to duplicate the checks 
that are already in `emitVoidPtrVAArg` ...Can't we simply always pass 
`true` for `ForceRightAdjust` on PowerPC?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D18

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

[PATCH] D133092: [clang] fix generation of .debug_aranges with LTO

[David Blaikie via Phabricator via cfe-commits]

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

Sounds good


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133092

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

[PATCH] D133202: [Clang] Avoid __builtin_assume_aligned crash when the 1st arg is array type

[Lin Yurong via Phabricator via cfe-commits]

yronglin added a comment.

Reproduce windows broken test:

ignore.cpp

  #include 
  
  void *__builtin_assume_aligned(const void *, size_t, ...) noexcept;
  void foo() {
int a;
(void) __builtin_assume_aligned(&a, 4);
  }



  FunctionDecl 0x14a80e480 <./ignore.cpp:3:1, col:7> col:7 
__builtin_assume_aligned 'void *(const void *, size_t, ...) noexcept'
  |-ParmVarDecl 0x14a80df80  col:44 'const void *'
  `-ParmVarDecl 0x14a80e050  col:52 'size_t':'unsigned long'
  FunctionDecl 0x14a80e210 <./ignore.cpp:3:7> col:7 implicit 
__builtin_assume_aligned 'void *(const void *, unsigned long, ...) noexcept' 
extern
  |-ParmVarDecl 0x14a80e308 <>  'const void *'
  |-ParmVarDecl 0x14a80e370 <>  'unsigned long'
  |-BuiltinAttr 0x14a80e2b0 <> Implicit 402
  |-NoThrowAttr 0x14a80e3e8  Implicit
  `-ConstAttr 0x14a80e410  Implicit

  ./ignore.cpp:3:7: error: cannot redeclare builtin function 
'__builtin_assume_aligned'
  void *__builtin_assume_aligned(const void *, size_t, ...) noexcept;
^
  ./ignore.cpp:3:7: note: '__builtin_assume_aligned' is a builtin with type 
'void *(const void *, unsigned long, ...) noexcept'
  1 error generated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133202

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

[PATCH] D126907: Deferred Concept Instantiation Implementation Take 2

[Louis Dionne via Phabricator via cfe-commits]

ldionne added a comment.

In D126907#3746477 , @Mordante wrote:

> Unfortunately there are a lot of different options and combination of options 
> to test libc++.
> So it's indeed not possible to test all options with once check-cxx 
> invocation.

This ^. We could include all the libc++ configurations in a single `check-cxx` 
invokation, but the tests would run for like 70 hours on most machines. 
Instead, we test different configurations in different CI jobs.

In D126907#3777056 , @erichkeane 
wrote:

> Still WIP, but uploading to show that I'm still on this :/
>
> The two modules related issues from libcxx are now fixed (as reported by 
> @Mordante), and that configuration builds and passes all tests with MOST of 
> this change.
>
> HOWEVER, the first of two fixes for @wlei messes up how constraint 
> expressions on class templates are compared, so the result is ~800 additional 
> libcxx failures.  I'm still working through that.

Just to make sure we're on the same page, I assume most of those issues are 
things that would have been encountered in user code otherwise and filed as 
bugs. So in a way, I think libc++ is simply acting like some kind of 
early-in-the-loop pre-release testing. This is similar to what some other 
open-source projects like Chrome do -- they build from trunk often and will 
report actual issues to us early. I do get why it can be annoying and 
disruptive to landing patches sometimes, though.

Concretely, what we could do is probably add `LLVM_ENABLE_RUNTIMES=libcxx` to 
the Clang pre-commit CI that already runs. That would catch some (but of course 
not all) issues. In particular, that should catch issues that would otherwise 
immediately break the libc++ "Bootstrapping build" CI job. For other issues 
(like an arbitrary combination of `-std=c++xy -fmodules -fno-rtti`), I think we 
can only rely on slower feedback when libc++ updates the nightly version of 
Clang that we use in our CI (which would act like a super-early adopter from 
the POV of Clang at that point).


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

https://reviews.llvm.org/D126907

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

[PATCH] D126907: Deferred Concept Instantiation Implementation Take 2

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D126907#3777088 , @ldionne wrote:

> In D126907#3746477 , @Mordante 
> wrote:
>
>> Unfortunately there are a lot of different options and combination of 
>> options to test libc++.
>> So it's indeed not possible to test all options with once check-cxx 
>> invocation.
>
> This ^. We could include all the libc++ configurations in a single 
> `check-cxx` invokation, but the tests would run for like 70 hours on most 
> machines. Instead, we test different configurations in different CI jobs.
>
> In D126907#3777056 , @erichkeane 
> wrote:
>
>> Still WIP, but uploading to show that I'm still on this :/
>>
>> The two modules related issues from libcxx are now fixed (as reported by 
>> @Mordante), and that configuration builds and passes all tests with MOST of 
>> this change.
>>
>> HOWEVER, the first of two fixes for @wlei messes up how constraint 
>> expressions on class templates are compared, so the result is ~800 
>> additional libcxx failures.  I'm still working through that.
>
> Just to make sure we're on the same page, I assume most of those issues are 
> things that would have been encountered in user code otherwise and filed as 
> bugs. So in a way, I think libc++ is simply acting like some kind of 
> early-in-the-loop pre-release testing. This is similar to what some other 
> open-source projects like Chrome do -- they build from trunk often and will 
> report actual issues to us early. I do get why it can be annoying and 
> disruptive to landing patches sometimes, though.

Yep, this is the case.  Just frustrating to be surprised by things like this as 
late in the process as I was, so I was a little grumpy above.  Unfortunately it 
seems like each of these cycles costs a month here :/

> Concretely, what we could do is probably add `LLVM_ENABLE_RUNTIMES=libcxx` to 
> the Clang pre-commit CI that already runs. That would catch some (but of 
> course not all) issues. In particular, that should catch issues that would 
> otherwise immediately break the libc++ "Bootstrapping build" CI job. For 
> other issues (like an arbitrary combination of `-std=c++xy -fmodules 
> -fno-rtti`), I think we can only rely on slower feedback when libc++ updates 
> the nightly version of Clang that we use in our CI (which would act like a 
> super-early adopter from the POV of Clang at that point).


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

https://reviews.llvm.org/D126907

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

[PATCH] D133338: [clang][PowerPC] PPC64 VAArg use coerced integer type for direct aggregate fits in register

[Ting Wang via Phabricator via cfe-commits]

tingwang updated this revision to Diff 458735.
tingwang added a comment.

Update according to comments:
Remove all those checks, they are redundant.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D18

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/PowerPC/ppc64-align-struct.c


Index: clang/test/CodeGen/PowerPC/ppc64-align-struct.c
===
--- clang/test/CodeGen/PowerPC/ppc64-align-struct.c
+++ clang/test/CodeGen/PowerPC/ppc64-align-struct.c
@@ -129,15 +129,15 @@
   return y;
 }
 
-// Error pattern will be fixed in https://reviews.llvm.org/D18
 // CHECK: define{{.*}} void @test8va(%struct.test8* noalias 
sret(%struct.test8) align 1 %[[AGG_RESULT:.*]], i32 noundef signext %x, ...)
 // CHECK: %[[CUR:[^ ]+]] = load i8*, i8** %ap
 // CHECK: %[[NEXT:[^ ]+]] = getelementptr inbounds i8, i8* %[[CUR]], i64 8
 // CHECK: store i8* %[[NEXT]], i8** %ap
-// CHECK: [[T0:%.*]] = bitcast i8* %[[CUR]] to %struct.test8*
+// CHECK: [[T0:%.*]] = getelementptr inbounds i8, i8* %[[CUR]], i64 7
+// CHECK: [[T1:%.*]] = bitcast i8* [[T0]] to %struct.test8*
 // CHECK: [[DEST:%.*]] = bitcast %struct.test8* %[[AGG_RESULT]] to i8*
-// CHECK: [[SRC:%.*]] = bitcast %struct.test8* [[T0]] to i8*
-// CHECK: call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 1 [[DEST]], i8* align 
8 [[SRC]], i64 1, i1 false)
+// CHECK: [[SRC:%.*]] = bitcast %struct.test8* [[T1]] to i8*
+// CHECK: call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 1 [[DEST]], i8* align 
1 [[SRC]], i64 1, i1 false)
 struct test8 test8va (int x, ...)
 {
   struct test8 y;
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -322,13 +322,17 @@
 ///   leaving one or more empty slots behind as padding.  If this
 ///   is false, the returned address might be less-aligned than
 ///   DirectAlign.
+/// \param ForceRightAdjust - Default is false. On big-endian platform and
+///   if the argument is smaller than a slot, set this flag will force
+///   right-adjust the argument in its slot irrespective of the type.
 static Address emitVoidPtrDirectVAArg(CodeGenFunction &CGF,
   Address VAListAddr,
   llvm::Type *DirectTy,
   CharUnits DirectSize,
   CharUnits DirectAlign,
   CharUnits SlotSize,
-  bool AllowHigherAlign) {
+  bool AllowHigherAlign,
+  bool ForceRightAdjust = false) {
   // Cast the element type to i8* if necessary.  Some platforms define
   // va_list as a struct containing an i8* instead of just an i8*.
   if (VAListAddr.getElementType() != CGF.Int8PtrTy)
@@ -354,7 +358,7 @@
   // If the argument is smaller than a slot, and this is a big-endian
   // target, the argument will be right-adjusted in its slot.
   if (DirectSize < SlotSize && CGF.CGM.getDataLayout().isBigEndian() &&
-  !DirectTy->isStructTy()) {
+  (!DirectTy->isStructTy() || ForceRightAdjust)) {
 Addr = CGF.Builder.CreateConstInBoundsByteGEP(Addr, SlotSize - DirectSize);
   }
 
@@ -375,11 +379,15 @@
 ///   an argument type with an alignment greater than the slot size
 ///   will be emitted on a higher-alignment address, potentially
 ///   leaving one or more empty slots behind as padding.
+/// \param ForceRightAdjust - Default is false. On big-endian platform and
+///   if the argument is smaller than a slot, set this flag will force
+///   right-adjust the argument in its slot irrespective of the type.
 static Address emitVoidPtrVAArg(CodeGenFunction &CGF, Address VAListAddr,
 QualType ValueTy, bool IsIndirect,
 TypeInfoChars ValueInfo,
 CharUnits SlotSizeAndAlign,
-bool AllowHigherAlign) {
+bool AllowHigherAlign,
+bool ForceRightAdjust = false) {
   // The size and alignment of the value that was passed directly.
   CharUnits DirectSize, DirectAlign;
   if (IsIndirect) {
@@ -395,9 +403,9 @@
   if (IsIndirect)
 DirectTy = DirectTy->getPointerTo(0);
 
-  Address Addr =
-  emitVoidPtrDirectVAArg(CGF, VAListAddr, DirectTy, DirectSize, 
DirectAlign,
- SlotSizeAndAlign, AllowHigherAlign);
+  Address Addr = emitVoidPtrDirectVAArg(CGF, VAListAddr, DirectTy, DirectSize,
+DirectAlign, SlotSizeAndAlign,
+AllowHigherAlign, ForceRightAdjust);
 
   if (IsIndirect) {
 Addr = Address(CGF.Builder.CreateLoad(Addr), ElementTy, ValueIn

[PATCH] D133338: [clang][PowerPC] PPC64 VAArg use coerced integer type for direct aggregate fits in register

[Ting Wang via Phabricator via cfe-commits]

tingwang added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:5471
+if (CoerceTy->isIntegerTy() && CoerceTy->getIntegerBitWidth() < 
GPRBits)
+  ForceRightAdjust = true;
+  }

uweigand wrote:
> Are all these checks really necessary here?  This seems to duplicate the 
> checks that are already in `emitVoidPtrVAArg` ...Can't we simply always 
> pass `true` for `ForceRightAdjust` on PowerPC?
Ah, yes. All these checks are redundant, and this essentially reverts back to 
before the commit that broke this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D18

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

[PATCH] D127695: WIP: clang: Implement Template Specialization Resugaring

[David Rector via Phabricator via cfe-commits]

davrec added inline comments.



Comment at: clang/lib/Sema/SemaTemplate.cpp:534-540
+  QualType TransformSubstTemplateTypeParmType(TypeLocBuilder &TLB,
+  SubstTemplateTypeParmTypeLoc TL) 
{
+QualType QT = TL.getType();
+const SubstTemplateTypeParmType *T = TL.getTypePtr();
+Decl *ReplacedDecl = T->getReplacedDecl();
+
+Optional PackIndex = T->getPackIndex();

davrec wrote:
> Haven't thought this through fully, but: would the following make D128113 
> (storing the pack index in the STTPT or introducing a new sugar type) 
> unnecessary?
> ```
> map, Optional> CurPackIndices;
> QualType TransformSubstTemplateTypeParmType(TypeLocBuilder &TLB,
>   SubstTemplateTypeParmTypeLoc 
> TL) {
>QualType QT = TL.getType();
>const SubstTemplateTypeParmType *T = TL.getTypePtr();
>Decl *ReplacedDecl = T->getReplacedDecl();
>
>Optional &PackIndex = CurPackIndices[{ReplacedDecl, 
> T->getIndex()}];
>if (!PackIndex && T->getReplacedParameter()->isParameterPack())
>  PackIndex = 0;
> 
>...
> 
>if (PackIndex)
>  ++PackIndex;
>  // ^ maybe reset to zero if > pack size, if we might be resugaring 
> multiple expansions
>return QT;
> }
> ```
Disregard above - upon further thought this does not improve the things; there 
still isn't enough info about the substitutions.  I.e. the issue is with 
substitutions, not the parameter declarations for which they are substituted.  
So a sugar node wrapping the STTPTs to represent each expansion instance really 
is needed.  Then when we have that I think we could map from those to their 
current pack indices per the above to infer the pack indices.

For this sugar node, maybe we could just modify `SubstTemplateTypeParmPackType` 
so it is not just canonical, but can also be sugar wrapping substituted STTPTs, 
as opposed to introducing a new Subst* type class?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127695

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

[PATCH] D133499: [clang]: Add DeclContext::dumpDecl() in order to conveniently dump an AST from a DeclContext.

[Tom Honermann via Phabricator via cfe-commits]

tahonermann created this revision.
tahonermann added reviewers: erichkeane, aaron.ballman, shafik.
Herald added a project: All.
tahonermann requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This change enables a declaration to be conveniently displayed within a 
debugger when only a DeclContext is available. For example, in gdb:

  (gdb) p Ctx
  $1 = (const clang::DeclContext *) 0x145a54f0
  (gdb) p Ctx->dumpDecl()
  ClassTemplateSpecializationDecl 0x145a54b0  col:12 
struct ict
  `-TemplateArgument type 'int'
`-BuiltinType 0x14538600 'int'
  $2 = void


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133499

Files:
  clang/include/clang/AST/DeclBase.h
  clang/lib/AST/ASTDumper.cpp


Index: clang/lib/AST/ASTDumper.cpp
===
--- clang/lib/AST/ASTDumper.cpp
+++ clang/lib/AST/ASTDumper.cpp
@@ -200,6 +200,11 @@
   P.Visit(this);
 }
 
+LLVM_DUMP_METHOD void DeclContext::dumpDecl() const {
+  if (const Decl *D = dyn_cast(this))
+D->dump();
+}
+
 LLVM_DUMP_METHOD void DeclContext::dumpLookups() const {
   dumpLookups(llvm::errs());
 }
Index: clang/include/clang/AST/DeclBase.h
===
--- clang/include/clang/AST/DeclBase.h
+++ clang/include/clang/AST/DeclBase.h
@@ -2524,6 +2524,7 @@
   static bool classof(const DeclContext *D) { return true; }
 
   void dumpDeclContext() const;
+  void dumpDecl() const;
   void dumpLookups() const;
   void dumpLookups(llvm::raw_ostream &OS, bool DumpDecls = false,
bool Deserialize = false) const;


Index: clang/lib/AST/ASTDumper.cpp
===
--- clang/lib/AST/ASTDumper.cpp
+++ clang/lib/AST/ASTDumper.cpp
@@ -200,6 +200,11 @@
   P.Visit(this);
 }
 
+LLVM_DUMP_METHOD void DeclContext::dumpDecl() const {
+  if (const Decl *D = dyn_cast(this))
+D->dump();
+}
+
 LLVM_DUMP_METHOD void DeclContext::dumpLookups() const {
   dumpLookups(llvm::errs());
 }
Index: clang/include/clang/AST/DeclBase.h
===
--- clang/include/clang/AST/DeclBase.h
+++ clang/include/clang/AST/DeclBase.h
@@ -2524,6 +2524,7 @@
   static bool classof(const DeclContext *D) { return true; }
 
   void dumpDeclContext() const;
+  void dumpDecl() const;
   void dumpLookups() const;
   void dumpLookups(llvm::raw_ostream &OS, bool DumpDecls = false,
bool Deserialize = false) const;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133428: [WebAssembly] Prototype `f32x4.relaxed_dot_bf16x8_add_f32`

[Thomas Lively via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGac3b8df8f2f4: [WebAssembly] Prototype 
`f32x4.relaxed_dot_bf16x8_add_f32` (authored by tlively).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133428

Files:
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-wasm.c
  llvm/include/llvm/IR/IntrinsicsWebAssembly.td
  llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
  llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll

Index: llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
===
--- llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
+++ llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll
@@ -786,6 +786,20 @@
   ret <4 x float> %v
 }
 
+; CHECK-LABEL: relaxed_dot_bf16x8_add_f32:
+; CHECK-NEXT: .functype relaxed_dot_bf16x8_add_f32 (v128, v128, v128) -> (v128){{$}}
+; CHECK-NEXT: f32x4.relaxed_dot_bf16x8_add_f32 $push[[R:[0-9]+]]=, $0, $1, $2{{$}}
+; CHECK-NEXT: return $pop[[R]]{{$}}
+declare <4 x float> @llvm.wasm.relaxed.dot.bf16x8.add.f32(<8 x i16>, <8 x i16>,
+  <4 x float>)
+define <4 x float> @relaxed_dot_bf16x8_add_f32(<8 x i16> %a, <8 x i16> %b,
+   <4 x float> %c) {
+  %v = call <4 x float> @llvm.wasm.relaxed.dot.bf16x8.add.f32(
+<8 x i16> %a, <8 x i16> %b, <4 x float> %c
+  )
+  ret <4 x float> %v
+}
+
 ; ==
 ; 2 x f64
 ; ==
Index: llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
===
--- llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
+++ llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
@@ -1466,3 +1466,15 @@
(v16i8 V128:$lhs), (v16i8 V128:$rhs), (v4i32 V128:$acc)))],
 "i32x4.dot_i8x16_i7x16_add_s\t$dst, $lhs, $rhs, $acc",
 "i32x4.dot_i8x16_i7x16_add_s", 0x113>;
+
+//===--===//
+// Relaxed BFloat16 dot product
+//===--===//
+
+defm RELAXED_DOT_BFLOAT :
+  RELAXED_I<(outs V128:$dst), (ins V128:$lhs, V128:$rhs, V128:$acc),
+(outs), (ins),
+[(set (v4f32 V128:$dst), (int_wasm_relaxed_dot_bf16x8_add_f32
+   (v8i16 V128:$lhs), (v8i16 V128:$rhs), (v4f32 V128:$acc)))],
+"f32x4.relaxed_dot_bf16x8_add_f32\t$dst, $lhs, $rhs, $acc",
+"f32x4.relaxed_dot_bf16x8_add_f32", 0x114>;
Index: llvm/include/llvm/IR/IntrinsicsWebAssembly.td
===
--- llvm/include/llvm/IR/IntrinsicsWebAssembly.td
+++ llvm/include/llvm/IR/IntrinsicsWebAssembly.td
@@ -285,6 +285,12 @@
 [llvm_v16i8_ty, llvm_v16i8_ty, llvm_v4i32_ty],
 [IntrNoMem, IntrSpeculatable]>;
 
+def int_wasm_relaxed_dot_bf16x8_add_f32:
+  Intrinsic<[llvm_v4f32_ty],
+[llvm_v8i16_ty, llvm_v8i16_ty, llvm_v4f32_ty],
+[IntrNoMem, IntrSpeculatable]>;
+
+
 //===--===//
 // Thread-local storage intrinsics
 //===--===//
Index: clang/test/CodeGen/builtins-wasm.c
===
--- clang/test/CodeGen/builtins-wasm.c
+++ clang/test/CodeGen/builtins-wasm.c
@@ -794,3 +794,10 @@
   // WEBASSEMBLY-SAME: <16 x i8> %a, <16 x i8> %b, <4 x i32> %c)
   // WEBASSEMBLY-NEXT: ret
 }
+
+f32x4 relaxed_dot_bf16x8_add_f32_f32x4(u16x8 a, u16x8 b, f32x4 c) {
+  return __builtin_wasm_relaxed_dot_bf16x8_add_f32_f32x4(a, b, c);
+  // WEBASSEMBLY: call <4 x float> @llvm.wasm.relaxed.dot.bf16x8.add.f32
+  // WEBASSEMBLY-SAME: <8 x i16> %a, <8 x i16> %b, <4 x float> %c)
+  // WEBASSEMBLY-NEXT: ret
+}
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -18870,6 +18870,14 @@
 CGM.getIntrinsic(Intrinsic::wasm_dot_i8x16_i7x16_add_signed);
 return Builder.CreateCall(Callee, {LHS, RHS, Acc});
   }
+  case WebAssembly::BI__builtin_wasm_relaxed_dot_bf16x8_add_f32_f32x4: {
+Value *LHS = EmitScalarExpr(E->getArg(0));
+Value *RHS = EmitScalarExpr(E->getArg(1));
+Value *Acc = EmitScalarExpr(E->getArg(2));
+Function *Callee =
+CGM.getIntrinsic(Intrinsic::wasm_relaxed_dot_bf16x8_add_f32);
+return Builder.CreateCall(Callee, {LHS, RHS, Acc});
+  }
   default:
 return nullptr;
   }
Index: clang/include/clang/Basic/BuiltinsWebAssembly.def
=

[clang] ac3b8df - [WebAssembly] Prototype `f32x4.relaxed_dot_bf16x8_add_f32`

[Thomas Lively via cfe-commits]

Author: Thomas Lively
Date: 2022-09-08T08:07:49-07:00
New Revision: ac3b8df8f2f433193827b8c0396ba8d41d1af565

URL: 
https://github.com/llvm/llvm-project/commit/ac3b8df8f2f433193827b8c0396ba8d41d1af565
DIFF: 
https://github.com/llvm/llvm-project/commit/ac3b8df8f2f433193827b8c0396ba8d41d1af565.diff

LOG: [WebAssembly] Prototype `f32x4.relaxed_dot_bf16x8_add_f32`

As proposed in https://github.com/WebAssembly/relaxed-simd/issues/77. Only an
LLVM intrinsic and a clang builtin are implemented. Since there is no bfloat16
type, use u16 to represent the bfloats in the builtin function arguments.

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

Added: 


Modified: 
clang/include/clang/Basic/BuiltinsWebAssembly.def
clang/lib/CodeGen/CGBuiltin.cpp
clang/test/CodeGen/builtins-wasm.c
llvm/include/llvm/IR/IntrinsicsWebAssembly.td
llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
llvm/test/CodeGen/WebAssembly/simd-intrinsics.ll

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsWebAssembly.def 
b/clang/include/clang/Basic/BuiltinsWebAssembly.def
index 03c6162f62e3..723645ca606a 100644
--- a/clang/include/clang/Basic/BuiltinsWebAssembly.def
+++ b/clang/include/clang/Basic/BuiltinsWebAssembly.def
@@ -188,6 +188,7 @@ TARGET_BUILTIN(__builtin_wasm_relaxed_q15mulr_s_i16x8, 
"V8sV8sV8s", "nc", "relax
 
 TARGET_BUILTIN(__builtin_wasm_dot_i8x16_i7x16_s_i16x8, "V8sV16ScV16Sc", "nc", 
"relaxed-simd")
 TARGET_BUILTIN(__builtin_wasm_dot_i8x16_i7x16_add_s_i32x4, "V4iV16ScV16ScV4i", 
"nc", "relaxed-simd")
+TARGET_BUILTIN(__builtin_wasm_relaxed_dot_bf16x8_add_f32_f32x4, 
"V4fV8UsV8UsV4f", "nc", "relaxed-simd")
 
 #undef BUILTIN
 #undef TARGET_BUILTIN

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 5af3811988e1..fff94678a684 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -18870,6 +18870,14 @@ Value 
*CodeGenFunction::EmitWebAssemblyBuiltinExpr(unsigned BuiltinID,
 CGM.getIntrinsic(Intrinsic::wasm_dot_i8x16_i7x16_add_signed);
 return Builder.CreateCall(Callee, {LHS, RHS, Acc});
   }
+  case WebAssembly::BI__builtin_wasm_relaxed_dot_bf16x8_add_f32_f32x4: {
+Value *LHS = EmitScalarExpr(E->getArg(0));
+Value *RHS = EmitScalarExpr(E->getArg(1));
+Value *Acc = EmitScalarExpr(E->getArg(2));
+Function *Callee =
+CGM.getIntrinsic(Intrinsic::wasm_relaxed_dot_bf16x8_add_f32);
+return Builder.CreateCall(Callee, {LHS, RHS, Acc});
+  }
   default:
 return nullptr;
   }

diff  --git a/clang/test/CodeGen/builtins-wasm.c 
b/clang/test/CodeGen/builtins-wasm.c
index ea591a195cad..9d742e7c7e29 100644
--- a/clang/test/CodeGen/builtins-wasm.c
+++ b/clang/test/CodeGen/builtins-wasm.c
@@ -794,3 +794,10 @@ i32x4 dot_i8x16_i7x16_add_s_i32x4(i8x16 a, i8x16 b, i32x4 
c) {
   // WEBASSEMBLY-SAME: <16 x i8> %a, <16 x i8> %b, <4 x i32> %c)
   // WEBASSEMBLY-NEXT: ret
 }
+
+f32x4 relaxed_dot_bf16x8_add_f32_f32x4(u16x8 a, u16x8 b, f32x4 c) {
+  return __builtin_wasm_relaxed_dot_bf16x8_add_f32_f32x4(a, b, c);
+  // WEBASSEMBLY: call <4 x float> @llvm.wasm.relaxed.dot.bf16x8.add.f32
+  // WEBASSEMBLY-SAME: <8 x i16> %a, <8 x i16> %b, <4 x float> %c)
+  // WEBASSEMBLY-NEXT: ret
+}

diff  --git a/llvm/include/llvm/IR/IntrinsicsWebAssembly.td 
b/llvm/include/llvm/IR/IntrinsicsWebAssembly.td
index f313be1b2235..7c678ee63b89 100644
--- a/llvm/include/llvm/IR/IntrinsicsWebAssembly.td
+++ b/llvm/include/llvm/IR/IntrinsicsWebAssembly.td
@@ -285,6 +285,12 @@ def int_wasm_dot_i8x16_i7x16_add_signed:
 [llvm_v16i8_ty, llvm_v16i8_ty, llvm_v4i32_ty],
 [IntrNoMem, IntrSpeculatable]>;
 
+def int_wasm_relaxed_dot_bf16x8_add_f32:
+  Intrinsic<[llvm_v4f32_ty],
+[llvm_v8i16_ty, llvm_v8i16_ty, llvm_v4f32_ty],
+[IntrNoMem, IntrSpeculatable]>;
+
+
 
//===--===//
 // Thread-local storage intrinsics
 
//===--===//

diff  --git a/llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td 
b/llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
index 14202a8e1924..36393aea293c 100644
--- a/llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
+++ b/llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
@@ -1466,3 +1466,15 @@ defm RELAXED_DOT_ADD :
(v16i8 V128:$lhs), (v16i8 V128:$rhs), (v4i32 V128:$acc)))],
 "i32x4.dot_i8x16_i7x16_add_s\t$dst, $lhs, $rhs, $acc",
 "i32x4.dot_i8x16_i7x16_add_s", 0x113>;
+
+//===--===//
+// Relaxed BFloat16 dot product
+//===--===//
+
+defm RELAXED_DOT_BFLOAT :
+  RELAXED_I<(outs V128:$dst), (ins V128:$lhs, V128:$rhs, V128:$acc),
+(outs), (ins),
+[(set

[PATCH] D133500: [clang] Correct handling of lambdas in lambda default arguments in dependent contexts.

[Tom Honermann via Phabricator via cfe-commits]

tahonermann created this revision.
tahonermann added reviewers: erichkeane, aaron.ballman, shafik.
Herald added a project: All.
tahonermann requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Previously, a lambda expression in a dependent context with a default argument 
containing an immediately invoked lambda expression would produce a closure 
class object that, if invoked such that the default argument was used, resulted 
in a compiler crash or one of the following assertion failures during code 
generation. The failures occurred regardless of whether the lambda expressions 
were dependent.

  clang/lib/CodeGen/CGCall.cpp:
  Assertion `(isGenericMethod || Ty->isVariablyModifiedType() || 
Ty.getNonReferenceType()->isObjCRetainableType() || getContext() 
.getCanonicalType(Ty.getNonReferenceType()) .getTypePtr() == 
getContext().getCanonicalType((*Arg)->getType()).getTypePtr()) && "type 
mismatch in call argument!"' failed.
  
  clang/lib/AST/Decl.cpp:
  Assertion `!Init->isValueDependent()' failed.

Default arguments in declarations in local context are instantiated along with 
their enclosing function or variable template (since such declarations can't be 
explicitly specialized). Previously, such instantiations were performed at the 
same time that their associated parameters were instantiated. However, that 
approach fails in cases like the following in which the context for the inner 
lambda is the outer lambda, but construction of the outer lambda is dependent 
on the parameters of the inner lambda. This change resolves this dependency by 
delaying instantiation of default arguments in local contexts until after 
construction of the enclosing context.

  template 
  auto f() {
return [](T = []{ return T{}; }()) { return 0; };
  }

Refactoring included with this change results in the same code now being used 
to instantiate default arguments that appear in local context and those that 
are only instantiated when used at a call site; previously, such code was 
duplicated and out of sync.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133500

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/DeclBase.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/default-arguments.cpp
  clang/test/CodeGenCXX/mangle-lambdas-cxx14.cpp
  clang/test/CodeGenCXX/mangle-lambdas-cxx20.cpp
  clang/test/CodeGenCXX/mangle-lambdas.cpp
  clang/test/SemaCXX/vartemplate-lambda.cpp
  clang/test/SemaTemplate/default-arguments.cpp
  clang/test/SemaTemplate/instantiate-local-class.cpp

Index: clang/test/SemaTemplate/instantiate-local-class.cpp
===
--- clang/test/SemaTemplate/instantiate-local-class.cpp
+++ clang/test/SemaTemplate/instantiate-local-class.cpp
@@ -401,7 +401,8 @@
 namespace PR21332 {
   template void f1() {
 struct S {  // expected-note{{in instantiation of member class 'S' requested here}}
-  void g1(int n = T::error);  // expected-error{{type 'int' cannot be used prior to '::' because it has no members}}
+  void g1(int n = T::error);  // expected-error{{type 'int' cannot be used prior to '::' because it has no members}} \
+  // expected-note {{in instantiation of default function argument expression for 'g1' required here}}
 };
   }
   template void f1();  // expected-note{{in instantiation of function template specialization 'PR21332::f1' requested here}}
@@ -438,7 +439,8 @@
 class S {  // expected-note {{in instantiation of member function 'PR21332::f6()::S::get' requested here}}
   void get() {
 class S2 {  // expected-note {{in instantiation of member class 'S2' requested here}}
-  void g1(int n = T::error);  // expected-error {{type 'int' cannot be used prior to '::' because it has no members}}
+  void g1(int n = T::error);  // expected-error {{type 'int' cannot be used prior to '::' because it has no members}} \
+  // expected-note  {{in instantiation of default function argument expression for 'g1' required here}}
 };
   }
 };
@@ -460,16 +462,18 @@
 
   template  void foo() {
 struct Inner { // expected-note {{in instantiation}}
-  void operator()(T a = "") {} // expected-error {{conversion function from 'const char[1]' to 'rdar23721638::A' invokes a deleted function}}
-  // expected-note@-1 {{passing argument to parameter 'a' here}}
+  void operator()(T a = "") {} // expected-error {{conversion function from 'const char[1]' to 'rdar23721638::A' invokes a deleted function}} \
+   // expected-note  {{in instantiation of default function argument expression for 'operator()' required here}} \
+   // expected-note  {{passing argument to parameter 'a' here}}
 };

[PATCH] D133499: [clang]: Add DeclContext::dumpDecl() in order to conveniently dump an AST from a DeclContext.

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/lib/AST/ASTDumper.cpp:205
+  if (const Decl *D = dyn_cast(this))
+D->dump();
+}

One thing to note is that the 'else' case here is a little uninformative.  See 
https://clang.llvm.org/doxygen/DeclBase_8cpp_source.html#l00915 for some 
similar logic here (though not sure we should be emulating that).

More, I wonder if there is SOME message here that should be dumped for 'else'.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133499

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

[PATCH] D127695: WIP: clang: Implement Template Specialization Resugaring

[Matheus Izvekov via Phabricator via cfe-commits]

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



Comment at: clang/lib/Sema/SemaTemplate.cpp:534-540
+  QualType TransformSubstTemplateTypeParmType(TypeLocBuilder &TLB,
+  SubstTemplateTypeParmTypeLoc TL) 
{
+QualType QT = TL.getType();
+const SubstTemplateTypeParmType *T = TL.getTypePtr();
+Decl *ReplacedDecl = T->getReplacedDecl();
+
+Optional PackIndex = T->getPackIndex();

davrec wrote:
> davrec wrote:
> > Haven't thought this through fully, but: would the following make D128113 
> > (storing the pack index in the STTPT or introducing a new sugar type) 
> > unnecessary?
> > ```
> > map, Optional> CurPackIndices;
> > QualType TransformSubstTemplateTypeParmType(TypeLocBuilder &TLB,
> >   SubstTemplateTypeParmTypeLoc 
> > TL) {
> >QualType QT = TL.getType();
> >const SubstTemplateTypeParmType *T = TL.getTypePtr();
> >Decl *ReplacedDecl = T->getReplacedDecl();
> >
> >Optional &PackIndex = CurPackIndices[{ReplacedDecl, 
> > T->getIndex()}];
> >if (!PackIndex && T->getReplacedParameter()->isParameterPack())
> >  PackIndex = 0;
> > 
> >...
> > 
> >if (PackIndex)
> >  ++PackIndex;
> >  // ^ maybe reset to zero if > pack size, if we might be resugaring 
> > multiple expansions
> >return QT;
> > }
> > ```
> Disregard above - upon further thought this does not improve the things; 
> there still isn't enough info about the substitutions.  I.e. the issue is 
> with substitutions, not the parameter declarations for which they are 
> substituted.  So a sugar node wrapping the STTPTs to represent each expansion 
> instance really is needed.  Then when we have that I think we could map from 
> those to their current pack indices per the above to infer the pack indices.
> 
> For this sugar node, maybe we could just modify 
> `SubstTemplateTypeParmPackType` so it is not just canonical, but can also be 
> sugar wrapping substituted STTPTs, as opposed to introducing a new Subst* 
> type class?
I will reply to this on https://reviews.llvm.org/D128113.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127695

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

[PATCH] D133500: [clang] Correct handling of lambdas in lambda default arguments in dependent contexts.

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

Patch seems sound, just a nit that we don't need a bunch of the asserts here, 
since the 'get' function already asserts it looks.  I'd like others to take a 
look too, but this looks acceptable to me.




Comment at: clang/lib/Sema/SemaTemplateInstantiate.cpp:1157
+  continue;
+assert(PVD->hasUninstantiatedDefaultArg());
+Expr *UninstExpr = PVD->getUninstantiatedDefaultArg();

This assert is unncessary, the line below will assert.  Same with the similar 
'assert' later on.



Comment at: clang/lib/Sema/SemaTemplateInstantiate.cpp:1159
+Expr *UninstExpr = PVD->getUninstantiatedDefaultArg();
+// FIXME: Obtain the source location for the '=' token.
+SourceLocation EqualLoc = UninstExpr->getBeginLoc();

Looks like we don't store the equals-token location, so any attempt here 
probably would have to have ParmVarDecl store this location somewhere?



Comment at: clang/lib/Sema/SemaTemplateInstantiate.cpp:2545
+bool ForCallExpr) {
+  assert(Param->hasUninstantiatedDefaultArg());
+

Here too.



Comment at: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:2303
+// that downstream diagnostics are omitted.
+assert(PVD->hasUninstantiatedDefaultArg());
+Expr *UninstExpr = PVD->getUninstantiatedDefaultArg();

See above.



Comment at: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:2705
+// that downstream diagnostics are omitted.
+assert(Params[P]->hasUninstantiatedDefaultArg());
+Expr *UninstExpr = Params[P]->getUninstantiatedDefaultArg();

And again.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133500

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

[PATCH] D128113: WIP: Clang: fix AST representation of expanded template arguments.

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

@davrec  @alexfh

I finally managed to have a talk to @rsmith about this.

He thinks that, even if we can't come up with a better solution in time, the 
benefits of this patch justify the costs observed, as those substitution nodes 
are pretty useless without a way to index the pack, and having a rich AST is 
one of Clang's main goals.

But he also came up with this nifty idea that this high cost is perhaps coming 
because we are reindexing the whole pack every time that repro recurses on that 
disjunction and we consume the first element in the deduction.
And that a good solution for this might be to just index the pack backwards, so 
that 0 is the last element.

I will try that sometime soon. Even if I don't see an improvement, any further 
objections we just re-merge this?

PS: That does not disregard the other ideas to further improve this in the 
future. Another thing he noted that would be important is to also be able to 
represent in the resulting AST a pack that expanded 0 times.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128113

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

[PATCH] D133500: [clang] Correct handling of lambdas in lambda default arguments in dependent contexts.

[Tom Honermann via Phabricator via cfe-commits]

tahonermann added inline comments.



Comment at: clang/lib/Sema/SemaTemplateInstantiate.cpp:2460-2475
-FunctionDecl *OwningFunc = cast(OldParm->getDeclContext());
-if (OwningFunc->isInLocalScopeForInstantiation()) {
-  // Instantiate default arguments for methods of local classes (DR1484)
-  // and non-defining declarations.
-  Sema::ContextRAII SavedContext(*this, OwningFunc);
-  LocalInstantiationScope Local(*this, true);
-  ExprResult NewArg = SubstExpr(Arg, TemplateArgs);

This functionality is now incorporated into `Sema::SubstDefaultArguments()` and 
postponed until after construction of enclosing declaration contexts.



Comment at: clang/lib/Sema/SemaTemplateInstantiate.cpp:2592-2613
+  if (ForCallExpr) {
+// Check the expression as an initializer for the parameter.
+InitializedEntity Entity
+  = InitializedEntity::InitializeParameter(Context, Param);
+InitializationKind Kind = InitializationKind::CreateCopy(
+Param->getLocation(),
+/*FIXME:EqualLoc*/ PatternExpr->getBeginLoc());

I find this code exceedingly troubling, but I haven't been able to figure out 
how to unify it. Conceptually, instantiation of a default argument should 
produce the same result (the instantiated default argument is cached after 
all!) whether it is implicitly always instantiated (as in a declaration in 
local scope or a friend function definition) or instantiated on demand for a 
call expression. However, my attempts to unify this code have all resulted in 
test failures that I have, so far, been unable to explain. Note that much of 
the code in the `ForCallExpr` case is replicated in the 
`ConvertParamDefaultArgument()` function. I think this should be investigated 
further and may be a reason to postpone approving this change.



Comment at: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:2138
+  else if (D->isLocalExternDecl()) {
+LexicalDC = SemaRef.CurContext;
+  }

This seems highly questionable to me. I suspect there is a better way to 
identify the correct context, but I have not so far found it elsewhere. Note 
that the context needed is for the enclosing function template specialization 
(not the enclosing template).



Comment at: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:2296-2311
+for (ParmVarDecl *PVD : Function->parameters()) {
+  if (!PVD->hasDefaultArg())
+continue;
+  if (SemaRef.SubstDefaultArgument(D->getInnerLocStart(), PVD, 
TemplateArgs)) {
+// If substitution fails, the default argument is set to a
+// RecoveryExpr that wraps the uninstantiated default argument so
+// that downstream diagnostics are omitted.

This code is effectively replicated in three distinct locations. It is probably 
worth moving it into a helper function somewhere.



Comment at: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:4565
-  /*DiscardedValue*/ false);
-  if (Result.isInvalid())
 return true;

The above removed code has been incorporated into 
`Sema::SubstDefaultArgument()`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133500

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

[clang-tools-extra] e09c750 - [clangd][ObjC] Improve completions for protocols + category names

[David Goldman via cfe-commits]

Author: David Goldman
Date: 2022-09-08T11:30:26-04:00
New Revision: e09c75049854fee251e99c4c3c55f3f391f52a10

URL: 
https://github.com/llvm/llvm-project/commit/e09c75049854fee251e99c4c3c55f3f391f52a10
DIFF: 
https://github.com/llvm/llvm-project/commit/e09c75049854fee251e99c4c3c55f3f391f52a10.diff

LOG: [clangd][ObjC] Improve completions for protocols + category names

- Render protocols as interfaces to differentiate them from classes
  since a protocol and class can have the same name. Take this one step
  further though, and only recommend protocols in ObjC protocol completions.

- Properly call `includeSymbolFromIndex` even with a cached
  speculative fuzzy find request

- Don't use the index to provide completions for category names,
  symbols there don't make sense

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

Added: 


Modified: 
clang-tools-extra/clangd/CodeComplete.cpp
clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
clang-tools-extra/clangd/unittests/TestIndex.cpp
clang-tools-extra/clangd/unittests/TestIndex.h

Removed: 




diff  --git a/clang-tools-extra/clangd/CodeComplete.cpp 
b/clang-tools-extra/clangd/CodeComplete.cpp
index f10235894190..9d9b0e748153 100644
--- a/clang-tools-extra/clangd/CodeComplete.cpp
+++ b/clang-tools-extra/clangd/CodeComplete.cpp
@@ -94,10 +94,14 @@ CompletionItemKind toCompletionItemKind(index::SymbolKind 
Kind) {
   case SK::Struct:
 return CompletionItemKind::Struct;
   case SK::Class:
-  case SK::Protocol:
   case SK::Extension:
   case SK::Union:
 return CompletionItemKind::Class;
+  case SK::Protocol:
+// Use interface instead of class for 
diff erentiation of classes and
+// protocols with the same name (e.g. @interface NSObject vs. @protocol
+// NSObject).
+return CompletionItemKind::Interface;
   case SK::TypeAlias:
 // We use the same kind as the VSCode C++ extension.
 // FIXME: pick a better option when we have one.
@@ -712,13 +716,13 @@ bool contextAllowsIndex(enum CodeCompletionContext::Kind 
K) {
   case CodeCompletionContext::CCC_Type:
   case CodeCompletionContext::CCC_ParenthesizedExpression:
   case CodeCompletionContext::CCC_ObjCInterfaceName:
-  case CodeCompletionContext::CCC_ObjCCategoryName:
   case CodeCompletionContext::CCC_Symbol:
   case CodeCompletionContext::CCC_SymbolOrNewName:
 return true;
   case CodeCompletionContext::CCC_OtherWithMacros:
   case CodeCompletionContext::CCC_DotMemberAccess:
   case CodeCompletionContext::CCC_ArrowMemberAccess:
+  case CodeCompletionContext::CCC_ObjCCategoryName:
   case CodeCompletionContext::CCC_ObjCPropertyAccess:
   case CodeCompletionContext::CCC_MacroName:
   case CodeCompletionContext::CCC_MacroNameUse:
@@ -1343,6 +1347,22 @@ bool allowIndex(CodeCompletionContext &CC) {
   llvm_unreachable("invalid NestedNameSpecifier kind");
 }
 
+// Should we include a symbol from the index given the completion kind?
+// FIXME: Ideally we can filter in the fuzzy find request itself.
+bool includeSymbolFromIndex(CodeCompletionContext::Kind Kind,
+const Symbol &Sym) {
+  // Objective-C protocols are only useful in ObjC protocol completions,
+  // in other places they're confusing, especially when they share the same
+  // identifier with a class.
+  if (Sym.SymInfo.Kind == index::SymbolKind::Protocol &&
+  Sym.SymInfo.Lang == index::SymbolLanguage::ObjC)
+return Kind == CodeCompletionContext::CCC_ObjCProtocolName;
+  else if (Kind == CodeCompletionContext::CCC_ObjCProtocolName)
+// Don't show anything else in ObjC protocol completions.
+return false;
+  return true;
+}
+
 std::future startAsyncFuzzyFind(const SymbolIndex &Index,
 const FuzzyFindRequest &Req) {
   return runAsync([&Index, Req]() {
@@ -1675,14 +1695,6 @@ class CodeCompleteFlow {
 return Output;
   }
 
-  bool includeSymbolFromIndex(const Symbol &Sym) {
-if (CCContextKind == CodeCompletionContext::CCC_ObjCProtocolName) {
-  return Sym.SymInfo.Lang == index::SymbolLanguage::ObjC &&
-  Sym.SymInfo.Kind == index::SymbolKind::Protocol;
-}
-return true;
-  }
-
   SymbolSlab queryIndex() {
 trace::Span Tracer("Query index");
 SPAN_ATTACH(Tracer, "limit", int64_t(Opts.Limit));
@@ -1716,11 +1728,8 @@ class CodeCompleteFlow {
 
 // Run the query against the index.
 SymbolSlab::Builder ResultsBuilder;
-if (Opts.Index->fuzzyFind(Req, [&](const Symbol &Sym) {
-  if (includeSymbolFromIndex(Sym))
-ResultsBuilder.insert(Sym);
-}))
-  Incomplete = true;
+Incomplete |= Opts.Index->fuzzyFind(
+Req, [&](const Symbol &Sym) { ResultsBuilder.insert(Sym); });
 return std::move(ResultsBuilder).build();
   }
 
@@ -1783,6 +1792,8 @@ class CodeCompleteFlow {
 for (const auto &IndexResult : IndexResults) {
   if (UsedIndexResults.co

[PATCH] D132962: [clangd][ObjC] Improve completions for protocols + category names

[David Goldman via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
dgoldman marked an inline comment as done.
Closed by commit rGe09c75049854: [clangd][ObjC] Improve completions for 
protocols + category names (authored by dgoldman).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132962

Files:
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang-tools-extra/clangd/unittests/TestIndex.cpp
  clang-tools-extra/clangd/unittests/TestIndex.h

Index: clang-tools-extra/clangd/unittests/TestIndex.h
===
--- clang-tools-extra/clangd/unittests/TestIndex.h
+++ clang-tools-extra/clangd/unittests/TestIndex.h
@@ -39,6 +39,8 @@
llvm::StringRef USRPrefix);
 // Create an @interface or @implementation.
 Symbol objcClass(llvm::StringRef Name);
+// Create an @interface or @implementation category.
+Symbol objcCategory(llvm::StringRef Name, llvm::StringRef CategoryName);
 // Create an @protocol.
 Symbol objcProtocol(llvm::StringRef Name);
 
Index: clang-tools-extra/clangd/unittests/TestIndex.cpp
===
--- clang-tools-extra/clangd/unittests/TestIndex.cpp
+++ clang-tools-extra/clangd/unittests/TestIndex.cpp
@@ -99,6 +99,11 @@
   return objcSym(Name, index::SymbolKind::Class, "objc(cs)");
 }
 
+Symbol objcCategory(llvm::StringRef Name, llvm::StringRef CategoryName) {
+  std::string USRPrefix = ("objc(cy)" + Name + "@").str();
+  return objcSym(CategoryName, index::SymbolKind::Extension, USRPrefix);
+}
+
 Symbol objcProtocol(llvm::StringRef Name) {
   return objcSym(Name, index::SymbolKind::Protocol, "objc(pl)");
 }
Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -1493,12 +1493,16 @@
 
 class IndexRequestCollector : public SymbolIndex {
 public:
+  IndexRequestCollector(std::vector Syms = {}) : Symbols(Syms) {}
+
   bool
   fuzzyFind(const FuzzyFindRequest &Req,
 llvm::function_ref Callback) const override {
 std::unique_lock Lock(Mut);
 Requests.push_back(Req);
 ReceivedRequestCV.notify_one();
+for (const auto &Sym : Symbols)
+  Callback(Sym);
 return true;
   }
 
@@ -1533,6 +1537,7 @@
   }
 
 private:
+  std::vector Symbols;
   // We need a mutex to handle async fuzzy find requests.
   mutable std::condition_variable ReceivedRequestCV;
   mutable std::mutex Mut;
@@ -3208,14 +3213,74 @@
   Symbol FoodClass = objcClass("FoodClass");
   Symbol SymFood = objcProtocol("Food");
   Symbol SymFooey = objcProtocol("Fooey");
+  auto Results = completions("id", {SymFood, FoodClass, SymFooey},
+ /*Opts=*/{}, "Foo.m");
+
+  // Should only give protocols for ObjC protocol completions.
+  EXPECT_THAT(Results.Completions,
+  UnorderedElementsAre(
+  AllOf(named("Food"), kind(CompletionItemKind::Interface)),
+  AllOf(named("Fooey"), kind(CompletionItemKind::Interface;
+
+  Results = completions("Fo^", {SymFood, FoodClass, SymFooey},
+/*Opts=*/{}, "Foo.m");
+  // Shouldn't give protocols for non protocol completions.
+  EXPECT_THAT(
+  Results.Completions,
+  ElementsAre(AllOf(named("FoodClass"), kind(CompletionItemKind::Class;
+}
+
+TEST(CompletionTest, ObjectiveCProtocolFromIndexSpeculation) {
+  MockFS FS;
+  MockCompilationDatabase CDB;
+  ClangdServer Server(CDB, FS, ClangdServer::optsForTest());
+
+  auto File = testPath("Foo.m");
+  Annotations Test(R"cpp(
+  @protocol Food
+  @end
+  id foo;
+  Foo$2^ bar;
+  )cpp");
+  runAddDocument(Server, File, Test.code());
+  clangd::CodeCompleteOptions Opts = {};
+
+  Symbol FoodClass = objcClass("FoodClass");
+  IndexRequestCollector Requests({FoodClass});
+  Opts.Index = &Requests;
+
+  auto CompleteAtPoint = [&](StringRef P) {
+return cantFail(runCodeComplete(Server, File, Test.point(P), Opts))
+.Completions;
+  };
+
+  auto C = CompleteAtPoint("1");
+  auto Reqs1 = Requests.consumeRequests(1);
+  ASSERT_EQ(Reqs1.size(), 1u);
+  EXPECT_THAT(C, ElementsAre(AllOf(named("Food"),
+   kind(CompletionItemKind::Interface;
+
+  C = CompleteAtPoint("2");
+  auto Reqs2 = Requests.consumeRequests(1);
+  // Speculation succeeded. Used speculative index result, but filtering now to
+  // now include FoodClass.
+  ASSERT_EQ(Reqs2.size(), 1u);
+  EXPECT_EQ(Reqs2[0], Reqs1[0]);
+  EXPECT_THAT(C, ElementsAre(AllOf(named("FoodClass"),
+   kind(CompletionItemKind::Class;
+}
+
+TEST(CompletionTest, ObjectiveCCategoryFromIndexIgnored) {
+  Symbol FoodCategory = objcCategory("FoodCl

[PATCH] D133202: [Clang] Avoid __builtin_assume_aligned crash when the 1st arg is array type

[Lin Yurong via Phabricator via cfe-commits]

yronglin added a comment.

Seems that a builtin can't be redeclared which has custom type checking
https://github.com/llvm/llvm-project/blob/ec8f2905a33ba970543c8edb4141c47f30d325f7/clang/lib/Basic/Builtins.cpp#L210-L214


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133202

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

[clang] de0e311 - [SystemZ] Improve handling of vector alignments.

[Jonas Paulsson via cfe-commits]

Author: Jonas Paulsson
Date: 2022-09-08T17:33:05+02:00
New Revision: de0e3117d40af95993b11d0622f9700415552d48

URL: 
https://github.com/llvm/llvm-project/commit/de0e3117d40af95993b11d0622f9700415552d48
DIFF: 
https://github.com/llvm/llvm-project/commit/de0e3117d40af95993b11d0622f9700415552d48.diff

LOG: [SystemZ] Improve handling of vector alignments.

Make the DataLayout string always hold a vector alignment of 8 bytes,
regardless of the vector ABI. This makes the datalayout depend only on the
target triple which is the general expectation (in assertions).

On older architectures where vectors use the natural alignment (16 bytes),
the front end will maintain the same behavior and produce an overalignment
compared to the datalayout.

Reviewed By: uweigand

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

Added: 
clang/test/CodeGen/SystemZ/align-systemz-02.c

Modified: 
clang/lib/Basic/Targets/SystemZ.h
clang/test/CodeGen/target-data.c
llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
llvm/test/CodeGen/SystemZ/function-attributes-01.ll
llvm/test/CodeGen/SystemZ/vec-abi-align.ll

Removed: 




diff  --git a/clang/lib/Basic/Targets/SystemZ.h 
b/clang/lib/Basic/Targets/SystemZ.h
index 7def024d07a7..371eb2516378 100644
--- a/clang/lib/Basic/Targets/SystemZ.h
+++ b/clang/lib/Basic/Targets/SystemZ.h
@@ -51,13 +51,13 @@ class LLVM_LIBRARY_VISIBILITY SystemZTargetInfo : public 
TargetInfo {
   // All vector types are default aligned on an 8-byte boundary, even if 
the
   // vector facility is not available. That is 
diff erent from Linux.
   MaxVectorAlign = 64;
-  // Compared to Linux/ELF, the data layout 
diff ers only in some details:
-  // - name mangling is GOFF
-  // - 128 bit vector types are 64 bit aligned
+  // Compared to Linux/ELF, the data layout 
diff ers only in that name
+  // mangling is GOFF.
   resetDataLayout(
   "E-m:l-i1:8:16-i8:8:16-i64:64-f128:64-v128:64-a:8:16-n32:64");
 } else
-  resetDataLayout("E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-a:8:16-n32:64");
+  resetDataLayout("E-m:e-i1:8:16-i8:8:16-i64:64-f128:64"
+  "-v128:64-a:8:16-n32:64");
 MaxAtomicPromoteWidth = MaxAtomicInlineWidth = 64;
 HasStrictFP = true;
   }
@@ -171,12 +171,14 @@ class LLVM_LIBRARY_VISIBILITY SystemZTargetInfo : public 
TargetInfo {
 }
 HasVector &= !SoftFloat;
 
-// If we use the vector ABI, vector types are 64-bit aligned.
-if (HasVector && !getTriple().isOSzOS()) {
+// If we use the vector ABI, vector types are 64-bit aligned. The
+// DataLayout string is always set to this alignment as it is not a
+// requirement that it follows the alignment emitted by the front end. It
+// is assumed generally that the Datalayout should reflect only the
+// target triple and not any specific feature.
+if (HasVector && !getTriple().isOSzOS())
   MaxVectorAlign = 64;
-  resetDataLayout("E-m:e-i1:8:16-i8:8:16-i64:64-f128:64"
-  "-v128:64-a:8:16-n32:64");
-}
+
 return true;
   }
 

diff  --git a/clang/test/CodeGen/SystemZ/align-systemz-02.c 
b/clang/test/CodeGen/SystemZ/align-systemz-02.c
new file mode 100644
index ..cc09a9093741
--- /dev/null
+++ b/clang/test/CodeGen/SystemZ/align-systemz-02.c
@@ -0,0 +1,68 @@
+// RUN: %clang_cc1 -triple s390x-linux-gnu %s -o - -target-feature +vector 
-emit-llvm \
+// RUN:| FileCheck %s -check-prefix=VECIR
+// RUN: %clang_cc1 -triple s390x-linux-gnu %s -o - -target-feature +vector 
-emit-obj -S \
+// RUN:| FileCheck %s -check-prefix=VECASM
+// RUN: %clang_cc1 -triple s390x-linux-gnu %s -o - -target-feature -vector 
-emit-llvm \
+// RUN:| FileCheck %s -check-prefix=SCALIR
+// RUN: %clang_cc1 -triple s390x-linux-gnu %s -o - -target-feature -vector 
-emit-obj -S \
+// RUN:| FileCheck %s -check-prefix=SCALASM
+
+typedef __attribute__((vector_size(16))) signed int vec_sint;
+
+volatile vec_sint GlobVsi;
+
+struct S {
+  int A;
+  vec_sint Vsi;
+} GlobS;
+
+void fun() {
+  GlobS.Vsi = GlobVsi;
+}
+
+// VECIR: %struct.S = type { i32, <4 x i32> }
+// VECIR: @GlobVsi = global <4 x i32> zeroinitializer, align 8
+// VECIR: @GlobS = global %struct.S zeroinitializer, align 8
+// VECIR: %0 = load volatile <4 x i32>, ptr @GlobVsi, align 8
+// VECIR: store <4 x i32> %0, ptr getelementptr inbounds (%struct.S, ptr 
@GlobS, i32 0, i32 1), align 8
+
+// VECASM:  lgrl %r1, GlobVsi@GOT
+// VECASM-NEXT: vl   %v0, 0(%r1), 3
+// VECASM-NEXT: lgrl %r1, GlobS@GOT
+// VECASM-NEXT: vst  %v0, 8(%r1), 3
+//
+// VECASM:   .globl  GlobVsi
+// VECASM:   .p2align3
+// VECASM: GlobVsi:
+// VECASM:   .space  16
+// VECASM:   .globl  GlobS
+// VECASM:   .p2align3
+// VECASM: GlobS:
+// VECASM:   .space  24
+
+// SCALIR: %struct.S = type { i32, [12 x i8], <4 x i32> }
+// SCALIR: @GlobVsi = global <4 x i32> zeroinitializ

[PATCH] D131158: [SystemZ] Improve handling of vector alignments

[Jonas Paulsson via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGde0e3117d40a: [SystemZ] Improve handling of vector 
alignments. (authored by jonpa).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131158

Files:
  clang/lib/Basic/Targets/SystemZ.h
  clang/test/CodeGen/SystemZ/align-systemz-02.c
  clang/test/CodeGen/target-data.c
  llvm/lib/Target/SystemZ/SystemZTargetMachine.cpp
  llvm/test/CodeGen/SystemZ/function-attributes-01.ll
  llvm/test/CodeGen/SystemZ/vec-abi-align.ll

Index: llvm/test/CodeGen/SystemZ/vec-abi-align.ll
===
--- llvm/test/CodeGen/SystemZ/vec-abi-align.ll
+++ llvm/test/CodeGen/SystemZ/vec-abi-align.ll
@@ -1,55 +1,73 @@
-; Verify that we use the vector ABI datalayout if and only if
-; the vector facility is present.
+; Verify that a struct as generated by the frontend is correctly accessed in
+; both cases of enabling/disabling the vector facility.
 ;
 ; RUN: llc < %s -mtriple=s390x-linux-gnu | \
-; RUN:   FileCheck -check-prefix=CHECK-NOVECTOR %s
+; RUN:   FileCheck -check-prefixes=CHECK,CHECK-NOVECTOR %s
 ; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=generic | \
-; RUN:   FileCheck -check-prefix=CHECK-NOVECTOR %s
+; RUN:   FileCheck -check-prefixes=CHECK,CHECK-NOVECTOR %s
 ; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z10 | \
-; RUN:   FileCheck -check-prefix=CHECK-NOVECTOR %s
+; RUN:   FileCheck -check-prefixes=CHECK,CHECK-NOVECTOR %s
 ; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z196 | \
-; RUN:   FileCheck -check-prefix=CHECK-NOVECTOR %s
+; RUN:   FileCheck -check-prefixes=CHECK,CHECK-NOVECTOR %s
 ; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=zEC12 | \
-; RUN:   FileCheck -check-prefix=CHECK-NOVECTOR %s
+; RUN:   FileCheck -check-prefixes=CHECK,CHECK-NOVECTOR %s
 ; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z13 | \
-; RUN:   FileCheck -check-prefix=CHECK-VECTOR %s
+; RUN:   FileCheck -check-prefixes=CHECK,CHECK-VECTOR %s
 
 ; RUN: llc < %s -mtriple=s390x-linux-gnu -mattr=vector | \
-; RUN:   FileCheck -check-prefix=CHECK-VECTOR %s
+; RUN:   FileCheck -check-prefixes=CHECK,CHECK-VECTOR %s
 ; RUN: llc < %s -mtriple=s390x-linux-gnu -mattr=+vector | \
-; RUN:   FileCheck -check-prefix=CHECK-VECTOR %s
+; RUN:   FileCheck -check-prefixes=CHECK,CHECK-VECTOR %s
 ; RUN: llc < %s -mtriple=s390x-linux-gnu -mattr=-vector,vector | \
-; RUN:   FileCheck -check-prefix=CHECK-VECTOR %s
+; RUN:   FileCheck -check-prefixes=CHECK,CHECK-VECTOR %s
 ; RUN: llc < %s -mtriple=s390x-linux-gnu -mattr=-vector,+vector | \
-; RUN:   FileCheck -check-prefix=CHECK-VECTOR %s
+; RUN:   FileCheck -check-prefixes=CHECK,CHECK-VECTOR %s
 ; RUN: llc < %s -mtriple=s390x-linux-gnu -mattr=-vector | \
-; RUN:   FileCheck -check-prefix=CHECK-NOVECTOR %s
+; RUN:   FileCheck -check-prefixes=CHECK,CHECK-NOVECTOR %s
 ; RUN: llc < %s -mtriple=s390x-linux-gnu -mattr=vector,-vector | \
-; RUN:   FileCheck -check-prefix=CHECK-NOVECTOR %s
+; RUN:   FileCheck -check-prefixes=CHECK,CHECK-NOVECTOR %s
 ; RUN: llc < %s -mtriple=s390x-linux-gnu -mattr=+vector,-vector | \
-; RUN:   FileCheck -check-prefix=CHECK-NOVECTOR %s
+; RUN:   FileCheck -check-prefixes=CHECK,CHECK-NOVECTOR %s
 
 ; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z13 -mattr=-vector | \
-; RUN:   FileCheck -check-prefix=CHECK-NOVECTOR %s
+; RUN:   FileCheck -check-prefixes=CHECK,CHECK-NOVECTOR %s
 
 ; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z13 -mattr=+soft-float | \
-; RUN:   FileCheck -check-prefix=CHECK-NOVECTOR %s
+; RUN:   FileCheck -check-prefixes=CHECK,CHECK-NOVECTOR %s
 ; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z13 \
 ; RUN:   -mattr=soft-float,-soft-float | \
-; RUN:   FileCheck -check-prefix=CHECK-VECTOR %s
+; RUN:   FileCheck -check-prefixes=CHECK,CHECK-VECTOR %s
 ; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z13 \
 ; RUN:   -mattr=-soft-float,soft-float | \
-; RUN:   FileCheck -check-prefix=CHECK-NOVECTOR %s
+; RUN:   FileCheck -check-prefixes=CHECK,CHECK-NOVECTOR %s
 
-%struct.S = type { i8, <2 x i64> }
+%struct.S_vx = type { i8, <2 x i64> }
+%struct.S_novx = type { i8, [15 x i8], <2 x i64> }
 
-define void @test(%struct.S* %s) nounwind {
-; CHECK-VECTOR-LABEL: @test
+define void @fun_vx(%struct.S_vx* %s) nounwind {
+; CHECK-LABEL: @fun_vx
+;
 ; CHECK-VECTOR: vl %v0, 8(%r2)
-; CHECK-NOVECTOR-LABEL: @test
+; CHECK-VECTOR: vst %v0, 8(%r2), 3
+;
+; CHECK-NOVECTOR-DAG: agsi 16(%r2), 1
+; CHECK-NOVECTOR-DAG: agsi 8(%r2), 1
+  %ptr = getelementptr %struct.S_vx, %struct.S_vx* %s, i64 0, i32 1
+  %vec = load <2 x i64>, <2 x i64>* %ptr
+  %add = add <2 x i64> %vec, 
+  store <2 x i64> %add, <2 x i64>* %ptr
+  ret void
+}
+
+define void @fun_novx(%struct.S_novx* %s) nounwind {
+; CHECK-LABEL: @fun_novx
+;
+; CHECK-VECTOR: vl  %v0, 16(%r2), 3
+; CHECK-VEC

[PATCH] D133479: [clangd] Set Incompleteness for spec fuzzyfind requests

[David Goldman via Phabricator via cfe-commits]

dgoldman added inline comments.



Comment at: clang-tools-extra/clangd/CodeComplete.cpp:1716
+  Incomplete |= SpecRes.first;
+  return std::move(SpecRes.second);
 }

Can this be safely moved - looks like it wasn't before?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133479

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

[PATCH] D133479: [clangd] Set Incompleteness for spec fuzzyfind requests

[David Goldman via Phabricator via cfe-commits]

dgoldman added inline comments.



Comment at: clang-tools-extra/clangd/CodeComplete.cpp:1716
+  Incomplete |= SpecRes.first;
+  return std::move(SpecRes.second);
 }

dgoldman wrote:
> Can this be safely moved - looks like it wasn't before?
Ah nevermind, missed that this is moving the local copy.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133479

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

[PATCH] D132131: [clang-format] Adds a formatter for aligning trailing comments over empty lines

[Yusuke Kadowaki via Phabricator via cfe-commits]

yusuke-kadowaki marked 7 inline comments as done.
yusuke-kadowaki added inline comments.



Comment at: clang/docs/ClangFormatStyleOptions.rst:865
+
+  * ``TCAS_DontAlign`` (in configuration: ``DontAlign``)
+Don't align trailing comments.

HazardyKnusperkeks wrote:
> MyDeveloperDay wrote:
> > yusuke-kadowaki wrote:
> > > MyDeveloperDay wrote:
> > > > Is Don'tAlign the same as Leave that other options support  (for 
> > > > options it best if we try and use the same terminiology
> > > > 
> > > > Always,Never,Leave (if that fits)
> > > IMHO, `Leave` probably fits but `DontAlign`  is more straightforward. 
> > > Also `DontAlign` is used for other alignment styles like 
> > > `BracketAlignmentStyle` so it would be more natural.
> > Leave should mean do nothing.. I'm personally not a fan of DontAlign 
> > because obvious there should be a ' between the n and the t but I see we 
> > use it elsewhere
> > 
> > But actually now I see your DontAlign is effectively the as before (i.e. it 
> > will not add extra spaces) 
> > 
> > The point of Leave is what people have been asking for when we introduce a 
> > new option, that is we if possible add an option which means "Don't touch 
> > it at all"  i.e.  if I want to have
> > 
> > ```
> > int a;   //  abc
> > int b;   /// bcd
> > int c;// cde
> > ```
> > 
> > Then so be it
> > 
> > 
> Leave is a nice option, yes.
> I think it is complementary to `Dont`.
> 
> But maybe if the option is called `AlignTrailingComments` one may interpret 
> `Leave` not as "don't touch the position of a comment at all" (what do we do, 
> if the comment is outside of the column limit?), but as "just don't touch 
> them, when they are somewhat aligned". Just a thought.
> Leave should mean do nothing

Ok now I see what `Leave` means. 
But that should be another piece of work no? 

Of course me or someone can add the feature later (I don't really know how to 
implement that though at least for now) 





Comment at: clang/include/clang/Format/Format.h:373
+  /// Different styles for aligning trailing comments.
+  enum TrailingCommentsAlignmentStyle : int8_t {
+/// Don't align trailing comments.

HazardyKnusperkeks wrote:
> MyDeveloperDay wrote:
> > yusuke-kadowaki wrote:
> > > MyDeveloperDay wrote:
> > > > all options have a life cycle
> > > > 
> > > > bool -> enum -> struct
> > > > 
> > > > One of the thing I ask you before, would we want to align across N 
> > > > empty lines, if ever so they I think
> > > > we should go straight to a struct
> > > > all options have a life cycle
> > > 
> > > I see your point. But we are checking `Style.MaxEmptyLinesToKeep` to 
> > > determine how many consecutive lines to align. So currently no need to 
> > > specify it from the option. You'll find the implementation below.
> > I think its a bad idea to hijack a different option to do this..I don't 
> > think it means the same thing and I think what whilst it might work there 
> > will be someone somewhere who doesn't want it to behave like this and will 
> > call it out as a bug.
> > 
> > 
> Since you are strictly against `Enabled` what to put into a struct?
> Since you are strictly against Enabled what to put into a struct?

@MyDeveloperDay 
Can you answer this? Plus it would be helpful if you just write down what your 
ideal struct be like.

> I don't think it means the same thing

How so? There's no empty lines more than `MaxEmptyLinesToKeep` all the time no?



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132131

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

[clang] 906ea59 - [SystemZ] Fix new test case

[Jonas Paulsson via cfe-commits]

Author: Jonas Paulsson
Date: 2022-09-08T18:05:17+02:00
New Revision: 906ea59d00f0deb9777aa977fdcb589d4736244c

URL: 
https://github.com/llvm/llvm-project/commit/906ea59d00f0deb9777aa977fdcb589d4736244c
DIFF: 
https://github.com/llvm/llvm-project/commit/906ea59d00f0deb9777aa977fdcb589d4736244c.diff

LOG: [SystemZ] Fix new test case

Add 'REQUIRES: systemz-registered-target'.

Added: 


Modified: 
clang/test/CodeGen/SystemZ/align-systemz-02.c

Removed: 




diff  --git a/clang/test/CodeGen/SystemZ/align-systemz-02.c 
b/clang/test/CodeGen/SystemZ/align-systemz-02.c
index cc09a9093741..013faea61ada 100644
--- a/clang/test/CodeGen/SystemZ/align-systemz-02.c
+++ b/clang/test/CodeGen/SystemZ/align-systemz-02.c
@@ -6,6 +6,7 @@
 // RUN:| FileCheck %s -check-prefix=SCALIR
 // RUN: %clang_cc1 -triple s390x-linux-gnu %s -o - -target-feature -vector 
-emit-obj -S \
 // RUN:| FileCheck %s -check-prefix=SCALASM
+// REQUIRES: systemz-registered-target
 
 typedef __attribute__((vector_size(16))) signed int vec_sint;
 



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

[PATCH] D128113: WIP: Clang: fix AST representation of expanded template arguments.

[David Rector via Phabricator via cfe-commits]

davrec added a comment.

In D128113#3777353 , @mizvekov wrote:

> @davrec  @alexfh
>
> I finally managed to have a talk to @rsmith about this.
>
> He thinks that, even if we can't come up with a better solution in time, the 
> benefits of this patch justify the costs observed, as those substitution 
> nodes are pretty useless without a way to index the pack, and having a rich 
> AST is one of Clang's main goals.

I support that - re-merge for now, and consider ways to reduce costs going 
forward.

I thought this through every which way and could not avoid @mizvekov's 
conclusion, that the only other way would be another Subst* type node, from 
which the pack indices could be inferred, but only via non-straightforward code 
requiring a bird's eye view of the AST.

Taking a step back and reconsidering, it's clear the original way - just 
storing the pack index - is very much preferable to all that complexity.  The 
benefits justify the costs for most users, and for clang developers who would 
be burdened by the appearance of an obscure new type class.  And as I said 
previously I think broad flags governing how much sugar/non-semantic info is 
added to the AST, i.e. letting users balance benefits vs. costs for themselves, 
is the better way to handle these concerns.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128113

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

[PATCH] D133339: [clangd] Isolate logic for setting LSPServer options

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet updated this revision to Diff 458769.
kadircet added a comment.

I agree this is creating confusing state for constructors of ClangdLSPServer. It
would be interesting to create LSPServer after the initialize request one day.

- Make client-capability related options private again.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D19

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h

Index: clang-tools-extra/clangd/ClangdLSPServer.h
===
--- clang-tools-extra/clangd/ClangdLSPServer.h
+++ clang-tools-extra/clangd/ClangdLSPServer.h
@@ -77,6 +77,9 @@
   void profile(MemoryTree &MT) const;
 
 private:
+  // Configure server using client capabilities to adjust response types and
+  // request handling.
+  void alignWithClient(const InitializeParams &Params);
   // Implement ClangdServer::Callbacks.
   void onDiagnosticsReady(PathRef File, llvm::StringRef Version,
   std::vector Diagnostics) override;
@@ -250,22 +253,6 @@
   LSPBinder::RawHandlers Handlers;
 
   const ThreadsafeFS &TFS;
-  /// Options used for diagnostics.
-  ClangdDiagnosticOptions DiagOpts;
-  /// The supported kinds of the client.
-  SymbolKindBitset SupportedSymbolKinds;
-  /// The supported completion item kinds of the client.
-  CompletionItemKindBitset SupportedCompletionItemKinds;
-  /// Whether the client supports CodeAction response objects.
-  bool SupportsCodeAction = false;
-  /// From capabilities of textDocument/documentSymbol.
-  bool SupportsHierarchicalDocumentSymbol = false;
-  /// Whether the client supports showing file status.
-  bool SupportFileStatus = false;
-  /// Which kind of markup should we use in textDocument/hover responses.
-  MarkupKind HoverContentFormat = MarkupKind::PlainText;
-  /// Whether the client supports offsets for parameter info labels.
-  bool SupportsOffsetsInSignatureHelp = false;
   std::mutex BackgroundIndexProgressMutex;
   enum class BackgroundIndexProgress {
 // Client doesn't support reporting progress. No transitions possible.
@@ -282,10 +269,28 @@
   // The progress to send when the progress bar is created.
   // Only valid in state Creating.
   BackgroundQueue::Stats PendingBackgroundIndexProgress;
-  /// LSP extension: skip WorkDoneProgressCreate, just send progress streams.
-  bool BackgroundIndexSkipCreate = false;
 
   Options Opts;
+  struct {
+// Options used for diagnostics.
+ClangdDiagnosticOptions DiagOpts;
+// Set of symbol kinds to use.
+SymbolKindBitset SymbolKinds;
+// Set of completion item kinds to use.
+CompletionItemKindBitset CompletionItemKinds;
+// Whether to emit code actions or commands as code action responses.
+bool EmitCodeAction = false;
+// Whether to emit hierarchical or flat document symbol responses.
+bool HierarchicalDocumentSymbol = false;
+// Whether to send file status updates.
+bool EmitFileStatus = false;
+// Which kind of markup should we use in textDocument/hover responses.
+MarkupKind HoverContentFormat = MarkupKind::PlainText;
+// Whether to have offsets for parameter info labels.
+bool OffsetsInSignatureHelp = false;
+// LSP extension: skip WorkDoneProgressCreate, just send progress streams.
+bool BackgroundIndexSkipCreate = false;
+  } ClientCapabilities;
   // The CDB is created by the "initialize" LSP method.
   std::unique_ptr BaseCDB;
   // CDB is BaseCDB plus any commands overridden via LSP extensions.
Index: clang-tools-extra/clangd/ClangdLSPServer.cpp
===
--- clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -441,8 +441,7 @@
   return Modifiers;
 }
 
-void ClangdLSPServer::onInitialize(const InitializeParams &Params,
-   Callback Reply) {
+void ClangdLSPServer::alignWithClient(const InitializeParams &Params) {
   // Determine character encoding first as it affects constructed ClangdServer.
   if (Params.capabilities.offsetEncoding && !Opts.Encoding) {
 Opts.Encoding = OffsetEncoding::UTF16; // fallback
@@ -463,9 +462,6 @@
 Opts.WorkspaceRoot = std::string(Params.rootUri->file());
   else if (Params.rootPath && !Params.rootPath->empty())
 Opts.WorkspaceRoot = *Params.rootPath;
-  if (Server)
-return Reply(llvm::make_error("server already initialized",
-ErrorCode::InvalidRequest));
 
   Opts.CodeComplete.EnableSnippets = Params.capabilities.CompletionSnippets;
   Opts.CodeComplete.IncludeFixIts = Params.capabilities.CompletionFixes;
@@ -475,25 +471,40 @@
   Params.capabilities.CompletionDocumentationFormat;
   Opts.SignatureHelpDocumentationFormat =
   Params.capabilities.SignatureHelpDocumentationFormat;
-  DiagOpts.EmbedFixesInDia

[clang] abd2b1a - [clang] Fix a crash in constant evaluation

[Kadir Cetinkaya via cfe-commits]

Author: Kadir Cetinkaya
Date: 2022-09-08T18:21:44+02:00
New Revision: abd2b1a9d0421f99d3d132dc99af55ae52f3ac3e

URL: 
https://github.com/llvm/llvm-project/commit/abd2b1a9d0421f99d3d132dc99af55ae52f3ac3e
DIFF: 
https://github.com/llvm/llvm-project/commit/abd2b1a9d0421f99d3d132dc99af55ae52f3ac3e.diff

LOG: [clang] Fix a crash in constant evaluation

Added: 


Modified: 
clang/lib/AST/ExprConstant.cpp
clang/test/SemaCXX/constexpr-value-init.cpp

Removed: 




diff  --git a/clang/lib/AST/ExprConstant.cpp b/clang/lib/AST/ExprConstant.cpp
index ba5690cd3c5a0..a5568e0158e33 100644
--- a/clang/lib/AST/ExprConstant.cpp
+++ b/clang/lib/AST/ExprConstant.cpp
@@ -4844,6 +4844,8 @@ enum EvalStmtResult {
 }
 
 static bool EvaluateVarDecl(EvalInfo &Info, const VarDecl *VD) {
+  if (VD->isInvalidDecl())
+return false;
   // We don't need to evaluate the initializer for a static local.
   if (!VD->hasLocalStorage())
 return true;

diff  --git a/clang/test/SemaCXX/constexpr-value-init.cpp 
b/clang/test/SemaCXX/constexpr-value-init.cpp
index 0d9ca8c55cd56..3314174a0ea17 100644
--- a/clang/test/SemaCXX/constexpr-value-init.cpp
+++ b/clang/test/SemaCXX/constexpr-value-init.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 %s -Wno-uninitialized -std=c++11 -fsyntax-only -verify
+// RUN: %clang_cc1 %s -Wno-uninitialized -std=c++17 -fsyntax-only -verify
 
 struct A {
   constexpr A() : a(b + 1), b(a + 1) {} // expected-note 5{{outside its 
lifetime}}
@@ -46,3 +46,17 @@ static_assert(e2.a[0].a == 1, "");
 static_assert(e2.a[0].b == 2, "");
 static_assert(e2.a[1].a == 1, "");
 static_assert(e2.a[1].b == 2, "");
+
+namespace InvalidDeclInsideConstExpr {
+template  struct i; // expected-note {{template is declared here}}
+template <> struct i<0> {};
+
+template  constexpr auto c() {
+  // i is valid, but it might be incomplete. g would be invalid in that 
case.
+  i g; // expected-error {{implicit instantiation of undefined template 
'InvalidDeclInsideConstExpr::i<1>'}}
+  return 0;
+}
+
+auto y = c<1>(); // expected-note {{in instantiation of function template 
specialization 'InvalidDeclInsideConstExpr::c<1>' requested here}}
+auto x = c<0>(); // this is valid.
+}



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

[PATCH] D133479: [clangd] Set Incompleteness for spec fuzzyfind requests

[Kadir Cetinkaya via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG71c4fb1d6482: [clangd] Set Incompleteness for spec fuzzyfind 
requests (authored by kadircet).

Changed prior to commit:
  https://reviews.llvm.org/D133479?vs=458690&id=458774#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133479

Files:
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/CodeComplete.h
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -2594,7 +2594,8 @@
   Opts.Index = &Requests;
 
   auto CompleteAtPoint = [&](StringRef P) {
-cantFail(runCodeComplete(Server, File, Test.point(P), Opts));
+auto CCR = cantFail(runCodeComplete(Server, File, Test.point(P), Opts));
+EXPECT_TRUE(CCR.HasMore);
   };
 
   CompleteAtPoint("1");
Index: clang-tools-extra/clangd/CodeComplete.h
===
--- clang-tools-extra/clangd/CodeComplete.h
+++ clang-tools-extra/clangd/CodeComplete.h
@@ -31,6 +31,7 @@
 #include "llvm/ADT/StringRef.h"
 #include 
 #include 
+#include 
 
 namespace clang {
 class NamedDecl;
@@ -262,7 +263,7 @@
   llvm::Optional NewReq;
   /// The result is consumed by `codeComplete()` if speculation succeeded.
   /// NOTE: the destructor will wait for the async call to finish.
-  std::future Result;
+  std::future> Result;
 };
 
 /// Gets code completions at a specified \p Pos in \p FileName.
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -70,6 +70,7 @@
 #include 
 #include 
 #include 
+#include 
 
 // We log detailed candidate here if you run with -debug-only=codecomplete.
 #define DEBUG_TYPE "CodeComplete"
@@ -1363,13 +1364,14 @@
   return true;
 }
 
-std::future startAsyncFuzzyFind(const SymbolIndex &Index,
-const FuzzyFindRequest &Req) {
-  return runAsync([&Index, Req]() {
+std::future>
+startAsyncFuzzyFind(const SymbolIndex &Index, const FuzzyFindRequest &Req) {
+  return runAsync>([&Index, Req]() {
 trace::Span Tracer("Async fuzzyFind");
 SymbolSlab::Builder Syms;
-Index.fuzzyFind(Req, [&Syms](const Symbol &Sym) { Syms.insert(Sym); });
-return std::move(Syms).build();
+bool Incomplete =
+Index.fuzzyFind(Req, [&Syms](const Symbol &Sym) { Syms.insert(Sym); });
+return std::make_pair(Incomplete, std::move(Syms).build());
   });
 }
 
@@ -1721,7 +1723,9 @@
   SPAN_ATTACH(Tracer, "Speculative results", true);
 
   trace::Span WaitSpec("Wait speculative results");
-  return SpecFuzzyFind->Result.get();
+  auto SpecRes = SpecFuzzyFind->Result.get();
+  Incomplete |= SpecRes.first;
+  return std::move(SpecRes.second);
 }
 
 SPAN_ATTACH(Tracer, "Speculative results", false);


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -2594,7 +2594,8 @@
   Opts.Index = &Requests;
 
   auto CompleteAtPoint = [&](StringRef P) {
-cantFail(runCodeComplete(Server, File, Test.point(P), Opts));
+auto CCR = cantFail(runCodeComplete(Server, File, Test.point(P), Opts));
+EXPECT_TRUE(CCR.HasMore);
   };
 
   CompleteAtPoint("1");
Index: clang-tools-extra/clangd/CodeComplete.h
===
--- clang-tools-extra/clangd/CodeComplete.h
+++ clang-tools-extra/clangd/CodeComplete.h
@@ -31,6 +31,7 @@
 #include "llvm/ADT/StringRef.h"
 #include 
 #include 
+#include 
 
 namespace clang {
 class NamedDecl;
@@ -262,7 +263,7 @@
   llvm::Optional NewReq;
   /// The result is consumed by `codeComplete()` if speculation succeeded.
   /// NOTE: the destructor will wait for the async call to finish.
-  std::future Result;
+  std::future> Result;
 };
 
 /// Gets code completions at a specified \p Pos in \p FileName.
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -70,6 +70,7 @@
 #include 
 #include 
 #include 
+#include 
 
 // We log detailed candidate here if you run with -debug-only=codecomplete.
 #define DEBUG_TYPE "CodeComplete"
@@ -1363,13 +1364,14 @@
   return true;
 }
 
-std::future startAsyncFuzzyFind(const SymbolIndex &Index,
-const FuzzyFindRequest &Req) {
- 

[clang-tools-extra] 71c4fb1 - [clangd] Set Incompleteness for spec fuzzyfind requests

[Kadir Cetinkaya via cfe-commits]

Author: Kadir Cetinkaya
Date: 2022-09-08T18:34:25+02:00
New Revision: 71c4fb1d6482e9b7e825ad28e0366649301470d3

URL: 
https://github.com/llvm/llvm-project/commit/71c4fb1d6482e9b7e825ad28e0366649301470d3
DIFF: 
https://github.com/llvm/llvm-project/commit/71c4fb1d6482e9b7e825ad28e0366649301470d3.diff

LOG: [clangd] Set Incompleteness for spec fuzzyfind requests

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

Added: 


Modified: 
clang-tools-extra/clangd/CodeComplete.cpp
clang-tools-extra/clangd/CodeComplete.h
clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/CodeComplete.cpp 
b/clang-tools-extra/clangd/CodeComplete.cpp
index 9d9b0e748153..275749da55e7 100644
--- a/clang-tools-extra/clangd/CodeComplete.cpp
+++ b/clang-tools-extra/clangd/CodeComplete.cpp
@@ -70,6 +70,7 @@
 #include 
 #include 
 #include 
+#include 
 
 // We log detailed candidate here if you run with -debug-only=codecomplete.
 #define DEBUG_TYPE "CodeComplete"
@@ -1363,13 +1364,14 @@ bool includeSymbolFromIndex(CodeCompletionContext::Kind 
Kind,
   return true;
 }
 
-std::future startAsyncFuzzyFind(const SymbolIndex &Index,
-const FuzzyFindRequest &Req) {
-  return runAsync([&Index, Req]() {
+std::future>
+startAsyncFuzzyFind(const SymbolIndex &Index, const FuzzyFindRequest &Req) {
+  return runAsync>([&Index, Req]() {
 trace::Span Tracer("Async fuzzyFind");
 SymbolSlab::Builder Syms;
-Index.fuzzyFind(Req, [&Syms](const Symbol &Sym) { Syms.insert(Sym); });
-return std::move(Syms).build();
+bool Incomplete =
+Index.fuzzyFind(Req, [&Syms](const Symbol &Sym) { Syms.insert(Sym); });
+return std::make_pair(Incomplete, std::move(Syms).build());
   });
 }
 
@@ -1721,7 +1723,9 @@ class CodeCompleteFlow {
   SPAN_ATTACH(Tracer, "Speculative results", true);
 
   trace::Span WaitSpec("Wait speculative results");
-  return SpecFuzzyFind->Result.get();
+  auto SpecRes = SpecFuzzyFind->Result.get();
+  Incomplete |= SpecRes.first;
+  return std::move(SpecRes.second);
 }
 
 SPAN_ATTACH(Tracer, "Speculative results", false);

diff  --git a/clang-tools-extra/clangd/CodeComplete.h 
b/clang-tools-extra/clangd/CodeComplete.h
index ebd451c95c76..269be8944df1 100644
--- a/clang-tools-extra/clangd/CodeComplete.h
+++ b/clang-tools-extra/clangd/CodeComplete.h
@@ -31,6 +31,7 @@
 #include "llvm/ADT/StringRef.h"
 #include 
 #include 
+#include 
 
 namespace clang {
 class NamedDecl;
@@ -262,7 +263,7 @@ struct SpeculativeFuzzyFind {
   llvm::Optional NewReq;
   /// The result is consumed by `codeComplete()` if speculation succeeded.
   /// NOTE: the destructor will wait for the async call to finish.
-  std::future Result;
+  std::future> Result;
 };
 
 /// Gets code completions at a specified \p Pos in \p FileName.

diff  --git a/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp 
b/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
index f2d8328afdbb..2fb5c7a47f77 100644
--- a/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ b/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -2594,7 +2594,8 @@ TEST(CompletionTest, EnableSpeculativeIndexRequest) {
   Opts.Index = &Requests;
 
   auto CompleteAtPoint = [&](StringRef P) {
-cantFail(runCodeComplete(Server, File, Test.point(P), Opts));
+auto CCR = cantFail(runCodeComplete(Server, File, Test.point(P), Opts));
+EXPECT_TRUE(CCR.HasMore);
   };
 
   CompleteAtPoint("1");



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

Re: [clang] b7a7aee - [clang] Qualify auto in range-based for loops (NFC)

[David Blaikie via cfe-commits]

Mixed feelings here - Kazu's made a lot of cleanup/stylistic changes
across the LLVM project for a while now, most, at least I think, are
quite welcome (things like switching to range-based-for, std
algorithms over llvm ones, llvm algorithms over manually written
loops, etc). But yeah, there's some threshold below which the churn
might not be worth the benefit - especially if the change doesn't come
along with tooling to enforce the invariant is maintained in the
future (if it's easy to make mistakes like this one - we'll regress it
and need to do cleanup again in the future)

Also, for this particular one, I wonder if in some cases this sort of
automatic transformation isn't ideal - if something is a pointer, but
that's an implementation detail, rather than an intentional feature of
an API (eg: the pointer-ness might be hidden behind a typedef and used
as an opaque handle, without any dereferencing, etc)

I think it'd be really good to have some discussion on discourse about
if/how some of these cleanups could be formed into a way to
enforce/encourage the invariant to be maintained going forward -
clang-tidy (assuming that's the basis for the tooling Kazu's using to
make these changes in the first place) integration into the LLVM build
in some way, etc.

& yeah, adding the `const` too if/when that's relevant would've
improved the quality/value/justification for a cleanup change like
this.

On Sun, Sep 4, 2022 at 5:58 AM Aaron Ballman via cfe-commits
 wrote:
>
> FWIW, sweeping NFC changes like this cause a fair amount of code churn
> (which makes tools like git blame a bit harder to use) for a
> relatively small improvement to code readability, which is why our
> developer policy asks that you "Avoid committing formatting- or
> whitespace-only changes outside of code you plan to make subsequent
> changes to." In the future, I'd caution against doing such large-scale
> sweeping NFC changes outside of areas you're actively working on
> unless there's some wider discussion with the community first. That
> said, all of your changes are all improvements, so thank you for them!
>
> Some of the changes you made would have ideally made it more clear
> when the deduced type is a pointer to a const object instead of hiding
> the qualifier behind the deduction. I've pointed out a couple such
> places below, but don't feel obligated to go back and change anything
> unless you're going to be touching other code in the area.
>
> ~Aaron
>
>
> On Sun, Sep 4, 2022 at 2:27 AM Kazu Hirata via cfe-commits
>  wrote:
> >
> >
> > Author: Kazu Hirata
> > Date: 2022-09-03T23:27:27-07:00
> > New Revision: b7a7aeee90cffefd0f73b8d9f44ab4d1d5123d05
> >
> > URL: 
> > https://github.com/llvm/llvm-project/commit/b7a7aeee90cffefd0f73b8d9f44ab4d1d5123d05
> > DIFF: 
> > https://github.com/llvm/llvm-project/commit/b7a7aeee90cffefd0f73b8d9f44ab4d1d5123d05.diff
> >
> > LOG: [clang] Qualify auto in range-based for loops (NFC)
> >
> > Added:
> >
> >
> > Modified:
> > clang/lib/ARCMigrate/ObjCMT.cpp
> > clang/lib/ARCMigrate/TransGCAttrs.cpp
> > clang/lib/AST/ASTContext.cpp
> > clang/lib/AST/ASTImporter.cpp
> > clang/lib/AST/Decl.cpp
> > clang/lib/AST/DeclObjC.cpp
> > clang/lib/AST/ODRHash.cpp
> > clang/lib/AST/OpenMPClause.cpp
> > clang/lib/AST/StmtProfile.cpp
> > clang/lib/AST/Type.cpp
> > clang/lib/Analysis/CFG.cpp
> > clang/lib/Analysis/ThreadSafetyCommon.cpp
> > clang/lib/CodeGen/CGBlocks.cpp
> > clang/lib/CodeGen/CGCall.cpp
> > clang/lib/CodeGen/CGClass.cpp
> > clang/lib/CodeGen/CGDebugInfo.cpp
> > clang/lib/CodeGen/CGDeclCXX.cpp
> > clang/lib/CodeGen/CGExpr.cpp
> > clang/lib/CodeGen/CGObjCGNU.cpp
> > clang/lib/CodeGen/CGObjCMac.cpp
> > clang/lib/CodeGen/CodeGenFunction.cpp
> > clang/lib/CodeGen/ObjectFilePCHContainerOperations.cpp
> > clang/lib/CodeGen/SwiftCallingConv.cpp
> > clang/lib/Driver/Compilation.cpp
> > clang/lib/Driver/Driver.cpp
> > clang/lib/Driver/ToolChains/Clang.cpp
> > clang/lib/Driver/ToolChains/CommonArgs.cpp
> > clang/lib/Driver/ToolChains/Gnu.cpp
> > clang/lib/Driver/ToolChains/HIPAMD.cpp
> > clang/lib/Format/Format.cpp
> > clang/lib/Frontend/FrontendActions.cpp
> > clang/lib/Index/USRGeneration.cpp
> > clang/lib/Sema/IdentifierResolver.cpp
> > clang/lib/Sema/Sema.cpp
> > clang/lib/Sema/SemaCodeComplete.cpp
> > clang/lib/Sema/SemaDecl.cpp
> > clang/lib/Sema/SemaDeclAttr.cpp
> > clang/lib/Sema/SemaDeclCXX.cpp
> > clang/lib/Sema/SemaDeclObjC.cpp
> > clang/lib/Sema/SemaExpr.cpp
> > clang/lib/Sema/SemaExprCXX.cpp
> > clang/lib/Sema/SemaInit.cpp
> > clang/lib/Sema/SemaLambda.cpp
> > clang/lib/Sema/SemaLookup.cpp
> > clang/lib/Sema/SemaObjCProperty.cpp
> > clang/lib/Sema/SemaOpenMP.cpp
> > clang/lib/Sema/SemaOverload.cpp
> > clang/lib/Sema/SemaTemplateDeduction.cpp
> > clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
> > clang/lib/

Re: [clang] 0e5813b - [clang][NFC] silences warnings

[David Blaikie via cfe-commits]

On Fri, Aug 26, 2022 at 2:10 PM Christopher Di Bella via cfe-commits
 wrote:
>
>
> Author: Abraham Corea Diaz
> Date: 2022-08-26T21:09:39Z
> New Revision: 0e5813b88e50576940070003e093d696390a6959
>
> URL: 
> https://github.com/llvm/llvm-project/commit/0e5813b88e50576940070003e093d696390a6959
> DIFF: 
> https://github.com/llvm/llvm-project/commit/0e5813b88e50576940070003e093d696390a6959.diff
>
> LOG: [clang][NFC] silences warnings
>
> * removes unused data member `OS` from `SARIFDiagnostic`
> * flags `Filename` variable as currently unused
>
> This is a follow-up to D131632.
>
> Added:
>
>
> Modified:
> clang/include/clang/Frontend/SARIFDiagnostic.h
> clang/lib/Frontend/SARIFDiagnostic.cpp
>
> Removed:
>
>
>
> 
> diff  --git a/clang/include/clang/Frontend/SARIFDiagnostic.h 
> b/clang/include/clang/Frontend/SARIFDiagnostic.h
> index bd0f1df9aa58..ec1d0b8e6a7c 100644
> --- a/clang/include/clang/Frontend/SARIFDiagnostic.h
> +++ b/clang/include/clang/Frontend/SARIFDiagnostic.h
> @@ -55,8 +55,6 @@ class SARIFDiagnostic : public DiagnosticRenderer {
>StringRef ModuleName) override;
>
>  private:
> -  raw_ostream &OS;
> -
>// Shared between SARIFDiagnosticPrinter and this renderer.
>SarifDocumentWriter *Writer;
>
>
> diff  --git a/clang/lib/Frontend/SARIFDiagnostic.cpp 
> b/clang/lib/Frontend/SARIFDiagnostic.cpp
> index 2bcbd5cf34f2..f0f32a179825 100644
> --- a/clang/lib/Frontend/SARIFDiagnostic.cpp
> +++ b/clang/lib/Frontend/SARIFDiagnostic.cpp
> @@ -33,7 +33,7 @@ namespace clang {
>  SARIFDiagnostic::SARIFDiagnostic(raw_ostream &OS, const LangOptions 
> &LangOpts,
>   DiagnosticOptions *DiagOpts,
>   SarifDocumentWriter *Writer)
> -: DiagnosticRenderer(LangOpts, DiagOpts), OS(OS), Writer(Writer) {}
> +: DiagnosticRenderer(LangOpts, DiagOpts), Writer(Writer) {}
>
>  // FIXME(llvm-project/issues/57323): Refactor Diagnostic classes.
>  void SARIFDiagnostic::emitDiagnosticMessage(
> @@ -71,7 +71,8 @@ SarifResult SARIFDiagnostic::addLocationToResult(
>  FileID FID = Loc.getFileID();
>  if (FID.isValid()) {
>if (const FileEntry *FE = Loc.getFileEntry()) {
> -emitFilename(FE->getName(), Loc.getManager());
> +[[gnu::unused]] llvm::StringRef Filename =

Does this not cause warnings on an MSVC build for an unknown
attribute? (there's a whole issue with unknown attributes and how to
diagnose them)

I think it's probably best in general to leave the variable out until it's used.

> +emitFilename(FE->getName(), Loc.getManager());
>  // FIXME(llvm-project/issues/57366): File-only locations
>}
>  }
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D133425: Silence -Wctad-maybe-unsupported stemming from system headers

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D133425#3775353 , @ldionne wrote:

> Wouldn't re-applying 
> https://github.com/llvm/llvm-project/commit/fcd549a7d8284a8e7c763fee3da2206acd8cdc4f
>  (which had been reverted IIUC) be a more precise fix for this problem? We'd 
> suppress the warning, but only for classes that we know are OK to use with 
> CTAD.

Oh that would be a great solution to this! Do you recall why that change was 
reverted?

> It is a fact that due to the nature of CTAD (which is enabled by default 
> based on some general rules), several classes in the standard library that 
> predated CTAD were not really designed with CTAD in mind, and CTAD should 
> arguably not be used with them.
>
> Re-applying `fcd549a7d8284a8e7c763fee3da2206acd8cdc4f` would not require any 
> Clang changes.

I think that would be a good solution if it's workable, at least for the issue 
we're seeing internally.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133425

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

[PATCH] D133425: Silence -Wctad-maybe-unsupported stemming from system headers

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D133425#3777598 , @aaron.ballman 
wrote:

> In D133425#3775353 , @ldionne wrote:
>
>> Re-applying `fcd549a7d8284a8e7c763fee3da2206acd8cdc4f` would not require any 
>> Clang changes.
>
> I think that would be a good solution if it's workable, at least for the 
> issue we're seeing internally.

It is worth noting that this won't resolve the issue when using libstdc++ and 
Clang's behavior with this diagnostic differs from GCC's: 
https://godbolt.org/z/YMznh4Weq


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133425

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

[PATCH] D127284: [clang-repl] Support statements on global scope in incremental mode.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D127284#3776805 , @aaron.ballman 
wrote:

> In D127284#3776036 , @rsmith wrote:
>
>> In terms of the high-level direction here, I think it would make sense to 
>> approach this by adding a full-fledged language extension to Clang to allow 
>> statements at the top level (with a `-f` flag to enable it), and then enable 
>> that extension in the interpreter. The major change that shift in viewpoint 
>> provides is that we should have explicit modeling of these top-level 
>> statements in the AST, rather than having them only transiently exist until 
>> they get passed off to the AST consumer. I think I'd want to see something 
>> like `TopLevelStmtDecl` added to explicitly model the case where we parse a 
>> statement at the top level. You can then extend the various parts of Clang 
>> that deal with global variable initializers to also handle 
>> `TopLevelStmtDecl`s.
>
> Thank you for the suggestion! I actually have a different view on this that I 
> was thinking about last night, but it's somewhat similar to yours in that it 
> involves a flag to opt into behavior.
>
> I don't think we should add a feature flag for this to Clang or support this 
> functionality in Clang's AST -- it does not meet our language extension 
> requirements (this won't be proposed to any standards body, etc). Further, I 
> don't think Clang maintainers should have to play cognitive whack-a-mole as 
> new statements and features are added to C and C++, wondering how they should 
> behave if at the top level. Instead, I think it would make sense to add a 
> flag to clang-repl so the user can decide whether they want their REPL 
> experience to be "whole TU" or "pretend we're wrapped in a function". For 
> users who want their experience to be both at the same time: that's an 
> interesting idea, but it is not a C or C++ REPL experience; I think those 
> users can go with the "whole TU" approach and write an extra line of code + 
> some braces, as needed.
>
> The reason I'm so uncomfortable with putting this into Clang is because 
> neither language is designed to expect this sort of behavior and the 
> resulting code will misbehave in mysterious ways when we guess wrong and it 
> will be very difficult to address them all. I expect some things to be easy 
> to recognize (see the `template` keyword and you know you can't be within a 
> function scope), other things will require a bit of token lookahead 
> (`unsigned long long _Thread_local i = 12;` cannot appear at local scope), 
> and still others will require looking ahead through a potentially arbitrary 
> number of statements (like with a VLA). I think the user should know 
> explicitly which context they're in given that it matters to the source 
> languages (and this is before we start to think about REPL over something 
> like ObjC/OpenCL/HLSL/etc which may have even more interesting situations to 
> worry about).

I had a really great conversation with @v.g.vassilev off-list about my concerns 
and the clang-repl needs/desires (thank you for taking the time to have that 
chat with me!), and this is a summary of what we think makes sense as a way 
forward:

Technical:

- clang gets a -cc1 (only) flag (or some other kind of not-user-facing option) 
to enable a special mode where you can mix statements and declarations at TU 
scope.
- clang-repl uses that new flag.
- clang gets a new AST node for TopLevelStmtDecl that's a Decl AST node 
wrapping a Stmt node; it's documented as only existing to support REPL. Add an 
assertion somewhere sensible that we never see one of these AST nodes outside 
of a clang-repl context.
- clang-repl uses that new AST node as-needed.

Administrative:

- clang-repl continues to push on standardization efforts in WG21 (and 
potentially WG14).
  - If those efforts lead to an explicit rejection of the idea, we should 
discuss how to proceed at that time, but I would envision that we'd remove the 
new AST node and the flag to enable this functionality, and introduce 
interfaces allowing us to synthesize code during codegen to try to break 
clang-repl users as little as possible. This way we aren't eating into 
standards body design space that will potentially give us problems in the 
future if the committees elect to do something *incompatible* in this space. 
(Basically: in a fight between clang-repl users and a new standard feature, the 
new standard feature "wins".) This will break clang-repl users, so we should 
consider documenting the potential for this up front (basically, call it an 
experimental feature of clang-repl rather than promising backwards 
compatibility for it).
- Any failures related to TopLevelStmtDecl will require collaboration between 
clang-repl and clang maintainers, but should mostly be driven by clang-repl 
maintainers.


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

https://reviews.llvm.or

[clang-tools-extra] d200db3 - [clang] template / auto deduction deduces common sugar

[Matheus Izvekov via cfe-commits]

Author: Matheus Izvekov
Date: 2022-09-08T19:17:48+02:00
New Revision: d200db38637884fd0b421802c6094b2a03ceb29e

URL: 
https://github.com/llvm/llvm-project/commit/d200db38637884fd0b421802c6094b2a03ceb29e
DIFF: 
https://github.com/llvm/llvm-project/commit/d200db38637884fd0b421802c6094b2a03ceb29e.diff

LOG: [clang] template / auto deduction deduces common sugar

After upgrading the type deduction machinery to retain type sugar in
D110216, we were left with a situation where there is no general
well behaved mechanism in Clang to unify the type sugar of multiple
deductions of the same type parameter.

So we ended up making an arbitrary choice: keep the sugar of the first
deduction, ignore subsequent ones.

In general, we already had this problem, but in a smaller scale.
The result of the conditional operator and many other binary ops
could benefit from such a mechanism.

This patch implements such a type sugar unification mechanism.

The basics:

This patch introduces a `getCommonSugaredType(QualType X, QualType Y)`
method to ASTContext which implements this functionality, and uses it
for unifying the results of type deduction and return type deduction.
This will return the most derived type sugar which occurs in both X and
Y.

Example:

Suppose we have these types:
```
using Animal = int;
using Cat = Animal;
using Dog = Animal;

using Tom = Cat;
using Spike = Dog;
using Tyke = Dog;
```
For `X = Tom, Y = Spike`, this will result in `Animal`.
For `X = Spike, Y = Tyke`, this will result in `Dog`.

How it works:

We take two types, X and Y, which we wish to unify as input.
These types must have the same (qualified or unqualified) canonical
type.

We dive down fast through top-level type sugar nodes, to the
underlying canonical node. If these canonical nodes differ, we
build a common one out of the two, unifying any sugar they had.
Note that this might involve a recursive call to unify any children
of those. We then return that canonical node, handling any qualifiers.

If they don't differ, we walk up the list of sugar type nodes we dived
through, finding the last identical pair, and returning that as the
result, again handling qualifiers.

Note that this patch will not unify sugar nodes if they are not
identical already. We will simply strip off top-level sugar nodes that
differ between X and Y. This sugar node unification will instead be
implemented in a subsequent patch.

This patch also implements a few users of this mechanism:
* Template argument deduction.
* Auto deduction, for functions returning auto / decltype(auto), with
  special handling for initializer_list as well.

Further users will be implemented in a subsequent patch.

Signed-off-by: Matheus Izvekov 

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

Added: 


Modified: 
clang-tools-extra/clangd/unittests/ASTTests.cpp
clang-tools-extra/clangd/unittests/HoverTests.cpp
clang/include/clang/AST/ASTContext.h
clang/include/clang/AST/Type.h
clang/include/clang/Sema/Sema.h
clang/lib/AST/ASTContext.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaDeclCXX.cpp
clang/lib/Sema/SemaExprCXX.cpp
clang/lib/Sema/SemaOverload.cpp
clang/lib/Sema/SemaStmt.cpp
clang/lib/Sema/SemaTemplate.cpp
clang/lib/Sema/SemaTemplateDeduction.cpp
clang/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp
clang/test/SemaCXX/deduced-return-void.cpp
clang/test/SemaCXX/sugared-auto.cpp
clang/test/SemaTemplate/deduction.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/ASTTests.cpp 
b/clang-tools-extra/clangd/unittests/ASTTests.cpp
index 4bb3e025b87a5..8f67136585308 100644
--- a/clang-tools-extra/clangd/unittests/ASTTests.cpp
+++ b/clang-tools-extra/clangd/unittests/ASTTests.cpp
@@ -84,7 +84,7 @@ TEST(GetDeducedType, KwAutoKwDecltypeExpansion) {
 
   ^auto i = {1,2};
   )cpp",
-  "class std::initializer_list",
+  "std::initializer_list",
   },
   {
   R"cpp( // auto in function return type with trailing return type

diff  --git a/clang-tools-extra/clangd/unittests/HoverTests.cpp 
b/clang-tools-extra/clangd/unittests/HoverTests.cpp
index 663ebf2403739..d5e3e5fd48df7 100644
--- a/clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ b/clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -1940,7 +1940,7 @@ TEST(Hover, All) {
   [](HoverInfo &HI) {
 HI.Name = "auto";
 HI.Kind = index::SymbolKind::TypeAlias;
-HI.Definition = "class std::initializer_list";
+HI.Definition = "std::initializer_list";
   }},
   {
   R"cpp(// User defined conversion to auto

diff  --git a/clang/include/clang/AST/ASTContext.h 
b/clang/include/clang/AST/ASTContext.h
index eb52bf5c736a0..8ef7a32e6f09e 100644
--- a/clang/include/clang/AST/ASTContext.h
+++ b/clang/include/clang/AST/ASTContext.h
@@ -2807,6 +2807,23

[clang] d42122c - [clang] use getCommonSugar in an assortment of places

[Matheus Izvekov via cfe-commits]

Author: Matheus Izvekov
Date: 2022-09-08T19:17:53+02:00
New Revision: d42122cd5db021e6b14a90a98ad1dd09412efb4c

URL: 
https://github.com/llvm/llvm-project/commit/d42122cd5db021e6b14a90a98ad1dd09412efb4c
DIFF: 
https://github.com/llvm/llvm-project/commit/d42122cd5db021e6b14a90a98ad1dd09412efb4c.diff

LOG: [clang] use getCommonSugar in an assortment of places

For this patch, a simple search was performed for patterns where there are
two types (usually an LHS and an RHS) which are structurally the same, and there
is some result type which is resolved as either one of them (typically LHS for
consistency).

We change those cases to resolve as the common sugared type between those two,
utilizing the new infrastructure created for this purpose.

Depends on D111283

Signed-off-by: Matheus Izvekov 

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

Added: 
clang/test/Sema/sugar-common-types.c
clang/test/SemaCXX/sugar-common-types.cpp

Modified: 
clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp

clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/narrowing-conversions-ignoreconversionfromtypes-option.cpp
clang/lib/Sema/SemaExpr.cpp
clang/lib/Sema/SemaExprCXX.cpp
clang/test/AST/ast-dump-fpfeatures.cpp
clang/test/CodeGen/compound-assign-overflow.c
clang/test/Sema/matrix-type-operators.c
clang/test/Sema/nullability.c
clang/test/SemaCXX/matrix-type-operators.cpp
clang/test/SemaCXX/sugared-auto.cpp
clang/test/SemaObjC/format-strings-objc.m
compiler-rt/test/ubsan/TestCases/Integer/add-overflow.cpp
compiler-rt/test/ubsan/TestCases/Integer/no-recover.cpp
compiler-rt/test/ubsan/TestCases/Integer/sub-overflow.cpp
compiler-rt/test/ubsan/TestCases/Integer/uadd-overflow.cpp
compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
lldb/test/API/commands/expression/rdar42038760/main.c
lldb/test/API/commands/expression/rdar44436068/main.c

Removed: 




diff  --git 
a/clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp 
b/clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp
index 70ecc202d0b28..6e38ea77ad68d 100644
--- a/clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp
+++ b/clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp
@@ -330,7 +330,7 @@ TEST_F(ExtractVariableTest, Test) {
  void bar() {
int (*placeholder)(int) = foo('c'); (void)placeholder;
  })cpp"},
-  // Arithmetic on typedef types yields plain integer types
+  // Arithmetic on typedef types preserves typedef types
   {R"cpp(typedef long NSInteger;
  void varDecl() {
 NSInteger a = 2 * 5;
@@ -339,7 +339,7 @@ TEST_F(ExtractVariableTest, Test) {
R"cpp(typedef long NSInteger;
  void varDecl() {
 NSInteger a = 2 * 5;
-long placeholder = a * 7; NSInteger b = placeholder + 3;
+NSInteger placeholder = a * 7; NSInteger b = placeholder + 3;
  })cpp"},
   };
   for (const auto &IO : InputOutputs) {

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/narrowing-conversions-ignoreconversionfromtypes-option.cpp
 
b/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/narrowing-conversions-ignoreconversionfromtypes-option.cpp
index 2fc5621c2fb8f..34da420fd0cc5 100644
--- 
a/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/narrowing-conversions-ignoreconversionfromtypes-option.cpp
+++ 
b/clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/narrowing-conversions-ignoreconversionfromtypes-option.cpp
@@ -42,7 +42,7 @@ void narrowing_size_method() {
   // IGNORED: Warning is disabled with IgnoreConversionFromTypes=global_size_t.
 
   i = j + v.size();
-  // CHECK-MESSAGES-DEFAULT: :[[@LINE-1]]:7: warning: narrowing conversion 
from 'long long' to signed type 'int' is implementation-defined 
[cppcoreguidelines-narrowing-conversions]
+  // CHECK-MESSAGES-DEFAULT: :[[@LINE-1]]:7: warning: narrowing conversion 
from 'global_size_t' (aka 'long long') to signed type 'int' is 
implementation-defined [cppcoreguidelines-narrowing-conversions]
   // IGNORED: Warning is disabled with IgnoreConversionFromTypes=global_size_t.
 }
 
@@ -51,7 +51,7 @@ void narrowing_size_method_binary_expr() {
   int j;
   vector v;
   i = j + v.size();
-  // CHECK-MESSAGES-DEFAULT: :[[@LINE-1]]:7: warning: narrowing conversion 
from 'long long' to signed type 'int' is implementation-defined 
[cppcoreguidelines-narrowing-conversions]
+  // CHECK-MESSAGES-DEFAULT: :[[@LINE-1]]:7: warning: narrowing conversion 
from 'global_size_t' (aka 'long long') to signed type 'int' is 
implementation-defined [cppcoreguidelines-narrowing-conversions]
   // IGNORED: Warning is disabled with IgnoreConversionF

[clang] 16e5d6d - [clang] extend getCommonSugaredType to merge sugar nodes

[Matheus Izvekov via cfe-commits]

Author: Matheus Izvekov
Date: 2022-09-08T19:17:53+02:00
New Revision: 16e5d6d7f98f1119aab3d10ec4f9e59b5aacd359

URL: 
https://github.com/llvm/llvm-project/commit/16e5d6d7f98f1119aab3d10ec4f9e59b5aacd359
DIFF: 
https://github.com/llvm/llvm-project/commit/16e5d6d7f98f1119aab3d10ec4f9e59b5aacd359.diff

LOG: [clang] extend getCommonSugaredType to merge sugar nodes

This continues D111283 by extending the getCommonSugaredType
implementation to also merge non-canonical type nodes.

We merge these nodes by going up starting from the canonical
node, calculating their merged properties on the way.

If we reach a pair that is too different, or which we could not
otherwise unify, we bail out and don't try to keep going on to
the next pair, in effect striping out all the remaining top-level
sugar nodes. This avoids mismatching 'companion' nodes, such as
ElaboratedType, so that they don't end up elaborating some other
unrelated thing.

Depends on D111509

Signed-off-by: Matheus Izvekov 

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

Added: 


Modified: 
clang/include/clang/AST/ASTContext.h
clang/lib/AST/ASTContext.cpp
clang/lib/Sema/SemaTemplateDeduction.cpp
clang/test/SemaCXX/sugar-common-types.cpp

Removed: 




diff  --git a/clang/include/clang/AST/ASTContext.h 
b/clang/include/clang/AST/ASTContext.h
index 8ef7a32e6f09..acde4ff6f942 100644
--- a/clang/include/clang/AST/ASTContext.h
+++ b/clang/include/clang/AST/ASTContext.h
@@ -1366,6 +1366,9 @@ class ASTContext : public RefCountedBase {
   CanQualType getDecayedType(CanQualType T) const {
 return CanQualType::CreateUnsafe(getDecayedType((QualType) T));
   }
+  /// Return the uniqued reference to a specified decay from the original
+  /// type to the decayed type.
+  QualType getDecayedType(QualType Orig, QualType Decayed) const;
 
   /// Return the uniqued reference to the atomic type for the specified
   /// type.

diff  --git a/clang/lib/AST/ASTContext.cpp b/clang/lib/AST/ASTContext.cpp
index d7c626adee19..fe06e8eb18f1 100644
--- a/clang/lib/AST/ASTContext.cpp
+++ b/clang/lib/AST/ASTContext.cpp
@@ -3332,6 +3332,26 @@ QualType ASTContext::getAdjustedType(QualType Orig, 
QualType New) const {
   return QualType(AT, 0);
 }
 
+QualType ASTContext::getDecayedType(QualType Orig, QualType Decayed) const {
+  llvm::FoldingSetNodeID ID;
+  AdjustedType::Profile(ID, Orig, Decayed);
+  void *InsertPos = nullptr;
+  AdjustedType *AT = AdjustedTypes.FindNodeOrInsertPos(ID, InsertPos);
+  if (AT)
+return QualType(AT, 0);
+
+  QualType Canonical = getCanonicalType(Decayed);
+
+  // Get the new insert position for the node we care about.
+  AT = AdjustedTypes.FindNodeOrInsertPos(ID, InsertPos);
+  assert(!AT && "Shouldn't be in the map!");
+
+  AT = new (*this, TypeAlignment) DecayedType(Orig, Decayed, Canonical);
+  Types.push_back(AT);
+  AdjustedTypes.InsertNode(AT, InsertPos);
+  return QualType(AT, 0);
+}
+
 QualType ASTContext::getDecayedType(QualType T) const {
   assert((T->isArrayType() || T->isFunctionType()) && "T does not decay");
 
@@ -3352,23 +3372,7 @@ QualType ASTContext::getDecayedType(QualType T) const {
   if (T->isFunctionType())
 Decayed = getPointerType(T);
 
-  llvm::FoldingSetNodeID ID;
-  AdjustedType::Profile(ID, T, Decayed);
-  void *InsertPos = nullptr;
-  AdjustedType *AT = AdjustedTypes.FindNodeOrInsertPos(ID, InsertPos);
-  if (AT)
-return QualType(AT, 0);
-
-  QualType Canonical = getCanonicalType(Decayed);
-
-  // Get the new insert position for the node we care about.
-  AT = AdjustedTypes.FindNodeOrInsertPos(ID, InsertPos);
-  assert(!AT && "Shouldn't be in the map!");
-
-  AT = new (*this, TypeAlignment) DecayedType(T, Decayed, Canonical);
-  Types.push_back(AT);
-  AdjustedTypes.InsertNode(AT, InsertPos);
-  return QualType(AT, 0);
+  return getDecayedType(T, Decayed);
 }
 
 /// getBlockPointerType - Return the uniqued reference to the type for
@@ -12145,9 +12149,8 @@ unsigned ASTContext::getTargetAddressSpace(LangAS AS) 
const {
 // the regular ones.
 
 static Decl *getCommonDecl(Decl *X, Decl *Y) {
-  if (X == Y)
-return X;
-  assert(declaresSameEntity(X, Y));
+  if (!declaresSameEntity(X, Y))
+return nullptr;
   for (const Decl *DX : X->redecls()) {
 // If we reach Y before reaching the first decl, that means X is older.
 if (DX == Y)
@@ -12182,11 +12185,19 @@ static TemplateName getCommonTemplateName(ASTContext 
&Ctx, TemplateName X,
   //with more sugar. For example one could be a SubstTemplateTemplate*
   //replacing the other.
   TemplateName CX = Ctx.getCanonicalTemplateName(X);
-  assert(CX.getAsVoidPointer() ==
- Ctx.getCanonicalTemplateName(Y).getAsVoidPointer());
+  if (CX.getAsVoidPointer() !=
+  Ctx.getCanonicalTemplateName(Y).getAsVoidPointer())
+return TemplateName();
   return CX;
 }
 
+static TemplateName
+getCommonTemplateNameChecked(ASTContext &C

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

[Matheus Izvekov via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rGd200db386378: [clang] template / auto deduction deduces 
common sugar (authored by mizvekov).

Changed prior to commit:
  https://reviews.llvm.org/D111283?vs=458587&id=458786#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111283

Files:
  clang-tools-extra/clangd/unittests/ASTTests.cpp
  clang-tools-extra/clangd/unittests/HoverTests.cpp
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp
  clang/test/SemaCXX/deduced-return-void.cpp
  clang/test/SemaCXX/sugared-auto.cpp
  clang/test/SemaTemplate/deduction.cpp

Index: clang/test/SemaTemplate/deduction.cpp
===
--- clang/test/SemaTemplate/deduction.cpp
+++ clang/test/SemaTemplate/deduction.cpp
@@ -162,6 +162,15 @@
 
 } // namespace test4
 
+namespace test5 {
+
+template  class a {};
+template  void c(b, b);
+template  void c(a, a);
+void d() { c(a(), a()); }
+
+} // namespace test5
+
 // Verify that we can deduce enum-typed arguments correctly.
 namespace test14 {
   enum E { E0, E1 };
Index: clang/test/SemaCXX/sugared-auto.cpp
===
--- clang/test/SemaCXX/sugared-auto.cpp
+++ clang/test/SemaCXX/sugared-auto.cpp
@@ -1,4 +1,12 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++20
+// RUN: %clang_cc1 -fsyntax-only -verify -xobjective-c++ %s -std=c++20 -fms-extensions -fblocks -fobjc-arc -fobjc-runtime-has-weak -fenable-matrix -Wno-dynamic-exception-spec -Wno-c++17-compat-mangling
+// RUN: %clang_cc1 -fsyntax-only -verify -xobjective-c++ %s -std=c++14 -fms-extensions -fblocks -fobjc-arc -fobjc-runtime-has-weak -fenable-matrix -Wno-dynamic-exception-spec -Wno-c++17-compat-mangling
+
+namespace std {
+template struct initializer_list {
+  const T *begin, *end;
+  initializer_list();
+};
+} // namespace std
 
 enum class N {};
 
@@ -9,6 +17,26 @@
 using Man = Animal;
 using Dog = Animal;
 
+using ManPtr = Man *;
+using DogPtr = Dog *;
+
+using SocratesPtr = ManPtr;
+
+using ConstMan = const Man;
+using ConstDog = const Dog;
+
+using Virus = void;
+using SARS = Virus;
+using Ebola = Virus;
+
+using Bacteria = float;
+using Bacilli = Bacteria;
+using Vibrio = Bacteria;
+
+struct Plant;
+using Gymnosperm = Plant;
+using Angiosperm = Plant;
+
 namespace variable {
 
 auto x1 = Animal();
@@ -25,6 +53,9 @@
 N t4 = x4; // expected-error {{lvalue of type 'Man' (aka 'int')}}
 N t5 = x5; // expected-error {{lvalue of type 'Dog' (aka 'int')}}
 
+auto x6 = { Man(), Dog() };
+N t6 = x6; // expected-error {{from 'std::initializer_list' (aka 'initializer_list')}}
+
 } // namespace variable
 
 namespace function_basic {
@@ -41,3 +72,160 @@
 N t3 = x3; // expected-error {{lvalue of type 'Animal' (aka 'int')}}
 
 } // namespace function_basic
+
+namespace function_multiple_basic {
+
+N t1 = [] { // expected-error {{rvalue of type 'Animal' (aka 'int')}}
+  if (true)
+return Man();
+  return Dog();
+}();
+
+N t2 = []() -> decltype(auto) { // expected-error {{rvalue of type 'Animal' (aka 'int')}}
+  if (true)
+return Man();
+  return Dog();
+}();
+
+N t3 = [] { // expected-error {{rvalue of type 'Animal' (aka 'int')}}
+  if (true)
+return Dog();
+  auto x = Man();
+  return x;
+}();
+
+N t4 = [] { // expected-error {{rvalue of type 'int'}}
+  if (true)
+return Dog();
+  return 1;
+}();
+
+N t5 = [] { // expected-error {{rvalue of type 'Virus' (aka 'void')}}
+  if (true)
+return Ebola();
+  return SARS();
+}();
+
+N t6 = [] { // expected-error {{rvalue of type 'void'}}
+  if (true)
+return SARS();
+  return;
+}();
+
+} // namespace function_multiple_basic
+
+#define TEST_AUTO(X, A, B) \
+  static_assert(__is_same(A, B), ""); \
+  auto X(A a, B b) {   \
+if (0) \
+  return a;\
+if (0) \
+  return b;\
+return N();\
+  }
+#define TEST_DAUTO(X, A, B) \
+  static_assert(__is_same(A, B), ""); \
+  decltype(auto) X(A a, B b) {  \
+if (0)  \
+  return static_cast(a); \
+if (0)  \
+  return static_cast(b); \
+return N(); \
+  }
+
+namespace misc {
+
+TEST_AUTO(t1, ManPtr, DogPtr)  // expected-error {{but deduced as 'Animal *' (aka 'int *')}}
+TEST_AUTO(t2, ManPtr, int *)   // expected-error {{but deduced as 'int *'}}
+TEST_AUTO(t3

[PATCH] D111509: [clang] use getCommonSugar in an assortment of places

[Matheus Izvekov via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGd42122cd5db0: [clang] use getCommonSugar in an assortment of 
places (authored by mizvekov).

Changed prior to commit:
  https://reviews.llvm.org/D111509?vs=458608&id=458787#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111509

Files:
  clang-tools-extra/clangd/unittests/tweaks/ExtractVariableTests.cpp
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines/narrowing-conversions-ignoreconversionfromtypes-option.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/AST/ast-dump-fpfeatures.cpp
  clang/test/CodeGen/compound-assign-overflow.c
  clang/test/Sema/matrix-type-operators.c
  clang/test/Sema/nullability.c
  clang/test/Sema/sugar-common-types.c
  clang/test/SemaCXX/matrix-type-operators.cpp
  clang/test/SemaCXX/sugar-common-types.cpp
  clang/test/SemaCXX/sugared-auto.cpp
  clang/test/SemaObjC/format-strings-objc.m
  compiler-rt/test/ubsan/TestCases/Integer/add-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/no-recover.cpp
  compiler-rt/test/ubsan/TestCases/Integer/sub-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/uadd-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
  compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
  lldb/test/API/commands/expression/rdar42038760/main.c
  lldb/test/API/commands/expression/rdar44436068/main.c

Index: lldb/test/API/commands/expression/rdar44436068/main.c
===
--- lldb/test/API/commands/expression/rdar44436068/main.c
+++ lldb/test/API/commands/expression/rdar44436068/main.c
@@ -3,6 +3,6 @@
 __int128_t n = 1;
 n = n + n;
 return n; //%self.expect("p n", substrs=['(__int128_t) $0 = 2'])
-  //%self.expect("p n + 6", substrs=['(__int128) $1 = 8'])
-  //%self.expect("p n + n", substrs=['(__int128) $2 = 4'])
+  //%self.expect("p n + 6", substrs=['(__int128_t) $1 = 8'])
+  //%self.expect("p n + n", substrs=['(__int128_t) $2 = 4'])
 }
Index: lldb/test/API/commands/expression/rdar42038760/main.c
===
--- lldb/test/API/commands/expression/rdar42038760/main.c
+++ lldb/test/API/commands/expression/rdar42038760/main.c
@@ -10,7 +10,7 @@
   struct S0 l_19;
   l_19.f2 = 419;
   uint32_t l_4037 = 4294967295UL;
-  l_19.f2 = g_463; //%self.expect("expr ((l_4037 % (-(g_463))) | l_19.f2)", substrs=['(unsigned int) $0 = 358717883'])
+  l_19.f2 = g_463; //%self.expect("expr ((l_4037 % (-(g_463))) | l_19.f2)", substrs=['(uint32_t) $0 = 358717883'])
 }
 int main()
 {
Index: compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
===
--- compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
+++ compiler-rt/test/ubsan/TestCases/Integer/usub-overflow.cpp
@@ -12,12 +12,12 @@
 
 #ifdef SUB_I32
   (void)(uint32_t(1) - uint32_t(2));
-  // CHECK-SUB_I32: usub-overflow.cpp:[[@LINE-1]]:22: runtime error: unsigned integer overflow: 1 - 2 cannot be represented in type 'unsigned int'
+  // CHECK-SUB_I32: usub-overflow.cpp:[[@LINE-1]]:22: runtime error: unsigned integer overflow: 1 - 2 cannot be represented in type '{{uint32_t|unsigned int}}'
 #endif
 
 #ifdef SUB_I64
   (void)(uint64_t(800ll) - uint64_t(900ll));
-  // CHECK-SUB_I64: 800 - 900 cannot be represented in type 'unsigned {{long( long)?}}'
+  // CHECK-SUB_I64: 800 - 900 cannot be represented in type '{{uint64_t|unsigned long( long)?}}'
 #endif
 
 #ifdef SUB_I128
@@ -26,6 +26,6 @@
 # else
   puts("__int128 not supported\n");
 # endif
-  // CHECK-SUB_I128: {{0x4000 - 0x8000 cannot be represented in type 'unsigned __int128'|__int128 not supported}}
+  // CHECK-SUB_I128: {{0x4000 - 0x8000 cannot be represented in type '__uint128_t'|__int128 not supported}}
 #endif
 }
Index: compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
===
--- compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
+++ compiler-rt/test/ubsan/TestCases/Integer/umul-overflow.cpp
@@ -13,7 +13,7 @@
   (void)(uint16_t(0x) * uint16_t(0x8001));
 
   (void)(uint32_t(0x) * uint32_t(0x2));
-  // CHECK: umul-overflow.cpp:15:31: runtime error: unsigned integer overflow: 4294967295 * 2 cannot be represented in type 'unsigned int'
+  // CHECK: umul-overflow.cpp:15:31: runtime error: unsigned integer overflow: 4294967295 * 2 cannot be represented in 

[PATCH] D130308: [clang] extend getCommonSugaredType to merge sugar nodes

[Matheus Izvekov via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rG16e5d6d7f98f: [clang] extend getCommonSugaredType to merge 
sugar nodes (authored by mizvekov).

Changed prior to commit:
  https://reviews.llvm.org/D130308?vs=458613&id=458788#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130308

Files:
  clang/include/clang/AST/ASTContext.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/test/SemaCXX/sugar-common-types.cpp

Index: clang/test/SemaCXX/sugar-common-types.cpp
===
--- clang/test/SemaCXX/sugar-common-types.cpp
+++ clang/test/SemaCXX/sugar-common-types.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++20 -fenable-matrix
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++20 -fenable-matrix -triple i686-pc-win32
 
 enum class N {};
 
@@ -38,3 +38,77 @@
 N t7 = X4() + Y4(); // expected-error {{rvalue of type 'B4'}}
 N t8 = X4() * Y4(); // expected-error {{rvalue of type 'B4'}}
 N t9 = X5() * Y5(); // expected-error {{rvalue of type 'A4 __attribute__((matrix_type(3, 3)))'}}
+
+template  struct S1 {
+  template  struct S2 {};
+};
+
+N t10 = 0 ? S1() : S1(); // expected-error {{from 'S1' (aka 'S1')}}
+N t11 = 0 ? S1::S2() : S1::S2(); // expected-error {{from 'S1::S2' (aka 'S2')}}
+
+template  using Al = S1;
+
+N t12 = 0 ? Al() : Al(); // expected-error {{from 'Al' (aka 'S1')}}
+
+#define AS1 __attribute__((address_space(1)))
+#define AS2 __attribute__((address_space(1)))
+using AS1X1 = AS1 B1;
+using AS1Y1 = AS1 B1;
+using AS2Y1 = AS2 B1;
+N t13 = 0 ? (AS1X1){} : (AS1Y1){}; // expected-error {{rvalue of type 'AS1 B1' (aka '__attribute__((address_space(1))) int')}}
+N t14 = 0 ? (AS1X1){} : (AS2Y1){}; // expected-error {{rvalue of type '__attribute__((address_space(1))) B1' (aka '__attribute__((address_space(1))) int')}}
+
+using FX1 = X1 ();
+using FY1 = Y1 ();
+N t15 = 0 ? (FX1*){} : (FY1*){}; // expected-error {{rvalue of type 'B1 (*)()' (aka 'int (*)()')}}
+
+struct SS1 {};
+using SB1 = SS1;
+using SX1 = SB1;
+using SY1 = SB1;
+
+using MFX1 = X1 SX1::*();
+using MFY1 = Y1 SY1::*();
+
+N t16 = 0 ? (MFX1*){} : (MFY1*){}; // expected-error {{rvalue of type 'B1 SB1::*(*)()'}}
+
+N t17 = 0 ? (FX1 SX1::*){} : (FY1 SY1::*){}; // expected-error {{rvalue of type 'B1 (SB1::*)() __attribute__((thiscall))'}}
+
+N t18 = 0 ? (__typeof(X1*)){} : (__typeof(Y1*)){}; // expected-error {{rvalue of type 'typeof(B1 *)' (aka 'int *')}}
+
+struct Enums {
+  enum X : B1;
+  enum Y : ::B1;
+};
+using EnumsB = Enums;
+using EnumsX = EnumsB;
+using EnumsY = EnumsB;
+
+N t19 = 0 ? (__underlying_type(EnumsX::X)){} : (__underlying_type(EnumsY::Y)){};
+// expected-error@-1 {{rvalue of type 'B1' (aka 'int')}}
+
+N t20 = 0 ? (__underlying_type(EnumsX::X)){} : (__underlying_type(EnumsY::X)){};
+// expected-error@-1 {{rvalue of type '__underlying_type(Enums::X)' (aka 'int')}}
+
+using SBTF1 = SS1 [[clang::btf_type_tag("1")]];
+using SBTF2 = ::SS1 [[clang::btf_type_tag("1")]];
+using SBTF3 = ::SS1 [[clang::btf_type_tag("2")]];
+
+N t21 = 0 ? (SBTF1){} : (SBTF3){}; // expected-error {{from 'SS1'}}
+N t22 = 0 ? (SBTF1){} : (SBTF2){}; // expected-error {{from 'SS1 btf_type_tag(1)' (aka 'SS1')}}
+
+using QX = const SB1 *;
+using QY = const ::SB1 *;
+N t23 = 0 ? (QX){} : (QY){}; // expected-error {{rvalue of type 'const SB1 *' (aka 'const SS1 *')}}
+
+template  using Alias = short;
+N t24 = 0 ? (Alias){} : (Alias){}; // expected-error {{rvalue of type 'Alias' (aka 'short')}}
+N t25 = 0 ? (Alias){} : (Alias){}; // expected-error {{rvalue of type 'short'}}
+
+template  concept C1 = true;
+template  concept C2 = true;
+C1 auto t26_1 = (SB1){};
+C1 auto t26_2 = (::SB1){};
+C2 auto t26_3 = (::SB1){};
+N t26 = 0 ? t26_1 : t26_2; // expected-error {{from 'SB1' (aka 'SS1')}}
+N t27 = 0 ? t26_1 : t26_3; // expected-error {{from 'SB1' (aka 'SS1')}}
Index: clang/lib/Sema/SemaTemplateDeduction.cpp
===
--- clang/lib/Sema/SemaTemplateDeduction.cpp
+++ clang/lib/Sema/SemaTemplateDeduction.cpp
@@ -3825,13 +3825,11 @@
 //   - If A is an array type, the pointer type produced by the
 // array-to-pointer standard conversion (4.2) is used in place of
 // A for type deduction; otherwise,
-if (ArgType->isArrayType())
-  ArgType = S.Context.getArrayDecayedType(ArgType);
 //   - If A is a function type, the pointer type produced by the
 // function-to-pointer standard conversion (4.3) is used in place
 // of A for type deduction; otherwise,
-else if (ArgType->isFunctionType())
-  ArgType = S.Context.getPointerType(ArgType);
+if (ArgType->canDecayToPointerType())
+  ArgType = S.Context.getDecayedType(ArgType);
 else {

[PATCH] D132977: [HLSL] Call global constructors inside entry

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/CodeGen/CGHLSLRuntime.cpp:167-170
+assert(cast(CS->getOperand(0))->getValue() == 65535 &&
+   "HLSL doesn't support setting priority for global ctors.");
+assert(isa(CS->getOperand(2)) &&
+   "HLSL doesn't support COMDat for global ctors.");

Do we have sema checks for this so users get decent diagnostics instead of a 
crash (or miscompile)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132977

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

[PATCH] D132997: [clang][Interp] Handle DeclRefExpr of reference types

[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 aside from a request for a comment in the test, thanks!




Comment at: clang/test/AST/Interp/references.cpp:91
+
+static_assert(RefToMemberExpr() == 11, ""); // expected-error{{not an integral 
constant expression}}




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

https://reviews.llvm.org/D132997

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

[PATCH] D132727: [clang][Interp] Implement array initializers and subscript expressions

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

Heads-up: after D132832  and D132727 
, clang/test/AST/Interp/arrays.cpp.test has a 
msan failure. It can be pre-existing or can be newly introduced.
There seems another issue about an integer overflow in `InitMap::isInitialized`.

Still investigating.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132727

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

[PATCH] D133499: [clang]: Add DeclContext::dumpDecl() in order to conveniently dump an AST from a DeclContext.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/AST/ASTDumper.cpp:204
+LLVM_DUMP_METHOD void DeclContext::dumpDecl() const {
+  if (const Decl *D = dyn_cast(this))
+D->dump();





Comment at: clang/lib/AST/ASTDumper.cpp:205
+  if (const Decl *D = dyn_cast(this))
+D->dump();
+}

erichkeane wrote:
> One thing to note is that the 'else' case here is a little uninformative.  
> See https://clang.llvm.org/doxygen/DeclBase_8cpp_source.html#l00915 for some 
> similar logic here (though not sure we should be emulating that).
> 
> More, I wonder if there is SOME message here that should be dumped for 'else'.
Looking at what inherits from `DeclContext`, is there use of it which is *not* 
a `Decl`? I couldn't find a use where it's not also a `Decl`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133499

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

[PATCH] D130308: [clang] extend getCommonSugaredType to merge sugar nodes

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

It looks like some of these changes are causing compiler to crash in 
`clang::ASTContext::getFloatTypeSemantics` during CUDA compilation:
https://lab.llvm.org/buildbot/#/builders/55/builds/35047

I'm currently working on narrowing down which commit is the culprit. Here's a 
snippet of the stack trace:

   #8 0x08fda385 
clang::ASTContext::getFloatTypeSemantics(clang::QualType) const 
(/buildbot/cuda-p4-0/work/clang-cuda-p4/clang/bin/clang-16+0x8fda385)
   #9 0x08927cb5 unsupportedTypeConversion(clang::Sema const&, 
clang::QualType, clang::QualType) SemaExpr.cpp:0:0
  #10 0x0894925a 
clang::Sema::CheckAssignmentConstraints(clang::QualType, 
clang::ActionResult&, clang::CastKind&, bool) 
(/buildbot/cuda-p4-0/work/clang-cuda-p4/clang/bin/clang-16+0x894925a)
  #11 0x08948e26 
clang::Sema::CheckAssignmentConstraints(clang::SourceLocation, clang::QualType, 
clang::QualType) 
(/buildbot/cuda-p4-0/work/clang-cuda-p4/clang/bin/clang-16+0x8948e26)
  #12 0x089570a7 clang::Sema::CheckAssignmentOperands(clang::Expr*, 
clang::ActionResult&, clang::SourceLocation, 
clang::QualType, clang::BinaryOperatorKind) 
(/buildbot/cuda-p4-0/work/clang-cuda-p4/clang/bin/clang-16+0x89570a7)
  #13 0x0893af00 clang::Sema::CreateBuiltinBinOp(clang::SourceLocation, 
clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) 
(/buildbot/cuda-p4-0/work/clang-cuda-p4/clang/bin/clang-16+0x893af00)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130308

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

[PATCH] D133499: [clang]: Add DeclContext::dumpDecl() in order to conveniently dump an AST from a DeclContext.

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/lib/AST/ASTDumper.cpp:205
+  if (const Decl *D = dyn_cast(this))
+D->dump();
+}

aaron.ballman wrote:
> erichkeane wrote:
> > One thing to note is that the 'else' case here is a little uninformative.  
> > See https://clang.llvm.org/doxygen/DeclBase_8cpp_source.html#l00915 for 
> > some similar logic here (though not sure we should be emulating that).
> > 
> > More, I wonder if there is SOME message here that should be dumped for 
> > 'else'.
> Looking at what inherits from `DeclContext`, is there use of it which is 
> *not* a `Decl`? I couldn't find a use where it's not also a `Decl`.
I've DEFINITELY run into it in the debugger before, but I have no idea WHAT 
case that is. It is sometimes just "DeclContext is an invalid pointer" kinda 
thing, so it might be worth-while to have SOME output besides "print nothing", 
particularly when debugging.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133499

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

[PATCH] D133202: [Clang] Avoid __builtin_assume_aligned crash when the 1st arg is array type

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Please look into the history of that test case to see why we're specifically 
testing for the ability to redeclare this builtin.

We could certainly allow this builtin to be redeclared using the `const void*` 
type — that doesn't really reflect the generic nature of the builtin, but it 
would work for compatibility with other compilers in the vast preponderance of 
code — but if we don't really need to do it, let's not go down that road.




Comment at: clang/lib/Sema/SemaChecking.cpp:7651-7652
+  Expr *FirstArg = TheCall->getArg(0);
+  if (auto *CE = dyn_cast(FirstArg))
+FirstArg = CE->getSubExprAsWritten();
 

yronglin wrote:
> rjmccall wrote:
> > rsmith wrote:
> > > This looks very suspicious to me: this will remove a cast expression that 
> > > was written in the source code from the AST. That loses source fidelity, 
> > > can give the wrong answer if the cast changed the value (such as a C++ 
> > > derived-to-base conversion to a non-primary base class), and in any case 
> > > this is only done once where there could be multiple explicit casts 
> > > written on an argument to the builtin, so if it's necessary, then it's 
> > > not being done fully.
> > > 
> > > Can this be removed?
> > Somehow I missed this in my review.  Yes, this line should be unnecessary, 
> > and as you say, it is definitely wrong.
> CodeGen need real `user-written-type` to generate 
> `__ubsan_handle_alignment_assumption ` 's arg, but not `const void *`
Because we're using custom type-checking here, there is no conversion to `const 
void *` in the first place; that conversion was an artifact of the earlier 
implementation.

Also, if the previous code in CodeGen looked like this, then it was buggy: it 
is incorrect in the case that someone wrote `(const void*) foo` as the 
argument, because it would inappropriately look through the explicit, 
user-provided cast.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133202

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

[PATCH] D132977: [HLSL] Call global constructors inside entry

[Chris Bieneman via Phabricator via cfe-commits]

beanz added inline comments.



Comment at: clang/lib/CodeGen/CGHLSLRuntime.cpp:167-170
+assert(cast(CS->getOperand(0))->getValue() == 65535 &&
+   "HLSL doesn't support setting priority for global ctors.");
+assert(isa(CS->getOperand(2)) &&
+   "HLSL doesn't support COMDat for global ctors.");

aaron.ballman wrote:
> Do we have sema checks for this so users get decent diagnostics instead of a 
> crash (or miscompile)?
It looks like COMDats are only attached if object format supports them (and 
DXContainer isn't properly handled there). I don't think there is any 
sema-level validation because the COMDat just binds to the global value 
address. I'll get a patch up to llvm::Triple to mark DXContainer as not 
supporting COMDat.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132977

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

[PATCH] D132977: [HLSL] Call global constructors inside entry

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/CodeGen/CGHLSLRuntime.cpp:167-170
+assert(cast(CS->getOperand(0))->getValue() == 65535 &&
+   "HLSL doesn't support setting priority for global ctors.");
+assert(isa(CS->getOperand(2)) &&
+   "HLSL doesn't support COMDat for global ctors.");

beanz wrote:
> aaron.ballman wrote:
> > Do we have sema checks for this so users get decent diagnostics instead of 
> > a crash (or miscompile)?
> It looks like COMDats are only attached if object format supports them (and 
> DXContainer isn't properly handled there). I don't think there is any 
> sema-level validation because the COMDat just binds to the global value 
> address. I'll get a patch up to llvm::Triple to mark DXContainer as not 
> supporting COMDat.
Thanks! Also be sure to add some logic to SemaDeclAttr.cpp to diagnose 
specifying a priority.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132977

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

[PATCH] D133509: Frontend: Adopt llvm::vfs::OutputBackend in CompilerInstance

[Steven Wu via Phabricator via cfe-commits]

steven_wu created this revision.
steven_wu added reviewers: sammccall, benlangmuir, raghavmedicherla, kzhuravl, 
dexonsmith.
Herald added a subscriber: ributzka.
Herald added a project: All.
steven_wu requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Adopt new virtual output backend in CompilerInstance.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D133509

Files:
  clang/include/clang/Frontend/CompilerInstance.h
  clang/lib/Frontend/CompilerInstance.cpp

Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -53,6 +53,7 @@
 #include "llvm/Support/Signals.h"
 #include "llvm/Support/TimeProfiler.h"
 #include "llvm/Support/Timer.h"
+#include "llvm/Support/VirtualOutputBackends.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
 #include 
@@ -521,6 +522,10 @@
 collectVFSEntries(*this, ModuleDepCollector);
   }
 
+  // Modules need an output manager.
+  if (!hasOutputBackend())
+createOutputBackend();
+
   for (auto &Listener : DependencyCollectors)
 Listener->attachToPreprocessor(*PP);
 
@@ -764,36 +769,19 @@
   // The ASTConsumer can own streams that write to the output files.
   assert(!hasASTConsumer() && "ASTConsumer should be reset");
   // Ignore errors that occur when trying to discard the temp file.
-  for (OutputFile &OF : OutputFiles) {
-if (EraseFiles) {
-  if (OF.File)
-consumeError(OF.File->discard());
-  if (!OF.Filename.empty())
-llvm::sys::fs::remove(OF.Filename);
-  continue;
-}
-
-if (!OF.File)
-  continue;
-
-if (OF.File->TmpName.empty()) {
-  consumeError(OF.File->discard());
-  continue;
-}
-
-// If '-working-directory' was passed, the output filename should be
-// relative to that.
-SmallString<128> NewOutFile(OF.Filename);
-FileMgr->FixupRelativePath(NewOutFile);
-
-llvm::Error E = OF.File->keep(NewOutFile);
-if (!E)
-  continue;
-
-getDiagnostics().Report(diag::err_unable_to_rename_temp)
-<< OF.File->TmpName << OF.Filename << std::move(E);
-
-llvm::sys::fs::remove(OF.File->TmpName);
+  if (!EraseFiles) {
+for (auto &O : OutputFiles)
+  llvm::handleAllErrors(
+  O.keep(),
+  [&](const llvm::vfs::TempFileOutputError &E) {
+getDiagnostics().Report(diag::err_unable_to_rename_temp)
+<< E.getTempPath() << E.getOutputPath()
+<< E.convertToErrorCode().message();
+  },
+  [&](const llvm::vfs::OutputError &E) {
+getDiagnostics().Report(diag::err_fe_unable_to_open_output)
+<< E.getOutputPath() << E.convertToErrorCode().message();
+  });
   }
   OutputFiles.clear();
   if (DeleteBuiltModules) {
@@ -827,6 +815,30 @@
   return std::make_unique();
 }
 
+void CompilerInstance::setOutputBackend(
+IntrusiveRefCntPtr NewOutputs) {
+  assert(!TheOutputBackend && "Already has an output manager");
+  TheOutputBackend = std::move(NewOutputs);
+}
+
+void CompilerInstance::createOutputBackend() {
+  assert(!TheOutputBackend && "Already has an output manager");
+  TheOutputBackend =
+  llvm::makeIntrusiveRefCnt();
+}
+
+llvm::vfs::OutputBackend &CompilerInstance::getOutputBackend() {
+  assert(TheOutputBackend);
+  return *TheOutputBackend;
+}
+
+llvm::vfs::OutputBackend &CompilerInstance::getOrCreateOutputBackend() {
+  if (!hasOutputBackend())
+createOutputBackend();
+  return getOutputBackend();
+}
+
+
 std::unique_ptr
 CompilerInstance::createOutputFile(StringRef OutputPath, bool Binary,
bool RemoveFileOnSignal, bool UseTemporary,
@@ -849,94 +861,29 @@
   assert((!CreateMissingDirectories || UseTemporary) &&
  "CreateMissingDirectories is only allowed when using temporary files");
 
-  std::unique_ptr OS;
-  Optional OSFile;
-
-  if (UseTemporary) {
-if (OutputPath == "-")
-  UseTemporary = false;
-else {
-  llvm::sys::fs::file_status Status;
-  llvm::sys::fs::status(OutputPath, Status);
-  if (llvm::sys::fs::exists(Status)) {
-// Fail early if we can't write to the final destination.
-if (!llvm::sys::fs::can_write(OutputPath))
-  return llvm::errorCodeToError(
-  make_error_code(llvm::errc::operation_not_permitted));
-
-// Don't use a temporary if the output is a special file. This handles
-// things like '-o /dev/null'
-if (!llvm::sys::fs::is_regular_file(Status))
-  UseTemporary = false;
-  }
-}
-  }
-
-  Optional Temp;
-  if (UseTemporary) {
-// Create a temporary file.
-// Insert - before the extension (if any), and because some tools
-// (noticeable, clang's own GlobalModuleIndex.cpp) glob for build
-// artifacts, also append .tmp.
-StringRef OutputExtension = llv

[PATCH] D129883: [HLSL] Support cbuffer/tbuffer for hlsl.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

(I didn't have the chance to do a complete review, but I did a partial one and 
spotted some things)




Comment at: clang/lib/Parse/ParseHLSL.cpp:79-80
+ParsedAttributes Attrs(AttrFactory);
+MaybeParseCXX11Attributes(Attrs);
+MaybeParseMicrosoftAttributes(Attrs);
+

Just double-checking, but this allows `[[]]` style attributes as well as `[]` 
style attributes, but not `__attribute__` or `__declspec` style attributes, is 
that intended?



Comment at: clang/lib/Sema/SemaHLSL.cpp:31-32
+void Sema::ActOnFinishHLSLBuffer(Decl *Dcl, SourceLocation RBrace) {
+  auto *BufDecl = dyn_cast_if_present(Dcl);
+  assert(BufDecl && "Invalid parameter, expected HLSLBufferDecl");
+  BufDecl->setRBraceLoc(RBrace);

`cast` will assert if given nullptr or the cast is invalid, so this should be 
equivalent.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129883

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

[PATCH] D133499: [clang]: Add DeclContext::dumpDecl() in order to conveniently dump an AST from a DeclContext.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/AST/ASTDumper.cpp:205
+  if (const Decl *D = dyn_cast(this))
+D->dump();
+}

erichkeane wrote:
> aaron.ballman wrote:
> > erichkeane wrote:
> > > One thing to note is that the 'else' case here is a little uninformative. 
> > >  See https://clang.llvm.org/doxygen/DeclBase_8cpp_source.html#l00915 for 
> > > some similar logic here (though not sure we should be emulating that).
> > > 
> > > More, I wonder if there is SOME message here that should be dumped for 
> > > 'else'.
> > Looking at what inherits from `DeclContext`, is there use of it which is 
> > *not* a `Decl`? I couldn't find a use where it's not also a `Decl`.
> I've DEFINITELY run into it in the debugger before, but I have no idea WHAT 
> case that is. It is sometimes just "DeclContext is an invalid pointer" kinda 
> thing, so it might be worth-while to have SOME output besides "print 
> nothing", particularly when debugging.
IIRC, the case this comes up in is when the object is only partially 
constructed, and so I agree that having an `else` clause here would be useful 
-- because this interface is predominately used from a debugger, it has to deal 
with special "impossible" situations a bit more carefully.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133499

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

[PATCH] D129883: [HLSL] Support cbuffer/tbuffer for hlsl.

[Xiang Li via Phabricator via cfe-commits]

python3kgae updated this revision to Diff 458807.
python3kgae marked 4 inline comments as done.
python3kgae added a comment.

Use cast to simplify code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129883

Files:
  clang/include/clang/AST/Decl.h
  clang/include/clang/AST/JSONNodeDumper.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/AST/TextNodeDumper.h
  clang/include/clang/Basic/DeclNodes.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/Decl.cpp
  clang/lib/AST/DeclBase.cpp
  clang/lib/AST/DeclPrinter.cpp
  clang/lib/AST/JSONNodeDumper.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/Basic/IdentifierTable.cpp
  clang/lib/Frontend/FrontendAction.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseHLSL.cpp
  clang/lib/Parse/Parser.cpp
  clang/lib/Sema/CMakeLists.txt
  clang/lib/Sema/IdentifierResolver.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaHLSL.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/AST/HLSL/Inputs/empty.hlsl
  clang/test/AST/HLSL/ast-dump-comment-cbuffe-tbufferr.hlsl
  clang/test/AST/HLSL/cbuffer_tbuffer.hlsl
  clang/test/AST/HLSL/pch_hlsl_buffer.hlsl
  clang/test/ParserHLSL/cb_error.hlsl
  clang/test/ParserHLSL/invalid_inside_cb.hlsl
  clang/test/SemaHLSL/cb_error.hlsl

Index: clang/test/SemaHLSL/cb_error.hlsl
===
--- /dev/null
+++ clang/test/SemaHLSL/cb_error.hlsl
@@ -0,0 +1,49 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl -o - -fsyntax-only %s -verify
+
+// expected-note@+1 {{declared here}}
+cbuffer a {
+  int x;
+};
+
+int foo() {
+  // expected-error@+1 {{'a' does not refer to a value}}
+  return sizeof(a);
+}
+
+// expected-error@+1 {{expected unqualified-id}}
+template  cbuffer a { Ty f; };
+
+// For back-compat reason, it is OK for multiple cbuffer/tbuffer use same name in hlsl.
+// And these cbuffer name only used for reflection, cannot be removed.
+cbuffer A {
+  float A;
+}
+
+cbuffer A {
+  float b;
+}
+
+tbuffer A {
+  float a;
+}
+
+float bar() {
+  // cbuffer/tbuffer name will not conflict with other variables.
+  return A;
+}
+
+cbuffer a {
+  // expected-error@+2 {{unknown type name 'oh'}}
+  // expected-error@+1 {{expected ';' after top level declarator}}
+  oh no!
+  // expected-warning@+1 {{missing terminating ' character}}
+  this isn't even valid HLSL code
+  despite seeming totally reasonable
+  once you understand that HLSL
+  is so flaming weird.
+}
+
+tbuffer B {
+  // expected-error@+1 {{unknown type name 'flaot'}}
+  flaot f;
+}
Index: clang/test/ParserHLSL/invalid_inside_cb.hlsl
===
--- /dev/null
+++ clang/test/ParserHLSL/invalid_inside_cb.hlsl
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl -o - -fsyntax-only %s -verify
+
+// template not allowed inside cbuffer.
+cbuffer A {
+// expected-error@+2 {{invalid declaration inside cbuffer}}
+template
+T foo(T t) { return t;}
+}
+
+cbuffer A {
+// expected-error@+2 {{invalid declaration inside cbuffer}}
+template
+struct S { float s;};
+}
+
+// typealias not allowed inside cbuffer.
+cbuffer A {
+// expected-error@+2 {{invalid declaration inside cbuffer}}
+// expected-warning@+1 {{alias declarations are a C++11 extension}}
+using F32 = float;
+}
Index: clang/test/ParserHLSL/cb_error.hlsl
===
--- /dev/null
+++ clang/test/ParserHLSL/cb_error.hlsl
@@ -0,0 +1,74 @@
+// RUN: %clang_cc1 -triple dxil-pc-shadermodel6.3-library -x hlsl -o - -fsyntax-only %s -verify
+
+// expected-error@+2 {{expected identifier}}
+// expected-error@+1 {{expected unqualified-id}}
+cbuffer { ... };
+// expected-error@+1 {{expected '{'}}
+cbuffer missing_definition;
+// expected-error@+1 {{expected unqualified-id}}
+int cbuffer;
+// expected-error@+1 {{expected identifier}}
+cbuffer;
+
+// expected-error@+2 {{expected identifier}}
+// expected-error@+1 {{expected unqualified-id}}
+tbuffer { ... };
+// expected-error@+1 {{expected '{'}}
+tbuffer missing_definition;
+// expected-error@+1 {{expected unqualified-id}}
+int tbuffer;
+// expected-error@+1 {{expected identifier}}
+tbuffer;
+
+// expected-error@+1 {{expected unqualified-id}}
+cbuffer A {}, B{}
+
+// cbuffer inside namespace is supported.
+namespace N {
+  cbuffer A {
+float g;
+  }
+}
+
+cbuffer A {
+  // expected-error@+1 {{invalid declaration inside cbuffer}}
+  namespace N {

[PATCH] D129883: [HLSL] Support cbuffer/tbuffer for hlsl.

[Xiang Li via Phabricator via cfe-commits]

python3kgae added inline comments.



Comment at: clang/lib/Parse/ParseHLSL.cpp:79-80
+ParsedAttributes Attrs(AttrFactory);
+MaybeParseCXX11Attributes(Attrs);
+MaybeParseMicrosoftAttributes(Attrs);
+

aaron.ballman wrote:
> Just double-checking, but this allows `[[]]` style attributes as well as `[]` 
> style attributes, but not `__attribute__` or `__declspec` style attributes, 
> is that intended?
That is what dxc currently support.
It may change in the future. But for now, only [[]] and [] are supported.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129883

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

[PATCH] D123630: Remove connection between 'ffast-math' and 'ffp-contract'.

[Joshua Cranmer via Phabricator via cfe-commits]

jcranmer-intel added a comment.

Some general comments on the documentation here:

One of the lesser-known issues of `-ffast-math` is the fact that it (or 
`-funsafe-math-optimizations`) causes `crtfastmath.o` to be linked, which adds 
a static constructor that sets the FTZ/DAZ bits in MXCSR, affecting not only 
the current compilation unit but all static and shared libraries included in 
the program. This behavior deserves to be mentioned somewhere in the 
documentation. Additionally, the effects of fast-math/unsafe-math-optimizations 
on fdenormal-fp-math{32} should be noted. I realize this is orthogonal to the 
actual change you're doing here, but while we're improving the documentation of 
`-f[no-]fast-math`, we should probably fix this missing documentation at the 
same time.




Comment at: clang/lib/Driver/ToolChains/Clang.cpp:2778
+  StringRef LastSeenFfpContractOption;
+  StringRef LastSeenFfastMathOption;
   if (!JA.isDeviceOffloading(Action::OFK_Cuda) &&

Given that this will only be set to "" or "fast", it probably makes sense to 
make for this be a `bool SeenFfastMathOption` variable instead.


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

https://reviews.llvm.org/D123630

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

[PATCH] D95497: Frontend: Respect -working-directory when checking if output files can be written

[Steven Wu via Phabricator via cfe-commits]

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

LGTM. I will commit this if no objection.


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

https://reviews.llvm.org/D95497

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

[PATCH] D130308: [clang] extend getCommonSugaredType to merge sugar nodes

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

The culprit appears to be D111509 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130308

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

[PATCH] D95497: Frontend: Respect -working-directory when checking if output files can be written

[Steven Wu via Phabricator via cfe-commits]

steven_wu requested changes to this revision.
steven_wu added a comment.
This revision now requires changes to proceed.

Actually, we need to fix the case when output is '-'.


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

https://reviews.llvm.org/D95497

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

[PATCH] D129883: [HLSL] Support cbuffer/tbuffer for hlsl.

[Chris Bieneman via Phabricator via cfe-commits]

beanz added inline comments.



Comment at: clang/lib/Parse/ParseHLSL.cpp:79-80
+ParsedAttributes Attrs(AttrFactory);
+MaybeParseCXX11Attributes(Attrs);
+MaybeParseMicrosoftAttributes(Attrs);
+

python3kgae wrote:
> aaron.ballman wrote:
> > Just double-checking, but this allows `[[]]` style attributes as well as 
> > `[]` style attributes, but not `__attribute__` or `__declspec` style 
> > attributes, is that intended?
> That is what dxc currently support.
> It may change in the future. But for now, only [[]] and [] are supported.
Well... worth noting, HLSL doesn't actually support C++11 attributes, but that 
is almost certainly going to change in the near future, so we might as well 
support them from the start in Clang.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129883

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

[PATCH] D111509: [clang] use getCommonSugar in an assortment of places

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

It appears that this change may result in clang crashing (e.g. it broke CUDA 
compilation: 
https://lab.llvm.org/buildbot/#/builders/55/builds/35047/steps/3/logs/stdio).

Reproducer:

  class {
typedef __complex__ a;
operator=(double b){c *= b} a c



  $bin/clang++ -cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -std=c++14 
-disable-llvm-passes -x c++ reproducer.cc
  reproducer.cc:2:11: warning: plain '_Complex' requires a type specifier; 
assuming '_Complex double'
typedef __complex__ a;
^
double
  reproducer.cc:3:3: error: a type specifier is required for all declarations
operator=(double b){c *= b} a c
^
  reproducer.cc:3:34: error: expected ';' at end of declaration list
operator=(double b){c *= b} a c
   ^
   ;
  reproducer.cc:4:1: error: expected '}'
  ^
  reproducer.cc:1:7: note: to match this '{'
  class {
^
  clang++: work/llvm/repo/llvm/include/llvm/Support/Casting.h:566: 
decltype(auto) llvm::cast(const From &) [To = clang::BuiltinType, From = 
clang::QualType]: Assertion `isa(Val) && "cast() argument of 
incompatible type!"' failed.
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.  Program arguments: bin/clang++ -cc1 -triple x86_64-unknown-linux-gnu 
-fsyntax-only -std=c++14 -disable-llvm-passes -x c++ reproducer.cc
  1.  reproducer.cc:3:29: current parser token '}'
  2.  reproducer.cc:1:1: parsing struct/union/class body '(anonymous)'
  3.  reproducer.cc:3:22: parsing function body '(anonymous 
class)::operator='
  4.  reproducer.cc:3:22: in compound statement ('{}')
   #0 0x55ad5d7fe49a llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
work/llvm/repo/llvm/lib/Support/Unix/Signals.inc:569:11
   #1 0x55ad5d7fe64b PrintStackTraceSignalHandler(void*) 
work/llvm/repo/llvm/lib/Support/Unix/Signals.inc:636:1
   #2 0x55ad5d7fcc96 llvm::sys::RunSignalHandlers() 
work/llvm/repo/llvm/lib/Support/Signals.cpp:103:5
   #3 0x55ad5d7fed75 SignalHandler(int) 
work/llvm/repo/llvm/lib/Support/Unix/Signals.inc:407:1
   #4 0x7f4b4e083200 __restore_rt 
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12200)
   #5 0x7f4b4daf28c1 raise ./signal/../sysdeps/unix/sysv/linux/raise.c:50:1
   #6 0x7f4b4dadc546 abort ./stdlib/abort.c:81:7
   #7 0x7f4b4dadc42f get_sysdep_segment_value ./intl/loadmsgcat.c:509:8
   #8 0x7f4b4dadc42f _nl_load_domain ./intl/loadmsgcat.c:970:34
   #9 0x7f4b4daeb242 (/lib/x86_64-linux-gnu/libc.so.6+0x31242)
  #10 0x55ad5e2f39e8 decltype(auto) llvm::cast(clang::QualType const&) 
work/llvm/repo/llvm/include/llvm/Support/Casting.h:567:43
  #11 0x55ad5e2f3929 clang::BuiltinType const* 
clang::Type::castAs() const 
work/llvm/build/debug/tools/clang/include/clang/AST/TypeNodes.inc:86:1
  #12 0x55ad62cfe279 
clang::ASTContext::getFloatTypeSemantics(clang::QualType) const 
work/llvm/repo/clang/lib/AST/ASTContext.cpp:1707:14
  #13 0x55ad61e8ad61 unsupportedTypeConversion(clang::Sema const&, 
clang::QualType, clang::QualType) 
work/llvm/repo/clang/lib/Sema/SemaExpr.cpp:1256:29
  #14 0x55ad61eb3961 
clang::Sema::CheckAssignmentConstraints(clang::QualType, 
clang::ActionResult&, clang::CastKind&, bool) 
work/llvm/repo/clang/lib/Sema/SemaExpr.cpp:9619:7
  #15 0x55ad61eb30c5 
clang::Sema::CheckAssignmentConstraints(clang::SourceLocation, clang::QualType, 
clang::QualType) work/llvm/repo/clang/lib/Sema/SemaExpr.cpp:9465:3
  #16 0x55ad61ec565f clang::Sema::CheckAssignmentOperands(clang::Expr*, 
clang::ActionResult&, clang::SourceLocation, 
clang::QualType, clang::BinaryOperatorKind) 
work/llvm/repo/clang/lib/Sema/SemaExpr.cpp:13919:12
  #17 0x55ad61ea1903 clang::Sema::CreateBuiltinBinOp(clang::SourceLocation, 
clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) 
work/llvm/repo/clang/lib/Sema/SemaExpr.cpp:14988:11
  #18 0x55ad61ecaf02 clang::Sema::BuildBinOp(clang::Scope*, 
clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) 
work/llvm/repo/clang/lib/Sema/SemaExpr.cpp:15511:10
  #19 0x55ad61e8a180 clang::Sema::ActOnBinOp(clang::Scope*, 
clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) 
work/llvm/repo/clang/lib/Sema/SemaExpr.cpp:15323:10
   


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111509

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

[PATCH] D127403: [clangd] Implement semantic token modifier "definition"

[David Goldman via Phabricator via cfe-commits]

dgoldman added inline comments.



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:863
+  Tok.addModifier(HighlightingModifier::Declaration);
+if (const auto Func = dyn_cast(Decl)) {
+  if (Func->isThisDeclarationADefinition())

Instead of doing it like this, I wonder if would make more sense to call 
getDefinition from 
https://cs.github.com/llvm/llvm-project/blob/ae071a59bc6cc09e0e0043e0ef1d9725853f1681/clang-tools-extra/clangd/XRefs.cpp#L76
 and if it matches Decl, add the Definition modifier?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127403

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

[PATCH] D111509: [clang] use getCommonSugar in an assortment of places

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

Thanks for the repro!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111509

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