[PATCH] D126189: [C++20][Modules] Build module static initializers per P1874R1.

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

@iains may I ask what's the issue to not land this? It looks like you're 
waiting for the behavior to be consistency with GCC?

Since this patch could fix https://github.com/llvm/llvm-project/issues/51873, 
which breaks the users to compile a hello world example.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126189

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

[clang] b646f09 - [clang-format] Fix misplacement of `*` in declaration of pointer to struct

[via cfe-commits]

Author: Huang Zhen-Hong
Date: 2022-06-29T15:21:02+08:00
New Revision: b646f0955574c6ad4c156c9db522e46f597cfda9

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

LOG: [clang-format] Fix misplacement of `*` in declaration of pointer to struct

Fixes #55810

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

Added: 


Modified: 
clang/lib/Format/TokenAnnotator.cpp
clang/unittests/Format/FormatTest.cpp
clang/unittests/Format/TokenAnnotatorTest.cpp

Removed: 




diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index 1ee95f26d1fc7..029cb9097871c 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -2314,6 +2314,31 @@ class AnnotatingParser {
 if (NextToken->isOneOf(tok::comma, tok::semi))
   return TT_PointerOrReference;
 
+// After right braces, star tokens are likely to be pointers to struct,
+// union, or class.
+//   struct {} *ptr;
+if (PrevToken->is(tok::r_brace) && Tok.is(tok::star))
+  return TT_PointerOrReference;
+
+// For "} &&"
+if (PrevToken->is(tok::r_brace) && Tok.is(tok::ampamp)) {
+  const FormatToken *MatchingLBrace = PrevToken->MatchingParen;
+
+  // We check whether there is a TemplateCloser(">") to indicate it's a
+  // template or not. If it's not a template, "&&" is likely a reference
+  // operator.
+  //   struct {} &&ref = {};
+  if (!MatchingLBrace)
+return TT_PointerOrReference;
+  FormatToken *BeforeLBrace = MatchingLBrace->getPreviousNonComment();
+  if (!BeforeLBrace || BeforeLBrace->isNot(TT_TemplateCloser))
+return TT_PointerOrReference;
+
+  // If it is a template, "&&" is a binary operator.
+  //   enable_if<>{} && ...
+  return TT_BinaryOperator;
+}
+
 if (PrevToken->Tok.isLiteral() ||
 PrevToken->isOneOf(tok::r_paren, tok::r_square, tok::kw_true,
tok::kw_false, tok::r_brace)) {

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index 972f3f195d856..d6deafe1093c8 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -10431,6 +10431,67 @@ TEST_F(FormatTest, UnderstandsUsesOfStarAndAmp) {
   "void F();",
   getGoogleStyleWithColumns(68));
 
+  FormatStyle Style = getLLVMStyle();
+  Style.PointerAlignment = FormatStyle::PAS_Left;
+  verifyFormat("struct {\n"
+   "}* ptr;",
+   Style);
+  verifyFormat("union {\n"
+   "}* ptr;",
+   Style);
+  verifyFormat("class {\n"
+   "}* ptr;",
+   Style);
+  verifyFormat("struct {\n"
+   "}&& ptr = {};",
+   Style);
+  verifyFormat("union {\n"
+   "}&& ptr = {};",
+   Style);
+  verifyFormat("class {\n"
+   "}&& ptr = {};",
+   Style);
+
+  Style.PointerAlignment = FormatStyle::PAS_Middle;
+  verifyFormat("struct {\n"
+   "} * ptr;",
+   Style);
+  verifyFormat("union {\n"
+   "} * ptr;",
+   Style);
+  verifyFormat("class {\n"
+   "} * ptr;",
+   Style);
+  verifyFormat("struct {\n"
+   "} && ptr = {};",
+   Style);
+  verifyFormat("union {\n"
+   "} && ptr = {};",
+   Style);
+  verifyFormat("class {\n"
+   "} && ptr = {};",
+   Style);
+
+  Style.PointerAlignment = FormatStyle::PAS_Right;
+  verifyFormat("struct {\n"
+   "} *ptr;",
+   Style);
+  verifyFormat("union {\n"
+   "} *ptr;",
+   Style);
+  verifyFormat("class {\n"
+   "} *ptr;",
+   Style);
+  verifyFormat("struct {\n"
+   "} &&ptr = {};",
+   Style);
+  verifyFormat("union {\n"
+   "} &&ptr = {};",
+   Style);
+  verifyFormat("class {\n"
+   "} &&ptr = {};",
+   Style);
+
   verifyIndependentOfContext("MACRO(int *i);");
   verifyIndependentOfContext("MACRO(auto *a);");
   verifyIndependentOfContext("MACRO(const A *a);");

diff  --git a/clang/unittests/Format/TokenAnnotatorTest.cpp 
b/clang/unittests/Format/TokenAnnotatorTest.cpp
index 2dbc5da07d4db..df1b052267478 100644
--- a/clang/unittests/Format/TokenAnnotatorTest.cpp
+++ b/clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -85,6 +85,32 @@ TEST_F(TokenAnnotatorTest, UnderstandsUsesOfStarAndAmp) {
   Tokens = annotate("case &x:");
   EXPECT_EQ(Tokens.size(), 5u) << Tokens;
   EXPECT_TOKEN(Tokens[1], tok::amp, TT_UnaryOperator);
+
+  Tokens = annotate("struct {\n"
+"} *ptr;");
+  EXPECT_EQ(Tokens.size(), 7u) << Tokens;
+  EXPECT_TOK

[PATCH] D127873: [clang-format] Fix misplacement of `*` in declaration of pointer to struct

[Jack Huang 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 rGb646f0955574: [clang-format] Fix misplacement of `*` in 
declaration of pointer to struct (authored by Huang Zhen-Hong 
, committed by jackhong12).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127873

Files:
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp
  clang/unittests/Format/TokenAnnotatorTest.cpp

Index: clang/unittests/Format/TokenAnnotatorTest.cpp
===
--- clang/unittests/Format/TokenAnnotatorTest.cpp
+++ clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -85,6 +85,32 @@
   Tokens = annotate("case &x:");
   EXPECT_EQ(Tokens.size(), 5u) << Tokens;
   EXPECT_TOKEN(Tokens[1], tok::amp, TT_UnaryOperator);
+
+  Tokens = annotate("struct {\n"
+"} *ptr;");
+  EXPECT_EQ(Tokens.size(), 7u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::star, TT_PointerOrReference);
+  Tokens = annotate("union {\n"
+"} *ptr;");
+  EXPECT_EQ(Tokens.size(), 7u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::star, TT_PointerOrReference);
+  Tokens = annotate("class {\n"
+"} *ptr;");
+  EXPECT_EQ(Tokens.size(), 7u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::star, TT_PointerOrReference);
+
+  Tokens = annotate("struct {\n"
+"} &&ptr = {};");
+  EXPECT_EQ(Tokens.size(), 10u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::ampamp, TT_PointerOrReference);
+  Tokens = annotate("union {\n"
+"} &&ptr = {};");
+  EXPECT_EQ(Tokens.size(), 10u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::ampamp, TT_PointerOrReference);
+  Tokens = annotate("class {\n"
+"} &&ptr = {};");
+  EXPECT_EQ(Tokens.size(), 10u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::ampamp, TT_PointerOrReference);
 }
 
 TEST_F(TokenAnnotatorTest, UnderstandsUsesOfPlusAndMinus) {
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -10431,6 +10431,67 @@
   "void F();",
   getGoogleStyleWithColumns(68));
 
+  FormatStyle Style = getLLVMStyle();
+  Style.PointerAlignment = FormatStyle::PAS_Left;
+  verifyFormat("struct {\n"
+   "}* ptr;",
+   Style);
+  verifyFormat("union {\n"
+   "}* ptr;",
+   Style);
+  verifyFormat("class {\n"
+   "}* ptr;",
+   Style);
+  verifyFormat("struct {\n"
+   "}&& ptr = {};",
+   Style);
+  verifyFormat("union {\n"
+   "}&& ptr = {};",
+   Style);
+  verifyFormat("class {\n"
+   "}&& ptr = {};",
+   Style);
+
+  Style.PointerAlignment = FormatStyle::PAS_Middle;
+  verifyFormat("struct {\n"
+   "} * ptr;",
+   Style);
+  verifyFormat("union {\n"
+   "} * ptr;",
+   Style);
+  verifyFormat("class {\n"
+   "} * ptr;",
+   Style);
+  verifyFormat("struct {\n"
+   "} && ptr = {};",
+   Style);
+  verifyFormat("union {\n"
+   "} && ptr = {};",
+   Style);
+  verifyFormat("class {\n"
+   "} && ptr = {};",
+   Style);
+
+  Style.PointerAlignment = FormatStyle::PAS_Right;
+  verifyFormat("struct {\n"
+   "} *ptr;",
+   Style);
+  verifyFormat("union {\n"
+   "} *ptr;",
+   Style);
+  verifyFormat("class {\n"
+   "} *ptr;",
+   Style);
+  verifyFormat("struct {\n"
+   "} &&ptr = {};",
+   Style);
+  verifyFormat("union {\n"
+   "} &&ptr = {};",
+   Style);
+  verifyFormat("class {\n"
+   "} &&ptr = {};",
+   Style);
+
   verifyIndependentOfContext("MACRO(int *i);");
   verifyIndependentOfContext("MACRO(auto *a);");
   verifyIndependentOfContext("MACRO(const A *a);");
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -2314,6 +2314,31 @@
 if (NextToken->isOneOf(tok::comma, tok::semi))
   return TT_PointerOrReference;
 
+// After right braces, star tokens are likely to be pointers to struct,
+// union, or class.
+//   struct {} *ptr;
+if (PrevToken->is(tok::r_brace) && Tok.is(tok::star))
+  return TT_PointerOrReference;
+
+// For "} &&"
+if (PrevToken->is(tok::r_brace) && Tok.is(tok::ampamp)) {
+  const FormatToken *MatchingLBrace = PrevToken->MatchingParen;
+
+  // We check whether there is a TemplateCloser(">") to indicate it's a
+  // template 

[PATCH] D126189: [C++20][Modules] Build module static initializers per P1874R1.

[Iain Sandoe via Phabricator via cfe-commits]

iains added a comment.

In D126189#3617850 , @ChuanqiXu wrote:

> @iains may I ask what's the issue to not land this? It looks like you're 
> waiting for the behavior to be consistency with GCC?
>
> Since this patch could fix https://github.com/llvm/llvm-project/issues/51873, 
> which breaks the users to compile a hello world example.

I need to make some typo corrections; there is no issue (I'm not waiting for 
anything) just prioritising posting patches to complete C++20 support .. will 
land this soon.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126189

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

[PATCH] D128612: RISC-V big-endian support implementation

[James Henderson via Phabricator via cfe-commits]

jhenderson added a comment.

Objcopy aspects look good, thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128612

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

[clang] b405407 - [clang][flang] Disable defaulting to `-fpie` for LLVM Flang

[Andrzej Warzynski via cfe-commits]

Author: Andrzej Warzynski
Date: 2022-06-29T07:53:06Z
New Revision: b405407a489902c0acfcf936bfda9821a1deb170

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

LOG: [clang][flang] Disable defaulting to `-fpie` for LLVM Flang

In, https://reviews.llvm.org/D120305, CLANG_DEFAULT_PIE_ON_LINUX was set
to `On` by default. However, neither `-fpie` nor `-fpic` are currently
supported in LLVM Flang. Hence, in this patch the behaviour controlled
with CLANG_DEFAULT_PIE_ON_LINUX is refined not to apply to Flang.

Another way to look at this is that CLANG_DEFAULT_PIE_ON_LINUX is
currently affecting both Clang and Flang. IIUC, the intention for this
CMake variable has always been to only affect Clang. This patch makes
sure that that's the case.

Without this change, you might see errors like this on X86_64:
```
/usr/bin/ld: main.o: relocation R_X86_64_32 against `.bss' can not be used when 
making a PIE object; recompile with -fPIC
```
I've not experienced any issues on AArch64. That's probably because on
AArch64 some object files happen to be position independent without
needing -fpie or -fpic.

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

Added: 
flang/test/Driver/pic-flags.f90

Modified: 
clang/lib/Driver/ToolChains/Linux.cpp
flang/docs/ReleaseNotes.md

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Linux.cpp 
b/clang/lib/Driver/ToolChains/Linux.cpp
index 4309b10603465..ceb1a982c3a4c 100644
--- a/clang/lib/Driver/ToolChains/Linux.cpp
+++ b/clang/lib/Driver/ToolChains/Linux.cpp
@@ -699,8 +699,11 @@ void Linux::AddIAMCUIncludeArgs(const ArgList &DriverArgs,
 }
 
 bool Linux::isPIEDefault(const llvm::opt::ArgList &Args) const {
-  return CLANG_DEFAULT_PIE_ON_LINUX || getTriple().isAndroid() ||
- getTriple().isMusl() || getSanitizerArgs(Args).requiresPIE();
+  // TODO: Remove the special treatment for Flang once its frontend driver can
+  // generate position independent code.
+  return !getDriver().IsFlangMode() &&
+ (CLANG_DEFAULT_PIE_ON_LINUX || getTriple().isAndroid() ||
+  getTriple().isMusl() || getSanitizerArgs(Args).requiresPIE());
 }
 
 bool Linux::IsAArch64OutlineAtomicsDefault(const ArgList &Args) const {

diff  --git a/flang/docs/ReleaseNotes.md b/flang/docs/ReleaseNotes.md
index b41a2aabb9733..38d5c3f0706dc 100644
--- a/flang/docs/ReleaseNotes.md
+++ b/flang/docs/ReleaseNotes.md
@@ -28,6 +28,13 @@ page](https://llvm.org/releases/).
 
 ## Non-comprehensive list of changes in this release
 * The bash wrapper script, `flang`, is renamed as `flang-to-external-fc`.
+* In contrast to Clang, Flang will not default to using `-fpie` when linking
+  executables. This is only a temporary solution and the goal is to align with
+  Clang in the near future. First, however, the frontend driver needs to be
+  extended so that it can generate position independent code (that requires
+  adding support for e.g. `-fpic` and `-mrelocation-model` in `flang-new
+  -fc1`). Once that is available, support for the `-fpie` can officially be
+  added and the default behaviour updated.
 
 ## New Compiler Flags
 * Refined how `-f{no-}color-diagnostics` is treated to better align with Clang.

diff  --git a/flang/test/Driver/pic-flags.f90 b/flang/test/Driver/pic-flags.f90
new file mode 100644
index 0..4e6b9796cb4a1
--- /dev/null
+++ b/flang/test/Driver/pic-flags.f90
@@ -0,0 +1,24 @@
+! Verify that in contrast to Clang, Flang does not default to generating 
position independent executables/code
+
+!-
+! RUN COMMANDS
+!-
+! RUN: %flang -### %s --target=aarch64-linux-gnu 2>&1 | FileCheck %s 
--check-prefix=CHECK-NOPIE
+! RUN: %flang -### %s --target=aarch64-linux-gnu -fno-pie 2>&1 | FileCheck %s 
--check-prefix=CHECK-NOPIE
+
+! RUN: %flang -### %s --target=aarch64-linux-gnu -fpie 2>&1 | FileCheck %s 
--check-prefix=CHECK-PIE
+
+!
+! EXPECTED OUTPUT
+!
+! CHECK-NOPIE: "-fc1"
+! CHECk-NOPIE-NOT: "-fpic"
+! CHECK-NOPIE: "{{.*}}ld"
+! CHECK-NOPIE-NOT: "-pie"
+
+! CHECK-PIE: "-fc1"
+!! TODO Once Flang supports `-fpie`, it //should// use -fpic when invoking 
`flang -fc1`. Update the following line once `-fpie` is
+! available.
+! CHECk-PIE-NOT: "-fpic"
+! CHECK-PIE: "{{.*}}ld"
+! CHECK-PIE-NOT: "-pie"



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

[PATCH] D128333: [clang][flang] Disable defaulting to `-fpie` for LLVM Flang

[Andrzej Warzynski via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGb405407a4899: [clang][flang] Disable defaulting to `-fpie` 
for LLVM Flang (authored by awarzynski).

Changed prior to commit:
  https://reviews.llvm.org/D128333?vs=440874&id=440884#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128333

Files:
  clang/lib/Driver/ToolChains/Linux.cpp
  flang/docs/ReleaseNotes.md
  flang/test/Driver/pic-flags.f90


Index: flang/test/Driver/pic-flags.f90
===
--- /dev/null
+++ flang/test/Driver/pic-flags.f90
@@ -0,0 +1,24 @@
+! Verify that in contrast to Clang, Flang does not default to generating 
position independent executables/code
+
+!-
+! RUN COMMANDS
+!-
+! RUN: %flang -### %s --target=aarch64-linux-gnu 2>&1 | FileCheck %s 
--check-prefix=CHECK-NOPIE
+! RUN: %flang -### %s --target=aarch64-linux-gnu -fno-pie 2>&1 | FileCheck %s 
--check-prefix=CHECK-NOPIE
+
+! RUN: %flang -### %s --target=aarch64-linux-gnu -fpie 2>&1 | FileCheck %s 
--check-prefix=CHECK-PIE
+
+!
+! EXPECTED OUTPUT
+!
+! CHECK-NOPIE: "-fc1"
+! CHECk-NOPIE-NOT: "-fpic"
+! CHECK-NOPIE: "{{.*}}ld"
+! CHECK-NOPIE-NOT: "-pie"
+
+! CHECK-PIE: "-fc1"
+!! TODO Once Flang supports `-fpie`, it //should// use -fpic when invoking 
`flang -fc1`. Update the following line once `-fpie` is
+! available.
+! CHECk-PIE-NOT: "-fpic"
+! CHECK-PIE: "{{.*}}ld"
+! CHECK-PIE-NOT: "-pie"
Index: flang/docs/ReleaseNotes.md
===
--- flang/docs/ReleaseNotes.md
+++ flang/docs/ReleaseNotes.md
@@ -28,6 +28,13 @@
 
 ## Non-comprehensive list of changes in this release
 * The bash wrapper script, `flang`, is renamed as `flang-to-external-fc`.
+* In contrast to Clang, Flang will not default to using `-fpie` when linking
+  executables. This is only a temporary solution and the goal is to align with
+  Clang in the near future. First, however, the frontend driver needs to be
+  extended so that it can generate position independent code (that requires
+  adding support for e.g. `-fpic` and `-mrelocation-model` in `flang-new
+  -fc1`). Once that is available, support for the `-fpie` can officially be
+  added and the default behaviour updated.
 
 ## New Compiler Flags
 * Refined how `-f{no-}color-diagnostics` is treated to better align with Clang.
Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -699,8 +699,11 @@
 }
 
 bool Linux::isPIEDefault(const llvm::opt::ArgList &Args) const {
-  return CLANG_DEFAULT_PIE_ON_LINUX || getTriple().isAndroid() ||
- getTriple().isMusl() || getSanitizerArgs(Args).requiresPIE();
+  // TODO: Remove the special treatment for Flang once its frontend driver can
+  // generate position independent code.
+  return !getDriver().IsFlangMode() &&
+ (CLANG_DEFAULT_PIE_ON_LINUX || getTriple().isAndroid() ||
+  getTriple().isMusl() || getSanitizerArgs(Args).requiresPIE());
 }
 
 bool Linux::IsAArch64OutlineAtomicsDefault(const ArgList &Args) const {


Index: flang/test/Driver/pic-flags.f90
===
--- /dev/null
+++ flang/test/Driver/pic-flags.f90
@@ -0,0 +1,24 @@
+! Verify that in contrast to Clang, Flang does not default to generating position independent executables/code
+
+!-
+! RUN COMMANDS
+!-
+! RUN: %flang -### %s --target=aarch64-linux-gnu 2>&1 | FileCheck %s --check-prefix=CHECK-NOPIE
+! RUN: %flang -### %s --target=aarch64-linux-gnu -fno-pie 2>&1 | FileCheck %s --check-prefix=CHECK-NOPIE
+
+! RUN: %flang -### %s --target=aarch64-linux-gnu -fpie 2>&1 | FileCheck %s --check-prefix=CHECK-PIE
+
+!
+! EXPECTED OUTPUT
+!
+! CHECK-NOPIE: "-fc1"
+! CHECk-NOPIE-NOT: "-fpic"
+! CHECK-NOPIE: "{{.*}}ld"
+! CHECK-NOPIE-NOT: "-pie"
+
+! CHECK-PIE: "-fc1"
+!! TODO Once Flang supports `-fpie`, it //should// use -fpic when invoking `flang -fc1`. Update the following line once `-fpie` is
+! available.
+! CHECk-PIE-NOT: "-fpic"
+! CHECK-PIE: "{{.*}}ld"
+! CHECK-PIE-NOT: "-pie"
Index: flang/docs/ReleaseNotes.md
===
--- flang/docs/ReleaseNotes.md
+++ flang/docs/ReleaseNotes.md
@@ -28,6 +28,13 @@
 
 ## Non-comprehensive list of changes in this release
 * The bash wrapper script, `flang`, is renamed as `flang-to-external-fc`.
+* In contrast to Clang, Flang will not default to using `-fpie` when linking
+  executables. This is only a temporary solution and the goal is to align with
+  Clang in the near future. First, however, the frontend driver needs to be
+  extended so that it can generate position independent code (that requ

[PATCH] D128783: Check for more -fsanitize=array-bounds regressions

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

Do we need a C test (just add a `-x c` RUN line)? @serge-sans-paille Do you 
think we may likely make C++ stricter than C?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128783

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

[PATCH] D128645: Update developer policy.

[Edd Barrett via Phabricator via cfe-commits]

vext01 added inline comments.



Comment at: llvm/docs/DeveloperPolicy.rst:88
+#. Patches should be unified diffs with "infinite context" (i.e. using 
something
+   like `git diff -U99 main`).
+

hubert.reinterpretcast wrote:
> Using `git diff` like this, there are risks that `main` is now ahead of your 
> branch's base. Probably safer to use `HEAD~n` where `n` is the number of 
> commits you have on your branch.
> 
The exact command you want to issue is going to vary according to circumstance 
and personal workflow preference. Sometimes `main` is fine, if it isn't 
`HEAD~n` is fine, but if you have a lot of commits then determining (i.e. 
manually counting) `n` will be impractical and you probably want to just use an 
absolute git hash.

I don't think we need to delve into a great level of detail. I think the prose 
"using something like" is adequate.


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

https://reviews.llvm.org/D128645

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

[PATCH] D128645: Update developer policy.

[Edd Barrett via Phabricator via cfe-commits]

vext01 updated this revision to Diff 440887.
vext01 added a comment.

Fixed grammar bits.


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

https://reviews.llvm.org/D128645

Files:
  llvm/docs/DeveloperPolicy.rst


Index: llvm/docs/DeveloperPolicy.rst
===
--- llvm/docs/DeveloperPolicy.rst
+++ llvm/docs/DeveloperPolicy.rst
@@ -84,30 +84,12 @@
patches may not apply correctly if the underlying code changes between the
time the patch was created and the time it is applied.
 
-#. Patches should be made with ``git format-patch``, or similar (see special
-   commands for `Requesting Phabricator review via the web interface
-   `_ ). If you use a
-   different tool, make sure it uses the ``diff -u`` format and that it
-   doesn't contain clutter which makes it hard to read.
-
-Once your patch is ready, submit it by emailing it to the appropriate project's
-commit mailing list (or commit it directly if applicable). Alternatively, some
-patches get sent to the project's development list or component of the LLVM bug
-tracker, but the commit list is the primary place for reviews and should
-generally be preferred.
-
-When sending a patch to a mailing list, it is a good idea to send it as an
-*attachment* to the message, not embedded into the text of the message.  This
-ensures that your mailer will not mangle the patch when it sends it (e.g. by
-making whitespace changes or by wrapping lines).
-
-*For Thunderbird users:* Before submitting a patch, please open *Preferences >
-Advanced > General > Config Editor*, find the key
-``mail.content_disposition_type``, and set its value to ``1``. Without this
-setting, Thunderbird sends your attachment using ``Content-Disposition: 
inline``
-rather than ``Content-Disposition: attachment``. Apple Mail gamely displays 
such
-a file inline, making it difficult to work with for reviewers using that
-program.
+#. Patches should be unified diffs with "infinite context" (i.e. using 
something
+   like `git diff -U99 main`).
+
+#. Once you have created your patch, create a
+   `Phabricator review `_ for
+   it (or commit it directly if applicable).
 
 When submitting patches, please do not add confidentiality or non-disclosure
 notices to the patches themselves.  These notices conflict with the LLVM
@@ -416,9 +398,11 @@
 provide the name and email address you would like to use in the Author
 property of the commit.
 
-Your first commit to a repository may require the autogenerated email to be
-approved by a moderator of the mailing list.
-This is normal and will be done when the mailing list owner has time.
+For external tracking purposes, committed changes are automatically reflected
+on a commits mailing list soon after the commit lands (e.g. llvm-commits_).
+Note that these mailing lists are moderated, and it is not unusual for a large
+commit to require a moderator to approve the email, so do not be concerned if a
+commit does not immediately appear in the archives.
 
 If you have recently been granted commit access, these policies apply:
 


Index: llvm/docs/DeveloperPolicy.rst
===
--- llvm/docs/DeveloperPolicy.rst
+++ llvm/docs/DeveloperPolicy.rst
@@ -84,30 +84,12 @@
patches may not apply correctly if the underlying code changes between the
time the patch was created and the time it is applied.
 
-#. Patches should be made with ``git format-patch``, or similar (see special
-   commands for `Requesting Phabricator review via the web interface
-   `_ ). If you use a
-   different tool, make sure it uses the ``diff -u`` format and that it
-   doesn't contain clutter which makes it hard to read.
-
-Once your patch is ready, submit it by emailing it to the appropriate project's
-commit mailing list (or commit it directly if applicable). Alternatively, some
-patches get sent to the project's development list or component of the LLVM bug
-tracker, but the commit list is the primary place for reviews and should
-generally be preferred.
-
-When sending a patch to a mailing list, it is a good idea to send it as an
-*attachment* to the message, not embedded into the text of the message.  This
-ensures that your mailer will not mangle the patch when it sends it (e.g. by
-making whitespace changes or by wrapping lines).
-
-*For Thunderbird users:* Before submitting a patch, please open *Preferences >
-Advanced > General > Config Editor*, find the key
-``mail.content_disposition_type``, and set its value to ``1``. Without this
-setting, Thunderbird sends your attachment using ``Content-Disposition: inline``
-rather than ``Content-Disposition: attachment``. Apple Mail gamely displays such
-a file inline, making it difficult to work with for reviewers using that
-program.
+#. Patches should be unified diffs with "infinite context" (i.e. using something
+   like `git diff -U99 main`).
+
+#. Once you have created your patch, crea

[PATCH] D127189: [clang][AIX] Add option to control quadword lock free atomics ABI on AIX

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

I am ok with this change overall, I just have a couple of questions about 
naming of the option.

1. Is there any precedent for options that start with `-maix` or `-m` for 
any other OS?
2. Is `quadword` the best word to use? There is no type information and this is 
restricted to integers. Would something like `-maix-i128-atomics` be a better 
name?
3. Since this is kind of an ABI-related decision, would it make sense (and 
would it be possible) to make this a further suboption to the `-mabi` option? 
Something like `-mabi=vec-extabi,i128-atomics,ieeelongdouble`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127189

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

[PATCH] D128612: RISC-V big-endian support implementation

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

lld/ELF change should be dropped from this change. Don't use 
`config->endianness`.
I feel sad that for little-endian users who don't use big-endian, every write 
now is slightly slower due to a check ;-)




Comment at: clang/lib/Basic/Targets/RISCV.cpp:124
   Builder.defineMacro("__riscv");
-  bool Is64Bit = getTriple().getArch() == llvm::Triple::riscv64;
+  bool Is64Bit = (getTriple().getArch() == llvm::Triple::riscv64 ||
+  getTriple().getArch() == llvm::Triple::riscv64be);

The convention doesn't add `()` in such an assignment.



Comment at: clang/lib/Basic/Targets/RISCV.cpp:220
 
-  if (getTriple().getArch() == llvm::Triple::riscv64) {
+  if (getTriple().getArch() == llvm::Triple::riscv64 ||
+  getTriple().getArch() == llvm::Triple::riscv64be) {

This can be simplified with something like `isRISCV64()`



Comment at: clang/lib/Basic/Targets/RISCV.h:144
+
+StringRef LayoutEndianness = Triple.isLittleEndian() ? "e" : "E";
+

You may use a `char` and possibly fold this into the expression below.



Comment at: clang/lib/Basic/Targets/RISCV.h:145
+StringRef LayoutEndianness = Triple.isLittleEndian() ? "e" : "E";
+
+resetDataLayout(

delete blank line


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128612

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

[PATCH] D127189: [clang][AIX] Add option to control quadword lock free atomics ABI on AIX

[Kai Luo via Phabricator via cfe-commits]

lkail added a comment.

> Is there any precedent for options that start with -maix or -m for any 
> other OS?

There is `-maix-struct-return`.

> Is quadword the best word to use? There is no type information and this is 
> restricted to integers. Would something like -maix-i128-atomics be a better 
> name?

'quadword' is used in ISA manual, so I follow it. Not merely `i128`, some 
struct types are also included, like

  struct Q {
char c[16];
  };



> Since this is kind of an ABI-related decision, would it make sense (and would 
> it be possible) to make this a further suboption to the -mabi option?

This makes sense. I'll try this solution.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127189

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

[PATCH] D105584: [MLIR][OpenMP] Distribute Construct Operation

[Abid via Phabricator via cfe-commits]

abidmalikwaterloo added a comment.

In D105584#3617666 , @clementval 
wrote:

> In D105584#3617456 , 
> @abidmalikwaterloo wrote:
>
>>   // CHECK-LABEL: omp_DistributeOp
>>   func.func @omp_DistributeOp(%lb : index, %ub : index, %step : index, 
>> %data_var : memref, %chunk_var : i32) -> () {
>>  // CHECK: omp.DistributeOp collapse(2)
>> "omp.DistributeOp" (%lb, %ub, %step) ({
>>   ^bb0(%iv: index):
>>omp.yield
>> }) {operand_segment_sizes = dense<[1,1,1,0,0]> : vector<5xi32>, 
>> collapse_val = 2} :
>>   (index, index, index) -> ()
>>
>>return
>>}
>>
>> Is this a valid test case for the operation?
>
> Should it be `"omp.distribute" (%lb, %ub, %step) ({`?

Yes. It should be. The rest should be okay? But, the test is failing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105584

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

[PATCH] D128679: [pseudo] Define a clangPseudoCLI library.

[Sam McCall via Phabricator via cfe-commits]

sammccall accepted this revision.
sammccall added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/pseudo/benchmarks/Benchmark.cpp:51
 const std::string *SourceText = nullptr;
-const Grammar *G = nullptr;
+const Language *PLang = nullptr;
 

nit: still PLang here and in a bunch of places



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/ParseLang.h:1
+//===--- ParseLang.h --- -*- 
C++-*-===//
+//

hokein wrote:
> sammccall wrote:
> > The "ParseLang" name doesn't feel right to me :-(
> > 
> > I think it's a combination of:
> >  - Lang is unneccesarily abbreviated
> >  - "Parse" doesn't actually disambiguate much, as "parse" is the whole 
> > project
> > 
> > Do you think `clang::pseudo::Language` would work?
> > 
> > 
> > (Sorry for not realizing this on the previous pass, I know it's a pain... 
> > happy to chat more offline)
> That sounds good to me. Regarding the location of this file, I think the 
> subdir grammar will be a better fit.
The main purpose of the `grammar` library is to minimize the amount of stuff we 
pull into the gen step right?

I'm a bit concerned about mixing clang::LangOptions in there unneccesarily - if 
grammar doesn't *need* the header, maybe it's OK where it is?



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/cli/CLI.h:9
+//
+// This file implements a CLI library, which provides an interface for getting
+// the basic pieces of psuedoparser (Grammar, LRTable etc) from a variety of

nit: "this file implements a CLI library which provides an interface for" is 
boilerplate.
Just "Provides the Grammar, LRTable etc for a language specified by flags"?



Comment at: clang-tools-extra/pseudo/lib/cli/CLI.cpp:42
+auto G = Grammar::parseBNF(GrammarText->get()->getBuffer(), Diags);
+if (!Diags.empty()) {
+  for (const auto &Diag : Diags)

hokein wrote:
> sammccall wrote:
> > this if() isn't needed unless you want to print a header to provide some 
> > context (which might be a good idea)
> I don't get your point of the comment.  Not sure what you meant by  `Print a 
> header`? 
> 
> I think for the CLI tool use-case, printing the diagnostic of the grammar by 
> default is reasonable.
You could replace

```
if (!Diags.empty())
 for(D : Diags)
...
```

with just: 
```
for (D : Diags)
  ...
```

unless you would prefer:
```
if (!Diags.empty()) {
  errs() << "Problems with the grammar:\n";
  for (D : Diags)
...
}
```

(Yesterday I thought the last one would be clearer, today I'm not so sure)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128679

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

[PATCH] D128652: [PowerPC] Finished kill_canary implementation and debugging

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a comment.

"Made a new phabricator review because of git issues" is not an appropriate 
description of a review/revision.

Hopefully the description you add will describe what this intrinsic is supposed 
to do. It seems to me that this is a poorly designed feature if it is meant to 
work the way it was implemented. Namely, it seems like this intrinsic clobbers 
the stack protect global value rather than clobbering the corresponding value 
on the stack for the specific function it is enclosed in. I would have thought 
that it will clobber the stack in the function, thereby allowing stack 
protection to work as expected for other functions in the module.




Comment at: llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp:5014
+
+if (IntrinsicID == Intrinsic::ppc_kill_canary) {
+  CurDAG->SelectNodeTo(N, PPC::NOP, MVT::Other, N->getOperand(0));

I think it would be preferable to handle this intrinsic in one place. The `nop` 
is not actually necessary here. We should simply remove the intrinsic from the 
stream in `PPCISelLowering.cpp` and not pass it on.



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11132
+  case Intrinsic::ppc_kill_canary: { 
+MachineFunction &MF = DAG.getMachineFunction();
+if (MF.getFunction().hasFnAttribute(Attribute::SafeStack) ||

The formatting of this entire block is quite messed up. Please run 
`clang-format` on this.



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11138
+
+IRBuilder<> B(&MF.getFunction().getEntryBlock().front());
+

Do we use this?



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11144
+
+if (GV == nullptr) break;
+EVT VT = DAG.getTargetLoweringInfo().getValueType(DAG.getDataLayout(), 
GV->getType(), true); 

Is it ok to just ignore a failure to get the GV here? Should this not be an 
assert?



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:11156-11168
+SDValue Store = DAG.getStore( 
+Op->getOperand(0), 
+DL,
+   DAG.getNode(
+ISD::XOR,
+   DL,
+   VT,

What is happening here? We load the value, XOR it with itself, store it again? 
Isn't that just zeroing it out? Why do we even need to load it then?



Comment at: llvm/test/CodeGen/PowerPC/kill-canary-intrinsic.ll:2
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   --ppc-asm-full-reg-names < %s | FileCheck %s

At the very least, this has to also include a RUN line for Linux.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128652

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

[PATCH] D128329: [clangd] Also mark output arguments of operator call expressions

[Christian Kandeler via Phabricator via cfe-commits]

ckandeler added a comment.

In D128329#3617172 , @nridge wrote:

> I'm going to take the liberty of approving this, as it seems straightforward 
> and unlikely to be contentious in any way.

Thanks!

> Please let me know if you need me to commit it.

Yes, please.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128329

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

[PATCH] D124690: [clangd] add inlay hints for std::forward-ed parameter packs

[Sam McCall via Phabricator via cfe-commits]

sammccall added inline comments.



Comment at: clang-tools-extra/clangd/InlayHints.cpp:478
   bool shouldHintReference(const ParmVarDecl *Param) {
-// If the parameter is a non-const reference type, print an inlay hint
+// If the parameter is of non-const l-value reference type not originating
+// from an unresolved expanded pack, print an inlay hint

The new condition is nonobvious, but the new comment just echoes the code.

Instead add a second sentence explaining *why*.
(I can't provide a suggestion, because I don't understand why)



Comment at: clang-tools-extra/clangd/InlayHints.cpp:483
+   !Type.getNonReferenceType().isConstQualified() &&
+   !isExpandedParameterPack(Param);
   }

nridge wrote:
> sammccall wrote:
> > why is this check needed if we already decline to provide a name for the 
> > parameter on line 534 in chooseParameterNames?
> `shouldHintName` and `shouldHintReference` are [two independent 
> conditions](https://searchfox.org/llvm/rev/508eb41d82ca956c30950d9a16b522a29aeeb333/clang-tools-extra/clangd/InlayHints.cpp#411-418)
>  governing whether we show the parameter name and/or a `&` indicating 
> pass-by-mutable-ref, respectively
> 
> (I did approve the [patch](https://reviews.llvm.org/D124359) that introduced 
> `shouldHintReference` myself, hope that's ok)
Thanks, that makes sense! I just hadn't understood that change.



Comment at: clang-tools-extra/clangd/InlayHints.cpp:483
+   !Type.getNonReferenceType().isConstQualified() &&
+   !isExpandedParameterPack(Param);
   }

sammccall wrote:
> nridge wrote:
> > sammccall wrote:
> > > why is this check needed if we already decline to provide a name for the 
> > > parameter on line 534 in chooseParameterNames?
> > `shouldHintName` and `shouldHintReference` are [two independent 
> > conditions](https://searchfox.org/llvm/rev/508eb41d82ca956c30950d9a16b522a29aeeb333/clang-tools-extra/clangd/InlayHints.cpp#411-418)
> >  governing whether we show the parameter name and/or a `&` indicating 
> > pass-by-mutable-ref, respectively
> > 
> > (I did approve the [patch](https://reviews.llvm.org/D124359) that 
> > introduced `shouldHintReference` myself, hope that's ok)
> Thanks, that makes sense! I just hadn't understood that change.
What exactly *is* the motivation for suppressing reference hints in the pack 
case?

(I can imagine there are cases where they're annoying, but it's hard to know if 
the condition is right without knowing what those are)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124690

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

[PATCH] D128612: RISC-V big-endian support implementation

[Guy Benyei via Phabricator via cfe-commits]

gbenyei added a comment.

In D128612#3617906 , @jhenderson 
wrote:

> Objcopy aspects look good, thanks.

Thanks




Comment at: llvm/lib/ExecutionEngine/JITLink/ELF_riscv.cpp:554
 .buildGraph();
-  } else {
-assert((*ELFObj)->getArch() == Triple::riscv32 &&
-   "Invalid triple for RISCV ELF object file");
+  } else if ((*ELFObj)->getArch() == Triple::riscv64be) {
+auto &ELFObjFile = cast>(**ELFObj);

jrtc27 wrote:
> Why switch to this order when before you've used 32, 64, 32be, 64be as the 
> order
The order in the code before my changes is 64, 32. I guess for no good reason, 
but I prefer not to re-order code while implementing a feature - it trashes git 
history.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128612

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

[PATCH] D128612: RISC-V big-endian support implementation

[Guy Benyei via Phabricator via cfe-commits]

gbenyei added a comment.

In D128612#3617955 , @MaskRay wrote:

> lld/ELF change should be dropped from this change. Don't use 
> `config->endianness`.
> I feel sad that for little-endian users who don't use big-endian, every write 
> now is slightly slower due to a check ;-)

Hi, I'm not sure I get it. How will we have a fully functional toolchain, if I 
don't implement the lld/ELF part?
In LLVM, unlike in GCC, target related decisions happen in runtime. I think 
it's a high level design decision. While I can understand the pain of LE 
developers getting a slightly slower linker due to endianness checking, I sure 
will feel the pain of a BE developer not having a linker...

Please explain why I shouldn't use `config->endianness`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128612

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

[PATCH] D124748: [clang-format] Fix whitespace counting stuff

[Kevin Cadieux via Phabricator via cfe-commits]

kevcadieux added a comment.

@sstwcw @HazardyKnusperkeks : this change introduced a regression in one of the 
clang format unit tests. I fixed it in the revision below. Could anyone please 
take a look / approve this revision to unblock Windows debug builds? Thanks!

https://reviews.llvm.org/D128786


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124748

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

[PATCH] D128786: [clang-format] Fix incorrect isspace input (NFC)

[Kevin Cadieux via Phabricator via cfe-commits]

kevcadieux added a comment.

FYI: failure looks like the following:

  [ RUN  ] FormatTest.IncorrectUnbalancedBracesInMacrosWithUnicode
  Exception Code: 0x8003
   #0 0x7ffe4253fc44 (C:\WINDOWS\SYSTEM32\ucrtbased.dll+0x7fc44)
   #1 0x7ffe4254a379 (C:\WINDOWS\SYSTEM32\ucrtbased.dll+0x8a379)
   #2 0x7ffe4254a245 (C:\WINDOWS\SYSTEM32\ucrtbased.dll+0x8a245)
   #3 0x7ffe4254a896 (C:\WINDOWS\SYSTEM32\ucrtbased.dll+0x8a896)
   #4 0x7ff649e04088 clang::format::countLeadingWhitespace 
D:\github\llvm-project\clang\lib\Format\FormatTokenLexer.cpp:869:0
   #5 0x7ff649e02184 clang::format::FormatTokenLexer::getNextToken(void) 
D:\github\llvm-project\clang\lib\Format\FormatTokenLexer.cpp:912:0
   #6 0x7ff649dfdd79 clang::format::FormatTokenLexer::lex(void) 
D:\github\llvm-project\clang\lib\Format\FormatTokenLexer.cpp:80:0
   #7 0x7ff649e97a3b clang::format::TokenAnalyzer::process(void) 
D:\github\llvm-project\clang\lib\Format\TokenAnalyzer.cpp:109:0
   #8 0x7ff649db28d6 ::operator() 
D:\github\llvm-project\clang\lib\Format\Format.cpp:3277:0
   #9 0x7ff649dd00d8 std::invoke< 
&,clang::format::Environment const &> C:\Program Files (x86)\Microsoft Visual 
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\type_traits:1534:0
  #10 0x7ff649dbf2e8 
std::_Invoker_ret,0>::_Call< 
&,clang::format::Environment const &> C:\Program Files (x86)\Microsoft Visual 
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\functional:660:0
  #11 0x7ff649db40b7 
std::_Func_impl_no_alloc<,std::pair,clang::format::Environment const &>::_Do_call C:\Program Files 
(x86)\Microsoft Visual 
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\functional:822:0
  #12 0x7ff649de48a5 std::_Func_class, class clang::format::Environment 
const &>::operator()(class clang::format::Environment const &) const C:\Program 
Files (x86)\Microsoft Visual 
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\include\functional:869:0
  #13 0x7ff649da8575 clang::format::internal::reformat(struct 
clang::format::FormatStyle const &, class llvm::StringRef, class 
llvm::ArrayRef, unsigned int, unsigned int, 
unsigned int, class llvm::StringRef, struct 
clang::format::FormattingAttemptStatus *) 
D:\github\llvm-project\clang\lib\Format\Format.cpp:3321:0
  #14 0x7ff649da5659 clang::format::reformat(struct 
clang::format::FormatStyle const &, class llvm::StringRef, class 
llvm::ArrayRef, class llvm::StringRef, struct 
clang::format::FormattingAttemptStatus *) 
D:\github\llvm-project\clang\lib\Format\Format.cpp:3346:0
  #15 0x7ff6497bc403 clang::format::`anonymous 
namespace'::FormatTest::format 
D:\github\llvm-project\clang\unittests\Format\FormatTest.cpp:43:0
  #16 0x7ff6497bd3a5 clang::format::`anonymous 
namespace'::FormatTest::verifyNoCrash 
D:\github\llvm-project\clang\unittests\Format\FormatTest.cpp:107:0
  #17 0x7ff64983abc3 clang::format::`anonymous 
namespace'::FormatTest_IncorrectUnbalancedBracesInMacrosWithUnicode_Test::TestBody
 D:\github\llvm-project\clang\unittests\Format\FormatTest.cpp:12178:0
  #18 0x7ff649ce991d 
testing::internal::HandleSehExceptionsInMethodIfSupported(class testing::Test *, void (__cdecl testing::Test::*)(void), char const 
*) D:\github\llvm-project\llvm\utils\unittest\googletest\src\gtest.cc:2418:0
  #19 0x7ff649ce977c 
testing::internal::HandleExceptionsInMethodIfSupported(class testing::Test *, void (__cdecl testing::Test::*)(void), char const 
*) D:\github\llvm-project\llvm\utils\unittest\googletest\src\gtest.cc:2488:0
  #20 0x7ff649cc61eb testing::Test::Run(void) 
D:\github\llvm-project\llvm\utils\unittest\googletest\src\gtest.cc:2515:0
  #21 0x7ff649cc6c56 testing::TestInfo::Run(void) 
D:\github\llvm-project\llvm\utils\unittest\googletest\src\gtest.cc:2687:0
  #22 0x7ff649cc72ee testing::TestSuite::Run(void) 
D:\github\llvm-project\llvm\utils\unittest\googletest\src\gtest.cc:2817:0
  #23 0x7ff649ccd668 testing::internal::UnitTestImpl::RunAllTests(void) 
D:\github\llvm-project\llvm\utils\unittest\googletest\src\gtest.cc:5339:0
  #24 0x7ff649ce9b0d 
testing::internal::HandleSehExceptionsInMethodIfSupported(class testing::internal::UnitTestImpl *, 
bool (__cdecl testing::internal::UnitTestImpl::*)(void), char const *) 
D:\github\llvm-project\llvm\utils\unittest\googletest\src\gtest.cc:2418:0
  #25 0x7ff649ce98cc 
testing::internal::HandleExceptionsInMethodIfSupported(class testing::internal::UnitTestImpl *, 
bool (__cdecl testing::internal::UnitTestImpl::*)(void), char const *) 
D:\github\llvm-project\llvm\utils\unittest\googletest\src\gtest.cc:2488:0
  #26 0x7ff649cc7940 testing::UnitTest::Run(void) 
D:\github\llvm-project\llvm\utils\unittest\googletest\src\gtest.cc:4925:0
  #27 0x7ff64a061043 RUN_ALL_TESTS(void) 
D:\github\llvm-project\llvm\utils\unittest\googletest\include\gtest\gtest.h:2473:0
  #28 0x7ff64a060fbe main 
D:\github\llvm-project\llvm\utils\unittest\UnitTestMain\TestMain.cpp:56:0
  #29 0x0

[PATCH] D128795: [pseudo] Reimplement hardcoded error handling as a recovery strategy. NFC

[Sam McCall via Phabricator via cfe-commits]

sammccall created this revision.
sammccall added a reviewer: hokein.
Herald added a project: All.
sammccall requested review of this revision.
Herald added subscribers: cfe-commits, alextsao1999.
Herald added a project: clang-tools-extra.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128795

Files:
  clang-tools-extra/pseudo/include/clang-pseudo/grammar/Grammar.h
  clang-tools-extra/pseudo/lib/GLR.cpp
  clang-tools-extra/pseudo/lib/grammar/GrammarBNF.cpp

Index: clang-tools-extra/pseudo/lib/grammar/GrammarBNF.cpp
===
--- clang-tools-extra/pseudo/lib/grammar/GrammarBNF.cpp
+++ clang-tools-extra/pseudo/lib/grammar/GrammarBNF.cpp
@@ -106,9 +106,10 @@
 
 assert(T->Rules.size() < (1 << RuleBits) &&
"Too many rules to fit in RuleID bits!");
-// Wherever RHS contains { foo }, mark foo for brace-recovery.
-// FIXME: this should be grammar annotations instead.
+// Infer recovery strategies.
 for (auto &Rule : T->Rules) {
+  // Wherever RHS contains { foo }, mark foo for brace-recovery.
+  // FIXME: this should be grammar annotations instead.
   for (unsigned I = 2; I < Rule.Size; ++I)
 if (Rule.Sequence[I] == tokenSymbol(tok::r_brace) &&
 Rule.Sequence[I - 2] == tokenSymbol(tok::l_brace) &&
@@ -116,6 +117,12 @@
   Rule.Recovery = RecoveryStrategy::Braces;
   Rule.RecoveryIndex = I - 1;
 }
+  // In `_ := symbol`, match symbol against the whole input on error.
+  // This ensures the overall parse never fails.
+  if (T->Nonterminals[Rule.Target].Name == "_") {
+Rule.Recovery = RecoveryStrategy::Eof;
+Rule.RecoveryIndex = 0;
+  }
 }
 const auto &SymbolOrder = getTopologicalOrder(T.get());
 llvm::stable_sort(
Index: clang-tools-extra/pseudo/lib/GLR.cpp
===
--- clang-tools-extra/pseudo/lib/GLR.cpp
+++ clang-tools-extra/pseudo/lib/GLR.cpp
@@ -30,13 +30,21 @@
 findRecoveryEndpoint(RecoveryStrategy Strategy,
  const GSS::Node *RecoveryNode,
  const TokenStream &Tokens) {
-  assert(Strategy == RecoveryStrategy::Braces);
-  const ForestNode *LBrace = RecoveryNode->Payload;
-  assert(LBrace->kind() == ForestNode::Terminal &&
- LBrace->symbol() == tokenSymbol(tok::l_brace));
-  if (const Token *RBrace = Tokens.tokens()[LBrace->startTokenIndex()].pair())
-return Tokens.index(*RBrace);
-  return llvm::None;
+  switch (Strategy) {
+  case RecoveryStrategy::Braces: {
+const ForestNode *LBrace = RecoveryNode->Payload;
+assert(LBrace->kind() == ForestNode::Terminal &&
+   LBrace->symbol() == tokenSymbol(tok::l_brace));
+if (const Token *RBrace = Tokens.tokens()[LBrace->startTokenIndex()].pair())
+  return Tokens.index(*RBrace);
+return llvm::None;
+  }
+  case RecoveryStrategy::Eof:
+return Tokens.tokens().size();
+  case RecoveryStrategy::None:
+break;
+  }
+  llvm_unreachable("Invalid strategy");
 }
 
 } // namespace
@@ -589,10 +597,7 @@
 // so we can keep parsing.
 if (NextHeads.empty()) {
   glrRecover(Heads, I, Tokens, Params, NextHeads);
-  if (NextHeads.empty())
-// FIXME: Ensure the `_ := start-symbol` rules have a fallback
-// error-recovery strategy attached. Then this condition can't happen.
-return Params.Forest.createOpaque(StartSymbol, /*Token::Index=*/0);
+  assert(!NextHeads.empty() && "No fallback recovery?!");
 } else
   ++I;
 
@@ -631,12 +636,9 @@
   unsigned I = Terminals.size();
   glrRecover(Heads, I, Tokens, Params, NextHeads);
   Reduce(NextHeads, tokenSymbol(tok::eof));
-  if (auto *Result = SearchForAccept(NextHeads))
-return *Result;
-
-  // We failed to parse the input, returning an opaque forest node for recovery.
-  // FIXME: as above, we can add fallback error handling so this is impossible.
-  return Params.Forest.createOpaque(StartSymbol, /*Token::Index=*/0);
+  auto *Result = SearchForAccept(NextHeads);
+  assert(Result && "No fallback recovery?");
+  return *Result;
 }
 
 void glrReduce(std::vector &Heads, SymbolID Lookahead,
Index: clang-tools-extra/pseudo/include/clang-pseudo/grammar/Grammar.h
===
--- clang-tools-extra/pseudo/include/clang-pseudo/grammar/Grammar.h
+++ clang-tools-extra/pseudo/include/clang-pseudo/grammar/Grammar.h
@@ -86,7 +86,7 @@
 }
 // Error recovery strategies.
 // FIXME: these should be provided as extensions instead.
-enum class RecoveryStrategy : uint8_t { None, Braces };
+enum class RecoveryStrategy : uint8_t { None, Braces, Eof };
 
 // An extension is a piece of native code specific to a grammar that modifies
 // the behavior of annotated rules. One ExtensionID is assigned for each unique
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https

[PATCH] D122768: [Clang][C++20] Support capturing structured bindings in lambdas

[Corentin Jabot via Phabricator via cfe-commits]

cor3ntin updated this revision to Diff 440912.
cor3ntin added a comment.

- fix typo
- add decompositions tests for the array and tuuple cases


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122768

Files:
  clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.cpp
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/AST/LambdaCapture.h
  clang/include/clang/AST/Stmt.h
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/ScopeInfo.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/DeclCXX.cpp
  clang/lib/AST/ExprCXX.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/Analysis/AnalysisDeclContext.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Sema/ScopeInfo.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/WebKit/UncountedLambdaCapturesChecker.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/lib/StaticAnalyzer/Core/LoopUnrolling.cpp
  clang/test/CodeGenCXX/cxx20-decomposition.cpp
  clang/test/SemaCXX/cxx1z-decomposition.cpp
  clang/test/SemaCXX/cxx20-decomposition.cpp
  clang/test/SemaCXX/decomposition-blocks.cpp
  clang/test/SemaCXX/decomposition-openmp.cpp
  clang/tools/libclang/CIndex.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1144,7 +1144,7 @@
 
   Structured binding extensions
   https://wg21.link/p1091r3";>P1091R3
-  Partial
+  Clang 15
 
   
 https://wg21.link/p1381r1";>P1381R1
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -3468,9 +3468,11 @@
C != CEnd; ++C) {
 if (!C->capturesVariable())
   continue;
-
-if (Visit(MakeCursorVariableRef(C->getCapturedVar(), C->getLocation(),
-TU)))
+// TODO: handle structured bindings here ?
+if (!isa(C->getCapturedVar()))
+  continue;
+if (Visit(MakeCursorVariableRef(cast(C->getCapturedVar()),
+C->getLocation(), TU)))
   return true;
   }
   // Visit init captures
Index: clang/test/SemaCXX/decomposition-openmp.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/decomposition-openmp.cpp
@@ -0,0 +1,13 @@
+
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++20 -fopenmp %s
+
+// FIXME: OpenMP should support capturing structured bindings
+auto f() {
+  int i[2] = {};
+  auto [a, b] = i; // expected-note 2{{declared here}}
+  return [=, &a] {
+// expected-error@-1 {{capturing a structured binding is not yet supported in OpenMP}}
+return a + b;
+// expected-error@-1 {{capturing a structured binding is not yet supported in OpenMP}}
+  };
+}
Index: clang/test/SemaCXX/decomposition-blocks.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/decomposition-blocks.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -verify %s -fblocks
+
+struct S {
+  int i : 1;
+  int j;
+};
+
+void run(void (^)());
+void test() {
+  auto [i, j] = S{1, 42}; // expected-note {{'i' declared here}}
+  run(^{
+(void)i; // expected-error {{reference to local binding 'i' declared in enclosing function 'test'}}
+  });
+}
Index: clang/test/SemaCXX/cxx20-decomposition.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx20-decomposition.cpp
@@ -0,0 +1,141 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify %s
+// expected-no-diagnostics
+
+template 
+constexpr bool is_same = false;
+template 
+constexpr bool is_same = true;
+
+struct S {
+  int i;
+  int &j;
+};
+
+void check_category() {
+  int a = 42;
+  {
+auto [v, r] = S{1, a};
+(void)[ v, r ] {
+  static_assert(is_same);
+  static_assert(is_same);
+};
+  }
+  {
+auto [v, r] = S{1, a};
+(void)[&v, &r ] {
+  static_assert(is_same);
+  static_assert(is_same);
+};
+  }
+  {
+S s{1, a};
+const auto &[v, r] = s;
+(void)[ v, r ] {
+  static_assert(is_same);
+  static_assert(is_same);
+};
+  }
+ 

[PATCH] D126694: [C++20][Modules] Implementation of GMF decl elision.

[Iain Sandoe via Phabricator via cfe-commits]

iains updated this revision to Diff 440915.
iains marked an inline comment as done.
iains added a comment.

rebased after D113545  was landed and removed 
that as a parent.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126694

Files:
  clang/include/clang/AST/DeclBase.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Decl.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaModule.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaStmtAsm.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/test/AST/ast-dump-decl.c
  clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp
  clang/test/Modules/cxx-templates.cpp
  clang/test/Modules/cxx20-10-4-ex2.cpp

Index: clang/test/Modules/cxx20-10-4-ex2.cpp
===
--- /dev/null
+++ clang/test/Modules/cxx20-10-4-ex2.cpp
@@ -0,0 +1,60 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+
+// RUN: %clang_cc1 -std=c++20 std-10-4-ex2-interface.cpp \
+// RUN:  -emit-module-interface -o M.pcm -Wno-unused-value
+// RUN: %clang_cc1 -std=c++20 std-10-4-ex2-implementation.cpp \
+// RUN:  -fmodule-file=M.pcm -fsyntax-only -verify
+//--- std-10-4-ex2.h
+
+namespace N {
+struct X {};
+int d();
+int e();
+inline int f(X, int = d()) { return e(); }
+int g(X);
+int h(X);
+} // namespace N
+
+//--- std-10-4-ex2-interface.cpp
+
+module;
+
+#include "std-10-4-ex2.h"
+
+export module M;
+
+template  int use_f() {
+  N::X x;   // N::X, N, and  ::  are decl-reachable from use_f
+  return f(x, 123); // N::f is decl-reachable from use_f,
+// N::e is indirectly decl-reachable from use_f
+//   because it is decl-reachable from N::f, and
+// N::d is decl-reachable from use_f
+//   because it is decl-reachable from N::f
+//   even though it is not used in this call
+}
+
+template  int use_g() {
+  N::X x; // N::X, N, and :: are decl-reachable from use_g
+  return g((T(), x)); // N::g is not decl-reachable from use_g
+}
+
+template  int use_h() {
+  N::X x; // N::X, N, and :: are decl-reachable from use_h
+  return h((T(), x)); // N::h is not decl-reachable from use_h, but
+  // N::h is decl-reachable from use_h
+}
+
+int k = use_h();
+// use_h is decl-reachable from k, so
+// N::h is decl-reachable from k
+
+//--- std-10-4-ex2-implementation.cpp
+
+module M;
+
+int a = use_f();
+int b = use_g(); // expected-er...@std-10-4-ex2-interface.cpp:20 {{use of undeclared identifier 'g'}}
+  // expected-note@-1 {{in instantiation of function template specialization 'use_g' requested here}}
+int c = use_h();
Index: clang/test/Modules/cxx-templates.cpp
===
--- clang/test/Modules/cxx-templates.cpp
+++ clang/test/Modules/cxx-templates.cpp
@@ -252,7 +252,7 @@
 // CHECK-DUMP:  ClassTemplateDecl {{.*}} <{{.*[/\\]}}cxx-templates-common.h:1:1, {{.*}}>  col:{{.*}} in cxx_templates_common SomeTemplate
 // CHECK-DUMP:ClassTemplateSpecializationDecl {{.*}} prev {{.*}} SomeTemplate
 // CHECK-DUMP-NEXT: TemplateArgument type 'char[2]'
-// CHECK-DUMP:ClassTemplateSpecializationDecl {{.*}} SomeTemplate definition
+// CHECK-DUMP:ClassTemplateSpecializationDecl {{.*}} SomeTemplate Visible definition
 // CHECK-DUMP-NEXT: DefinitionData
 // CHECK-DUMP-NEXT:   DefaultConstructor
 // CHECK-DUMP-NEXT:   CopyConstructor
@@ -263,7 +263,7 @@
 // CHECK-DUMP-NEXT: TemplateArgument type 'char[2]'
 // CHECK-DUMP:ClassTemplateSpecializationDecl {{.*}} prev {{.*}} SomeTemplate
 // CHECK-DUMP-NEXT: TemplateArgument type 'char[1]'
-// CHECK-DUMP:ClassTemplateSpecializationDecl {{.*}} SomeTemplate definition
+// CHECK-DUMP:ClassTemplateSpecializationDecl {{.*}} SomeTemplate Visible definition
 // CHECK-DUMP-NEXT: DefinitionData
 // CHECK-DUMP-NEXT:   DefaultConstructor
 // CHECK-DUMP-NEXT:   CopyConstructor
Index: clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp
===
--- clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp
+++ clang/test/CXX/basic/basic.scope/basic.scope.namespace/p2.cpp
@@ -29,9 +29,8 @@
 #endif
 
 void test_early() {
-  in_header = 1; // expected-error {{missing '#include "foo.h"'; 'in_header' must be declared before it is used}}
-  // expected-note@* {{not visible}}
-
+  in_header = 1;  // expected-error {{m

[PATCH] D126694: [C++20][Modules] Implementation of GMF decl elision.

[Iain Sandoe via Phabricator via cfe-commits]

iains added inline comments.



Comment at: clang/include/clang/AST/DeclBase.h:624
   bool isModulePrivate() const {
 return getModuleOwnershipKind() == ModuleOwnershipKind::ModulePrivate;
   }

ChuanqiXu wrote:
> According to the opinion from @rsmith, the discarded declaration is private 
> too.
I guess you mean `>=`  ... however Discardable is a stronger constraint than 
Private 

If a decl remains marked Discardable (after the processing to determine 
reachable ones) that means it is both unreachable and invisible.
So it must not participate in any processing (with the one exception of 
diagnostic output).  I would be concerned that the change you suggest above 
could cause a  Discardable decl to be considered in merging  or lookup and we 
would then need (maybe a lot) of logic like:

```
 if (D->isModulePrivate() && !D->isModuleDiscardable())
...
```

I will take a look on the next iteration.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126694

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

[clang] 32aac7b - [NFC] Switch FloatModeKind enum class to use bitmask enums

[Jolanta Jensen via cfe-commits]

Author: Jolanta Jensen
Date: 2022-06-29T11:02:02+01:00
New Revision: 32aac7babfdd2a7e6d40cb186d676bef93bfc6bb

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

LOG: [NFC] Switch FloatModeKind enum class to use bitmask enums

Using bitmask enums simplifies and clarifies the code.

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

Added: 


Modified: 
clang/include/clang/Basic/TargetInfo.h
clang/lib/Basic/Targets/X86.h

Removed: 




diff  --git a/clang/include/clang/Basic/TargetInfo.h 
b/clang/include/clang/Basic/TargetInfo.h
index 3ed47559ab4d0..0ab3e9b67dfe8 100644
--- a/clang/include/clang/Basic/TargetInfo.h
+++ b/clang/include/clang/Basic/TargetInfo.h
@@ -15,6 +15,7 @@
 #define LLVM_CLANG_BASIC_TARGETINFO_H
 
 #include "clang/Basic/AddressSpaces.h"
+#include "clang/Basic/BitmaskEnum.h"
 #include "clang/Basic/CodeGenOptions.h"
 #include "clang/Basic/LLVM.h"
 #include "clang/Basic/LangOptions.h"
@@ -52,14 +53,14 @@ class MacroBuilder;
 namespace Builtin { struct Info; }
 
 enum class FloatModeKind {
-  NoFloat = 255,
-  Half = 0,
-  Float,
-  Double,
-  LongDouble,
-  Float128,
-  Ibm128,
-  Last = Ibm128
+  NoFloat = 0,
+  Half = 1 << 0,
+  Float = 1 << 1,
+  Double = 1 << 2,
+  LongDouble = 1 << 3,
+  Float128 = 1 << 4,
+  Ibm128 = 1 << 5,
+  LLVM_MARK_AS_BITMASK_ENUM(Ibm128)
 };
 
 /// Fields controlling how types are laid out in memory; these may need to
@@ -221,7 +222,9 @@ class TargetInfo : public virtual TransferrableTargetInfo,
   mutable VersionTuple PlatformMinVersion;
 
   unsigned HasAlignMac68kSupport : 1;
-  unsigned RealTypeUsesObjCFPRetMask : (int)FloatModeKind::Last + 1;
+  unsigned RealTypeUsesObjCFPRetMask
+  : llvm::BitmaskEnumDetail::bitWidth(
+(int)FloatModeKind::LLVM_BITMASK_LARGEST_ENUMERATOR);
   unsigned ComplexLongDoubleUsesFP2Ret : 1;
 
   unsigned HasBuiltinMSVaList : 1;
@@ -890,9 +893,7 @@ class TargetInfo : public virtual TransferrableTargetInfo,
   /// Check whether the given real type should use the "fpret" flavor of
   /// Objective-C message passing on this target.
   bool useObjCFPRetForRealType(FloatModeKind T) const {
-assert(T <= FloatModeKind::Last &&
-   "T value is larger than RealTypeUsesObjCFPRetMask can handle");
-return RealTypeUsesObjCFPRetMask & (1 << (int)T);
+return RealTypeUsesObjCFPRetMask & llvm::BitmaskEnumDetail::Underlying(T);
   }
 
   /// Check whether _Complex long double should use the "fp2ret" flavor

diff  --git a/clang/lib/Basic/Targets/X86.h b/clang/lib/Basic/Targets/X86.h
index 007d5c23ec4c7..78e444f4e4eb0 100644
--- a/clang/lib/Basic/Targets/X86.h
+++ b/clang/lib/Basic/Targets/X86.h
@@ -14,6 +14,7 @@
 #define LLVM_CLANG_LIB_BASIC_TARGETS_X86_H
 
 #include "OSTargets.h"
+#include "clang/Basic/BitmaskEnum.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/Basic/TargetOptions.h"
 #include "llvm/ADT/Triple.h"
@@ -419,8 +420,8 @@ class LLVM_LIBRARY_VISIBILITY X86_32TargetInfo : public 
X86TargetInfo {
 
 // Use fpret for all types.
 RealTypeUsesObjCFPRetMask =
-((1 << (int)FloatModeKind::Float) | (1 << (int)FloatModeKind::Double) |
- (1 << (int)FloatModeKind::LongDouble));
+(int)(FloatModeKind::Float | FloatModeKind::Double |
+  FloatModeKind::LongDouble);
 
 // x86-32 has atomics up to 8 bytes
 MaxAtomicPromoteWidth = 64;
@@ -699,7 +700,7 @@ class LLVM_LIBRARY_VISIBILITY X86_64TargetInfo : public 
X86TargetInfo {
 "64-i64:64-f80:128-n8:16:32:64-S128");
 
 // Use fpret only for long double.
-RealTypeUsesObjCFPRetMask = (1 << (int)FloatModeKind::LongDouble);
+RealTypeUsesObjCFPRetMask = (int)FloatModeKind::LongDouble;
 
 // Use fp2ret for _Complex long double.
 ComplexLongDoubleUsesFP2Ret = true;



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

[PATCH] D128182: [NFC] Switch FloatModeKind enum class to use bitmask enums

[Jolanta Jensen via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG32aac7babfdd: [NFC] Switch FloatModeKind enum class to use 
bitmask enums (authored by jolanta.jensen).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128182

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/X86.h


Index: clang/lib/Basic/Targets/X86.h
===
--- clang/lib/Basic/Targets/X86.h
+++ clang/lib/Basic/Targets/X86.h
@@ -14,6 +14,7 @@
 #define LLVM_CLANG_LIB_BASIC_TARGETS_X86_H
 
 #include "OSTargets.h"
+#include "clang/Basic/BitmaskEnum.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/Basic/TargetOptions.h"
 #include "llvm/ADT/Triple.h"
@@ -419,8 +420,8 @@
 
 // Use fpret for all types.
 RealTypeUsesObjCFPRetMask =
-((1 << (int)FloatModeKind::Float) | (1 << (int)FloatModeKind::Double) |
- (1 << (int)FloatModeKind::LongDouble));
+(int)(FloatModeKind::Float | FloatModeKind::Double |
+  FloatModeKind::LongDouble);
 
 // x86-32 has atomics up to 8 bytes
 MaxAtomicPromoteWidth = 64;
@@ -699,7 +700,7 @@
 "64-i64:64-f80:128-n8:16:32:64-S128");
 
 // Use fpret only for long double.
-RealTypeUsesObjCFPRetMask = (1 << (int)FloatModeKind::LongDouble);
+RealTypeUsesObjCFPRetMask = (int)FloatModeKind::LongDouble;
 
 // Use fp2ret for _Complex long double.
 ComplexLongDoubleUsesFP2Ret = true;
Index: clang/include/clang/Basic/TargetInfo.h
===
--- clang/include/clang/Basic/TargetInfo.h
+++ clang/include/clang/Basic/TargetInfo.h
@@ -15,6 +15,7 @@
 #define LLVM_CLANG_BASIC_TARGETINFO_H
 
 #include "clang/Basic/AddressSpaces.h"
+#include "clang/Basic/BitmaskEnum.h"
 #include "clang/Basic/CodeGenOptions.h"
 #include "clang/Basic/LLVM.h"
 #include "clang/Basic/LangOptions.h"
@@ -52,14 +53,14 @@
 namespace Builtin { struct Info; }
 
 enum class FloatModeKind {
-  NoFloat = 255,
-  Half = 0,
-  Float,
-  Double,
-  LongDouble,
-  Float128,
-  Ibm128,
-  Last = Ibm128
+  NoFloat = 0,
+  Half = 1 << 0,
+  Float = 1 << 1,
+  Double = 1 << 2,
+  LongDouble = 1 << 3,
+  Float128 = 1 << 4,
+  Ibm128 = 1 << 5,
+  LLVM_MARK_AS_BITMASK_ENUM(Ibm128)
 };
 
 /// Fields controlling how types are laid out in memory; these may need to
@@ -221,7 +222,9 @@
   mutable VersionTuple PlatformMinVersion;
 
   unsigned HasAlignMac68kSupport : 1;
-  unsigned RealTypeUsesObjCFPRetMask : (int)FloatModeKind::Last + 1;
+  unsigned RealTypeUsesObjCFPRetMask
+  : llvm::BitmaskEnumDetail::bitWidth(
+(int)FloatModeKind::LLVM_BITMASK_LARGEST_ENUMERATOR);
   unsigned ComplexLongDoubleUsesFP2Ret : 1;
 
   unsigned HasBuiltinMSVaList : 1;
@@ -890,9 +893,7 @@
   /// Check whether the given real type should use the "fpret" flavor of
   /// Objective-C message passing on this target.
   bool useObjCFPRetForRealType(FloatModeKind T) const {
-assert(T <= FloatModeKind::Last &&
-   "T value is larger than RealTypeUsesObjCFPRetMask can handle");
-return RealTypeUsesObjCFPRetMask & (1 << (int)T);
+return RealTypeUsesObjCFPRetMask & llvm::BitmaskEnumDetail::Underlying(T);
   }
 
   /// Check whether _Complex long double should use the "fp2ret" flavor


Index: clang/lib/Basic/Targets/X86.h
===
--- clang/lib/Basic/Targets/X86.h
+++ clang/lib/Basic/Targets/X86.h
@@ -14,6 +14,7 @@
 #define LLVM_CLANG_LIB_BASIC_TARGETS_X86_H
 
 #include "OSTargets.h"
+#include "clang/Basic/BitmaskEnum.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/Basic/TargetOptions.h"
 #include "llvm/ADT/Triple.h"
@@ -419,8 +420,8 @@
 
 // Use fpret for all types.
 RealTypeUsesObjCFPRetMask =
-((1 << (int)FloatModeKind::Float) | (1 << (int)FloatModeKind::Double) |
- (1 << (int)FloatModeKind::LongDouble));
+(int)(FloatModeKind::Float | FloatModeKind::Double |
+  FloatModeKind::LongDouble);
 
 // x86-32 has atomics up to 8 bytes
 MaxAtomicPromoteWidth = 64;
@@ -699,7 +700,7 @@
 "64-i64:64-f80:128-n8:16:32:64-S128");
 
 // Use fpret only for long double.
-RealTypeUsesObjCFPRetMask = (1 << (int)FloatModeKind::LongDouble);
+RealTypeUsesObjCFPRetMask = (int)FloatModeKind::LongDouble;
 
 // Use fp2ret for _Complex long double.
 ComplexLongDoubleUsesFP2Ret = true;
Index: clang/include/clang/Basic/TargetInfo.h
===
--- clang/include/clang/Basic/TargetInfo.h
+++ clang/include/clang/Basic/TargetInfo.h
@@ -15,6 +15,7 @@
 #define LLVM_CLANG_BASIC_TARGETINFO_H
 
 #include "clang/Basic/AddressSpaces.h"
+#include "clang/Basic/BitmaskEnum.h"
 #include "clang/Basic/CodeGenOptions.h"
 #include "cla

[PATCH] D124690: [clangd] add inlay hints for std::forward-ed parameter packs

[Tobias Ribizel via Phabricator via cfe-commits]

upsj updated this revision to Diff 440921.
upsj marked 14 inline comments as done.
upsj added a comment.

- simplify parameter pack detection
- improve function naming
- make handling of unexpanded packs and varargs more visible
- add tests involving template specializations
- make documentation more descriptive


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124690

Files:
  clang-tools-extra/clangd/AST.cpp
  clang-tools-extra/clangd/AST.h
  clang-tools-extra/clangd/InlayHints.cpp
  clang-tools-extra/clangd/unittests/InlayHintTests.cpp

Index: clang-tools-extra/clangd/unittests/InlayHintTests.cpp
===
--- clang-tools-extra/clangd/unittests/InlayHintTests.cpp
+++ clang-tools-extra/clangd/unittests/InlayHintTests.cpp
@@ -174,6 +174,43 @@
   )cpp");
 }
 
+TEST(ParameterHints, NoNameVariadicDeclaration) {
+  // No hint for anonymous variadic parameter
+  assertParameterHints(R"cpp(
+template 
+void foo(Args&& ...);
+void bar() {
+  foo(42);
+}
+  )cpp");
+}
+
+TEST(ParameterHints, NoNameVariadicForwarded) {
+  // No hint for anonymous variadic parameter
+  // This prototype of std::forward is sufficient for clang to recognize it
+  assertParameterHints(R"cpp(
+namespace std { template  T&& forward(T&); }
+void foo(int);
+template 
+void bar(Args&&... args) { return foo(std::forward(args)...); }
+void baz() {
+  bar(42);
+}
+  )cpp");
+}
+
+TEST(ParameterHints, NoNameVariadicPlain) {
+  // No hint for anonymous variadic parameter
+  assertParameterHints(R"cpp(
+void foo(int);
+template 
+void bar(Args&&... args) { return foo(args...); }
+void baz() {
+  bar(42);
+}
+  )cpp");
+}
+
 TEST(ParameterHints, NameInDefinition) {
   // Parameter name picked up from definition if necessary.
   assertParameterHints(R"cpp(
@@ -186,6 +223,36 @@
ExpectedHint{"param: ", "param"});
 }
 
+TEST(ParameterHints, NamePartiallyInDefinition) {
+  // Parameter name picked up from definition if necessary.
+  assertParameterHints(R"cpp(
+void foo(int, int b);
+void bar() {
+  foo($param1[[42]], $param2[[42]]);
+}
+void foo(int a, int) {};
+  )cpp",
+   ExpectedHint{"a: ", "param1"},
+   ExpectedHint{"b: ", "param2"});
+}
+
+TEST(ParameterHints, NameInDefinitionVariadic) {
+  // Parameter name picked up from definition in a resolved forwarded parameter.
+  assertParameterHints(R"cpp(
+void foo(int, int);
+template 
+void bar(Args... args) {
+  foo(args...);
+}
+void baz() {
+  bar($param1[[42]], $param2[[42]]);
+}
+void foo(int a, int b) {};
+  )cpp",
+   ExpectedHint{"a: ", "param1"},
+   ExpectedHint{"b: ", "param2"});
+}
+
 TEST(ParameterHints, NameMismatch) {
   // Prefer name from declaration.
   assertParameterHints(R"cpp(
@@ -258,6 +325,389 @@
ExpectedHint{"param: ", "param"});
 }
 
+TEST(ParameterHints, VariadicForwardedConstructor) {
+  // Name hint for variadic parameter using std::forward in a constructor call
+  // This prototype of std::forward is sufficient for clang to recognize it
+  assertParameterHints(R"cpp(
+namespace std { template  T&& forward(T&); }
+struct S { S(int a); };
+template 
+T bar(Args&&... args) { return T{std::forward(args)...}; }
+void baz() {
+  int b;
+  bar($param[[b]]);
+}
+  )cpp",
+   ExpectedHint{"a: ", "param"});
+}
+
+TEST(ParameterHints, VariadicPlainConstructor) {
+  // Name hint for variadic parameter in a constructor call
+  assertParameterHints(R"cpp(
+struct S { S(int a); };
+template 
+T bar(Args&&... args) { return T{args...}; }
+void baz() {
+  int b;
+  bar($param[[b]]);
+}
+  )cpp",
+   ExpectedHint{"a: ", "param"});
+}
+
+TEST(ParameterHints, VariadicForwardedNewConstructor) {
+  // Name hint for variadic parameter using std::forward in a new expression
+  // This prototype of std::forward is sufficient for clang to recognize it
+  assertParameterHints(R"cpp(
+namespace std { template  T&& forward(T&); }
+struct S { S(int a); };
+template 
+T* bar(Args&&... args) { return new T{std::forward(args)...}; }
+void baz() {
+  int b;
+  bar($param[[b]]);
+}
+  )cpp",
+   ExpectedHint{"a: ", "param"});
+}
+
+TEST(ParameterHints, VariadicPlainNewConstructor) {
+  // Name hint for variadic parameter in a new expression
+  assertParameterHints(R"cpp(
+struct S { S(int a); };
+template 
+T* bar(Args&&... args) { return new T{args...}; }
+void baz() {
+  int b;
+  bar($param[[b]]);
+}
+  )cpp",
+   ExpectedHint{"a: ", "param"});
+}
+
+TEST(ParameterHints, VariadicForwarded) {
+  // Name for variadi

[PATCH] D124690: [clangd] add inlay hints for std::forward-ed parameter packs

[Tobias Ribizel via Phabricator via cfe-commits]

upsj added inline comments.



Comment at: clang-tools-extra/clangd/AST.cpp:690
+getPackTemplateParameter(const FunctionDecl *Callee) {
+  if (const auto *TemplateDecl = Callee->getPrimaryTemplate()) {
+auto TemplateParams = TemplateDecl->getTemplateParameters()->asArray();

sammccall wrote:
> This is doing something pretty strange if Callee is a function template 
> specialization.
> 
> It's not clear to me whether this function should be handling that case 
> (which AFAICS it doesn't, but could inspect the specialization kind), or 
> whether resolveForwardingParameters is responsible for not calling this 
> function in that case (in which case we should probably have an assert here).
> 
> Can you also add a test case that function template specialization doesn't 
> confuse us? i.e. it should return the parmvardecls from the specialization's 
> definition.
Do the new tests `VariadicNameFromSpecialization(Recursive)?` match what you 
had in mind?



Comment at: clang-tools-extra/clangd/InlayHints.cpp:483
+   !Type.getNonReferenceType().isConstQualified() &&
+   !isExpandedParameterPack(Param);
   }

sammccall wrote:
> sammccall wrote:
> > nridge wrote:
> > > sammccall wrote:
> > > > why is this check needed if we already decline to provide a name for 
> > > > the parameter on line 534 in chooseParameterNames?
> > > `shouldHintName` and `shouldHintReference` are [two independent 
> > > conditions](https://searchfox.org/llvm/rev/508eb41d82ca956c30950d9a16b522a29aeeb333/clang-tools-extra/clangd/InlayHints.cpp#411-418)
> > >  governing whether we show the parameter name and/or a `&` indicating 
> > > pass-by-mutable-ref, respectively
> > > 
> > > (I did approve the [patch](https://reviews.llvm.org/D124359) that 
> > > introduced `shouldHintReference` myself, hope that's ok)
> > Thanks, that makes sense! I just hadn't understood that change.
> What exactly *is* the motivation for suppressing reference hints in the pack 
> case?
> 
> (I can imagine there are cases where they're annoying, but it's hard to know 
> if the condition is right without knowing what those are)
I added an explanation. Basically, if we are unable to figure out which 
parameter the arguments are being forwarded to, the type of the ParmVarDecl for 
`Args&&...` gets deduced as `T&` or `T&&`, so that would mean even though we 
don't know whether the argument will eventually be forwarded to a reference 
parameter, we still claim all mutable lvalue arguments will be mutated, which 
IMO introduces more noise than necessary. But I think there are also good 
arguments for adding them to be safe.

There is another detail here, which is that we don't record whether we used 
std::forward, so the corresponding rvalue-to-lvalue conversions may lead to 
some unnecessary & annotations for rvalue arguments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124690

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

[clang] 4ee6b78 - [test][RISCV][Driver] Precommit tests for D128625

[Anton Afanasyev via cfe-commits]

Author: Anton Afanasyev
Date: 2022-06-29T13:25:56+03:00
New Revision: 4ee6b7806bc04e3d037c0679260a54828ce7ad4c

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

LOG: [test][RISCV][Driver] Precommit tests for D128625

Added: 
clang/test/Driver/Inputs/basic_riscv32_tree/bin/riscv32-unknown-linux-gnu-ld

clang/test/Driver/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1/crtbegin.o

clang/test/Driver/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1/crtend.o

clang/test/Driver/Inputs/basic_riscv32_tree/riscv32-unknown-linux-gnu/include/c++/8.0.1/.keep

clang/test/Driver/Inputs/basic_riscv32_tree/riscv32-unknown-linux-gnu/lib/crt0.o
clang/test/Driver/Inputs/basic_riscv64_tree/bin/riscv64-unknown-linux-gnu-ld

clang/test/Driver/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1/crtbegin.o

clang/test/Driver/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1/crtend.o

clang/test/Driver/Inputs/basic_riscv64_tree/riscv64-unknown-linux-gnu/include/c++/8.0.1/.keep

clang/test/Driver/Inputs/basic_riscv64_tree/riscv64-unknown-linux-gnu/lib/crt0.o

Modified: 
clang/test/Driver/riscv32-toolchain.c
clang/test/Driver/riscv64-toolchain.c

Removed: 




diff  --git 
a/clang/test/Driver/Inputs/basic_riscv32_tree/bin/riscv32-unknown-linux-gnu-ld 
b/clang/test/Driver/Inputs/basic_riscv32_tree/bin/riscv32-unknown-linux-gnu-ld
new file mode 100755
index 0..b23e55619b2ff
--- /dev/null
+++ 
b/clang/test/Driver/Inputs/basic_riscv32_tree/bin/riscv32-unknown-linux-gnu-ld
@@ -0,0 +1 @@
+#!/bin/true

diff  --git 
a/clang/test/Driver/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1/crtbegin.o
 
b/clang/test/Driver/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1/crtbegin.o
new file mode 100644
index 0..e69de29bb2d1d

diff  --git 
a/clang/test/Driver/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1/crtend.o
 
b/clang/test/Driver/Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1/crtend.o
new file mode 100644
index 0..e69de29bb2d1d

diff  --git 
a/clang/test/Driver/Inputs/basic_riscv32_tree/riscv32-unknown-linux-gnu/include/c++/8.0.1/.keep
 
b/clang/test/Driver/Inputs/basic_riscv32_tree/riscv32-unknown-linux-gnu/include/c++/8.0.1/.keep
new file mode 100644
index 0..e69de29bb2d1d

diff  --git 
a/clang/test/Driver/Inputs/basic_riscv32_tree/riscv32-unknown-linux-gnu/lib/crt0.o
 
b/clang/test/Driver/Inputs/basic_riscv32_tree/riscv32-unknown-linux-gnu/lib/crt0.o
new file mode 100644
index 0..e69de29bb2d1d

diff  --git 
a/clang/test/Driver/Inputs/basic_riscv64_tree/bin/riscv64-unknown-linux-gnu-ld 
b/clang/test/Driver/Inputs/basic_riscv64_tree/bin/riscv64-unknown-linux-gnu-ld
new file mode 100755
index 0..b23e55619b2ff
--- /dev/null
+++ 
b/clang/test/Driver/Inputs/basic_riscv64_tree/bin/riscv64-unknown-linux-gnu-ld
@@ -0,0 +1 @@
+#!/bin/true

diff  --git 
a/clang/test/Driver/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1/crtbegin.o
 
b/clang/test/Driver/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1/crtbegin.o
new file mode 100644
index 0..e69de29bb2d1d

diff  --git 
a/clang/test/Driver/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1/crtend.o
 
b/clang/test/Driver/Inputs/basic_riscv64_tree/lib/gcc/riscv64-unknown-linux-gnu/8.0.1/crtend.o
new file mode 100644
index 0..e69de29bb2d1d

diff  --git 
a/clang/test/Driver/Inputs/basic_riscv64_tree/riscv64-unknown-linux-gnu/include/c++/8.0.1/.keep
 
b/clang/test/Driver/Inputs/basic_riscv64_tree/riscv64-unknown-linux-gnu/include/c++/8.0.1/.keep
new file mode 100644
index 0..e69de29bb2d1d

diff  --git 
a/clang/test/Driver/Inputs/basic_riscv64_tree/riscv64-unknown-linux-gnu/lib/crt0.o
 
b/clang/test/Driver/Inputs/basic_riscv64_tree/riscv64-unknown-linux-gnu/lib/crt0.o
new file mode 100644
index 0..e69de29bb2d1d

diff  --git a/clang/test/Driver/riscv32-toolchain.c 
b/clang/test/Driver/riscv32-toolchain.c
index 40d45fa017c8a..4b3cc997ee1cb 100644
--- a/clang/test/Driver/riscv32-toolchain.c
+++ b/clang/test/Driver/riscv32-toolchain.c
@@ -21,15 +21,15 @@
 // RUN:   --sysroot=%S/Inputs/basic_riscv32_tree/riscv32-unknown-elf 2>&1 \
 // RUN:   | FileCheck -check-prefix=C-RV32-BAREMETAL-ILP32 %s
 
-// C-RV32-BAREMETAL-ILP32: 
"{{.*}}Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-elf/8.0.1/../../..{{/|}}..{{/|}}bin{{/|}}riscv32-unknown-elf-ld"
+// C-RV32-BAREMETAL-ILP32: 
"{{.*}}Inputs/basic_riscv32_tree/lib/gcc/riscv32-unknown-linux-gnu/8.0.1/../../..{{/|}}..{{/|}}bin{{/|}}riscv32-unknown-elf-ld"
 // C-RV32-BAREMETAL-ILP3

[PATCH] D126189: [C++20][Modules] Build module static initializers per P1874R1.

[Iain Sandoe via Phabricator via cfe-commits]

iains updated this revision to Diff 440924.
iains added a comment.

rebased, corrected some spellings.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126189

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/Basic/Module.h
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGDeclCXX.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/Parse/ParseAST.cpp
  clang/lib/Sema/SemaModule.cpp
  clang/test/CodeGen/module-intializer-pmf.cpp
  clang/test/CodeGen/module-intializer.cpp

Index: clang/test/CodeGen/module-intializer.cpp
===
--- /dev/null
+++ clang/test/CodeGen/module-intializer.cpp
@@ -0,0 +1,186 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 N.cpp \
+// RUN:-emit-module-interface -o N.pcm
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 N.pcm -S -emit-llvm \
+// RUN:  -o - | FileCheck %s --check-prefix=CHECK-N
+
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 O.cpp \
+// RUN:-emit-module-interface -o O.pcm
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 O.pcm -S -emit-llvm \
+// RUN:  -o - | FileCheck %s --check-prefix=CHECK-O
+
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 M-part.cpp \
+// RUN:-emit-module-interface -o M-part.pcm
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 M-part.pcm -S \
+// RUN: -emit-llvm -o - | FileCheck %s --check-prefix=CHECK-P
+
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 M.cpp \
+// RUN: -fmodule-file=N.pcm -fmodule-file=O.pcm -fmodule-file=M-part.pcm \
+// RUN:-emit-module-interface -o M.pcm
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 M.pcm -S -emit-llvm \
+// RUN:  -o - | FileCheck %s --check-prefix=CHECK-M
+
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 useM.cpp \
+// RUN: -fmodule-file=M.pcm -S -emit-llvm  -o - \
+// RUN: | FileCheck %s --check-prefix=CHECK-USE
+
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 M-impl.cpp \
+// RUN: -fmodule-file=M.pcm -S -emit-llvm  -o - \
+// RUN: | FileCheck %s --check-prefix=CHECK-IMPL
+
+//--- N-h.h
+
+struct Oink {
+  Oink(){};
+};
+
+Oink Hog;
+
+//--- N.cpp
+
+module;
+#include "N-h.h"
+
+export module N;
+
+export struct Quack {
+  Quack(){};
+};
+
+export Quack Duck;
+
+// CHECK-N: define internal void @__cxx_global_var_init
+// CHECK-N: call void @_ZN4OinkC1Ev
+// CHECK-N: define internal void @__cxx_global_var_init
+// CHECK-N: call void @_ZNW1N5QuackC1Ev
+// CHECK-N: define void @_ZGIW1N
+// CHECK-N: store i8 1, ptr @_ZGIW1N__in_chrg
+// CHECK-N: call void @__cxx_global_var_init
+// CHECK-N: call void @__cxx_global_var_init
+
+//--- O-h.h
+
+struct Meow {
+  Meow(){};
+};
+
+Meow Cat;
+
+//--- O.cpp
+
+module;
+#include "O-h.h"
+
+export module O;
+
+export struct Bark {
+  Bark(){};
+};
+
+export Bark Dog;
+
+// CHECK-O: define internal void @__cxx_global_var_init
+// CHECK-O: call void @_ZN4MeowC2Ev
+// CHECK-O: define internal void @__cxx_global_var_init
+// CHECK-O: call void @_ZNW1O4BarkC1Ev
+// CHECK-O: define void @_ZGIW1O
+// CHECK-O: store i8 1, ptr @_ZGIW1O__in_chrg
+// CHECK-O: call void @__cxx_global_var_init
+// CHECK-O: call void @__cxx_global_var_init
+
+//--- P-h.h
+
+struct Croak {
+  Croak(){};
+};
+
+Croak Frog;
+
+//--- M-part.cpp
+
+module;
+#include "P-h.h"
+
+module M:Part;
+
+struct Squawk {
+  Squawk(){};
+};
+
+Squawk parrot;
+
+// CHECK-P: define internal void @__cxx_global_var_init
+// CHECK-P: call void @_ZN5CroakC1Ev
+// CHECK-P: define internal void @__cxx_global_var_init
+// CHECK-P: call void @_ZNW1M6SquawkC1Ev
+// CHECK-P: define void @_ZGIW1MWP4Part
+// CHECK-P: store i8 1, ptr @_ZGIW1MWP4Part__in_chrg
+// CHECK-P: call void @__cxx_global_var_init
+// CHECK-P: call void @__cxx_global_var_init
+
+//--- M-h.h
+
+struct Moo {
+  Moo(){};
+};
+
+Moo Cow;
+
+//--- M.cpp
+
+module;
+#include "M-h.h"
+
+export module M;
+import N;
+export import O;
+import :Part;
+
+export struct Baa {
+  int x;
+  Baa(){};
+  Baa(int x) : x(x) {}
+  int getX() { return x; }
+};
+
+export Baa Sheep(10);
+
+// CHECK-M: define internal void @__cxx_global_var_init
+// CHECK-M: call void @_ZN3MooC1Ev
+// CHECK-M: define internal void @__cxx_global_var_init
+// CHECK-M: call void @_ZNW1M3BaaC1Ei
+// CHECK-M: declare void @_ZGIW1O()
+// CHECK-M: declare void @_ZGIW1N()
+// CHECK-M: declare void @_ZGIW1MWP4Part()
+// CHECK-M: define void @_ZGIW1M
+// CHECK-M: store i8 1, ptr @_ZGIW1M__in_chrg
+// CHECK-M: call void @_ZGIW1O()
+// CHECK-M: call void @_ZGIW1N()
+// CHECK-M: call void @_ZGIW1MWP4Part()
+// CHECK-M: call void @__cxx_global_var_init
+// CHECK-M: call void @__cxx_global_var_init
+
+//--- useM.cpp
+
+import M;
+
+int main() {
+  return Sheep.getX();
+}
+
+// CHECK-USE: declare void @_ZGIW1M
+// CHECK-USE: de

[PATCH] D128486: [pseudo] Add error-recovery framework & brace-based recovery

[Haojian Wu via Phabricator via cfe-commits]

hokein added a comment.

the patch looks a good start to me, some initial comments (mostly around the 
recovery part).




Comment at: clang-tools-extra/pseudo/include/clang-pseudo/GLR.h:150
+// OldHeads is the parse state at TokenIndex.
+// This function consumes consumes zero or more tokens (advancing TokenIndex),
+// and places any recovery states created in NewHeads.

If I read it correctly, consuming zero token is consider failure of the 
function, right?



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/grammar/Grammar.h:134
+  uint8_t RecoveryIndex = -1;
+  RecoveryStrategy Recovery = RecoveryStrategy::None;
+

So each rule will have at most 1 recovery-strategy (it is fine for the initial 
version), but I think in the future we want more (probably we need to change 
the Sequence to an array of `{SymbolID, RevoeryStrategy}`).

```
selection-statement := IF CONSTEXPR_opt ( init-statement_opt condition ) 
statement ELSE statement
```
We might want different recoveries in `( . init-statement_opt condition )` 
`(init-statement_opt condition) . statement`, `ELSE . statement`.






Comment at: clang-tools-extra/pseudo/include/clang-pseudo/grammar/LRTable.h:248
+  // A given state has [RecoveryOffset[S], RecoveryOffset[S+1]).
+  std::vector RecoveryOffset;
+  std::vector Recoveries;

I see the motivation of the `OffsetTable` structure now, this would come as a 
follow-up to simplify the `ReduceOffset` and `RecoveryOffset`, right?



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:29
+
+llvm::Optional
+findRecoveryEndpoint(RecoveryStrategy Strategy,

nit: unsigned => `Token::Index`



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:44
+
+void glrRecover(llvm::ArrayRef OldHeads,
+unsigned &TokenIndex, const TokenStream &Tokens,

The `GLR.cpp` file is growing significantly, I think the recovery part is large 
enough to be lived in a separate file `GLRRecovery.cpp`, but the declaration 
can still be in the `GLR.h`.



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:68
+// one arbitrarily.
+std::vector Path;
+  };

nit: maybe name it `Parses` or `PartialParses`. Path make me think this is a 
patch of GSS nodes.



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:83
+  //expr := type ( . expr )   - (up) we should recover this outer expr
+  //expr := . type ( expr )   - (up+left) we should not recover this type!
+  //

I think you're right -- I thought the first GSS node with a recovery state we 
encounter during the Walkup  state is the node we want. 

This example is a little confusing (it still matches our previous mental 
model), I didn't get it until we discussed offline. I think the following 
example is clearer 

```
parsing the text `if (true) else ?`

IfStmt := if (stmt) else . stmt - which we're currently parsing
IfStmt := if (.stmt) else stmt  - (left) the first recovery GSS node, should 
not recover from this
IfStmt := . if (stmt) else stmt - (up), we should recover from this
```

I also think it is worth to add it into the test.



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:88
+  // For now, we have to take this into account when defining recovery rules.
+  // FIXME: find a more satisfying way to avoid such false recovery.
+  std::vector Path;

I can't think of a better solution other than a search-based one (would like to 
think more about it).

Currently, we find all recovery options by traversing the whole GSS, and do a 
post-filter (based on the Start, and End). I might do both in the DFS (which 
will save some cost of traversing), the DFS will give us the best recovery 
options, and then we build the GSS node, and forest node.  But up to you.



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:111
+  };
+  for (auto *N : llvm::reverse(OldHeads))
+DFS(N, TokenIndex, DFS);

any particular reason why we iterate the OldHeads in a reversed order?



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:130
+
+  assert(NewHeads.empty()); // We may repeatedly populate and clear it.
+  llvm::Optional RecoveryRange;

nit: might be clearer to move the assertion to the beginning of the function.



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:174
+<< " strategies\n");
+++TokenIndex;
+  }

Advancing the TokenIndex here seems a little surprising and doesn't match what 
the comment says (` On failure, NewHeads is empty and TokenIndex is 
unchanged.`). I think this should be done in caller side.



Comment at: clang-tools-extra/pseudo/lib/GLR.cpp:64
+// These represent the partial parse that is being discarded.
+// They should become the children of the op

[PATCH] D126189: [C++20][Modules] Build module static initializers per P1874R1.

[Iain Sandoe via Phabricator via cfe-commits]

iains added a comment.

In D126189#3598568 , @urnathan wrote:

> please sed /initialiser/initializer/, I noticed a few had crept in.

should be done now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126189

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

[PATCH] D124690: [clangd] add inlay hints for std::forward-ed parameter packs

[Sam McCall via Phabricator via cfe-commits]

sammccall accepted this revision.
sammccall added a comment.

Thanks for the readability improvements! I've forgotten if you have commit 
access?

This stuff is complicated and I'm definitely going to forget the reasoning, the 
intuitive explanations are going to help a lot if changes are needed in future.
(Maybe it's just me, but the formal language around instantiations, deductions, 
etc makes my eyes glaze over - as if it's the words themselves rather than how 
you use them!)




Comment at: clang-tools-extra/clangd/AST.cpp:690
+getPackTemplateParameter(const FunctionDecl *Callee) {
+  if (const auto *TemplateDecl = Callee->getPrimaryTemplate()) {
+auto TemplateParams = TemplateDecl->getTemplateParameters()->asArray();

upsj wrote:
> sammccall wrote:
> > This is doing something pretty strange if Callee is a function template 
> > specialization.
> > 
> > It's not clear to me whether this function should be handling that case 
> > (which AFAICS it doesn't, but could inspect the specialization kind), or 
> > whether resolveForwardingParameters is responsible for not calling this 
> > function in that case (in which case we should probably have an assert 
> > here).
> > 
> > Can you also add a test case that function template specialization doesn't 
> > confuse us? i.e. it should return the parmvardecls from the 
> > specialization's definition.
> Do the new tests `VariadicNameFromSpecialization(Recursive)?` match what you 
> had in mind?
Yes, that's fantastic, thank you!



Comment at: clang-tools-extra/clangd/InlayHints.cpp:483
+   !Type.getNonReferenceType().isConstQualified() &&
+   !isExpandedParameterPack(Param);
   }

upsj wrote:
> sammccall wrote:
> > sammccall wrote:
> > > nridge wrote:
> > > > sammccall wrote:
> > > > > why is this check needed if we already decline to provide a name for 
> > > > > the parameter on line 534 in chooseParameterNames?
> > > > `shouldHintName` and `shouldHintReference` are [two independent 
> > > > conditions](https://searchfox.org/llvm/rev/508eb41d82ca956c30950d9a16b522a29aeeb333/clang-tools-extra/clangd/InlayHints.cpp#411-418)
> > > >  governing whether we show the parameter name and/or a `&` indicating 
> > > > pass-by-mutable-ref, respectively
> > > > 
> > > > (I did approve the [patch](https://reviews.llvm.org/D124359) that 
> > > > introduced `shouldHintReference` myself, hope that's ok)
> > > Thanks, that makes sense! I just hadn't understood that change.
> > What exactly *is* the motivation for suppressing reference hints in the 
> > pack case?
> > 
> > (I can imagine there are cases where they're annoying, but it's hard to 
> > know if the condition is right without knowing what those are)
> I added an explanation. Basically, if we are unable to figure out which 
> parameter the arguments are being forwarded to, the type of the ParmVarDecl 
> for `Args&&...` gets deduced as `T&` or `T&&`, so that would mean even though 
> we don't know whether the argument will eventually be forwarded to a 
> reference parameter, we still claim all mutable lvalue arguments will be 
> mutated, which IMO introduces more noise than necessary. But I think there 
> are also good arguments for adding them to be safe.
> 
> There is another detail here, which is that we don't record whether we used 
> std::forward, so the corresponding rvalue-to-lvalue conversions may lead to 
> some unnecessary & annotations for rvalue arguments.
This makes sense, the comment explains well, thank you!
I have a couple of quibbles, up to you whether to change the logic.

#1: There's an unstated assumption that pack arguments *will* be forwarded 
(there are other things we can do with them, like use them in 
fold-expressions). It's a pretty good assumption but if the comment talks about 
forwarding, it should probably mention explicitly ("it's likely the params will 
be somehow forwarded, and...")

#2: the idea is that if the reference-ness is deduced from the callsite, then 
it's not meaningful as an "is the param modified" signal, it's just "is this 
arg modifiable". Fair enough, but this is a property of universal/forwarding 
references (T&& where T is a template param), not of packs. So I *think* this 
check should rather be !isInstantiatedFromForwardingReference(Param).
But maybe that's more complexity and what you have is a good heuristic - I 
think at least we should call out that it's a heuristic for the true condition.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124690

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

[clang] 9d2e830 - [analyzer] Fix BindingDecl evaluation for reference types

[via cfe-commits]

Author: isuckatcs
Date: 2022-06-29T13:01:19+02:00
New Revision: 9d2e830737bcf8035cf263e4b4cb279b7b07cf24

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

LOG: [analyzer] Fix BindingDecl evaluation for reference types

The case when the bound variable is reference type in a
BindingDecl wasn't handled, which lead to false positives.

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

Added: 


Modified: 
clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
clang/test/Analysis/structured_bindings.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp 
b/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
index 1d99236a50379..b03d02640a87b 100644
--- a/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ b/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -2630,6 +2630,9 @@ void ExprEngine::VisitCommonDeclRefExpr(const Expr *Ex, 
const NamedDecl *D,
 } else
   llvm_unreachable("An unknown case of structured binding encountered!");
 
+if (BD->getType()->isReferenceType())
+  V = state->getSVal(V.getAsRegion());
+
 Bldr.generateNode(Ex, Pred, state->BindExpr(Ex, LCtx, V), nullptr,
   ProgramPoint::PostLValueKind);
 

diff  --git a/clang/test/Analysis/structured_bindings.cpp 
b/clang/test/Analysis/structured_bindings.cpp
index 3e8ff1c2aa6ab..7004c2e7dcf43 100644
--- a/clang/test/Analysis/structured_bindings.cpp
+++ b/clang/test/Analysis/structured_bindings.cpp
@@ -1,9 +1,32 @@
-// RUN: %clang_analyze_cc1 -std=c++17 -analyzer-checker=core -verify %s
+// RUN: %clang_analyze_cc1 -std=c++17 
-analyzer-checker=core,debug.ExprInspection -verify %s
+
+void clang_analyzer_eval(bool);
 
 struct s { int a; };
 int foo() {
-auto[a] = s{1}; // FIXME: proper modelling
-if (a) {
-}
+  auto [a] = s{1};
+  clang_analyzer_eval(a == 1); // expected-warning{{TRUE}}
 } // expected-warning{{non-void function does not return a value}}
 
+struct s2 {
+  int &x;
+};
+
+int *foo2(s2 in) {
+  auto [a] = in;
+  return &a;
+}
+
+void bar() {
+  int i = 1;
+  s2 a{i};
+
+  auto *x = foo2(a);
+
+  clang_analyzer_eval(*x == i); // expected-warning{{TRUE}}
+
+  *x = 2;
+
+  clang_analyzer_eval(*x == 2); // expected-warning{{TRUE}}
+  clang_analyzer_eval(i == 2);  // expected-warning{{TRUE}}
+}



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

[PATCH] D128716: [analyzer] Fix BindingDecl evaluation for reference types.

[Domján Dániel via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG9d2e830737bc: [analyzer] Fix BindingDecl evaluation for 
reference types (authored by isuckatcs).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128716

Files:
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/test/Analysis/structured_bindings.cpp


Index: clang/test/Analysis/structured_bindings.cpp
===
--- clang/test/Analysis/structured_bindings.cpp
+++ clang/test/Analysis/structured_bindings.cpp
@@ -1,9 +1,32 @@
-// RUN: %clang_analyze_cc1 -std=c++17 -analyzer-checker=core -verify %s
+// RUN: %clang_analyze_cc1 -std=c++17 
-analyzer-checker=core,debug.ExprInspection -verify %s
+
+void clang_analyzer_eval(bool);
 
 struct s { int a; };
 int foo() {
-auto[a] = s{1}; // FIXME: proper modelling
-if (a) {
-}
+  auto [a] = s{1};
+  clang_analyzer_eval(a == 1); // expected-warning{{TRUE}}
 } // expected-warning{{non-void function does not return a value}}
 
+struct s2 {
+  int &x;
+};
+
+int *foo2(s2 in) {
+  auto [a] = in;
+  return &a;
+}
+
+void bar() {
+  int i = 1;
+  s2 a{i};
+
+  auto *x = foo2(a);
+
+  clang_analyzer_eval(*x == i); // expected-warning{{TRUE}}
+
+  *x = 2;
+
+  clang_analyzer_eval(*x == 2); // expected-warning{{TRUE}}
+  clang_analyzer_eval(i == 2);  // expected-warning{{TRUE}}
+}
Index: clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -2630,6 +2630,9 @@
 } else
   llvm_unreachable("An unknown case of structured binding encountered!");
 
+if (BD->getType()->isReferenceType())
+  V = state->getSVal(V.getAsRegion());
+
 Bldr.generateNode(Ex, Pred, state->BindExpr(Ex, LCtx, V), nullptr,
   ProgramPoint::PostLValueKind);
 


Index: clang/test/Analysis/structured_bindings.cpp
===
--- clang/test/Analysis/structured_bindings.cpp
+++ clang/test/Analysis/structured_bindings.cpp
@@ -1,9 +1,32 @@
-// RUN: %clang_analyze_cc1 -std=c++17 -analyzer-checker=core -verify %s
+// RUN: %clang_analyze_cc1 -std=c++17 -analyzer-checker=core,debug.ExprInspection -verify %s
+
+void clang_analyzer_eval(bool);
 
 struct s { int a; };
 int foo() {
-auto[a] = s{1}; // FIXME: proper modelling
-if (a) {
-}
+  auto [a] = s{1};
+  clang_analyzer_eval(a == 1); // expected-warning{{TRUE}}
 } // expected-warning{{non-void function does not return a value}}
 
+struct s2 {
+  int &x;
+};
+
+int *foo2(s2 in) {
+  auto [a] = in;
+  return &a;
+}
+
+void bar() {
+  int i = 1;
+  s2 a{i};
+
+  auto *x = foo2(a);
+
+  clang_analyzer_eval(*x == i); // expected-warning{{TRUE}}
+
+  *x = 2;
+
+  clang_analyzer_eval(*x == 2); // expected-warning{{TRUE}}
+  clang_analyzer_eval(i == 2);  // expected-warning{{TRUE}}
+}
Index: clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -2630,6 +2630,9 @@
 } else
   llvm_unreachable("An unknown case of structured binding encountered!");
 
+if (BD->getType()->isReferenceType())
+  V = state->getSVal(V.getAsRegion());
+
 Bldr.generateNode(Ex, Pred, state->BindExpr(Ex, LCtx, V), nullptr,
   ProgramPoint::PostLValueKind);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D128679: [pseudo] Define a clangPseudoCLI library.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 440929.
hokein marked an inline comment as done.
hokein added a comment.

address review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128679

Files:
  clang-tools-extra/pseudo/benchmarks/Benchmark.cpp
  clang-tools-extra/pseudo/benchmarks/CMakeLists.txt
  clang-tools-extra/pseudo/fuzzer/CMakeLists.txt
  clang-tools-extra/pseudo/fuzzer/Fuzzer.cpp
  clang-tools-extra/pseudo/include/clang-pseudo/GLR.h
  clang-tools-extra/pseudo/include/clang-pseudo/Language.h
  clang-tools-extra/pseudo/include/clang-pseudo/ParseLang.h
  clang-tools-extra/pseudo/include/clang-pseudo/cli/CLI.h
  clang-tools-extra/pseudo/include/clang-pseudo/cxx/CXX.h
  clang-tools-extra/pseudo/include/clang-pseudo/grammar/Grammar.h
  clang-tools-extra/pseudo/lib/CMakeLists.txt
  clang-tools-extra/pseudo/lib/cli/CLI.cpp
  clang-tools-extra/pseudo/lib/cli/CMakeLists.txt
  clang-tools-extra/pseudo/lib/cxx/CXX.cpp
  clang-tools-extra/pseudo/tool/CMakeLists.txt
  clang-tools-extra/pseudo/tool/ClangPseudo.cpp
  clang-tools-extra/pseudo/unittests/GLRTest.cpp

Index: clang-tools-extra/pseudo/unittests/GLRTest.cpp
===
--- clang-tools-extra/pseudo/unittests/GLRTest.cpp
+++ clang-tools-extra/pseudo/unittests/GLRTest.cpp
@@ -8,6 +8,7 @@
 
 #include "clang-pseudo/GLR.h"
 #include "clang-pseudo/Token.h"
+#include "clang-pseudo/Language.h"
 #include "clang-pseudo/grammar/Grammar.h"
 #include "clang/Basic/LangOptions.h"
 #include "clang/Basic/TokenKinds.h"
@@ -48,9 +49,15 @@
 public:
   void build(llvm::StringRef GrammarBNF) {
 std::vector Diags;
-G = Grammar::parseBNF(GrammarBNF, Diags);
+TestLang.G = Grammar::parseBNF(GrammarBNF, Diags);
   }
 
+  TokenStream emptyTokenStream() {
+TokenStream Empty;
+Empty.finalize();
+return Empty;
+  }
+ 
   void buildGrammar(std::vector Nonterminals,
 std::vector Rules) {
 Nonterminals.push_back("_");
@@ -66,19 +73,22 @@
 
   SymbolID id(llvm::StringRef Name) const {
 for (unsigned I = 0; I < NumTerminals; ++I)
-  if (G.table().Terminals[I] == Name)
+  if (TestLang.G.table().Terminals[I] == Name)
 return tokenSymbol(static_cast(I));
-for (SymbolID ID = 0; ID < G.table().Nonterminals.size(); ++ID)
-  if (G.table().Nonterminals[ID].Name == Name)
+for (SymbolID ID = 0; ID < TestLang.G.table().Nonterminals.size(); ++ID)
+  if (TestLang.G.table().Nonterminals[ID].Name == Name)
 return ID;
 ADD_FAILURE() << "No such symbol found: " << Name;
 return 0;
   }
 
   RuleID ruleFor(llvm::StringRef NonterminalName) const {
-auto RuleRange = G.table().Nonterminals[id(NonterminalName)].RuleRange;
+auto RuleRange =
+TestLang.G.table().Nonterminals[id(NonterminalName)].RuleRange;
 if (RuleRange.End - RuleRange.Start == 1)
-  return G.table().Nonterminals[id(NonterminalName)].RuleRange.Start;
+  return TestLang.G.table()
+  .Nonterminals[id(NonterminalName)]
+  .RuleRange.Start;
 ADD_FAILURE() << "Expected a single rule for " << NonterminalName
   << ", but it has " << RuleRange.End - RuleRange.Start
   << " rule!\n";
@@ -86,7 +96,7 @@
   }
 
 protected:
-  Grammar G;
+  Language TestLang;
   ForestArena Arena;
   GSS GSStack;
 };
@@ -112,9 +122,8 @@
/*Parents=*/{GSSNode0});
 
   buildGrammar({}, {}); // Create a fake empty grammar.
-  LRTable T =
-  LRTable::buildForTests(G, /*Entries=*/
- {
+  TestLang.Table =
+  LRTable::buildForTests(TestLang.G, /*Entries=*/{
  {1, tokenSymbol(tok::semi), Action::shift(4)},
  {2, tokenSymbol(tok::semi), Action::shift(4)},
  {3, tokenSymbol(tok::semi), Action::shift(5)},
@@ -123,8 +132,8 @@
 
   ForestNode &SemiTerminal = Arena.createTerminal(tok::semi, 0);
   std::vector NewHeads;
-  glrShift({GSSNode1, GSSNode2, GSSNode3}, SemiTerminal, {G, T, Arena, GSStack},
-   NewHeads);
+  glrShift({GSSNode1, GSSNode2, GSSNode3}, SemiTerminal,
+   {TestLang.G, TestLang.Table, Arena, GSStack}, NewHeads);
 
   EXPECT_THAT(NewHeads,
   UnorderedElementsAre(AllOf(state(4), parsedSymbol(&SemiTerminal),
@@ -144,8 +153,8 @@
   buildGrammar({"class-name", "enum-name"},
{"class-name := IDENTIFIER", "enum-name := IDENTIFIER"});
 
-  LRTable Table = LRTable::buildForTests(
-  G,
+  TestLang.Table = LRTable::buildForTests(
+  TestLang.G,
   {
   {/*State=*/0, id("class-name"), Action::goTo(2)},
   {/*State=*/0, id("enum-name"), Action::goTo(3)},
@@ -161,7 +170,8 @@
   GSStack.addNode(1, &Arena.createTerminal(tok::identifier, 0), {GSSNode0});
 
   std::vector Heads = {GSSNode1};
-  glrReduce(Heads, tokenSymbol(tok:

[PATCH] D128679: [pseudo] Define a clangPseudoCLI library.

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: clang-tools-extra/pseudo/benchmarks/Benchmark.cpp:51
 const std::string *SourceText = nullptr;
-const Grammar *G = nullptr;
+const Language *PLang = nullptr;
 

sammccall wrote:
> nit: still PLang here and in a bunch of places
renamed all to `Lang`



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/ParseLang.h:1
+//===--- ParseLang.h --- -*- 
C++-*-===//
+//

sammccall wrote:
> hokein wrote:
> > sammccall wrote:
> > > The "ParseLang" name doesn't feel right to me :-(
> > > 
> > > I think it's a combination of:
> > >  - Lang is unneccesarily abbreviated
> > >  - "Parse" doesn't actually disambiguate much, as "parse" is the whole 
> > > project
> > > 
> > > Do you think `clang::pseudo::Language` would work?
> > > 
> > > 
> > > (Sorry for not realizing this on the previous pass, I know it's a pain... 
> > > happy to chat more offline)
> > That sounds good to me. Regarding the location of this file, I think the 
> > subdir grammar will be a better fit.
> The main purpose of the `grammar` library is to minimize the amount of stuff 
> we pull into the gen step right?
> 
> I'm a bit concerned about mixing clang::LangOptions in there unneccesarily - 
> if grammar doesn't *need* the header, maybe it's OK where it is?
as discussed offline, moved back to `pseudo/`



Comment at: clang-tools-extra/pseudo/lib/cli/CLI.cpp:42
+auto G = Grammar::parseBNF(GrammarText->get()->getBuffer(), Diags);
+if (!Diags.empty()) {
+  for (const auto &Diag : Diags)

sammccall wrote:
> hokein wrote:
> > sammccall wrote:
> > > this if() isn't needed unless you want to print a header to provide some 
> > > context (which might be a good idea)
> > I don't get your point of the comment.  Not sure what you meant by  `Print 
> > a header`? 
> > 
> > I think for the CLI tool use-case, printing the diagnostic of the grammar 
> > by default is reasonable.
> You could replace
> 
> ```
> if (!Diags.empty())
>  for(D : Diags)
> ...
> ```
> 
> with just: 
> ```
> for (D : Diags)
>   ...
> ```
> 
> unless you would prefer:
> ```
> if (!Diags.empty()) {
>   errs() << "Problems with the grammar:\n";
>   for (D : Diags)
> ...
> }
> ```
> 
> (Yesterday I thought the last one would be clearer, today I'm not so sure)
oops, I see what you mean now. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128679

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

[PATCH] D128805: [pseudo] Fix bugs/inconsistencies in forest dump.

[Sam McCall via Phabricator via cfe-commits]

sammccall created this revision.
sammccall added a reviewer: hokein.
Herald added a project: All.
sammccall requested review of this revision.
Herald added subscribers: cfe-commits, alextsao1999.
Herald added a project: clang-tools-extra.

- when printing a shared node for the second time, don't print its children 
(This keeps output proportional to the size of the structure)
- when printing a shared node for the second time, print its type only, not 
rule (for consistency with above: don't dump details of nodes twice)
- don't abbreviate shared nodes, to ensure we can prune the tree there


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128805

Files:
  clang-tools-extra/pseudo/lib/Forest.cpp
  clang-tools-extra/pseudo/test/glr.cpp
  clang-tools-extra/pseudo/unittests/ForestTest.cpp
  clang-tools-extra/pseudo/unittests/GLRTest.cpp

Index: clang-tools-extra/pseudo/unittests/GLRTest.cpp
===
--- clang-tools-extra/pseudo/unittests/GLRTest.cpp
+++ clang-tools-extra/pseudo/unittests/GLRTest.cpp
@@ -399,8 +399,7 @@
  "[  0, end) └─test := left-paren expr\n"
  "[  0,   1)   ├─left-paren := {\n"
  "[  0,   1)   │ └─{ := tok[0]\n"
- "[  1, end)   └─expr := IDENTIFIER =#1\n"
- "[  1, end) └─IDENTIFIER := tok[1]\n");
+ "[  1, end)   └─expr =#1\n");
 }
 
 TEST_F(GLRTest, GLRReduceOrder) {
Index: clang-tools-extra/pseudo/unittests/ForestTest.cpp
===
--- clang-tools-extra/pseudo/unittests/ForestTest.cpp
+++ clang-tools-extra/pseudo/unittests/ForestTest.cpp
@@ -122,8 +122,31 @@
 "[  0, end) │ └─IDENTIFIER := tok[0]\n"
 "[  0, end) └─type := enum-type\n"
 "[  0, end)   └─enum-type := shared-type\n"
-"[  0, end) └─shared-type := IDENTIFIER =#1\n"
-"[  0, end)   └─IDENTIFIER := tok[0]\n");
+"[  0, end) └─shared-type =#1\n");
+}
+
+TEST_F(ForestTest, DumpAbbreviatedShared) {
+  build(R"cpp(
+_ := A
+A := B
+B := *
+  )cpp");
+
+  ForestArena Arena;
+  const auto *Star = &Arena.createTerminal(tok::star, 0);
+
+  const auto *B = &Arena.createSequence(symbol("B"), ruleFor("B"), {Star});
+  const auto *A1 = &Arena.createSequence(symbol("A"), ruleFor("A"), {B});
+  const auto *A2 = &Arena.createSequence(symbol("A"), ruleFor("A"), {B});
+  const auto *A = &Arena.createAmbiguous(symbol("A"), {A1, A2});
+
+  // We must not abbreviate away shared nodes: if we show A~* there's no way to
+  // show that the intermediate B node is shared between A1 and A2.
+  EXPECT_EQ(A->dumpRecursive(G, /*Abbreviate=*/true),
+"[  0, end) A := \n"
+"[  0, end) ├─A~B := * #1\n"
+"[  0, end) │ └─* := tok[0]\n"
+"[  0, end) └─A~B =#1\n");
 }
 
 } // namespace
Index: clang-tools-extra/pseudo/test/glr.cpp
===
--- clang-tools-extra/pseudo/test/glr.cpp
+++ clang-tools-extra/pseudo/test/glr.cpp
@@ -7,7 +7,8 @@
 // CHECK-NEXT: │ ├─expression~multiplicative-expression := multiplicative-expression * pm-expression
 // CHECK-NEXT: │ │ ├─multiplicative-expression~IDENTIFIER := tok[5]
 // CHECK-NEXT: │ │ ├─* := tok[6]
-// CHECK-NEXT: │ │ └─pm-expression~IDENTIFIER := tok[7]
+// CHECK-NEXT: │ │ └─pm-expression~id-expression := unqualified-id #1
+// CHECK-NEXT: │ │   └─unqualified-id~IDENTIFIER := tok[7]
 // CHECK-NEXT: │ └─; := tok[8]
 // CHECK-NEXT: └─statement~simple-declaration := decl-specifier-seq init-declarator-list ;
 // CHECK-NEXT:   ├─decl-specifier-seq~simple-type-specifier := 
@@ -18,6 +19,6 @@
 // CHECK-NEXT:   │ └─simple-type-specifier~IDENTIFIER := tok[5]
 // CHECK-NEXT:   ├─init-declarator-list~ptr-declarator := ptr-operator ptr-declarator
 // CHECK-NEXT:   │ ├─ptr-operator~* := tok[6]
-// CHECK-NEXT:   │ └─ptr-declarator~IDENTIFIER := tok[7]
+// CHECK-NEXT:   │ └─ptr-declarator~id-expression =#1
 // CHECK-NEXT:   └─; := tok[8]
 }
Index: clang-tools-extra/pseudo/lib/Forest.cpp
===
--- clang-tools-extra/pseudo/lib/Forest.cpp
+++ clang-tools-extra/pseudo/lib/Forest.cpp
@@ -63,6 +63,7 @@
   Dump = [&](const ForestNode *P, Token::Index End,
  llvm::Optional ElidedParent,
  LineDecoration LineDec) {
+bool SharedNode = VisitCounts.find(P)->getSecond() > 1;
 llvm::ArrayRef Children;
 auto EndOfElement = [&](size_t ChildIndex) {
   return ChildIndex + 1 == Children.size()
@@ -74,7 +75,14 @@
 } else if 

[PATCH] D128679: [pseudo] Define a clangPseudoCLI library.

[Sam McCall via Phabricator via cfe-commits]

sammccall accepted this revision.
sammccall added a comment.

Looks good!




Comment at: clang-tools-extra/pseudo/include/clang-pseudo/Language.h:21
+  Grammar G;
+  LRTable Table;
+

LR might be more distinguishing (and shorter!), up to you


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128679

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

[clang-tools-extra] 333620d - [clangd] Support multiline semantic tokens

[Kadir Cetinkaya via cfe-commits]

Author: Kadir Cetinkaya
Date: 2022-06-29T13:49:03+02:00
New Revision: 333620d37a26949e9f66c823425cf9a2065e3890

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

LOG: [clangd] Support multiline semantic tokens

Per LSP, multiline tokens should be handled as if they end at the end
of the line starting the token (there's also a capability to enable them, but
that's an adventure for a different day).

Fixes https://github.com/clangd/clangd/issues/1145

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

Added: 


Modified: 
clang-tools-extra/clangd/ClangdLSPServer.cpp
clang-tools-extra/clangd/SemanticHighlighting.cpp
clang-tools-extra/clangd/SemanticHighlighting.h
clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/ClangdLSPServer.cpp 
b/clang-tools-extra/clangd/ClangdLSPServer.cpp
index edafb40ff2b79..54e6765be315b 100644
--- a/clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ b/clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -1397,14 +1397,15 @@ static void increment(std::string &S) {
 
 void ClangdLSPServer::onSemanticTokens(const SemanticTokensParams &Params,
Callback CB) {
+  auto File = Params.textDocument.uri.file();
   Server->semanticHighlights(
   Params.textDocument.uri.file(),
-  [this, File(Params.textDocument.uri.file().str()), CB(std::move(CB))](
+  [this, File(File.str()), CB(std::move(CB)), 
Code(Server->getDraft(File))](
   llvm::Expected> HT) mutable {
 if (!HT)
   return CB(HT.takeError());
 SemanticTokens Result;
-Result.tokens = toSemanticTokens(*HT);
+Result.tokens = toSemanticTokens(*HT, *Code);
 {
   std::lock_guard Lock(SemanticTokensMutex);
   auto &Last = LastSemanticTokens[File];
@@ -1420,14 +1421,15 @@ void ClangdLSPServer::onSemanticTokens(const 
SemanticTokensParams &Params,
 void ClangdLSPServer::onSemanticTokensDelta(
 const SemanticTokensDeltaParams &Params,
 Callback CB) {
+  auto File = Params.textDocument.uri.file();
   Server->semanticHighlights(
   Params.textDocument.uri.file(),
-  [this, PrevResultID(Params.previousResultId),
-   File(Params.textDocument.uri.file().str()), CB(std::move(CB))](
+  [this, PrevResultID(Params.previousResultId), File(File.str()),
+   CB(std::move(CB)), Code(Server->getDraft(File))](
   llvm::Expected> HT) mutable {
 if (!HT)
   return CB(HT.takeError());
-std::vector Toks = toSemanticTokens(*HT);
+std::vector Toks = toSemanticTokens(*HT, *Code);
 
 SemanticTokensOrDelta Result;
 {

diff  --git a/clang-tools-extra/clangd/SemanticHighlighting.cpp 
b/clang-tools-extra/clangd/SemanticHighlighting.cpp
index 489bb93856a04..2ab7461eee9c6 100644
--- a/clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ b/clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -30,7 +30,9 @@
 #include "llvm/ADT/None.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/STLExtras.h"
+#include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Casting.h"
+#include "llvm/Support/Error.h"
 #include 
 
 namespace clang {
@@ -918,33 +920,69 @@ bool operator<(const HighlightingToken &L, const 
HighlightingToken &R) {
 }
 
 std::vector
-toSemanticTokens(llvm::ArrayRef Tokens) {
+toSemanticTokens(llvm::ArrayRef Tokens,
+ llvm::StringRef Code) {
   assert(std::is_sorted(Tokens.begin(), Tokens.end()));
   std::vector Result;
+  // In case we split a HighlightingToken into multiple tokens (e.g. because it
+  // was spanning multiple lines), this tracks the last one. This prevents
+  // having a copy all the time.
+  HighlightingToken Scratch;
   const HighlightingToken *Last = nullptr;
   for (const HighlightingToken &Tok : Tokens) {
 Result.emplace_back();
-SemanticToken &Out = Result.back();
+SemanticToken *Out = &Result.back();
 // deltaStart/deltaLine are relative if possible.
 if (Last) {
-  assert(Tok.R.start.line >= Last->R.start.line);
-  Out.deltaLine = Tok.R.start.line - Last->R.start.line;
-  if (Out.deltaLine == 0) {
+  assert(Tok.R.start.line >= Last->R.end.line);
+  Out->deltaLine = Tok.R.start.line - Last->R.end.line;
+  if (Out->deltaLine == 0) {
 assert(Tok.R.start.character >= Last->R.start.character);
-Out.deltaStart = Tok.R.start.character - Last->R.start.character;
+Out->deltaStart = Tok.R.start.character - Last->R.start.character;
   } else {
-Out.deltaStart = Tok.R.start.character;
+Out->deltaStart = Tok.R.start.character;
   }
 } else {
-  Out.deltaLine = Tok.R.start.line;
-  Out.deltaStart = Tok.R.start.character;
+  Out-

[PATCH] D127856: [clangd] Support multiline semantic tokens

[Kadir Cetinkaya 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 rG333620d37a26: [clangd] Support multiline semantic tokens 
(authored by kadircet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127856

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

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -944,7 +944,7 @@
   )");
   Tokens.front().Modifiers |= unsigned(HighlightingModifier::Declaration);
   Tokens.front().Modifiers |= unsigned(HighlightingModifier::Readonly);
-  auto Results = toSemanticTokens(Tokens);
+  auto Results = toSemanticTokens(Tokens, /*Code=*/"");
 
   ASSERT_THAT(Results, SizeIs(3));
   EXPECT_EQ(Results[0].tokenType, unsigned(HighlightingKind::Variable));
@@ -972,13 +972,15 @@
   auto Before = toSemanticTokens(tokens(R"(
 [[foo]] [[bar]] [[baz]]
 [[one]] [[two]] [[three]]
-  )"));
+  )"),
+ /*Code=*/"");
   EXPECT_THAT(diffTokens(Before, Before), IsEmpty());
 
   auto After = toSemanticTokens(tokens(R"(
 [[foo]] [[hello]] [[world]] [[baz]]
 [[one]] [[two]] [[three]]
-  )"));
+  )"),
+/*Code=*/"");
 
   // Replace [bar, baz] with [hello, world, baz]
   auto Diff = diffTokens(Before, After);
@@ -1000,6 +1002,30 @@
   EXPECT_EQ(3u, Diff.front().tokens[2].length);
 }
 
+TEST(SemanticHighlighting, MultilineTokens) {
+  llvm::StringRef AnnotatedCode = R"cpp(
+  [[fo
+o
+o]] [[bar]])cpp";
+  auto Toks = toSemanticTokens(tokens(AnnotatedCode),
+   Annotations(AnnotatedCode).code());
+  ASSERT_THAT(Toks, SizeIs(4));
+  // foo
+  EXPECT_EQ(Toks[0].deltaLine, 1u);
+  EXPECT_EQ(Toks[0].deltaStart, 2u);
+  EXPECT_EQ(Toks[0].length, 2u);
+  EXPECT_EQ(Toks[1].deltaLine, 1u);
+  EXPECT_EQ(Toks[1].deltaStart, 0u);
+  EXPECT_EQ(Toks[1].length, 1u);
+  EXPECT_EQ(Toks[2].deltaLine, 1u);
+  EXPECT_EQ(Toks[2].deltaStart, 0u);
+  EXPECT_EQ(Toks[2].length, 1u);
+
+  // bar
+  EXPECT_EQ(Toks[3].deltaLine, 0u);
+  EXPECT_EQ(Toks[3].deltaStart, 2u);
+  EXPECT_EQ(Toks[3].length, 3u);
+}
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/SemanticHighlighting.h
===
--- clang-tools-extra/clangd/SemanticHighlighting.h
+++ clang-tools-extra/clangd/SemanticHighlighting.h
@@ -21,6 +21,7 @@
 #define LLVM_CLANG_TOOLS_EXTRA_CLANGD_SEMANTICHIGHLIGHTING_H
 
 #include "Protocol.h"
+#include "llvm/ADT/StringRef.h"
 #include "llvm/Support/raw_ostream.h"
 
 namespace clang {
@@ -101,7 +102,8 @@
 // main AST.
 std::vector getSemanticHighlightings(ParsedAST &AST);
 
-std::vector toSemanticTokens(llvm::ArrayRef);
+std::vector toSemanticTokens(llvm::ArrayRef,
+llvm::StringRef Code);
 llvm::StringRef toSemanticTokenType(HighlightingKind Kind);
 llvm::StringRef toSemanticTokenModifier(HighlightingModifier Modifier);
 std::vector diffTokens(llvm::ArrayRef Before,
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -30,7 +30,9 @@
 #include "llvm/ADT/None.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/STLExtras.h"
+#include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Casting.h"
+#include "llvm/Support/Error.h"
 #include 
 
 namespace clang {
@@ -918,33 +920,69 @@
 }
 
 std::vector
-toSemanticTokens(llvm::ArrayRef Tokens) {
+toSemanticTokens(llvm::ArrayRef Tokens,
+ llvm::StringRef Code) {
   assert(std::is_sorted(Tokens.begin(), Tokens.end()));
   std::vector Result;
+  // In case we split a HighlightingToken into multiple tokens (e.g. because it
+  // was spanning multiple lines), this tracks the last one. This prevents
+  // having a copy all the time.
+  HighlightingToken Scratch;
   const HighlightingToken *Last = nullptr;
   for (const HighlightingToken &Tok : Tokens) {
 Result.emplace_back();
-SemanticToken &Out = Result.back();
+SemanticToken *Out = &Result.back();
 // deltaStart/deltaLine are relative if possible.
 if (Last) {
-  assert(Tok.R.start.line >= Last->R.start.line);
-  Out.deltaLine = Tok.R.start.line - Last->R.start.line;
-  if (Out.deltaLine == 0) {
+  assert(Tok.R.start.line >= Last->R.end.line);
+  Out->deltaLine = Tok.R.start.line - Last->R.end.li

[PATCH] D124690: [clangd] add inlay hints for std::forward-ed parameter packs

[Tobias Ribizel via Phabricator via cfe-commits]

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

yes, I have commit access




Comment at: clang-tools-extra/clangd/InlayHints.cpp:483
+   !Type.getNonReferenceType().isConstQualified() &&
+   !isExpandedParameterPack(Param);
   }

sammccall wrote:
> upsj wrote:
> > sammccall wrote:
> > > sammccall wrote:
> > > > nridge wrote:
> > > > > sammccall wrote:
> > > > > > why is this check needed if we already decline to provide a name 
> > > > > > for the parameter on line 534 in chooseParameterNames?
> > > > > `shouldHintName` and `shouldHintReference` are [two independent 
> > > > > conditions](https://searchfox.org/llvm/rev/508eb41d82ca956c30950d9a16b522a29aeeb333/clang-tools-extra/clangd/InlayHints.cpp#411-418)
> > > > >  governing whether we show the parameter name and/or a `&` indicating 
> > > > > pass-by-mutable-ref, respectively
> > > > > 
> > > > > (I did approve the [patch](https://reviews.llvm.org/D124359) that 
> > > > > introduced `shouldHintReference` myself, hope that's ok)
> > > > Thanks, that makes sense! I just hadn't understood that change.
> > > What exactly *is* the motivation for suppressing reference hints in the 
> > > pack case?
> > > 
> > > (I can imagine there are cases where they're annoying, but it's hard to 
> > > know if the condition is right without knowing what those are)
> > I added an explanation. Basically, if we are unable to figure out which 
> > parameter the arguments are being forwarded to, the type of the ParmVarDecl 
> > for `Args&&...` gets deduced as `T&` or `T&&`, so that would mean even 
> > though we don't know whether the argument will eventually be forwarded to a 
> > reference parameter, we still claim all mutable lvalue arguments will be 
> > mutated, which IMO introduces more noise than necessary. But I think there 
> > are also good arguments for adding them to be safe.
> > 
> > There is another detail here, which is that we don't record whether we used 
> > std::forward, so the corresponding rvalue-to-lvalue conversions may lead to 
> > some unnecessary & annotations for rvalue arguments.
> This makes sense, the comment explains well, thank you!
> I have a couple of quibbles, up to you whether to change the logic.
> 
> #1: There's an unstated assumption that pack arguments *will* be forwarded 
> (there are other things we can do with them, like use them in 
> fold-expressions). It's a pretty good assumption but if the comment talks 
> about forwarding, it should probably mention explicitly ("it's likely the 
> params will be somehow forwarded, and...")
> 
> #2: the idea is that if the reference-ness is deduced from the callsite, then 
> it's not meaningful as an "is the param modified" signal, it's just "is this 
> arg modifiable". Fair enough, but this is a property of universal/forwarding 
> references (T&& where T is a template param), not of packs. So I *think* this 
> check should rather be !isInstantiatedFromForwardingReference(Param).
> But maybe that's more complexity and what you have is a good heuristic - I 
> think at least we should call out that it's a heuristic for the true 
> condition.
> 
> 
#1: I agree, I'll make that more clear before committing.

#2: Now that I think about it, there are actually two things we don't keep 
track of: parameters could lose their reference-ness via `Args...` instead of 
`Args&&...` and their rvalue-ness by not using `std::forward`. We only look at 
whether the innermost call takes a reference parameter, but as I said, we may 
lose some of that information on the way, claiming the function may modify the 
argument when it actually creates a copy on the way (losing reference-ness). I 
think the case of an rvalue being mistaken for an lvalue should not be much of 
an issue, since the reference annotation almost makes sense.

To visualize the situation: These three snippets all add &: hints to the 
parameter of bar
```
void foo(int&);
template 
void bar(Args... args) { return foo(args...); }
void baz() {
  bar(1);
}
```
```
void foo(int&);
template 
void bar(Args&&... args) { return foo(args...); }
void baz() {
  bar(1);
}
```
```
void foo(int&);
template 
void bar(Args&&... args) { return foo(std::forward(args)...); }
void baz() {
  int a;
  bar(a);
}
```
Two of these three cases probably shouldn't have this annotation?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124690

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

[PATCH] D128807: [clang][transformer] Finish plumbing `Note` all the way to the output.

[Clement Courbet via Phabricator via cfe-commits]

courbet created this revision.
courbet added a reviewer: ymandel.
Herald added a subscriber: carlosgalvezp.
Herald added a project: All.
courbet requested review of this revision.
Herald added projects: clang, clang-tools-extra.

Right now we can only add a single warning, notes are not possible.

Apparently some provisions were made to allow notes, but they were never
propagated all the way to the diagnostics.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128807

Files:
  clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.cpp
  clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
  clang/include/clang/Tooling/Transformer/RewriteRule.h
  clang/lib/Tooling/Transformer/RewriteRule.cpp

Index: clang/lib/Tooling/Transformer/RewriteRule.cpp
===
--- clang/lib/Tooling/Transformer/RewriteRule.cpp
+++ clang/lib/Tooling/Transformer/RewriteRule.cpp
@@ -50,17 +50,26 @@
 // produces a bad range, whereas the latter will simply ignore A.
 if (!EditRange)
   return SmallVector();
-auto Replacement = E.Replacement->eval(Result);
-if (!Replacement)
-  return Replacement.takeError();
-auto Metadata = E.Metadata(Result);
-if (!Metadata)
-  return Metadata.takeError();
 transformer::Edit T;
 T.Kind = E.Kind;
 T.Range = *EditRange;
-T.Replacement = std::move(*Replacement);
-T.Metadata = std::move(*Metadata);
+if (E.Replacement) {
+  auto Replacement = E.Replacement->eval(Result);
+  if (!Replacement)
+return Replacement.takeError();
+  T.Replacement = std::move(*Replacement);
+}
+if (E.Note) {
+  auto Note = E.Note->eval(Result);
+  if (!Note)
+return Note.takeError();
+  T.Note = std::move(*Note);
+}
+if (auto Metadata = E.Metadata(Result)) {
+  if (!Metadata)
+return Metadata.takeError();
+  T.Metadata = std::move(*Metadata);
+}
 Edits.push_back(std::move(T));
   }
   return Edits;
@@ -121,6 +130,28 @@
   return E;
 }
 
+ASTEdit transformer::withNote(ASTEdit Edit, TextGenerator Note) {
+  Edit. Note = std::move(Note);
+  return Edit;
+}
+
+EditGenerator transformer::withNote(EditGenerator Generator, TextGenerator Note) {
+  return
+  [G = std::move(Generator), N=std::move(Note)](
+  const MatchResult &Result) -> llvm::Expected> {
+llvm::Expected> Edits = G(Result);
+if (!Edits)
+  return Edits.takeError();
+llvm::Expected Note = N->eval(Result);
+if (!Note)
+  return Note.takeError();
+for (Edit& E : *Edits) {
+  E.Note = *Note;
+}
+return Edits;
+  };
+}
+
 namespace {
 /// A \c TextGenerator that always returns a fixed string.
 class SimpleTextGenerator : public MatchComputation {
Index: clang/include/clang/Tooling/Transformer/RewriteRule.h
===
--- clang/include/clang/Tooling/Transformer/RewriteRule.h
+++ clang/include/clang/Tooling/Transformer/RewriteRule.h
@@ -46,6 +46,7 @@
   EditKind Kind = EditKind::Range;
   CharSourceRange Range;
   std::string Replacement;
+  std::string Note;
   llvm::Any Metadata;
 };
 
@@ -246,6 +247,14 @@
   return Edit;
 }
 
+// Adds a note to the given edit or edits. If there are several edits, the note
+// is added to each one of them.
+// \code
+//   withNote(noopEdit(), cat("some note"))
+// \endcode
+EditGenerator withNote(EditGenerator Generator, TextGenerator Note);
+ASTEdit withNote(ASTEdit Edit, TextGenerator Note);
+
 /// Assuming that the inner range is enclosed by the outer range, creates
 /// precision edits to remove the parts of the outer range that are not included
 /// in the inner range.
Index: clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
@@ -28,6 +28,7 @@
 using transformer::makeRule;
 using transformer::node;
 using transformer::noopEdit;
+using transformer::withNote;
 using transformer::RewriteRuleWith;
 using transformer::RootID;
 using transformer::statement;
@@ -85,11 +86,33 @@
   EXPECT_EQ(Errors.size(), 1U);
   EXPECT_EQ(Errors[0].Message.Message, "message");
   EXPECT_THAT(Errors[0].Message.Ranges, testing::IsEmpty());
+  EXPECT_THAT(Errors[0].Notes, testing::IsEmpty());
 
   // The diagnostic is anchored to the match, "return 5".
   EXPECT_EQ(Errors[0].Message.FileOffset, 10U);
 }
 
+TEST(TransformerClangTidyCheckTest, NotesCorrectlyGenerated) {
+  class DiagAndNoteCheck : public TransformerClangTidyCheck {
+  public:
+DiagAndNoteCheck(StringRef Name, ClangTidyContext *Context)
+: TransformerClangTidyCheck(
+  makeRule(returnStmt(),
+   withNote(noopEdit(node(RootID)), ca

[PATCH] D128807: [clang][transformer] Finish plumbing `Note` all the way to the output.

[Clement Courbet via Phabricator via cfe-commits]

courbet updated this revision to Diff 440948.
courbet added a comment.

Format patch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128807

Files:
  clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.cpp
  clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
  clang/include/clang/Tooling/Transformer/RewriteRule.h
  clang/lib/Tooling/Transformer/RewriteRule.cpp

Index: clang/lib/Tooling/Transformer/RewriteRule.cpp
===
--- clang/lib/Tooling/Transformer/RewriteRule.cpp
+++ clang/lib/Tooling/Transformer/RewriteRule.cpp
@@ -50,17 +50,26 @@
 // produces a bad range, whereas the latter will simply ignore A.
 if (!EditRange)
   return SmallVector();
-auto Replacement = E.Replacement->eval(Result);
-if (!Replacement)
-  return Replacement.takeError();
-auto Metadata = E.Metadata(Result);
-if (!Metadata)
-  return Metadata.takeError();
 transformer::Edit T;
 T.Kind = E.Kind;
 T.Range = *EditRange;
-T.Replacement = std::move(*Replacement);
-T.Metadata = std::move(*Metadata);
+if (E.Replacement) {
+  auto Replacement = E.Replacement->eval(Result);
+  if (!Replacement)
+return Replacement.takeError();
+  T.Replacement = std::move(*Replacement);
+}
+if (E.Note) {
+  auto Note = E.Note->eval(Result);
+  if (!Note)
+return Note.takeError();
+  T.Note = std::move(*Note);
+}
+if (auto Metadata = E.Metadata(Result)) {
+  if (!Metadata)
+return Metadata.takeError();
+  T.Metadata = std::move(*Metadata);
+}
 Edits.push_back(std::move(T));
   }
   return Edits;
@@ -121,6 +130,29 @@
   return E;
 }
 
+ASTEdit transformer::withNote(ASTEdit Edit, TextGenerator Note) {
+  Edit.Note = std::move(Note);
+  return Edit;
+}
+
+EditGenerator transformer::withNote(EditGenerator Generator,
+TextGenerator Note) {
+  return
+  [G = std::move(Generator), N = std::move(Note)](
+  const MatchResult &Result) -> llvm::Expected> {
+llvm::Expected> Edits = G(Result);
+if (!Edits)
+  return Edits.takeError();
+llvm::Expected Note = N->eval(Result);
+if (!Note)
+  return Note.takeError();
+for (Edit &E : *Edits) {
+  E.Note = *Note;
+}
+return Edits;
+  };
+}
+
 namespace {
 /// A \c TextGenerator that always returns a fixed string.
 class SimpleTextGenerator : public MatchComputation {
Index: clang/include/clang/Tooling/Transformer/RewriteRule.h
===
--- clang/include/clang/Tooling/Transformer/RewriteRule.h
+++ clang/include/clang/Tooling/Transformer/RewriteRule.h
@@ -46,6 +46,7 @@
   EditKind Kind = EditKind::Range;
   CharSourceRange Range;
   std::string Replacement;
+  std::string Note;
   llvm::Any Metadata;
 };
 
@@ -246,6 +247,14 @@
   return Edit;
 }
 
+// Adds a note to the given edit or edits. If there are several edits, the note
+// is added to each one of them.
+// \code
+//   withNote(noopEdit(), cat("some note"))
+// \endcode
+EditGenerator withNote(EditGenerator Generator, TextGenerator Note);
+ASTEdit withNote(ASTEdit Edit, TextGenerator Note);
+
 /// Assuming that the inner range is enclosed by the outer range, creates
 /// precision edits to remove the parts of the outer range that are not included
 /// in the inner range.
Index: clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
@@ -31,6 +31,7 @@
 using transformer::RewriteRuleWith;
 using transformer::RootID;
 using transformer::statement;
+using transformer::withNote;
 
 // Invert the code of an if-statement, while maintaining its semantics.
 RewriteRuleWith invertIf() {
@@ -85,11 +86,33 @@
   EXPECT_EQ(Errors.size(), 1U);
   EXPECT_EQ(Errors[0].Message.Message, "message");
   EXPECT_THAT(Errors[0].Message.Ranges, testing::IsEmpty());
+  EXPECT_THAT(Errors[0].Notes, testing::IsEmpty());
 
   // The diagnostic is anchored to the match, "return 5".
   EXPECT_EQ(Errors[0].Message.FileOffset, 10U);
 }
 
+TEST(TransformerClangTidyCheckTest, NotesCorrectlyGenerated) {
+  class DiagAndNoteCheck : public TransformerClangTidyCheck {
+  public:
+DiagAndNoteCheck(StringRef Name, ClangTidyContext *Context)
+: TransformerClangTidyCheck(
+  makeRule(returnStmt(),
+   withNote(noopEdit(node(RootID)), cat("some note")),
+   cat("message")),
+  Name, Context) {}
+  };
+  std::string Input = "int h() { return 5; }";
+  std::vector Errors;
+  EXPECT_EQ(Input, test::runCheckOnCo

[PATCH] D128774: [libTooling] Add a comment about comment parsing to getAssociatedRange.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

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

Thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128774

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

[PATCH] D128774: [libTooling] Add a comment about comment parsing to getAssociatedRange.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added inline comments.



Comment at: clang/include/clang/Tooling/Transformer/SourceCode.h:47
+/// range containing associated comments, you may need to invoke the tool with
+/// -fparse-all-comments.
 CharSourceRange getAssociatedRange(const Decl &D, ASTContext &Context);




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128774

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

[PATCH] D128766: Update references to Discourse instead of the mailing lists.

[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 with some minor corrections. Thank you for this!




Comment at: clang/docs/ExternalClangExamples.rst:21
 
-If you know of (or wrote!) a tool or project using Clang, please send an
-email to Clang's `development discussion mailing list
-`_ to have it added.
+If you know of (or wrote!) a tool or project using Clang, pleasepost on 
+`the Discourse forums (Clang Frontend category)





Comment at: clang/www/get_involved.html:39
+https://discourse.llvm.org/c/clang/6";>Clang Frontend Discourse 
forum -
+This forums is for everything else Clang related (questions and answers, design
 discussions, etc).




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128766

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

[PATCH] D128706: [Clang] Disable clang-format entirely for clang/test tree.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Should we also do `llvm/test` and `clang-tools-extra/test` at the same time? 
The LLVM tests will show up in precommit CI, but I'm not certain that precommit 
CI actually tests clang-tools-extra (it also notably lacks coverage for libc++ 
and lldb as well).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128706

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

[PATCH] D126864: [clang] Introduce -fstrict-flex-arrays= for stricter handling of flexible arrays

[serge via Phabricator via cfe-commits]

serge-sans-paille updated this revision to Diff 440942.
serge-sans-paille added a subscriber: chandlerc.
serge-sans-paille added a comment.

Code updated to take into account two situations:

- size resulting from macro expansion. Previous behavior was inconsistent in 
that situation. I chose to consider that `int a[1]` and `int a[N]` where N is a 
macro definition both are FAM.   That's GCC behavior too. CCing @chandlerc 
because he introduced that feature, probably because that could make an array a 
FAM just based on preprocessor flag (?)

- FAM within non-standard layout C++ object. GCC allows that behavior and clang 
used to have an inconsistent approach here. I'd like to stick to GCC behavior.

Note that we still diverge from GCC behavior for `int a[N]` when `N` results 
from template expansion. I could revert that too.


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

https://reviews.llvm.org/D126864

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/Expr.h
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/StaticAnalyzer/Core/MemRegion.cpp
  clang/test/CodeGen/bounds-checking-fam.c
  clang/test/CodeGen/bounds-checking-fam.cpp
  clang/test/CodeGen/bounds-checking.c
  clang/test/CodeGen/object-size-flex-array.c
  clang/test/CodeGenObjC/ubsan-array-bounds.m
  clang/test/Sema/array-bounds-ptr-arith.c
  clang/test/SemaCXX/array-bounds-strict-flex-arrays.cpp
  clang/test/SemaCXX/array-bounds.cpp

Index: clang/test/SemaCXX/array-bounds.cpp
===
--- clang/test/SemaCXX/array-bounds.cpp
+++ clang/test/SemaCXX/array-bounds.cpp
@@ -208,12 +208,14 @@
 
 namespace metaprogramming {
 #define ONE 1
-  struct foo { char c[ONE]; }; // expected-note {{declared here}}
+struct foo {
+  char c[ONE];
+};
   template  struct bar { char c[N]; }; // expected-note {{declared here}}
 
   char test(foo *F, bar<1> *B) {
-return F->c[3] + // expected-warning {{array index 3 is past the end of the array (which contains 1 element)}}
-   B->c[3]; // expected-warning {{array index 3 is past the end of the array (which contains 1 element)}}
+return F->c[3] + // no-warning
+   B->c[3];  // expected-warning {{array index 3 is past the end of the array (which contains 1 element)}}
   }
 }
 
Index: clang/test/SemaCXX/array-bounds-strict-flex-arrays.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/array-bounds-strict-flex-arrays.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -verify -fstrict-flex-arrays=3 %s
+
+// We cannot know for sure the size of a flexible array.
+void test() {
+  struct {
+int f;
+int a[];
+  } s2;
+  s2.a[2] = 0; // no-warning
+}
+
+// Under -fstrict-flex-arrays `a` is not a flexible array.
+void test1() {
+  struct {
+int f;
+int a[1]; // expected-note {{declared here}}
+  } s2;
+  s2.a[2] = 0; // expected-warning 1 {{array index 2 is past the end of the array (which contains 1 element)}}
+}
Index: clang/test/Sema/array-bounds-ptr-arith.c
===
--- clang/test/Sema/array-bounds-ptr-arith.c
+++ clang/test/Sema/array-bounds-ptr-arith.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -verify -Warray-bounds-pointer-arithmetic %s
+// RUN: %clang_cc1 -verify -Warray-bounds-pointer-arithmetic -fstrict-flex-arrays=1 %s
 
 // Test case from PR10615
 struct ext2_super_block{
@@ -12,40 +12,3 @@
 {
 	 return (void *)es->s_uuid + 80; // expected-warning {{refers past the end of the array}}
 }
-
-// Test case reduced from PR11594
-struct S { int n; };
-void pr11594(struct S *s) {
-  int a[10];
-  int *p = a - s->n;
-}
-
-// Test case reduced from .  This resulted in
-// an assertion failure because of the typedef instead of an explicit
-// constant array type.
-struct RDar11387038 {};
-typedef struct RDar11387038 RDar11387038Array[1];
-struct RDar11387038_Table {
-  RDar11387038Array z;
-};
-typedef struct RDar11387038_Table * TPtr;
-typedef TPtr *TabHandle;
-struct RDar11387038_B { TabHandle x; };
-typedef struct RDar11387038_B RDar11387038_B;
-
-void radar11387038(void) {
-  RDar11387038_B *pRDar11387038_B;
-  struct RDar11387038* y = &(*pRDar11387038_B->x)->z[4];
-}
-
-void pr51682 (void) {
-  int arr [1];
-  switch (0) {
-case 0:
-  break;
-case 1:
-  asm goto (""::"r"(arr[42] >> 1)::failed); // no-warning
-  break;
-  }
-failed:;
-}
Index: clang/test/CodeGenObjC/ubsan-array-bounds.m
===
--- clang/test/CodeGenObjC/ubsan-array-bounds.m
+++ clang/test/CodeGenObjC/ubsan-array-bounds.m
@@ -14,46 +14,

[PATCH] D125944: Template instantiation error recovery

[Purva Chaudhari via Phabricator via cfe-commits]

Purva-Chaudhari updated this revision to Diff 440959.
Purva-Chaudhari added a comment.

Added new file for template test


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

https://reviews.llvm.org/D125944

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/test/Interpreter/templateRecovery.cpp


Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -9456,6 +9456,19 @@
 SavedPendingLocalImplicitInstantiations;
   };
 
+  class PerformPendingInstantiationsRAII {
+  public:
+PerformPendingInstantiationsRAII(Sema &S): S(S) {} ;
+
+~PerformPendingInstantiationsRAII() {
+  S.PerformPendingInstantiations();
+  assert(S.PendingInstantiations.empty() &&
+ "there shouldn't be any pending instantiations");
+}
+  private:
+Sema &S;
+  };
+
   /// A helper class for building up ExtParameterInfos.
   class ExtParameterInfoBuilder {
 SmallVector Infos;
Index: clang/lib/Interpreter/IncrementalParser.cpp
===
--- clang/lib/Interpreter/IncrementalParser.cpp
+++ clang/lib/Interpreter/IncrementalParser.cpp
@@ -177,6 +177,7 @@
   }
 
   DiagnosticsEngine &Diags = getCI()->getDiagnostics();
+  Sema::PerformPendingInstantiationsRAII PerformPendingInstantiations(S);
   if (Diags.hasErrorOccurred()) {
 TranslationUnitDecl *MostRecentTU = C.getTranslationUnitDecl();

Index: clang/test/Interpreter/templateRecovery.cpp
===
--- /dev/null
+++ clang/test/Interpreter/templateRecovery.cpp
@@ -0,0 +1,2 @@
+// RUN: clang-repl "template T f() { return T(); }" "auto ptu2 = 
f(); err;" \
+// RUN: "auto ptu2 = f();" "int i = 0;"


Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -9456,6 +9456,19 @@
 SavedPendingLocalImplicitInstantiations;
   };
 
+  class PerformPendingInstantiationsRAII {
+  public:
+PerformPendingInstantiationsRAII(Sema &S): S(S) {} ;
+
+~PerformPendingInstantiationsRAII() {
+  S.PerformPendingInstantiations();
+  assert(S.PendingInstantiations.empty() &&
+ "there shouldn't be any pending instantiations");
+}
+  private:
+Sema &S;
+  };
+
   /// A helper class for building up ExtParameterInfos.
   class ExtParameterInfoBuilder {
 SmallVector Infos;
Index: clang/lib/Interpreter/IncrementalParser.cpp
===
--- clang/lib/Interpreter/IncrementalParser.cpp
+++ clang/lib/Interpreter/IncrementalParser.cpp
@@ -177,6 +177,7 @@
   }
 
   DiagnosticsEngine &Diags = getCI()->getDiagnostics();
+  Sema::PerformPendingInstantiationsRAII PerformPendingInstantiations(S);
   if (Diags.hasErrorOccurred()) {
 TranslationUnitDecl *MostRecentTU = C.getTranslationUnitDecl();

Index: clang/test/Interpreter/templateRecovery.cpp
===
--- /dev/null
+++ clang/test/Interpreter/templateRecovery.cpp
@@ -0,0 +1,2 @@
+// RUN: clang-repl "template T f() { return T(); }" "auto ptu2 = f(); err;" \
+// RUN: "auto ptu2 = f();" "int i = 0;"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D128747: ISSUE - incorrect -Winfinite-recursion warning on potentially-unevaluated operand #21668

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Thank you for this fix, it's coming along well! Can you also add a release note 
to `clang/docs/ReleaseNotes.rst` mentioning the fix?




Comment at: clang/lib/Analysis/CFG.cpp:4062
+  //   operand. [...]
+  // We add only potentially evaluated statements to block to avoid
+  // CFG generation for unevaluated operands.





Comment at: clang/lib/Analysis/CFG.cpp:4064-4068
+  if (S && !S->isTypeDependent()) {
+if (S->isPotentiallyEvaluated()) {
+  return VisitChildren(S);
+}
+  }





Comment at: clang/test/SemaCXX/typeinfo:1-16
+namespace std {
+  class type_info {
+  public:
+virtual ~type_info();
+const char* name() const { return __name; }
+bool operator==(const type_info& __arg) const {
+ return __name == __arg.__name;

You should stick this into the place where it's used rather than a separate 
file, more comments below about why.



Comment at: clang/test/SemaCXX/warn-infinite-recursion.cpp:178
+struct Q {
+  virtual ~Q(){};
+};





Comment at: clang/test/SemaCXX/warn-infinite-recursion.cpp:191
+}
\ No newline at end of file


Please add a newline back to the end of the file.



Comment at: clang/test/SemaCXX/warn-infinite-recursion.cpp:3
 
+#include "typeinfo"
+

appmonster007 wrote:
> `#include ` resulted in 'typeinfo' file not found with  
> include; use "quotes" instead
Yup, that's actually by design. We don't want to include headers from the 
system because then we're testing against whatever happens to be installed on 
the machine running the test, which makes for poor test coverage. What we 
usually do is put the system header definitions directly into the file under 
test, or if it's code that's going to be shared by multiple tests, we'll make a 
file for it in the `Inputs` directory, and tell the `RUN` line to look there 
when doing an include. Then we always know exactly what we're testing against.

In this case, I'd just lower the `type_info` class into this file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128747

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

[clang] 64ab2b1 - Improve handling of static assert messages.

[Corentin Jabot via cfe-commits]

Author: Corentin Jabot
Date: 2022-06-29T14:57:35+02:00
New Revision: 64ab2b1dcc5136a744fcac21d3d2c59e9cce040a

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

LOG: Improve handling of static assert messages.

Instead of dumping the string literal (which
quotes it and escape every non-ascii symbol),
we can use the content of the string when it is a
8 byte string.

Wide, UTF-8/UTF-16/32 strings are still completely
escaped, until we clarify how these entities should
behave (cf https://wg21.link/p2361).

`FormatDiagnostic` is modified to escape
non printable characters and invalid UTF-8.

This ensures that unicode characters, spaces and new
lines are properly rendered in static messages.
This make clang more consistent with other implementation
and fixes this tweet
https://twitter.com/jfbastien/status/1298307325443231744 :)

Of note, `PaddingChecker` did print out new lines that were
later removed by the diagnostic printing code.
To be consistent with its tests, the new lines are removed
from the diagnostic.

Unicode tables updated to both use the Unicode definitions
and the Unicode 14.0 data.

U+00AD SOFT HYPHEN is still considered a print character
to match existing practices in terminals, in addition of
being considered a formatting character as per Unicode.

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

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/Basic/Diagnostic.cpp
clang/lib/Sema/SemaDeclCXX.cpp
clang/lib/StaticAnalyzer/Checkers/PaddingChecker.cpp
clang/test/Lexer/null-character-in-literal.c
clang/test/Misc/diag-special-chars.c
clang/test/Misc/wrong-encoding.c
clang/test/SemaCXX/static-assert.cpp
llvm/include/llvm/Support/Unicode.h
llvm/lib/Support/Unicode.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 3e29987ad2631..99288d0ffac4e 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -273,6 +273,8 @@ Improvements to Clang's diagnostics
 - When using class templates without arguments, clang now tells developers
   that template arguments are missing in certain contexts.
   This fixes `Issue 55962 
`_.
+- Printable Unicode characters within `static_assert` messages are no longer
+  escaped.
 
 Non-comprehensive list of changes in this release
 -

diff  --git a/clang/lib/Basic/Diagnostic.cpp b/clang/lib/Basic/Diagnostic.cpp
index deb398756e373..dbe62ecb50d33 100644
--- a/clang/lib/Basic/Diagnostic.cpp
+++ b/clang/lib/Basic/Diagnostic.cpp
@@ -25,8 +25,9 @@
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringRef.h"
+#include "llvm/Support/ConvertUTF.h"
 #include "llvm/Support/CrashRecoveryContext.h"
-#include "llvm/Support/Locale.h"
+#include "llvm/Support/Unicode.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
 #include 
@@ -803,6 +804,50 @@ FormatDiagnostic(SmallVectorImpl &OutStr) const {
   FormatDiagnostic(Diag.begin(), Diag.end(), OutStr);
 }
 
+/// pushEscapedString - Append Str to the diagnostic buffer,
+/// escaping non-printable characters and ill-formed code unit sequences.
+static void pushEscapedString(StringRef Str, SmallVectorImpl &OutStr) {
+  OutStr.reserve(OutStr.size() + Str.size());
+  auto *Begin = reinterpret_cast(Str.data());
+  llvm::raw_svector_ostream OutStream(OutStr);
+  const unsigned char *End = Begin + Str.size();
+  while (Begin != End) {
+// ASCII case
+if (isPrintable(*Begin) || isWhitespace(*Begin)) {
+  OutStream << *Begin;
+  ++Begin;
+  continue;
+}
+if (llvm::isLegalUTF8Sequence(Begin, End)) {
+  llvm::UTF32 CodepointValue;
+  llvm::UTF32 *CpPtr = &CodepointValue;
+  const unsigned char *CodepointBegin = Begin;
+  const unsigned char *CodepointEnd =
+  Begin + llvm::getNumBytesForUTF8(*Begin);
+  llvm::ConversionResult Res = llvm::ConvertUTF8toUTF32(
+  &Begin, CodepointEnd, &CpPtr, CpPtr + 1, llvm::strictConversion);
+  (void)Res;
+  assert(
+  llvm::conversionOK == Res &&
+  "the sequence is legal UTF-8 but we couldn't convert it to UTF-32");
+  assert(Begin == CodepointEnd &&
+ "we must be further along in the string now");
+  if (llvm::sys::unicode::isPrintable(CodepointValue) ||
+  llvm::sys::unicode::isFormatting(CodepointValue)) {
+OutStr.append(CodepointBegin, CodepointEnd);
+continue;
+  }
+  // Unprintable code point.
+  OutStream << "";
+  continue;
+}
+// Invalid code unit.
+OutStream << "<" << llvm::format_hex_no_prefix(*Begin, 2, true) << ">";

[PATCH] D108469: Improve handling of static assert messages.

[Corentin Jabot 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 rG64ab2b1dcc51: Improve handling of static assert messages. 
(authored by cor3ntin).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108469

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Basic/Diagnostic.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/StaticAnalyzer/Checkers/PaddingChecker.cpp
  clang/test/Lexer/null-character-in-literal.c
  clang/test/Misc/diag-special-chars.c
  clang/test/Misc/wrong-encoding.c
  clang/test/SemaCXX/static-assert.cpp
  llvm/include/llvm/Support/Unicode.h
  llvm/lib/Support/Unicode.cpp

Index: llvm/lib/Support/Unicode.cpp
===
--- llvm/lib/Support/Unicode.cpp
+++ llvm/lib/Support/Unicode.cpp
@@ -19,197 +19,271 @@
 namespace sys {
 namespace unicode {
 
+/// Unicode code points of the categories L, M, N, P, S and Zs are considered
+/// printable.
+/// In addition, U+00AD SOFT HYPHEN is also considered printable, as
+/// it's actually displayed on most terminals. \return true if the character is
+/// considered printable.
 bool isPrintable(int UCS) {
-  // Sorted list of non-overlapping intervals of code points that are not
-  // supposed to be printable.
-  static const UnicodeCharRange NonPrintableRanges[] = {
-{ 0x, 0x001F }, { 0x007F, 0x009F }, { 0x034F, 0x034F },
-{ 0x0378, 0x0379 }, { 0x037F, 0x0383 }, { 0x038B, 0x038B },
-{ 0x038D, 0x038D }, { 0x03A2, 0x03A2 }, { 0x0528, 0x0530 },
-{ 0x0557, 0x0558 }, { 0x0560, 0x0560 }, { 0x0588, 0x0588 },
-{ 0x058B, 0x058E }, { 0x0590, 0x0590 }, { 0x05C8, 0x05CF },
-{ 0x05EB, 0x05EF }, { 0x05F5, 0x0605 }, { 0x061C, 0x061D },
-{ 0x06DD, 0x06DD }, { 0x070E, 0x070F }, { 0x074B, 0x074C },
-{ 0x07B2, 0x07BF }, { 0x07FB, 0x07FF }, { 0x082E, 0x082F },
-{ 0x083F, 0x083F }, { 0x085C, 0x085D }, { 0x085F, 0x089F },
-{ 0x08A1, 0x08A1 }, { 0x08AD, 0x08E3 }, { 0x08FF, 0x08FF },
-{ 0x0978, 0x0978 }, { 0x0980, 0x0980 }, { 0x0984, 0x0984 },
-{ 0x098D, 0x098E }, { 0x0991, 0x0992 }, { 0x09A9, 0x09A9 },
-{ 0x09B1, 0x09B1 }, { 0x09B3, 0x09B5 }, { 0x09BA, 0x09BB },
-{ 0x09C5, 0x09C6 }, { 0x09C9, 0x09CA }, { 0x09CF, 0x09D6 },
-{ 0x09D8, 0x09DB }, { 0x09DE, 0x09DE }, { 0x09E4, 0x09E5 },
-{ 0x09FC, 0x0A00 }, { 0x0A04, 0x0A04 }, { 0x0A0B, 0x0A0E },
-{ 0x0A11, 0x0A12 }, { 0x0A29, 0x0A29 }, { 0x0A31, 0x0A31 },
-{ 0x0A34, 0x0A34 }, { 0x0A37, 0x0A37 }, { 0x0A3A, 0x0A3B },
-{ 0x0A3D, 0x0A3D }, { 0x0A43, 0x0A46 }, { 0x0A49, 0x0A4A },
-{ 0x0A4E, 0x0A50 }, { 0x0A52, 0x0A58 }, { 0x0A5D, 0x0A5D },
-{ 0x0A5F, 0x0A65 }, { 0x0A76, 0x0A80 }, { 0x0A84, 0x0A84 },
-{ 0x0A8E, 0x0A8E }, { 0x0A92, 0x0A92 }, { 0x0AA9, 0x0AA9 },
-{ 0x0AB1, 0x0AB1 }, { 0x0AB4, 0x0AB4 }, { 0x0ABA, 0x0ABB },
-{ 0x0AC6, 0x0AC6 }, { 0x0ACA, 0x0ACA }, { 0x0ACE, 0x0ACF },
-{ 0x0AD1, 0x0ADF }, { 0x0AE4, 0x0AE5 }, { 0x0AF2, 0x0B00 },
-{ 0x0B04, 0x0B04 }, { 0x0B0D, 0x0B0E }, { 0x0B11, 0x0B12 },
-{ 0x0B29, 0x0B29 }, { 0x0B31, 0x0B31 }, { 0x0B34, 0x0B34 },
-{ 0x0B3A, 0x0B3B }, { 0x0B45, 0x0B46 }, { 0x0B49, 0x0B4A },
-{ 0x0B4E, 0x0B55 }, { 0x0B58, 0x0B5B }, { 0x0B5E, 0x0B5E },
-{ 0x0B64, 0x0B65 }, { 0x0B78, 0x0B81 }, { 0x0B84, 0x0B84 },
-{ 0x0B8B, 0x0B8D }, { 0x0B91, 0x0B91 }, { 0x0B96, 0x0B98 },
-{ 0x0B9B, 0x0B9B }, { 0x0B9D, 0x0B9D }, { 0x0BA0, 0x0BA2 },
-{ 0x0BA5, 0x0BA7 }, { 0x0BAB, 0x0BAD }, { 0x0BBA, 0x0BBD },
-{ 0x0BC3, 0x0BC5 }, { 0x0BC9, 0x0BC9 }, { 0x0BCE, 0x0BCF },
-{ 0x0BD1, 0x0BD6 }, { 0x0BD8, 0x0BE5 }, { 0x0BFB, 0x0C00 },
-{ 0x0C04, 0x0C04 }, { 0x0C0D, 0x0C0D }, { 0x0C11, 0x0C11 },
-{ 0x0C29, 0x0C29 }, { 0x0C34, 0x0C34 }, { 0x0C3A, 0x0C3C },
-{ 0x0C45, 0x0C45 }, { 0x0C49, 0x0C49 }, { 0x0C4E, 0x0C54 },
-{ 0x0C57, 0x0C57 }, { 0x0C5A, 0x0C5F }, { 0x0C64, 0x0C65 },
-{ 0x0C70, 0x0C77 }, { 0x0C80, 0x0C81 }, { 0x0C84, 0x0C84 },
-{ 0x0C8D, 0x0C8D }, { 0x0C91, 0x0C91 }, { 0x0CA9, 0x0CA9 },
-{ 0x0CB4, 0x0CB4 }, { 0x0CBA, 0x0CBB }, { 0x0CC5, 0x0CC5 },
-{ 0x0CC9, 0x0CC9 }, { 0x0CCE, 0x0CD4 }, { 0x0CD7, 0x0CDD },
-{ 0x0CDF, 0x0CDF }, { 0x0CE4, 0x0CE5 }, { 0x0CF0, 0x0CF0 },
-{ 0x0CF3, 0x0D01 }, { 0x0D04, 0x0D04 }, { 0x0D0D, 0x0D0D },
-{ 0x0D11, 0x0D11 }, { 0x0D3B, 0x0D3C }, { 0x0D45, 0x0D45 },
-{ 0x0D49, 0x0D49 }, { 0x0D4F, 0x0D56 }, { 0x0D58, 0x0D5F },
-{ 0x0D64, 0x0D65 }, { 0x0D76, 0x0D78 }, { 0x0D80, 0x0D81 },
-{ 0x0D84, 0x0D84 }, { 0x0D97, 0x0D99 }, { 0x0DB2, 0x0DB2 },
-{ 0x0DBC, 0x0DBC }, { 0x0DBE, 0x0DBF }, { 0x0DC7, 0x0DC9 },
-{ 0x0DCB, 0x0DCE }, { 0x0DD5, 0x0DD5 }, { 0x0DD7, 0x0DD7 },
-{ 0x0DE0, 0x0DF1 }, { 0x0DF5, 0x0E00 }, { 0x0E3B, 0x0E3E },
-{ 0x0E5C, 0x0E80 }, { 0x0E83, 0x0E83 }, { 0x0E85, 0x0E86 },
-{ 0x0E89, 0x0E89 }, { 0x0E8B, 0x0E8C }, { 0x0E8E, 0x0E93 },
-{ 0x0E98, 0x0E98 }, { 0x

[PATCH] D128812: [pseudo] prototype build syntax-tree from the parse forest.

[Haojian Wu via Phabricator via cfe-commits]

hokein created this revision.
Herald added a subscriber: mgorny.
Herald added a project: All.
hokein requested review of this revision.
Herald added subscribers: cfe-commits, alextsao1999.
Herald added projects: clang, clang-tools-extra.

WARNING: this is an extremely-hacked prototype.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128812

Files:
  clang-tools-extra/pseudo/include/clang-pseudo/syntax/SyntaxTree.h
  clang-tools-extra/pseudo/lib/CMakeLists.txt
  clang-tools-extra/pseudo/lib/syntax/Build.cpp
  clang-tools-extra/pseudo/lib/syntax/CMakeLists.txt
  clang-tools-extra/pseudo/tool/CMakeLists.txt
  clang-tools-extra/pseudo/tool/ClangPseudo.cpp
  clang/include/clang/Tooling/Syntax/Nodes.h
  clang/lib/Tooling/Syntax/Nodes.cpp
  clang/lib/Tooling/Syntax/Synthesis.cpp

Index: clang/lib/Tooling/Syntax/Synthesis.cpp
===
--- clang/lib/Tooling/Syntax/Synthesis.cpp
+++ clang/lib/Tooling/Syntax/Synthesis.cpp
@@ -62,6 +62,7 @@
 // Allocates the concrete syntax `Tree` according to its `NodeKind`.
 syntax::Tree *allocateTree(syntax::Arena &A, syntax::NodeKind Kind) {
   switch (Kind) {
+  case syntax::NodeKind::PLeaf:
   case syntax::NodeKind::OLeaf:
   case syntax::NodeKind::Leaf:
 assert(false);
Index: clang/lib/Tooling/Syntax/Nodes.cpp
===
--- clang/lib/Tooling/Syntax/Nodes.cpp
+++ clang/lib/Tooling/Syntax/Nodes.cpp
@@ -12,6 +12,9 @@
 
 raw_ostream &syntax::operator<<(raw_ostream &OS, NodeKind K) {
   switch (K) {
+  case NodeKind::PLeaf:
+OS << "PLeaf";
+break;
 #define CONCRETE_NODE(Kind, Parent)\
   case NodeKind::Kind: \
 return OS << #Kind;
Index: clang/include/clang/Tooling/Syntax/Nodes.h
===
--- clang/include/clang/Tooling/Syntax/Nodes.h
+++ clang/include/clang/Tooling/Syntax/Nodes.h
@@ -31,6 +31,7 @@
 /// blocks of enumerator constants must correspond to the inheritance hierarchy
 /// of syntax::Node.
 enum class NodeKind : uint16_t {
+  PLeaf,
 #define CONCRETE_NODE(Kind, Base) Kind,
 #include "clang/Tooling/Syntax/Nodes.inc"
 };
Index: clang-tools-extra/pseudo/tool/ClangPseudo.cpp
===
--- clang-tools-extra/pseudo/tool/ClangPseudo.cpp
+++ clang-tools-extra/pseudo/tool/ClangPseudo.cpp
@@ -14,6 +14,7 @@
 #include "clang-pseudo/grammar/Grammar.h"
 #include "clang-pseudo/grammar/LRGraph.h"
 #include "clang-pseudo/grammar/LRTable.h"
+#include "clang-pseudo/syntax/SyntaxTree.h"
 #include "clang/Basic/LangOptions.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/CommandLine.h"
@@ -117,8 +118,12 @@
   auto &Root =
   glrParse(*ParseableStream,
clang::pseudo::ParseParams{Lang, Arena, GSS}, *StartSymID);
-  if (PrintForest)
+  if (PrintForest) {
 llvm::outs() << Root.dumpRecursive(Lang.G, /*Abbreviated=*/true);
+llvm::BumpPtrAllocator A;
+llvm::outs() << clang::pseudo::dumpSyntaxTree(
+clang::pseudo::buildSyntaxTree(A, Root, *ParseableStream));
+  }
 
   if (PrintStatistics) {
 llvm::outs() << "Forest bytes: " << Arena.bytes()
Index: clang-tools-extra/pseudo/tool/CMakeLists.txt
===
--- clang-tools-extra/pseudo/tool/CMakeLists.txt
+++ clang-tools-extra/pseudo/tool/CMakeLists.txt
@@ -13,6 +13,7 @@
   PRIVATE
   clangPseudo
   clangPseudoGrammar
+  clangPseudoSyntax
   clangPseudoCLI
   )
 
Index: clang-tools-extra/pseudo/lib/syntax/CMakeLists.txt
===
--- /dev/null
+++ clang-tools-extra/pseudo/lib/syntax/CMakeLists.txt
@@ -0,0 +1,11 @@
+set(LLVM_LINK_COMPONENTS Support)
+
+add_clang_library(clangPseudoSyntax
+  Build.cpp
+
+  LINK_LIBS
+  clangSyntaxTree
+  clangPseudo
+  clangPseudoGrammar
+  )
+
Index: clang-tools-extra/pseudo/lib/syntax/Build.cpp
===
--- /dev/null
+++ clang-tools-extra/pseudo/lib/syntax/Build.cpp
@@ -0,0 +1,188 @@
+
+
+#include "clang-pseudo/Forest.h"
+#include "clang-pseudo/cxx/CXX.h"
+#include "clang-pseudo/grammar/Grammar.h"
+#include "clang-pseudo/syntax/SyntaxTree.h"
+#include "clang/Tooling/Syntax/Nodes.h"
+#include "clang/Tooling/Syntax/Tree.h"
+#include "llvm/ADT/BitVector.h"
+
+namespace clang {
+namespace syntax {
+class TreeBuilder {
+public:
+  TreeBuilder(llvm::BumpPtrAllocator &Arena) : Arena(Arena) {}
+
+  syntax::Node *build(const pseudo::ForestNode &Node,
+  const pseudo::TokenStream &Tokens) {
+for (const auto &T : Tokens.tokens()) {
+  Leaves.push_back(new (Arena) syntax::PLeaf(&T));
+  Leaves.back()->setRole(NodeRole::Unknown);
+  Leaves.back()->Original = Leaves

[PATCH] D128762: [Clang] Rename StringLiteral::isAscii() => isOrdinary() [NFC]

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/AST/Expr.h:1789-1886
+  enum StringKind { Ordinary, Wide, UTF8, UTF16, UTF32 };
 
 private:
   unsigned numTrailingObjects(OverloadToken) const { return 1; }
   unsigned numTrailingObjects(OverloadToken) const {
 return getNumConcatenated();
   }

I like the idea of renaming both of these -- `isASCII()` can be a bit confusing 
with `containsNonAscii()` as well. However, instead of "ordinary", would it 
make more sense to go with "narrow" as the term of art? That also goes nicely 
with the use of "wide" in this interface.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128762

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

[PATCH] D128762: [Clang] Rename StringLiteral::isAscii() => isOrdinary() [NFC]

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Also, precommit CI pointed out that you need to make some additional changes in 
clang-tools-extra to avoid build errors.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128762

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

[PATCH] D128814: [Clang][Preprocessor] Fix inconsistent `FLT_EVAL_METHOD` when compiling vs preprocessing

[Egor Zhdan via Phabricator via cfe-commits]

egorzhdan created this revision.
egorzhdan added a reviewer: zahiraam.
Herald added a project: All.
egorzhdan requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

When running `clang -E -Ofast` on macOS, the `__FLT_EVAL_METHOD__` macro is 
`0`, which causes the following typedef to be emitted into the preprocessed 
source: `typedef float float_t`.

However, when running `clang -c -Ofast`, `__FLT_EVAL_METHOD__` is `-1`, and 
`typedef long double float_t` is emitted.

This causes build errors for certain projects, which are not reproducible when 
compiling from preprocessed source.

The issue is that `__FLT_EVAL_METHOD__` is configured in `Sema::Sema` which is 
not executed when running in `-E` mode.

This change moves that logic into the preprocessor initialization method, which 
is invoked correctly in `-E` mode.

rdar://92748429


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128814

Files:
  clang/lib/Lex/Preprocessor.cpp
  clang/lib/Sema/Sema.cpp
  clang/test/Preprocessor/flt_eval_macro.cpp


Index: clang/test/Preprocessor/flt_eval_macro.cpp
===
--- clang/test/Preprocessor/flt_eval_macro.cpp
+++ clang/test/Preprocessor/flt_eval_macro.cpp
@@ -16,6 +16,9 @@
 // RUN: %clang_cc1 -E -dM -triple=arm64_32-apple-ios -target-feature -sse \
 // RUN:   %s -o - | FileCheck %s  -strict-whitespace
 
+// RUN: %clang_cc1 -E -dM -triple=x86_64-apple-macos13.0 -ffast-math \
+// RUN:   %s -o - | FileCheck %s -check-prefix=CHECK-MINUS-ONE 
-strict-whitespace
+
 // RUN: %clang_cc1 -E -dM -triple i386-pc-windows -target-cpu pentium4 %s -o - 
\
 // RUN:   | FileCheck %s  -strict-whitespace
 
@@ -35,7 +38,9 @@
 #define __GLIBC_FLT_EVAL_METHOD 2
 #endif
 
-#if __GLIBC_FLT_EVAL_METHOD == 0 || __GLIBC_FLT_EVAL_METHOD == 16
+#if __GLIBC_FLT_EVAL_METHOD == -1
+#define Name "MinusOne"
+#elif __GLIBC_FLT_EVAL_METHOD == 0 || __GLIBC_FLT_EVAL_METHOD == 16
 #define Name "One"
 #elif __GLIBC_FLT_EVAL_METHOD == 1
 #define Name "Two"
@@ -59,6 +64,7 @@
 
 int foo() {
   // CHECK: #define Name "One"
+  // CHECK-MINUS-ONE: #define Name "MinusOne"
   // EXT: #define Name "Three"
   return Name;
 }
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -249,21 +249,8 @@
   SemaPPCallbackHandler = Callbacks.get();
   PP.addPPCallbacks(std::move(Callbacks));
   SemaPPCallbackHandler->set(*this);
-  if (getLangOpts().getFPEvalMethod() == LangOptions::FEM_UnsetOnCommandLine)
-// Use setting from TargetInfo.
-PP.setCurrentFPEvalMethod(SourceLocation(),
-  ctxt.getTargetInfo().getFPEvalMethod());
-  else
-// Set initial value of __FLT_EVAL_METHOD__ from the command line.
-PP.setCurrentFPEvalMethod(SourceLocation(),
-  getLangOpts().getFPEvalMethod());
+
   CurFPFeatures.setFPEvalMethod(PP.getCurrentFPEvalMethod());
-  // When `-ffast-math` option is enabled, it triggers several driver math
-  // options to be enabled. Among those, only one the following two modes
-  // affect the eval-method:  reciprocal or reassociate.
-  if (getLangOpts().AllowFPReassoc || getLangOpts().AllowRecip)
-PP.setCurrentFPEvalMethod(SourceLocation(),
-  LangOptions::FEM_Indeterminable);
 }
 
 // Anchor Sema's type info to this TU.
Index: clang/lib/Lex/Preprocessor.cpp
===
--- clang/lib/Lex/Preprocessor.cpp
+++ clang/lib/Lex/Preprocessor.cpp
@@ -206,6 +206,18 @@
 
   // Initialize the __FTL_EVAL_METHOD__ macro to the TargetInfo.
   setTUFPEvalMethod(getTargetInfo().getFPEvalMethod());
+
+  if (getLangOpts().getFPEvalMethod() == LangOptions::FEM_UnsetOnCommandLine)
+// Use setting from TargetInfo.
+setCurrentFPEvalMethod(SourceLocation(), Target.getFPEvalMethod());
+  else
+// Set initial value of __FLT_EVAL_METHOD__ from the command line.
+setCurrentFPEvalMethod(SourceLocation(), getLangOpts().getFPEvalMethod());
+  // When `-ffast-math` option is enabled, it triggers several driver math
+  // options to be enabled. Among those, only one the following two modes
+  // affect the eval-method:  reciprocal or reassociate.
+  if (getLangOpts().AllowFPReassoc || getLangOpts().AllowRecip)
+setCurrentFPEvalMethod(SourceLocation(), LangOptions::FEM_Indeterminable);
 }
 
 void Preprocessor::InitializeForModelFile() {


Index: clang/test/Preprocessor/flt_eval_macro.cpp
===
--- clang/test/Preprocessor/flt_eval_macro.cpp
+++ clang/test/Preprocessor/flt_eval_macro.cpp
@@ -16,6 +16,9 @@
 // RUN: %clang_cc1 -E -dM -triple=arm64_32-apple-ios -target-feature -sse \
 // RUN:   %s -o - | FileCheck %s  -strict-whitespace
 
+// RUN: %clang_cc1 -E -dM -triple=x86_64-apple-macos13.0 -ffast-math \
+// RUN:   %s -o -

[clang-tools-extra] 1ba7f52 - [pseudo] Update the cxx.bnf path in comments to reflect the new

[Haojian Wu via cfe-commits]

Author: Haojian Wu
Date: 2022-06-29T15:10:39+02:00
New Revision: 1ba7f5218ccdc0b4fd836cb4f0d647866f793c87

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

LOG: [pseudo] Update the cxx.bnf path in comments to reflect the new
location, NFC

Added: 


Modified: 
clang-tools-extra/pseudo/include/clang-pseudo/cxx/CXX.h
clang-tools-extra/pseudo/test/check-cxx-bnf.test

Removed: 




diff  --git a/clang-tools-extra/pseudo/include/clang-pseudo/cxx/CXX.h 
b/clang-tools-extra/pseudo/include/clang-pseudo/cxx/CXX.h
index 4acad01588124..707297d3fb32d 100644
--- a/clang-tools-extra/pseudo/include/clang-pseudo/cxx/CXX.h
+++ b/clang-tools-extra/pseudo/include/clang-pseudo/cxx/CXX.h
@@ -7,9 +7,9 @@
 
//===--===//
 //
 //  This file defines public interfaces for the C++ grammar
-//  (pseudo/lib/cxx.bnf). It provides a fast way to access core building pieces
-//  of the LR parser, e.g. Grammar, LRTable, rather than parsing the grammar
-//  file at the runtime.
+//  (pseudo/lib/cxx/cxx.bnf). It provides a fast way to access core building
+//  pieces of the LR parser, e.g. Grammar, LRTable, rather than parsing the
+//  grammar file at the runtime.
 //
 //  We do a compilation of the C++ BNF grammar at build time, and generate
 //  critical data sources. The implementation of the interfaces are based on 
the

diff  --git a/clang-tools-extra/pseudo/test/check-cxx-bnf.test 
b/clang-tools-extra/pseudo/test/check-cxx-bnf.test
index e7e7194257629..b825ff32faa1c 100644
--- a/clang-tools-extra/pseudo/test/check-cxx-bnf.test
+++ b/clang-tools-extra/pseudo/test/check-cxx-bnf.test
@@ -1,2 +1,2 @@
-// verify clang/lib/Tooling/Syntax/Pseudo/cxx.bnf
+// verify clang/lib/Tooling/Syntax/Pseudo/cxx/cxx.bnf
 // RUN: clang-pseudo -grammar=%cxx-bnf-file



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

[PATCH] D128814: [Clang][Preprocessor] Fix inconsistent `FLT_EVAL_METHOD` when compiling vs preprocessing

[Egor Zhdan via Phabricator via cfe-commits]

egorzhdan updated this revision to Diff 440978.
egorzhdan added a comment.

Adjust commit message


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128814

Files:
  clang/lib/Lex/Preprocessor.cpp
  clang/lib/Sema/Sema.cpp
  clang/test/Preprocessor/flt_eval_macro.cpp


Index: clang/test/Preprocessor/flt_eval_macro.cpp
===
--- clang/test/Preprocessor/flt_eval_macro.cpp
+++ clang/test/Preprocessor/flt_eval_macro.cpp
@@ -16,6 +16,9 @@
 // RUN: %clang_cc1 -E -dM -triple=arm64_32-apple-ios -target-feature -sse \
 // RUN:   %s -o - | FileCheck %s  -strict-whitespace
 
+// RUN: %clang_cc1 -E -dM -triple=x86_64-apple-macos13.0 -ffast-math \
+// RUN:   %s -o - | FileCheck %s -check-prefix=CHECK-MINUS-ONE 
-strict-whitespace
+
 // RUN: %clang_cc1 -E -dM -triple i386-pc-windows -target-cpu pentium4 %s -o - 
\
 // RUN:   | FileCheck %s  -strict-whitespace
 
@@ -35,7 +38,9 @@
 #define __GLIBC_FLT_EVAL_METHOD 2
 #endif
 
-#if __GLIBC_FLT_EVAL_METHOD == 0 || __GLIBC_FLT_EVAL_METHOD == 16
+#if __GLIBC_FLT_EVAL_METHOD == -1
+#define Name "MinusOne"
+#elif __GLIBC_FLT_EVAL_METHOD == 0 || __GLIBC_FLT_EVAL_METHOD == 16
 #define Name "One"
 #elif __GLIBC_FLT_EVAL_METHOD == 1
 #define Name "Two"
@@ -59,6 +64,7 @@
 
 int foo() {
   // CHECK: #define Name "One"
+  // CHECK-MINUS-ONE: #define Name "MinusOne"
   // EXT: #define Name "Three"
   return Name;
 }
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -249,21 +249,8 @@
   SemaPPCallbackHandler = Callbacks.get();
   PP.addPPCallbacks(std::move(Callbacks));
   SemaPPCallbackHandler->set(*this);
-  if (getLangOpts().getFPEvalMethod() == LangOptions::FEM_UnsetOnCommandLine)
-// Use setting from TargetInfo.
-PP.setCurrentFPEvalMethod(SourceLocation(),
-  ctxt.getTargetInfo().getFPEvalMethod());
-  else
-// Set initial value of __FLT_EVAL_METHOD__ from the command line.
-PP.setCurrentFPEvalMethod(SourceLocation(),
-  getLangOpts().getFPEvalMethod());
+
   CurFPFeatures.setFPEvalMethod(PP.getCurrentFPEvalMethod());
-  // When `-ffast-math` option is enabled, it triggers several driver math
-  // options to be enabled. Among those, only one the following two modes
-  // affect the eval-method:  reciprocal or reassociate.
-  if (getLangOpts().AllowFPReassoc || getLangOpts().AllowRecip)
-PP.setCurrentFPEvalMethod(SourceLocation(),
-  LangOptions::FEM_Indeterminable);
 }
 
 // Anchor Sema's type info to this TU.
Index: clang/lib/Lex/Preprocessor.cpp
===
--- clang/lib/Lex/Preprocessor.cpp
+++ clang/lib/Lex/Preprocessor.cpp
@@ -206,6 +206,18 @@
 
   // Initialize the __FTL_EVAL_METHOD__ macro to the TargetInfo.
   setTUFPEvalMethod(getTargetInfo().getFPEvalMethod());
+
+  if (getLangOpts().getFPEvalMethod() == LangOptions::FEM_UnsetOnCommandLine)
+// Use setting from TargetInfo.
+setCurrentFPEvalMethod(SourceLocation(), Target.getFPEvalMethod());
+  else
+// Set initial value of __FLT_EVAL_METHOD__ from the command line.
+setCurrentFPEvalMethod(SourceLocation(), getLangOpts().getFPEvalMethod());
+  // When `-ffast-math` option is enabled, it triggers several driver math
+  // options to be enabled. Among those, only one the following two modes
+  // affect the eval-method:  reciprocal or reassociate.
+  if (getLangOpts().AllowFPReassoc || getLangOpts().AllowRecip)
+setCurrentFPEvalMethod(SourceLocation(), LangOptions::FEM_Indeterminable);
 }
 
 void Preprocessor::InitializeForModelFile() {


Index: clang/test/Preprocessor/flt_eval_macro.cpp
===
--- clang/test/Preprocessor/flt_eval_macro.cpp
+++ clang/test/Preprocessor/flt_eval_macro.cpp
@@ -16,6 +16,9 @@
 // RUN: %clang_cc1 -E -dM -triple=arm64_32-apple-ios -target-feature -sse \
 // RUN:   %s -o - | FileCheck %s  -strict-whitespace
 
+// RUN: %clang_cc1 -E -dM -triple=x86_64-apple-macos13.0 -ffast-math \
+// RUN:   %s -o - | FileCheck %s -check-prefix=CHECK-MINUS-ONE -strict-whitespace
+
 // RUN: %clang_cc1 -E -dM -triple i386-pc-windows -target-cpu pentium4 %s -o - \
 // RUN:   | FileCheck %s  -strict-whitespace
 
@@ -35,7 +38,9 @@
 #define __GLIBC_FLT_EVAL_METHOD 2
 #endif
 
-#if __GLIBC_FLT_EVAL_METHOD == 0 || __GLIBC_FLT_EVAL_METHOD == 16
+#if __GLIBC_FLT_EVAL_METHOD == -1
+#define Name "MinusOne"
+#elif __GLIBC_FLT_EVAL_METHOD == 0 || __GLIBC_FLT_EVAL_METHOD == 16
 #define Name "One"
 #elif __GLIBC_FLT_EVAL_METHOD == 1
 #define Name "Two"
@@ -59,6 +64,7 @@
 
 int foo() {
   // CHECK: #define Name "One"
+  // CHECK-MINUS-ONE: #define Name "MinusOne"
   // EXT: #define Name "Three"
   return Name;
 }
Index: clang/lib/Sema/Sema.cpp
=

[PATCH] D125944: Template instantiation error recovery

[Purva Chaudhari via Phabricator via cfe-commits]

Purva-Chaudhari updated this revision to Diff 440980.
Purva-Chaudhari added a comment.

File name


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

https://reviews.llvm.org/D125944

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/test/Interpreter/template-recovery.cpp


Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -9456,6 +9456,19 @@
 SavedPendingLocalImplicitInstantiations;
   };
 
+  class PerformPendingInstantiationsRAII {
+  public:
+PerformPendingInstantiationsRAII(Sema &S): S(S) {} ;
+
+~PerformPendingInstantiationsRAII() {
+  S.PerformPendingInstantiations();
+  assert(S.PendingInstantiations.empty() &&
+ "there shouldn't be any pending instantiations");
+}
+  private:
+Sema &S;
+  };
+
   /// A helper class for building up ExtParameterInfos.
   class ExtParameterInfoBuilder {
 SmallVector Infos;
Index: clang/lib/Interpreter/IncrementalParser.cpp
===
--- clang/lib/Interpreter/IncrementalParser.cpp
+++ clang/lib/Interpreter/IncrementalParser.cpp
@@ -177,6 +177,7 @@
   }
 
   DiagnosticsEngine &Diags = getCI()->getDiagnostics();
+  Sema::PerformPendingInstantiationsRAII PerformPendingInstantiations(S);
   if (Diags.hasErrorOccurred()) {
 TranslationUnitDecl *MostRecentTU = C.getTranslationUnitDecl();

Index: clang/test/Interpreter/template-recovery.cpp
===
--- /dev/null
+++ clang/test/Interpreter/template-recovery.cpp
@@ -0,0 +1,2 @@
+// RUN: clang-repl "template T f() { return T(); }" "auto ptu2 = 
f(); err;" \
+// RUN: "auto ptu2 = f();" "int i = 0;"


Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -9456,6 +9456,19 @@
 SavedPendingLocalImplicitInstantiations;
   };
 
+  class PerformPendingInstantiationsRAII {
+  public:
+PerformPendingInstantiationsRAII(Sema &S): S(S) {} ;
+
+~PerformPendingInstantiationsRAII() {
+  S.PerformPendingInstantiations();
+  assert(S.PendingInstantiations.empty() &&
+ "there shouldn't be any pending instantiations");
+}
+  private:
+Sema &S;
+  };
+
   /// A helper class for building up ExtParameterInfos.
   class ExtParameterInfoBuilder {
 SmallVector Infos;
Index: clang/lib/Interpreter/IncrementalParser.cpp
===
--- clang/lib/Interpreter/IncrementalParser.cpp
+++ clang/lib/Interpreter/IncrementalParser.cpp
@@ -177,6 +177,7 @@
   }
 
   DiagnosticsEngine &Diags = getCI()->getDiagnostics();
+  Sema::PerformPendingInstantiationsRAII PerformPendingInstantiations(S);
   if (Diags.hasErrorOccurred()) {
 TranslationUnitDecl *MostRecentTU = C.getTranslationUnitDecl();

Index: clang/test/Interpreter/template-recovery.cpp
===
--- /dev/null
+++ clang/test/Interpreter/template-recovery.cpp
@@ -0,0 +1,2 @@
+// RUN: clang-repl "template T f() { return T(); }" "auto ptu2 = f(); err;" \
+// RUN: "auto ptu2 = f();" "int i = 0;"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D128816: [OpenMP] Add loop tripcount argument to kernel launch and remove push function

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 created this revision.
jhuber6 added reviewers: jdoerfert, tianshilei1992, JonChesterfield, ABataev.
Herald added subscribers: mattd, asavonic, guansong, yaxunl.
Herald added a project: All.
jhuber6 requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, sstefan1.
Herald added projects: clang, LLVM.

Previously we added the `push_target_tripcount` function to send the
loop tripcount to the device runtime so we knew how to configure the
teams / threads for execute the loop for a teams distribute construct.
This was implemented as a separate function mostly to avoid changing the
interface for backwards compatbility. Now that we've changed it anyway
and the new interface can take an arbitrary number of arguments via the
struct without changing the ABI, we can move this to the new interface.
This will simplify the runtime by removing unnecessary state between
calls.

Depends on D128550 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128816

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.h
  clang/test/OpenMP/distribute_codegen.cpp
  clang/test/OpenMP/distribute_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_num_threads_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_private_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_proc_bind_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_num_threads_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_private_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_proc_bind_codegen.cpp
  clang/test/OpenMP/distribute_private_codegen.cpp
  clang/test/OpenMP/distribute_simd_codegen.cpp
  clang/test/OpenMP/distribute_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_simd_private_codegen.cpp
  clang/test/OpenMP/distribute_simd_reduction_codegen.cpp
  clang/test/OpenMP/nvptx_lambda_capturing.cpp
  clang/test/OpenMP/reduction_implicit_map.cpp
  clang/test/OpenMP/target_codegen_global_capture.cpp
  clang/test/OpenMP/target_map_codegen_03.cpp
  clang/test/OpenMP/target_map_codegen_hold.cpp
  clang/test/OpenMP/target_offload_mandatory_codegen.cpp
  clang/test/OpenMP/target_parallel_codegen.cpp
  clang/test/OpenMP/target_parallel_for_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/target_parallel_if_codegen.cpp
  clang/test/OpenMP/target_parallel_num_threads_codegen.cpp
  clang/test/OpenMP/target_teams_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_collapse_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_dist_schedule_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_firstprivate_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_lastprivate_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_collapse_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_dist_schedule_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_firstprivate_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_if_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_lastprivate_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_order_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_private_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_proc_bind_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_reduction_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_schedule_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_simd_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_simd_collapse_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_simd_dist_schedule_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_simd_if_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_simd_lastprivate_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_simd_private_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_simd_proc_b

[PATCH] D128783: [test] Check for more -fsanitize=array-bounds regressions

[serge via Phabricator via cfe-commits]

serge-sans-paille added a comment.

In D128783#3617924 , @MaskRay wrote:

> Do we need a C test (just add a `-x c` RUN line)? @serge-sans-paille Do you 
> think we may likely make C++ stricter than C?

I've started a similar discussion on https://reviews.llvm.org/D126864, but I'm 
fine to discuss that here :-)

Some extra data points:

GCC doesn't special case macro expansion, nor non-standard layout, not even 
size that result from the expansion of a template parameter.

I *guess* bounds resulting from macro expansion could result from preprocessor 
parameters and then are somehow variable.

I *guess*  bounds resulting from template parameter expansion could result from 
various template instantiation and then are somehow variable.

I don't have a clue about non-standard layout interaction with FAM.

Following Chesterton's fence 
 we should understand why 
this was introduced in Clang, because it turns out this actually causes issues 
to (some) users, and without that knowledge I'd be in favor of adopting GCC 
behavior and not making C++ stricter than C here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128783

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

[PATCH] D128783: [test] Check for more -fsanitize=array-bounds regressions

[serge via Phabricator via cfe-commits]

serge-sans-paille added a comment.

And note that with current clang, the behavior I describe here is not uniform 
across clang code base :-/


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128783

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

[PATCH] D128805: [pseudo] Fix bugs/inconsistencies in forest dump.

[Haojian Wu via Phabricator via cfe-commits]

hokein accepted this revision.
hokein added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/pseudo/unittests/ForestTest.cpp:138
+
+  const auto *B = &Arena.createSequence(symbol("B"), ruleFor("B"), {Star});
+  const auto *A1 = &Arena.createSequence(symbol("A"), ruleFor("A"), {B});

I was confused by the forest here -- the fact that it doesn't reflect the 
grammar (I was trying to figure out why there is an ambiguous node for A by 
reading the grammar above)

I think there should be a comment clarifying the gap between the grammar and 
forest --  this is an artificial forest which is only for testing the dump 
purpose -- we only need the symbol bits from the grammar (I actual think 
`GLRTest::buildGrammar` is a better fit for the tests in this file). 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128805

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

[clang] 56ab966 - [CUDA] Stop adding CUDA features twice

[Joseph Huber via cfe-commits]

Author: Joseph Huber
Date: 2022-06-29T09:34:09-04:00
New Revision: 56ab966a04dd22570fcb18276e2409c94e82c571

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

LOG: [CUDA] Stop adding CUDA features twice

We currently call the `addNVPTXFeatures` function in two places, inside
of the CUDA Toolchain and inside of Clang in the standard entry point.
We normally add features to the job in Clang, so the call inside of the
CUDA toolchain is redundant and results in `+ptx` features being added.
Since we remove this call, we no longer will have a cached CUDA
installation so we will usually create it twice.

Reviewed By: tra

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Cuda.cpp
clang/lib/Driver/ToolChains/Cuda.h

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Cuda.cpp 
b/clang/lib/Driver/ToolChains/Cuda.cpp
index 0e87540d1615d..5e59677947e62 100644
--- a/clang/lib/Driver/ToolChains/Cuda.cpp
+++ b/clang/lib/Driver/ToolChains/Cuda.cpp
@@ -636,23 +636,20 @@ void NVPTX::OpenMPLinker::ConstructJob(Compilation &C, 
const JobAction &JA,
 
 void NVPTX::getNVPTXTargetFeatures(const Driver &D, const llvm::Triple &Triple,
const llvm::opt::ArgList &Args,
-   std::vector &Features,
-   Optional Version) {
+   std::vector &Features) {
   if (Args.hasArg(options::OPT_cuda_feature_EQ)) {
 StringRef PtxFeature =
 Args.getLastArgValue(options::OPT_cuda_feature_EQ, "+ptx42");
 Features.push_back(Args.MakeArgString(PtxFeature));
 return;
-  } else if (!Version) {
-CudaInstallationDetector CudaInstallation(D, Triple, Args);
-Version = CudaInstallation.version();
   }
+  CudaInstallationDetector CudaInstallation(D, Triple, Args);
 
   // New CUDA versions often introduce new instructions that are only supported
   // by new PTX version, so we need to raise PTX level to enable them in NVPTX
   // back-end.
   const char *PtxFeature = nullptr;
-  switch (*Version) {
+  switch (CudaInstallation.version()) {
 #define CASE_CUDA_VERSION(CUDA_VER, PTX_VER)   
\
   case CudaVersion::CUDA_##CUDA_VER:   
\
 PtxFeature = "+ptx" #PTX_VER;  
\
@@ -746,11 +743,6 @@ void CudaToolChain::addClangTargetOptions(
 
   clang::CudaVersion CudaInstallationVersion = CudaInstallation.version();
 
-  std::vector Features;
-  NVPTX::getNVPTXTargetFeatures(getDriver(), getTriple(), DriverArgs, Features,
-CudaInstallationVersion);
-  for (StringRef PtxFeature : Features)
-CC1Args.append({"-target-feature", DriverArgs.MakeArgString(PtxFeature)});
   if (DriverArgs.hasFlag(options::OPT_fcuda_short_ptr,
  options::OPT_fno_cuda_short_ptr, false))
 CC1Args.append({"-mllvm", "--nvptx-short-ptr"});

diff  --git a/clang/lib/Driver/ToolChains/Cuda.h 
b/clang/lib/Driver/ToolChains/Cuda.h
index f2517a9b38d1e..809a25227ac49 100644
--- a/clang/lib/Driver/ToolChains/Cuda.h
+++ b/clang/lib/Driver/ToolChains/Cuda.h
@@ -126,8 +126,7 @@ class LLVM_LIBRARY_VISIBILITY OpenMPLinker : public Tool {
 
 void getNVPTXTargetFeatures(const Driver &D, const llvm::Triple &Triple,
 const llvm::opt::ArgList &Args,
-std::vector &Features,
-Optional Version = None);
+std::vector &Features);
 
 } // end namespace NVPTX
 } // end namespace tools



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

[PATCH] D128752: [CUDA] Stop adding CUDA features twice

[Joseph Huber via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG56ab966a04dd: [CUDA] Stop adding CUDA features twice 
(authored by jhuber6).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128752

Files:
  clang/lib/Driver/ToolChains/Cuda.cpp
  clang/lib/Driver/ToolChains/Cuda.h


Index: clang/lib/Driver/ToolChains/Cuda.h
===
--- clang/lib/Driver/ToolChains/Cuda.h
+++ clang/lib/Driver/ToolChains/Cuda.h
@@ -126,8 +126,7 @@
 
 void getNVPTXTargetFeatures(const Driver &D, const llvm::Triple &Triple,
 const llvm::opt::ArgList &Args,
-std::vector &Features,
-Optional Version = None);
+std::vector &Features);
 
 } // end namespace NVPTX
 } // end namespace tools
Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -636,23 +636,20 @@
 
 void NVPTX::getNVPTXTargetFeatures(const Driver &D, const llvm::Triple &Triple,
const llvm::opt::ArgList &Args,
-   std::vector &Features,
-   Optional Version) {
+   std::vector &Features) {
   if (Args.hasArg(options::OPT_cuda_feature_EQ)) {
 StringRef PtxFeature =
 Args.getLastArgValue(options::OPT_cuda_feature_EQ, "+ptx42");
 Features.push_back(Args.MakeArgString(PtxFeature));
 return;
-  } else if (!Version) {
-CudaInstallationDetector CudaInstallation(D, Triple, Args);
-Version = CudaInstallation.version();
   }
+  CudaInstallationDetector CudaInstallation(D, Triple, Args);
 
   // New CUDA versions often introduce new instructions that are only supported
   // by new PTX version, so we need to raise PTX level to enable them in NVPTX
   // back-end.
   const char *PtxFeature = nullptr;
-  switch (*Version) {
+  switch (CudaInstallation.version()) {
 #define CASE_CUDA_VERSION(CUDA_VER, PTX_VER)   
\
   case CudaVersion::CUDA_##CUDA_VER:   
\
 PtxFeature = "+ptx" #PTX_VER;  
\
@@ -746,11 +743,6 @@
 
   clang::CudaVersion CudaInstallationVersion = CudaInstallation.version();
 
-  std::vector Features;
-  NVPTX::getNVPTXTargetFeatures(getDriver(), getTriple(), DriverArgs, Features,
-CudaInstallationVersion);
-  for (StringRef PtxFeature : Features)
-CC1Args.append({"-target-feature", DriverArgs.MakeArgString(PtxFeature)});
   if (DriverArgs.hasFlag(options::OPT_fcuda_short_ptr,
  options::OPT_fno_cuda_short_ptr, false))
 CC1Args.append({"-mllvm", "--nvptx-short-ptr"});


Index: clang/lib/Driver/ToolChains/Cuda.h
===
--- clang/lib/Driver/ToolChains/Cuda.h
+++ clang/lib/Driver/ToolChains/Cuda.h
@@ -126,8 +126,7 @@
 
 void getNVPTXTargetFeatures(const Driver &D, const llvm::Triple &Triple,
 const llvm::opt::ArgList &Args,
-std::vector &Features,
-Optional Version = None);
+std::vector &Features);
 
 } // end namespace NVPTX
 } // end namespace tools
Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -636,23 +636,20 @@
 
 void NVPTX::getNVPTXTargetFeatures(const Driver &D, const llvm::Triple &Triple,
const llvm::opt::ArgList &Args,
-   std::vector &Features,
-   Optional Version) {
+   std::vector &Features) {
   if (Args.hasArg(options::OPT_cuda_feature_EQ)) {
 StringRef PtxFeature =
 Args.getLastArgValue(options::OPT_cuda_feature_EQ, "+ptx42");
 Features.push_back(Args.MakeArgString(PtxFeature));
 return;
-  } else if (!Version) {
-CudaInstallationDetector CudaInstallation(D, Triple, Args);
-Version = CudaInstallation.version();
   }
+  CudaInstallationDetector CudaInstallation(D, Triple, Args);
 
   // New CUDA versions often introduce new instructions that are only supported
   // by new PTX version, so we need to raise PTX level to enable them in NVPTX
   // back-end.
   const char *PtxFeature = nullptr;
-  switch (*Version) {
+  switch (CudaInstallation.version()) {
 #define CASE_CUDA_VERSION(CUDA_VER, PTX_VER)   \
   case CudaVersion::CUDA_##CUDA_VER:   \
 PtxFeatur

[PATCH] D128795: [pseudo] Reimplement hardcoded error handling as a recovery strategy. NFC

[Haojian Wu via Phabricator via cfe-commits]

hokein accepted this revision.
hokein added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/pseudo/include/clang-pseudo/grammar/Grammar.h:89
 // FIXME: these should be provided as extensions instead.
-enum class RecoveryStrategy : uint8_t { None, Braces };
+enum class RecoveryStrategy : uint8_t { None, Braces, Eof };
 

I think there should be some documentation for the strategies here. (do you 
plan to add them when the above FIXME is fixed?)



Comment at: clang-tools-extra/pseudo/lib/grammar/GrammarBNF.cpp:122
+  // This ensures the overall parse never fails.
+  if (T->Nonterminals[Rule.Target].Name == "_") {
+Rule.Recovery = RecoveryStrategy::Eof;

nit: use the `StartSymbol` global variable (we might want to rename it to 
`Underscore`).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128795

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

[PATCH] D128103: Adds AST Matcher for ObjCStringLiteral

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

The only things left to do are: regenerate the documentation by running 
clang/docs/tools/dump_ast_matchers.py and add a release note for the new 
matcher, but otherwise this looks good to me.

In D128103#3617156 , @NoQ wrote:

> Yes the use case is coming up in D126097 ; 
> it's not used yet because `hasDescendant(StringLiteral)` is used to skip it 
> but this matchert would be a more precise solution (yes there's an actual 
> `StringLiteral` inside `ObjCStringLiteral`).

Ah, great to hear this will be used quickly in tree too!


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

https://reviews.llvm.org/D128103

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

[clang] f382545 - [clang-cl] Handle some pragma alloc_text corner cases handled by MSVC

[Stephen Long via cfe-commits]

Author: Stephen Long
Date: 2022-06-29T06:45:59-07:00
New Revision: f382545b2ba8a39435f7efa02dadc722c429d2cd

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

LOG: [clang-cl] Handle some pragma alloc_text corner cases handled by MSVC

MSVC's pragma alloc_text accepts a function that was redeclared in
a non extern-C context if the previous declaration was in an extern-C
context. i.e.

```
extern "C" { static void f(); }
static void f();
```

MSVC's pragma alloc_text also rejects non-functions.

Reviewed By: hans

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

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Sema/SemaAttr.cpp
clang/test/Sema/pragma-ms-alloc-text.c
clang/test/Sema/pragma-ms-alloc-text.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 442088d078d98..dc9ca4bd18e2e 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -992,6 +992,8 @@ def err_pragma_expected_file_scope : Error<
   "'#pragma %0' can only appear at file scope">;
 def err_pragma_alloc_text_c_linkage: Error<
   "'#pragma alloc_text' is applicable only to functions with C linkage">;
+def err_pragma_alloc_text_not_function: Error<
+  "'#pragma alloc_text' is applicable only to functions">;
 
 def warn_pragma_unused_undeclared_var : Warning<
   "undeclared variable %0 used as an argument for '#pragma unused'">,

diff  --git a/clang/lib/Sema/SemaAttr.cpp b/clang/lib/Sema/SemaAttr.cpp
index c7e62e5895533..c997d018a4065 100644
--- a/clang/lib/Sema/SemaAttr.cpp
+++ b/clang/lib/Sema/SemaAttr.cpp
@@ -810,8 +810,13 @@ void Sema::ActOnPragmaMSAllocText(
   return;
 }
 
-DeclContext *DC = ND->getDeclContext();
-if (getLangOpts().CPlusPlus && !DC->isExternCContext()) {
+auto *FD = dyn_cast(ND->getCanonicalDecl());
+if (!FD) {
+  Diag(Loc, diag::err_pragma_alloc_text_not_function);
+  return;
+}
+
+if (getLangOpts().CPlusPlus && !FD->isInExternCContext()) {
   Diag(Loc, diag::err_pragma_alloc_text_c_linkage);
   return;
 }

diff  --git a/clang/test/Sema/pragma-ms-alloc-text.c 
b/clang/test/Sema/pragma-ms-alloc-text.c
index a5f2e9f11dce2..ff49fa475cd96 100644
--- a/clang/test/Sema/pragma-ms-alloc-text.c
+++ b/clang/test/Sema/pragma-ms-alloc-text.c
@@ -1,9 +1,12 @@
 // RUN: %clang_cc1 -fms-extensions -fsyntax-only -verify %s
 
 void foo();
-#pragma alloc_text("hello", foo) // expected-no-diagnostics
+#pragma alloc_text("hello", foo) // no-error
 void foo() {}
 
 static void foo1();
-#pragma alloc_text("hello", foo1) // expected-no-diagnostics
+#pragma alloc_text("hello", foo1) // no-error
 void foo1() {}
+
+int foo2;
+#pragma alloc_text(c, foo2) // expected-error {{'#pragma alloc_text' is 
applicable only to functions}}

diff  --git a/clang/test/Sema/pragma-ms-alloc-text.cpp 
b/clang/test/Sema/pragma-ms-alloc-text.cpp
index 931b152fe78cc..a150cb2d815af 100644
--- a/clang/test/Sema/pragma-ms-alloc-text.cpp
+++ b/clang/test/Sema/pragma-ms-alloc-text.cpp
@@ -40,3 +40,20 @@ static void foo6();
 #pragma alloc_text(c, foo6) // no-warning
 void foo6() {}
 }
+
+extern "C" {
+static void foo7();
+}
+static void foo7();
+#pragma alloc_text(c, foo7) // no-warning
+void foo7() {}
+
+static void foo8();
+extern "C" {
+static void foo8();
+}
+#pragma alloc_text(c, foo8) // expected-error {{'#pragma alloc_text' is 
applicable only to functions with C linkage}}
+void foo8() {}
+
+enum foo9 { A, B, C };
+#pragma alloc_text(c, foo9) // expected-error {{'#pragma alloc_text' is 
applicable only to functions}}



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

[PATCH] D128649: [clang-cl] Handle some pragma alloc_text corner cases handled by MSVC

[Stephen Long 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 rGf382545b2ba8: [clang-cl] Handle some pragma alloc_text 
corner cases handled by MSVC (authored by steplong).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128649

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaAttr.cpp
  clang/test/Sema/pragma-ms-alloc-text.c
  clang/test/Sema/pragma-ms-alloc-text.cpp


Index: clang/test/Sema/pragma-ms-alloc-text.cpp
===
--- clang/test/Sema/pragma-ms-alloc-text.cpp
+++ clang/test/Sema/pragma-ms-alloc-text.cpp
@@ -40,3 +40,20 @@
 #pragma alloc_text(c, foo6) // no-warning
 void foo6() {}
 }
+
+extern "C" {
+static void foo7();
+}
+static void foo7();
+#pragma alloc_text(c, foo7) // no-warning
+void foo7() {}
+
+static void foo8();
+extern "C" {
+static void foo8();
+}
+#pragma alloc_text(c, foo8) // expected-error {{'#pragma alloc_text' is 
applicable only to functions with C linkage}}
+void foo8() {}
+
+enum foo9 { A, B, C };
+#pragma alloc_text(c, foo9) // expected-error {{'#pragma alloc_text' is 
applicable only to functions}}
Index: clang/test/Sema/pragma-ms-alloc-text.c
===
--- clang/test/Sema/pragma-ms-alloc-text.c
+++ clang/test/Sema/pragma-ms-alloc-text.c
@@ -1,9 +1,12 @@
 // RUN: %clang_cc1 -fms-extensions -fsyntax-only -verify %s
 
 void foo();
-#pragma alloc_text("hello", foo) // expected-no-diagnostics
+#pragma alloc_text("hello", foo) // no-error
 void foo() {}
 
 static void foo1();
-#pragma alloc_text("hello", foo1) // expected-no-diagnostics
+#pragma alloc_text("hello", foo1) // no-error
 void foo1() {}
+
+int foo2;
+#pragma alloc_text(c, foo2) // expected-error {{'#pragma alloc_text' is 
applicable only to functions}}
Index: clang/lib/Sema/SemaAttr.cpp
===
--- clang/lib/Sema/SemaAttr.cpp
+++ clang/lib/Sema/SemaAttr.cpp
@@ -810,8 +810,13 @@
   return;
 }
 
-DeclContext *DC = ND->getDeclContext();
-if (getLangOpts().CPlusPlus && !DC->isExternCContext()) {
+auto *FD = dyn_cast(ND->getCanonicalDecl());
+if (!FD) {
+  Diag(Loc, diag::err_pragma_alloc_text_not_function);
+  return;
+}
+
+if (getLangOpts().CPlusPlus && !FD->isInExternCContext()) {
   Diag(Loc, diag::err_pragma_alloc_text_c_linkage);
   return;
 }
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -992,6 +992,8 @@
   "'#pragma %0' can only appear at file scope">;
 def err_pragma_alloc_text_c_linkage: Error<
   "'#pragma alloc_text' is applicable only to functions with C linkage">;
+def err_pragma_alloc_text_not_function: Error<
+  "'#pragma alloc_text' is applicable only to functions">;
 
 def warn_pragma_unused_undeclared_var : Warning<
   "undeclared variable %0 used as an argument for '#pragma unused'">,


Index: clang/test/Sema/pragma-ms-alloc-text.cpp
===
--- clang/test/Sema/pragma-ms-alloc-text.cpp
+++ clang/test/Sema/pragma-ms-alloc-text.cpp
@@ -40,3 +40,20 @@
 #pragma alloc_text(c, foo6) // no-warning
 void foo6() {}
 }
+
+extern "C" {
+static void foo7();
+}
+static void foo7();
+#pragma alloc_text(c, foo7) // no-warning
+void foo7() {}
+
+static void foo8();
+extern "C" {
+static void foo8();
+}
+#pragma alloc_text(c, foo8) // expected-error {{'#pragma alloc_text' is applicable only to functions with C linkage}}
+void foo8() {}
+
+enum foo9 { A, B, C };
+#pragma alloc_text(c, foo9) // expected-error {{'#pragma alloc_text' is applicable only to functions}}
Index: clang/test/Sema/pragma-ms-alloc-text.c
===
--- clang/test/Sema/pragma-ms-alloc-text.c
+++ clang/test/Sema/pragma-ms-alloc-text.c
@@ -1,9 +1,12 @@
 // RUN: %clang_cc1 -fms-extensions -fsyntax-only -verify %s
 
 void foo();
-#pragma alloc_text("hello", foo) // expected-no-diagnostics
+#pragma alloc_text("hello", foo) // no-error
 void foo() {}
 
 static void foo1();
-#pragma alloc_text("hello", foo1) // expected-no-diagnostics
+#pragma alloc_text("hello", foo1) // no-error
 void foo1() {}
+
+int foo2;
+#pragma alloc_text(c, foo2) // expected-error {{'#pragma alloc_text' is applicable only to functions}}
Index: clang/lib/Sema/SemaAttr.cpp
===
--- clang/lib/Sema/SemaAttr.cpp
+++ clang/lib/Sema/SemaAttr.cpp
@@ -810,8 +810,13 @@
   return;
 }
 
-DeclContext *DC = ND->getDeclContext();
-if (getLangOpts().CPlusPlus && !DC->isExternCContext()) {
+auto 

[PATCH] D128726: [RISCV][NFC] Move static global variables into static variable in function.

[Kito Cheng via Phabricator via cfe-commits]

kito-cheng added a comment.

My understanding is the reason why no global variable is because 1. the 
initialization order and 2. might increase the launch time of programs, moving 
that into function scope could resolve both issue: 1. initialized in 
deterministic order[1], 2. Initialized that when the first time used.

[1] 
https://stackoverflow.com/questions/49856152/static-function-variable-initialization-order-in-the-same-function
[2] 
https://en.cppreference.com/w/cpp/language/storage_duration#Static_local_variables

- stackoverflow and cppreference might not formal source, but should be enough 
here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128726

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

[PATCH] D123952: [FPEnv] Allow CompoundStmt to keep FP options

[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 modulo the rename request.




Comment at: clang/lib/AST/Stmt.cpp:370-371
   setStmts(Stmts);
+  if (hasStoredFPFeatures())
+setStoredFPFeatures(FPFeatures);
 }

rjmccall wrote:
> aaron.ballman wrote:
> > There's a part of me that wonders if it's a slightly more clear design to 
> > have `setStoredFPFeatures()` set `CompoundStmtBits.HasFPFeatures` to true 
> > as needed rather than requiring the caller to do this two-step 
> > initialization process. WDYT?
> `setStoredFPFeatures` is only otherwise used in deserialization, and the node 
> has to be allocated properly to support it.  I think this is the right 
> approach.
My concern was more with new calls added later -- it seems reasonable that 
someone would think they could call `setStoredFPFeatures()` and have them 
stored rather than asserting the object already claims to have stored features.

That said, I don't feel strongly, so we can always adjust it in the future as 
new callers are added.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123952

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

[PATCH] D128726: [RISCV][NFC] Move static global variables into static variable in function.

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added a comment.

Seems you're right, the C++11 standard does clearly say (9.7p4):

> Dynamic initialization of a block-scope variable with static storage duration 
> (6.6.4.1) or thread storage duration (6.6.4.2) is performed the first time 
> control passes through its declaration; such a variable is considered 
> initialized upon the completion of its initialization. If the initialization 
> exits by throwing an exception, the initialization is not complete, so it 
> will be tried again the next time control enters the declaration. If control 
> enters the declaration concurrently while the variable is being initialized, 
> the concurrent execution shall wait for completion of the initialization. If 
> control re-enters the declaration recursively while the variable is being 
> initialized, the behavior is undefined.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128726

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

[PATCH] D128762: [Clang] Rename StringLiteral::isAscii() => isOrdinary() [NFC]

[Corentin Jabot via Phabricator via cfe-commits]

cor3ntin updated this revision to Diff 440994.
cor3ntin added a comment.
Herald added subscribers: carlosgalvezp, usaxena95, kadircet, arphaman.
Herald added a project: clang-tools-extra.

- fix clang-tidy build
- apply the same change in StringLiteralParser/CharLiteralParser


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128762

Files:
  clang-tools-extra/clang-tidy/modernize/RawStringLiteralCheck.cpp
  clang-tools-extra/clangd/refactor/tweaks/RawStringLiteral.cpp
  clang/include/clang/AST/Expr.h
  clang/include/clang/Lex/LiteralSupport.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/OSLog.cpp
  clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp
  clang/lib/Frontend/Rewrite/RewriteObjC.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/Parser.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaExprObjC.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaStmtAsm.cpp

Index: clang/lib/Sema/SemaStmtAsm.cpp
===
--- clang/lib/Sema/SemaStmtAsm.cpp
+++ clang/lib/Sema/SemaStmtAsm.cpp
@@ -254,7 +254,7 @@
   SmallVector OutputConstraintInfos;
 
   // The parser verifies that there is a string literal here.
-  assert(AsmString->isAscii());
+  assert(AsmString->isOrdinary());
 
   FunctionDecl *FD = dyn_cast(getCurLexicalContext());
   llvm::StringMap FeatureMap;
@@ -262,7 +262,7 @@
 
   for (unsigned i = 0; i != NumOutputs; i++) {
 StringLiteral *Literal = Constraints[i];
-assert(Literal->isAscii());
+assert(Literal->isOrdinary());
 
 StringRef OutputName;
 if (Names[i])
@@ -353,7 +353,7 @@
 
   for (unsigned i = NumOutputs, e = NumOutputs + NumInputs; i != e; i++) {
 StringLiteral *Literal = Constraints[i];
-assert(Literal->isAscii());
+assert(Literal->isOrdinary());
 
 StringRef InputName;
 if (Names[i])
@@ -459,7 +459,7 @@
   // Check that the clobbers are valid.
   for (unsigned i = 0; i != NumClobbers; i++) {
 StringLiteral *Literal = Clobbers[i];
-assert(Literal->isAscii());
+assert(Literal->isOrdinary());
 
 StringRef Clobber = Literal->getString();
 
Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -87,7 +87,7 @@
 if (ElemTy->isChar8Type())
   return SIF_None;
 LLVM_FALLTHROUGH;
-  case StringLiteral::Ascii:
+  case StringLiteral::Ordinary:
 // char array can be initialized with a narrow string.
 // Only allow char x[] = "foo";  not char x[] = L"foo";
 if (ElemTy->isCharType())
Index: clang/lib/Sema/SemaExprObjC.cpp
===
--- clang/lib/Sema/SemaExprObjC.cpp
+++ clang/lib/Sema/SemaExprObjC.cpp
@@ -50,7 +50,7 @@
   S = cast(E);
 
   // ObjC strings can't be wide or UTF.
-  if (!S->isAscii()) {
+  if (!S->isOrdinary()) {
 Diag(S->getBeginLoc(), diag::err_cfstring_literal_not_string_constant)
 << S->getSourceRange();
 return true;
@@ -70,7 +70,7 @@
 QualType StrTy = Context.getConstantArrayType(
 CAT->getElementType(), llvm::APInt(32, StrBuf.size() + 1), nullptr,
 CAT->getSizeModifier(), CAT->getIndexTypeCVRQualifiers());
-S = StringLiteral::Create(Context, StrBuf, StringLiteral::Ascii,
+S = StringLiteral::Create(Context, StrBuf, StringLiteral::Ordinary,
   /*Pascal=*/false, StrTy, &StrLocs[0],
   StrLocs.size());
   }
@@ -448,7 +448,7 @@
 }
 // If this is potentially an Objective-C string literal, add the '@'.
 else if (StringLiteral *String = dyn_cast(OrigElement)) {
-  if (String->isAscii()) {
+  if (String->isOrdinary()) {
 S.Diag(OrigElement->getBeginLoc(), diag::err_box_literal_collection)
 << 0 << OrigElement->getSourceRange()
 << FixItHint::CreateInsertion(OrigElement->getBeginLoc(), "@");
@@ -533,7 +533,7 @@
 if (CE->getCastKind() == CK_ArrayToPointerDecay)
   if (auto *SL =
   dyn_cast(CE->getSubExpr()->IgnoreParens())) {
-assert((SL->isAscii() || SL->isUTF8()) &&
+assert((SL->isOrdinary() || SL->isUTF8()) &&
"unexpected character encoding");
 StringRef Str = SL->getString();
 const llvm::UTF8 *StrBegin = Str.bytes_begin();
Index: clang/lib/Sema/SemaExprCXX.cpp
===
--- clang/lib/Sema/SemaExprCXX.cpp
+++ clang/lib/Sema/SemaExprCXX.cpp
@@ -4009,7 +4009,7 @@

[PATCH] D128499: [Clang] Fix: Restore warning inadvertently removed by D126061.

[Mikhail Maltsev via Phabricator via cfe-commits]

miyuki added a comment.

Thanks for fixing the issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128499

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

[PATCH] D128762: [Clang] Rename StringLiteral::isAscii() => isOrdinary() [NFC]

[Corentin Jabot via Phabricator via cfe-commits]

cor3ntin added inline comments.



Comment at: clang/include/clang/AST/Expr.h:1789-1886
+  enum StringKind { Ordinary, Wide, UTF8, UTF16, UTF32 };
 
 private:
   unsigned numTrailingObjects(OverloadToken) const { return 1; }
   unsigned numTrailingObjects(OverloadToken) const {
 return getNumConcatenated();
   }

aaron.ballman wrote:
> I like the idea of renaming both of these -- `isASCII()` can be a bit 
> confusing with `containsNonAscii()` as well. However, instead of "ordinary", 
> would it make more sense to go with "narrow" as the term of art? That also 
> goes nicely with the use of "wide" in this interface.
narrow encompass ordinary and `u8` literals in standard terminology.
And, I think `narrow` is too easilly mistaken as a synonym for `getByteLength() 
== 1`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128762

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

[PATCH] D128821: [clangd][ObjC] Fix ObjC method definition completion

[David Goldman via Phabricator via cfe-commits]

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

D124637  improved filtering of method 
expressions, but not method
definitions. With this change, clangd will now filter ObjC method
definition completions based on their entire selector instead of
only the first selector fragment.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128821

Files:
  clang-tools-extra/clangd/CodeComplete.cpp
  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
@@ -3131,6 +3131,26 @@
   EXPECT_THAT(C, ElementsAre(signature("(char)c secondArgument:(id)object")));
 }
 
+TEST(CompletionTest, ObjectiveCMethodDeclarationFilterOnEntireSelector) {
+  auto Results = completions(R"objc(
+  @interface Foo
+  - (int)valueForCharacter:(char)c secondArgument:(id)object;
+  @end
+  @implementation Foo
+  secondArg^
+  @end
+)objc",
+ /*IndexSymbols=*/{},
+ /*Opts=*/{}, "Foo.m");
+
+  auto C = Results.Completions;
+  EXPECT_THAT(C, ElementsAre(named("valueForCharacter:")));
+  EXPECT_THAT(C, ElementsAre(filterText("valueForCharacter:secondArgument:")));
+  EXPECT_THAT(C, ElementsAre(kind(CompletionItemKind::Method)));
+  EXPECT_THAT(C, ElementsAre(qualifier("- (int)")));
+  EXPECT_THAT(C, ElementsAre(signature("(char)c secondArgument:(id)object")));
+}
+
 TEST(CompletionTest, ObjectiveCMethodDeclarationPrefixTyped) {
   auto Results = completions(R"objc(
   @interface Foo
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -851,19 +851,21 @@
   // Returns the filtering/sorting name for Result, which must be from Results.
   // Returned string is owned by this recorder (or the AST).
   llvm::StringRef getName(const CodeCompletionResult &Result) {
+CodeCompletionString *CCS = nullptr;
 switch (Result.Kind) {
 case CodeCompletionResult::RK_Declaration:
   if (auto *ID = Result.Declaration->getIdentifier())
 return ID->getName();
+  CCS = codeCompletionString(Result);
   break;
 case CodeCompletionResult::RK_Keyword:
   return Result.Keyword;
 case CodeCompletionResult::RK_Macro:
   return Result.Macro->getName();
 case CodeCompletionResult::RK_Pattern:
-  return Result.Pattern->getTypedText();
+  CCS = Result.Pattern;
+  break;
 }
-auto *CCS = codeCompletionString(Result);
 const CodeCompletionString::Chunk *OnlyText = nullptr;
 for (auto &C : *CCS) {
   if (C.Kind != CodeCompletionString::CK_TypedText)


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -3131,6 +3131,26 @@
   EXPECT_THAT(C, ElementsAre(signature("(char)c secondArgument:(id)object")));
 }
 
+TEST(CompletionTest, ObjectiveCMethodDeclarationFilterOnEntireSelector) {
+  auto Results = completions(R"objc(
+  @interface Foo
+  - (int)valueForCharacter:(char)c secondArgument:(id)object;
+  @end
+  @implementation Foo
+  secondArg^
+  @end
+)objc",
+ /*IndexSymbols=*/{},
+ /*Opts=*/{}, "Foo.m");
+
+  auto C = Results.Completions;
+  EXPECT_THAT(C, ElementsAre(named("valueForCharacter:")));
+  EXPECT_THAT(C, ElementsAre(filterText("valueForCharacter:secondArgument:")));
+  EXPECT_THAT(C, ElementsAre(kind(CompletionItemKind::Method)));
+  EXPECT_THAT(C, ElementsAre(qualifier("- (int)")));
+  EXPECT_THAT(C, ElementsAre(signature("(char)c secondArgument:(id)object")));
+}
+
 TEST(CompletionTest, ObjectiveCMethodDeclarationPrefixTyped) {
   auto Results = completions(R"objc(
   @interface Foo
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -851,19 +851,21 @@
   // Returns the filtering/sorting name for Result, which must be from Results.
   // Returned string is owned by this recorder (or the AST).
   llvm::StringRef getName(const CodeCompletionResult &Result) {
+CodeCompletionString *CCS = nullptr;
 switch (Result.Kind) {
 case CodeCompletionR

[PATCH] D128747: ISSUE - incorrect -Winfinite-recursion warning on potentially-unevaluated operand #21668

[Prathit Aswar via Phabricator via cfe-commits]

appmonster007 updated this revision to Diff 440992.
appmonster007 added a comment.

inserted bullet point for `-Winfinite-recursion` diagnostics fix, where 
diagnostic will not warn for unevaluated operands of ``typeid`` expression, 
under "Improvements to Clang’s diagnostics" in clang/docs/ReleaseNotes.rst

fixed issue with typeinfo header, just included it directly in 
`warn-infinite-recursion.cpp` file

fixed recommended minor changes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128747

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Analysis/CFG.cpp
  clang/test/SemaCXX/warn-infinite-recursion.cpp

Index: clang/test/SemaCXX/warn-infinite-recursion.cpp
===
--- clang/test/SemaCXX/warn-infinite-recursion.cpp
+++ clang/test/SemaCXX/warn-infinite-recursion.cpp
@@ -171,3 +171,35 @@
 }
 
 int wrapper_sum = test_wrapper<2>();  // expected-note{{instantiation}}
+
+namespace std {
+class type_info {
+public:
+  virtual ~type_info();
+  const char *name() const { return __name; }
+  bool operator==(const type_info &__arg) const {
+return __name == __arg.__name;
+  }
+
+  bool operator!=(const type_info &__arg) const {
+return !operator==(__arg);
+  }
+
+protected:
+  const char *__name;
+};
+} // namespace std
+struct Q {
+  virtual ~Q(){};
+};
+
+Q q;
+Q &evaluated_recursive_function(int x) { // expected-warning{{call itself}}
+  (void)typeid(evaluated_recursive_function(x)); // expected-warning {{expression with side effects will be evaluated despite being used as an operand to 'typeid'}}
+  return q;
+}
+
+int unevaluated_recursive_function() {
+  (void)typeid(unevaluated_recursive_function());
+  return 0;
+}
Index: clang/lib/Analysis/CFG.cpp
===
--- clang/lib/Analysis/CFG.cpp
+++ clang/lib/Analysis/CFG.cpp
@@ -564,6 +564,7 @@
 AddStmtChoice asc);
   CFGBlock *VisitCXXThrowExpr(CXXThrowExpr *T);
   CFGBlock *VisitCXXTryStmt(CXXTryStmt *S);
+  CFGBlock *VisitCXXTypeidExpr(CXXTypeidExpr *S, AddStmtChoice asc);
   CFGBlock *VisitDeclStmt(DeclStmt *DS);
   CFGBlock *VisitDeclSubExpr(DeclStmt *DS);
   CFGBlock *VisitDefaultStmt(DefaultStmt *D);
@@ -2220,6 +2221,9 @@
 case Stmt::CXXTryStmtClass:
   return VisitCXXTryStmt(cast(S));
 
+case Stmt::CXXTypeidExprClass:
+  return VisitCXXTypeidExpr(cast(S), asc);
+
 case Stmt::CXXForRangeStmtClass:
   return VisitCXXForRangeStmt(cast(S));
 
@@ -4045,6 +4049,25 @@
   return VisitStmt(T, AddStmtChoice::AlwaysAdd);
 }
 
+CFGBlock *CFGBuilder::VisitCXXTypeidExpr(CXXTypeidExpr *S, AddStmtChoice asc) {
+  if (asc.alwaysAdd(*this, S)) {
+autoCreateBlock();
+appendStmt(Block, S);
+  }
+
+  // C++ [expr.typeid]p3:
+  //   When typeid is applied to an expression other than an glvalue of a
+  //   polymorphic class type [...] [the] expression is an unevaluated
+  //   operand. [...]
+  // We add only potentially evaluated statements to the block to avoid
+  // CFG generation for unevaluated operands.
+  if (S && !S->isTypeDependent() && S->isPotentiallyEvaluated())
+return VisitChildren(S);
+
+  // Return block without CFG for unevaluated operands.
+  return Block;
+}
+
 CFGBlock *CFGBuilder::VisitDoStmt(DoStmt *D) {
   CFGBlock *LoopSuccessor = nullptr;
 
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -267,6 +267,10 @@
 - When using class templates without arguments, clang now tells developers
   that template arguments are missing in certain contexts.
   This fixes `Issue 55962 `_.
+- The ``-Winfinite-recursion`` diagnostic will not warn for 
+  unevaluated operands of ``typeid`` expression. Unevaluated 
+  operands of ``typeid`` expression are skipped for the CFG build. 
+  This fixes `Issue 21668 `_.
 
 Non-comprehensive list of changes in this release
 -
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D128747: ISSUE - incorrect -Winfinite-recursion warning on potentially-unevaluated operand #21668

[Prathit Aswar via Phabricator via cfe-commits]

appmonster007 updated this revision to Diff 440997.
appmonster007 marked an inline comment as done.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128747

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Analysis/CFG.cpp
  clang/test/SemaCXX/warn-infinite-recursion.cpp

Index: clang/test/SemaCXX/warn-infinite-recursion.cpp
===
--- clang/test/SemaCXX/warn-infinite-recursion.cpp
+++ clang/test/SemaCXX/warn-infinite-recursion.cpp
@@ -171,3 +171,35 @@
 }
 
 int wrapper_sum = test_wrapper<2>();  // expected-note{{instantiation}}
+
+namespace std {
+class type_info {
+public:
+  virtual ~type_info();
+  const char *name() const { return __name; }
+  bool operator==(const type_info &__arg) const {
+return __name == __arg.__name;
+  }
+
+  bool operator!=(const type_info &__arg) const {
+return !operator==(__arg);
+  }
+
+protected:
+  const char *__name;
+};
+} // namespace std
+struct Q {
+  virtual ~Q() = default;
+};
+
+Q q;
+Q &evaluated_recursive_function(int x) { // expected-warning{{call itself}}
+  (void)typeid(evaluated_recursive_function(x)); // expected-warning {{expression with side effects will be evaluated despite being used as an operand to 'typeid'}}
+  return q;
+}
+
+int unevaluated_recursive_function() {
+  (void)typeid(unevaluated_recursive_function());
+  return 0;
+}
Index: clang/lib/Analysis/CFG.cpp
===
--- clang/lib/Analysis/CFG.cpp
+++ clang/lib/Analysis/CFG.cpp
@@ -564,6 +564,7 @@
 AddStmtChoice asc);
   CFGBlock *VisitCXXThrowExpr(CXXThrowExpr *T);
   CFGBlock *VisitCXXTryStmt(CXXTryStmt *S);
+  CFGBlock *VisitCXXTypeidExpr(CXXTypeidExpr *S, AddStmtChoice asc);
   CFGBlock *VisitDeclStmt(DeclStmt *DS);
   CFGBlock *VisitDeclSubExpr(DeclStmt *DS);
   CFGBlock *VisitDefaultStmt(DefaultStmt *D);
@@ -2220,6 +2221,9 @@
 case Stmt::CXXTryStmtClass:
   return VisitCXXTryStmt(cast(S));
 
+case Stmt::CXXTypeidExprClass:
+  return VisitCXXTypeidExpr(cast(S), asc);
+
 case Stmt::CXXForRangeStmtClass:
   return VisitCXXForRangeStmt(cast(S));
 
@@ -4045,6 +4049,25 @@
   return VisitStmt(T, AddStmtChoice::AlwaysAdd);
 }
 
+CFGBlock *CFGBuilder::VisitCXXTypeidExpr(CXXTypeidExpr *S, AddStmtChoice asc) {
+  if (asc.alwaysAdd(*this, S)) {
+autoCreateBlock();
+appendStmt(Block, S);
+  }
+
+  // C++ [expr.typeid]p3:
+  //   When typeid is applied to an expression other than an glvalue of a
+  //   polymorphic class type [...] [the] expression is an unevaluated
+  //   operand. [...]
+  // We add only potentially evaluated statements to the block to avoid
+  // CFG generation for unevaluated operands.
+  if (S && !S->isTypeDependent() && S->isPotentiallyEvaluated())
+return VisitChildren(S);
+
+  // Return block without CFG for unevaluated operands.
+  return Block;
+}
+
 CFGBlock *CFGBuilder::VisitDoStmt(DoStmt *D) {
   CFGBlock *LoopSuccessor = nullptr;
 
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -267,6 +267,10 @@
 - When using class templates without arguments, clang now tells developers
   that template arguments are missing in certain contexts.
   This fixes `Issue 55962 `_.
+- The ``-Winfinite-recursion`` diagnostic will not warn for 
+  unevaluated operands of ``typeid`` expression. Unevaluated 
+  operands of ``typeid`` expression are skipped for the CFG build. 
+  This fixes `Issue 21668 `_.
 
 Non-comprehensive list of changes in this release
 -
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D128747: ISSUE - incorrect -Winfinite-recursion warning on potentially-unevaluated operand #21668

[Prathit Aswar via Phabricator via cfe-commits]

appmonster007 updated this revision to Diff 440999.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128747

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Analysis/CFG.cpp
  clang/test/SemaCXX/warn-infinite-recursion.cpp

Index: clang/test/SemaCXX/warn-infinite-recursion.cpp
===
--- clang/test/SemaCXX/warn-infinite-recursion.cpp
+++ clang/test/SemaCXX/warn-infinite-recursion.cpp
@@ -171,3 +171,35 @@
 }
 
 int wrapper_sum = test_wrapper<2>();  // expected-note{{instantiation}}
+
+namespace std {
+class type_info {
+public:
+  virtual ~type_info();
+  const char *name() const { return __name; }
+  bool operator==(const type_info &__arg) const {
+return __name == __arg.__name;
+  }
+
+  bool operator!=(const type_info &__arg) const {
+return !operator==(__arg);
+  }
+
+protected:
+  const char *__name;
+};
+} // namespace std
+struct Q {
+  virtual ~Q() = default;
+};
+
+Q q;
+Q &evaluated_recursive_function(int x) { // expected-warning{{call itself}}
+  (void)typeid(evaluated_recursive_function(x)); // expected-warning {{expression with side effects will be evaluated despite being used as an operand to 'typeid'}}
+  return q;
+}
+
+int unevaluated_recursive_function() {
+  (void)typeid(unevaluated_recursive_function());
+  return 0;
+}
Index: clang/lib/Analysis/CFG.cpp
===
--- clang/lib/Analysis/CFG.cpp
+++ clang/lib/Analysis/CFG.cpp
@@ -564,6 +564,7 @@
 AddStmtChoice asc);
   CFGBlock *VisitCXXThrowExpr(CXXThrowExpr *T);
   CFGBlock *VisitCXXTryStmt(CXXTryStmt *S);
+  CFGBlock *VisitCXXTypeidExpr(CXXTypeidExpr *S, AddStmtChoice asc);
   CFGBlock *VisitDeclStmt(DeclStmt *DS);
   CFGBlock *VisitDeclSubExpr(DeclStmt *DS);
   CFGBlock *VisitDefaultStmt(DefaultStmt *D);
@@ -2220,6 +2221,9 @@
 case Stmt::CXXTryStmtClass:
   return VisitCXXTryStmt(cast(S));
 
+case Stmt::CXXTypeidExprClass:
+  return VisitCXXTypeidExpr(cast(S), asc);
+
 case Stmt::CXXForRangeStmtClass:
   return VisitCXXForRangeStmt(cast(S));
 
@@ -4045,6 +4049,25 @@
   return VisitStmt(T, AddStmtChoice::AlwaysAdd);
 }
 
+CFGBlock *CFGBuilder::VisitCXXTypeidExpr(CXXTypeidExpr *S, AddStmtChoice asc) {
+  if (asc.alwaysAdd(*this, S)) {
+autoCreateBlock();
+appendStmt(Block, S);
+  }
+
+  // C++ [expr.typeid]p3:
+  //   When typeid is applied to an expression other than an glvalue of a
+  //   polymorphic class type [...] [the] expression is an unevaluated
+  //   operand. [...]
+  // We add only potentially evaluated statements to the block to avoid
+  // CFG generation for unevaluated operands.
+  if (S && !S->isTypeDependent() && S->isPotentiallyEvaluated())
+return VisitChildren(S);
+
+  // Return block without CFG for unevaluated operands.
+  return Block;
+}
+
 CFGBlock *CFGBuilder::VisitDoStmt(DoStmt *D) {
   CFGBlock *LoopSuccessor = nullptr;
 
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -267,6 +267,10 @@
 - When using class templates without arguments, clang now tells developers
   that template arguments are missing in certain contexts.
   This fixes `Issue 55962 `_.
+- The ``-Winfinite-recursion`` diagnostic will not warn for
+  unevaluated operands of ``typeid`` expression. Unevaluated
+  operands of ``typeid`` expression are skipped for the CFG build.
+  This fixes `Issue 21668 `_.
 
 Non-comprehensive list of changes in this release
 -
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124690: [clangd] add inlay hints for std::forward-ed parameter packs

[Sam McCall via Phabricator via cfe-commits]

sammccall added inline comments.



Comment at: clang-tools-extra/clangd/InlayHints.cpp:483
+   !Type.getNonReferenceType().isConstQualified() &&
+   !isExpandedParameterPack(Param);
   }

upsj wrote:
> sammccall wrote:
> > upsj wrote:
> > > sammccall wrote:
> > > > sammccall wrote:
> > > > > nridge wrote:
> > > > > > sammccall wrote:
> > > > > > > why is this check needed if we already decline to provide a name 
> > > > > > > for the parameter on line 534 in chooseParameterNames?
> > > > > > `shouldHintName` and `shouldHintReference` are [two independent 
> > > > > > conditions](https://searchfox.org/llvm/rev/508eb41d82ca956c30950d9a16b522a29aeeb333/clang-tools-extra/clangd/InlayHints.cpp#411-418)
> > > > > >  governing whether we show the parameter name and/or a `&` 
> > > > > > indicating pass-by-mutable-ref, respectively
> > > > > > 
> > > > > > (I did approve the [patch](https://reviews.llvm.org/D124359) that 
> > > > > > introduced `shouldHintReference` myself, hope that's ok)
> > > > > Thanks, that makes sense! I just hadn't understood that change.
> > > > What exactly *is* the motivation for suppressing reference hints in the 
> > > > pack case?
> > > > 
> > > > (I can imagine there are cases where they're annoying, but it's hard to 
> > > > know if the condition is right without knowing what those are)
> > > I added an explanation. Basically, if we are unable to figure out which 
> > > parameter the arguments are being forwarded to, the type of the 
> > > ParmVarDecl for `Args&&...` gets deduced as `T&` or `T&&`, so that would 
> > > mean even though we don't know whether the argument will eventually be 
> > > forwarded to a reference parameter, we still claim all mutable lvalue 
> > > arguments will be mutated, which IMO introduces more noise than 
> > > necessary. But I think there are also good arguments for adding them to 
> > > be safe.
> > > 
> > > There is another detail here, which is that we don't record whether we 
> > > used std::forward, so the corresponding rvalue-to-lvalue conversions may 
> > > lead to some unnecessary & annotations for rvalue arguments.
> > This makes sense, the comment explains well, thank you!
> > I have a couple of quibbles, up to you whether to change the logic.
> > 
> > #1: There's an unstated assumption that pack arguments *will* be forwarded 
> > (there are other things we can do with them, like use them in 
> > fold-expressions). It's a pretty good assumption but if the comment talks 
> > about forwarding, it should probably mention explicitly ("it's likely the 
> > params will be somehow forwarded, and...")
> > 
> > #2: the idea is that if the reference-ness is deduced from the callsite, 
> > then it's not meaningful as an "is the param modified" signal, it's just 
> > "is this arg modifiable". Fair enough, but this is a property of 
> > universal/forwarding references (T&& where T is a template param), not of 
> > packs. So I *think* this check should rather be 
> > !isInstantiatedFromForwardingReference(Param).
> > But maybe that's more complexity and what you have is a good heuristic - I 
> > think at least we should call out that it's a heuristic for the true 
> > condition.
> > 
> > 
> #1: I agree, I'll make that more clear before committing.
> 
> #2: Now that I think about it, there are actually two things we don't keep 
> track of: parameters could lose their reference-ness via `Args...` instead of 
> `Args&&...` and their rvalue-ness by not using `std::forward`. We only look 
> at whether the innermost call takes a reference parameter, but as I said, we 
> may lose some of that information on the way, claiming the function may 
> modify the argument when it actually creates a copy on the way (losing 
> reference-ness). I think the case of an rvalue being mistaken for an lvalue 
> should not be much of an issue, since the reference annotation almost makes 
> sense.
> 
> To visualize the situation: These three snippets all add &: hints to the 
> parameter of bar
> ```
> void foo(int&);
> template 
> void bar(Args... args) { return foo(args...); }
> void baz() {
>   bar(1);
> }
> ```
> ```
> void foo(int&);
> template 
> void bar(Args&&... args) { return foo(args...); }
> void baz() {
>   bar(1);
> }
> ```
> ```
> void foo(int&);
> template 
> void bar(Args&&... args) { return foo(std::forward(args)...); }
> void baz() {
>   int a;
>   bar(a);
> }
> ```
> Two of these three cases probably shouldn't have this annotation?
> parameters could lose their reference-ness via Args... instead of Args&&...
(I'm not quite following what you mean here: if we deduce as `Args` rather than 
`Args&&` then the parameters are not references in the first place, we're 
passing by value)

> and their rvalue-ness by not using std::forward
Yes. Fundamentally if we're deducing the ref type then we should be looking for 
a concrete signal of how the value is ultimately used, which involves tracking 
casts like std::forward. This

[PATCH] D128821: [clangd][ObjC] Fix ObjC method definition completion

[Sam McCall via Phabricator via cfe-commits]

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

Ah, this is subtle. Thanks!




Comment at: clang-tools-extra/clangd/CodeComplete.cpp:866
 case CodeCompletionResult::RK_Pattern:
-  return Result.Pattern->getTypedText();
+  CCS = Result.Pattern;
+  break;

weirdly, codeCompletionString(Result) looks like it would mutate Result and 
then return a pattern with the same chunks (but different extra fields). So not 
affect the result of this function, but possibly others as a side-effect.

(e.g. add BriefComment and ParentName in the case that there's a pattern + 
declaration, as there is here)

What you have is fine, but if you feel like digging deeper 
codeCompletionString(Result) may be either better or worse here!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128821

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

[PATCH] D128747: ISSUE - incorrect -Winfinite-recursion warning on potentially-unevaluated operand #21668

[Prathit Aswar via Phabricator via cfe-commits]

appmonster007 updated this revision to Diff 441005.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128747

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Analysis/CFG.cpp
  clang/test/SemaCXX/warn-infinite-recursion.cpp

Index: clang/test/SemaCXX/warn-infinite-recursion.cpp
===
--- clang/test/SemaCXX/warn-infinite-recursion.cpp
+++ clang/test/SemaCXX/warn-infinite-recursion.cpp
@@ -171,3 +171,35 @@
 }
 
 int wrapper_sum = test_wrapper<2>();  // expected-note{{instantiation}}
+
+namespace std {
+class type_info {
+public:
+  virtual ~type_info();
+  const char *name() const { return __name; }
+  bool operator==(const type_info &__arg) const {
+return __name == __arg.__name;
+  }
+
+  bool operator!=(const type_info &__arg) const {
+return !operator==(__arg);
+  }
+
+protected:
+  const char *__name;
+};
+} // namespace std
+struct Q {
+  virtual ~Q() = default;
+};
+
+Q q;
+Q &evaluated_recursive_function(int x) { // expected-warning{{call itself}}
+  (void)typeid(evaluated_recursive_function(x)); // expected-warning {{expression with side effects will be evaluated despite being used as an operand to 'typeid'}}
+  return q;
+}
+
+int unevaluated_recursive_function() {
+  (void)typeid(unevaluated_recursive_function());
+  return 0;
+}
Index: clang/lib/Analysis/CFG.cpp
===
--- clang/lib/Analysis/CFG.cpp
+++ clang/lib/Analysis/CFG.cpp
@@ -564,6 +564,7 @@
 AddStmtChoice asc);
   CFGBlock *VisitCXXThrowExpr(CXXThrowExpr *T);
   CFGBlock *VisitCXXTryStmt(CXXTryStmt *S);
+  CFGBlock *VisitCXXTypeidExpr(CXXTypeidExpr *S, AddStmtChoice asc);
   CFGBlock *VisitDeclStmt(DeclStmt *DS);
   CFGBlock *VisitDeclSubExpr(DeclStmt *DS);
   CFGBlock *VisitDefaultStmt(DefaultStmt *D);
@@ -2220,6 +2221,9 @@
 case Stmt::CXXTryStmtClass:
   return VisitCXXTryStmt(cast(S));
 
+case Stmt::CXXTypeidExprClass:
+  return VisitCXXTypeidExpr(cast(S), asc);
+
 case Stmt::CXXForRangeStmtClass:
   return VisitCXXForRangeStmt(cast(S));
 
@@ -4045,6 +4049,25 @@
   return VisitStmt(T, AddStmtChoice::AlwaysAdd);
 }
 
+CFGBlock *CFGBuilder::VisitCXXTypeidExpr(CXXTypeidExpr *S, AddStmtChoice asc) {
+  if (asc.alwaysAdd(*this, S)) {
+autoCreateBlock();
+appendStmt(Block, S);
+  }
+
+  // C++ [expr.typeid]p3:
+  //   When typeid is applied to an expression other than an glvalue of a
+  //   polymorphic class type [...] [the] expression is an unevaluated
+  //   operand. [...]
+  // We add only potentially evaluated statements to the block to avoid
+  // CFG generation for unevaluated operands.
+  if (S && !S->isTypeDependent() && S->isPotentiallyEvaluated())
+return VisitChildren(S);
+
+  // Return block without CFG for unevaluated operands.
+  return Block;
+}
+
 CFGBlock *CFGBuilder::VisitDoStmt(DoStmt *D) {
   CFGBlock *LoopSuccessor = nullptr;
 
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -267,6 +267,10 @@
 - When using class templates without arguments, clang now tells developers
   that template arguments are missing in certain contexts.
   This fixes `Issue 55962 `_.
+- The ``-Winfinite-recursion`` diagnostic will not warn for
+  unevaluated operands of ``typeid`` expression. Unevaluated
+  operands of ``typeid`` expression are skipped for the CFG build.
+  This fixes `Issue 21668 `_.
 
 Non-comprehensive list of changes in this release
 -
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D128288: [PowerPC] Fix signatures for vec_replace_unaligned builtin

[Lei Huang via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGcaf7243a6b53: [PowerPC] Fix signatures for 
vec_replace_unaligned builtin (authored by lei).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128288

Files:
  clang/lib/Headers/altivec.h
  clang/test/CodeGen/PowerPC/builtins-ppc-p10vector.c
  clang/test/CodeGen/PowerPC/builtins-ppc-vec-ins-error.c

Index: clang/test/CodeGen/PowerPC/builtins-ppc-vec-ins-error.c
===
--- clang/test/CodeGen/PowerPC/builtins-ppc-vec-ins-error.c
+++ clang/test/CodeGen/PowerPC/builtins-ppc-vec-ins-error.c
@@ -49,12 +49,12 @@
 }
 
 #elif defined(__TEST_UNALIGNED_UI)
-vector unsigned int test_vec_replace_unaligned_ui(void) {
+vector unsigned char test_vec_replace_unaligned_ui(void) {
   return vec_replace_unaligned(vuia, uia, 16); // expected-error {{byte number 16 is outside of the valid range [0, 12]}}
 }
 
 #else
-vector unsigned long long test_vec_replace_unaligned_ull(void) {
+vector unsigned char test_vec_replace_unaligned_ull(void) {
   return vec_replace_unaligned(vulla, ulla, 12); // expected-error {{byte number 12 is outside of the valid range [0, 8]}}
 }
 #endif
Index: clang/test/CodeGen/PowerPC/builtins-ppc-p10vector.c
===
--- clang/test/CodeGen/PowerPC/builtins-ppc-p10vector.c
+++ clang/test/CodeGen/PowerPC/builtins-ppc-p10vector.c
@@ -1183,8 +1183,7 @@
 // CHECK-BE-NEXT:[[TMP3:%.*]] = bitcast <16 x i8> [[TMP1]] to <4 x i32>
 // CHECK-BE-NEXT:[[TMP4:%.*]] = call <4 x i32> @llvm.ppc.altivec.vinsw(<4 x i32> [[TMP3]], i32 [[TMP2]], i32 6)
 // CHECK-BE-NEXT:[[TMP5:%.*]] = bitcast <4 x i32> [[TMP4]] to <16 x i8>
-// CHECK-BE-NEXT:[[TMP6:%.*]] = bitcast <16 x i8> [[TMP5]] to <4 x i32>
-// CHECK-BE-NEXT:ret <4 x i32> [[TMP6]]
+// CHECK-BE-NEXT:ret <16 x i8> [[TMP5]]
 //
 // CHECK-LE-LABEL: @test_vec_replace_unaligned_si(
 // CHECK-LE-NEXT:  entry:
@@ -1194,10 +1193,9 @@
 // CHECK-LE-NEXT:[[TMP3:%.*]] = bitcast <16 x i8> [[TMP1]] to <4 x i32>
 // CHECK-LE-NEXT:[[TMP4:%.*]] = call <4 x i32> @llvm.ppc.altivec.vinsw(<4 x i32> [[TMP3]], i32 [[TMP2]], i32 6)
 // CHECK-LE-NEXT:[[TMP5:%.*]] = bitcast <4 x i32> [[TMP4]] to <16 x i8>
-// CHECK-LE-NEXT:[[TMP6:%.*]] = bitcast <16 x i8> [[TMP5]] to <4 x i32>
-// CHECK-LE-NEXT:ret <4 x i32> [[TMP6]]
+// CHECK-LE-NEXT:ret <16 x i8> [[TMP5]]
 //
-vector signed int test_vec_replace_unaligned_si(void) {
+vector unsigned char test_vec_replace_unaligned_si(void) {
   return vec_replace_unaligned(vsia, sia, 6);
 }
 
@@ -1209,8 +1207,7 @@
 // CHECK-BE-NEXT:[[TMP3:%.*]] = bitcast <16 x i8> [[TMP1]] to <4 x i32>
 // CHECK-BE-NEXT:[[TMP4:%.*]] = call <4 x i32> @llvm.ppc.altivec.vinsw(<4 x i32> [[TMP3]], i32 [[TMP2]], i32 8)
 // CHECK-BE-NEXT:[[TMP5:%.*]] = bitcast <4 x i32> [[TMP4]] to <16 x i8>
-// CHECK-BE-NEXT:[[TMP6:%.*]] = bitcast <16 x i8> [[TMP5]] to <4 x i32>
-// CHECK-BE-NEXT:ret <4 x i32> [[TMP6]]
+// CHECK-BE-NEXT:ret <16 x i8> [[TMP5]]
 //
 // CHECK-LE-LABEL: @test_vec_replace_unaligned_ui(
 // CHECK-LE-NEXT:  entry:
@@ -1220,10 +1217,9 @@
 // CHECK-LE-NEXT:[[TMP3:%.*]] = bitcast <16 x i8> [[TMP1]] to <4 x i32>
 // CHECK-LE-NEXT:[[TMP4:%.*]] = call <4 x i32> @llvm.ppc.altivec.vinsw(<4 x i32> [[TMP3]], i32 [[TMP2]], i32 8)
 // CHECK-LE-NEXT:[[TMP5:%.*]] = bitcast <4 x i32> [[TMP4]] to <16 x i8>
-// CHECK-LE-NEXT:[[TMP6:%.*]] = bitcast <16 x i8> [[TMP5]] to <4 x i32>
-// CHECK-LE-NEXT:ret <4 x i32> [[TMP6]]
+// CHECK-LE-NEXT:ret <16 x i8> [[TMP5]]
 //
-vector unsigned int test_vec_replace_unaligned_ui(void) {
+vector unsigned char test_vec_replace_unaligned_ui(void) {
   return vec_replace_unaligned(vuia, uia, 8);
 }
 
@@ -1236,8 +1232,7 @@
 // CHECK-BE-NEXT:[[TMP3:%.*]] = bitcast <16 x i8> [[TMP1]] to <4 x i32>
 // CHECK-BE-NEXT:[[TMP4:%.*]] = call <4 x i32> @llvm.ppc.altivec.vinsw(<4 x i32> [[TMP3]], i32 [[CONV]], i32 12)
 // CHECK-BE-NEXT:[[TMP5:%.*]] = bitcast <4 x i32> [[TMP4]] to <16 x i8>
-// CHECK-BE-NEXT:[[TMP6:%.*]] = bitcast <16 x i8> [[TMP5]] to <4 x float>
-// CHECK-BE-NEXT:ret <4 x float> [[TMP6]]
+// CHECK-BE-NEXT:ret <16 x i8> [[TMP5]]
 //
 // CHECK-LE-LABEL: @test_vec_replace_unaligned_f(
 // CHECK-LE-NEXT:  entry:
@@ -1248,10 +1243,9 @@
 // CHECK-LE-NEXT:[[TMP3:%.*]] = bitcast <16 x i8> [[TMP1]] to <4 x i32>
 // CHECK-LE-NEXT:[[TMP4:%.*]] = call <4 x i32> @llvm.ppc.altivec.vinsw(<4 x i32> [[TMP3]], i32 [[CONV]], i32 12)
 // CHECK-LE-NEXT:[[TMP5:%.*]] = bitcast <4 x i32> [[TMP4]] to <16 x i8>
-// CHECK-LE-NEXT:[[TMP6:%.*]] = bitcast <16 x i8> [[TMP5]] to <4 x float>
-// CHECK-LE-NEXT:ret <4 x float> [[TMP6]]
+// CHECK-LE-NEXT:ret <16 x i8> [[TMP5]]
 //
-vector float test_vec_replace_unaligned_f(void) {
+vector unsigned char test_vec_

[clang] caf7243 - [PowerPC] Fix signatures for vec_replace_unaligned builtin

[Lei Huang via cfe-commits]

Author: Lei Huang
Date: 2022-06-29T09:35:52-05:00
New Revision: caf7243a6b53aa16f9fbdfbaa18096defb2eb374

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

LOG: [PowerPC] Fix signatures for vec_replace_unaligned builtin

``vec_replace_unaligned`` is meant to return vuc to emphasize that elements
are being inserted on unnatural boundaries.

Reviewed By: amyk, quinnp

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

Added: 


Modified: 
clang/lib/Headers/altivec.h
clang/test/CodeGen/PowerPC/builtins-ppc-p10vector.c
clang/test/CodeGen/PowerPC/builtins-ppc-vec-ins-error.c

Removed: 




diff  --git a/clang/lib/Headers/altivec.h b/clang/lib/Headers/altivec.h
index 4c3ec59d31b34..0b1e76e81cc77 100644
--- a/clang/lib/Headers/altivec.h
+++ b/clang/lib/Headers/altivec.h
@@ -18966,23 +18966,23 @@ vec_blendv(vector double __a, vector double __b,
 
 #define vec_replace_unaligned(__a, __b, __c)   
\
   _Generic((__a), vector signed int
\
-   : (vector signed int)__builtin_altivec_vinsw(   
\
- (vector unsigned char)__a, (unsigned int)__b, __c),   
\
+   : __builtin_altivec_vinsw((vector unsigned char)__a,
\
+ (unsigned int)__b, __c),  
\
  vector unsigned int   
\
-   : (vector unsigned int)__builtin_altivec_vinsw( 
\
- (vector unsigned char)__a, (unsigned int)__b, __c),   
\
+   : __builtin_altivec_vinsw((vector unsigned char)__a,
\
+ (unsigned int)__b, __c),  
\
  vector unsigned long long 
\
-   : (vector unsigned long long)__builtin_altivec_vinsd(   
\
- (vector unsigned char)__a, (unsigned long long)__b, __c), 
\
+   : __builtin_altivec_vinsd((vector unsigned char)__a,
\
+ (unsigned long long)__b, __c),
\
  vector signed long long   
\
-   : (vector signed long long)__builtin_altivec_vinsd( 
\
- (vector unsigned char)__a, (unsigned long long)__b, __c), 
\
+   : __builtin_altivec_vinsd((vector unsigned char)__a,
\
+ (unsigned long long)__b, __c),
\
  vector float  
\
-   : (vector float)__builtin_altivec_vinsw((vector unsigned char)__a,  
\
-   (unsigned int)__b, __c),
\
+   : __builtin_altivec_vinsw((vector unsigned char)__a,
\
+ (unsigned int)__b, __c),  
\
  vector double 
\
-   : (vector double)__builtin_altivec_vinsd(   
\
-   (vector unsigned char)__a, (unsigned long long)__b, __c))
+   : __builtin_altivec_vinsd((vector unsigned char)__a,
\
+ (unsigned long long)__b, __c))
 
 #define vec_replace_elt(__a, __b, __c) 
\
   _Generic((__a), vector signed int
\

diff  --git a/clang/test/CodeGen/PowerPC/builtins-ppc-p10vector.c 
b/clang/test/CodeGen/PowerPC/builtins-ppc-p10vector.c
index c7e9e1a9237f5..c76298a4f0f98 100644
--- a/clang/test/CodeGen/PowerPC/builtins-ppc-p10vector.c
+++ b/clang/test/CodeGen/PowerPC/builtins-ppc-p10vector.c
@@ -1183,8 +1183,7 @@ vector double test_vec_replace_elt_d(void) {
 // CHECK-BE-NEXT:[[TMP3:%.*]] = bitcast <16 x i8> [[TMP1]] to <4 x i32>
 // CHECK-BE-NEXT:[[TMP4:%.*]] = call <4 x i32> @llvm.ppc.altivec.vinsw(<4 
x i32> [[TMP3]], i32 [[TMP2]], i32 6)
 // CHECK-BE-NEXT:[[TMP5:%.*]] = bitcast <4 x i32> [[TMP4]] to <16 x i8>
-// CHECK-BE-NEXT:[[TMP6:%.*]] = bitcast <16 x i8> [[TMP5]] to <4 x i32>
-// CHECK-BE-NEXT:ret <4 x i32> [[TMP6]]
+// CHECK-BE-NEXT:ret <16 x i8> [[TMP5]]
 //
 // CHECK-LE-LABEL: @test_vec_replace_unaligned_si(
 // CHECK-LE-NEXT:  entry:
@@ -1194,10 +1193,9 @@ vector double test_vec_replace_elt_d(void) {
 // CHECK-LE-NEXT:[[TMP3:%.*]] = bitcast <16 x i8> [[TMP1]] to <4 x i32>
 // CHECK-LE-NEXT:[[TMP4:%.*]] = call <4 x i32> @llvm.ppc.altivec.vinsw(<4 
x i32> [[TMP3]], i32 [[TMP2]], i32 6)
 // CHECK-LE-NEXT:[[TMP5:%.*]] = bitcast <4 x i3

[PATCH] D128826: Go-to-type on smart_ptr now also shows Foo

[Tom Praschan via Phabricator via cfe-commits]

tom-anders created this revision.
Herald added subscribers: usaxena95, kadircet, arphaman.
Herald added a project: All.
tom-anders requested review of this revision.
Herald added subscribers: cfe-commits, ilya-biryukov.
Herald added a project: clang-tools-extra.

Fixes clangd/clangd#1026


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128826

Files:
  clang-tools-extra/clangd/HeuristicResolver.h
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp

Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -1786,11 +1786,11 @@
 
 TEST(FindType, All) {
   Annotations HeaderA(R"cpp(
-struct [[Target]] { operator int() const; };
+struct $Target[[Target]] { operator int() const; };
 struct Aggregate { Target a, b; };
 Target t;
 
-template  class smart_ptr {
+template  class $smart_ptr[[smart_ptr]] {
   T& operator*();
   T* operator->();
   T* get();
@@ -1829,11 +1829,11 @@
 ASSERT_GT(A.points().size(), 0u) << Case;
 for (auto Pos : A.points())
   EXPECT_THAT(findType(AST, Pos),
-  ElementsAre(sym("Target", HeaderA.range(), HeaderA.range(
+  ElementsAre(
+sym("Target", HeaderA.range("Target"), HeaderA.range("Target"
   << Case;
   }
 
-  // FIXME: We'd like these cases to work. Fix them and move above.
   for (const llvm::StringRef Case : {
"smart_ptr ^tsmart;",
}) {
@@ -1842,7 +1842,10 @@
 ParsedAST AST = TU.build();
 
 EXPECT_THAT(findType(AST, A.point()),
-Not(Contains(sym("Target", HeaderA.range(), HeaderA.range()
+UnorderedElementsAre(
+  sym("Target", HeaderA.range("Target"), HeaderA.range("Target")),
+  sym("smart_ptr", HeaderA.range("smart_ptr"), HeaderA.range("smart_ptr"))
+))
 << Case;
   }
 }
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -9,6 +9,7 @@
 #include "AST.h"
 #include "FindSymbols.h"
 #include "FindTarget.h"
+#include "HeuristicResolver.h"
 #include "ParsedAST.h"
 #include "Protocol.h"
 #include "Quality.h"
@@ -1907,36 +1908,43 @@
   return QualType();
 }
 
-// Given a type targeted by the cursor, return a type that's more interesting
+// Given a type targeted by the cursor, return one or more types that are more interesting
 // to target.
-static QualType unwrapFindType(QualType T) {
+static llvm::SmallVector unwrapFindType(
+QualType T, const HeuristicResolver* H) {
   if (T.isNull())
-return T;
+return {T};
 
   // If there's a specific type alias, point at that rather than unwrapping.
   if (const auto* TDT = T->getAs())
-return QualType(TDT, 0);
+return {QualType(TDT, 0)};
 
   // Pointers etc => pointee type.
   if (const auto *PT = T->getAs())
-return unwrapFindType(PT->getPointeeType());
+return {unwrapFindType(PT->getPointeeType(), H)};
   if (const auto *RT = T->getAs())
-return unwrapFindType(RT->getPointeeType());
+return {unwrapFindType(RT->getPointeeType(), H)};
   if (const auto *AT = T->getAsArrayTypeUnsafe())
-return unwrapFindType(AT->getElementType());
+return {unwrapFindType(AT->getElementType(), H)};
   // FIXME: use HeuristicResolver to unwrap smart pointers?
 
   // Function type => return type.
   if (auto *FT = T->getAs())
-return unwrapFindType(FT->getReturnType());
+return {unwrapFindType(FT->getReturnType(), H)};
   if (auto *CRD = T->getAsCXXRecordDecl()) {
 if (CRD->isLambda())
-  return unwrapFindType(CRD->getLambdaCallOperator()->getReturnType());
+  return {unwrapFindType(CRD->getLambdaCallOperator()->getReturnType(), H)};
 // FIXME: more cases we'd prefer the return type of the call operator?
 //std::function etc?
   }
 
-  return T;
+  // For smart pointer types, add the underlying type
+  llvm::SmallVector Result = {T};
+  if (H)
+if (const auto* PointeeType = H->getPointeeType(T.getNonReferenceType().getTypePtr()))
+  Result.append(unwrapFindType(QualType(PointeeType, 0), H));
+
+  return Result;
 }
 
 std::vector findType(ParsedAST &AST, Position Pos) {
@@ -1951,10 +1959,14 @@
   // The general scheme is: position -> AST node -> type -> declaration.
   auto SymbolsFromNode =
   [&AST](const SelectionTree::Node *N) -> std::vector {
-QualType Type = unwrapFindType(typeForNode(N));
-if (Type.isNull())
-  return {};
-return locateSymbolForType(AST, Type);
+std::vector LocatedSymbols;
+
+for (const QualType& Type : unwrapFindType(typeForNode(N), AST.getHeuristicResolver()))
+  if (!Type.isNull()) {
+llvm::copy(locateSymbolForType

[PATCH] D126864: [clang] Introduce -fstrict-flex-arrays= for stricter handling of flexible arrays

[Martin Sebor via Phabricator via cfe-commits]

msebor added a comment.

In D126864#3616524 , 
@serge-sans-paille wrote:

> GCC and Clang don't have the same behavior wrt. macros-as-abound and 
> standard-layout-requirement, see https://godbolt.org/z/3vc4TcTYz
> I'm fine with keeping the CLang behavior, but do we want to keep it only for 
> level=0, and drop it for higher level (this would look odd to me).

If you're referring to the warning, GCC needs `-O2` to issue most instances of 
`-Warray-bounds`.  The warning also treats one-element trailing arrays as 
flexible array members, so it's intentionally silent about the test case.  GCC 
should update the warning to reflect the `-fstrict-flex-arrays=N` level.  
(Macros are long expanded by the time the code reaches the middle end so they 
don't come into play, except perhaps when they come from system headers.)


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

https://reviews.llvm.org/D126864

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

[PATCH] D128826: Go-to-type on smart_ptr now also shows Foo

[Tom Praschan via Phabricator via cfe-commits]

tom-anders added inline comments.



Comment at: clang-tools-extra/clangd/HeuristicResolver.h:75
+  // could look up the name appearing on the RHS.
+  const Type *getPointeeType(const Type *T) const;
+

Not sure if it's the right call to make this public? The documentation needs to 
be adapted at least I think


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128826

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

[PATCH] D128826: Go-to-type on smart_ptr now also shows Foo

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

Thanks! I just have a question if this behavior should be even "stronger":

In most editors, if you return one result you go straight there, if you return 
two results you get a menu.
A menu is significantly worse than going straight to the right result - the UI 
is clunkier and the choice interrupts your workflow.

So my question is, do you think that we should *only* return the pointee in 
these cases?

(It's possible to change this later, but I'd like to take a reasonable guess as 
this is forcing an API change from Type -> vector)
cc @kadircet


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128826

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

[PATCH] D128826: Go-to-type on smart_ptr now also shows Foo

[Sam McCall via Phabricator via cfe-commits]

sammccall accepted this revision.
sammccall added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/clangd/HeuristicResolver.h:75
+  // could look up the name appearing on the RHS.
+  const Type *getPointeeType(const Type *T) const;
+

tom-anders wrote:
> Not sure if it's the right call to make this public? The documentation needs 
> to be adapted at least I think
It's a bit unfortunate that it doesn't fit the usual pattern of "resolve the 
target of this AST node", but it's fairly closely related, it needs to use the 
Ctx in the same way, and it's already implemented here... I think it's OK (at 
least I can't see a better alternative).

We should probably have a unit test for it though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128826

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

[PATCH] D128826: Go-to-type on smart_ptr now also shows Foo

[Sam McCall via Phabricator via cfe-commits]

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

Sorry, I didn't mean to accept yet - wanted some discussion on behavior & 
probably a unittest for the newly-public function.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128826

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

[PATCH] D127762: [Clang][AArch64] Add ACLE attributes for SME.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D127762#3615702 , @sdesmalen wrote:

> Thanks for your patience reviewing this patch @aaron.ballman!

Happy to help, thank you for your patience with my constant stream of questions 
about the design. :-)




Comment at: clang/include/clang/AST/Type.h:4064
 bool HasTrailingReturn : 1;
+unsigned AArch64SMEAttributes : 8;
 Qualifiers TypeQuals;

sdesmalen wrote:
> aaron.ballman wrote:
> > If we're taking up space in the extra bitfields, why do we need to also 
> > take up space in the function prototype itself?
> This field is added to ExtProtoInfo struct, which is used to populate the 
> ExtraBitfields in the `FunctionPrototype`'s AST node.
> 
> Sorry if this wasn't clear because the diff had no context. `arc diff` wasn't 
> working for me, so manually updated the patch, but then forgot to add full 
> context.
Ah, I see what's going on there, thank you (the extra context helped as well).



Comment at: clang/include/clang/Basic/Attr.td:2333
 
+def ArmStreamingCompatible : TypeAttr, TargetSpecificAttr {
+  let Spellings = [GNU<"arm_streaming_compatible">];

sdesmalen wrote:
> aaron.ballman wrote:
> > You are handling these as declaration attributes in SemaDeclAttr.cpp but 
> > declaring them to be type attributes here in Attr.td; that's not okay. If 
> > these are type attributes, there should not be code for them in 
> > SemaDeclAttr.cpp. (This is why I really think the design needs to be 
> > rethought; I think they should be type attributes only, but I think you're 
> > trying to match what your specification says.)
> Okay, I've removed the handling in SemaDeclAttr, so that it is only handled 
> in SemaType.cpp.
> 
> But it still allows the attribute to be applied to any position in the 
> function declaration, i.e.
> 
>   __attribute__((arm_streaming)) float foo1(int);
>   float __attribute__((arm_streaming)) foo2(int);
>   float foo3(int) __attribute__((arm_streaming));
> 
> Is that expected?
https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax

"For compatibility with existing code written for compiler versions that did 
not implement attributes on nested declarators, some laxity is allowed in the 
placing of attributes. If an attribute that only applies to types is applied to 
a declaration, it is treated as applying to the type of that declaration. If an 
attribute that only applies to declarations is applied to the type of a 
declaration, it is treated as applying to that declaration; and, for 
compatibility with code placing the attributes immediately before the 
identifier declared, such an attribute applied to a function return type is 
treated as applying to the function type, and such an attribute applied to an 
array element type is treated as applying to the array type. If an attribute 
that only applies to function types is applied to a pointer-to-function type, 
it is treated as applying to the pointer target type; if such an attribute is 
applied to a function return type that is not a pointer-to-function type, it is 
treated as applying to the function type."

So yes, that's expected because the attribute only applies to types, so it 
magically "slides" onto the type regardless of where it was written on the 
declaration. By making it a type only attribute, it's now clear what the GNU 
attribute applies to regardless of where it's written.



Comment at: clang/include/clang/Basic/Attr.td:2345
+
+def ArmLocallyStreaming : DeclOrStmtAttr, TargetSpecificAttr 
{
+  let Spellings = [GNU<"arm_locally_streaming">];

sdesmalen wrote:
> aaron.ballman wrote:
> > Why is this a *statement* attribute?
> You're right that it shouldn't be. I want it to just be a decl attribute and 
> don't want it to be either a Type or a Stmt attribute, but that doesn't seem 
> to exist.
> I find their meaning quite confusing, because both allow me to limit their 
> applicability to Functions. What is the right class to derive from here?
Hmm, we have some documentation at 
https://clang.llvm.org/docs/InternalsManual.html#how-to-add-an-attribute but 
it's not very clear on all the choices and when to pick which one.

For declaration attributes on a function, the question really boils down to 
whether you want redeclarations to automatically inherit the attribute or not. 
e.g.,
```
__attribute__((arm_locally_streaming)) void func(void);
void func(void); // Is this declaration also marked locally streaming?

void use(void) {
  func(); // Does this use see the attribute or not?
}
```
If you want the call in `use()` to see the attribute, then you want the 
attribute to be inherited on the redeclaration, and so you'd use 
`InheritableAttr`. If you don't want the call in `use()` to see the attribute, 
then you'd use `Attr`.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:2000
   "overridden v

[PATCH] D128747: ISSUE - incorrect -Winfinite-recursion warning on potentially-unevaluated operand #21668

[Prathit Aswar via Phabricator via cfe-commits]

appmonster007 updated this revision to Diff 441014.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128747

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Analysis/CFG.cpp
  clang/test/SemaCXX/warn-infinite-recursion.cpp

Index: clang/test/SemaCXX/warn-infinite-recursion.cpp
===
--- clang/test/SemaCXX/warn-infinite-recursion.cpp
+++ clang/test/SemaCXX/warn-infinite-recursion.cpp
@@ -171,3 +171,35 @@
 }
 
 int wrapper_sum = test_wrapper<2>();  // expected-note{{instantiation}}
+
+namespace std {
+class type_info {
+public:
+  virtual ~type_info();
+  const char *name() const { return __name; }
+  bool operator==(const type_info &__arg) const {
+return __name == __arg.__name;
+  }
+
+  bool operator!=(const type_info &__arg) const {
+return !operator==(__arg);
+  }
+
+protected:
+  const char *__name;
+};
+} // namespace std
+struct Q {
+  virtual ~Q() = default;
+};
+
+Q q;
+Q &evaluated_recursive_function(int x) { // expected-warning{{call itself}}
+  (void)typeid(evaluated_recursive_function(x)); // expected-warning {{expression with side effects will be evaluated despite being used as an operand to 'typeid'}}
+  return q;
+}
+
+int unevaluated_recursive_function() {
+  (void)typeid(unevaluated_recursive_function());
+  return 0;
+}
Index: clang/lib/Analysis/CFG.cpp
===
--- clang/lib/Analysis/CFG.cpp
+++ clang/lib/Analysis/CFG.cpp
@@ -564,6 +564,7 @@
 AddStmtChoice asc);
   CFGBlock *VisitCXXThrowExpr(CXXThrowExpr *T);
   CFGBlock *VisitCXXTryStmt(CXXTryStmt *S);
+  CFGBlock *VisitCXXTypeidExpr(CXXTypeidExpr *S, AddStmtChoice asc);
   CFGBlock *VisitDeclStmt(DeclStmt *DS);
   CFGBlock *VisitDeclSubExpr(DeclStmt *DS);
   CFGBlock *VisitDefaultStmt(DefaultStmt *D);
@@ -2220,6 +2221,9 @@
 case Stmt::CXXTryStmtClass:
   return VisitCXXTryStmt(cast(S));
 
+case Stmt::CXXTypeidExprClass:
+  return VisitCXXTypeidExpr(cast(S), asc);
+
 case Stmt::CXXForRangeStmtClass:
   return VisitCXXForRangeStmt(cast(S));
 
@@ -4045,6 +4049,25 @@
   return VisitStmt(T, AddStmtChoice::AlwaysAdd);
 }
 
+CFGBlock *CFGBuilder::VisitCXXTypeidExpr(CXXTypeidExpr *S, AddStmtChoice asc) {
+  if (asc.alwaysAdd(*this, S)) {
+autoCreateBlock();
+appendStmt(Block, S);
+  }
+
+  // C++ [expr.typeid]p3:
+  //   When typeid is applied to an expression other than an glvalue of a
+  //   polymorphic class type [...] [the] expression is an unevaluated
+  //   operand. [...]
+  // We add only potentially evaluated statements to the block to avoid
+  // CFG generation for unevaluated operands.
+  if (S && !S->isTypeDependent() && S->isPotentiallyEvaluated())
+return VisitChildren(S);
+
+  // Return block without CFG for unevaluated operands.
+  return Block;
+}
+
 CFGBlock *CFGBuilder::VisitDoStmt(DoStmt *D) {
   CFGBlock *LoopSuccessor = nullptr;
 
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -275,6 +275,10 @@
   This fixes `Issue 55962 `_.
 - Printable Unicode characters within `static_assert` messages are no longer
   escaped.
+- The ``-Winfinite-recursion`` diagnostic will not warn for
+  unevaluated operands of ``typeid`` expression. Unevaluated
+  operands of ``typeid`` expression are skipped for the CFG build.
+  This fixes `Issue 21668 `_.
 
 Non-comprehensive list of changes in this release
 -
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D122255: Meta directive runtime support

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: clang/include/clang/AST/OpenMPClause.h:8859
+/// \code
+/// #pragma omp metadirective when(user={consition(N<100)}:parallel for)
+/// \endcode

condition?



Comment at: clang/include/clang/AST/OpenMPClause.h:8893-8894
+
+  /// Sets the location of '('.
+  void setLParenLoc(SourceLocation Loc) { LParenLoc = Loc; }
+

make it private



Comment at: clang/include/clang/AST/OpenMPClause.h:8900
+  /// Returns the directive variant kind
+  OpenMPDirectiveKind getDKind() { return DKind; }
+

const



Comment at: clang/include/clang/AST/OpenMPClause.h:8905
+  /// Returns the OMPTraitInfo
+  OMPTraitInfo &getTI() { return *TI; }
+

const



Comment at: clang/include/clang/AST/StmtOpenMP.h:5479
EmptyShell);
+   
   Stmt *getIfStmt() const { return IfStmt; }

Remove this change



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:10852
+def err_omp_misplaced_default_clause : Error<
+  "misplaced default clause! Only one default clause is allowed in"
+  "metadirective in the end">;

We do not use explamations in messages, better to have something `only single 
default ...`



Comment at: clang/include/clang/Sema/Sema.h:10688
   Stmt *AStmt, SourceLocation StartLoc, SourceLocation EndLoc);
+  StmtResult ActOnOpenMPExecutableMetaDirective( 
+  OpenMPDirectiveKind Kind, const DeclarationNameInfo &DirName, 

Comment for this new function



Comment at: clang/include/clang/Sema/Sema.h:11138
+  OMPClause *ActOnOpenMPWhenClause(OMPTraitInfo &TI, OpenMPDirectiveKind DKind,
+   StmtResult Directive,
+   SourceLocation StartLoc,

formatting



Comment at: clang/lib/AST/OpenMPClause.cpp:1614-1617
+  if (Node->getTI().Sets.size() == 0) {
+OS << "default(";
+return;
+  }

Is this correct? Just `default(` is expected to be printed?



Comment at: clang/lib/AST/StmtPrinter.cpp:658
   bool ForceNoStmt) {
+
   OMPClausePrinter Printer(OS, Policy);

Do not insert empty line here



Comment at: clang/lib/AST/StmtPrinter.cpp:661
   ArrayRef Clauses = S->clauses();
-  for (auto *Clause : Clauses)
+  for (auto *Clause : Clauses){
 if (Clause && !Clause->isImplicit()) {

formatting



Comment at: clang/lib/AST/StmtPrinter.cpp:665
   Printer.Visit(Clause);
+  if (dyn_cast(S)){
+ 

use `isa`



Comment at: clang/lib/AST/StmtPrinter.cpp:667
+ 
+   OMPWhenClause *c = dyn_cast(Clause);
+   if (c!=NULL){

Camel naming style expceted



Comment at: clang/lib/AST/StmtPrinter.cpp:668
+   OMPWhenClause *c = dyn_cast(Clause);
+   if (c!=NULL){
+   if (c->getDKind() != llvm::omp::OMPD_unknown){

formatting, use nullptr instead of NULL (or just `C`)



Comment at: clang/lib/AST/StmtPrinter.cpp:669
+   if (c!=NULL){
+   if (c->getDKind() != llvm::omp::OMPD_unknown){
+   Printer.VisitOMPWhenClause(c);

Formatting



Comment at: clang/lib/Parse/ParseOpenMP.cpp:2433
 Parser::ParseOpenMPDeclarativeOrExecutableDirective(ParsedStmtContext StmtCtx) 
{
+// need to check about the following
   static bool ReadDirectiveWithinMetadirective = false;

What is this?



Comment at: clang/lib/Parse/ParseOpenMP.cpp:2474
tok::annot_pragma_openmp_end);
+   
 while (Tok.isNot(tok::annot_pragma_openmp_end)) {

Restore original code here



Comment at: clang/lib/Parse/ParseOpenMP.cpp:2498-2506
+// Parse ':' // You have parsed the OpenMP Context in the meta 
directive 
 if (Tok.is(tok::colon))
   ConsumeAnyToken();
 else {
   Diag(Tok, diag::err_omp_expected_colon) << "when clause";
   TPA.Commit();
   return Directive;

Remove this extra stuff 



Comment at: clang/lib/Parse/ParseOpenMP.cpp:2546
+// Array A will be used for sorting
+SmallVector> A;
+

What `A` stands after, what does it mean?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122255

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

[PATCH] D128704: [clang-extdef-mapping] Directly process .ast files

[Tobias Hieta via Phabricator via cfe-commits]

thieta added inline comments.



Comment at: clang/tools/clang-extdef-mapping/ClangExtDefMapGen.cpp:136
+  FileManager fm(CI.getFileSystemOpts());
+  SmallString<128> absPath(astPath);
+  fm.makeAbsolutePath(absPath);

thieta wrote:
> Pretty sure 128 is wrong here - but I searched the codebase and that seems to 
> be the most common size used? I couldn't find anything using PATH_MAX or 
> something like that.
Never mind 128 is just the default size not the absolute size. Got it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128704

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

[PATCH] D128786: [clang-format] Fix incorrect isspace input (NFC)

[MyDeveloperDay via Phabricator via cfe-commits]

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128786

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

[PATCH] D128762: [Clang] Rename StringLiteral::isAscii() => isOrdinary() [NFC]

[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.

Assuming precommit CI comes back clean, this LGTM!




Comment at: clang/include/clang/AST/Expr.h:1789-1886
+  enum StringKind { Ordinary, Wide, UTF8, UTF16, UTF32 };
 
 private:
   unsigned numTrailingObjects(OverloadToken) const { return 1; }
   unsigned numTrailingObjects(OverloadToken) const {
 return getNumConcatenated();
   }

cor3ntin wrote:
> aaron.ballman wrote:
> > I like the idea of renaming both of these -- `isASCII()` can be a bit 
> > confusing with `containsNonAscii()` as well. However, instead of 
> > "ordinary", would it make more sense to go with "narrow" as the term of 
> > art? That also goes nicely with the use of "wide" in this interface.
> narrow encompass ordinary and `u8` literals in standard terminology.
> And, I think `narrow` is too easilly mistaken as a synonym for 
> `getByteLength() == 1`
Ah, okay, I didn't remember correctly that narrow included UTF-8 literals. 
"Ordinary" is fine by me, thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128762

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

[PATCH] D126956: [tbaa] Handle base classes in struct tbaa

[Bruno De Fraine via Phabricator via cfe-commits]

brunodf updated this revision to Diff 441017.
brunodf added a comment.
Herald added a subscriber: mgrang.

New version that fixes the problem with base classes not appearing in order of 
increasing offset.

This issue was discovered in the multistage build, but the test case has now 
been extended for this situation.

Also changed to obtain the the size of the base subobject with `getDataSize()` 
since other subobjects may be allocated in its tail padding.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126956

Files:
  clang/lib/CodeGen/CodeGenTBAA.cpp
  clang/test/CodeGen/tbaa-class.cpp
  clang/unittests/CodeGen/TBAAMetadataTest.cpp

Index: clang/unittests/CodeGen/TBAAMetadataTest.cpp
===
--- clang/unittests/CodeGen/TBAAMetadataTest.cpp
+++ clang/unittests/CodeGen/TBAAMetadataTest.cpp
@@ -968,13 +968,10 @@
   MConstInt(0)),
 MConstInt(0));
 
-  auto ClassDerived = MMTuple(
-MMString("_ZTS7Derived"),
-MMTuple(
-  MMString("short"),
-  OmnipotentCharCXX,
-  MConstInt(0)),
-MConstInt(4));
+  auto ClassDerived =
+  MMTuple(MMString("_ZTS7Derived"), ClassBase, MConstInt(0),
+  MMTuple(MMString("short"), OmnipotentCharCXX, MConstInt(0)),
+  MConstInt(4));
 
   const Instruction *I = match(BB,
   MInstruction(Instruction::Store,
@@ -1047,13 +1044,10 @@
   MConstInt(0)),
 MConstInt(Compiler.PtrSize));
 
-  auto ClassDerived = MMTuple(
-MMString("_ZTS7Derived"),
-MMTuple(
-  MMString("short"),
-  OmnipotentCharCXX,
-  MConstInt(0)),
-MConstInt(Compiler.PtrSize + 4));
+  auto ClassDerived =
+  MMTuple(MMString("_ZTS7Derived"), ClassBase, MConstInt(0),
+  MMTuple(MMString("short"), OmnipotentCharCXX, MConstInt(0)),
+  MConstInt(Compiler.PtrSize + 4));
 
   const Instruction *I = match(BB,
   MInstruction(Instruction::Store,
Index: clang/test/CodeGen/tbaa-class.cpp
===
--- clang/test/CodeGen/tbaa-class.cpp
+++ clang/test/CodeGen/tbaa-class.cpp
@@ -51,6 +51,25 @@
uint32_t f32_2;
 };
 
+class StructT {
+public:
+  uint32_t f32_2;
+  void foo();
+};
+class StructM1 : public StructS, public StructT {
+public:
+  uint16_t f16_2;
+};
+class StructDyn {
+public:
+  uint32_t f32_2;
+  virtual void foo();
+};
+class StructM2 : public StructS, public StructDyn {
+public:
+  uint16_t f16_2;
+};
+
 uint32_t g(uint32_t *s, StructA *A, uint64_t count) {
 // CHECK-LABEL: define{{.*}} i32 @_Z1g
 // CHECK: store i32 1, i32* %{{.*}}, align 4, !tbaa [[TAG_i32:!.*]]
@@ -199,6 +218,30 @@
   return b1->a.f32;
 }
 
+uint32_t g13(StructM1 *M, StructS *S) {
+  // CHECK-LABEL: define{{.*}} i32 @_Z3g13
+  // CHECK: store i16 1, i16* %{{.*}}, align 4, !tbaa [[TAG_i16]]
+  // CHECK: store i16 4, i16* %{{.*}}, align 4, !tbaa [[TAG_i16]]
+  // PATH-LABEL: define{{.*}} i32 @_Z3g13
+  // PATH: store i16 1, i16* %{{.*}}, align 4, !tbaa [[TAG_S_f16]]
+  // PATH: store i16 4, i16* %{{.*}}, align 4, !tbaa [[TAG_M1_f16_2:!.*]]
+  S->f16 = 1;
+  M->f16_2 = 4;
+  return S->f16;
+}
+
+uint32_t g14(StructM2 *M, StructS *S) {
+  // CHECK-LABEL: define{{.*}} i32 @_Z3g14
+  // CHECK: store i16 1, i16* %{{.*}}, align 4, !tbaa [[TAG_i16]]
+  // CHECK: store i16 4, i16* %{{.*}}, align 4, !tbaa [[TAG_i16]]
+  // PATH-LABEL: define{{.*}} i32 @_Z3g14
+  // PATH: store i16 1, i16* %{{.*}}, align 4, !tbaa [[TAG_S_f16]]
+  // PATH: store i16 4, i16* %{{.*}}, align 4, !tbaa [[TAG_M2_f16_2:!.*]]
+  S->f16 = 1;
+  M->f16_2 = 4;
+  return S->f16;
+}
+
 // CHECK: [[TYPE_char:!.*]] = !{!"omnipotent char", [[TAG_cxx_tbaa:!.*]],
 // CHECK: [[TAG_cxx_tbaa]] = !{!"Simple C++ TBAA"}
 // CHECK: [[TAG_i32]] = !{[[TYPE_i32:!.*]], [[TYPE_i32]], i64 0}
@@ -222,11 +265,17 @@
 // OLD-PATH: [[TYPE_S]] = !{!"_ZTS7StructS", [[TYPE_SHORT]], i64 0, [[TYPE_INT]], i64 4}
 // OLD-PATH: [[TAG_S_f16]] = !{[[TYPE_S]], [[TYPE_SHORT]], i64 0}
 // OLD-PATH: [[TAG_S2_f32_2]] = !{[[TYPE_S2:!.*]], [[TYPE_INT]], i64 12}
-// OLD-PATH: [[TYPE_S2]] = !{!"_ZTS8StructS2", [[TYPE_SHORT]], i64 8, [[TYPE_INT]], i64 12}
+// OLD-PATH: [[TYPE_S2]] = !{!"_ZTS8StructS2", [[TYPE_S]], i64 0, [[TYPE_SHORT]], i64 8, [[TYPE_INT]], i64 12}
 // OLD-PATH: [[TAG_C_b_a_f32]] = !{[[TYPE_C:!.*]], [[TYPE_INT]], i64 12}
 // OLD-PATH: [[TYPE_C]] = !{!"_ZTS7StructC", [[TYPE_SHORT]], i64 0, [[TYPE_B]], i64 4, [[TYPE_INT]], i64 28}
 // OLD-PATH: [[TAG_D_b_a_f32]] = !{[[TYPE_D:!.*]], [[TYPE_INT]], i64 12}
 // OLD-PATH: [[TYPE_D]] = !{!"_ZTS7StructD", [[TYPE_SHORT]], i64 0, [[TYPE_B]], i64 4, [[TYPE_INT]], i64 28, [[TYPE_CHAR]], i64 32}
+// OLD-PATH: [[TAG_M1_f16_2]] = !{[[TYPE_M1:!.*]], [[TYPE_SHORT]], i64 12}
+// OLD-PATH: [[TYPE_M1]] = !{!"_ZTS8StructM1", [[TYPE_S]], i64 0, [[TYPE_T:!.*]], i64 8, [[TYPE_SHORT]], i64 12}
+// OLD_PATH: [[TYPE_T]] = !{!"_ZTS7StructT", [[TYPE_INT]], i64 0}
+// OLD-