[PATCH] D93829: [clangd] Support outgoing calls in call hierarchy

2020-12-26 Thread Quentin Chateau via Phabricator via cfe-commits
qchateau updated this revision to Diff 313767.
qchateau added a comment.

- Fix tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93829

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/XRefs.h
  clang-tools-extra/clangd/index/Index.cpp
  clang-tools-extra/clangd/index/Index.h
  clang-tools-extra/clangd/index/MemIndex.cpp
  clang-tools-extra/clangd/index/MemIndex.h
  clang-tools-extra/clangd/index/Merge.cpp
  clang-tools-extra/clangd/index/Merge.h
  clang-tools-extra/clangd/index/ProjectAware.cpp
  clang-tools-extra/clangd/index/dex/Dex.cpp
  clang-tools-extra/clangd/index/dex/Dex.h
  clang-tools-extra/clangd/test/type-hierarchy.test
  clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang-tools-extra/clangd/unittests/RenameTests.cpp

Index: clang-tools-extra/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/clangd/unittests/RenameTests.cpp
@@ -1225,6 +1225,12 @@
   return true; // has more references
 }
 
+bool refersTo(const RefsRequest ,
+  llvm::function_ref Callback)
+const override {
+  return false;
+}
+
 bool fuzzyFind(
 const FuzzyFindRequest ,
 llvm::function_ref Callback) const override {
@@ -1281,6 +1287,12 @@
   return false;
 }
 
+bool refersTo(const RefsRequest ,
+  llvm::function_ref Callback)
+const override {
+  return false;
+}
+
 bool fuzzyFind(const FuzzyFindRequest &,
llvm::function_ref) const override {
   return false;
Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -1345,6 +1345,12 @@
 return false;
   }
 
+  bool
+  refersTo(const RefsRequest &,
+   llvm::function_ref) const override {
+return false;
+  }
+
   void relations(const RelationsRequest &,
  llvm::function_ref)
   const override {}
Index: clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
===
--- clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
+++ clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
@@ -37,17 +37,27 @@
 
 // Helpers for matching call hierarchy data structures.
 MATCHER_P(WithName, N, "") { return arg.name == N; }
+MATCHER_P(WithDetail, N, "") { return arg.detail == N; }
 MATCHER_P(WithSelectionRange, R, "") { return arg.selectionRange == R; }
 
 template 
 ::testing::Matcher From(ItemMatcher M) {
   return Field(::from, M);
 }
+template 
+::testing::Matcher To(ItemMatcher M) {
+  return Field(::to, M);
+}
 template 
-::testing::Matcher FromRanges(RangeMatchers... M) {
+::testing::Matcher IFromRanges(RangeMatchers... M) {
   return Field(::fromRanges,
UnorderedElementsAre(M...));
 }
+template 
+::testing::Matcher OFromRanges(RangeMatchers... M) {
+  return Field(::fromRanges,
+   UnorderedElementsAre(M...));
+}
 
 TEST(CallHierarchy, IncomingOneFile) {
   Annotations Source(R"cpp(
@@ -72,22 +82,25 @@
   prepareCallHierarchy(AST, Source.point(), testPath(TU.Filename));
   ASSERT_THAT(Items, ElementsAre(WithName("callee")));
   auto IncomingLevel1 = incomingCalls(Items[0], Index.get());
-  ASSERT_THAT(IncomingLevel1,
-  ElementsAre(AllOf(From(WithName("caller1")),
-FromRanges(Source.range("Callee");
+  ASSERT_THAT(
+  IncomingLevel1,
+  ElementsAre(AllOf(From(AllOf(WithName("caller1"), WithDetail("caller1"))),
+IFromRanges(Source.range("Callee");
 
   auto IncomingLevel2 = incomingCalls(IncomingLevel1[0].from, Index.get());
-  ASSERT_THAT(IncomingLevel2,
-  ElementsAre(AllOf(From(WithName("caller2")),
-FromRanges(Source.range("Caller1A"),
-   Source.range("Caller1B"))),
-  AllOf(From(WithName("caller3")),
-FromRanges(Source.range("Caller1C");
+  ASSERT_THAT(
+  IncomingLevel2,
+  ElementsAre(AllOf(From(AllOf(WithName("caller2"), WithDetail("caller2"))),
+IFromRanges(Source.range("Caller1A"),
+Source.range("Caller1B"))),
+  AllOf(From(AllOf(WithName("caller3"), WithDetail("caller3"))),
+IFromRanges(Source.range("Caller1C");
 
   auto IncomingLevel3 = 

[PATCH] D93829: [clangd] Support outgoing calls in call hierarchy

2020-12-26 Thread Quentin Chateau via Phabricator via cfe-commits
qchateau created this revision.
qchateau added a reviewer: sammccall.
Herald added subscribers: usaxena95, kadircet, arphaman, mgrang.
qchateau requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang.

The implementation is very close the the incoming
calls implementation. The results of the outgoing
calls are expected to be the exact symmetry of the
incoming calls.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93829

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/XRefs.h
  clang-tools-extra/clangd/index/Index.cpp
  clang-tools-extra/clangd/index/Index.h
  clang-tools-extra/clangd/index/MemIndex.cpp
  clang-tools-extra/clangd/index/MemIndex.h
  clang-tools-extra/clangd/index/Merge.cpp
  clang-tools-extra/clangd/index/Merge.h
  clang-tools-extra/clangd/index/ProjectAware.cpp
  clang-tools-extra/clangd/index/dex/Dex.cpp
  clang-tools-extra/clangd/index/dex/Dex.h
  clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang-tools-extra/clangd/unittests/RenameTests.cpp

Index: clang-tools-extra/clangd/unittests/RenameTests.cpp
===
--- clang-tools-extra/clangd/unittests/RenameTests.cpp
+++ clang-tools-extra/clangd/unittests/RenameTests.cpp
@@ -1225,6 +1225,12 @@
   return true; // has more references
 }
 
+bool refersTo(const RefsRequest ,
+  llvm::function_ref Callback)
+const override {
+  return false;
+}
+
 bool fuzzyFind(
 const FuzzyFindRequest ,
 llvm::function_ref Callback) const override {
@@ -1281,6 +1287,12 @@
   return false;
 }
 
+bool refersTo(const RefsRequest ,
+  llvm::function_ref Callback)
+const override {
+  return false;
+}
+
 bool fuzzyFind(const FuzzyFindRequest &,
llvm::function_ref) const override {
   return false;
Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -1345,6 +1345,12 @@
 return false;
   }
 
+  bool
+  refersTo(const RefsRequest &,
+   llvm::function_ref) const override {
+return false;
+  }
+
   void relations(const RelationsRequest &,
  llvm::function_ref)
   const override {}
Index: clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
===
--- clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
+++ clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
@@ -37,17 +37,27 @@
 
 // Helpers for matching call hierarchy data structures.
 MATCHER_P(WithName, N, "") { return arg.name == N; }
+MATCHER_P(WithDetail, N, "") { return arg.detail == N; }
 MATCHER_P(WithSelectionRange, R, "") { return arg.selectionRange == R; }
 
 template 
 ::testing::Matcher From(ItemMatcher M) {
   return Field(::from, M);
 }
+template 
+::testing::Matcher To(ItemMatcher M) {
+  return Field(::to, M);
+}
 template 
-::testing::Matcher FromRanges(RangeMatchers... M) {
+::testing::Matcher IFromRanges(RangeMatchers... M) {
   return Field(::fromRanges,
UnorderedElementsAre(M...));
 }
+template 
+::testing::Matcher OFromRanges(RangeMatchers... M) {
+  return Field(::fromRanges,
+   UnorderedElementsAre(M...));
+}
 
 TEST(CallHierarchy, IncomingOneFile) {
   Annotations Source(R"cpp(
@@ -72,22 +82,25 @@
   prepareCallHierarchy(AST, Source.point(), testPath(TU.Filename));
   ASSERT_THAT(Items, ElementsAre(WithName("callee")));
   auto IncomingLevel1 = incomingCalls(Items[0], Index.get());
-  ASSERT_THAT(IncomingLevel1,
-  ElementsAre(AllOf(From(WithName("caller1")),
-FromRanges(Source.range("Callee");
+  ASSERT_THAT(
+  IncomingLevel1,
+  ElementsAre(AllOf(From(AllOf(WithName("caller1"), WithDetail("caller1"))),
+IFromRanges(Source.range("Callee");
 
   auto IncomingLevel2 = incomingCalls(IncomingLevel1[0].from, Index.get());
-  ASSERT_THAT(IncomingLevel2,
-  ElementsAre(AllOf(From(WithName("caller2")),
-FromRanges(Source.range("Caller1A"),
-   Source.range("Caller1B"))),
-  AllOf(From(WithName("caller3")),
-FromRanges(Source.range("Caller1C");
+  ASSERT_THAT(
+  IncomingLevel2,
+  ElementsAre(AllOf(From(AllOf(WithName("caller2"), WithDetail("caller2"))),
+IFromRanges(Source.range("Caller1A"),
+   

[PATCH] D93787: [analyzer] Fix crash caused by accessing empty map

2020-12-26 Thread Vince Bridgers via Phabricator via cfe-commits
vabridgers added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:1241
   if (TheTok.getIdentifierInfo() == VariadicParamII) {
-TStream.injectRange(PrevParamMap.at(VariadicParamII));
+if (PrevParamMap.find(VariadicParamII) != PrevParamMap.end())
+  TStream.injectRange(PrevParamMap.at(VariadicParamII));

steakhal wrote:
> Btw this lookup supposed to be successful. Always. Which suggests me that 
> there are even more logic bug lurking there.
> Without using 'at' here we wouldn't notice it, which is lucky.
If we keep the at(), maybe it's worthwhile adding an assert for the key 
present? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93787

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


[PATCH] D93787: [analyzer] Fix crash caused by accessing empty map

2020-12-26 Thread Vince Bridgers via Phabricator via cfe-commits
vabridgers added a comment.

Thanks @steakhal , I found your Bugzilla bug only after I submitted this patch. 
I'll revise based on your comments and resubmit. Best!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93787

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


[PATCH] D93595: [analyzer] Fix extraction of punned and known scalar SVals

2020-12-26 Thread Vince Bridgers via Phabricator via cfe-commits
vabridgers added a comment.

Thanks for the comments, @NoQ . I'll carefully review and update. BTW, I found 
an old Bugzilla case that seems to relate to this change directly -> 
https://bugs.llvm.org/show_bug.cgi?id=2820. Once this change is evolved and 
accepted, I'll update that Bugzilla issue and close. Cheers!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93595

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


[PATCH] D93806: [clang-format] PR48569 clang-format fails to align case label with `switch` with Whitesmith Indentation

2020-12-26 Thread MyDeveloperDay via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGc7dcc4c72588: [clang-format] PR48569 clang-format fails to 
align case label with `switch`… (authored by MyDeveloperDay).

Changed prior to commit:
  https://reviews.llvm.org/D93806?vs=313699=313746#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93806

Files:
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -13658,7 +13658,7 @@
"  {\n"
"  switch (a)\n"
"{\n"
-   "case 2:\n"
+   "  case 2:\n"
"{\n"
"}\n"
"break;\n"
@@ -13670,18 +13670,18 @@
"  {\n"
"  switch (a)\n"
"{\n"
-   "case 0:\n"
+   "  case 0:\n"
"break;\n"
-   "case 1:\n"
+   "  case 1:\n"
"{\n"
"foo();\n"
"break;\n"
"}\n"
-   "case 2:\n"
+   "  case 2:\n"
"{\n"
"}\n"
"break;\n"
-   "default:\n"
+   "  default:\n"
"break;\n"
"}\n"
"  }\n",
@@ -13691,12 +13691,12 @@
"  {\n"
"  switch (a)\n"
"{\n"
-   "case 0:\n"
+   "  case 0:\n"
"{\n"
"foo(x);\n"
"}\n"
"break;\n"
-   "default:\n"
+   "  default:\n"
"{\n"
"foo(1);\n"
"}\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2244,18 +2244,26 @@
 --Line->Level;
   if (LeftAlignLabel)
 Line->Level = 0;
+
+  bool RemoveWhitesmithsCaseIndent =
+  (!Style.IndentCaseBlocks &&
+   Style.BreakBeforeBraces == FormatStyle::BS_Whitesmiths);
+
+  if (RemoveWhitesmithsCaseIndent)
+--Line->Level;
+
   if (!Style.IndentCaseBlocks && CommentsBeforeNextToken.empty() &&
   FormatTok->Tok.is(tok::l_brace)) {
-CompoundStatementIndenter Indenter(this, Line->Level,
-   Style.BraceWrapping.AfterCaseLabel,
-   Style.BraceWrapping.IndentBraces);
+
+CompoundStatementIndenter Indenter(
+this, Line->Level, Style.BraceWrapping.AfterCaseLabel,
+Style.BraceWrapping.IndentBraces || RemoveWhitesmithsCaseIndent);
 parseBlock(/*MustBeDeclaration=*/false);
 if (FormatTok->Tok.is(tok::kw_break)) {
   if (Style.BraceWrapping.AfterControlStatement ==
   FormatStyle::BWACS_Always) {
 addUnwrappedLine();
-if (!Style.IndentCaseBlocks &&
-Style.BreakBeforeBraces == FormatStyle::BS_Whitesmiths) {
+if (RemoveWhitesmithsCaseIndent) {
   Line->Level++;
 }
   }
@@ -2276,6 +2284,7 @@
 
 void UnwrappedLineParser::parseCaseLabel() {
   assert(FormatTok->Tok.is(tok::kw_case) && "'case' expected");
+
   // FIXME: fix handling of complex expressions here.
   do {
 nextToken();


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -13658,7 +13658,7 @@
"  {\n"
"  switch (a)\n"
"{\n"
-   "case 2:\n"
+   "  case 2:\n"
"{\n"
"}\n"
"break;\n"
@@ -13670,18 +13670,18 @@
"  {\n"
"  switch (a)\n"
"{\n"
-   "case 0:\n"
+   "  case 0:\n"
"break;\n"
-   "case 1:\n"
+   "  case 1:\n"
"{\n"
"foo();\n"
"break;\n"
"}\n"
-   "case 2:\n"
+   "  case 2:\n"
"{\n"
"}\n"
"break;\n"
-   "default:\n"
+   "  default:\n"
"break;\n"
"}\n"
"  }\n",
@@ -13691,12 +13691,12 @@
"  {\n"
"  switch (a)\n"
"{\n"
-   "case 0:\n"
+   "  case 

[clang] c7dcc4c - [clang-format] PR48569 clang-format fails to align case label with `switch` with Whitesmith Indentation

2020-12-26 Thread via cfe-commits

Author: mydeveloperday
Date: 2020-12-26T15:19:03Z
New Revision: c7dcc4c72588db9ffb7ae379983450193b943f5b

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

LOG: [clang-format] PR48569 clang-format fails to align case label with 
`switch` with Whitesmith Indentation

https://bugs.llvm.org/show_bug.cgi?id=48569

This is a tentative fix which addresses a PR raise regarding Case indentation 
when working with Whitesmiths Indentation

I could not find online any reference sources as to what the case indentation 
for Whitesmith's should be (or be allowed to be)

But according to the documentation, we don't obey the rules for Whitesmith's

```
In particular, the documentation states that this option is to "indent case 
labels one level from the switch statement. When false, use the same 
indentation level as for the switch statement."
```

The behaviour we add here is actually as the TODO in the tests used to state in 
{D67627}, but when {D82016} was added and I brought these tests out from being 
TODO I realized I changed the indentation.

Reviewed By: curdeius, HazardyKnusperkeks

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

Added: 


Modified: 
clang/lib/Format/UnwrappedLineParser.cpp
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/lib/Format/UnwrappedLineParser.cpp 
b/clang/lib/Format/UnwrappedLineParser.cpp
index 4c2ee421d092..99b8c28dca2b 100644
--- a/clang/lib/Format/UnwrappedLineParser.cpp
+++ b/clang/lib/Format/UnwrappedLineParser.cpp
@@ -2244,18 +2244,26 @@ void UnwrappedLineParser::parseLabel(bool 
LeftAlignLabel) {
 --Line->Level;
   if (LeftAlignLabel)
 Line->Level = 0;
+
+  bool RemoveWhitesmithsCaseIndent =
+  (!Style.IndentCaseBlocks &&
+   Style.BreakBeforeBraces == FormatStyle::BS_Whitesmiths);
+
+  if (RemoveWhitesmithsCaseIndent)
+--Line->Level;
+
   if (!Style.IndentCaseBlocks && CommentsBeforeNextToken.empty() &&
   FormatTok->Tok.is(tok::l_brace)) {
-CompoundStatementIndenter Indenter(this, Line->Level,
-   Style.BraceWrapping.AfterCaseLabel,
-   Style.BraceWrapping.IndentBraces);
+
+CompoundStatementIndenter Indenter(
+this, Line->Level, Style.BraceWrapping.AfterCaseLabel,
+Style.BraceWrapping.IndentBraces || RemoveWhitesmithsCaseIndent);
 parseBlock(/*MustBeDeclaration=*/false);
 if (FormatTok->Tok.is(tok::kw_break)) {
   if (Style.BraceWrapping.AfterControlStatement ==
   FormatStyle::BWACS_Always) {
 addUnwrappedLine();
-if (!Style.IndentCaseBlocks &&
-Style.BreakBeforeBraces == FormatStyle::BS_Whitesmiths) {
+if (RemoveWhitesmithsCaseIndent) {
   Line->Level++;
 }
   }
@@ -2276,6 +2284,7 @@ void UnwrappedLineParser::parseLabel(bool LeftAlignLabel) 
{
 
 void UnwrappedLineParser::parseCaseLabel() {
   assert(FormatTok->Tok.is(tok::kw_case) && "'case' expected");
+
   // FIXME: fix handling of complex expressions here.
   do {
 nextToken();

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index b6d9e67273ac..bdf4abb26c7e 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -13658,7 +13658,7 @@ TEST_F(FormatTest, WhitesmithsBraceBreaking) {
"  {\n"
"  switch (a)\n"
"{\n"
-   "case 2:\n"
+   "  case 2:\n"
"{\n"
"}\n"
"break;\n"
@@ -13670,18 +13670,18 @@ TEST_F(FormatTest, WhitesmithsBraceBreaking) {
"  {\n"
"  switch (a)\n"
"{\n"
-   "case 0:\n"
+   "  case 0:\n"
"break;\n"
-   "case 1:\n"
+   "  case 1:\n"
"{\n"
"foo();\n"
"break;\n"
"}\n"
-   "case 2:\n"
+   "  case 2:\n"
"{\n"
"}\n"
"break;\n"
-   "default:\n"
+   "  default:\n"
"break;\n"
"}\n"
"  }\n",
@@ -13691,12 +13691,12 @@ TEST_F(FormatTest, WhitesmithsBraceBreaking) {
"  {\n"
"  switch (a)\n"
"{\n"
-   "case 0:\n"
+   "  case 0:\n"
"{\n"
"foo(x);\n"
"}\n"
"break;\n"
-   "default:\n"
+   "  default:\n"
"{\n"
"foo(1);\n"
"

[PATCH] D93822: [clang][Sema] Add diagnostics for implicit widening of multiplication result

2020-12-26 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri created this revision.
lebedev.ri added reviewers: rsmith, aaron.ballman, rjmccall, erichkeane, 
dblaikie.
lebedev.ri added a project: LLVM.
lebedev.ri requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Overflows are never fun.
In most cases (in most of the code), they are rare,
because usually you e.g. don't have as many elements.

However, it's exceptionally easy to fall into this pitfail
in code that deals with images, because, assuming 4-channel 32-bit FP data,
you need *just* ~269 megapixel image to case an overflow
when computing at least the total byte count.

In darktable , there is a *long*, 
painful history of dealing with such bugs:

- https://github.com/darktable-org/darktable/pull/7419
- 
https://github.com/darktable-org/darktable/commit/eea1989f2c9fa76710db07baaec4c19c1e40e81c
- 
https://github.com/darktable-org/darktable/commit/70626dd95bf0fab36f2d011dab075e3ebbf7aa28
- https://github.com/darktable-org/darktable/pull/670
- 
https://github.com/darktable-org/darktable/commit/38c69fb1b2bc90057c569242cb9945a10be0b583

and yet they clearly keep resurfacing still.

It would be immensely helpful to have a diagnostic for those patterns,
which is what this change proposes.

Currently, i only diagnose the most obvious case, where multiplication
is directly widened with no other expressions inbetween,
(i.e. `long r = (int)a * (int)b` but not even e.g. `long r = ((int)a * (int)b)`)
however that might be worth relaxing later.

Right now i've added the diagnostic into `-Wall`.
I have not yet looked at clang stage-2 story.

Thoughts?


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D93822

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Sema/implicit-widening-of-multiplication-result.c
  
clang/test/Sema/implicit-widening-of-pointer-offset-in-array-subscript-expression.c
  clang/test/Sema/implicit-widening-of-pointer-offset.c

Index: clang/test/Sema/implicit-widening-of-pointer-offset.c
===
--- /dev/null
+++ clang/test/Sema/implicit-widening-of-pointer-offset.c
@@ -0,0 +1,97 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -Wimplicit-widening-of-pointer-offset -verify %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -Wimplicit-widening-of-pointer-offset -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck --implicit-check-not="fix-it" %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -Wimplicit-widening-of-pointer-offset -verify -x c++ %s
+
+// RUN: %clang_cc1 -triple i686-linux-gnu   -fsyntax-only -Wimplicit-widening-of-pointer-offset -verify=silent %s
+// RUN: %clang_cc1 -triple i686-linux-gnu   -fsyntax-only -Wimplicit-widening-of-pointer-offset -verify=silent -x c++ %s
+
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -Wimplicit-widening-conversion -verify %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -Wall -verify %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -verify=silent %s
+
+// silent-no-diagnostics
+
+char *t0(char *base, int a, int b) {
+  return base + a * b; // #0
+  // expected-warning@#0 {{result of multiplication in type 'int' is used as a pointer offset after an implicit widening conversion to type 'ssize_t'}}
+  // expected-note@#0 {{make conversion explicit to silence this warning}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:17-[[@LINE-3]]:17}:"(ssize_t)("
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-4]]:21-[[@LINE-4]]:21}:")"
+  // expected-note@#0 {{perform multiplication in a wider type}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-6]]:17-[[@LINE-6]]:17}:"(ssize_t)"
+}
+char *t1(char *base, int a, int b) {
+  return a * b + base; // #1
+  // expected-warning@#1 {{result of multiplication in type 'int' is used as a pointer offset after an implicit widening conversion to type 'ssize_t'}}
+  // expected-note@#1 {{make conversion explicit to silence this warning}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:10-[[@LINE-3]]:10}:"(ssize_t)("
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-4]]:14-[[@LINE-4]]:14}:")"
+  // expected-note@#1 {{perform multiplication in a wider type}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-6]]:10-[[@LINE-6]]:10}:"(ssize_t)"
+}
+
+char *t2(char *base, unsigned int a, int b) {
+  return base + a * b; // #2
+  // expected-warning@#2 {{result of multiplication in type 'unsigned int' is used as a pointer offset after an implicit widening conversion to type 'size_t'}}
+  // expected-note@#2 {{make conversion explicit to silence this warning}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:17-[[@LINE-3]]:17}:"(size_t)("
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-4]]:21-[[@LINE-4]]:21}:")"
+  // expected-note@#2 {{perform multiplication in a wider 

[PATCH] D88905: [Clang] Allow "ext_vector_type" applied to Booleans

2020-12-26 Thread Kazushi Marukawa via Phabricator via cfe-commits
kaz7 added a comment.

We are using this patch in llvm/clang for VE and the patch is really helpful to 
implement intrinsic instructions using vector mask registers.  This works fine 
in backend since backend supports vXi1.  I wish people working on clang think 
this patch is reasonable.




Comment at: clang/docs/LanguageExtensions.rst:466
+  typedef bool bool4 __attribute__((ext_vector_type(4)));
+  // Objects of bool8 type hold 8 bits, sizeof(bool8) == 1
+

rsmith wrote:
> Comment talks about `bool8` but we defined the type `bool4`.
This is not fixed yet, `sizeof(bool8)`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88905

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


[PATCH] D93806: [clang-format] PR48569 clang-format fails to align case label with `switch` with Whitesmith Indentation

2020-12-26 Thread Marek Kurdej via Phabricator via cfe-commits
curdeius added a comment.

In D93806#2471738 , @MyDeveloperDay 
wrote:

> This is the closest I could find thus far 
> http://bitsavers.informatik.uni-stuttgart.de/pdf/chromatics/CGC_7900_C_Programmers_Manual_Mar82.pdf
>
> and the very  few examples from the manual show the case is aligned with the 
> switch
>
> F14838781: image.png 

Nice! Thank you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93806

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


[PATCH] D93806: [clang-format] PR48569 clang-format fails to align case label with `switch` with Whitesmith Indentation

2020-12-26 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.

This is the closest I could find thus far 
http://bitsavers.informatik.uni-stuttgart.de/pdf/chromatics/CGC_7900_C_Programmers_Manual_Mar82.pdf

and the very  few examples from the manual show the case is aligned with the 
switch

F14838781: image.png 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93806

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


[PATCH] D78058: option to write files to memory instead of disk

2020-12-26 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

@dexonsmith thanks for sharing!
Some initial thoughts since abstracting outputs is something we're starting to 
care about too...

This doesn't appear to be an extension point - you can write to an InMemoryFS 
or to real disk, but not to anything else. If we're going to add abstractions 
around output, I think they should support flexible use in libraries (which 
doesn't need to cost complexity here: FS vs MemoryFS vs custom storage can 
implement the same interface).
With the right interface, I think this obviates the need for RequestedOutput 
and generalizes it - a caller can install an intercepting output backend that 
hooks certain paths and delegates the rest to the old backend.
(Of course such a backend could be provided, but it gets the complexity out of 
the way of the core abstractions)

I think the lifecycle and allowed operations on outputs would be clearer if an 
`Output` class was returned, with methods, rather than a stream + handle and 
various "free" functions (well, methods on OutputManager) than manipulate the 
handle.
This would again make it easier to reason about what operations are part of a 
storage backend: there'd be some `OutputBackend` interface to implement, and it 
would hand out `Output` objects which again must be implemented. (This would be 
reminiscent of FileManager + vfs::FileSystem + vfs::File).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78058

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