[PATCH] D42530: Clang permits assignment to vector/extvector elements in a const method

[Andrew V. Tischenko via Phabricator via cfe-commits]

avt77 added a comment.

In https://reviews.llvm.org/D42530#995227, @rjmccall wrote:

> That's still just const-propagation.  The const qualifier on the pointee type 
> of this should propagate to the l-value resulting from the member access, and 
> the vector-specific projection logic should continue to propagate const to 
> the type of the element l-value.


I'm afraid it's wrong because from my point of view Clang generates wrong 
message for test OhNo3 (see err_typecheck_assign_const.cpp). It should not be  
"read-only variable is not assignable" because v[4] is not read-only variable. 
Any other non-const method is able to change this variable w/o any problems. 
The the same is for OhNo and OhNo2.

BTW, gcc generates

error: assignment of read-only location ‘*(const float*)(&((const 
OhNo2*)this)->OhNo2::v)’

and that's OK because we try to change the value through 
const-pointer-to-const. Am I right?


https://reviews.llvm.org/D42530



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

[PATCH] D42796: [clangd] Skip inline namespace when collecting scopes for index symbols.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clangd/index/SymbolCollector.cpp:74
+if (llvm::isa(Context) ||
+llvm::isa(Context))
+  break;

I may not know enough about the AST, sorry if the question is obvious.
`TranslationUnitDecl` is the root of the tree, but why should we stop at 
`LinkageSpecDecl`?

This code is probably going away per @hokein's comments.



Comment at: clangd/index/SymbolCollector.cpp:195
 llvm::SmallString<128> USR;
+if (ND->getIdentifier() == nullptr)
+  return true;

sammccall wrote:
> hokein wrote:
> > Consider moving to `shouldFilterDecl`? We also have a check `if 
> > (ND->getDeclName().isEmpty())` there, which I assume does similar thing. 
> hmm, what case is this handling? should `shouldFilterDecl` catch it?
Why do we skip names without identifiers? AFAIK, they are perfectly reasonable 
C++ entities: overloaded operators, constructors, etc. 


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D42796



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

[PATCH] D42755: [libcxx] Fix last_write_time tests for filesystems that don't support very small times.

[Jonas Hahnfeld via Phabricator via cfe-commits]

Hahnfeld resigned from this revision.
Hahnfeld added a comment.

In https://reviews.llvm.org/D42755#995593, @vsapsai wrote:

> Good suggestion for explaining the problem with `file_time_type::min()` in 
> more detail. Also PR35990  has 
> some details on how different filesystems handle `file_time_type::min()`. As 
> the change doesn't fix the PR, I don't think it is worth mentioning it in the 
> commit message but it can be still useful in code review discussion.


If there is an upstream bug report, please link to that one. With that 
information the changes look good, but I'd like @EricWF to accept.


https://reviews.llvm.org/D42755



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

[PATCH] D42810: [Sema] Add implicit members even for invalid CXXRecordDecls

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC324062: [Sema] Add implicit members even for invalid 
CXXRecordDecls (authored by ibiryukov, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D42810?vs=132443&id=132546#toc

Repository:
  rC Clang

https://reviews.llvm.org/D42810

Files:
  lib/Sema/SemaDecl.cpp
  test/Index/Inputs/crash-preamble-classes.h
  test/Index/crash-preamble-classes.cpp


Index: test/Index/Inputs/crash-preamble-classes.h
===
--- test/Index/Inputs/crash-preamble-classes.h
+++ test/Index/Inputs/crash-preamble-classes.h
@@ -0,0 +1,9 @@
+struct Incomplete;
+
+struct X : Incomplete {
+  X();
+};
+
+struct Y : X {
+  using X::X;
+};
Index: test/Index/crash-preamble-classes.cpp
===
--- test/Index/crash-preamble-classes.cpp
+++ test/Index/crash-preamble-classes.cpp
@@ -0,0 +1,8 @@
+#include "crash-preamble-classes.h"
+
+struct Z : Y {
+  Z() {}
+};
+
+// RUN: env CINDEXTEST_EDITING=1 \
+// RUN: c-index-test -test-load-source-reparse 5 local -I %S/Inputs %s
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -15440,10 +15440,10 @@
   CXXRecord->getDestructor());
 }
 
-if (!CXXRecord->isInvalidDecl()) {
-  // Add any implicitly-declared members to this class.
-  AddImplicitlyDeclaredMembersToClass(CXXRecord);
+// Add any implicitly-declared members to this class.
+AddImplicitlyDeclaredMembersToClass(CXXRecord);
 
+if (!CXXRecord->isInvalidDecl()) {
   // If we have virtual base classes, we may end up finding multiple
   // final overriders for a given virtual function. Check for this
   // problem now.


Index: test/Index/Inputs/crash-preamble-classes.h
===
--- test/Index/Inputs/crash-preamble-classes.h
+++ test/Index/Inputs/crash-preamble-classes.h
@@ -0,0 +1,9 @@
+struct Incomplete;
+
+struct X : Incomplete {
+  X();
+};
+
+struct Y : X {
+  using X::X;
+};
Index: test/Index/crash-preamble-classes.cpp
===
--- test/Index/crash-preamble-classes.cpp
+++ test/Index/crash-preamble-classes.cpp
@@ -0,0 +1,8 @@
+#include "crash-preamble-classes.h"
+
+struct Z : Y {
+  Z() {}
+};
+
+// RUN: env CINDEXTEST_EDITING=1 \
+// RUN: c-index-test -test-load-source-reparse 5 local -I %S/Inputs %s
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -15440,10 +15440,10 @@
   CXXRecord->getDestructor());
 }
 
-if (!CXXRecord->isInvalidDecl()) {
-  // Add any implicitly-declared members to this class.
-  AddImplicitlyDeclaredMembersToClass(CXXRecord);
+// Add any implicitly-declared members to this class.
+AddImplicitlyDeclaredMembersToClass(CXXRecord);
 
+if (!CXXRecord->isInvalidDecl()) {
   // If we have virtual base classes, we may end up finding multiple
   // final overriders for a given virtual function. Check for this
   // problem now.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r324062 - [Sema] Add implicit members even for invalid CXXRecordDecls

[Ilya Biryukov via cfe-commits]

Author: ibiryukov
Date: Fri Feb  2 00:40:08 2018
New Revision: 324062

URL: http://llvm.org/viewvc/llvm-project?rev=324062&view=rev
Log:
[Sema] Add implicit members even for invalid CXXRecordDecls

Summary:
It should be safe, since other code paths are already generating
implicit members even in invalid CXXRecordDecls (e.g. lookup).

If we don't generate implicit members on CXXRecordDecl's completion,
they will be generated by next lookup of constructors. This causes a
crash when the following conditions are met:
  - a CXXRecordDecl is invalid,
  - it is provided via ExternalASTSource (e.g. from PCH),
  - it has inherited constructors (they create ShadowDecls),
  - lookup of its constructors was not run before ASTWriter serialized
it.

This may require the ShadowDecls created for inherited constructors to
be removed from the class, but that's no longer possible since class is
provided by ExternalASTSource.

See provided lit test for an example.

Reviewers: bkramer

Reviewed By: bkramer

Subscribers: cfe-commits

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

Added:
cfe/trunk/test/Index/Inputs/crash-preamble-classes.h
cfe/trunk/test/Index/crash-preamble-classes.cpp
Modified:
cfe/trunk/lib/Sema/SemaDecl.cpp

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=324062&r1=324061&r2=324062&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Fri Feb  2 00:40:08 2018
@@ -15440,10 +15440,10 @@ void Sema::ActOnFields(Scope *S, SourceL
   CXXRecord->getDestructor());
 }
 
-if (!CXXRecord->isInvalidDecl()) {
-  // Add any implicitly-declared members to this class.
-  AddImplicitlyDeclaredMembersToClass(CXXRecord);
+// Add any implicitly-declared members to this class.
+AddImplicitlyDeclaredMembersToClass(CXXRecord);
 
+if (!CXXRecord->isInvalidDecl()) {
   // If we have virtual base classes, we may end up finding multiple
   // final overriders for a given virtual function. Check for this
   // problem now.

Added: cfe/trunk/test/Index/Inputs/crash-preamble-classes.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/Inputs/crash-preamble-classes.h?rev=324062&view=auto
==
--- cfe/trunk/test/Index/Inputs/crash-preamble-classes.h (added)
+++ cfe/trunk/test/Index/Inputs/crash-preamble-classes.h Fri Feb  2 00:40:08 
2018
@@ -0,0 +1,9 @@
+struct Incomplete;
+
+struct X : Incomplete {
+  X();
+};
+
+struct Y : X {
+  using X::X;
+};

Added: cfe/trunk/test/Index/crash-preamble-classes.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/crash-preamble-classes.cpp?rev=324062&view=auto
==
--- cfe/trunk/test/Index/crash-preamble-classes.cpp (added)
+++ cfe/trunk/test/Index/crash-preamble-classes.cpp Fri Feb  2 00:40:08 2018
@@ -0,0 +1,8 @@
+#include "crash-preamble-classes.h"
+
+struct Z : Y {
+  Z() {}
+};
+
+// RUN: env CINDEXTEST_EDITING=1 \
+// RUN: c-index-test -test-load-source-reparse 5 local -I %S/Inputs %s


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

[PATCH] D39571: [clangd] DidChangeConfiguration Notification

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clangd/ClangdLSPServer.cpp:302
 
+// FIXME: This function needs to be properly tested.
+void ClangdLSPServer::onChangeConfiguration(

simark wrote:
> simark wrote:
> > ilya-biryukov wrote:
> > > simark wrote:
> > > > simark wrote:
> > > > > ilya-biryukov wrote:
> > > > > > simark wrote:
> > > > > > > ilya-biryukov wrote:
> > > > > > > > simark wrote:
> > > > > > > > > ilya-biryukov wrote:
> > > > > > > > > > Are you planning to to address this FIXME before checking 
> > > > > > > > > > the code in?
> > > > > > > > > Following what you said here:
> > > > > > > > > 
> > > > > > > > > https://reviews.llvm.org/D39571?id=124024#inline-359345
> > > > > > > > > 
> > > > > > > > > I have not really looked into what was wrong with the test, 
> > > > > > > > > and what is missing in the infrastructure to make it work.  
> > > > > > > > > But I assumed that the situation did not change since then.  
> > > > > > > > > Can you enlighten me on what the problem was, and what is 
> > > > > > > > > missing?
> > > > > > > > We usually write unittests for that kind of thing, since they 
> > > > > > > > allow to plug an in-memory filesystem, but we only test 
> > > > > > > > `ClangdServer` (examples are in 
> > > > > > > > `unittests/clangd/ClangdTests.cpp`). `ClangdLSPServer` does not 
> > > > > > > > allow to plug in a virtual filesystem (vfs). Even if we add 
> > > > > > > > vfs, it's still hard to unit-test because we'll have to match 
> > > > > > > > the json input/output directly.
> > > > > > > > 
> > > > > > > > This leaves us with an option of a lit test that runs `clangd` 
> > > > > > > > directly, similar to tests in `test/clangd`.
> > > > > > > > The lit test would need to create a temporary directory, create 
> > > > > > > > proper `compile_commands.json` there, then send the LSP 
> > > > > > > > commands with the path to the test to clangd.
> > > > > > > > One major complication is that in LSP we have to specify the 
> > > > > > > > size of each message, but in our case the size would change 
> > > > > > > > depending on created temp path. It means we'll have to patch 
> > > > > > > > the test input to setup proper paths and message sizes.
> > > > > > > > If we choose to go down this path, 
> > > > > > > > `clang-tools-extra/test/clang-tidy/vfsoverlay.cpp` does a 
> > > > > > > > similar setup (create temp-dir, patch up some configuration 
> > > > > > > > files to point into the temp directory, etc) and could be used 
> > > > > > > > as a starting point.
> > > > > > > > 
> > > > > > > > It's not impossible to write that test, it's just a bit 
> > > > > > > > involved. Having a test would be nice, though, to ensure we 
> > > > > > > > don't break this method while doing other things. Especially 
> > > > > > > > given that this functionality is not used anywhere in clangd.
> > > > > > > > We usually write unittests for that kind of thing, since they 
> > > > > > > > allow to plug an in-memory filesystem, but we only test 
> > > > > > > > ClangdServer (examples are in 
> > > > > > > > unittests/clangd/ClangdTests.cpp). ClangdLSPServer does not 
> > > > > > > > allow to plug in a virtual filesystem (vfs). Even if we add 
> > > > > > > > vfs, it's still hard to unit-test because we'll have to match 
> > > > > > > > the json input/output directly.
> > > > > > > 
> > > > > > > What do you mean by "we'll have to match the json input/output 
> > > > > > > directly"?  That we'll have to match the complete JSON output 
> > > > > > > textually?  Couldn't the test parse the JSON into some data 
> > > > > > > structures, then we could assert specific things, like that this 
> > > > > > > particular field is present and contains a certain substring, for 
> > > > > > > example?
> > > > > > > 
> > > > > > > > This leaves us with an option of a lit test that runs clangd 
> > > > > > > > directly, similar to tests in test/clangd.
> > > > > > > > The lit test would need to create a temporary directory, create 
> > > > > > > > proper compile_commands.json there, then send the LSP commands 
> > > > > > > > with the path to the test to clangd.
> > > > > > > > One major complication is that in LSP we have to specify the 
> > > > > > > > size of each message, but in our case the size would change 
> > > > > > > > depending on created temp path. It means we'll have to patch 
> > > > > > > > the test input to setup proper paths and message sizes.
> > > > > > > > If we choose to go down this path, 
> > > > > > > > clang-tools-extra/test/clang-tidy/vfsoverlay.cpp does a similar 
> > > > > > > > setup (create temp-dir, patch up some configuration files to 
> > > > > > > > point into the temp directory, etc) and could be used as a 
> > > > > > > > starting point.
> > > > > > > 
> > > > > > > Ok, I see the complication with the Content-Length.  I am not 
> > > > > > > familiar with lit yet, so I don't know what it is capable of.  
> > > > > > > But being able to

[PATCH] D42812: [clang-tidy] ObjC ARC objects should not trigger performance-unnecessary-value-param

[Haojian Wu via Phabricator via cfe-commits]

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

LGTM


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D42812



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

[clang-tools-extra] r324065 - [clangd] Skip inline namespace when collecting scopes for index symbols.

[Eric Liu via cfe-commits]

Author: ioeric
Date: Fri Feb  2 02:31:42 2018
New Revision: 324065

URL: http://llvm.org/viewvc/llvm-project?rev=324065&view=rev
Log:
[clangd] Skip inline namespace when collecting scopes for index symbols.

Summary:
Some STL symbols are defined in inline namespaces. For example,
```
namespace std {
inline namespace __cxx11 {
 typedef ... string;
}
}
```
Currently, this will be `std::__cxx11::string`; however, `std::string` is 
desired.

Inline namespaces are treated as transparent scopes. This
reflects the way they're most commonly used for lookup. Ideally we'd
include them, but at query time it's hard to find all the inline
namespaces to query: the preamble doesn't have a dedicated list.

Reviewers: sammccall, hokein

Reviewed By: sammccall

Subscribers: klimek, ilya-biryukov, jkorous-apple, cfe-commits

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

Modified:
clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp
clang-tools-extra/trunk/unittests/clangd/SymbolCollectorTests.cpp

Modified: clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp?rev=324065&r1=324064&r2=324065&view=diff
==
--- clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp (original)
+++ clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp Fri Feb  2 
02:31:42 2018
@@ -9,6 +9,7 @@
 
 #include "SymbolCollector.h"
 #include "../CodeCompletionStrings.h"
+#include "Logger.h"
 #include "clang/AST/DeclCXX.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/Basic/SourceManager.h"
@@ -97,8 +98,8 @@ bool shouldFilterDecl(const NamedDecl *N
   //   * symbols in namespaces or translation unit scopes (e.g. no class
   // members)
   //   * enum constants in unscoped enum decl (e.g. "red" in "enum {red};")
-  auto InTopLevelScope =
-  hasDeclContext(anyOf(namespaceDecl(), translationUnitDecl()));
+  auto InTopLevelScope = hasDeclContext(
+  anyOf(namespaceDecl(), translationUnitDecl(), linkageSpecDecl()));
   if (match(decl(allOf(Opts.IndexMainFiles
? decl()
: decl(unless(isExpansionInMainFile())),
@@ -180,7 +181,17 @@ bool SymbolCollector::handleDeclOccurenc
   return true;
 
 auto &SM = ND->getASTContext().getSourceManager();
-std::string QName = ND->getQualifiedNameAsString();
+
+std::string QName;
+llvm::raw_string_ostream OS(QName);
+PrintingPolicy Policy(ASTCtx->getLangOpts());
+// Note that inline namespaces are treated as transparent scopes. This
+// reflects the way they're most commonly used for lookup. Ideally we'd
+// include them, but at query time it's hard to find all the inline
+// namespaces to query: the preamble doesn't have a dedicated list.
+Policy.SuppressUnwrittenScope = true;
+ND->printQualifiedName(OS, Policy);
+OS.flush();
 
 Symbol S;
 S.ID = std::move(ID);

Modified: clang-tools-extra/trunk/unittests/clangd/SymbolCollectorTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clangd/SymbolCollectorTests.cpp?rev=324065&r1=324064&r2=324065&view=diff
==
--- clang-tools-extra/trunk/unittests/clangd/SymbolCollectorTests.cpp (original)
+++ clang-tools-extra/trunk/unittests/clangd/SymbolCollectorTests.cpp Fri Feb  
2 02:31:42 2018
@@ -198,8 +198,7 @@ TEST_F(SymbolCollectorTest, IncludeEnums
   runSymbolCollector(Header, /*Main=*/"");
   EXPECT_THAT(Symbols, UnorderedElementsAre(QName("Red"), QName("Color"),
 QName("Green"), QName("Color2"),
-QName("ns"),
-QName("ns::Black")));
+QName("ns"), QName("ns::Black")));
 }
 
 TEST_F(SymbolCollectorTest, IgnoreNamelessSymbols) {
@@ -321,6 +320,53 @@ TEST_F(SymbolCollectorTest, IgnoreClassM
   EXPECT_THAT(Symbols, UnorderedElementsAre(QName("Foo")));
 }
 
+TEST_F(SymbolCollectorTest, Scopes) {
+  const std::string Header = R"(
+namespace na {
+class Foo {};
+namespace nb {
+class Bar {};
+}
+}
+  )";
+  runSymbolCollector(Header, /*Main=*/"");
+  EXPECT_THAT(Symbols,
+  UnorderedElementsAre(QName("na"), QName("na::nb"),
+   QName("na::Foo"), QName("na::nb::Bar")));
+}
+
+TEST_F(SymbolCollectorTest, ExternC) {
+  const std::string Header = R"(
+extern "C" { class Foo {}; }
+namespace na {
+extern "C" { class Bar {}; }
+}
+  )";
+  runSymbolCollector(Header, /*Main=*/"");
+  EXPECT_THAT(Symbols,
+  UnorderedElementsAre(QName("na"), QName("Foo"), QName("Bar")));
+}
+
+TEST_F(SymbolCollectorTest, SkipInlineNamespace) {
+  const std::string Header = R"(
+namespace na {
+i

[PATCH] D42796: [clangd] Skip inline namespace when collecting scopes for index symbols.

[Eric Liu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL324065: [clangd] Skip inline namespace when collecting 
scopes for index symbols. (authored by ioeric, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

https://reviews.llvm.org/D42796

Files:
  clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp
  clang-tools-extra/trunk/unittests/clangd/SymbolCollectorTests.cpp

Index: clang-tools-extra/trunk/unittests/clangd/SymbolCollectorTests.cpp
===
--- clang-tools-extra/trunk/unittests/clangd/SymbolCollectorTests.cpp
+++ clang-tools-extra/trunk/unittests/clangd/SymbolCollectorTests.cpp
@@ -198,8 +198,7 @@
   runSymbolCollector(Header, /*Main=*/"");
   EXPECT_THAT(Symbols, UnorderedElementsAre(QName("Red"), QName("Color"),
 QName("Green"), QName("Color2"),
-QName("ns"),
-QName("ns::Black")));
+QName("ns"), QName("ns::Black")));
 }
 
 TEST_F(SymbolCollectorTest, IgnoreNamelessSymbols) {
@@ -321,6 +320,53 @@
   EXPECT_THAT(Symbols, UnorderedElementsAre(QName("Foo")));
 }
 
+TEST_F(SymbolCollectorTest, Scopes) {
+  const std::string Header = R"(
+namespace na {
+class Foo {};
+namespace nb {
+class Bar {};
+}
+}
+  )";
+  runSymbolCollector(Header, /*Main=*/"");
+  EXPECT_THAT(Symbols,
+  UnorderedElementsAre(QName("na"), QName("na::nb"),
+   QName("na::Foo"), QName("na::nb::Bar")));
+}
+
+TEST_F(SymbolCollectorTest, ExternC) {
+  const std::string Header = R"(
+extern "C" { class Foo {}; }
+namespace na {
+extern "C" { class Bar {}; }
+}
+  )";
+  runSymbolCollector(Header, /*Main=*/"");
+  EXPECT_THAT(Symbols,
+  UnorderedElementsAre(QName("na"), QName("Foo"), QName("Bar")));
+}
+
+TEST_F(SymbolCollectorTest, SkipInlineNamespace) {
+  const std::string Header = R"(
+namespace na {
+inline namespace nb {
+class Foo {};
+}
+}
+namespace na {
+// This is still inlined.
+namespace nb {
+class Bar {};
+}
+}
+  )";
+  runSymbolCollector(Header, /*Main=*/"");
+  EXPECT_THAT(Symbols,
+  UnorderedElementsAre(QName("na"), QName("na::nb"),
+   QName("na::Foo"), QName("na::Bar")));
+}
+
 TEST_F(SymbolCollectorTest, SymbolWithDocumentation) {
   const std::string Header = R"(
 namespace nx {
Index: clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp
===
--- clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp
+++ clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp
@@ -9,6 +9,7 @@
 
 #include "SymbolCollector.h"
 #include "../CodeCompletionStrings.h"
+#include "Logger.h"
 #include "clang/AST/DeclCXX.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/Basic/SourceManager.h"
@@ -97,8 +98,8 @@
   //   * symbols in namespaces or translation unit scopes (e.g. no class
   // members)
   //   * enum constants in unscoped enum decl (e.g. "red" in "enum {red};")
-  auto InTopLevelScope =
-  hasDeclContext(anyOf(namespaceDecl(), translationUnitDecl()));
+  auto InTopLevelScope = hasDeclContext(
+  anyOf(namespaceDecl(), translationUnitDecl(), linkageSpecDecl()));
   if (match(decl(allOf(Opts.IndexMainFiles
? decl()
: decl(unless(isExpansionInMainFile())),
@@ -180,7 +181,17 @@
   return true;
 
 auto &SM = ND->getASTContext().getSourceManager();
-std::string QName = ND->getQualifiedNameAsString();
+
+std::string QName;
+llvm::raw_string_ostream OS(QName);
+PrintingPolicy Policy(ASTCtx->getLangOpts());
+// Note that inline namespaces are treated as transparent scopes. This
+// reflects the way they're most commonly used for lookup. Ideally we'd
+// include them, but at query time it's hard to find all the inline
+// namespaces to query: the preamble doesn't have a dedicated list.
+Policy.SuppressUnwrittenScope = true;
+ND->printQualifiedName(OS, Policy);
+OS.flush();
 
 Symbol S;
 S.ID = std::move(ID);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42730: [clang-tidy]] Add check for use of types/classes/functions from header which are deprecated and removed in C++17

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh added inline comments.



Comment at: clang-tidy/modernize/AvoidFunctionalCheck.cpp:22
+  Finder->addMatcher(
+  cxxRecordDecl(allOf(anyOf(isDerivedFrom("std::binary_function"),
+isDerivedFrom("std::unary_function")),

aaron.ballman wrote:
> These should all be `::std::` instead of `std::` to cover pathological code 
> that puts `std` inside of another namespace.
Could you change the names to "::std" again, since my suggested code didn't 
take this comment into account?



Comment at: clang-tidy/modernize/AvoidFunctionalCheck.h:19
+
+/// Check for several deprecated types and classes from  header
+///

aaron.ballman wrote:
> alexfh wrote:
> > aaron.ballman wrote:
> > > alexfh wrote:
> > > > Quuxplusone wrote:
> > > > > aaron.ballman wrote:
> > > > > > alexfh wrote:
> > > > > > > alexfh wrote:
> > > > > > > > aaron.ballman wrote:
> > > > > > > > > massberg wrote:
> > > > > > > > > > massberg wrote:
> > > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > > Missing full stop at the end of the sentence.
> > > > > > > > > > > > 
> > > > > > > > > > > > Why should this modernize check be limited to 
> > > > > > > > > > > > ``? Just like we have a "deprecated 
> > > > > > > > > > > > headers" check, perhaps this should be a "deprecated 
> > > > > > > > > > > > APIs" check?
> > > > > > > > > > > Added full stop.
> > > > > > > > > > > 
> > > > > > > > > > > I'm not sure if this check should be limited to 
> > > > > > > > > > >  or be extended to a full 'deprecated API' 
> > > > > > > > > > > check.
> > > > > > > > > > > This change is just a start, several more types and 
> > > > > > > > > > > classes which are removed from  will follow, 
> > > > > > > > > > > e.g:
> > > > > > > > > > > 
> > > > > > > > > > > - std::ptr_fun, std::mem_fun, std::mem_fun_ref
> > > > > > > > > > > - std::bind1st, std::bind2nd
> > > > > > > > > > > - std::unary_function, std::binary_function
> > > > > > > > > > > - std::pointer_to_unary_function, 
> > > > > > > > > > > std::pointer_to_binary_function, std::mem_fun_t, 
> > > > > > > > > > > std::mem_fun1_t, std::const_mem_fun_t, 
> > > > > > > > > > > - std::const_mem_fun1_t, std::mem_fun_ref_t, 
> > > > > > > > > > > std::mem_fun1_ref_t, std::const_mem_fun_ref_t, 
> > > > > > > > > > > std::const_mem_fun1_ref_t
> > > > > > > > > > > - std::binder1st, std::binder2nd
> > > > > > > > > > > 
> > > > > > > > > > > As these are a bunch of functions and types, in my eyes a 
> > > > > > > > > > > check just for  is fine. But I'm also fine 
> > > > > > > > > > > with a general 'deprecated API' check.
> > > > > > > > > > > Alex, can you comment on this?
> > > > > > > > > > There are already other checks for functions which are 
> > > > > > > > > > removed in C++17 like modernize-replace-random-shuffle.
> > > > > > > > > > So I think having an separate check for functions and types 
> > > > > > > > > > removed from  would be OK.
> > > > > > > > > You've hit the nail on the head for what I'm trying to avoid 
> > > > > > > > > -- we shouldn't have multiple checks unless they do 
> > > > > > > > > drastically different things. Having a deprecated check like 
> > > > > > > > > this really only makes sense for APIs that are deprecated but 
> > > > > > > > > aren't uniformly marked as `[[deprecated]]` by the library. 
> > > > > > > > > As such, I think we really only need one check for this 
> > > > > > > > > rather than splitting it out over multiple checks -- the 
> > > > > > > > > existing check functionality could be rolled into this one 
> > > > > > > > > and its check become an alias.
> > > > > > > > > I'm not sure if this check should be limited to  
> > > > > > > > > or be extended to a full 'deprecated API' check.
> > > > > > > > 
> > > > > > > > IIUC, it should be possible to implement fixits at least for 
> > > > > > > > some use cases here. My impression was that Jens was at least 
> > > > > > > > considering to work on fixits. The other check mentioned here - 
> > > > > > > > `modernize-replace-random-shuffle` already implements fixits. 
> > > > > > > > Fixits are specific to the API and some codebases may have 
> > > > > > > > better replacement APIs than what the standard suggests, so 
> > > > > > > > different users may want to apply different set of the fixes. 
> > > > > > > > Given all that, I wouldn't just merge all of the checks dealing 
> > > > > > > > with deprecated APIs. Splitting them at least by header seems 
> > > > > > > > like a good start, maybe even finer granularity may be needed 
> > > > > > > > in some cases.
> > > > > > > TL;DR "they do drastically different things" is the case for this 
> > > > > > > check and modernize-replace-random-shuffle.
> > > > > > I disagree that they do drastically different things or that 
> > > > > > fix-its are a problem. Some of these APIs have replacements, others 
> > > > > > do not. At the end of the day, the basics are t

[PATCH] D42796: [clangd] Skip inline namespace when collecting scopes for index symbols.

[Eric Liu via Phabricator via cfe-commits]

ioeric updated this revision to Diff 132552.
ioeric added a comment.

- clang-format


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D42796

Files:
  clangd/index/SymbolCollector.cpp
  unittests/clangd/SymbolCollectorTests.cpp

Index: unittests/clangd/SymbolCollectorTests.cpp
===
--- unittests/clangd/SymbolCollectorTests.cpp
+++ unittests/clangd/SymbolCollectorTests.cpp
@@ -201,8 +201,7 @@
   runSymbolCollector(Header, /*Main=*/"");
   EXPECT_THAT(Symbols, UnorderedElementsAre(QName("Red"), QName("Color"),
 QName("Green"), QName("Color2"),
-QName("ns"),
-QName("ns::Black")));
+QName("ns"), QName("ns::Black")));
 }
 
 TEST_F(SymbolCollectorTest, IgnoreNamelessSymbols) {
@@ -324,6 +323,53 @@
   EXPECT_THAT(Symbols, UnorderedElementsAre(QName("Foo")));
 }
 
+TEST_F(SymbolCollectorTest, Scopes) {
+  const std::string Header = R"(
+namespace na {
+class Foo {};
+namespace nb {
+class Bar {};
+}
+}
+  )";
+  runSymbolCollector(Header, /*Main=*/"");
+  EXPECT_THAT(Symbols,
+  UnorderedElementsAre(QName("na"), QName("na::nb"),
+   QName("na::Foo"), QName("na::nb::Bar")));
+}
+
+TEST_F(SymbolCollectorTest, ExternC) {
+  const std::string Header = R"(
+extern "C" { class Foo {}; }
+namespace na {
+extern "C" { class Bar {}; }
+}
+  )";
+  runSymbolCollector(Header, /*Main=*/"");
+  EXPECT_THAT(Symbols,
+  UnorderedElementsAre(QName("na"), QName("Foo"), QName("Bar")));
+}
+
+TEST_F(SymbolCollectorTest, SkipInlineNamespace) {
+  const std::string Header = R"(
+namespace na {
+inline namespace nb {
+class Foo {};
+}
+}
+namespace na {
+// This is still inlined.
+namespace nb {
+class Bar {};
+}
+}
+  )";
+  runSymbolCollector(Header, /*Main=*/"");
+  EXPECT_THAT(Symbols,
+  UnorderedElementsAre(QName("na"), QName("na::nb"),
+   QName("na::Foo"), QName("na::Bar")));
+}
+
 TEST_F(SymbolCollectorTest, SymbolWithDocumentation) {
   const std::string Header = R"(
 namespace nx {
Index: clangd/index/SymbolCollector.cpp
===
--- clangd/index/SymbolCollector.cpp
+++ clangd/index/SymbolCollector.cpp
@@ -9,6 +9,7 @@
 
 #include "SymbolCollector.h"
 #include "../CodeCompletionStrings.h"
+#include "Logger.h"
 #include "clang/AST/DeclCXX.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/Basic/SourceManager.h"
@@ -97,8 +98,8 @@
   //   * symbols in namespaces or translation unit scopes (e.g. no class
   // members)
   //   * enum constants in unscoped enum decl (e.g. "red" in "enum {red};")
-  auto InTopLevelScope =
-  hasDeclContext(anyOf(namespaceDecl(), translationUnitDecl()));
+  auto InTopLevelScope = hasDeclContext(
+  anyOf(namespaceDecl(), translationUnitDecl(), linkageSpecDecl()));
   if (match(decl(allOf(Opts.IndexMainFiles
? decl()
: decl(unless(isExpansionInMainFile())),
@@ -180,7 +181,17 @@
   return true;
 
 auto &SM = ND->getASTContext().getSourceManager();
-std::string QName = ND->getQualifiedNameAsString();
+
+std::string QName;
+llvm::raw_string_ostream OS(QName);
+PrintingPolicy Policy(ASTCtx->getLangOpts());
+// Note that inline namespaces are treated as transparent scopes. This
+// reflects the way they're most commonly used for lookup. Ideally we'd
+// include them, but at query time it's hard to find all the inline
+// namespaces to query: the preamble doesn't have a dedicated list.
+Policy.SuppressUnwrittenScope = true;
+ND->printQualifiedName(OS, Policy);
+OS.flush();
 
 Symbol S;
 S.ID = std::move(ID);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42796: [clangd] Skip inline namespace when collecting scopes for index symbols.

[Eric Liu via Phabricator via cfe-commits]

ioeric added inline comments.



Comment at: clangd/index/SymbolCollector.cpp:69
+// qualifier. Inline namespaces and unscoped enums are skipped.
+llvm::Expected getScope(const NamedDecl *ND) {
+  llvm::SmallVector Contexts;

hokein wrote:
> There is a `SuppressUnwrittenScope` option in `PrintingPolicy`,  I think we 
> can probably use `printQualifiedName` with our customized policy (setting 
> `SuppressUnwrittenScope` to true) here.
This is perfect! Thank you!



Comment at: clangd/index/SymbolCollector.cpp:73
+   Context = Context->getParent()) {
+if (llvm::isa(Context) ||
+llvm::isa(Context))

sammccall wrote:
> I'm not sure this is always correct: at least clang accepts this code:
> 
>   namespace X { extern "C++" { int y; }}
> 
> and you'll emit "y" instead of "X::y".
> 
> I think the check you want is
> 
>   if (Context->isTransparentContext() || Context->isInlineNamespace())
> continue;
> 
>  isTransparentContext will handle the Namespace and Enum cases as you do 
> below, including the enum/enum class distinction.
> 
> (The code you have below is otherwise correct, I think - but a reader needs 
> to think about more separate cases in order to see that)
In `namespace X { extern "C++" { int y; }}`, we would still want `y` instead of 
`X::y` since C-style symbol doesn't have scope. `printQualifiedName` also does 
the same thing printing `y`; I've added a test case for `extern C`.

I also realized we've been dropping C symbols in `shouldFilterDecl` and fixed 
it in the same patch.



Comment at: clangd/index/SymbolCollector.cpp:74
+if (llvm::isa(Context) ||
+llvm::isa(Context))
+  break;

ilya-biryukov wrote:
> I may not know enough about the AST, sorry if the question is obvious.
> `TranslationUnitDecl` is the root of the tree, but why should we stop at 
> `LinkageSpecDecl`?
> 
> This code is probably going away per @hokein's comments.
Symbols in `LinkageSpecDecl` (i.e. `extern "C"`) are C style symbols and do not 
have scopes. Also see my reply to Sam's related comment.



Comment at: clangd/index/SymbolCollector.cpp:195
 llvm::SmallString<128> USR;
+if (ND->getIdentifier() == nullptr)
+  return true;

ilya-biryukov wrote:
> sammccall wrote:
> > hokein wrote:
> > > Consider moving to `shouldFilterDecl`? We also have a check `if 
> > > (ND->getDeclName().isEmpty())` there, which I assume does similar thing. 
> > hmm, what case is this handling? should `shouldFilterDecl` catch it?
> Why do we skip names without identifiers? AFAIK, they are perfectly 
> reasonable C++ entities: overloaded operators, constructors, etc. 
`getName` crashes for `NamedDecl` without identifier. I thought symbols without 
identifier are not interesting for global code completion, so I added this 
filter to avoid crash. But on a second thought, these symbols would still be 
useful for go-to-definition, for example. 

This is no longer needed with `printQualifiedName` though.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D42796



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

[PATCH] D42796: [clangd] Skip inline namespace when collecting scopes for index symbols.

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clangd/index/SymbolCollector.cpp:73
+   Context = Context->getParent()) {
+if (llvm::isa(Context) ||
+llvm::isa(Context))

ioeric wrote:
> sammccall wrote:
> > I'm not sure this is always correct: at least clang accepts this code:
> > 
> >   namespace X { extern "C++" { int y; }}
> > 
> > and you'll emit "y" instead of "X::y".
> > 
> > I think the check you want is
> > 
> >   if (Context->isTransparentContext() || Context->isInlineNamespace())
> > continue;
> > 
> >  isTransparentContext will handle the Namespace and Enum cases as you do 
> > below, including the enum/enum class distinction.
> > 
> > (The code you have below is otherwise correct, I think - but a reader needs 
> > to think about more separate cases in order to see that)
> In `namespace X { extern "C++" { int y; }}`, we would still want `y` instead 
> of `X::y` since C-style symbol doesn't have scope. `printQualifiedName` also 
> does the same thing printing `y`; I've added a test case for `extern C`.
> 
> I also realized we've been dropping C symbols in `shouldFilterDecl` and fixed 
> it in the same patch.
I think we want `X::y`, not `y`.

Lookup still finds it inside the namespace and does not find it in the global 
scope. So for our purposes they are actually inside the namespace and have the 
qualified name of this namespace. Here's an example:
```
namespace ns {
extern "C" int foo();
}

void test() {
  ns::foo(); // ok
  foo(); // error
  ::foo(); // error
}
```

Note, however, that the tricky bit there is probably merging of the symbols, as 
it means symbols with the same USR (they are the same for all `extern "c"` 
declarations with the same name, right?) can have different qualified names and 
we won't know which one to choose.

```
namespace a {
 extern "C" int foo();
}
namespace b {
  extern "C" int foo(); // probably same USR, different qname. Also, possibly 
different types.
}
```


Repository:
  rL LLVM

https://reviews.llvm.org/D42796



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

[PATCH] D42840: [docs] Fix duplicate arguments for JoinedAndSeparate

[Jonas Hahnfeld via Phabricator via cfe-commits]

Hahnfeld created this revision.
Hahnfeld added reviewers: rsmith, craig.topper.
Herald added a subscriber: cfe-commits.

We can't see how many arguments are in the meta var name, so just
assume that is the right number.


Repository:
  rC Clang

https://reviews.llvm.org/D42840

Files:
  utils/TableGen/ClangOptionDocEmitter.cpp


Index: utils/TableGen/ClangOptionDocEmitter.cpp
===
--- utils/TableGen/ClangOptionDocEmitter.cpp
+++ utils/TableGen/ClangOptionDocEmitter.cpp
@@ -245,19 +245,27 @@
 void emitOptionName(StringRef Prefix, const Record *Option, raw_ostream &OS) {
   // Find the arguments to list after the option.
   unsigned NumArgs = getNumArgsForKind(Option->getValueAsDef("Kind"), Option);
+  bool HasMetaVarName = !Option->isValueUnset("MetaVarName");
 
   std::vector Args;
-  if (!Option->isValueUnset("MetaVarName"))
+  if (HasMetaVarName)
 Args.push_back(Option->getValueAsString("MetaVarName"));
   else if (NumArgs == 1)
 Args.push_back("");
 
-  while (Args.size() < NumArgs) {
-Args.push_back(("").str());
-// Use '--args  ...' if any number of args are allowed.
-if (Args.size() == 2 && NumArgs == UnlimitedArgs) {
-  Args.back() += "...";
-  break;
+  // Fill up arguments if this option didn't provide a meta var name or it
+  // supports an unlimited number of arguments. We can't see how many arguments
+  // already are in a meta var name, so assume it has right number. This is
+  // needed for JoinedAndSeparate options so that there arent't too many
+  // arguments.
+  if (!HasMetaVarName || NumArgs == UnlimitedArgs) {
+while (Args.size() < NumArgs) {
+  Args.push_back(("").str());
+  // Use '--args  ...' if any number of args are allowed.
+  if (Args.size() == 2 && NumArgs == UnlimitedArgs) {
+Args.back() += "...";
+break;
+  }
 }
   }
 


Index: utils/TableGen/ClangOptionDocEmitter.cpp
===
--- utils/TableGen/ClangOptionDocEmitter.cpp
+++ utils/TableGen/ClangOptionDocEmitter.cpp
@@ -245,19 +245,27 @@
 void emitOptionName(StringRef Prefix, const Record *Option, raw_ostream &OS) {
   // Find the arguments to list after the option.
   unsigned NumArgs = getNumArgsForKind(Option->getValueAsDef("Kind"), Option);
+  bool HasMetaVarName = !Option->isValueUnset("MetaVarName");
 
   std::vector Args;
-  if (!Option->isValueUnset("MetaVarName"))
+  if (HasMetaVarName)
 Args.push_back(Option->getValueAsString("MetaVarName"));
   else if (NumArgs == 1)
 Args.push_back("");
 
-  while (Args.size() < NumArgs) {
-Args.push_back(("").str());
-// Use '--args  ...' if any number of args are allowed.
-if (Args.size() == 2 && NumArgs == UnlimitedArgs) {
-  Args.back() += "...";
-  break;
+  // Fill up arguments if this option didn't provide a meta var name or it
+  // supports an unlimited number of arguments. We can't see how many arguments
+  // already are in a meta var name, so assume it has right number. This is
+  // needed for JoinedAndSeparate options so that there arent't too many
+  // arguments.
+  if (!HasMetaVarName || NumArgs == UnlimitedArgs) {
+while (Args.size() < NumArgs) {
+  Args.push_back(("").str());
+  // Use '--args  ...' if any number of args are allowed.
+  if (Args.size() == 2 && NumArgs == UnlimitedArgs) {
+Args.back() += "...";
+break;
+  }
 }
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r323155 - Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target

[Hans Wennborg via cfe-commits]

Thanks! I've merged them to 6.0 as below and they will be part of rc2,
scheduled for next week.

Chandler, do you want to write release notes for this?

On Thu, Feb 1, 2018 at 8:09 PM, Chandler Carruth  wrote:
> +Hans Wennborg +tstel...@redhat.com
>
> So the retpoline patch series we should get back ported start with this
> revision and have two follow ups:
> r323155

Merged in r324067 (llvm), r324068 (cfe), r324069 (lld)

> r323288

Merged in r324070.

> r323915

Merged in r324071.

>
> +Reid Kleckner was going to look at doing the (likely more involved)
> backport to the 5 branch
>
> On Mon, Jan 22, 2018 at 2:06 PM Chandler Carruth via cfe-commits
>  wrote:
>>
>> Author: chandlerc
>> Date: Mon Jan 22 14:05:25 2018
>> New Revision: 323155
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=323155&view=rev
>> Log:
>> Introduce the "retpoline" x86 mitigation technique for variant #2 of the
>> speculative execution vulnerabilities disclosed today, specifically
>> identified by CVE-2017-5715, "Branch Target Injection", and is one of the
>> two halves to Spectre..
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42796: [clangd] Skip inline namespace when collecting scopes for index symbols.

[Eric Liu via Phabricator via cfe-commits]

ioeric updated this revision to Diff 132549.
ioeric marked 2 inline comments as done.
ioeric edited the summary of this revision.
ioeric added a comment.

Addressed review comments.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D42796

Files:
  clangd/index/SymbolCollector.cpp
  unittests/clangd/SymbolCollectorTests.cpp

Index: unittests/clangd/SymbolCollectorTests.cpp
===
--- unittests/clangd/SymbolCollectorTests.cpp
+++ unittests/clangd/SymbolCollectorTests.cpp
@@ -201,8 +201,7 @@
   runSymbolCollector(Header, /*Main=*/"");
   EXPECT_THAT(Symbols, UnorderedElementsAre(QName("Red"), QName("Color"),
 QName("Green"), QName("Color2"),
-QName("ns"),
-QName("ns::Black")));
+QName("ns"), QName("ns::Black")));
 }
 
 TEST_F(SymbolCollectorTest, IgnoreNamelessSymbols) {
@@ -324,6 +323,53 @@
   EXPECT_THAT(Symbols, UnorderedElementsAre(QName("Foo")));
 }
 
+TEST_F(SymbolCollectorTest, Scopes) {
+  const std::string Header = R"(
+namespace na {
+class Foo {};
+namespace nb {
+class Bar {};
+}
+}
+  )";
+  runSymbolCollector(Header, /*Main=*/"");
+  EXPECT_THAT(Symbols,
+  UnorderedElementsAre(QName("na"), QName("na::nb"),
+   QName("na::Foo"), QName("na::nb::Bar")));
+}
+
+TEST_F(SymbolCollectorTest, ExternC) {
+  const std::string Header = R"(
+extern "C" { class Foo {}; }
+namespace na {
+extern "C" { class Bar {}; }
+}
+  )";
+  runSymbolCollector(Header, /*Main=*/"");
+  EXPECT_THAT(Symbols, UnorderedElementsAre(QName("na"), QName("Foo"),
+QName("Bar")));
+}
+
+TEST_F(SymbolCollectorTest, SkipInlineNamespace) {
+  const std::string Header = R"(
+namespace na {
+inline namespace nb {
+class Foo {};
+}
+}
+namespace na {
+// This is still inlined.
+namespace nb {
+class Bar {};
+}
+}
+  )";
+  runSymbolCollector(Header, /*Main=*/"");
+  EXPECT_THAT(Symbols,
+  UnorderedElementsAre(QName("na"), QName("na::nb"),
+   QName("na::Foo"), QName("na::Bar")));
+}
+
 TEST_F(SymbolCollectorTest, SymbolWithDocumentation) {
   const std::string Header = R"(
 namespace nx {
Index: clangd/index/SymbolCollector.cpp
===
--- clangd/index/SymbolCollector.cpp
+++ clangd/index/SymbolCollector.cpp
@@ -9,6 +9,7 @@
 
 #include "SymbolCollector.h"
 #include "../CodeCompletionStrings.h"
+#include "Logger.h"
 #include "clang/AST/DeclCXX.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/Basic/SourceManager.h"
@@ -97,8 +98,8 @@
   //   * symbols in namespaces or translation unit scopes (e.g. no class
   // members)
   //   * enum constants in unscoped enum decl (e.g. "red" in "enum {red};")
-  auto InTopLevelScope =
-  hasDeclContext(anyOf(namespaceDecl(), translationUnitDecl()));
+  auto InTopLevelScope = hasDeclContext(
+  anyOf(namespaceDecl(), translationUnitDecl(), linkageSpecDecl()));
   if (match(decl(allOf(Opts.IndexMainFiles
? decl()
: decl(unless(isExpansionInMainFile())),
@@ -180,7 +181,17 @@
   return true;
 
 auto &SM = ND->getASTContext().getSourceManager();
-std::string QName = ND->getQualifiedNameAsString();
+
+std::string QName;
+llvm::raw_string_ostream OS(QName);
+PrintingPolicy Policy(ASTCtx->getLangOpts());
+// Note that inline namespaces are treated as transparent scopes. This
+// reflects the way they're most commonly used for lookup. Ideally we'd
+// include them, but at query time it's hard to find all the inline
+// namespaces to query: the preamble doesn't have a dedicated list.
+Policy.SuppressUnwrittenScope = true;
+ND->printQualifiedName(OS, Policy);
+OS.flush();
 
 Symbol S;
 S.ID = std::move(ID);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42841: [docs] Improve help for OpenMP options

[Jonas Hahnfeld via Phabricator via cfe-commits]

Hahnfeld created this revision.
Hahnfeld added reviewers: ABataev, gtbercea.
Herald added subscribers: cfe-commits, guansong.

- Add HelpText for -fopenmp so that it appears in clang --help.
- Hide -fopenmp-relocatable-target from there.
- Hide -fno-openmp-simd, other options only list the positive argument.
- Improve MetaVarName for -Xopenmp-target=<...> (depends on 
https://reviews.llvm.org/D42840)


Repository:
  rC Clang

https://reviews.llvm.org/D42841

Files:
  include/clang/Driver/Options.td


Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -466,7 +466,8 @@
 def Xopenmp_target : Separate<["-"], "Xopenmp-target">,
   HelpText<"Pass  to the target offloading toolchain.">, 
MetaVarName<"">;
 def Xopenmp_target_EQ : JoinedAndSeparate<["-"], "Xopenmp-target=">,
-  HelpText<"Pass  to the specified target offloading toolchain. The 
triple that identifies the toolchain must be provided after the equals sign.">, 
MetaVarName<"">;
+  HelpText<"Pass  to the specified target offloading toolchain identified 
by .">,
+  MetaVarName<" ">;
 def z : Separate<["-"], "z">, Flags<[LinkerInput, RenderAsInput]>,
   HelpText<"Pass -z  to the linker">, MetaVarName<"">,
   Group;
@@ -1380,7 +1381,8 @@
 
 def fobjc_sender_dependent_dispatch : Flag<["-"], 
"fobjc-sender-dependent-dispatch">, Group;
 def fomit_frame_pointer : Flag<["-"], "fomit-frame-pointer">, Group;
-def fopenmp : Flag<["-"], "fopenmp">, Group, Flags<[CC1Option, 
NoArgumentUnused]>;
+def fopenmp : Flag<["-"], "fopenmp">, Group, Flags<[CC1Option, 
NoArgumentUnused]>,
+  HelpText<"Parse OpenMP pragmas and generate parallel code.">;
 def fno_openmp : Flag<["-"], "fno-openmp">, Group, 
Flags<[NoArgumentUnused]>;
 def fopenmp_version_EQ : Joined<["-"], "fopenmp-version=">, Group, 
Flags<[CC1Option, NoArgumentUnused]>;
 def fopenmp_EQ : Joined<["-"], "fopenmp=">, Group;
@@ -1390,14 +1392,11 @@
   HelpText<"Specify comma-separated list of triples OpenMP offloading targets 
to be supported">;
 def fopenmp_dump_offload_linker_script : Flag<["-"], 
"fopenmp-dump-offload-linker-script">, Group,
   Flags<[NoArgumentUnused]>;
-def fopenmp_relocatable_target : Flag<["-"], "fopenmp-relocatable-target">, 
Group, Flags<[CC1Option, NoArgumentUnused]>,
-  HelpText<"OpenMP target code is compiled as relocatable using the -c flag. 
For OpenMP targets the code is relocatable by default.">;
-def fnoopenmp_relocatable_target : Flag<["-"], 
"fnoopenmp-relocatable-target">, Group, Flags<[CC1Option, 
NoArgumentUnused]>,
-  HelpText<"Do not compile OpenMP target code as relocatable.">;
+def fopenmp_relocatable_target : Flag<["-"], "fopenmp-relocatable-target">, 
Group, Flags<[CC1Option, NoArgumentUnused]>;
+def fnoopenmp_relocatable_target : Flag<["-"], 
"fnoopenmp-relocatable-target">, Group, Flags<[CC1Option, 
NoArgumentUnused]>;
 def fopenmp_simd : Flag<["-"], "fopenmp-simd">, Group, 
Flags<[CC1Option, NoArgumentUnused]>,
   HelpText<"Emit OpenMP code only for SIMD-based constructs.">;
-def fno_openmp_simd : Flag<["-"], "fno-openmp-simd">, Group, 
Flags<[CC1Option, NoArgumentUnused]>,
-  HelpText<"Disable OpenMP code for SIMD-based constructs.">;
+def fno_openmp_simd : Flag<["-"], "fno-openmp-simd">, Group, 
Flags<[CC1Option, NoArgumentUnused]>;
 def fno_optimize_sibling_calls : Flag<["-"], "fno-optimize-sibling-calls">, 
Group;
 def foptimize_sibling_calls : Flag<["-"], "foptimize-sibling-calls">, 
Group;
 def force__cpusubtype__ALL : Flag<["-"], "force_cpusubtype_ALL">;


Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -466,7 +466,8 @@
 def Xopenmp_target : Separate<["-"], "Xopenmp-target">,
   HelpText<"Pass  to the target offloading toolchain.">, MetaVarName<"">;
 def Xopenmp_target_EQ : JoinedAndSeparate<["-"], "Xopenmp-target=">,
-  HelpText<"Pass  to the specified target offloading toolchain. The triple that identifies the toolchain must be provided after the equals sign.">, MetaVarName<"">;
+  HelpText<"Pass  to the specified target offloading toolchain identified by .">,
+  MetaVarName<" ">;
 def z : Separate<["-"], "z">, Flags<[LinkerInput, RenderAsInput]>,
   HelpText<"Pass -z  to the linker">, MetaVarName<"">,
   Group;
@@ -1380,7 +1381,8 @@
 
 def fobjc_sender_dependent_dispatch : Flag<["-"], "fobjc-sender-dependent-dispatch">, Group;
 def fomit_frame_pointer : Flag<["-"], "fomit-frame-pointer">, Group;
-def fopenmp : Flag<["-"], "fopenmp">, Group, Flags<[CC1Option, NoArgumentUnused]>;
+def fopenmp : Flag<["-"], "fopenmp">, Group, Flags<[CC1Option, NoArgumentUnused]>,
+  HelpText<"Parse OpenMP pragmas and generate parallel code.">;
 def fno_openmp : Flag<["-"], "fno-openmp">, Group, Flags<[NoArgumentUnused]>;
 def fopenmp_version_EQ : Joined<["-"], "fopenmp-version=">, Group, Flags<[CC1Option, NoArgumentUnu

[clang-tools-extra] r324073 - [clangd] Remove a unused include. NFC

[Eric Liu via cfe-commits]

Author: ioeric
Date: Fri Feb  2 03:25:38 2018
New Revision: 324073

URL: http://llvm.org/viewvc/llvm-project?rev=324073&view=rev
Log:
[clangd] Remove a unused include. NFC

Modified:
clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp

Modified: clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp?rev=324073&r1=324072&r2=324073&view=diff
==
--- clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp (original)
+++ clang-tools-extra/trunk/clangd/index/SymbolCollector.cpp Fri Feb  2 
03:25:38 2018
@@ -9,7 +9,6 @@
 
 #include "SymbolCollector.h"
 #include "../CodeCompletionStrings.h"
-#include "Logger.h"
 #include "clang/AST/DeclCXX.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/Basic/SourceManager.h"


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

Re: [PATCH] D42796: [clangd] Skip inline namespace when collecting scopes for index symbols.

[Sam McCall via cfe-commits]

Yeah this is just a bug in clang's pprinter. I'll fix it.

If you give multiple C++ names to the same linker symbol using extern C,
I'm pretty sure you're in UB land.

On Fri, Feb 2, 2018, 12:04 Ilya Biryukov via Phabricator <
revi...@reviews.llvm.org> wrote:

> ilya-biryukov added inline comments.
>
>
> 
> Comment at: clangd/index/SymbolCollector.cpp:73
> +   Context = Context->getParent()) {
> +if (llvm::isa(Context) ||
> +llvm::isa(Context))
> 
> ioeric wrote:
> > sammccall wrote:
> > > I'm not sure this is always correct: at least clang accepts this code:
> > >
> > >   namespace X { extern "C++" { int y; }}
> > >
> > > and you'll emit "y" instead of "X::y".
> > >
> > > I think the check you want is
> > >
> > >   if (Context->isTransparentContext() || Context->isInlineNamespace())
> > > continue;
> > >
> > >  isTransparentContext will handle the Namespace and Enum cases as you
> do below, including the enum/enum class distinction.
> > >
> > > (The code you have below is otherwise correct, I think - but a reader
> needs to think about more separate cases in order to see that)
> > In `namespace X { extern "C++" { int y; }}`, we would still want `y`
> instead of `X::y` since C-style symbol doesn't have scope.
> `printQualifiedName` also does the same thing printing `y`; I've added a
> test case for `extern C`.
> >
> > I also realized we've been dropping C symbols in `shouldFilterDecl` and
> fixed it in the same patch.
> I think we want `X::y`, not `y`.
>
> Lookup still finds it inside the namespace and does not find it in the
> global scope. So for our purposes they are actually inside the namespace
> and have the qualified name of this namespace. Here's an example:
> ```
> namespace ns {
> extern "C" int foo();
> }
>
> void test() {
>   ns::foo(); // ok
>   foo(); // error
>   ::foo(); // error
> }
> ```
>
> Note, however, that the tricky bit there is probably merging of the
> symbols, as it means symbols with the same USR (they are the same for all
> `extern "c"` declarations with the same name, right?) can have different
> qualified names and we won't know which one to choose.
>
> ```
> namespace a {
>  extern "C" int foo();
> }
> namespace b {
>   extern "C" int foo(); // probably same USR, different qname. Also,
> possibly different types.
> }
> ```
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D42796
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42573: [wip] The new threading implementation

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov updated this revision to Diff 132567.
ilya-biryukov added a comment.

Cleaned up the patch and added the missing bits.
This is in a much better shape now and should be ready for review.
I'll have a go through the existing review comments to make sure all concerns 
were addressed.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D42573

Files:
  clangd/ASTWorker.cpp
  clangd/ASTWorker.h
  clangd/CMakeLists.txt
  clangd/ClangdServer.h
  clangd/ClangdUnitStore.cpp
  clangd/ClangdUnitStore.h
  clangd/TUScheduler.cpp
  clangd/TUScheduler.h
  clangd/Threading.cpp
  clangd/Threading.h

Index: clangd/Threading.h
===
--- clangd/Threading.h
+++ clangd/Threading.h
@@ -12,74 +12,68 @@
 
 #include "Context.h"
 #include "Function.h"
+#include 
+#include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 
 namespace clang {
 namespace clangd {
-/// A simple fixed-size thread pool implementation.
-class ThreadPool {
+
+/// A shared boolean flag indicating if the computation was cancelled.
+/// Once cancelled, cannot be returned to the previous state.
+/// FIXME: We should split this class it into consumers and producers of the
+/// cancellation flags.
+class CancellationFlag {
 public:
-  /// If \p AsyncThreadsCount is 0, requests added using addToFront and addToEnd
-  /// will be processed synchronously on the calling thread.
-  // Otherwise, \p AsyncThreadsCount threads will be created to schedule the
-  // requests.
-  ThreadPool(unsigned AsyncThreadsCount);
-  /// Destructor blocks until all requests are processed and worker threads are
-  /// terminated.
-  ~ThreadPool();
+  CancellationFlag();
 
-  /// Add a new request to run function \p F with args \p As to the start of the
-  /// queue. The request will be run on a separate thread.
-  template 
-  void addToFront(Func &&F, Args &&... As) {
-if (RunSynchronously) {
-  std::forward(F)(std::forward(As)...);
-  return;
-}
+  void cancel() {
+assert(WasCancelled && "the object was moved");
+WasCancelled->store(true);
+  }
 
-{
-  std::lock_guard Lock(Mutex);
-  RequestQueue.emplace_front(
-  BindWithForward(std::forward(F), std::forward(As)...),
-  Context::current().clone());
-}
-RequestCV.notify_one();
+  bool isCancelled() const {
+assert(WasCancelled && "the object was moved");
+return WasCancelled->load();
   }
 
-  /// Add a new request to run function \p F with args \p As to the end of the
-  /// queue. The request will be run on a separate thread.
-  template  void addToEnd(Func &&F, Args &&... As) {
-if (RunSynchronously) {
-  std::forward(F)(std::forward(As)...);
-  return;
-}
+private:
+  std::shared_ptr> WasCancelled;
+};
 
-{
-  std::lock_guard Lock(Mutex);
-  RequestQueue.emplace_back(
-  BindWithForward(std::forward(F), std::forward(As)...),
-  Context::current().clone());
-}
-RequestCV.notify_one();
-  }
+/// Limits the number of threads that can acquire the lock at the same time.
+class Semaphore {
+public:
+  Semaphore(std::size_t MaxLocks);
+
+  void lock();
+  void unlock();
+
+private:
+  std::mutex Mutex;
+  std::condition_variable SlotsChanged;
+  std::size_t FreeSlots;
+};
+
+/// Allows to run tasks on separate (detached) threads and wait for all tasks to
+/// finish.
+class AsyncTaskRunner {
+public:
+  ~AsyncTaskRunner();
+
+  void waitForAll();
+  void runAsync(UniqueFunction Action);
 
 private:
-  bool RunSynchronously;
-  mutable std::mutex Mutex;
-  /// We run some tasks on separate threads(parsing, CppFile cleanup).
-  /// These threads looks into RequestQueue to find requests to handle and
-  /// terminate when Done is set to true.
-  std::vector Workers;
-  /// Setting Done to true will make the worker threads terminate.
-  bool Done = false;
-  /// A queue of requests.
-  std::deque, Context>> RequestQueue;
-  /// Condition variable to wake up worker threads.
-  std::condition_variable RequestCV;
+  std::mutex Mutex;
+  std::condition_variable TasksReachedZero;
+  std::size_t InFlightTasks = 0;
 };
 } // namespace clangd
 } // namespace clang
Index: clangd/Threading.cpp
===
--- clangd/Threading.cpp
+++ clangd/Threading.cpp
@@ -1,63 +1,61 @@
 #include "Threading.h"
+#include "llvm/ADT/ScopeExit.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/Threading.h"
 
 namespace clang {
 namespace clangd {
-ThreadPool::ThreadPool(unsigned AsyncThreadsCount)
-: RunSynchronously(AsyncThreadsCount == 0) {
-  if (RunSynchronously) {
-// Don't start the worker thread if we're running synchronously
-return;
-  }
 
-  Workers.reserve(AsyncThreadsCount);
-  for (unsigned I = 0; I < AsyncThreadsCount; ++I) {
-Workers.push_back(std::thread([this, I]() {
-  llvm::set_thread_name(llvm::formatv("scheduler/{0}", I));
- 

[PATCH] D42727: [clang-format] Adds space around angle brackets in text protos

[Daniel Jasper via Phabricator via cfe-commits]

djasper added inline comments.



Comment at: lib/Format/TokenAnnotator.cpp:82
 CurrentToken->MatchingParen = Left;
-CurrentToken->Type = TT_TemplateCloser;
+if (Style.Language == FormatStyle::LK_TextProto)
+  CurrentToken->Type = TT_DictLiteral;

Here and in many other places, you are only checking against LK_TextProto. 
However, in LK_Proto, we also have a lot of text-formatted protos in field 
options. So, most places, these two should result in the same behavior, I think.



Comment at: lib/Format/TokenAnnotator.cpp:2517
+  if (Left.is(tok::greater) && Right.is(tok::greater)) {
+if (Style.Language == FormatStyle::LK_TextProto) {
+  return !Style.Cpp11BracedListStyle;

No braces.


Repository:
  rC Clang

https://reviews.llvm.org/D42727



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

[PATCH] D42573: [clangd] The new threading implementation

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov marked 3 inline comments as done.
ilya-biryukov added inline comments.



Comment at: clangd/ClangdServer.h:140
+///  the working threads as soon as an idle thread is available.
+///- scheduleOnQueue will schedule to a specific queue. Requests from the
+///  same queue are not processed concurrently. Requests in each queue are

sammccall wrote:
> As discussed offline, Queue's semantics are very similar to a thread, except:
>  - cooperatively scheduled: Queues do not yield until idle
>  - limited in parallelism by the size of the threadpool
> 
> In the interests of keeping things simple and familiar, I think we should 
> start out by using `std::thread`.
> We can use a semaphore to limit the parallelism (I'm fine with doing this in 
> the first iteration, but urge you to consider leaving it out until we see 
> actual problems with using the CPU as our limit). This should give both 
> properties above (if the Queue only releases the semaphore when idle).
> If we still have performance problems we may need to switch to a multiplexing 
> version, though I have a hard time imagining it (e.g. even on windows, thread 
> spawn should be <1us, and memory usage is trivial compared to anything that 
> touches an AST).
Done exactly that. There's a new abstraction in the patch that manages creating 
threads and waiting for them to finish for us. It seems pretty simple, please 
take a look and let me know what you think.



Comment at: clangd/ClangdServer.h:141
+///- scheduleOnQueue will schedule to a specific queue. Requests from the
+///  same queue are not processed concurrently. Requests in each queue are
+///  executed in the FIFO order.

sammccall wrote:
> Similarly, the free requests look a lot like standalone threads, with a few 
> enhancements that are implementable but also possible YAGNI.
>  - running code complete first is roughly[1] equivalent to elevating the 
> thread's priority (no portability shim in llvm yet, but it's pretty easy). I 
> don't think this needs to be in the first patch.
>  - limiting parallelism can be done with semaphores. In fact we can easily 
> express something like "up to 18 queued tasks, up to 20 free tasks, up to 20 
> total", which nice for latency.
> 
> [1] I see both advantages and disadvantages, happy to discuss more!
We're not setting the priorities in the first version, but certainly agree we 
should add that later.
And we're using a simple semaphore to limit the number of actively running 
threads.



Comment at: clangd/ClangdServer.h:143
+///  executed in the FIFO order.
 class ThreadPool {
 public:

sammccall wrote:
> So overall here, I think that we can drop `ThreadPool` without much impact on 
> the design.
> `Queue` would stay, as a wrapper around `std::thread` that lets you add tasks 
> to its runloop. It would be owned by FileData, and shutdown would be 
> triggered by its destructor.
> 
> The advantage is one less layer here to understand, and an attractive 
> nuisance to tweak over time.
> The downsides I see:
>   - threading is no longer abstracted away, so changes to it are less isolated
> I think it's likely that we get away with the model staying simple. If it 
> gets complicated, we'll want to add the abstraction back in. But this isn't 
> java, we can abstract when we need it :-)
>   - RunSynchronously escapes into Scheduler. This is for the worse I think, 
> but only slightly.
I tried fiddling with the idea and ended up abandoning the `RequestQueue` in 
favor of the `std::queue` with explicit locks.
There's only one place where we queue requests now (processing the 
updates/reads of the ASTs), everything else is managed by creating separate 
`std::thread`s.



Comment at: clangd/TUScheduler.cpp:23
+return;
+  Worker = std::thread([&]() {
+while (true) {

sammccall wrote:
> I tend to find thread bodies more readable as a member function, up to you
Moved it as a member function and made a (questionable) decision that clients 
of the class are responsible for running that function on a separate thread 
themselves. 
It allows to reuse the abstraction that runs the threads and waits for them to 
finish (also used when spawning threads for completion, and similar).
It shouldn't be too bad, given that we have just a single client. Even though 
the interface is not particularly nice.

Happy to chat about it.



Comment at: clangd/TUScheduler.cpp:258
+std::lock_guard BarrierLock(Barrier);
+// XXX: what if preamble got built by this time?
+// if (!Preamble)

sammccall wrote:
> this seems like where shared_ptr might help us out if we're willing to deal 
> with it.
> If we captured a shared_ptr here, then we'd want to call 
> getPossiblyStalePreamble inside rather than outside the lambda.
> 
> So this would look something like:
>  - FileASTThread 

[PATCH] D42573: [clangd] The new threading implementation

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov updated this revision to Diff 132570.
ilya-biryukov marked an inline comment as done.
ilya-biryukov added a comment.

- Removed redundant includes


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D42573

Files:
  clangd/ASTWorker.cpp
  clangd/ASTWorker.h
  clangd/CMakeLists.txt
  clangd/ClangdServer.h
  clangd/ClangdUnitStore.cpp
  clangd/ClangdUnitStore.h
  clangd/TUScheduler.cpp
  clangd/TUScheduler.h
  clangd/Threading.cpp
  clangd/Threading.h

Index: clangd/Threading.h
===
--- clangd/Threading.h
+++ clangd/Threading.h
@@ -12,74 +12,65 @@
 
 #include "Context.h"
 #include "Function.h"
+#include 
+#include 
 #include 
-#include 
+#include 
 #include 
-#include 
 #include 
 
 namespace clang {
 namespace clangd {
-/// A simple fixed-size thread pool implementation.
-class ThreadPool {
+
+/// A shared boolean flag indicating if the computation was cancelled.
+/// Once cancelled, cannot be returned to the previous state.
+/// FIXME: We should split this class it into consumers and producers of the
+/// cancellation flags.
+class CancellationFlag {
 public:
-  /// If \p AsyncThreadsCount is 0, requests added using addToFront and addToEnd
-  /// will be processed synchronously on the calling thread.
-  // Otherwise, \p AsyncThreadsCount threads will be created to schedule the
-  // requests.
-  ThreadPool(unsigned AsyncThreadsCount);
-  /// Destructor blocks until all requests are processed and worker threads are
-  /// terminated.
-  ~ThreadPool();
+  CancellationFlag();
 
-  /// Add a new request to run function \p F with args \p As to the start of the
-  /// queue. The request will be run on a separate thread.
-  template 
-  void addToFront(Func &&F, Args &&... As) {
-if (RunSynchronously) {
-  std::forward(F)(std::forward(As)...);
-  return;
-}
+  void cancel() {
+assert(WasCancelled && "the object was moved");
+WasCancelled->store(true);
+  }
 
-{
-  std::lock_guard Lock(Mutex);
-  RequestQueue.emplace_front(
-  BindWithForward(std::forward(F), std::forward(As)...),
-  Context::current().clone());
-}
-RequestCV.notify_one();
+  bool isCancelled() const {
+assert(WasCancelled && "the object was moved");
+return WasCancelled->load();
   }
 
-  /// Add a new request to run function \p F with args \p As to the end of the
-  /// queue. The request will be run on a separate thread.
-  template  void addToEnd(Func &&F, Args &&... As) {
-if (RunSynchronously) {
-  std::forward(F)(std::forward(As)...);
-  return;
-}
+private:
+  std::shared_ptr> WasCancelled;
+};
 
-{
-  std::lock_guard Lock(Mutex);
-  RequestQueue.emplace_back(
-  BindWithForward(std::forward(F), std::forward(As)...),
-  Context::current().clone());
-}
-RequestCV.notify_one();
-  }
+/// Limits the number of threads that can acquire the lock at the same time.
+class Semaphore {
+public:
+  Semaphore(std::size_t MaxLocks);
+
+  void lock();
+  void unlock();
+
+private:
+  std::mutex Mutex;
+  std::condition_variable SlotsChanged;
+  std::size_t FreeSlots;
+};
+
+/// Allows to run tasks on separate (detached) threads and wait for all tasks to
+/// finish.
+class AsyncTaskRunner {
+public:
+  ~AsyncTaskRunner();
+
+  void waitForAll();
+  void runAsync(UniqueFunction Action);
 
 private:
-  bool RunSynchronously;
-  mutable std::mutex Mutex;
-  /// We run some tasks on separate threads(parsing, CppFile cleanup).
-  /// These threads looks into RequestQueue to find requests to handle and
-  /// terminate when Done is set to true.
-  std::vector Workers;
-  /// Setting Done to true will make the worker threads terminate.
-  bool Done = false;
-  /// A queue of requests.
-  std::deque, Context>> RequestQueue;
-  /// Condition variable to wake up worker threads.
-  std::condition_variable RequestCV;
+  std::mutex Mutex;
+  std::condition_variable TasksReachedZero;
+  std::size_t InFlightTasks = 0;
 };
 } // namespace clangd
 } // namespace clang
Index: clangd/Threading.cpp
===
--- clangd/Threading.cpp
+++ clangd/Threading.cpp
@@ -1,63 +1,62 @@
 #include "Threading.h"
+#include "llvm/ADT/ScopeExit.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/Threading.h"
+#include 
 
 namespace clang {
 namespace clangd {
-ThreadPool::ThreadPool(unsigned AsyncThreadsCount)
-: RunSynchronously(AsyncThreadsCount == 0) {
-  if (RunSynchronously) {
-// Don't start the worker thread if we're running synchronously
-return;
-  }
 
-  Workers.reserve(AsyncThreadsCount);
-  for (unsigned I = 0; I < AsyncThreadsCount; ++I) {
-Workers.push_back(std::thread([this, I]() {
-  llvm::set_thread_name(llvm::formatv("scheduler/{0}", I));
-  while (true) {
-UniqueFunction Request;
-Context Ctx;
-
-// Pick request from the queue
-{
- 

[PATCH] D42841: [docs] Improve help for OpenMP options

[Jonas Hahnfeld via Phabricator via cfe-commits]

Hahnfeld updated this revision to Diff 132571.
Hahnfeld edited the summary of this revision.

https://reviews.llvm.org/D42841

Files:
  include/clang/Driver/Options.td


Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -466,7 +466,8 @@
 def Xopenmp_target : Separate<["-"], "Xopenmp-target">,
   HelpText<"Pass  to the target offloading toolchain.">, 
MetaVarName<"">;
 def Xopenmp_target_EQ : JoinedAndSeparate<["-"], "Xopenmp-target=">,
-  HelpText<"Pass  to the specified target offloading toolchain. The 
triple that identifies the toolchain must be provided after the equals sign.">, 
MetaVarName<"">;
+  HelpText<"Pass  to the target offloading toolchain identified by 
.">,
+  MetaVarName<" ">;
 def z : Separate<["-"], "z">, Flags<[LinkerInput, RenderAsInput]>,
   HelpText<"Pass -z  to the linker">, MetaVarName<"">,
   Group;
@@ -1380,24 +1381,26 @@
 
 def fobjc_sender_dependent_dispatch : Flag<["-"], 
"fobjc-sender-dependent-dispatch">, Group;
 def fomit_frame_pointer : Flag<["-"], "fomit-frame-pointer">, Group;
-def fopenmp : Flag<["-"], "fopenmp">, Group, Flags<[CC1Option, 
NoArgumentUnused]>;
+def fopenmp : Flag<["-"], "fopenmp">, Group, Flags<[CC1Option, 
NoArgumentUnused]>,
+  HelpText<"Parse OpenMP pragmas and generate parallel code.">;
 def fno_openmp : Flag<["-"], "fno-openmp">, Group, 
Flags<[NoArgumentUnused]>;
 def fopenmp_version_EQ : Joined<["-"], "fopenmp-version=">, Group, 
Flags<[CC1Option, NoArgumentUnused]>;
 def fopenmp_EQ : Joined<["-"], "fopenmp=">, Group;
-def fopenmp_use_tls : Flag<["-"], "fopenmp-use-tls">, Group, 
Flags<[NoArgumentUnused]>;
-def fnoopenmp_use_tls : Flag<["-"], "fnoopenmp-use-tls">, Group, 
Flags<[CC1Option, NoArgumentUnused]>;
+def fopenmp_use_tls : Flag<["-"], "fopenmp-use-tls">, Group,
+  Flags<[NoArgumentUnused, HelpHidden]>;
+def fnoopenmp_use_tls : Flag<["-"], "fnoopenmp-use-tls">, Group,
+  Flags<[CC1Option, NoArgumentUnused, HelpHidden]>;
 def fopenmp_targets_EQ : CommaJoined<["-"], "fopenmp-targets=">, 
Flags<[DriverOption, CC1Option]>,
   HelpText<"Specify comma-separated list of triples OpenMP offloading targets 
to be supported">;
-def fopenmp_dump_offload_linker_script : Flag<["-"], 
"fopenmp-dump-offload-linker-script">, Group,
-  Flags<[NoArgumentUnused]>;
-def fopenmp_relocatable_target : Flag<["-"], "fopenmp-relocatable-target">, 
Group, Flags<[CC1Option, NoArgumentUnused]>,
-  HelpText<"OpenMP target code is compiled as relocatable using the -c flag. 
For OpenMP targets the code is relocatable by default.">;
-def fnoopenmp_relocatable_target : Flag<["-"], 
"fnoopenmp-relocatable-target">, Group, Flags<[CC1Option, 
NoArgumentUnused]>,
-  HelpText<"Do not compile OpenMP target code as relocatable.">;
+def fopenmp_dump_offload_linker_script : Flag<["-"], 
"fopenmp-dump-offload-linker-script">,
+  Group, Flags<[NoArgumentUnused, HelpHidden]>;
+def fopenmp_relocatable_target : Flag<["-"], "fopenmp-relocatable-target">,
+  Group, Flags<[CC1Option, NoArgumentUnused, HelpHidden]>;
+def fnoopenmp_relocatable_target : Flag<["-"], "fnoopenmp-relocatable-target">,
+  Group, Flags<[CC1Option, NoArgumentUnused, HelpHidden]>;
 def fopenmp_simd : Flag<["-"], "fopenmp-simd">, Group, 
Flags<[CC1Option, NoArgumentUnused]>,
   HelpText<"Emit OpenMP code only for SIMD-based constructs.">;
-def fno_openmp_simd : Flag<["-"], "fno-openmp-simd">, Group, 
Flags<[CC1Option, NoArgumentUnused]>,
-  HelpText<"Disable OpenMP code for SIMD-based constructs.">;
+def fno_openmp_simd : Flag<["-"], "fno-openmp-simd">, Group, 
Flags<[CC1Option, NoArgumentUnused]>;
 def fno_optimize_sibling_calls : Flag<["-"], "fno-optimize-sibling-calls">, 
Group;
 def foptimize_sibling_calls : Flag<["-"], "foptimize-sibling-calls">, 
Group;
 def force__cpusubtype__ALL : Flag<["-"], "force_cpusubtype_ALL">;


Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -466,7 +466,8 @@
 def Xopenmp_target : Separate<["-"], "Xopenmp-target">,
   HelpText<"Pass  to the target offloading toolchain.">, MetaVarName<"">;
 def Xopenmp_target_EQ : JoinedAndSeparate<["-"], "Xopenmp-target=">,
-  HelpText<"Pass  to the specified target offloading toolchain. The triple that identifies the toolchain must be provided after the equals sign.">, MetaVarName<"">;
+  HelpText<"Pass  to the target offloading toolchain identified by .">,
+  MetaVarName<" ">;
 def z : Separate<["-"], "z">, Flags<[LinkerInput, RenderAsInput]>,
   HelpText<"Pass -z  to the linker">, MetaVarName<"">,
   Group;
@@ -1380,24 +1381,26 @@
 
 def fobjc_sender_dependent_dispatch : Flag<["-"], "fobjc-sender-dependent-dispatch">, Group;
 def fomit_frame_pointer : Flag<["-"], "fomit-frame-pointer">, Group;
-def fopenmp : Flag<["-"], "fopenmp">, Group, Flags<[CC1Option, NoArgumentUnused]>;
+def fopenmp :

Re: [PATCH] D42796: [clangd] Skip inline namespace when collecting scopes for index symbols.

[Ilya Biryukov via cfe-commits]

In a single translation unit, yes. In multiple translation units that
aren't linked together it's totally fine (may actually refer to different
entities).


On Fri, Feb 2, 2018 at 1:04 PM Sam McCall  wrote:

> Yeah this is just a bug in clang's pprinter. I'll fix it.
>
> If you give multiple C++ names to the same linker symbol using extern C,
> I'm pretty sure you're in UB land.
>
> On Fri, Feb 2, 2018, 12:04 Ilya Biryukov via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> ilya-biryukov added inline comments.
>>
>>
>> 
>> Comment at: clangd/index/SymbolCollector.cpp:73
>> +   Context = Context->getParent()) {
>> +if (llvm::isa(Context) ||
>> +llvm::isa(Context))
>> 
>> ioeric wrote:
>> > sammccall wrote:
>> > > I'm not sure this is always correct: at least clang accepts this code:
>> > >
>> > >   namespace X { extern "C++" { int y; }}
>> > >
>> > > and you'll emit "y" instead of "X::y".
>> > >
>> > > I think the check you want is
>> > >
>> > >   if (Context->isTransparentContext() || Context->isInlineNamespace())
>> > > continue;
>> > >
>> > >  isTransparentContext will handle the Namespace and Enum cases as you
>> do below, including the enum/enum class distinction.
>> > >
>> > > (The code you have below is otherwise correct, I think - but a reader
>> needs to think about more separate cases in order to see that)
>> > In `namespace X { extern "C++" { int y; }}`, we would still want `y`
>> instead of `X::y` since C-style symbol doesn't have scope.
>> `printQualifiedName` also does the same thing printing `y`; I've added a
>> test case for `extern C`.
>> >
>> > I also realized we've been dropping C symbols in `shouldFilterDecl` and
>> fixed it in the same patch.
>> I think we want `X::y`, not `y`.
>>
>> Lookup still finds it inside the namespace and does not find it in the
>> global scope. So for our purposes they are actually inside the namespace
>> and have the qualified name of this namespace. Here's an example:
>> ```
>> namespace ns {
>> extern "C" int foo();
>> }
>>
>> void test() {
>>   ns::foo(); // ok
>>   foo(); // error
>>   ::foo(); // error
>> }
>> ```
>>
>> Note, however, that the tricky bit there is probably merging of the
>> symbols, as it means symbols with the same USR (they are the same for all
>> `extern "c"` declarations with the same name, right?) can have different
>> qualified names and we won't know which one to choose.
>>
>> ```
>> namespace a {
>>  extern "C" int foo();
>> }
>> namespace b {
>>   extern "C" int foo(); // probably same USR, different qname. Also,
>> possibly different types.
>> }
>> ```
>>
>>
>> Repository:
>>   rL LLVM
>>
>> https://reviews.llvm.org/D42796
>>
>>
>>
>>

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

Re: [PATCH] D42796: [clangd] Skip inline namespace when collecting scopes for index symbols.

[Sam McCall via cfe-commits]

Right. And multiple TUs that *are* linked together would be fine too.
But in that case I don't think we need to be clever about treating these as
the same symbol. Indexing them twice is fine.

On Fri, Feb 2, 2018 at 1:42 PM, Ilya Biryukov  wrote:

> In a single translation unit, yes. In multiple translation units that
> aren't linked together it's totally fine (may actually refer to different
> entities).
>
>
> On Fri, Feb 2, 2018 at 1:04 PM Sam McCall  wrote:
>
>> Yeah this is just a bug in clang's pprinter. I'll fix it.
>>
>> If you give multiple C++ names to the same linker symbol using extern C,
>> I'm pretty sure you're in UB land.
>>
>> On Fri, Feb 2, 2018, 12:04 Ilya Biryukov via Phabricator <
>> revi...@reviews.llvm.org> wrote:
>>
>>> ilya-biryukov added inline comments.
>>>
>>>
>>> 
>>> Comment at: clangd/index/SymbolCollector.cpp:73
>>> +   Context = Context->getParent()) {
>>> +if (llvm::isa(Context) ||
>>> +llvm::isa(Context))
>>> 
>>> ioeric wrote:
>>> > sammccall wrote:
>>> > > I'm not sure this is always correct: at least clang accepts this
>>> code:
>>> > >
>>> > >   namespace X { extern "C++" { int y; }}
>>> > >
>>> > > and you'll emit "y" instead of "X::y".
>>> > >
>>> > > I think the check you want is
>>> > >
>>> > >   if (Context->isTransparentContext() ||
>>> Context->isInlineNamespace())
>>> > > continue;
>>> > >
>>> > >  isTransparentContext will handle the Namespace and Enum cases as
>>> you do below, including the enum/enum class distinction.
>>> > >
>>> > > (The code you have below is otherwise correct, I think - but a
>>> reader needs to think about more separate cases in order to see that)
>>> > In `namespace X { extern "C++" { int y; }}`, we would still want `y`
>>> instead of `X::y` since C-style symbol doesn't have scope.
>>> `printQualifiedName` also does the same thing printing `y`; I've added a
>>> test case for `extern C`.
>>> >
>>> > I also realized we've been dropping C symbols in `shouldFilterDecl`
>>> and fixed it in the same patch.
>>> I think we want `X::y`, not `y`.
>>>
>>> Lookup still finds it inside the namespace and does not find it in the
>>> global scope. So for our purposes they are actually inside the namespace
>>> and have the qualified name of this namespace. Here's an example:
>>> ```
>>> namespace ns {
>>> extern "C" int foo();
>>> }
>>>
>>> void test() {
>>>   ns::foo(); // ok
>>>   foo(); // error
>>>   ::foo(); // error
>>> }
>>> ```
>>>
>>> Note, however, that the tricky bit there is probably merging of the
>>> symbols, as it means symbols with the same USR (they are the same for all
>>> `extern "c"` declarations with the same name, right?) can have different
>>> qualified names and we won't know which one to choose.
>>>
>>> ```
>>> namespace a {
>>>  extern "C" int foo();
>>> }
>>> namespace b {
>>>   extern "C" int foo(); // probably same USR, different qname. Also,
>>> possibly different types.
>>> }
>>> ```
>>>
>>>
>>> Repository:
>>>   rL LLVM
>>>
>>> https://reviews.llvm.org/D42796
>>>
>>>
>>>
>>>
>
> --
> Regards,
> Ilya Biryukov
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D42796: [clangd] Skip inline namespace when collecting scopes for index symbols.

[Ilya Biryukov via cfe-commits]

Exactly. We should make sure we *don't* treat them as the same symbol. But
I would expect there USRs to be the same and that's what we use to
deduplicate.


On Fri, Feb 2, 2018 at 1:45 PM Sam McCall  wrote:

> Right. And multiple TUs that *are* linked together would be fine too.
> But in that case I don't think we need to be clever about treating these
> as the same symbol. Indexing them twice is fine.
>
> On Fri, Feb 2, 2018 at 1:42 PM, Ilya Biryukov 
> wrote:
>
>> In a single translation unit, yes. In multiple translation units that
>> aren't linked together it's totally fine (may actually refer to different
>> entities).
>>
>>
>> On Fri, Feb 2, 2018 at 1:04 PM Sam McCall  wrote:
>>
>>> Yeah this is just a bug in clang's pprinter. I'll fix it.
>>>
>>> If you give multiple C++ names to the same linker symbol using extern C,
>>> I'm pretty sure you're in UB land.
>>>
>>> On Fri, Feb 2, 2018, 12:04 Ilya Biryukov via Phabricator <
>>> revi...@reviews.llvm.org> wrote:
>>>
 ilya-biryukov added inline comments.


 
 Comment at: clangd/index/SymbolCollector.cpp:73
 +   Context = Context->getParent()) {
 +if (llvm::isa(Context) ||
 +llvm::isa(Context))
 
 ioeric wrote:
 > sammccall wrote:
 > > I'm not sure this is always correct: at least clang accepts this
 code:
 > >
 > >   namespace X { extern "C++" { int y; }}
 > >
 > > and you'll emit "y" instead of "X::y".
 > >
 > > I think the check you want is
 > >
 > >   if (Context->isTransparentContext() ||
 Context->isInlineNamespace())
 > > continue;
 > >
 > >  isTransparentContext will handle the Namespace and Enum cases as
 you do below, including the enum/enum class distinction.
 > >
 > > (The code you have below is otherwise correct, I think - but a
 reader needs to think about more separate cases in order to see that)
 > In `namespace X { extern "C++" { int y; }}`, we would still want `y`
 instead of `X::y` since C-style symbol doesn't have scope.
 `printQualifiedName` also does the same thing printing `y`; I've added a
 test case for `extern C`.
 >
 > I also realized we've been dropping C symbols in `shouldFilterDecl`
 and fixed it in the same patch.
 I think we want `X::y`, not `y`.

 Lookup still finds it inside the namespace and does not find it in the
 global scope. So for our purposes they are actually inside the namespace
 and have the qualified name of this namespace. Here's an example:
 ```
 namespace ns {
 extern "C" int foo();
 }

 void test() {
   ns::foo(); // ok
   foo(); // error
   ::foo(); // error
 }
 ```

 Note, however, that the tricky bit there is probably merging of the
 symbols, as it means symbols with the same USR (they are the same for all
 `extern "c"` declarations with the same name, right?) can have different
 qualified names and we won't know which one to choose.

 ```
 namespace a {
  extern "C" int foo();
 }
 namespace b {
   extern "C" int foo(); // probably same USR, different qname. Also,
 possibly different types.
 }
 ```


 Repository:
   rL LLVM

 https://reviews.llvm.org/D42796




>>
>> --
>> Regards,
>> Ilya Biryukov
>>
>
>

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

Re: [PATCH] D42796: [clangd] Skip inline namespace when collecting scopes for index symbols.

[Sam McCall via cfe-commits]

My intuition was that the USRs would be different, that linkage would
either be included or not included from the USR, but it wouldn't affect
whether the namespace is included. (Reasoning: USRs model language
concepts, not linker ones)

But we're both wrong. If I'm reading USRGeneration correctly, hitting a
linkage spec while walking the scope tree sets the "ignore result" flag
which signals the result is unusable (and short-circuits some paths that
finish computing it). This seems like it may cause problems for us :-)
I wonder why the tests didn't catch it, maybe I'm misreading.

On Fri, Feb 2, 2018 at 1:46 PM, Ilya Biryukov  wrote:

> Exactly. We should make sure we *don't* treat them as the same symbol. But
> I would expect there USRs to be the same and that's what we use to
> deduplicate.
>
>
> On Fri, Feb 2, 2018 at 1:45 PM Sam McCall  wrote:
>
>> Right. And multiple TUs that *are* linked together would be fine too.
>> But in that case I don't think we need to be clever about treating these
>> as the same symbol. Indexing them twice is fine.
>>
>> On Fri, Feb 2, 2018 at 1:42 PM, Ilya Biryukov 
>> wrote:
>>
>>> In a single translation unit, yes. In multiple translation units that
>>> aren't linked together it's totally fine (may actually refer to different
>>> entities).
>>>
>>>
>>> On Fri, Feb 2, 2018 at 1:04 PM Sam McCall  wrote:
>>>
 Yeah this is just a bug in clang's pprinter. I'll fix it.

 If you give multiple C++ names to the same linker symbol using extern
 C, I'm pretty sure you're in UB land.

 On Fri, Feb 2, 2018, 12:04 Ilya Biryukov via Phabricator <
 revi...@reviews.llvm.org> wrote:

> ilya-biryukov added inline comments.
>
>
> 
> Comment at: clangd/index/SymbolCollector.cpp:73
> +   Context = Context->getParent()) {
> +if (llvm::isa(Context) ||
> +llvm::isa(Context))
> 
> ioeric wrote:
> > sammccall wrote:
> > > I'm not sure this is always correct: at least clang accepts this
> code:
> > >
> > >   namespace X { extern "C++" { int y; }}
> > >
> > > and you'll emit "y" instead of "X::y".
> > >
> > > I think the check you want is
> > >
> > >   if (Context->isTransparentContext() ||
> Context->isInlineNamespace())
> > > continue;
> > >
> > >  isTransparentContext will handle the Namespace and Enum cases as
> you do below, including the enum/enum class distinction.
> > >
> > > (The code you have below is otherwise correct, I think - but a
> reader needs to think about more separate cases in order to see that)
> > In `namespace X { extern "C++" { int y; }}`, we would still want `y`
> instead of `X::y` since C-style symbol doesn't have scope.
> `printQualifiedName` also does the same thing printing `y`; I've added a
> test case for `extern C`.
> >
> > I also realized we've been dropping C symbols in `shouldFilterDecl`
> and fixed it in the same patch.
> I think we want `X::y`, not `y`.
>
> Lookup still finds it inside the namespace and does not find it in the
> global scope. So for our purposes they are actually inside the namespace
> and have the qualified name of this namespace. Here's an example:
> ```
> namespace ns {
> extern "C" int foo();
> }
>
> void test() {
>   ns::foo(); // ok
>   foo(); // error
>   ::foo(); // error
> }
> ```
>
> Note, however, that the tricky bit there is probably merging of the
> symbols, as it means symbols with the same USR (they are the same for all
> `extern "c"` declarations with the same name, right?) can have different
> qualified names and we won't know which one to choose.
>
> ```
> namespace a {
>  extern "C" int foo();
> }
> namespace b {
>   extern "C" int foo(); // probably same USR, different qname. Also,
> possibly different types.
> }
> ```
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D42796
>
>
>
>
>>>
>>> --
>>> Regards,
>>> Ilya Biryukov
>>>
>>
>>
>
> --
> Regards,
> Ilya Biryukov
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D42796: [clangd] Skip inline namespace when collecting scopes for index symbols.

[Ilya Biryukov via cfe-commits]

At least now we know they might cause problems. Thanks for digging into
this.


On Fri, Feb 2, 2018 at 1:53 PM Sam McCall  wrote:

> My intuition was that the USRs would be different, that linkage would
> either be included or not included from the USR, but it wouldn't affect
> whether the namespace is included. (Reasoning: USRs model language
> concepts, not linker ones)
>
> But we're both wrong. If I'm reading USRGeneration correctly, hitting a
> linkage spec while walking the scope tree sets the "ignore result" flag
> which signals the result is unusable (and short-circuits some paths that
> finish computing it). This seems like it may cause problems for us :-)
> I wonder why the tests didn't catch it, maybe I'm misreading.
>
> On Fri, Feb 2, 2018 at 1:46 PM, Ilya Biryukov 
> wrote:
>
>> Exactly. We should make sure we *don't* treat them as the same symbol.
>> But I would expect there USRs to be the same and that's what we use to
>> deduplicate.
>>
>>
>> On Fri, Feb 2, 2018 at 1:45 PM Sam McCall  wrote:
>>
>>> Right. And multiple TUs that *are* linked together would be fine too.
>>> But in that case I don't think we need to be clever about treating these
>>> as the same symbol. Indexing them twice is fine.
>>>
>>> On Fri, Feb 2, 2018 at 1:42 PM, Ilya Biryukov 
>>> wrote:
>>>
 In a single translation unit, yes. In multiple translation units that
 aren't linked together it's totally fine (may actually refer to different
 entities).


 On Fri, Feb 2, 2018 at 1:04 PM Sam McCall  wrote:

> Yeah this is just a bug in clang's pprinter. I'll fix it.
>
> If you give multiple C++ names to the same linker symbol using extern
> C, I'm pretty sure you're in UB land.
>
> On Fri, Feb 2, 2018, 12:04 Ilya Biryukov via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> ilya-biryukov added inline comments.
>>
>>
>> 
>> Comment at: clangd/index/SymbolCollector.cpp:73
>> +   Context = Context->getParent()) {
>> +if (llvm::isa(Context) ||
>> +llvm::isa(Context))
>> 
>> ioeric wrote:
>> > sammccall wrote:
>> > > I'm not sure this is always correct: at least clang accepts this
>> code:
>> > >
>> > >   namespace X { extern "C++" { int y; }}
>> > >
>> > > and you'll emit "y" instead of "X::y".
>> > >
>> > > I think the check you want is
>> > >
>> > >   if (Context->isTransparentContext() ||
>> Context->isInlineNamespace())
>> > > continue;
>> > >
>> > >  isTransparentContext will handle the Namespace and Enum cases as
>> you do below, including the enum/enum class distinction.
>> > >
>> > > (The code you have below is otherwise correct, I think - but a
>> reader needs to think about more separate cases in order to see that)
>> > In `namespace X { extern "C++" { int y; }}`, we would still want
>> `y` instead of `X::y` since C-style symbol doesn't have scope.
>> `printQualifiedName` also does the same thing printing `y`; I've added a
>> test case for `extern C`.
>> >
>> > I also realized we've been dropping C symbols in `shouldFilterDecl`
>> and fixed it in the same patch.
>> I think we want `X::y`, not `y`.
>>
>> Lookup still finds it inside the namespace and does not find it in
>> the global scope. So for our purposes they are actually inside the
>> namespace and have the qualified name of this namespace. Here's an 
>> example:
>> ```
>> namespace ns {
>> extern "C" int foo();
>> }
>>
>> void test() {
>>   ns::foo(); // ok
>>   foo(); // error
>>   ::foo(); // error
>> }
>> ```
>>
>> Note, however, that the tricky bit there is probably merging of the
>> symbols, as it means symbols with the same USR (they are the same for all
>> `extern "c"` declarations with the same name, right?) can have different
>> qualified names and we won't know which one to choose.
>>
>> ```
>> namespace a {
>>  extern "C" int foo();
>> }
>> namespace b {
>>   extern "C" int foo(); // probably same USR, different qname. Also,
>> possibly different types.
>> }
>> ```
>>
>>
>> Repository:
>>   rL LLVM
>>
>> https://reviews.llvm.org/D42796
>>
>>
>>
>>

 --
 Regards,
 Ilya Biryukov

>>>
>>>
>>
>> --
>> Regards,
>> Ilya Biryukov
>>
>
>

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

Re: [PATCH] D42796: [clangd] Skip inline namespace when collecting scopes for index symbols.

[Sam McCall via cfe-commits]

I was misreading: we set isIgnored if we're trying to generate a USR for a
linkagespecdecl itself (not a symbol in it).
For other e.g. a var, we check if the DC is a NamedDecl and if so, visit it
before visiting the var.
Linkagespec isn't a nameddecl, so this is a no-op. Result: things
(directly) under extern {} blocks don't get any outer scope info in their
USR. But not sure if this is intended (it's certainly not what *we* want!)

On Fri, Feb 2, 2018 at 2:05 PM, Ilya Biryukov  wrote:

> At least now we know they might cause problems. Thanks for digging into
> this.
>
>
> On Fri, Feb 2, 2018 at 1:53 PM Sam McCall  wrote:
>
>> My intuition was that the USRs would be different, that linkage would
>> either be included or not included from the USR, but it wouldn't affect
>> whether the namespace is included. (Reasoning: USRs model language
>> concepts, not linker ones)
>>
>> But we're both wrong. If I'm reading USRGeneration correctly, hitting a
>> linkage spec while walking the scope tree sets the "ignore result" flag
>> which signals the result is unusable (and short-circuits some paths that
>> finish computing it). This seems like it may cause problems for us :-)
>> I wonder why the tests didn't catch it, maybe I'm misreading.
>>
>> On Fri, Feb 2, 2018 at 1:46 PM, Ilya Biryukov 
>> wrote:
>>
>>> Exactly. We should make sure we *don't* treat them as the same symbol.
>>> But I would expect there USRs to be the same and that's what we use to
>>> deduplicate.
>>>
>>>
>>> On Fri, Feb 2, 2018 at 1:45 PM Sam McCall  wrote:
>>>
 Right. And multiple TUs that *are* linked together would be fine too.
 But in that case I don't think we need to be clever about treating
 these as the same symbol. Indexing them twice is fine.

 On Fri, Feb 2, 2018 at 1:42 PM, Ilya Biryukov 
 wrote:

> In a single translation unit, yes. In multiple translation units that
> aren't linked together it's totally fine (may actually refer to different
> entities).
>
>
> On Fri, Feb 2, 2018 at 1:04 PM Sam McCall 
> wrote:
>
>> Yeah this is just a bug in clang's pprinter. I'll fix it.
>>
>> If you give multiple C++ names to the same linker symbol using extern
>> C, I'm pretty sure you're in UB land.
>>
>> On Fri, Feb 2, 2018, 12:04 Ilya Biryukov via Phabricator <
>> revi...@reviews.llvm.org> wrote:
>>
>>> ilya-biryukov added inline comments.
>>>
>>>
>>> 
>>> Comment at: clangd/index/SymbolCollector.cpp:73
>>> +   Context = Context->getParent()) {
>>> +if (llvm::isa(Context) ||
>>> +llvm::isa(Context))
>>> 
>>> ioeric wrote:
>>> > sammccall wrote:
>>> > > I'm not sure this is always correct: at least clang accepts this
>>> code:
>>> > >
>>> > >   namespace X { extern "C++" { int y; }}
>>> > >
>>> > > and you'll emit "y" instead of "X::y".
>>> > >
>>> > > I think the check you want is
>>> > >
>>> > >   if (Context->isTransparentContext() ||
>>> Context->isInlineNamespace())
>>> > > continue;
>>> > >
>>> > >  isTransparentContext will handle the Namespace and Enum cases
>>> as you do below, including the enum/enum class distinction.
>>> > >
>>> > > (The code you have below is otherwise correct, I think - but a
>>> reader needs to think about more separate cases in order to see that)
>>> > In `namespace X { extern "C++" { int y; }}`, we would still want
>>> `y` instead of `X::y` since C-style symbol doesn't have scope.
>>> `printQualifiedName` also does the same thing printing `y`; I've added a
>>> test case for `extern C`.
>>> >
>>> > I also realized we've been dropping C symbols in
>>> `shouldFilterDecl` and fixed it in the same patch.
>>> I think we want `X::y`, not `y`.
>>>
>>> Lookup still finds it inside the namespace and does not find it in
>>> the global scope. So for our purposes they are actually inside the
>>> namespace and have the qualified name of this namespace. Here's an 
>>> example:
>>> ```
>>> namespace ns {
>>> extern "C" int foo();
>>> }
>>>
>>> void test() {
>>>   ns::foo(); // ok
>>>   foo(); // error
>>>   ::foo(); // error
>>> }
>>> ```
>>>
>>> Note, however, that the tricky bit there is probably merging of the
>>> symbols, as it means symbols with the same USR (they are the same for 
>>> all
>>> `extern "c"` declarations with the same name, right?) can have different
>>> qualified names and we won't know which one to choose.
>>>
>>> ```
>>> namespace a {
>>>  extern "C" int foo();
>>> }
>>> namespace b {
>>>   extern "C" int foo(); // probably same USR, different qname. Also,
>>> possibly different types.
>>> }
>>> ```
>>>
>>>
>>> Repository:
>>>   rL LLVM
>>>
>>> https://reviews.llvm.org

Re: [PATCH] D42796: [clangd] Skip inline namespace when collecting scopes for index symbols.

[Sam McCall via cfe-commits]

Talked to Ben, he thinks this is probably unintentional and that it's
probably OK to change.
I'll see if it breaks anything.

On Fri, Feb 2, 2018 at 2:11 PM, Sam McCall  wrote:

> I was misreading: we set isIgnored if we're trying to generate a USR for a
> linkagespecdecl itself (not a symbol in it).
> For other e.g. a var, we check if the DC is a NamedDecl and if so, visit
> it before visiting the var.
> Linkagespec isn't a nameddecl, so this is a no-op. Result: things
> (directly) under extern {} blocks don't get any outer scope info in their
> USR. But not sure if this is intended (it's certainly not what *we* want!)
>
> On Fri, Feb 2, 2018 at 2:05 PM, Ilya Biryukov 
> wrote:
>
>> At least now we know they might cause problems. Thanks for digging into
>> this.
>>
>>
>> On Fri, Feb 2, 2018 at 1:53 PM Sam McCall  wrote:
>>
>>> My intuition was that the USRs would be different, that linkage would
>>> either be included or not included from the USR, but it wouldn't affect
>>> whether the namespace is included. (Reasoning: USRs model language
>>> concepts, not linker ones)
>>>
>>> But we're both wrong. If I'm reading USRGeneration correctly, hitting a
>>> linkage spec while walking the scope tree sets the "ignore result" flag
>>> which signals the result is unusable (and short-circuits some paths that
>>> finish computing it). This seems like it may cause problems for us :-)
>>> I wonder why the tests didn't catch it, maybe I'm misreading.
>>>
>>> On Fri, Feb 2, 2018 at 1:46 PM, Ilya Biryukov 
>>> wrote:
>>>
 Exactly. We should make sure we *don't* treat them as the same symbol.
 But I would expect there USRs to be the same and that's what we use to
 deduplicate.


 On Fri, Feb 2, 2018 at 1:45 PM Sam McCall  wrote:

> Right. And multiple TUs that *are* linked together would be fine too.
> But in that case I don't think we need to be clever about treating
> these as the same symbol. Indexing them twice is fine.
>
> On Fri, Feb 2, 2018 at 1:42 PM, Ilya Biryukov 
> wrote:
>
>> In a single translation unit, yes. In multiple translation units that
>> aren't linked together it's totally fine (may actually refer to different
>> entities).
>>
>>
>> On Fri, Feb 2, 2018 at 1:04 PM Sam McCall 
>> wrote:
>>
>>> Yeah this is just a bug in clang's pprinter. I'll fix it.
>>>
>>> If you give multiple C++ names to the same linker symbol using
>>> extern C, I'm pretty sure you're in UB land.
>>>
>>> On Fri, Feb 2, 2018, 12:04 Ilya Biryukov via Phabricator <
>>> revi...@reviews.llvm.org> wrote:
>>>
 ilya-biryukov added inline comments.


 
 Comment at: clangd/index/SymbolCollector.cpp:73
 +   Context = Context->getParent()) {
 +if (llvm::isa(Context) ||
 +llvm::isa(Context))
 
 ioeric wrote:
 > sammccall wrote:
 > > I'm not sure this is always correct: at least clang accepts
 this code:
 > >
 > >   namespace X { extern "C++" { int y; }}
 > >
 > > and you'll emit "y" instead of "X::y".
 > >
 > > I think the check you want is
 > >
 > >   if (Context->isTransparentContext() ||
 Context->isInlineNamespace())
 > > continue;
 > >
 > >  isTransparentContext will handle the Namespace and Enum cases
 as you do below, including the enum/enum class distinction.
 > >
 > > (The code you have below is otherwise correct, I think - but a
 reader needs to think about more separate cases in order to see that)
 > In `namespace X { extern "C++" { int y; }}`, we would still want
 `y` instead of `X::y` since C-style symbol doesn't have scope.
 `printQualifiedName` also does the same thing printing `y`; I've added 
 a
 test case for `extern C`.
 >
 > I also realized we've been dropping C symbols in
 `shouldFilterDecl` and fixed it in the same patch.
 I think we want `X::y`, not `y`.

 Lookup still finds it inside the namespace and does not find it in
 the global scope. So for our purposes they are actually inside the
 namespace and have the qualified name of this namespace. Here's an 
 example:
 ```
 namespace ns {
 extern "C" int foo();
 }

 void test() {
   ns::foo(); // ok
   foo(); // error
   ::foo(); // error
 }
 ```

 Note, however, that the tricky bit there is probably merging of the
 symbols, as it means symbols with the same USR (they are the same for 
 all
 `extern "c"` declarations with the same name, right?) can have 
 different
 qualified names and we won't know which one to choose.
>

[PATCH] D41655: [clang-tidy] New check bugprone-unused-return-value

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh added inline comments.



Comment at: clang-tidy/bugprone/UnusedReturnValueCheck.cpp:36
+  Node.printQualifiedName(OS, Policy);
+  return llvm::Regex(RegExp).match(OS.str());
+}

Can we avoid creating the regex on each match? For example, by changing the 
parameter type to llvm::Regex. If we need the matcher at all - see the comment 
below.



Comment at: clang-tidy/bugprone/UnusedReturnValueCheck.cpp:45-48
+"^::std::async$|"
+"^::std::launder$|"
+"^::std::remove$|"
+"^::std::remove_if$|"

I strongly suspect that we could get away without regexs here. hasAnyName 
supports inline namespaces, so at least the first five entries here are 
covered. The main problem with std::unique_ptr<.*>::release is the need to 
match any template parameters. I *think*, we could adjust hasName to allow 
omitting template parameters (so that `std::unique_ptr::release` would match 
specializations of unique_ptr as well). The `empty` and `allocate` would need 
some research. Can we just list all specific classes where we care about 
`empty`? (Alternatively, can we match `empty` unqualified and check that it's 
somewhere inside `std`, but I don't like that much, since it would add 
inconsistency in how this check is configured.)



Comment at: clang-tidy/bugprone/UnusedReturnValueCheck.cpp:61
+  callExpr(callee(functionDecl(
+   matchesInlinedName(FuncRegex),
+   // Don't match void overloads of checked functions.

This is a rather expensive matcher and it is going to be run on each callExpr, 
which is a lot. Let's at least swap it with the `unless(returns(voidType()))` 
below to reduce the number of times it's called.


https://reviews.llvm.org/D41655



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

[PATCH] D41655: [clang-tidy] New check bugprone-unused-return-value

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh added inline comments.



Comment at: clang-tidy/bugprone/UnusedReturnValueCheck.cpp:45-48
+"^::std::async$|"
+"^::std::launder$|"
+"^::std::remove$|"
+"^::std::remove_if$|"

alexfh wrote:
> I strongly suspect that we could get away without regexs here. hasAnyName 
> supports inline namespaces, so at least the first five entries here are 
> covered. The main problem with std::unique_ptr<.*>::release is the need to 
> match any template parameters. I *think*, we could adjust hasName to allow 
> omitting template parameters (so that `std::unique_ptr::release` would match 
> specializations of unique_ptr as well). The `empty` and `allocate` would need 
> some research. Can we just list all specific classes where we care about 
> `empty`? (Alternatively, can we match `empty` unqualified and check that it's 
> somewhere inside `std`, but I don't like that much, since it would add 
> inconsistency in how this check is configured.)
A clarification: we could go with your current version and optimize this part 
later. But the option may start being used by someone and then will change - 
that would be nice to avoid.

Alternatively, we could switch to hasAnyName right away and leave only the 
functions that can be easily supported, and then figure out what to do with 
`release`, `allocate` and `empty`.

I'd probably prefer the latter.


https://reviews.llvm.org/D41655



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

[clang-tools-extra] r324079 - [clang-tidy] Don't reinvent the wheel, use existing log2 functions.

[Benjamin Kramer via cfe-commits]

Author: d0k
Date: Fri Feb  2 05:23:21 2018
New Revision: 324079

URL: http://llvm.org/viewvc/llvm-project?rev=324079&view=rev
Log:
[clang-tidy] Don't reinvent the wheel, use existing log2 functions.

This also makes the code ready for int128, even though I think it's
currently impossible to get an int128 into this code path.

Modified:
clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp

Modified: clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp?rev=324079&r1=324078&r2=324079&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp Fri 
Feb  2 05:23:21 2018
@@ -966,13 +966,6 @@ void RedundantExpressionCheck::checkRela
   }
 }
 
-unsigned intLog2(uint64_t X) {
-  unsigned Result = 0;
-  while (X >>= 1)
-++Result;
-  return Result;
-}
-
 void RedundantExpressionCheck::check(const MatchFinder::MatchResult &Result) {
   if (const auto *BinOp = Result.Nodes.getNodeAs("binary")) {
 // If the expression's constants are macros, check whether they are
@@ -1049,7 +1042,7 @@ void RedundantExpressionCheck::check(con
 // If ShiftingConst is shifted left with more bits than the position of the
 // leftmost 1 in the bit representation of AndValue, AndConstant is
 // ineffective.
-if (intLog2(AndValue.getExtValue()) >= ShiftingValue)
+if (AndValue.getActiveBits() > ShiftingValue)
   return;
 
 auto Diag = diag(BinaryAndExpr->getOperatorLoc(),


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

[clang-tools-extra] r324080 - [clang-tidy] Remove global constructor. No functionality change intended.

[Benjamin Kramer via cfe-commits]

Author: d0k
Date: Fri Feb  2 05:23:24 2018
New Revision: 324080

URL: http://llvm.org/viewvc/llvm-project?rev=324080&view=rev
Log:
[clang-tidy] Remove global constructor. No functionality change intended.

Modified:
clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp

Modified: clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp?rev=324080&r1=324079&r2=324080&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp Fri 
Feb  2 05:23:24 2018
@@ -37,8 +37,12 @@ namespace {
 using llvm::APSInt;
 } // namespace
 
-static const llvm::StringSet<> KnownBannedMacroNames = {"EAGAIN", 
"EWOULDBLOCK",
-"SIGCLD", "SIGCHLD"};
+static constexpr llvm::StringLiteral KnownBannedMacroNames[] = {
+"EAGAIN",
+"EWOULDBLOCK",
+"SIGCLD",
+"SIGCHLD",
+};
 
 static bool incrementWithoutOverflow(const APSInt &Value, APSInt &Result) {
   Result = Value;
@@ -318,13 +322,13 @@ AST_MATCHER(ConditionalOperator, conditi
 
 AST_MATCHER(Expr, isMacro) { return Node.getExprLoc().isMacroID(); }
 
-AST_MATCHER_P(Expr, expandedByMacro, llvm::StringSet<>, Names) {
+AST_MATCHER_P(Expr, expandedByMacro, ArrayRef, Names) {
   const SourceManager &SM = Finder->getASTContext().getSourceManager();
   const LangOptions &LO = Finder->getASTContext().getLangOpts();
   SourceLocation Loc = Node.getExprLoc();
   while (Loc.isMacroID()) {
 StringRef MacroName = Lexer::getImmediateMacroName(Loc, SM, LO);
-if (Names.count(MacroName))
+if (llvm::is_contained(Names, MacroName))
   return true;
 Loc = SM.getImmediateMacroCallerLoc(Loc);
   }


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

Re: [clang-tools-extra] r324079 - [clang-tidy] Don't reinvent the wheel, use existing log2 functions.

[Alexander Kornienko via cfe-commits]

Thanks! I knew there was something already, but I hadn't find it ;)

On Fri, Feb 2, 2018 at 2:23 PM, Benjamin Kramer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: d0k
> Date: Fri Feb  2 05:23:21 2018
> New Revision: 324079
>
> URL: http://llvm.org/viewvc/llvm-project?rev=324079&view=rev
> Log:
> [clang-tidy] Don't reinvent the wheel, use existing log2 functions.
>
> This also makes the code ready for int128, even though I think it's
> currently impossible to get an int128 into this code path.
>
> Modified:
> clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp
>
> Modified: clang-tools-extra/trunk/clang-tidy/misc/
> RedundantExpressionCheck.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/
> trunk/clang-tidy/misc/RedundantExpressionCheck.cpp?
> rev=324079&r1=324078&r2=324079&view=diff
> 
> ==
> --- clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp
> (original)
> +++ clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp
> Fri Feb  2 05:23:21 2018
> @@ -966,13 +966,6 @@ void RedundantExpressionCheck::checkRela
>}
>  }
>
> -unsigned intLog2(uint64_t X) {
> -  unsigned Result = 0;
> -  while (X >>= 1)
> -++Result;
> -  return Result;
> -}
> -
>  void RedundantExpressionCheck::check(const MatchFinder::MatchResult
> &Result) {
>if (const auto *BinOp = Result.Nodes.getNodeAs("binary"))
> {
>  // If the expression's constants are macros, check whether they are
> @@ -1049,7 +1042,7 @@ void RedundantExpressionCheck::check(con
>  // If ShiftingConst is shifted left with more bits than the position
> of the
>  // leftmost 1 in the bit representation of AndValue, AndConstant is
>  // ineffective.
> -if (intLog2(AndValue.getExtValue()) >= ShiftingValue)
> +if (AndValue.getActiveBits() > ShiftingValue)
>return;
>
>  auto Diag = diag(BinaryAndExpr->getOperatorLoc(),
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r324081 - [AST] namespace ns { extern "C" { int X; }} prints as "ns::X", not as "X"

[Sam McCall via cfe-commits]

Author: sammccall
Date: Fri Feb  2 05:34:47 2018
New Revision: 324081

URL: http://llvm.org/viewvc/llvm-project?rev=324081&view=rev
Log:
[AST] namespace ns { extern "C" { int X; }} prints as "ns::X", not as "X"

Modified:
cfe/trunk/lib/AST/Decl.cpp
cfe/trunk/unittests/AST/NamedDeclPrinterTest.cpp

Modified: cfe/trunk/lib/AST/Decl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Decl.cpp?rev=324081&r1=324080&r2=324081&view=diff
==
--- cfe/trunk/lib/AST/Decl.cpp (original)
+++ cfe/trunk/lib/AST/Decl.cpp Fri Feb  2 05:34:47 2018
@@ -1497,9 +1497,10 @@ void NamedDecl::printQualifiedName(raw_o
   using ContextsTy = SmallVector;
   ContextsTy Contexts;
 
-  // Collect contexts.
-  while (Ctx && isa(Ctx)) {
-Contexts.push_back(Ctx);
+  // Collect named contexts.
+  while (Ctx) {
+if (isa(Ctx))
+  Contexts.push_back(Ctx);
 Ctx = Ctx->getParent();
   }
 

Modified: cfe/trunk/unittests/AST/NamedDeclPrinterTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/AST/NamedDeclPrinterTest.cpp?rev=324081&r1=324080&r2=324081&view=diff
==
--- cfe/trunk/unittests/AST/NamedDeclPrinterTest.cpp (original)
+++ cfe/trunk/unittests/AST/NamedDeclPrinterTest.cpp Fri Feb  2 05:34:47 2018
@@ -173,3 +173,10 @@ TEST(NamedDeclPrinter, TestClassWithScop
 "A",
 "X::Y::A"));
 }
+
+TEST(NamedDeclPrinter, TestLinkageInNamespace) {
+  ASSERT_TRUE(PrintedWrittenNamedDeclCXX11Matches(
+"namespace X { extern \"C\" { int A; } }",
+"A",
+"X::A"));
+}


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

[clang-tools-extra] r324084 - [clang-tidy] Kill marco. No functionality change.

[Benjamin Kramer via cfe-commits]

Author: d0k
Date: Fri Feb  2 05:39:07 2018
New Revision: 324084

URL: http://llvm.org/viewvc/llvm-project?rev=324084&view=rev
Log:
[clang-tidy] Kill marco. No functionality change.

Modified:
clang-tools-extra/trunk/clang-tidy/android/CloexecAccept4Check.cpp
clang-tools-extra/trunk/clang-tidy/android/CloexecEpollCreate1Check.cpp
clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInit1Check.cpp
clang-tools-extra/trunk/clang-tidy/android/CloexecOpenCheck.cpp
clang-tools-extra/trunk/clang-tidy/android/CloexecSocketCheck.cpp
clang-tools-extra/trunk/clang-tidy/modernize/UseNullptrCheck.cpp
clang-tools-extra/trunk/clang-tidy/utils/ASTUtils.cpp

Modified: clang-tools-extra/trunk/clang-tidy/android/CloexecAccept4Check.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecAccept4Check.cpp?rev=324084&r1=324083&r2=324084&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/CloexecAccept4Check.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/android/CloexecAccept4Check.cpp Fri Feb  
2 05:39:07 2018
@@ -32,7 +32,7 @@ void CloexecAccept4Check::registerMatche
 }
 
 void CloexecAccept4Check::check(const MatchFinder::MatchResult &Result) {
-  insertMacroFlag(Result, /*MarcoFlag=*/"SOCK_CLOEXEC", /*ArgPos=*/3);
+  insertMacroFlag(Result, /*MacroFlag=*/"SOCK_CLOEXEC", /*ArgPos=*/3);
 }
 
 } // namespace android

Modified: 
clang-tools-extra/trunk/clang-tidy/android/CloexecEpollCreate1Check.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecEpollCreate1Check.cpp?rev=324084&r1=324083&r2=324084&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/CloexecEpollCreate1Check.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/android/CloexecEpollCreate1Check.cpp Fri 
Feb  2 05:39:07 2018
@@ -25,7 +25,7 @@ void CloexecEpollCreate1Check::registerM
 }
 
 void CloexecEpollCreate1Check::check(const MatchFinder::MatchResult &Result) {
-  insertMacroFlag(Result, /*MarcoFlag=*/"EPOLL_CLOEXEC", /*ArgPos=*/0);
+  insertMacroFlag(Result, /*MacroFlag=*/"EPOLL_CLOEXEC", /*ArgPos=*/0);
 }
 
 } // namespace android

Modified: 
clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInit1Check.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInit1Check.cpp?rev=324084&r1=324083&r2=324084&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInit1Check.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInit1Check.cpp Fri 
Feb  2 05:39:07 2018
@@ -25,7 +25,7 @@ void CloexecInotifyInit1Check::registerM
 }
 
 void CloexecInotifyInit1Check::check(const MatchFinder::MatchResult &Result) {
-  insertMacroFlag(Result, /*MarcoFlag=*/"IN_CLOEXEC", /*ArgPos=*/0);
+  insertMacroFlag(Result, /*MacroFlag=*/"IN_CLOEXEC", /*ArgPos=*/0);
 }
 
 } // namespace android

Modified: clang-tools-extra/trunk/clang-tidy/android/CloexecOpenCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecOpenCheck.cpp?rev=324084&r1=324083&r2=324084&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/CloexecOpenCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/android/CloexecOpenCheck.cpp Fri Feb  2 
05:39:07 2018
@@ -36,7 +36,7 @@ void CloexecOpenCheck::check(const Match
   const auto *FD = Result.Nodes.getNodeAs(FuncDeclBindingStr);
   assert(FD->param_size() > 1);
   int ArgPos = (FD->param_size() > 2) ? 2 : 1;
-  insertMacroFlag(Result, /*MarcoFlag=*/"O_CLOEXEC", ArgPos);
+  insertMacroFlag(Result, /*MacroFlag=*/"O_CLOEXEC", ArgPos);
 }
 
 } // namespace android

Modified: clang-tools-extra/trunk/clang-tidy/android/CloexecSocketCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecSocketCheck.cpp?rev=324084&r1=324083&r2=324084&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/CloexecSocketCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/android/CloexecSocketCheck.cpp Fri Feb  
2 05:39:07 2018
@@ -27,7 +27,7 @@ void CloexecSocketCheck::registerMatcher
 }
 
 void CloexecSocketCheck::check(const MatchFinder::MatchResult &Result) {
-  insertMacroFlag(Result, /*MarcoFlag=*/"SOCK_CLOEXEC", /*ArgPos=*/1);
+  insertMacroFlag(Result, /*MacroFlag=*/"SOCK_CLOEXEC", /*ArgPos=*/1);
 }
 
 } // namespace android

Modified: clang-tools-extra/trunk/clang-tidy/modernize/UseNullptrCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/UseNullptrCheck.cpp?rev=324084&r1=324083&r2=324084&view=diff
==

[clang-tools-extra] r324083 - [clang-tidy] Widen anonymous namespace.

[Benjamin Kramer via cfe-commits]

Author: d0k
Date: Fri Feb  2 05:39:00 2018
New Revision: 324083

URL: http://llvm.org/viewvc/llvm-project?rev=324083&view=rev
Log:
[clang-tidy] Widen anonymous namespace.

The matchers in this check are prone to create ODR violations otherwise.
No functionality change.

Modified:
clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp

Modified: clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp?rev=324083&r1=324082&r2=324083&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/misc/RedundantExpressionCheck.cpp Fri 
Feb  2 05:39:00 2018
@@ -32,10 +32,8 @@ using namespace clang::tidy::matchers;
 namespace clang {
 namespace tidy {
 namespace misc {
-
 namespace {
 using llvm::APSInt;
-} // namespace
 
 static constexpr llvm::StringLiteral KnownBannedMacroNames[] = {
 "EAGAIN",
@@ -629,6 +627,7 @@ static bool areExprsMacroAndNonMacro(con
 
   return LhsLoc.isMacroID() != RhsLoc.isMacroID();
 }
+} // namespace
 
 void RedundantExpressionCheck::registerMatchers(MatchFinder *Finder) {
   const auto AnyLiteralExpr = ignoringParenImpCasts(


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

[PATCH] D42645: New simple Checker for mmap calls

[David CARLIER via Phabricator via cfe-commits]

devnexen added a comment.

Updated. I ve tried (with few personal code) called as f/ptr, prots set via 
variable as well. Might sounds obvious to you though this is my first 
contribution to this :-) Any chance it get pushed ? Just asking I test 
constantly/carry patches between 3 machines :-)


Repository:
  rC Clang

https://reviews.llvm.org/D42645



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

[PATCH] D42361: [Tooling] Returns non-zero status code when files are skipped.

[Eric Liu via Phabricator via cfe-commits]

ioeric added a comment.

Ping?


Repository:
  rC Clang

https://reviews.llvm.org/D42361



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

[PATCH] D42641: [MinGW] Emit typeinfo locally for dllimported classes without key functions

[Hans Wennborg via Phabricator via cfe-commits]

hans added a comment.

In https://reviews.llvm.org/D42641#995845, @mstorsjo wrote:

> @hans I'd like to have this in 6.0 as well, to allow building Qt for windows 
> as DLLs.


Okay, let's just have it bake in trunk a little bit longer and then I'll merge.


Repository:
  rL LLVM

https://reviews.llvm.org/D42641



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

[PATCH] D41569: Summary:Constraint enforcement and diagnostics

[Saar Raz via Phabricator via cfe-commits]

saar.raz updated this revision to Diff 132576.
saar.raz added a comment.

- When a conjunction constraint expression has both sides false, both sides 
will now be diagnosed.

Updating D41569: Summary:
=

Constraint enforcement and diagnostics


Repository:
  rC Clang

https://reviews.llvm.org/D41569

Files:
  include/clang/AST/ExprCXX.h
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/Sema.h
  include/clang/Sema/TemplateDeduction.h
  lib/AST/ExprCXX.cpp
  lib/Sema/SemaOverload.cpp
  lib/Sema/SemaTemplate.cpp
  lib/Sema/SemaTemplateDeduction.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp
  test/CXX/concepts-ts/expr/expr.prim/expr.prim.id/p3.cpp
  
test/CXX/concepts-ts/temp/temp.constr/temp.constr.constr/function-templates.cpp
  
test/CXX/concepts-ts/temp/temp.constr/temp.constr.constr/non-function-templates.cpp
  
test/CXX/concepts-ts/temp/temp.constr/temp.constr.constr/partial-specializations.cpp

Index: test/CXX/concepts-ts/temp/temp.constr/temp.constr.constr/partial-specializations.cpp
===
--- /dev/null
+++ test/CXX/concepts-ts/temp/temp.constr/temp.constr.constr/partial-specializations.cpp
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -std=c++2a -fconcepts-ts -x c++ -verify %s
+
+namespace class_templates
+{
+  template requires sizeof(T) >= 4 // expected-note {{because 'sizeof(char) >= 4' (1 >= 4) evaluated to false}}
+  struct is_same { static constexpr bool value = false; };
+
+  template requires sizeof(T*) >= 4 && sizeof(T) >= 4
+  struct is_same { static constexpr bool value = true; };
+
+  static_assert(!is_same::value);
+  static_assert(!is_same::value);
+  static_assert(is_same::value);
+  static_assert(is_same::value); // expected-error {{constraints not satisfied for class template 'is_same' [with T = char, U = char]}}
+}
+
+namespace variable_templates
+{
+  template requires sizeof(T) >= 4
+  constexpr bool is_same_v = false;
+
+  template requires sizeof(T*) >= 4 && sizeof(T) >= 4
+  constexpr bool is_same_v = true;
+
+  static_assert(!is_same_v);
+  static_assert(!is_same_v);
+  static_assert(is_same_v);
+}
\ No newline at end of file
Index: test/CXX/concepts-ts/temp/temp.constr/temp.constr.constr/non-function-templates.cpp
===
--- /dev/null
+++ test/CXX/concepts-ts/temp/temp.constr/temp.constr.constr/non-function-templates.cpp
@@ -0,0 +1,79 @@
+// RUN: %clang_cc1 -std=c++2a -fconcepts-ts -x c++ -verify %s
+
+template requires sizeof(T) >= 2 // expected-note{{because 'sizeof(char) >= 2' (1 >= 2) evaluated to false}}
+struct A {
+  static constexpr int value = sizeof(T);
+};
+
+static_assert(A::value == 4);
+static_assert(A::value == 1); // expected-error{{constraints not satisfied for class template 'A' [with T = char]}}
+
+template
+  requires sizeof(T) != sizeof(U) // expected-note{{because 'sizeof(int) != sizeof(char [4])' (4 != 4) evaluated to false}}
+   && sizeof(T) >= 4 // expected-note{{because 'sizeof(char) >= 4' (1 >= 4) evaluated to false}}
+constexpr int SizeDiff = sizeof(T) > sizeof(U) ? sizeof(T) - sizeof(U) : sizeof(U) - sizeof(T);
+
+static_assert(SizeDiff == 3);
+static_assert(SizeDiff == 0); // expected-error{{constraints not satisfied for variable template 'SizeDiff' [with T = int, U = char [4]]}}
+static_assert(SizeDiff == 3); // expected-error{{constraints not satisfied for variable template 'SizeDiff' [with T = char, U = int]}}
+
+template
+  requires ((sizeof(Ts) == 4) || ...) // expected-note{{because 'sizeof(char) == 4' (1 == 4) evaluated to false}} expected-note{{'sizeof(long long) == 4' (8 == 4) evaluated to false}} expected-note{{'sizeof(int [20]) == 4' (80 == 4) evaluated to false}}
+constexpr auto SumSizes = (sizeof(Ts) + ...);
+
+static_assert(SumSizes == 13);
+static_assert(SumSizes == 89); // expected-error{{constraints not satisfied for variable template 'SumSizes' [with Ts = ]}}
+
+template
+concept IsBig = sizeof(T) > 100; // expected-note{{because 'sizeof(int) > 100' (4 > 100) evaluated to false}}
+
+template
+  requires IsBig // expected-note{{'int' does not satisfy 'IsBig'}}
+using BigPtr = T*;
+
+static_assert(sizeof(BigPtr)); // expected-error{{constraints not satisfied for alias template 'BigPtr' [with T = int]
+
+template requires T::value // expected-note{{because substituted constraint expression is ill-formed: type 'int' cannot be used prior to '::' because it has no members}}
+struct S { static constexpr bool value = true; };
+
+struct S2 { static constexpr bool value = true; };
+
+static_assert(S::value); // expected-error{{constraints not satisfied for class template 'S' [with T = int]}}
+static_assert(S::value);
+
+template
+struct AA
+{
+template requires sizeof(U) == sizeof(T) // expected-note{{because 'sizeof(int [2]) == sizeof(int)' (8 == 4) evaluated to false}}
+struct B
+{
+

r324093 - [Index] fix USR generation for namespace{extern{X}}

[Sam McCall via cfe-commits]

Author: sammccall
Date: Fri Feb  2 06:13:37 2018
New Revision: 324093

URL: http://llvm.org/viewvc/llvm-project?rev=324093&view=rev
Log:
[Index] fix USR generation for namespace{extern{X}}

Added:
cfe/trunk/test/Index/USR/linkage.cpp
Modified:
cfe/trunk/lib/Index/USRGeneration.cpp

Modified: cfe/trunk/lib/Index/USRGeneration.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Index/USRGeneration.cpp?rev=324093&r1=324092&r2=324093&view=diff
==
--- cfe/trunk/lib/Index/USRGeneration.cpp (original)
+++ cfe/trunk/lib/Index/USRGeneration.cpp Fri Feb  2 06:13:37 2018
@@ -103,7 +103,7 @@ public:
   void VisitUnresolvedUsingTypenameDecl(const UnresolvedUsingTypenameDecl *D);
 
   void VisitLinkageSpecDecl(const LinkageSpecDecl *D) {
-IgnoreResults = true;
+IgnoreResults = true; // No USRs for linkage specs themselves.
   }
 
   void VisitUsingDirectiveDecl(const UsingDirectiveDecl *D) {
@@ -192,6 +192,8 @@ bool USRGenerator::ShouldGenerateLocatio
 void USRGenerator::VisitDeclContext(const DeclContext *DC) {
   if (const NamedDecl *D = dyn_cast(DC))
 Visit(D);
+  else if (isa(DC)) // Linkage specs are transparent in USRs.
+VisitDeclContext(DC->getParent());
 }
 
 void USRGenerator::VisitFieldDecl(const FieldDecl *D) {

Added: cfe/trunk/test/Index/USR/linkage.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/USR/linkage.cpp?rev=324093&view=auto
==
--- cfe/trunk/test/Index/USR/linkage.cpp (added)
+++ cfe/trunk/test/Index/USR/linkage.cpp Fri Feb  2 06:13:37 2018
@@ -0,0 +1,7 @@
+// RUN: c-index-test core -print-source-symbols -- %s | FileCheck %s
+
+// Linkage decls are skipped in USRs for enclosed items.
+// Linkage decls themselves don't have USRs (no lines between ns and X).
+// CHECK: {{[0-9]+}}:11 | namespace/C++ | ns | c:@N@ns |
+// CHECK-NEXT: {{[0-9]+}}:33 | variable/C | X | c:@N@ns@X |
+namespace ns { extern "C" { int X; } }


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

[PATCH] D42841: [docs] Improve help for OpenMP options

[Alexey Bataev via Phabricator via cfe-commits]

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

1. Mark this patch as NFC.
2. LG


https://reviews.llvm.org/D42841



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

Re: [PATCH] D42796: [clangd] Skip inline namespace when collecting scopes for index symbols.

[Sam McCall via cfe-commits]

Fixed prettyprinter in r324081 and USRs in r324093.

On Fri, Feb 2, 2018 at 2:16 PM, Sam McCall  wrote:

> Talked to Ben, he thinks this is probably unintentional and that it's
> probably OK to change.
> I'll see if it breaks anything.
>
> On Fri, Feb 2, 2018 at 2:11 PM, Sam McCall  wrote:
>
>> I was misreading: we set isIgnored if we're trying to generate a USR for
>> a linkagespecdecl itself (not a symbol in it).
>> For other e.g. a var, we check if the DC is a NamedDecl and if so, visit
>> it before visiting the var.
>> Linkagespec isn't a nameddecl, so this is a no-op. Result: things
>> (directly) under extern {} blocks don't get any outer scope info in their
>> USR. But not sure if this is intended (it's certainly not what *we* want!)
>>
>> On Fri, Feb 2, 2018 at 2:05 PM, Ilya Biryukov 
>> wrote:
>>
>>> At least now we know they might cause problems. Thanks for digging into
>>> this.
>>>
>>>
>>> On Fri, Feb 2, 2018 at 1:53 PM Sam McCall  wrote:
>>>
 My intuition was that the USRs would be different, that linkage would
 either be included or not included from the USR, but it wouldn't affect
 whether the namespace is included. (Reasoning: USRs model language
 concepts, not linker ones)

 But we're both wrong. If I'm reading USRGeneration correctly, hitting a
 linkage spec while walking the scope tree sets the "ignore result" flag
 which signals the result is unusable (and short-circuits some paths that
 finish computing it). This seems like it may cause problems for us :-)
 I wonder why the tests didn't catch it, maybe I'm misreading.

 On Fri, Feb 2, 2018 at 1:46 PM, Ilya Biryukov 
 wrote:

> Exactly. We should make sure we *don't* treat them as the same symbol.
> But I would expect there USRs to be the same and that's what we use to
> deduplicate.
>
>
> On Fri, Feb 2, 2018 at 1:45 PM Sam McCall 
> wrote:
>
>> Right. And multiple TUs that *are* linked together would be fine too.
>> But in that case I don't think we need to be clever about treating
>> these as the same symbol. Indexing them twice is fine.
>>
>> On Fri, Feb 2, 2018 at 1:42 PM, Ilya Biryukov 
>> wrote:
>>
>>> In a single translation unit, yes. In multiple translation units
>>> that aren't linked together it's totally fine (may actually refer to
>>> different entities).
>>>
>>>
>>> On Fri, Feb 2, 2018 at 1:04 PM Sam McCall 
>>> wrote:
>>>
 Yeah this is just a bug in clang's pprinter. I'll fix it.

 If you give multiple C++ names to the same linker symbol using
 extern C, I'm pretty sure you're in UB land.

 On Fri, Feb 2, 2018, 12:04 Ilya Biryukov via Phabricator <
 revi...@reviews.llvm.org> wrote:

> ilya-biryukov added inline comments.
>
>
> 
> Comment at: clangd/index/SymbolCollector.cpp:73
> +   Context = Context->getParent()) {
> +if (llvm::isa(Context) ||
> +llvm::isa(Context))
> 
> ioeric wrote:
> > sammccall wrote:
> > > I'm not sure this is always correct: at least clang accepts
> this code:
> > >
> > >   namespace X { extern "C++" { int y; }}
> > >
> > > and you'll emit "y" instead of "X::y".
> > >
> > > I think the check you want is
> > >
> > >   if (Context->isTransparentContext() ||
> Context->isInlineNamespace())
> > > continue;
> > >
> > >  isTransparentContext will handle the Namespace and Enum cases
> as you do below, including the enum/enum class distinction.
> > >
> > > (The code you have below is otherwise correct, I think - but a
> reader needs to think about more separate cases in order to see that)
> > In `namespace X { extern "C++" { int y; }}`, we would still want
> `y` instead of `X::y` since C-style symbol doesn't have scope.
> `printQualifiedName` also does the same thing printing `y`; I've 
> added a
> test case for `extern C`.
> >
> > I also realized we've been dropping C symbols in
> `shouldFilterDecl` and fixed it in the same patch.
> I think we want `X::y`, not `y`.
>
> Lookup still finds it inside the namespace and does not find it in
> the global scope. So for our purposes they are actually inside the
> namespace and have the qualified name of this namespace. Here's an 
> example:
> ```
> namespace ns {
> extern "C" int foo();
> }
>
> void test() {
>   ns::foo(); // ok
>   foo(); // error
>   ::foo(); // error
> }
> ```
>
> Note, however, that the tricky bit there is probably merging of
> the symbol

[PATCH] D42645: New simple Checker for mmap calls

[David CARLIER via Phabricator via cfe-commits]

devnexen updated this revision to Diff 132578.

Repository:
  rC Clang

https://reviews.llvm.org/D42645

Files:
  include/clang/StaticAnalyzer/Checkers/Checkers.td
  lib/StaticAnalyzer/Checkers/CMakeLists.txt
  lib/StaticAnalyzer/Checkers/MmapWriteExecChecker.cpp

Index: lib/StaticAnalyzer/Checkers/MmapWriteExecChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/MmapWriteExecChecker.cpp
+++ lib/StaticAnalyzer/Checkers/MmapWriteExecChecker.cpp
@@ -0,0 +1,78 @@
+// MmapWriteExecChecker.cpp - Check for the prot argument -===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// This checker tests the 3rd argument of mmap's calls to check if
+// it is writable and executable in the same time. It's somehow
+// an optional checker since for example in JIT libraries it is pretty common.
+//
+//===--===//
+
+#include "ClangSACheckers.h"
+
+#include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
+#include "clang/StaticAnalyzer/Core/Checker.h"
+#include "clang/StaticAnalyzer/Core/CheckerManager.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
+
+using namespace clang;
+using namespace ento;
+using llvm::APSInt;
+
+namespace {
+class MmapWriteExecChecker : public Checker {
+  CallDescription MmapFn;
+  static int ProtWrite;
+  static int ProtExec;
+  mutable std::unique_ptr BT;
+public:
+  MmapWriteExecChecker() : MmapFn("mmap") {}
+  void checkPreCall(const CallEvent &Call, CheckerContext &C) const;
+};
+}
+
+int MmapWriteExecChecker::ProtWrite = 0x02;
+int MmapWriteExecChecker::ProtExec  = 0x04;
+
+void MmapWriteExecChecker::checkPreCall(const CallEvent &Call,
+ CheckerContext &C) const {
+  if (Call.isCalled(MmapFn)) {
+if (Call.getNumArgs() < 3)
+  return;
+
+llvm::Triple Triple = C.getASTContext().getTargetInfo().getTriple();
+
+if (Triple.isOSGlibc())
+  ProtExec = 0x01;
+
+SVal ProtVal = Call.getArgSVal(2); 
+Optional ProtLoc = ProtVal.getAs();
+int64_t Prot = ProtLoc->getValue().getSExtValue();
+
+if ((Prot & (ProtWrite | ProtExec)) == (ProtWrite | ProtExec)) {
+  if (!BT)
+BT.reset(new BugType(this, "W^X check fails, Write Exec prot flags set", "Security"));
+
+  ExplodedNode *N = C.generateNonFatalErrorNode();
+  if (!N)
+return;
+
+  auto Report = llvm::make_unique(
+  *BT, "Both PROT_WRITE and PROT_EXEC flags had been set. It can "
+   "leads to exploitable memory regions, overwritten with malicious code"
+ , N);
+  Report->addRange(Call.getArgSourceRange(2));
+  C.emitReport(std::move(Report));
+}
+  }
+}
+
+void ento::registerMmapWriteExecChecker(CheckerManager &mgr) {
+  mgr.registerChecker();
+}
Index: lib/StaticAnalyzer/Checkers/CMakeLists.txt
===
--- lib/StaticAnalyzer/Checkers/CMakeLists.txt
+++ lib/StaticAnalyzer/Checkers/CMakeLists.txt
@@ -49,6 +49,7 @@
   MallocChecker.cpp
   MallocOverflowSecurityChecker.cpp
   MallocSizeofChecker.cpp
+  MmapWriteExecChecker.cpp
   MisusedMovedObjectChecker.cpp
   MPI-Checker/MPIBugReporter.cpp
   MPI-Checker/MPIChecker.cpp
Index: include/clang/StaticAnalyzer/Checkers/Checkers.td
===
--- include/clang/StaticAnalyzer/Checkers/Checkers.td
+++ include/clang/StaticAnalyzer/Checkers/Checkers.td
@@ -86,7 +86,7 @@
 
 // The APIModeling package is for checkers that model APIs and don't perform
 // any diagnostics. These checkers are always turned on; this package is
-// intended for API modeling that is not controlled by the target triple.
+// intended for API modeling that is not controlled by the the target triple.
 def APIModeling : Package<"apiModeling">, Hidden;
 def GoogleAPIModeling : Package<"google">, InPackage;
 
@@ -394,6 +394,10 @@
   def FloatLoopCounter : Checker<"FloatLoopCounter">,
 HelpText<"Warn on using a floating point value as a loop counter (CERT: FLP30-C, FLP30-CPP)">,
 DescFile<"CheckSecuritySyntaxOnly.cpp">;
+
+  def MmapWriteExecChecker : Checker<"MmapWriteExec">,
+HelpText<"Check if mmap() call is not both writable and executable">,
+DescFile<"MmapWriteExecChecker.cpp">;
 }
 
 let ParentPackage = SecurityAlpha in {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D41655: [clang-tidy] New check bugprone-unused-return-value

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In https://reviews.llvm.org/D41655#980672, @khuttun wrote:

> The checker reports 7 warnings on LLVM + Clang code bases, all on 
> std::unique_ptr::release:
>
> lib/Bitcode/Reader/BitReader.cpp:114:3
>
> - release() called on moved-from unique_ptr
> - no harm, just unnecessary


Agreed.

> lib/ExecutionEngine/ExecutionEngine.cpp:149:7
> 
> - release() called before erasing unique_ptr from a container
> - false positive?

False positive.

> lib/Target/AMDGPU/GCNIterativeScheduler.cpp:196:5
> 
> - release() called before assigning new pointer to unique_ptr
> - false positive?

False positive, but a bad code smell given that the assignment operator will 
perform the release.

> lib/AsmParser/LLParser.cpp:855:3
> 
> - get() + release() could be replaced with release()
> 
>   tools/clang/lib/Lex/ModuleMap.cpp:791:3
> - false positive?

False positive.

> tools/clang/tools/extra/clangd/Compiler.cpp:61:3
> 
> - get() + release() could potentially be replaced with release()?

False positive.

> unittests/Support/Casting.cpp:144:3
> 
> - release() called to avoid calling delete on a pointer to global object
> - false positive?

False positive.

From what I can tell of these reports, they almost all boil down to ignoring 
the call to `release()` because the pointer is no longer owned by the 
`unique_ptr`. This is a pretty reasonable code pattern, but it also seems 
reasonable to expect users to cast the result to `void` to silence the warning, 
so I think this is fine. Have you checked any other large C++ code bases, like 
Qt or boost?


https://reviews.llvm.org/D41655



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

[PATCH] D42730: [clang-tidy]] Add check for use of types/classes/functions from header which are deprecated and removed in C++17

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang-tidy/modernize/AvoidFunctionalCheck.h:19
+
+/// Check for several deprecated types and classes from  header
+///

alexfh wrote:
> aaron.ballman wrote:
> > alexfh wrote:
> > > aaron.ballman wrote:
> > > > alexfh wrote:
> > > > > Quuxplusone wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > alexfh wrote:
> > > > > > > > alexfh wrote:
> > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > massberg wrote:
> > > > > > > > > > > massberg wrote:
> > > > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > > > Missing full stop at the end of the sentence.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Why should this modernize check be limited to 
> > > > > > > > > > > > > ``? Just like we have a "deprecated 
> > > > > > > > > > > > > headers" check, perhaps this should be a "deprecated 
> > > > > > > > > > > > > APIs" check?
> > > > > > > > > > > > Added full stop.
> > > > > > > > > > > > 
> > > > > > > > > > > > I'm not sure if this check should be limited to 
> > > > > > > > > > > >  or be extended to a full 'deprecated API' 
> > > > > > > > > > > > check.
> > > > > > > > > > > > This change is just a start, several more types and 
> > > > > > > > > > > > classes which are removed from  will 
> > > > > > > > > > > > follow, e.g:
> > > > > > > > > > > > 
> > > > > > > > > > > > - std::ptr_fun, std::mem_fun, std::mem_fun_ref
> > > > > > > > > > > > - std::bind1st, std::bind2nd
> > > > > > > > > > > > - std::unary_function, std::binary_function
> > > > > > > > > > > > - std::pointer_to_unary_function, 
> > > > > > > > > > > > std::pointer_to_binary_function, std::mem_fun_t, 
> > > > > > > > > > > > std::mem_fun1_t, std::const_mem_fun_t, 
> > > > > > > > > > > > - std::const_mem_fun1_t, std::mem_fun_ref_t, 
> > > > > > > > > > > > std::mem_fun1_ref_t, std::const_mem_fun_ref_t, 
> > > > > > > > > > > > std::const_mem_fun1_ref_t
> > > > > > > > > > > > - std::binder1st, std::binder2nd
> > > > > > > > > > > > 
> > > > > > > > > > > > As these are a bunch of functions and types, in my eyes 
> > > > > > > > > > > > a check just for  is fine. But I'm also 
> > > > > > > > > > > > fine with a general 'deprecated API' check.
> > > > > > > > > > > > Alex, can you comment on this?
> > > > > > > > > > > There are already other checks for functions which are 
> > > > > > > > > > > removed in C++17 like modernize-replace-random-shuffle.
> > > > > > > > > > > So I think having an separate check for functions and 
> > > > > > > > > > > types removed from  would be OK.
> > > > > > > > > > You've hit the nail on the head for what I'm trying to 
> > > > > > > > > > avoid -- we shouldn't have multiple checks unless they do 
> > > > > > > > > > drastically different things. Having a deprecated check 
> > > > > > > > > > like this really only makes sense for APIs that are 
> > > > > > > > > > deprecated but aren't uniformly marked as `[[deprecated]]` 
> > > > > > > > > > by the library. As such, I think we really only need one 
> > > > > > > > > > check for this rather than splitting it out over multiple 
> > > > > > > > > > checks -- the existing check functionality could be rolled 
> > > > > > > > > > into this one and its check become an alias.
> > > > > > > > > > I'm not sure if this check should be limited to 
> > > > > > > > > >  or be extended to a full 'deprecated API' 
> > > > > > > > > > check.
> > > > > > > > > 
> > > > > > > > > IIUC, it should be possible to implement fixits at least for 
> > > > > > > > > some use cases here. My impression was that Jens was at least 
> > > > > > > > > considering to work on fixits. The other check mentioned here 
> > > > > > > > > - `modernize-replace-random-shuffle` already implements 
> > > > > > > > > fixits. Fixits are specific to the API and some codebases may 
> > > > > > > > > have better replacement APIs than what the standard suggests, 
> > > > > > > > > so different users may want to apply different set of the 
> > > > > > > > > fixes. Given all that, I wouldn't just merge all of the 
> > > > > > > > > checks dealing with deprecated APIs. Splitting them at least 
> > > > > > > > > by header seems like a good start, maybe even finer 
> > > > > > > > > granularity may be needed in some cases.
> > > > > > > > TL;DR "they do drastically different things" is the case for 
> > > > > > > > this check and modernize-replace-random-shuffle.
> > > > > > > I disagree that they do drastically different things or that 
> > > > > > > fix-its are a problem. Some of these APIs have replacements, 
> > > > > > > others do not. At the end of the day, the basics are the same: 
> > > > > > > the functionality is deprecated and you should consider a 
> > > > > > > replacement. Sometimes we know that replacement up front, other 
> > > > > > > times we don't. I don't think we should make users reach for a 
> > > > > > > per-header file answer to that problem unless it provides them 
> > > > > > 

[PATCH] D42829: Emit label names according to -discard-value-names.

[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 a small formatting nit in the test.




Comment at: test/CodeGenCXX/discard-name-values.cpp:7
 
-// CHECK: ret i32 %bar
-// DISCARDVALUE: ret i32 %0
+extern "C" void branch();
+

Indentation is a bit off here. Actually, it seems off for much of the file -- 
can you reindent the comments as well?


https://reviews.llvm.org/D42829



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

[PATCH] D42844: [OpenCL] Add test for atomic pointers.

[Mariya Podchishchaeva via Phabricator via cfe-commits]

Fznamznon created this revision.
Herald added subscribers: cfe-commits, Anastasia, yaxunl.

Repository:
  rC Clang

https://reviews.llvm.org/D42844

Files:
  test/SemaOpenCL/atomic-ptr.cl


Index: test/SemaOpenCL/atomic-ptr.cl
===
--- /dev/null
+++ test/SemaOpenCL/atomic-ptr.cl
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -O0 -cl-std=CL2.0 -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+void __kernel test_atomic_ptrs(void){
+  // Null assignment to atomic pointer is legal
+  local atomic_int *p1 = 0;
+
+  // Array aliasing is permitted
+  local atomic_int a[16];
+  local atomic_int *p2 = a;
+
+  // Test pointer arithmetics
+  local atomic_int *p3 = p1 + 1;
+
+  // Test implicit cast to pointer
+  local atomic_int *p4 = a + 1;
+}


Index: test/SemaOpenCL/atomic-ptr.cl
===
--- /dev/null
+++ test/SemaOpenCL/atomic-ptr.cl
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -O0 -cl-std=CL2.0 -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+void __kernel test_atomic_ptrs(void){
+  // Null assignment to atomic pointer is legal
+  local atomic_int *p1 = 0;
+
+  // Array aliasing is permitted
+  local atomic_int a[16];
+  local atomic_int *p2 = a;
+
+  // Test pointer arithmetics
+  local atomic_int *p3 = p1 + 1;
+
+  // Test implicit cast to pointer
+  local atomic_int *p4 = a + 1;
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42736: [DebugInfo] Improvements to representation of enumeration types (PR36168)

[Momchil Velikov via Phabricator via cfe-commits]

chill updated this revision to Diff 132587.
chill added a comment.

Changes, relative to the previous revision:

- a few tweaks to the tests


https://reviews.llvm.org/D42736

Files:
  lib/CodeGen/CGDebugInfo.cpp
  test/CodeGen/debug-info-enum.cpp
  test/CodeGenCXX/debug-info-enum-class.cpp
  test/CodeGenCXX/debug-info-enum.cpp
  test/Modules/ModuleDebugInfo.cpp

Index: test/Modules/ModuleDebugInfo.cpp
===
--- test/Modules/ModuleDebugInfo.cpp
+++ test/Modules/ModuleDebugInfo.cpp
@@ -48,7 +48,7 @@
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type,
 // CHECK-NOT:  name:
 // CHECK-SAME: )
-// CHECK: !DIEnumerator(name: "e5", value: 5)
+// CHECK: !DIEnumerator(name: "e5", value: 5, isUnsigned: true)
 
 // CHECK: !DIDerivedType(tag: DW_TAG_typedef, name: "B",
 // no mangled name here yet.
Index: test/CodeGenCXX/debug-info-enum.cpp
===
--- test/CodeGenCXX/debug-info-enum.cpp
+++ test/CodeGenCXX/debug-info-enum.cpp
@@ -11,7 +11,7 @@
 // CHECK-SAME:  identifier: "_ZTSN5test11eE"
 // CHECK: [[TEST1]] = !DINamespace(name: "test1"
 // CHECK: [[TEST1_ENUMS]] = !{[[TEST1_E:![0-9]*]]}
-// CHECK: [[TEST1_E]] = !DIEnumerator(name: "E", value: 0)
+// CHECK: [[TEST1_E]] = !DIEnumerator(name: "E", value: 0, isUnsigned: true)
 enum e { E };
 void foo() {
   int v = E;
Index: test/CodeGenCXX/debug-info-enum-class.cpp
===
--- test/CodeGenCXX/debug-info-enum-class.cpp
+++ test/CodeGenCXX/debug-info-enum-class.cpp
@@ -15,20 +15,20 @@
 // CHECK-SAME: baseType: ![[INT:[0-9]+]]
 // CHECK-SAME: size: 32
 // CHECK-NOT:  offset:
-// CHECK-NOT:  flags:
+// CHECK-SAME: flags: DIFlagFixedEnum
 // CHECK-SAME: ){{$}}
 // CHECK: ![[INT]] = !DIBasicType(name: "int"
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "B"
 // CHECK-SAME: line: 4
 // CHECK-SAME: baseType: ![[ULONG:[0-9]+]]
 // CHECK-SAME: size: 64
 // CHECK-NOT:  offset:
-// CHECK-NOT:  flags:
+// CHECK-SAME: flags: DIFlagFixedEnum
 // CHECK-SAME: ){{$}}
 // CHECK: ![[ULONG]] = !DIBasicType(name: "long unsigned int"
 // CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "C"
 // CHECK-SAME: line: 5
-// CHECK-NOT:  baseType:
+// CHECK-SAME: baseType: ![[ULONG:[0-9]+]]
 // CHECK-SAME: size: 32
 // CHECK-NOT:  offset:
 // CHECK-NOT:  flags:
Index: test/CodeGen/debug-info-enum.cpp
===
--- /dev/null
+++ test/CodeGen/debug-info-enum.cpp
@@ -0,0 +1,80 @@
+// RUN: %clang -target x86_64-linux -g -S -emit-llvm -o - %s | FileCheck %s
+
+// Test enumerator value representation for each possible underlying integer
+// type; test the integer type and FixedEnum flags are as expected.
+enum class E0 : signed char {
+  A0 = -128,
+  B0 = 127,
+} x0;
+// CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E0"
+// CHECK-SAME: baseType: ![[SCHAR:[0-9]+]]
+// CHECK-SAME: DIFlagFixedEnum
+// CHECK: ![[SCHAR]] = !DIBasicType(name: "signed char", size: 8, encoding: DW_ATE_signed_char)
+// CHECK: !DIEnumerator(name: "A0", value: -128)
+// CHECK: !DIEnumerator(name: "B0", value: 127)
+
+enum class E1 : unsigned char { A1 = 255 } x1;
+// CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E1"
+// CHECK-SAME: baseType: ![[UCHAR:[0-9]+]]
+// CHECK-SAME: DIFlagFixedEnum
+// CHECK: ![[UCHAR]] = !DIBasicType(name: "unsigned char", size: 8, encoding: DW_ATE_unsigned_char)
+// CHECK: !DIEnumerator(name: "A1", value: 255, isUnsigned: true)
+
+enum class E2 : signed short {
+  A2 = -32768,
+  B2 = 32767,
+} x2;
+// CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E2"
+// CHECK-SAME: baseType: ![[SHORT:[0-9]+]]
+// CHECK-SAME: DIFlagFixedEnum
+// CHECK: ![[SHORT]] = !DIBasicType(name: "short", size: 16, encoding: DW_ATE_signed)
+// CHECK: !DIEnumerator(name: "A2", value: -32768)
+// CHECK: !DIEnumerator(name: "B2", value: 32767)
+
+enum class E3 : unsigned short { A3 = 65535 } x3;
+// CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E3"
+// CHECK-SAME: baseType: ![[USHORT:[0-9]+]]
+// CHECK-SAME: DIFlagFixedEnum
+// CHECK: ![[USHORT]] = !DIBasicType(name: "unsigned short", size: 16, encoding: DW_ATE_unsigned)
+// CHECK: !DIEnumerator(name: "A3", value: 65535, isUnsigned: true)
+
+enum class E4 : signed int { A4 = -2147483648, B4 = 2147483647 } x4;
+// CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E4"
+// CHECK-SAME: baseType: ![[INT:[0-9]+]]
+// CHECK-SAME: DIFlagFixedEnum
+// CHECK: ![[INT]] = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+// CHECK: !DIEnumerator(name: "A4", value: -2147483648)
+// 

[clang-tools-extra] r324097 - [clang-tidy] ObjC ARC objects should not trigger performance-unnecessary-value-param

[Ben Hamilton via cfe-commits]

Author: benhamilton
Date: Fri Feb  2 07:34:33 2018
New Revision: 324097

URL: http://llvm.org/viewvc/llvm-project?rev=324097&view=rev
Log:
[clang-tidy] ObjC ARC objects should not trigger 
performance-unnecessary-value-param

Summary:
The following Objective-C code currently incorrectly triggers
clang-tidy's performance-unnecessary-value-param check:

```
% cat /tmp/performance-unnecessary-value-param-arc.m
void foo(id object) { }

clang-tidy /tmp/performance-unnecessary-value-param-arc.m
-checks=-\*,performance-unnecessary-value-param -- -xobjective-c
-fobjc-abi-version=2 -fobjc-arc
1 warning generated.
/src/llvm/tools/clang/tools/extra/test/clang-tidy/performance-unnecessary-value-param-arc.m:10:13:
warning: the parameter 'object' is copied for each invocation but only
used as a const reference; consider making it a const reference
[performance-unnecessary-value-param]
void foo(id object) { }
 ~~ ^
 const &
```

This is wrong for a few reasons:

1) Objective-C doesn't have references, so `const &` is not going to help
2) ARC heavily optimizes the "expensive" copy which triggers the warning

This fixes the issue by disabling the warning for non-C++, as well as
disabling it for objects under ARC memory management for
Objective-C++.

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

Test Plan: New tests added. Ran tests with `make -j12 check-clang-tools`.

Reviewers: alexfh, hokein

Reviewed By: hokein

Subscribers: stephanemoore, klimek, xazax.hun, cfe-commits, Wizard

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

Added:

clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.m

clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.mm
Modified:

clang-tools-extra/trunk/clang-tidy/performance/UnnecessaryValueParamCheck.cpp
clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/performance/UnnecessaryValueParamCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/performance/UnnecessaryValueParamCheck.cpp?rev=324097&r1=324096&r2=324097&view=diff
==
--- 
clang-tools-extra/trunk/clang-tidy/performance/UnnecessaryValueParamCheck.cpp 
(original)
+++ 
clang-tools-extra/trunk/clang-tidy/performance/UnnecessaryValueParamCheck.cpp 
Fri Feb  2 07:34:33 2018
@@ -79,6 +79,10 @@ UnnecessaryValueParamCheck::UnnecessaryV
   Options.getLocalOrGlobal("IncludeStyle", "llvm"))) {}
 
 void UnnecessaryValueParamCheck::registerMatchers(MatchFinder *Finder) {
+  // This check is specific to C++ and doesn't apply to languages like
+  // Objective-C.
+  if (!getLangOpts().CPlusPlus)
+return;
   const auto ExpensiveValueParamDecl =
   parmVarDecl(hasType(hasCanonicalType(allOf(
   unless(referenceType()), 
matchers::isExpensiveToCopy(,

Modified: clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.cpp?rev=324097&r1=324096&r2=324097&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.cpp Fri Feb  2 07:34:33 
2018
@@ -45,7 +45,8 @@ llvm::Optional isExpensiveToCopy(Q
 return llvm::None;
   return !Type.isTriviallyCopyableType(Context) &&
  !classHasTrivialCopyAndDestroy(Type) &&
- !hasDeletedCopyConstructor(Type);
+ !hasDeletedCopyConstructor(Type) &&
+ !Type->isObjCLifetimeType();
 }
 
 bool recordIsTriviallyDefaultConstructible(const RecordDecl &RecordDecl,

Added: 
clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.m
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.m?rev=324097&view=auto
==
--- 
clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.m
 (added)
+++ 
clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.m
 Fri Feb  2 07:34:33 2018
@@ -0,0 +1,16 @@
+// RUN: clang-tidy %s -checks=-*,performance-unnecessary-value-param -- \
+// RUN:   -xobjective-c -fobjc-abi-version=2 -fobjc-arc | count 0
+
+#if !__has_feature(objc_arc)
+#error Objective-C ARC not enabled as expected
+#endif
+
+// Passing an Objective-C ARC-managed object to a C function should
+// not raise performance-unnecessary-value-param.
+void foo(id object) { }
+
+// Same for explcitly non-ARC-managed Objective-C objects.
+void bar(__unsafe_unretained id object) { }
+
+// Same for Objective-c classes.
+void baz(Class c) { }

Added: 
clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.mm
URL: 
http://llvm.org/viewvc/llvm-project/clan

[PATCH] D42812: [clang-tidy] ObjC ARC objects should not trigger performance-unnecessary-value-param

[Ben Hamilton via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL324097: [clang-tidy] ObjC ARC objects should not trigger 
performance-unnecessary-value… (authored by benhamilton, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

https://reviews.llvm.org/D42812

Files:
  clang-tools-extra/trunk/clang-tidy/performance/UnnecessaryValueParamCheck.cpp
  clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.cpp
  
clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.m
  
clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.mm


Index: 
clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.m
===
--- 
clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.m
+++ 
clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.m
@@ -0,0 +1,16 @@
+// RUN: clang-tidy %s -checks=-*,performance-unnecessary-value-param -- \
+// RUN:   -xobjective-c -fobjc-abi-version=2 -fobjc-arc | count 0
+
+#if !__has_feature(objc_arc)
+#error Objective-C ARC not enabled as expected
+#endif
+
+// Passing an Objective-C ARC-managed object to a C function should
+// not raise performance-unnecessary-value-param.
+void foo(id object) { }
+
+// Same for explcitly non-ARC-managed Objective-C objects.
+void bar(__unsafe_unretained id object) { }
+
+// Same for Objective-c classes.
+void baz(Class c) { }
Index: 
clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.mm
===
--- 
clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.mm
+++ 
clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.mm
@@ -0,0 +1,16 @@
+// RUN: clang-tidy %s -checks=-*,performance-unnecessary-value-param -- \
+// RUN:   -xobjective-c++ -fobjc-abi-version=2 -fobjc-arc | count 0
+
+#if !__has_feature(objc_arc)
+#error Objective-C ARC not enabled as expected
+#endif
+
+// Passing an Objective-C ARC-managed object to a C function should
+// not raise performance-unnecessary-value-param.
+void foo(id object) { }
+
+// Same for explcitly non-ARC-managed Objective-C objects.
+void bar(__unsafe_unretained id object) { }
+
+// Same for Objective-c classes.
+void baz(Class c) { }
Index: 
clang-tools-extra/trunk/clang-tidy/performance/UnnecessaryValueParamCheck.cpp
===
--- 
clang-tools-extra/trunk/clang-tidy/performance/UnnecessaryValueParamCheck.cpp
+++ 
clang-tools-extra/trunk/clang-tidy/performance/UnnecessaryValueParamCheck.cpp
@@ -79,6 +79,10 @@
   Options.getLocalOrGlobal("IncludeStyle", "llvm"))) {}
 
 void UnnecessaryValueParamCheck::registerMatchers(MatchFinder *Finder) {
+  // This check is specific to C++ and doesn't apply to languages like
+  // Objective-C.
+  if (!getLangOpts().CPlusPlus)
+return;
   const auto ExpensiveValueParamDecl =
   parmVarDecl(hasType(hasCanonicalType(allOf(
   unless(referenceType()), 
matchers::isExpensiveToCopy(,
Index: clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.cpp
===
--- clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.cpp
+++ clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.cpp
@@ -45,7 +45,8 @@
 return llvm::None;
   return !Type.isTriviallyCopyableType(Context) &&
  !classHasTrivialCopyAndDestroy(Type) &&
- !hasDeletedCopyConstructor(Type);
+ !hasDeletedCopyConstructor(Type) &&
+ !Type->isObjCLifetimeType();
 }
 
 bool recordIsTriviallyDefaultConstructible(const RecordDecl &RecordDecl,


Index: clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.m
===
--- clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.m
+++ clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.m
@@ -0,0 +1,16 @@
+// RUN: clang-tidy %s -checks=-*,performance-unnecessary-value-param -- \
+// RUN:   -xobjective-c -fobjc-abi-version=2 -fobjc-arc | count 0
+
+#if !__has_feature(objc_arc)
+#error Objective-C ARC not enabled as expected
+#endif
+
+// Passing an Objective-C ARC-managed object to a C function should
+// not raise performance-unnecessary-value-param.
+void foo(id object) { }
+
+// Same for explcitly non-ARC-managed Objective-C objects.
+void bar(__unsafe_unretained id object) { }
+
+// Same for Objective-c classes.
+void baz(Class c) { }
Index: clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.mm
===
--- clang-tools-extra/trunk/test/clang-tidy/performance-unnecessary-value-param-arc.mm
+++ clang-tools-extra/trunk/test/clang-t

[PATCH] D42736: [DebugInfo] Improvements to representation of enumeration types (PR36168)

[Momchil Velikov via Phabricator via cfe-commits]

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



Comment at: test/CodeGen/debug-info-enum.cpp:2
+// RUN: %clang -target x86_64-linux -g -S -emit-llvm -o - %s | FileCheck %s
+enum class E0 : signed char {
+  A0 = -128,

dblaikie wrote:
> Could you summarize the purpose of each of these tests (possibly in a comment 
> above the enum in each case) - there look to be more test cases than I'd 
> imagine being necessary, but I haven't carefully analyzed them.
> 
> For example: I wouldn't expect to test every integer type, if the code 
> handling them is general enough to be demonstrated by one or two cases?
Yes, in hindsight, there are more tests that strictly necessary, I just 
enumerated all the different integer type sizes cross signed/usigned, for some 
there were no errors, for some there were always errors, for some there were 
sometimes errors only sometimes (i.e. depending on compiler target and/or 
options).




Comment at: test/CodeGen/debug-info-enum.cpp:6-10
+// CHECK: !DICompositeType(tag: DW_TAG_enumeration_type, name: "E0"
+// CHECK-SAME: flags: DIFlagFixedEnum
+// CHECK: !DIBasicType(name: "signed char", size: 8, encoding: 
DW_ATE_signed_char)
+// CHECK: !DIEnumerator(name: "A0", value: -128)
+// CHECK: !DIEnumerator(name: "B0", value: 127)

dblaikie wrote:
> Rather than relying on specific ordering of output, generally you should test 
> that the actual references across different metadata records are correct (eg: 
> check that the DICompositeType's member list elements are the DIEnumerators 
> (use named matches, rather than hardcoding the metadata node numbers))
> 
> Though, admittedly, this is a lot easier to read as-is. 
I've done that, to some extent, making sure each enumeration refers to the 
expected underlying type. Not idea how to do that completely independent of 
order.


https://reviews.llvm.org/D42736



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

[PATCH] D42730: [clang-tidy]] Add check for use of types/classes/functions from header which are deprecated and removed in C++17

[Jens Massberg via Phabricator via cfe-commits]

massberg updated this revision to Diff 132592.
massberg marked an inline comment as done.

https://reviews.llvm.org/D42730

Files:
  clang-tidy/modernize/AvoidFunctionalCheck.cpp
  clang-tidy/modernize/AvoidFunctionalCheck.h
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/ModernizeTidyModule.cpp
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/modernize-avoid-functional.rst
  test/clang-tidy/modernize-avoid-functional.cpp

Index: test/clang-tidy/modernize-avoid-functional.cpp
===
--- test/clang-tidy/modernize-avoid-functional.cpp
+++ test/clang-tidy/modernize-avoid-functional.cpp
@@ -0,0 +1,63 @@
+// RUN: %check_clang_tidy %s modernize-avoid-functional %t
+
+namespace std {
+
+template 
+class binary_function {};
+
+template 
+class unary_function {};
+
+template 
+class pointer_to_unary_function
+: public std::unary_function {  // NOLINT
+};
+
+template 
+pointer_to_unary_function ptr_fun(Result (*f)(Arg)) {
+  pointer_to_unary_function Nothing;
+  return Nothing;
+}
+
+template 
+class mem_fun_t {};
+
+template 
+mem_fun_t mem_fun(Res (T::*f)()) {}
+
+}  // namespace std
+
+// CHECK-MESSAGES: [[@LINE+1]]:25: warning: 'binary_function' is deprecated in C++11 and removed in C++17 [modernize-avoid-functional]
+class BinaryTestClass : public std::binary_function {
+ public:
+  BinaryTestClass();
+};
+
+// CHECK-MESSAGES: [[@LINE+1]]:24: warning: 'unary_function' is deprecated in C++11 and removed in C++17 [modernize-avoid-functional]
+class UnaryTestClass : public std::unary_function {
+ public:
+  UnaryTestClass();
+};
+
+class TestClass {
+ public:
+  int test() { return 1; }
+};
+
+// CHECK-MESSAGES: [[@LINE+2]]:31: warning: 'unary_function' is deprecated in C++11 and removed in C++17 [modernize-avoid-functional]
+class AnotherUnaryTestClass : public TestClass,
+  public std::unary_function {
+ public:
+  AnotherUnaryTestClass();
+};
+
+
+int simpleFunc(int X) { return X + 1; };
+
+void foo(void) {
+// CHECK-MESSAGES: [[@LINE+1]]:3: warning: 'std::ptr_fun' is deprecated in C++11 and removed in C++17 [modernize-avoid-functional]
+  std::ptr_fun(simpleFunc);
+
+// CHECK-MESSAGES: [[@LINE+1]]:3: warning: 'std::mem_fun' is deprecated in C++11 and removed in C++17 [modernize-avoid-functional]
+  std::mem_fun(&TestClass::test);
+}
Index: docs/clang-tidy/checks/modernize-avoid-functional.rst
===
--- docs/clang-tidy/checks/modernize-avoid-functional.rst
+++ docs/clang-tidy/checks/modernize-avoid-functional.rst
@@ -0,0 +1,14 @@
+.. title:: clang-tidy - modernize-avoid-functional
+
+modernize-avoid-functional
+==
+
+Warns if types, classes and functions from '' header which are
+  deprecated in C++11 and removed in C++17 are used.
+In particular, this check warns if one of the following deprecated objects is
+used:
+
+-  'std::unary_function'
+-  'std::binary_function'
+-  'std::ptr_fun'
+-  'std::mem_fun'
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -154,6 +154,7 @@
misc-unused-raii
misc-unused-using-decls
modernize-avoid-bind
+   modernize-avoid-functional
modernize-deprecated-headers
modernize-loop-convert
modernize-make-shared
Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -89,6 +89,12 @@
   using decltype specifiers and lambda with otherwise unutterable 
   return types.
 
+- New `modernize-avoid-functional
+  `_ check
+
+  Warns if types, classes and functions from '' header which are
+  deprecated in C++11 and removed in C++17 are used.
+
 - New alias `hicpp-avoid-goto
   `_ to 
   `cppcoreguidelines-avoid-goto `_
Index: clang-tidy/modernize/ModernizeTidyModule.cpp
===
--- clang-tidy/modernize/ModernizeTidyModule.cpp
+++ clang-tidy/modernize/ModernizeTidyModule.cpp
@@ -11,6 +11,7 @@
 #include "../ClangTidyModule.h"
 #include "../ClangTidyModuleRegistry.h"
 #include "AvoidBindCheck.h"
+#include "AvoidFunctionalCheck.h"
 #include "DeprecatedHeadersCheck.h"
 #include "LoopConvertCheck.h"
 #include "MakeSharedCheck.h"
@@ -45,6 +46,8 @@
 public:
   void addCheckFactories(ClangTidyCheckFactories &CheckFactories) override {
 CheckFactories.registerCheck("modernize-avoid-bind");
+CheckFactories.registerCheck(
+"modernize-avoid-functional");
 CheckFactories.registerCheck(
 "modernize-deprecated-headers");
 

r324098 - [CodeGen][va_args] Correct Vector Struct va-arg 'in_reg' code gen

[Erich Keane via cfe-commits]

Author: erichkeane
Date: Fri Feb  2 07:53:35 2018
New Revision: 324098

URL: http://llvm.org/viewvc/llvm-project?rev=324098&view=rev
Log:
[CodeGen][va_args] Correct Vector Struct va-arg 'in_reg' code gen

When trying to track down a different bug, we discovered
that calling __builtin_va_arg on a vec3f type caused
the SROA pass to issue a warning that there was an illegal
access.

Further research showed that the vec3f type is
alloca'ed as size '12', but the _builtin_va_arg code
on x86_64 was always loading this out of registers as
{double, double}. Thus, the 2nd store into the vec3f
was storing in bytes 12-15!

This patch alters the original implementation which always
assumed {double, double} to use the actual coerced type
instead, so the LLVM-IR generated is a load/GEP/store of
a <2 x float> and a float, rather than a double and a double.

Tests were added for all combinations I could think of that
would fit in 2 FP registers, and all work exactly as expected.

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

Added:
cfe/trunk/test/CodeGen/x86_64-floatvectors.c
Modified:
cfe/trunk/lib/CodeGen/TargetInfo.cpp

Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=324098&r1=324097&r2=324098&view=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Fri Feb  2 07:53:35 2018
@@ -3790,17 +3790,18 @@ Address X86_64ABIInfo::EmitVAArg(CodeGen
 Address RegAddrHi =
   CGF.Builder.CreateConstInBoundsByteGEP(RegAddrLo,
  CharUnits::fromQuantity(16));
-llvm::Type *DoubleTy = CGF.DoubleTy;
-llvm::StructType *ST = llvm::StructType::get(DoubleTy, DoubleTy);
+llvm::Type *ST = AI.canHaveCoerceToType()
+ ? AI.getCoerceToType()
+ : llvm::StructType::get(CGF.DoubleTy, CGF.DoubleTy);
 llvm::Value *V;
 Address Tmp = CGF.CreateMemTemp(Ty);
 Tmp = CGF.Builder.CreateElementBitCast(Tmp, ST);
-V = CGF.Builder.CreateLoad(
-   CGF.Builder.CreateElementBitCast(RegAddrLo, DoubleTy));
+V = CGF.Builder.CreateLoad(CGF.Builder.CreateElementBitCast(
+RegAddrLo, ST->getStructElementType(0)));
 CGF.Builder.CreateStore(V,
CGF.Builder.CreateStructGEP(Tmp, 0, CharUnits::Zero()));
-V = CGF.Builder.CreateLoad(
-   CGF.Builder.CreateElementBitCast(RegAddrHi, DoubleTy));
+V = CGF.Builder.CreateLoad(CGF.Builder.CreateElementBitCast(
+RegAddrHi, ST->getStructElementType(1)));
 CGF.Builder.CreateStore(V,
   CGF.Builder.CreateStructGEP(Tmp, 1, CharUnits::fromQuantity(8)));
 

Added: cfe/trunk/test/CodeGen/x86_64-floatvectors.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/x86_64-floatvectors.c?rev=324098&view=auto
==
--- cfe/trunk/test/CodeGen/x86_64-floatvectors.c (added)
+++ cfe/trunk/test/CodeGen/x86_64-floatvectors.c Fri Feb  2 07:53:35 2018
@@ -0,0 +1,131 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | \
+// RUN:   FileCheck %s
+
+// This test validates that the inreg branch generation for __builtin_va_arg 
+// does not exceed the alloca size of the type, which can cause the SROA pass 
to
+// eliminate the assignment.
+
+typedef struct { float x, y, z; } vec3f;
+
+double Vec3FTest(__builtin_va_list ap) {
+  vec3f vec = __builtin_va_arg(ap, vec3f);
+  return vec.x + vec.y + vec.z;
+}
+// CHECK: define double @Vec3FTest
+// CHECK: vaarg.in_reg:
+// CHECK: [[Vec3FLoad1:%.*]] = load <2 x float>, <2 x float>*
+// CHECK: [[Vec3FGEP1:%.*]] = getelementptr inbounds { <2 x float>, float }, { 
<2 x float>, float }* {{%.*}}, i32 0, i32 0
+// CHECK: store <2 x float> [[Vec3FLoad1]], <2 x float>* [[Vec3FGEP1]]
+// CHECK: [[Vec3FLoad2:%.*]] = load float, float*
+// CHECK: [[Vec3FGEP2:%.*]] = getelementptr inbounds { <2 x float>, float }, { 
<2 x float>, float }* {{%.*}}, i32 0, i32 1
+// CHECK: store float [[Vec3FLoad2]], float* [[Vec3FGEP2]]
+// CHECK: vaarg.in_mem:
+
+
+typedef struct { float x, y, z, q; } vec4f;
+
+double Vec4FTest(__builtin_va_list ap) {
+  vec4f vec = __builtin_va_arg(ap, vec4f);
+  return vec.x + vec.y + vec.z + vec.q;
+}
+// CHECK: define double @Vec4FTest
+// CHECK: vaarg.in_reg:
+// CHECK: [[Vec4FLoad1:%.*]] = load <2 x float>, <2 x float>*
+// CHECK: [[Vec4FGEP1:%.*]] = getelementptr inbounds { <2 x float>, <2 x 
float> }, { <2 x float>, <2 x float> }* {{%.*}}, i32 0, i32 0
+// CHECK: store <2 x float> [[Vec4FLoad1]], <2 x float>* [[Vec4FGEP1]]
+// CHECK: [[Vec4FLoad2:%.*]] = load <2 x float>, <2 x float>*
+// CHECK: [[Vec4FGEP2:%.*]] = getelementptr inbounds { <2 x float>, <2 x 
float> }, { <2 x float>, <2 x float> }* {{%.*}}, i32 0, i32 1
+// CHECK: store <2 x float> [[Vec4FLoad2]], <2 

[PATCH] D42811: [CodeGen][va_args] Correct Vector Struct va-arg 'in_reg' code gen

[Erich Keane via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL324098: [CodeGen][va_args] Correct Vector Struct va-arg 
'in_reg' code gen (authored by erichkeane, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D42811?vs=132452&id=132594#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D42811

Files:
  cfe/trunk/lib/CodeGen/TargetInfo.cpp
  cfe/trunk/test/CodeGen/x86_64-floatvectors.c

Index: cfe/trunk/test/CodeGen/x86_64-floatvectors.c
===
--- cfe/trunk/test/CodeGen/x86_64-floatvectors.c
+++ cfe/trunk/test/CodeGen/x86_64-floatvectors.c
@@ -0,0 +1,131 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | \
+// RUN:   FileCheck %s
+
+// This test validates that the inreg branch generation for __builtin_va_arg 
+// does not exceed the alloca size of the type, which can cause the SROA pass to
+// eliminate the assignment.
+
+typedef struct { float x, y, z; } vec3f;
+
+double Vec3FTest(__builtin_va_list ap) {
+  vec3f vec = __builtin_va_arg(ap, vec3f);
+  return vec.x + vec.y + vec.z;
+}
+// CHECK: define double @Vec3FTest
+// CHECK: vaarg.in_reg:
+// CHECK: [[Vec3FLoad1:%.*]] = load <2 x float>, <2 x float>*
+// CHECK: [[Vec3FGEP1:%.*]] = getelementptr inbounds { <2 x float>, float }, { <2 x float>, float }* {{%.*}}, i32 0, i32 0
+// CHECK: store <2 x float> [[Vec3FLoad1]], <2 x float>* [[Vec3FGEP1]]
+// CHECK: [[Vec3FLoad2:%.*]] = load float, float*
+// CHECK: [[Vec3FGEP2:%.*]] = getelementptr inbounds { <2 x float>, float }, { <2 x float>, float }* {{%.*}}, i32 0, i32 1
+// CHECK: store float [[Vec3FLoad2]], float* [[Vec3FGEP2]]
+// CHECK: vaarg.in_mem:
+
+
+typedef struct { float x, y, z, q; } vec4f;
+
+double Vec4FTest(__builtin_va_list ap) {
+  vec4f vec = __builtin_va_arg(ap, vec4f);
+  return vec.x + vec.y + vec.z + vec.q;
+}
+// CHECK: define double @Vec4FTest
+// CHECK: vaarg.in_reg:
+// CHECK: [[Vec4FLoad1:%.*]] = load <2 x float>, <2 x float>*
+// CHECK: [[Vec4FGEP1:%.*]] = getelementptr inbounds { <2 x float>, <2 x float> }, { <2 x float>, <2 x float> }* {{%.*}}, i32 0, i32 0
+// CHECK: store <2 x float> [[Vec4FLoad1]], <2 x float>* [[Vec4FGEP1]]
+// CHECK: [[Vec4FLoad2:%.*]] = load <2 x float>, <2 x float>*
+// CHECK: [[Vec4FGEP2:%.*]] = getelementptr inbounds { <2 x float>, <2 x float> }, { <2 x float>, <2 x float> }* {{%.*}}, i32 0, i32 1
+// CHECK: store <2 x float> [[Vec4FLoad2]], <2 x float>* [[Vec4FGEP2]]
+// CHECK: vaarg.in_mem:
+
+typedef struct { double x, y; } vec2d;
+
+double Vec2DTest(__builtin_va_list ap) {
+  vec2d vec = __builtin_va_arg(ap, vec2d);
+  return vec.x + vec.y;
+}
+// CHECK: define double @Vec2DTest
+// CHECK: vaarg.in_reg:
+// CHECK: [[Vec2DLoad1:%.*]] = load double, double*
+// CHECK: [[Vec2DGEP1:%.*]] = getelementptr inbounds { double, double }, { double, double }* {{%.*}}, i32 0, i32 0
+// CHECK: store double [[Vec2DLoad1]], double* [[Vec2DGEP1]]
+// CHECK: [[Vec2DLoad2:%.*]] = load double, double*
+// CHECK: [[Vec2DGEP2:%.*]] = getelementptr inbounds { double, double }, { double, double }* {{%.*}}, i32 0, i32 1
+// CHECK: store double [[Vec2DLoad2]], double* [[Vec2DGEP2]]
+// CHECK: vaarg.in_mem:
+
+typedef struct {
+  float x, y;
+  double z;
+} vec2f1d;
+
+double Vec2F1DTest(__builtin_va_list ap) {
+  vec2f1d vec = __builtin_va_arg(ap, vec2f1d);
+  return vec.x + vec.y + vec.z;
+}
+// CHECK: define double @Vec2F1DTest
+// CHECK: vaarg.in_reg:
+// CHECK: [[Vec2F1DLoad1:%.*]] = load <2 x float>, <2 x float>*
+// CHECK: [[Vec2F1DGEP1:%.*]] = getelementptr inbounds { <2 x float>, double }, { <2 x float>, double }* {{%.*}}, i32 0, i32 0
+// CHECK: store <2 x float> [[Vec2F1DLoad1]], <2 x float>* [[Vec2F1DGEP1]]
+// CHECK: [[Vec2F1DLoad2:%.*]] = load double, double*
+// CHECK: [[Vec2F1DGEP2:%.*]] = getelementptr inbounds { <2 x float>, double }, { <2 x float>, double }* {{%.*}}, i32 0, i32 1
+// CHECK: store double [[Vec2F1DLoad2]], double* [[Vec2F1DGEP2]]
+// CHECK: vaarg.in_mem:
+
+typedef struct {
+  double x;
+  float y, z;
+} vec1d2f;
+
+double Vec1D2FTest(__builtin_va_list ap) {
+  vec1d2f vec = __builtin_va_arg(ap, vec1d2f);
+  return vec.x + vec.y + vec.z;
+}
+// CHECK: define double @Vec1D2FTest
+// CHECK: vaarg.in_reg:
+// CHECK: [[Vec1D2FLoad1:%.*]] = load double, double*
+// CHECK: [[Vec1D2FGEP1:%.*]] = getelementptr inbounds { double, <2 x float> }, { double, <2 x float> }* {{%.*}}, i32 0, i32 0
+// CHECK: store double [[Vec1D2FLoad1]], double* [[Vec1D2FGEP1]]
+// CHECK: [[Vec1D2FLoad2:%.*]] = load <2 x float>, <2 x float>*
+// CHECK: [[Vec1D2FGEP2:%.*]] = getelementptr inbounds { double, <2 x float> }, { double, <2 x float> }* {{%.*}}, i32 0, i32 1
+// CHECK: store <2 x float> [[Vec1D2FLoad2]], <2 x float>* [[Vec1D2FGEP2]]
+// CHECK: vaarg.in_mem:
+
+typedef struct {
+  float x;
+  double z;
+} vec1f1d;
+
+double Vec1F1DTest(__builtin_va_list ap) {
+  vec1f1d vec = __builtin_va

[PATCH] D40787: [clang-tidy] Replace the usage of std::uncaught_exception with std::uncaught_exceptions

[Daniel Kolozsvari via Phabricator via cfe-commits]

koldaniel updated this revision to Diff 132595.

https://reviews.llvm.org/D40787

Files:
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/ModernizeTidyModule.cpp
  clang-tidy/modernize/UseUncaughtExceptionsCheck.cpp
  clang-tidy/modernize/UseUncaughtExceptionsCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/modernize-use-uncaught-exceptions.rst
  test/clang-tidy/modernize-use-uncaught-exceptions.cpp

Index: test/clang-tidy/modernize-use-uncaught-exceptions.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-use-uncaught-exceptions.cpp
@@ -0,0 +1,79 @@
+// RUN: %check_clang_tidy %s modernize-use-uncaught-exceptions %t -- -- -std=c++1z
+#define MACRO std::uncaught_exception
+// CHECK-FIXES: #define MACRO std::uncaught_exception
+
+bool uncaught_exception() {
+  return 0;
+}
+
+namespace std {
+  bool uncaught_exception() {
+return false;
+  }
+
+  int uncaught_exceptions() {
+return 0;
+  }
+}
+
+template 
+bool doSomething(T t) { 
+  return t();
+  // CHECK-FIXES: return t();
+}
+
+template 
+bool doSomething2() { 
+  return T();
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: 'std::uncaught_exception' is deprecated, use 'std::uncaught_exceptions' instead
+  // CHECK-FIXES: return T();
+}
+
+void no_warn() {
+
+  uncaught_exception();
+  // CHECK-FIXES: uncaught_exception();
+
+  doSomething(uncaught_exception);
+  // CHECK-FIXES: doSomething(uncaught_exception);
+}
+
+void warn() {
+
+  std::uncaught_exception();
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: 'std::uncaught_exception' is deprecated, use 'std::uncaught_exceptions' instead
+  // CHECK-FIXES: std::uncaught_exceptions();
+
+  using std::uncaught_exception;
+  // CHECK-MESSAGES: [[@LINE-1]]:14: warning: 'std::uncaught_exception' is deprecated, use 'std::uncaught_exceptions' instead
+  // CHECK-FIXES: using std::uncaught_exceptions;
+
+  uncaught_exception();
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: 'std::uncaught_exception' is deprecated, use 'std::uncaught_exceptions' instead
+  // CHECK-FIXES: uncaught_exceptions();
+
+  bool b{uncaught_exception()};
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: 'std::uncaught_exception' is deprecated, use 'std::uncaught_exceptions' instead
+  // CHECK-FIXES: bool b{std::uncaught_exceptions() > 0};
+
+  MACRO();
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: 'std::uncaught_exception' is deprecated, use 'std::uncaught_exceptions' instead
+  // CHECK-FIXES: MACRO();
+
+  doSomething(std::uncaught_exception);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: 'std::uncaught_exception' is deprecated, use 'std::uncaught_exceptions' instead
+  // CHECK-FIXES: doSomething(std::uncaught_exception);
+
+  doSomething(uncaught_exception);
+  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: 'std::uncaught_exception' is deprecated, use 'std::uncaught_exceptions' instead
+  // CHECK-FIXES: doSomething(uncaught_exception);
+
+  bool (*foo)();
+  foo = &uncaught_exception;
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: 'std::uncaught_exception' is deprecated, use 'std::uncaught_exceptions' instead
+  // CHECK-FIXES: foo = &uncaught_exception;
+
+  doSomething2();
+  // CHECK-MESSAGES: [[@LINE-1]]:16: warning: 'std::uncaught_exception' is deprecated, use 'std::uncaught_exceptions' instead
+  // CHECK-FIXES: doSomething2();
+}
Index: docs/clang-tidy/checks/modernize-use-uncaught-exceptions.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/modernize-use-uncaught-exceptions.rst
@@ -0,0 +1,64 @@
+.. title:: clang-tidy - modernize-use-uncaught-exceptions
+
+modernize-use-uncaught-exceptions
+
+
+This check will warn on calls to ``std::uncaught_exception`` and replace them with
+calls to ``std::uncaught_exceptions``, since ``std::uncaught_exception`` was deprecated
+in C++17.
+
+Below are a few examples of what kind of occurrences will be found and what
+they will be replaced with.
+
+.. code-block:: c++
+
+#define MACRO1 std::uncaught_exception
+#define MACRO2 std::uncaught_exception
+
+int uncaught_exception() {
+return 0;
+}
+
+int main() {
+int res;
+
+res = uncaught_exception();
+// No warning, since it is not the deprecated function from namespace std
+
+res = MACRO2();
+// Warning, but will not be replaced
+
+res = std::uncaught_exception();
+// Warning and replaced
+
+using std::uncaught_exception;
+// Warning and replaced
+
+res = uncaught_exception();
+// Warning and replaced
+}
+
+After applying the fixes the code will look like the following:
+
+.. code-block:: c++
+
+#define MACRO1 std::uncaught_exception
+#define MACRO2 std::uncaught_exception
+
+int uncaught_exception() {
+return 0;
+}
+
+int main() {
+int res;
+
+res = uncaught_exception();
+
+

[PATCH] D41318: Start setting dso_local in clang

[Sean Fertile via Phabricator via cfe-commits]

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

LGTM


https://reviews.llvm.org/D41318



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

r324102 - [AMDGPU] Switch to the new addr space mapping by default

[Yaxun Liu via cfe-commits]

Author: yaxunl
Date: Fri Feb  2 08:08:24 2018
New Revision: 324102

URL: http://llvm.org/viewvc/llvm-project?rev=324102&view=rev
Log:
[AMDGPU] Switch to the new addr space mapping by default

This requires corresponding llvm change.

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

Modified:
cfe/trunk/lib/Basic/Targets/AMDGPU.cpp
cfe/trunk/lib/Basic/Targets/AMDGPU.h
cfe/trunk/test/CodeGen/address-space.c
cfe/trunk/test/CodeGen/default-address-space.c
cfe/trunk/test/CodeGen/target-data.c
cfe/trunk/test/CodeGenOpenCL/address-spaces.cl
cfe/trunk/test/CodeGenOpenCL/amdgpu-abi-struct-coerce.cl
cfe/trunk/test/CodeGenOpenCL/amdgpu-alignment.cl
cfe/trunk/test/CodeGenOpenCL/amdgpu-debug-info-variable-expression.cl
cfe/trunk/test/CodeGenOpenCL/amdgpu-enqueue-kernel.cl
cfe/trunk/test/CodeGenOpenCL/amdgpu-env-amdgiz.cl
cfe/trunk/test/CodeGenOpenCL/amdgpu-nullptr.cl
cfe/trunk/test/CodeGenOpenCL/blocks.cl
cfe/trunk/test/CodeGenOpenCL/byval.cl
cfe/trunk/test/CodeGenOpenCL/opencl_types.cl
cfe/trunk/test/CodeGenOpenCL/size_t.cl

Modified: cfe/trunk/lib/Basic/Targets/AMDGPU.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/AMDGPU.cpp?rev=324102&r1=324101&r2=324102&view=diff
==
--- cfe/trunk/lib/Basic/Targets/AMDGPU.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/AMDGPU.cpp Fri Feb  2 08:08:24 2018
@@ -30,7 +30,7 @@ namespace targets {
 
 static const char *const DataLayoutStringR600 =
 "e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128"
-"-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64";
+"-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-A5";
 
 static const char *const DataLayoutStringSIPrivateIsZero =
 "e-p:32:32-p1:64:64-p2:64:64-p3:32:32-p4:64:64-p5:32:32"

Modified: cfe/trunk/lib/Basic/Targets/AMDGPU.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/AMDGPU.h?rev=324102&r1=324101&r2=324102&view=diff
==
--- cfe/trunk/lib/Basic/Targets/AMDGPU.h (original)
+++ cfe/trunk/lib/Basic/Targets/AMDGPU.h Fri Feb  2 08:08:24 2018
@@ -77,10 +77,7 @@ class LLVM_LIBRARY_VISIBILITY AMDGPUTarg
 return TT.getArch() == llvm::Triple::amdgcn;
   }
 
-  static bool isGenericZero(const llvm::Triple &TT) {
-return TT.getEnvironmentName() == "amdgiz" ||
-   TT.getEnvironmentName() == "amdgizcl";
-  }
+  static bool isGenericZero(const llvm::Triple &TT) { return true; }
 
 public:
   AMDGPUTargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts);

Modified: cfe/trunk/test/CodeGen/address-space.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/address-space.c?rev=324102&r1=324101&r2=324102&view=diff
==
--- cfe/trunk/test/CodeGen/address-space.c (original)
+++ cfe/trunk/test/CodeGen/address-space.c Fri Feb  2 08:08:24 2018
@@ -1,5 +1,4 @@
 // RUN: %clang_cc1 -triple x86_64-apple-darwin -emit-llvm < %s | FileCheck 
-check-prefixes=CHECK,X86,GIZ %s
-// RUN: %clang_cc1 -triple amdgcn -emit-llvm < %s | FileCheck 
-check-prefixes=CHECK,PIZ %s
 // RUN: %clang_cc1 -triple amdgcn---amdgiz -emit-llvm < %s | FileCheck 
-check-prefixes=CHECK,AMDGIZ,GIZ %s
 
 // CHECK: @foo = common addrspace(1) global
@@ -26,11 +25,9 @@ __attribute__((address_space(2))) int *A
 // CHECK-LABEL: define void @test3()
 // X86: load i32 addrspace(2)*, i32 addrspace(2)** @B
 // AMDGIZ: load i32 addrspace(2)*, i32 addrspace(2)** addrspacecast (i32 
addrspace(2)* addrspace(1)* @B to i32 addrspace(2)**)
-// PIZ: load i32 addrspace(2)*, i32 addrspace(2)* addrspace(4)* addrspacecast 
(i32 addrspace(2)* addrspace(1)* @B to i32 addrspace(2)* addrspace(4)*)
 // CHECK: load i32, i32 addrspace(2)*
 // X86: load i32 addrspace(2)*, i32 addrspace(2)** @A
 // AMDGIZ: load i32 addrspace(2)*, i32 addrspace(2)** addrspacecast (i32 
addrspace(2)* addrspace(1)* @A to i32 addrspace(2)**)
-// PIZ: load i32 addrspace(2)*, i32 addrspace(2)* addrspace(4)* addrspacecast 
(i32 addrspace(2)* addrspace(1)* @A to i32 addrspace(2)* addrspace(4)*)
 // CHECK: store i32 {{.*}}, i32 addrspace(2)*
 void test3() {
   *A = *B;
@@ -44,8 +41,6 @@ typedef struct {
 // CHECK-LABEL: define void @test4(
 // GIZ: call void @llvm.memcpy.p0i8.p2i8
 // GIZ: call void @llvm.memcpy.p2i8.p0i8
-// PIZ: call void @llvm.memcpy.p4i8.p2i8
-// PIZ: call void @llvm.memcpy.p2i8.p4i8
 void test4(MyStruct __attribute__((address_space(2))) *pPtr) {
   MyStruct s = pPtr[0];
   pPtr[0] = s;

Modified: cfe/trunk/test/CodeGen/default-address-space.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/default-address-space.c?rev=324102&r1=324101&r2=324102&view=diff
==
--- cfe/trunk/test/CodeGen/default-address-space.c (original)
+++ cfe/trunk/t

[PATCH] D40956: [AMDGPU] Switch to the new addr space mapping by default for clang

[Yaxun Liu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL324102: [AMDGPU] Switch to the new addr space mapping by 
default (authored by yaxunl, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D40956?vs=125959&id=132602#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D40956

Files:
  cfe/trunk/lib/Basic/Targets/AMDGPU.cpp
  cfe/trunk/lib/Basic/Targets/AMDGPU.h
  cfe/trunk/test/CodeGen/address-space.c
  cfe/trunk/test/CodeGen/default-address-space.c
  cfe/trunk/test/CodeGen/target-data.c
  cfe/trunk/test/CodeGenOpenCL/address-spaces.cl
  cfe/trunk/test/CodeGenOpenCL/amdgpu-abi-struct-coerce.cl
  cfe/trunk/test/CodeGenOpenCL/amdgpu-alignment.cl
  cfe/trunk/test/CodeGenOpenCL/amdgpu-debug-info-variable-expression.cl
  cfe/trunk/test/CodeGenOpenCL/amdgpu-enqueue-kernel.cl
  cfe/trunk/test/CodeGenOpenCL/amdgpu-env-amdgiz.cl
  cfe/trunk/test/CodeGenOpenCL/amdgpu-nullptr.cl
  cfe/trunk/test/CodeGenOpenCL/blocks.cl
  cfe/trunk/test/CodeGenOpenCL/byval.cl
  cfe/trunk/test/CodeGenOpenCL/opencl_types.cl
  cfe/trunk/test/CodeGenOpenCL/size_t.cl

Index: cfe/trunk/lib/Basic/Targets/AMDGPU.h
===
--- cfe/trunk/lib/Basic/Targets/AMDGPU.h
+++ cfe/trunk/lib/Basic/Targets/AMDGPU.h
@@ -77,10 +77,7 @@
 return TT.getArch() == llvm::Triple::amdgcn;
   }
 
-  static bool isGenericZero(const llvm::Triple &TT) {
-return TT.getEnvironmentName() == "amdgiz" ||
-   TT.getEnvironmentName() == "amdgizcl";
-  }
+  static bool isGenericZero(const llvm::Triple &TT) { return true; }
 
 public:
   AMDGPUTargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts);
Index: cfe/trunk/lib/Basic/Targets/AMDGPU.cpp
===
--- cfe/trunk/lib/Basic/Targets/AMDGPU.cpp
+++ cfe/trunk/lib/Basic/Targets/AMDGPU.cpp
@@ -30,7 +30,7 @@
 
 static const char *const DataLayoutStringR600 =
 "e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128"
-"-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64";
+"-v192:256-v256:256-v512:512-v1024:1024-v2048:2048-n32:64-A5";
 
 static const char *const DataLayoutStringSIPrivateIsZero =
 "e-p:32:32-p1:64:64-p2:64:64-p3:32:32-p4:64:64-p5:32:32"
Index: cfe/trunk/test/CodeGenOpenCL/amdgpu-abi-struct-coerce.cl
===
--- cfe/trunk/test/CodeGenOpenCL/amdgpu-abi-struct-coerce.cl
+++ cfe/trunk/test/CodeGenOpenCL/amdgpu-abi-struct-coerce.cl
@@ -1,6 +1,6 @@
 // REQUIRES: amdgpu-registered-target
-// RUN: %clang_cc1 -triple amdgcn-unknown-unknown-amdgiz -S -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,AMDGCN %s
-// RUN: %clang_cc1 -triple r600-unknown-unknown -S -emit-llvm -o - %s | FileCheck -check-prefixes=CHECK,R600 %s
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -S -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple r600-unknown-unknown -S -emit-llvm -o - %s | FileCheck %s
 
 typedef __attribute__(( ext_vector_type(2) )) char char2;
 typedef __attribute__(( ext_vector_type(3) )) char char3;
@@ -309,8 +309,7 @@
 // CHECK: void @func_different_size_type_pair_arg(i64 %arg1.coerce0, i32 %arg1.coerce1)
 void func_different_size_type_pair_arg(different_size_type_pair arg1) { }
 
-// AMDGCN: void @func_flexible_array_arg(%struct.flexible_array addrspace(5)* byval nocapture align 4 %arg)
-// R600: void @func_flexible_array_arg(%struct.flexible_array* byval nocapture align 4 %arg)
+// CHECK: void @func_flexible_array_arg(%struct.flexible_array addrspace(5)* byval nocapture align 4 %arg)
 void func_flexible_array_arg(flexible_array arg) { }
 
 // CHECK: define float @func_f32_ret()
@@ -405,16 +404,14 @@
   return s;
 }
 
-// AMDGCN: define void @func_ret_struct_arr32(%struct.struct_arr32 addrspace(5)* noalias nocapture sret %agg.result)
-// R600: define void @func_ret_struct_arr32(%struct.struct_arr32* noalias nocapture sret %agg.result)
+// CHECK: define void @func_ret_struct_arr32(%struct.struct_arr32 addrspace(5)* noalias nocapture sret %agg.result)
 struct_arr32 func_ret_struct_arr32()
 {
   struct_arr32 s = { 0 };
   return s;
 }
 
-// AMDGCN: define void @func_ret_struct_arr33(%struct.struct_arr33 addrspace(5)* noalias nocapture sret %agg.result)
-// R600: define void @func_ret_struct_arr33(%struct.struct_arr33* noalias nocapture sret %agg.result)
+// CHECK: define void @func_ret_struct_arr33(%struct.struct_arr33 addrspace(5)* noalias nocapture sret %agg.result)
 struct_arr33 func_ret_struct_arr33()
 {
   struct_arr33 s = { 0 };
@@ -443,8 +440,7 @@
   return s;
 }
 
-// AMDGCN: define void @func_flexible_array_ret(%struct.flexible_array addrspace(5)* noalias nocapture sret %agg.result)
-// R600: define void @func_flexible_array_ret(%struct.flexible_array* noalias nocapture sret %agg.result)
+// CHECK: define void @func_flexible_array_ret(%struct.flexible_array addrspace(5)* noalias nocapture

[PATCH] D42650: [clang-format] New format param ObjCBinPackProtocolList

[Ben Hamilton via Phabricator via cfe-commits]

benhamilton added inline comments.



Comment at: lib/Format/ContinuationIndenter.cpp:1214
 // FIXME: We likely want to do this for more combinations of brackets.
 // Verify that it is wanted for ObjC, too.
 if (Current.is(tok::less) && Current.ParentBracket == tok::l_paren) {

stephanemoore wrote:
> With the new parameter does this comment still apply? Maybe we can remove it?
Good point.

This is about <> brackets nested inside () parens, which I believe is 
applicable to Objective-C 2.0 generics passed to C/C++ functions, but not to 
protocol conformance lists.

I'll send out a separate diff to add tests and clean up this comment, since I 
think the behavior is wanted for ObjC as well, but I think it's unrelated to 
this diff.


Repository:
  rC Clang

https://reviews.llvm.org/D42650



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

[PATCH] D39571: [clangd] DidChangeConfiguration Notification

[Simon Marchi via Phabricator via cfe-commits]

simark added inline comments.



Comment at: clangd/ClangdLSPServer.cpp:302
 
+// FIXME: This function needs to be properly tested.
+void ClangdLSPServer::onChangeConfiguration(

ilya-biryukov wrote:
> simark wrote:
> > simark wrote:
> > > ilya-biryukov wrote:
> > > > simark wrote:
> > > > > simark wrote:
> > > > > > ilya-biryukov wrote:
> > > > > > > simark wrote:
> > > > > > > > ilya-biryukov wrote:
> > > > > > > > > simark wrote:
> > > > > > > > > > ilya-biryukov wrote:
> > > > > > > > > > > Are you planning to to address this FIXME before checking 
> > > > > > > > > > > the code in?
> > > > > > > > > > Following what you said here:
> > > > > > > > > > 
> > > > > > > > > > https://reviews.llvm.org/D39571?id=124024#inline-359345
> > > > > > > > > > 
> > > > > > > > > > I have not really looked into what was wrong with the test, 
> > > > > > > > > > and what is missing in the infrastructure to make it work.  
> > > > > > > > > > But I assumed that the situation did not change since then. 
> > > > > > > > > >  Can you enlighten me on what the problem was, and what is 
> > > > > > > > > > missing?
> > > > > > > > > We usually write unittests for that kind of thing, since they 
> > > > > > > > > allow to plug an in-memory filesystem, but we only test 
> > > > > > > > > `ClangdServer` (examples are in 
> > > > > > > > > `unittests/clangd/ClangdTests.cpp`). `ClangdLSPServer` does 
> > > > > > > > > not allow to plug in a virtual filesystem (vfs). Even if we 
> > > > > > > > > add vfs, it's still hard to unit-test because we'll have to 
> > > > > > > > > match the json input/output directly.
> > > > > > > > > 
> > > > > > > > > This leaves us with an option of a lit test that runs 
> > > > > > > > > `clangd` directly, similar to tests in `test/clangd`.
> > > > > > > > > The lit test would need to create a temporary directory, 
> > > > > > > > > create proper `compile_commands.json` there, then send the 
> > > > > > > > > LSP commands with the path to the test to clangd.
> > > > > > > > > One major complication is that in LSP we have to specify the 
> > > > > > > > > size of each message, but in our case the size would change 
> > > > > > > > > depending on created temp path. It means we'll have to patch 
> > > > > > > > > the test input to setup proper paths and message sizes.
> > > > > > > > > If we choose to go down this path, 
> > > > > > > > > `clang-tools-extra/test/clang-tidy/vfsoverlay.cpp` does a 
> > > > > > > > > similar setup (create temp-dir, patch up some configuration 
> > > > > > > > > files to point into the temp directory, etc) and could be 
> > > > > > > > > used as a starting point.
> > > > > > > > > 
> > > > > > > > > It's not impossible to write that test, it's just a bit 
> > > > > > > > > involved. Having a test would be nice, though, to ensure we 
> > > > > > > > > don't break this method while doing other things. Especially 
> > > > > > > > > given that this functionality is not used anywhere in clangd.
> > > > > > > > > We usually write unittests for that kind of thing, since they 
> > > > > > > > > allow to plug an in-memory filesystem, but we only test 
> > > > > > > > > ClangdServer (examples are in 
> > > > > > > > > unittests/clangd/ClangdTests.cpp). ClangdLSPServer does not 
> > > > > > > > > allow to plug in a virtual filesystem (vfs). Even if we add 
> > > > > > > > > vfs, it's still hard to unit-test because we'll have to match 
> > > > > > > > > the json input/output directly.
> > > > > > > > 
> > > > > > > > What do you mean by "we'll have to match the json input/output 
> > > > > > > > directly"?  That we'll have to match the complete JSON output 
> > > > > > > > textually?  Couldn't the test parse the JSON into some data 
> > > > > > > > structures, then we could assert specific things, like that 
> > > > > > > > this particular field is present and contains a certain 
> > > > > > > > substring, for example?
> > > > > > > > 
> > > > > > > > > This leaves us with an option of a lit test that runs clangd 
> > > > > > > > > directly, similar to tests in test/clangd.
> > > > > > > > > The lit test would need to create a temporary directory, 
> > > > > > > > > create proper compile_commands.json there, then send the LSP 
> > > > > > > > > commands with the path to the test to clangd.
> > > > > > > > > One major complication is that in LSP we have to specify the 
> > > > > > > > > size of each message, but in our case the size would change 
> > > > > > > > > depending on created temp path. It means we'll have to patch 
> > > > > > > > > the test input to setup proper paths and message sizes.
> > > > > > > > > If we choose to go down this path, 
> > > > > > > > > clang-tools-extra/test/clang-tidy/vfsoverlay.cpp does a 
> > > > > > > > > similar setup (create temp-dir, patch up some configuration 
> > > > > > > > > files to point into the temp directory, etc) and could be 
> > > > > > > > > used as a starting point.
> > > > > > > > 
> > > > > > > > 

[PATCH] D42530: Clang permits assignment to vector/extvector elements in a const method

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

If you just want a better diagnostic, there's quite a bit of machinery already 
set up to give more specific errors about why such-and-such l-value isn't 
modifiable.  There may even be vector-specific diagnostics for that already, 
just triggered from the wrong place in the code.


https://reviews.llvm.org/D42530



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

[PATCH] D42530: Clang permits assignment to vector/extvector elements in a const method

[Andrew V. Tischenko via Phabricator via cfe-commits]

avt77 updated this revision to Diff 132607.
avt77 added a comment.

I re-implemented the patch. Now it works properly with const methods in CXX 
classes.


https://reviews.llvm.org/D42530

Files:
  lib/AST/ExprClassification.cpp
  lib/Sema/SemaExpr.cpp
  test/Sema/assign.c
  test/Sema/typedef-retain.c
  test/SemaCXX/anonymous-union.cpp
  test/SemaCXX/err_typecheck_assign_const.cpp

Index: test/SemaCXX/err_typecheck_assign_const.cpp
===
--- test/SemaCXX/err_typecheck_assign_const.cpp
+++ test/SemaCXX/err_typecheck_assign_const.cpp
@@ -129,3 +129,23 @@
   Func &bar();
   bar()() = 0; // expected-error {{read-only variable is not assignable}}
 }
+
+typedef float float4 __attribute__((ext_vector_type(4)));
+struct OhNo {
+  float4 v;
+  void AssignMe() const { v.x = 1; } // expected-error {{cannot assign to non-static data member within const member function 'AssignMe'}} \
+expected-note {{member function 'OhNo::AssignMe' is declared const here}}
+};
+
+typedef float float4_2 __attribute__((__vector_size__(16)));
+struct OhNo2 {
+  float4_2 v;
+  void AssignMe() const { v[0] = 1; } // expected-error {{cannot assign to non-static data member within const member function 'AssignMe'}} \
+expected-note {{member function 'OhNo2::AssignMe' is declared const here}}
+};
+
+struct OhNo3 {
+  float v[4];
+  void AssignMe() const { v[0] = 1; } // expected-error {{cannot assign to non-static data member within const member function 'AssignMe'}} \
+expected-note {{member function 'OhNo3::AssignMe' is declared const here}}
+};
Index: test/SemaCXX/anonymous-union.cpp
===
--- test/SemaCXX/anonymous-union.cpp
+++ test/SemaCXX/anonymous-union.cpp
@@ -40,7 +40,8 @@
 }
 
 void X::test_unqual_references_const() const { // expected-note 2{{member function 'X::test_unqual_references_const' is declared const here}}
-  d = 0.0;
+  // TODO: it seems we should not see any error here becuase 'd' is mutable
+  d = 0.0; // expected-error {{read-only variable is not assignable}}
   f2 = 0; // expected-error{{cannot assign to non-static data member within const member function 'test_unqual_references_const'}}
   a = 0; // expected-error{{cannot assign to non-static data member within const member function 'test_unqual_references_const'}}
 }
Index: test/Sema/typedef-retain.c
===
--- test/Sema/typedef-retain.c
+++ test/Sema/typedef-retain.c
@@ -16,8 +16,8 @@
 typedef int a[5];
 void test3() {
   typedef const a b;
-  b r;
-  r[0]=10;  // expected-error {{read-only variable is not assignable}}
+  b r;  // expected-note {{variable 'r' declared const here}}
+  r[0]=10;  // expected-error {{cannot assign to variable 'r' with const-qualified type 'b' (aka 'int const[5]')}}
 }
 
 int test4(const a y) {
Index: test/Sema/assign.c
===
--- test/Sema/assign.c
+++ test/Sema/assign.c
@@ -11,10 +11,10 @@
 
 typedef int arr[10];
 void test3() {
-  const arr b;
-  const int b2[10]; 
-  b[4] = 1; // expected-error {{read-only variable is not assignable}}
-  b2[4] = 1; // expected-error {{read-only variable is not assignable}}
+  const arr b;  // expected-note {{variable 'b' declared const here}}
+  const int b2[10];   // expected-note {{variable 'b2' declared const here}}
+  b[4] = 1; // expected-error {{cannot assign to variable 'b' with const-qualified type 'const arr' (aka 'int const[10]')}}
+  b2[4] = 1; // expected-error {{cannot assign to variable 'b2' with const-qualified type 'const int [10]'}}
 }
 
 typedef struct I {
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -10321,7 +10321,7 @@
 /// 'const' due to being captured within a block?
 enum NonConstCaptureKind { NCCK_None, NCCK_Block, NCCK_Lambda };
 static NonConstCaptureKind isReferenceToNonConstCapture(Sema &S, Expr *E) {
-  assert(E->isLValue() && E->getType().isConstQualified());
+  assert(E->isLValue());
   E = E->IgnoreParens();
 
   // Must be a reference to a declaration from an enclosing scope.
@@ -10401,10 +10401,8 @@
   const ValueDecl *VD = ME->getMemberDecl();
   if (const FieldDecl *Field = dyn_cast(VD)) {
 // Mutable fields can be modified even if the class is const.
-if (Field->isMutable()) {
-  assert(DiagnosticEmitted && "Expected diagnostic not emitted.");
+if (Field->isMutable())
   break;
-}
 
 if (!IsTypeModifiable(Field->getType(), IsDereference)) {
   if (!DiagnosticEmitted) {
@@ -10434,8 +10432,16 @@
 // Static fields do not inherit constness from parents.
 break;
   }
-  break;
-} // End MemberExpr
+ 

[PATCH] D42361: [Tooling] Returns non-zero status code when files are skipped.

[Benjamin Kramer via Phabricator via cfe-commits]

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

Removing FIXME seems right to me.


Repository:
  rC Clang

https://reviews.llvm.org/D42361



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

[clang-tools-extra] r324105 - [clangd] Fix ExternC test broken by r324081

[Sam McCall via cfe-commits]

Author: sammccall
Date: Fri Feb  2 09:01:36 2018
New Revision: 324105

URL: http://llvm.org/viewvc/llvm-project?rev=324105&view=rev
Log:
[clangd] Fix ExternC test broken by r324081

Modified:
clang-tools-extra/trunk/unittests/clangd/SymbolCollectorTests.cpp

Modified: clang-tools-extra/trunk/unittests/clangd/SymbolCollectorTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clangd/SymbolCollectorTests.cpp?rev=324105&r1=324104&r2=324105&view=diff
==
--- clang-tools-extra/trunk/unittests/clangd/SymbolCollectorTests.cpp (original)
+++ clang-tools-extra/trunk/unittests/clangd/SymbolCollectorTests.cpp Fri Feb  
2 09:01:36 2018
@@ -343,8 +343,8 @@ TEST_F(SymbolCollectorTest, ExternC) {
 }
   )";
   runSymbolCollector(Header, /*Main=*/"");
-  EXPECT_THAT(Symbols,
-  UnorderedElementsAre(QName("na"), QName("Foo"), QName("Bar")));
+  EXPECT_THAT(Symbols, UnorderedElementsAre(QName("na"), QName("Foo"),
+QName("na::Bar")));
 }
 
 TEST_F(SymbolCollectorTest, SkipInlineNamespace) {


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

r324107 - Start setting dso_local in clang.

[Rafael Espindola via cfe-commits]

Author: rafael
Date: Fri Feb  2 09:17:39 2018
New Revision: 324107

URL: http://llvm.org/viewvc/llvm-project?rev=324107&view=rev
Log:
Start setting dso_local in clang.

This starts adding dso_local to clang.

The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go
away. My objective for now is to move enough of it to clang to remove
the need for the TargetMachine one to handle PIE copy relocations and
-fno-plt. With that it should then be easy to implement a
-fno-copy-reloc in clang.

This patch just adds the cases where we assume a symbol to be local
based on the file being compiled for an executable or a shared
library.

Added:
cfe/trunk/test/CodeGen/dso-local-executable.c
cfe/trunk/test/CodeGenCXX/dso-local-executable.cpp
Modified:
cfe/trunk/lib/CodeGen/CGDecl.cpp
cfe/trunk/lib/CodeGen/CGVTT.cpp
cfe/trunk/lib/CodeGen/CGVTables.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.h
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/test/CodeGen/mbackchain-2.c
cfe/trunk/test/CodeGen/mbackchain-3.c
cfe/trunk/test/CodeGen/mips-vector-return.c
cfe/trunk/test/CodeGen/split-stacks.c
cfe/trunk/test/CodeGenCXX/debug-info-static-member.cpp
cfe/trunk/test/CodeGenCXX/debug-info-template.cpp
cfe/trunk/test/CodeGenCXX/float16-declarations.cpp
cfe/trunk/test/CodeGenCXX/split-stacks.cpp
cfe/trunk/test/Driver/lanai-unknown-unknown.cpp
cfe/trunk/test/Driver/le32-unknown-nacl.cpp
cfe/trunk/test/Driver/le64-unknown-unknown.cpp
cfe/trunk/test/Driver/riscv32-toolchain.c
cfe/trunk/test/Driver/riscv64-toolchain.c
cfe/trunk/test/Frontend/ast-codegen.c

Modified: cfe/trunk/lib/CodeGen/CGDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDecl.cpp?rev=324107&r1=324106&r2=324107&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDecl.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDecl.cpp Fri Feb  2 09:17:39 2018
@@ -240,7 +240,7 @@ llvm::Constant *CodeGenModule::getOrCrea
   getModule(), LTy, Ty.isConstant(getContext()), Linkage, Init, Name,
   nullptr, llvm::GlobalVariable::NotThreadLocal, TargetAS);
   GV->setAlignment(getContext().getDeclAlign(&D).getQuantity());
-  setGlobalVisibility(GV, &D, ForDefinition);
+  setGVProperties(GV, &D, ForDefinition);
 
   if (supportsCOMDAT() && GV->isWeakForLinker())
 GV->setComdat(TheModule.getOrInsertComdat(GV->getName()));
@@ -344,6 +344,7 @@ CodeGenFunction::AddInitializerToStaticV
   OldGV->getThreadLocalMode(),

CGM.getContext().getTargetAddressSpace(D.getType()));
 GV->setVisibility(OldGV->getVisibility());
+GV->setDSOLocal(OldGV->isDSOLocal());
 GV->setComdat(OldGV->getComdat());
 
 // Steal the name of the old global

Modified: cfe/trunk/lib/CodeGen/CGVTT.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGVTT.cpp?rev=324107&r1=324106&r2=324107&view=diff
==
--- cfe/trunk/lib/CodeGen/CGVTT.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGVTT.cpp Fri Feb  2 09:17:39 2018
@@ -100,7 +100,7 @@ CodeGenVTables::EmitVTTDefinition(llvm::
 VTT->setComdat(CGM.getModule().getOrInsertComdat(VTT->getName()));
 
   // Set the right visibility.
-  CGM.setGlobalVisibility(VTT, RD, ForDefinition);
+  CGM.setGVProperties(VTT, RD, ForDefinition);
 }
 
 llvm::GlobalVariable *CodeGenVTables::GetAddrOfVTT(const CXXRecordDecl *RD) {

Modified: cfe/trunk/lib/CodeGen/CGVTables.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGVTables.cpp?rev=324107&r1=324106&r2=324107&view=diff
==
--- cfe/trunk/lib/CodeGen/CGVTables.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGVTables.cpp Fri Feb  2 09:17:39 2018
@@ -51,7 +51,7 @@ llvm::Constant *CodeGenModule::GetAddrOf
 
 static void setThunkVisibility(CodeGenModule &CGM, const CXXMethodDecl *MD,
const ThunkInfo &Thunk, llvm::Function *Fn) {
-  CGM.setGlobalVisibility(Fn, MD, ForDefinition);
+  CGM.setGVProperties(Fn, MD, ForDefinition);
 }
 
 static void setThunkProperties(CodeGenModule &CGM, const ThunkInfo &Thunk,
@@ -730,7 +730,7 @@ CodeGenVTables::GenerateConstructionVTab
   // Create the variable that will hold the construction vtable.
   llvm::GlobalVariable *VTable =
 CGM.CreateOrReplaceCXXRuntimeVariable(Name, VTType, Linkage);
-  CGM.setGlobalVisibility(VTable, RD, ForDefinition);
+  CGM.setGVProperties(VTable, RD, ForDefinition);
 
   // V-tables are always unnamed_addr.
   VTable->setUnnamedAddr(llvm::GlobalValue::UnnamedAddr::Global);

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=324107&r1=324106&r2=324107&view=diff
==

[PATCH] D41318: Start setting dso_local in clang

[Rafael Avila de Espindola via Phabricator via cfe-commits]

espindola closed this revision.
espindola added a comment.

r324107


https://reviews.llvm.org/D41318



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

r324108 - Revert "Start setting dso_local in clang."

[Rafael Espindola via cfe-commits]

Author: rafael
Date: Fri Feb  2 09:29:22 2018
New Revision: 324108

URL: http://llvm.org/viewvc/llvm-project?rev=324108&view=rev
Log:
Revert "Start setting dso_local in clang."

This reverts commit r324107.

I will have to test it on OS X.

Removed:
cfe/trunk/test/CodeGen/dso-local-executable.c
cfe/trunk/test/CodeGenCXX/dso-local-executable.cpp
Modified:
cfe/trunk/lib/CodeGen/CGDecl.cpp
cfe/trunk/lib/CodeGen/CGVTT.cpp
cfe/trunk/lib/CodeGen/CGVTables.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.h
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/test/CodeGen/mbackchain-2.c
cfe/trunk/test/CodeGen/mbackchain-3.c
cfe/trunk/test/CodeGen/mips-vector-return.c
cfe/trunk/test/CodeGen/split-stacks.c
cfe/trunk/test/CodeGenCXX/debug-info-static-member.cpp
cfe/trunk/test/CodeGenCXX/debug-info-template.cpp
cfe/trunk/test/CodeGenCXX/float16-declarations.cpp
cfe/trunk/test/CodeGenCXX/split-stacks.cpp
cfe/trunk/test/Driver/lanai-unknown-unknown.cpp
cfe/trunk/test/Driver/le32-unknown-nacl.cpp
cfe/trunk/test/Driver/le64-unknown-unknown.cpp
cfe/trunk/test/Driver/riscv32-toolchain.c
cfe/trunk/test/Driver/riscv64-toolchain.c
cfe/trunk/test/Frontend/ast-codegen.c

Modified: cfe/trunk/lib/CodeGen/CGDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDecl.cpp?rev=324108&r1=324107&r2=324108&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDecl.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDecl.cpp Fri Feb  2 09:29:22 2018
@@ -240,7 +240,7 @@ llvm::Constant *CodeGenModule::getOrCrea
   getModule(), LTy, Ty.isConstant(getContext()), Linkage, Init, Name,
   nullptr, llvm::GlobalVariable::NotThreadLocal, TargetAS);
   GV->setAlignment(getContext().getDeclAlign(&D).getQuantity());
-  setGVProperties(GV, &D, ForDefinition);
+  setGlobalVisibility(GV, &D, ForDefinition);
 
   if (supportsCOMDAT() && GV->isWeakForLinker())
 GV->setComdat(TheModule.getOrInsertComdat(GV->getName()));
@@ -344,7 +344,6 @@ CodeGenFunction::AddInitializerToStaticV
   OldGV->getThreadLocalMode(),

CGM.getContext().getTargetAddressSpace(D.getType()));
 GV->setVisibility(OldGV->getVisibility());
-GV->setDSOLocal(OldGV->isDSOLocal());
 GV->setComdat(OldGV->getComdat());
 
 // Steal the name of the old global

Modified: cfe/trunk/lib/CodeGen/CGVTT.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGVTT.cpp?rev=324108&r1=324107&r2=324108&view=diff
==
--- cfe/trunk/lib/CodeGen/CGVTT.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGVTT.cpp Fri Feb  2 09:29:22 2018
@@ -100,7 +100,7 @@ CodeGenVTables::EmitVTTDefinition(llvm::
 VTT->setComdat(CGM.getModule().getOrInsertComdat(VTT->getName()));
 
   // Set the right visibility.
-  CGM.setGVProperties(VTT, RD, ForDefinition);
+  CGM.setGlobalVisibility(VTT, RD, ForDefinition);
 }
 
 llvm::GlobalVariable *CodeGenVTables::GetAddrOfVTT(const CXXRecordDecl *RD) {

Modified: cfe/trunk/lib/CodeGen/CGVTables.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGVTables.cpp?rev=324108&r1=324107&r2=324108&view=diff
==
--- cfe/trunk/lib/CodeGen/CGVTables.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGVTables.cpp Fri Feb  2 09:29:22 2018
@@ -51,7 +51,7 @@ llvm::Constant *CodeGenModule::GetAddrOf
 
 static void setThunkVisibility(CodeGenModule &CGM, const CXXMethodDecl *MD,
const ThunkInfo &Thunk, llvm::Function *Fn) {
-  CGM.setGVProperties(Fn, MD, ForDefinition);
+  CGM.setGlobalVisibility(Fn, MD, ForDefinition);
 }
 
 static void setThunkProperties(CodeGenModule &CGM, const ThunkInfo &Thunk,
@@ -730,7 +730,7 @@ CodeGenVTables::GenerateConstructionVTab
   // Create the variable that will hold the construction vtable.
   llvm::GlobalVariable *VTable =
 CGM.CreateOrReplaceCXXRuntimeVariable(Name, VTType, Linkage);
-  CGM.setGVProperties(VTable, RD, ForDefinition);
+  CGM.setGlobalVisibility(VTable, RD, ForDefinition);
 
   // V-tables are always unnamed_addr.
   VTable->setUnnamedAddr(llvm::GlobalValue::UnnamedAddr::Global);

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=324108&r1=324107&r2=324108&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Fri Feb  2 09:29:22 2018
@@ -717,63 +717,6 @@ void CodeGenModule::setGlobalVisibility(
 GV->setVisibility(GetLLVMVisibility(LV.getVisibility()));
 }
 
-static bool shouldAssumeDSOLocal(const CodeGenModule &CGM,
- llvm::GlobalValue

[PATCH] D41887: [libcxxabi][demangler] Clean up and llvm-ify the expression parser

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL324111: [demangler] Clean up the expression parser (authored 
by epilk, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D41887?vs=132279&id=132620#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D41887

Files:
  libcxxabi/trunk/src/cxa_demangle.cpp
  libcxxabi/trunk/test/test_demangle.pass.cpp

Index: libcxxabi/trunk/test/test_demangle.pass.cpp
===
--- libcxxabi/trunk/test/test_demangle.pass.cpp
+++ libcxxabi/trunk/test/test_demangle.pass.cpp
@@ -29617,6 +29617,45 @@
 {"_Z1fIJicEEvDp7MuncherIAstT__S1_E", "void f(Muncher, Muncher)"},
 {"_ZN1SIJifcEE1fIJdjEEEiDp4MerpIJifcT_EE", "int S::f(Merp, Merp)"},
 {"_Z1pIJicEEiDp4MerpIXsZT_EJT_EE", "int p(Merp, Merp)"},
+
+// Some expression symbols found in clang's test/CodeGenCXX/mangle-exprs.cpp
+{"_ZN5Casts8implicitILj4EEEvPN9enable_ifIXleT_Li4EEvE4typeE", "void Casts::implicit<4u>(enable_if<(4u) <= (4), void>::type*)"},
+{"_ZN5Casts6cstyleILj4EEEvPN9enable_ifIXleT_cvjLi4EEvE4typeE", "void Casts::cstyle<4u>(enable_if<(4u) <= ((unsigned int)(4)), void>::type*)"},
+{"_ZN5Casts10functionalILj4EEEvPN9enable_ifIXleT_cvjLi4EEvE4typeE", "void Casts::functional<4u>(enable_if<(4u) <= ((unsigned int)(4)), void>::type*)"},
+{"_ZN5Casts7static_ILj4EEEvPN9enable_ifIXleT_scjLi4EEvE4typeE", "void Casts::static_<4u>(enable_if<(4u) <= (static_cast(4)), void>::type*)"},
+{"_ZN5Casts12reinterpret_ILj4EiEEvPN9enable_ifIXleT_szrcPT0_Li0EEvE4typeE", "void Casts::reinterpret_<4u, int>(enable_if<(4u) <= (sizeof (reinterpret_cast(0))), void>::type*)"},
+{"_ZN5Casts6const_IiXadL_ZNS_1iEvPN9enable_ifIXleLi0EszccPT_T0_EvE4typeE", "void Casts::const_(enable_if<(0) <= (sizeof (const_cast(&(Casts::i, void>::type*)"},
+{"_ZN5Casts8dynamic_INS_1SEXadL_ZNS_1sEvPN9enable_ifIXleLi0EszdcPT_T0_EvE4typeE", "void Casts::dynamic_(enable_if<(0) <= (sizeof (dynamic_cast(&(Casts::s, void>::type*)"},
+{"_ZN5Casts1fILi6EEENS_1TIXT_EEEv", "Casts::T<6> Casts::f<6>()"},
+{"_ZN5Casts5auto_IiEEvDTnw_DapicvT__EEE", "void Casts::auto_(decltype(new auto((int)("},
+{"_ZN5Casts7scalar_IiEEvDTcmcvT__Ecvi_EE", "void Casts::scalar_(decltype(((int)()) , ((int)("},
+{"_ZN5test11aIsEEDTcl3foocvT__EEES1_", "decltype(foo((short)())) test1::a(short)"},
+{"_ZN5test21aIPFfvEEEvT_DTclfL0p_EE", "void test2::a(float (*)(), decltype(fp()))"},
+{"_ZN5test21bIPFfvEEEDTclfp_EET_", "decltype(fp()) test2::b(float (*)())"},
+{"_ZN5test21cIPFfvEEEvT_PFvDTclfL1p_EEE", "void test2::c(float (*)(), void (*)(decltype(fp("},
+{"_ZN5test21dIPFfvEEEvT_PFDTclfL0p_EEvE", "void test2::d(float (*)(), decltype(fp()) (*)())"},
+{"_ZN5test21eIPFfvEEEvPFDTclfp_EET_E", "void test2::e(decltype(fp()) (*)(float (*)()))"},
+{"_ZN5test21fIPFfvEEEvPFvT_DTclfL0p_EEE", "void test2::f(void (*)(float (*)(), decltype(fp("},
+{"_ZN5test21gIPFfvEEEvT_DTclfL0p_EE", "void test2::g(float (*)(), decltype(fp()))"},
+{"_ZN5test21hIPFfvEEEvT_DTcvPFDTclfL0p_EEvELi0EE", "void test2::h(float (*)(), decltype((decltype(fp()) (*)())(0)))"},
+{"_ZN5test21iIPFfvEEEvDTcvPFDTclfp_EET_ELi0EE", "void test2::i(decltype((decltype(fp()) (*)(float (*)()))(0)))"},
+{"_ZZN5test21gIPFfvEEEvT_DTclfL0p_EEE8variable", "void test2::g(float (*)(), decltype(fp()))::variable"},
+{"_ZN5test31aINS_1XEMS1_PiEEvT_T0_DTdsfL0p_fL0p0_E", "void test3::a(test3::X, int* test3::X::*, decltype(fp.*fp0))"},
+{"_ZN5test43tf1INS_1XEEEvDTnw_T_piLi1EEE", "void test4::tf1(decltype(new test4::X(1)))"},
+{"_ZN5test51aIiEEvDTnxcvT__EE", "void test5::a(decltype(noexcept ((int)("},
+{"_ZN5test62f1IiEEvDTcvT_dtdtL_ZNS_1zEE2ua1iE", "void test6::f1(decltype((int)(test6::z.ua.i)))"},
+{"_ZN5test62f2IiEEvDTcvT_dtdtL_ZNS_1zEE2ub1iE", "void test6::f2(decltype((int)(test6::z.ub.i)))"},
+{"_ZN5test62f3IiEEvDTcvT_dtdtL_ZNS_1zEE1s1iE", "void test6::f3(decltype((int)(test6::z.s.i)))"},
+{"_ZN5test62f4IiEEvDTcvT_dtdtL_ZNS_1zEE4uuss1iE", "void test6::f4(decltype((int)(test6::z.uuss.i)))"},
+{"_ZN5test62f5IiEEvDTcvT_dtptL_ZNS_2zpEE2ua1iE", "void test6::f5(decltype((int)(test6::zp->ua.i)))"},
+{"_ZN5test62f6IiEEvDTcvT_dtptL_ZNS_2zpEE2ub1iE", "void test6::f6(decltype((int)(test6::zp->ub.i)))"},
+{"_ZN5test62f7IiEEvDTcvT_dtptL_ZNS_2zpEE1s1iE", "void test6::f7(decltype((int)(test6::zp->s.i)))"},
+{"_ZN5test62f8IiEEvDTcvT_dtptL_ZNS_2zpEE4uuss1iE", "void test6::f8(decltype((int)(test6::zp->uuss.i)))"},
+{"_ZN5test73fD2IiEEDTcmcvNS_1DEL_ZNS_1bEEcvT__EES2_", "decltype(((test7::D)(test7::b)) , ((int)())) test7::fD2(int)"},
+{"_ZN5test73fT2IiEEDTcvT__EES1_", "decltype((int)()) test7::fT2(int)"},
+{"_ZN5test73fT4IiEEDTcvT_Li1EES1_", "decltype((int)(1)) test7::fT4(int)"},
+{"_ZN5test73fT6INS_1BEEEDTcvT__Li1ELi2EEES2_", "decltype((test7::B)(

[PATCH] D42640: [clangd] Prototype: collect symbol #include & insert #include in global code completion.

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

TL;DR:

- I think we can expose fewer types/abstractions in the header mapping, and put 
it all in one header. If we want some functionality to be global-index only, we 
should make it an option to the symbolcollector, not stash the logic somewhere 
else I think.
- regex seems like a big hammer, but we can revisit if this is on the hot path
- the overridden path should probably be an "include string" rather than a URI
- lots of naming nits as usual :-)
- I haven't reviewed the actual preprocessor/include-path madness yet :-)




Comment at: clangd/ClangdLSPServer.cpp:161
+ApplyEdit.edit = WE;
+reply(C, "Inserted header " + Params.includeInsertion->headerUri);
+call(C, "workspace/applyEdit", ApplyEdit);

The caveat from apply fix also applies here. Maybe we should combine the tail 
of this case and the tail of apply-fix (the part from WorkspaceEdit)? They're 
simple (and wrong) now, but will need the same changes.



Comment at: clangd/ClangdServer.cpp:411
 
+Expected
+ClangdServer::insertInclude(const Context &Ctx, PathRef File, StringRef Code,

(I still want to look at  this bit... on monday :-)



Comment at: clangd/CodeComplete.cpp:254
   // Builds an LSP completion item.
-  CompletionItem build(const CompletionItemScores &Scores,
+  CompletionItem build(llvm::StringRef FileName, llvm::StringRef Contents,
+   const CompletionItemScores &Scores,

contents is unused



Comment at: clangd/CodeComplete.cpp:289-290
+if (!D->HeaderUri.empty()) {
+  Command Cmd;
+  Cmd.title = "Insert #include";
+  Cmd.command = ExecuteCommandParams::CLANGD_INSERT_HEADER_INCLUDE;

not sure where this is shown, but maybe add "if needed"?



Comment at: clangd/CodeComplete.cpp:296
+  Cmd.includeInsertion = std::move(Insertion);
+  I.command = std::move(Cmd);
+}

LSP says we should use additionalTextEdits instead.
I think we have OK reasons, but you probably want to mention it here.



Comment at: clangd/CodeComplete.cpp:836
if (Recorder.CCSema)
- Output = runWithSema();
+ Output = runWithSema(SemaCCInput.FileName,
+  SemaCCInput.Contents);

What do you think about (redundantly) passing filename to the constructor, and 
stashing it in a member, instead of passing to all the methods here?
I think main purpose of having this class is not having the *primary* data flow 
obscured by all the various context variables.

If you don't like that, we could also pass the SemaCCInput struct to the 
constructor itself. The distinction between constrcutor params and run() params 
is pretty artificial.

(as noted above, I think/hope Contents is unused in any case)



Comment at: clangd/Protocol.cpp:370
 Result["additionalTextEdits"] = json::ary(CI.additionalTextEdits);
+  if (CI.command) {
+Result["command"] = *CI.command;

nit: drop braces consistent with the other code around here



Comment at: clangd/Protocol.h:380
+
+  std::string headerUri;
+  /// Note: "documentChanges" is not currently used because currently there is

I would call this "header". At least in the current implementation, it's not a 
URI, and we we really don't want anyone trying to parse it.



Comment at: clangd/Protocol.h:381
+  std::string headerUri;
+  /// Note: "documentChanges" is not currently used because currently there is
+  /// no support for versioned edits.

I don't think this comment applies here?



Comment at: clangd/Protocol.h:398
   const static llvm::StringLiteral CLANGD_APPLY_FIX_COMMAND;
 
+  const static llvm::StringLiteral CLANGD_INSERT_HEADER_INCLUDE;

nit: remove blank line (and below). These form a list.



Comment at: clangd/Protocol.h:412
 
+struct Command {
+  std::string title;

Hmm, you could consider `struct Command : public ExecuteCommandParams { 
std::string title; }`

I guess it's a hack, but this repetition seems a little silly. You could then 
reuse some of the JSON stuff too.



Comment at: clangd/global-symbol-builder/PragmaCommentHandler.h:1
+//===-- PragmaCommentHandler.h - find all symbols*- C++ 
-*-===//
+//

can this also be put in HeaderMap.h?



Comment at: clangd/global-symbol-builder/PragmaCommentHandler.h:28
+/// 
https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/IWYUPragmas.md#iwyu-pragma-private
+class PragmaCommentHandler : public clang::CommentHandler {
+public:

I'm not sure this class needs to be exposed, can we just expose a functi

r324113 - [Tooling] Returns non-zero status code when files are skipped.

[Eric Liu via cfe-commits]

Author: ioeric
Date: Fri Feb  2 10:19:22 2018
New Revision: 324113

URL: http://llvm.org/viewvc/llvm-project?rev=324113&view=rev
Log:
[Tooling] Returns non-zero status code when files are skipped.

Reviewers: hokein, bkramer

Reviewed By: bkramer

Subscribers: bkramer, klimek, cfe-commits

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

Modified:
cfe/trunk/include/clang/Tooling/Tooling.h
cfe/trunk/lib/Tooling/Tooling.cpp

Modified: cfe/trunk/include/clang/Tooling/Tooling.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/Tooling.h?rev=324113&r1=324112&r2=324113&view=diff
==
--- cfe/trunk/include/clang/Tooling/Tooling.h (original)
+++ cfe/trunk/include/clang/Tooling/Tooling.h Fri Feb  2 10:19:22 2018
@@ -330,6 +330,9 @@ class ClangTool {
   /// Runs an action over all files specified in the command line.
   ///
   /// \param Action Tool action.
+  ///
+  /// \returns 0 on success; 1 if any error occured; 2 if there is no error but
+  /// some files are skipped due to missing compile commands.
   int run(ToolAction *Action);
 
   /// \brief Create an AST for each file specified in the command line and

Modified: cfe/trunk/lib/Tooling/Tooling.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/Tooling.cpp?rev=324113&r1=324112&r2=324113&view=diff
==
--- cfe/trunk/lib/Tooling/Tooling.cpp (original)
+++ cfe/trunk/lib/Tooling/Tooling.cpp Fri Feb  2 10:19:22 2018
@@ -388,6 +388,7 @@ int ClangTool::run(ToolAction *Action) {
 llvm::MemoryBuffer::getMemBuffer(MappedFile.second));
 
   bool ProcessingFailed = false;
+  bool FileSkipped = false;
   for (const auto &SourcePath : SourcePaths) {
 std::string File(getAbsolutePath(SourcePath));
 
@@ -401,12 +402,8 @@ int ClangTool::run(ToolAction *Action) {
 std::vector CompileCommandsForFile =
 Compilations.getCompileCommands(File);
 if (CompileCommandsForFile.empty()) {
-  // FIXME: There are two use cases here: doing a fuzzy
-  // "find . -name '*.cc' |xargs tool" match, where as a user I don't care
-  // about the .cc files that were not found, and the use case where I
-  // specify all files I want to run over explicitly, where this should
-  // be an error. We'll want to add an option for this.
   llvm::errs() << "Skipping " << File << ". Compile command not found.\n";
+  FileSkipped = true;
   continue;
 }
 for (CompileCommand &CompileCommand : CompileCommandsForFile) {
@@ -466,7 +463,7 @@ int ClangTool::run(ToolAction *Action) {
  Twine(InitialDirectory) + "\n!");
 }
   }
-  return ProcessingFailed ? 1 : 0;
+  return ProcessingFailed ? 1 : (FileSkipped ? 2 : 0);
 }
 
 namespace {


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

[PATCH] D42361: [Tooling] Returns non-zero status code when files are skipped.

[Eric Liu via Phabricator via cfe-commits]

ioeric updated this revision to Diff 132624.
ioeric added a comment.

removed FIXME


Repository:
  rC Clang

https://reviews.llvm.org/D42361

Files:
  include/clang/Tooling/Tooling.h
  lib/Tooling/Tooling.cpp


Index: lib/Tooling/Tooling.cpp
===
--- lib/Tooling/Tooling.cpp
+++ lib/Tooling/Tooling.cpp
@@ -388,6 +388,7 @@
 llvm::MemoryBuffer::getMemBuffer(MappedFile.second));
 
   bool ProcessingFailed = false;
+  bool FileSkipped = false;
   for (const auto &SourcePath : SourcePaths) {
 std::string File(getAbsolutePath(SourcePath));
 
@@ -401,12 +402,8 @@
 std::vector CompileCommandsForFile =
 Compilations.getCompileCommands(File);
 if (CompileCommandsForFile.empty()) {
-  // FIXME: There are two use cases here: doing a fuzzy
-  // "find . -name '*.cc' |xargs tool" match, where as a user I don't care
-  // about the .cc files that were not found, and the use case where I
-  // specify all files I want to run over explicitly, where this should
-  // be an error. We'll want to add an option for this.
   llvm::errs() << "Skipping " << File << ". Compile command not found.\n";
+  FileSkipped = true;
   continue;
 }
 for (CompileCommand &CompileCommand : CompileCommandsForFile) {
@@ -466,7 +463,7 @@
  Twine(InitialDirectory) + "\n!");
 }
   }
-  return ProcessingFailed ? 1 : 0;
+  return ProcessingFailed ? 1 : (FileSkipped ? 2 : 0);
 }
 
 namespace {
Index: include/clang/Tooling/Tooling.h
===
--- include/clang/Tooling/Tooling.h
+++ include/clang/Tooling/Tooling.h
@@ -330,6 +330,9 @@
   /// Runs an action over all files specified in the command line.
   ///
   /// \param Action Tool action.
+  ///
+  /// \returns 0 on success; 1 if any error occured; 2 if there is no error but
+  /// some files are skipped due to missing compile commands.
   int run(ToolAction *Action);
 
   /// \brief Create an AST for each file specified in the command line and


Index: lib/Tooling/Tooling.cpp
===
--- lib/Tooling/Tooling.cpp
+++ lib/Tooling/Tooling.cpp
@@ -388,6 +388,7 @@
 llvm::MemoryBuffer::getMemBuffer(MappedFile.second));
 
   bool ProcessingFailed = false;
+  bool FileSkipped = false;
   for (const auto &SourcePath : SourcePaths) {
 std::string File(getAbsolutePath(SourcePath));
 
@@ -401,12 +402,8 @@
 std::vector CompileCommandsForFile =
 Compilations.getCompileCommands(File);
 if (CompileCommandsForFile.empty()) {
-  // FIXME: There are two use cases here: doing a fuzzy
-  // "find . -name '*.cc' |xargs tool" match, where as a user I don't care
-  // about the .cc files that were not found, and the use case where I
-  // specify all files I want to run over explicitly, where this should
-  // be an error. We'll want to add an option for this.
   llvm::errs() << "Skipping " << File << ". Compile command not found.\n";
+  FileSkipped = true;
   continue;
 }
 for (CompileCommand &CompileCommand : CompileCommandsForFile) {
@@ -466,7 +463,7 @@
  Twine(InitialDirectory) + "\n!");
 }
   }
-  return ProcessingFailed ? 1 : 0;
+  return ProcessingFailed ? 1 : (FileSkipped ? 2 : 0);
 }
 
 namespace {
Index: include/clang/Tooling/Tooling.h
===
--- include/clang/Tooling/Tooling.h
+++ include/clang/Tooling/Tooling.h
@@ -330,6 +330,9 @@
   /// Runs an action over all files specified in the command line.
   ///
   /// \param Action Tool action.
+  ///
+  /// \returns 0 on success; 1 if any error occured; 2 if there is no error but
+  /// some files are skipped due to missing compile commands.
   int run(ToolAction *Action);
 
   /// \brief Create an AST for each file specified in the command line and
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42361: [Tooling] Returns non-zero status code when files are skipped.

[Eric Liu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC324113: [Tooling] Returns non-zero status code when files 
are skipped. (authored by ioeric, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D42361?vs=132624&id=132626#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D42361

Files:
  include/clang/Tooling/Tooling.h
  lib/Tooling/Tooling.cpp


Index: include/clang/Tooling/Tooling.h
===
--- include/clang/Tooling/Tooling.h
+++ include/clang/Tooling/Tooling.h
@@ -330,6 +330,9 @@
   /// Runs an action over all files specified in the command line.
   ///
   /// \param Action Tool action.
+  ///
+  /// \returns 0 on success; 1 if any error occured; 2 if there is no error but
+  /// some files are skipped due to missing compile commands.
   int run(ToolAction *Action);
 
   /// \brief Create an AST for each file specified in the command line and
Index: lib/Tooling/Tooling.cpp
===
--- lib/Tooling/Tooling.cpp
+++ lib/Tooling/Tooling.cpp
@@ -388,6 +388,7 @@
 llvm::MemoryBuffer::getMemBuffer(MappedFile.second));
 
   bool ProcessingFailed = false;
+  bool FileSkipped = false;
   for (const auto &SourcePath : SourcePaths) {
 std::string File(getAbsolutePath(SourcePath));
 
@@ -401,12 +402,8 @@
 std::vector CompileCommandsForFile =
 Compilations.getCompileCommands(File);
 if (CompileCommandsForFile.empty()) {
-  // FIXME: There are two use cases here: doing a fuzzy
-  // "find . -name '*.cc' |xargs tool" match, where as a user I don't care
-  // about the .cc files that were not found, and the use case where I
-  // specify all files I want to run over explicitly, where this should
-  // be an error. We'll want to add an option for this.
   llvm::errs() << "Skipping " << File << ". Compile command not found.\n";
+  FileSkipped = true;
   continue;
 }
 for (CompileCommand &CompileCommand : CompileCommandsForFile) {
@@ -466,7 +463,7 @@
  Twine(InitialDirectory) + "\n!");
 }
   }
-  return ProcessingFailed ? 1 : 0;
+  return ProcessingFailed ? 1 : (FileSkipped ? 2 : 0);
 }
 
 namespace {


Index: include/clang/Tooling/Tooling.h
===
--- include/clang/Tooling/Tooling.h
+++ include/clang/Tooling/Tooling.h
@@ -330,6 +330,9 @@
   /// Runs an action over all files specified in the command line.
   ///
   /// \param Action Tool action.
+  ///
+  /// \returns 0 on success; 1 if any error occured; 2 if there is no error but
+  /// some files are skipped due to missing compile commands.
   int run(ToolAction *Action);
 
   /// \brief Create an AST for each file specified in the command line and
Index: lib/Tooling/Tooling.cpp
===
--- lib/Tooling/Tooling.cpp
+++ lib/Tooling/Tooling.cpp
@@ -388,6 +388,7 @@
 llvm::MemoryBuffer::getMemBuffer(MappedFile.second));
 
   bool ProcessingFailed = false;
+  bool FileSkipped = false;
   for (const auto &SourcePath : SourcePaths) {
 std::string File(getAbsolutePath(SourcePath));
 
@@ -401,12 +402,8 @@
 std::vector CompileCommandsForFile =
 Compilations.getCompileCommands(File);
 if (CompileCommandsForFile.empty()) {
-  // FIXME: There are two use cases here: doing a fuzzy
-  // "find . -name '*.cc' |xargs tool" match, where as a user I don't care
-  // about the .cc files that were not found, and the use case where I
-  // specify all files I want to run over explicitly, where this should
-  // be an error. We'll want to add an option for this.
   llvm::errs() << "Skipping " << File << ". Compile command not found.\n";
+  FileSkipped = true;
   continue;
 }
 for (CompileCommand &CompileCommand : CompileCommandsForFile) {
@@ -466,7 +463,7 @@
  Twine(InitialDirectory) + "\n!");
 }
   }
-  return ProcessingFailed ? 1 : 0;
+  return ProcessingFailed ? 1 : (FileSkipped ? 2 : 0);
 }
 
 namespace {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42361: [Tooling] Returns non-zero status code when files are skipped.

[Eric Liu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL324113: [Tooling] Returns non-zero status code when files 
are skipped. (authored by ioeric, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

https://reviews.llvm.org/D42361

Files:
  cfe/trunk/include/clang/Tooling/Tooling.h
  cfe/trunk/lib/Tooling/Tooling.cpp


Index: cfe/trunk/include/clang/Tooling/Tooling.h
===
--- cfe/trunk/include/clang/Tooling/Tooling.h
+++ cfe/trunk/include/clang/Tooling/Tooling.h
@@ -330,6 +330,9 @@
   /// Runs an action over all files specified in the command line.
   ///
   /// \param Action Tool action.
+  ///
+  /// \returns 0 on success; 1 if any error occured; 2 if there is no error but
+  /// some files are skipped due to missing compile commands.
   int run(ToolAction *Action);
 
   /// \brief Create an AST for each file specified in the command line and
Index: cfe/trunk/lib/Tooling/Tooling.cpp
===
--- cfe/trunk/lib/Tooling/Tooling.cpp
+++ cfe/trunk/lib/Tooling/Tooling.cpp
@@ -388,6 +388,7 @@
 llvm::MemoryBuffer::getMemBuffer(MappedFile.second));
 
   bool ProcessingFailed = false;
+  bool FileSkipped = false;
   for (const auto &SourcePath : SourcePaths) {
 std::string File(getAbsolutePath(SourcePath));
 
@@ -401,12 +402,8 @@
 std::vector CompileCommandsForFile =
 Compilations.getCompileCommands(File);
 if (CompileCommandsForFile.empty()) {
-  // FIXME: There are two use cases here: doing a fuzzy
-  // "find . -name '*.cc' |xargs tool" match, where as a user I don't care
-  // about the .cc files that were not found, and the use case where I
-  // specify all files I want to run over explicitly, where this should
-  // be an error. We'll want to add an option for this.
   llvm::errs() << "Skipping " << File << ". Compile command not found.\n";
+  FileSkipped = true;
   continue;
 }
 for (CompileCommand &CompileCommand : CompileCommandsForFile) {
@@ -466,7 +463,7 @@
  Twine(InitialDirectory) + "\n!");
 }
   }
-  return ProcessingFailed ? 1 : 0;
+  return ProcessingFailed ? 1 : (FileSkipped ? 2 : 0);
 }
 
 namespace {


Index: cfe/trunk/include/clang/Tooling/Tooling.h
===
--- cfe/trunk/include/clang/Tooling/Tooling.h
+++ cfe/trunk/include/clang/Tooling/Tooling.h
@@ -330,6 +330,9 @@
   /// Runs an action over all files specified in the command line.
   ///
   /// \param Action Tool action.
+  ///
+  /// \returns 0 on success; 1 if any error occured; 2 if there is no error but
+  /// some files are skipped due to missing compile commands.
   int run(ToolAction *Action);
 
   /// \brief Create an AST for each file specified in the command line and
Index: cfe/trunk/lib/Tooling/Tooling.cpp
===
--- cfe/trunk/lib/Tooling/Tooling.cpp
+++ cfe/trunk/lib/Tooling/Tooling.cpp
@@ -388,6 +388,7 @@
 llvm::MemoryBuffer::getMemBuffer(MappedFile.second));
 
   bool ProcessingFailed = false;
+  bool FileSkipped = false;
   for (const auto &SourcePath : SourcePaths) {
 std::string File(getAbsolutePath(SourcePath));
 
@@ -401,12 +402,8 @@
 std::vector CompileCommandsForFile =
 Compilations.getCompileCommands(File);
 if (CompileCommandsForFile.empty()) {
-  // FIXME: There are two use cases here: doing a fuzzy
-  // "find . -name '*.cc' |xargs tool" match, where as a user I don't care
-  // about the .cc files that were not found, and the use case where I
-  // specify all files I want to run over explicitly, where this should
-  // be an error. We'll want to add an option for this.
   llvm::errs() << "Skipping " << File << ". Compile command not found.\n";
+  FileSkipped = true;
   continue;
 }
 for (CompileCommand &CompileCommand : CompileCommandsForFile) {
@@ -466,7 +463,7 @@
  Twine(InitialDirectory) + "\n!");
 }
   }
-  return ProcessingFailed ? 1 : 0;
+  return ProcessingFailed ? 1 : (FileSkipped ? 2 : 0);
 }
 
 namespace {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42857: testing phabricator email reply

[Eric Liu via Phabricator via cfe-commits]

ioeric created this revision.
Herald added subscribers: cfe-commits, klimek.
ioeric removed rCTE Clang Tools Extra as the repository for this revision.
ioeric removed subscribers: klimek, cfe-commits.
ioeric added a comment.

top Comment




Comment at: change-namespace/ChangeNamespace.cpp:42
 
+inline std::string
+joinNamespaces(const llvm::SmallVectorImpl &Namespaces) {

Test comment 1.


https://reviews.llvm.org/D42857

Files:
  change-namespace/ChangeNamespace.cpp


Index: change-namespace/ChangeNamespace.cpp
===
--- change-namespace/ChangeNamespace.cpp
+++ change-namespace/ChangeNamespace.cpp
@@ -18,16 +18,6 @@
 
 namespace {
 
-inline std::string
-joinNamespaces(const llvm::SmallVectorImpl &Namespaces) {
-  if (Namespaces.empty())
-return "";
-  std::string Result = Namespaces.front();
-  for (auto I = Namespaces.begin() + 1, E = Namespaces.end(); I != E; ++I)
-Result += ("::" + *I).str();
-  return Result;
-}
-
 // Given "a::b::c", returns {"a", "b", "c"}.
 llvm::SmallVector splitSymbolName(llvm::StringRef Name) {
   llvm::SmallVector Splitted;
@@ -49,6 +39,16 @@
   return TLoc.getLocStart();
 }
 
+inline std::string
+joinNamespaces(const llvm::SmallVectorImpl &Namespaces) {
+  if (Namespaces.empty())
+return "";
+  std::string Result = Namespaces.front();
+  for (auto I = Namespaces.begin() + 1, E = Namespaces.end(); I != E; ++I)
+Result += ("::" + *I).str();
+  return Result;
+}
+
 SourceLocation endLocationForType(TypeLoc TLoc) {
   // Dig past any namespace or keyword qualifications.
   while (TLoc.getTypeLocClass() == TypeLoc::Elaborated ||


Index: change-namespace/ChangeNamespace.cpp
===
--- change-namespace/ChangeNamespace.cpp
+++ change-namespace/ChangeNamespace.cpp
@@ -18,16 +18,6 @@
 
 namespace {
 
-inline std::string
-joinNamespaces(const llvm::SmallVectorImpl &Namespaces) {
-  if (Namespaces.empty())
-return "";
-  std::string Result = Namespaces.front();
-  for (auto I = Namespaces.begin() + 1, E = Namespaces.end(); I != E; ++I)
-Result += ("::" + *I).str();
-  return Result;
-}
-
 // Given "a::b::c", returns {"a", "b", "c"}.
 llvm::SmallVector splitSymbolName(llvm::StringRef Name) {
   llvm::SmallVector Splitted;
@@ -49,6 +39,16 @@
   return TLoc.getLocStart();
 }
 
+inline std::string
+joinNamespaces(const llvm::SmallVectorImpl &Namespaces) {
+  if (Namespaces.empty())
+return "";
+  std::string Result = Namespaces.front();
+  for (auto I = Namespaces.begin() + 1, E = Namespaces.end(); I != E; ++I)
+Result += ("::" + *I).str();
+  return Result;
+}
+
 SourceLocation endLocationForType(TypeLoc TLoc) {
   // Dig past any namespace or keyword qualifications.
   while (TLoc.getTypeLocClass() == TypeLoc::Elaborated ||
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r324114 - [analyzer] [tests] Fix crash in SATestBuild.py

[George Karpenkov via cfe-commits]

Author: george.karpenkov
Date: Fri Feb  2 10:27:14 2018
New Revision: 324114

URL: http://llvm.org/viewvc/llvm-project?rev=324114&view=rev
Log:
[analyzer] [tests] Fix crash in SATestBuild.py

Modified:
cfe/trunk/utils/analyzer/CmpRuns.py

Modified: cfe/trunk/utils/analyzer/CmpRuns.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/utils/analyzer/CmpRuns.py?rev=324114&r1=324113&r2=324114&view=diff
==
--- cfe/trunk/utils/analyzer/CmpRuns.py (original)
+++ cfe/trunk/utils/analyzer/CmpRuns.py Fri Feb  2 10:27:14 2018
@@ -97,10 +97,17 @@ class AnalysisDiagnostic:
 
 
 class CmpOptions:
+"""
+Fake output of option parser with manually constructed options.
+"""
+
 def __init__(self, verboseLog=None, rootA="", rootB=""):
 self.rootA = rootA
 self.rootB = rootB
 self.verboseLog = verboseLog
+self.relative_path_histogram = False
+self.relative_log_path_histogram = False
+self.absolute_path_histogram = False
 
 
 class AnalysisReport:


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

[PATCH] D42758: Support `#pragma comment(lib, "name")` in the frontend for ELF

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd marked 2 inline comments as done.
compnerd added a comment.

@probinson it would be pretty cool if we could get the PS4 environment to share 
the same linker options implementation.  What other options do you guys need 
for this to be a viable approach?


Repository:
  rC Clang

https://reviews.llvm.org/D42758



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

[PATCH] D42768: AST: add an extension to support SwiftCC on MS ABI

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: lib/AST/MicrosoftMangle.cpp:1717
+Out << '8';
+for (const char *NS : {"__swift_cc", "__Swift"})
+  mangleSourceName(NS);

When I implemented regcall, it was brought up that this was likely a bad idea, 
and to just choose a letter for mangleCallingConvention.  It is a really stable 
list as it is, and if you avoid ones in the immediate pattern, you'll be fine.


Repository:
  rC Clang

https://reviews.llvm.org/D42768



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

[PATCH] D42672: [CFG] [analyzer] Heavier CFGConstructor elements.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ updated this revision to Diff 132637.
NoQ added a comment.

Whoops! Actually use the new function with the assertion.

Also disable creating construction contexts when the flag is off.


https://reviews.llvm.org/D42672

Files:
  include/clang/Analysis/AnalysisDeclContext.h
  include/clang/Analysis/CFG.h
  include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
  lib/Analysis/AnalysisDeclContext.cpp
  lib/Analysis/CFG.cpp
  lib/Analysis/LiveVariables.cpp
  lib/StaticAnalyzer/Core/AnalysisManager.cpp
  lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
  lib/StaticAnalyzer/Core/CoreEngine.cpp
  lib/StaticAnalyzer/Core/ExprEngine.cpp
  lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  lib/StaticAnalyzer/Core/PathDiagnostic.cpp
  test/Analysis/analyzer-config.c
  test/Analysis/analyzer-config.cpp
  test/Analysis/cfg-rich-constructors.cpp
  test/Analysis/cfg.cpp

Index: test/Analysis/cfg.cpp
===
--- test/Analysis/cfg.cpp
+++ test/Analysis/cfg.cpp
@@ -1,5 +1,16 @@
-// RUN: %clang_analyze_cc1 -analyzer-checker=debug.DumpCFG -triple x86_64-apple-darwin12 -analyzer-config cfg-temporary-dtors=true -std=c++11 %s > %t 2>&1
-// RUN: FileCheck --input-file=%t %s
+// RUN: %clang_analyze_cc1 -analyzer-checker=debug.DumpCFG -triple x86_64-apple-darwin12 -analyzer-config cfg-temporary-dtors=true -std=c++11 -analyzer-config cfg-rich-constructors=false %s > %t 2>&1
+// RUN: FileCheck --input-file=%t -check-prefixes=CHECK,WARNINGS %s
+// RUN: %clang_analyze_cc1 -analyzer-checker=debug.DumpCFG -triple x86_64-apple-darwin12 -analyzer-config cfg-temporary-dtors=true -std=c++11 -analyzer-config cfg-rich-constructors=true %s > %t 2>&1
+// RUN: FileCheck --input-file=%t -check-prefixes=CHECK,ANALYZER %s
+
+// This file tests how we construct two different flavors of the Clang CFG -
+// the CFG used by the Sema analysis-based warnings and the CFG used by the
+// static analyzer. The difference in the behavior is checked via FileCheck
+// prefixes (WARNINGS and ANALYZER respectively). When introducing new analyzer
+// flags, no new run lines should be added - just these flags would go to the
+// respective line depending on where is it turned on and where is it turned
+// off. Feel free to add tests that test only one of the CFG flavors if you're
+// not sure how the other flavor is supposed to work in your case.
 
 // CHECK-LABEL: void checkWrap(int i)
 // CHECK: ENTRY
@@ -116,7 +127,8 @@
 // CHECK-NEXT:   Succs (1): B1
 // CHECK: [B1]
 // CHECK-NEXT:   1:  CFGNewAllocator(A *)
-// CHECK-NEXT:   2:  (CXXConstructExpr, class A)
+// WARNINGS-NEXT:   2:  (CXXConstructExpr, class A)
+// ANALYZER-NEXT:   2:  (CXXConstructExpr, [B1.3], class A)
 // CHECK-NEXT:   3: new A([B1.2])
 // CHECK-NEXT:   4: A *a = new A();
 // CHECK-NEXT:   5: a
@@ -138,7 +150,8 @@
 // CHECK: [B1]
 // CHECK-NEXT:   1: 5
 // CHECK-NEXT:   2: CFGNewAllocator(A *)
-// CHECK-NEXT:   3:  (CXXConstructExpr, class A [5])
+// WARNINGS-NEXT:   3:  (CXXConstructExpr, class A [5])
+// ANALYZER-NEXT:   3:  (CXXConstructExpr, [B1.4], class A [5])
 // CHECK-NEXT:   4: new A {{\[\[}}B1.1]]
 // CHECK-NEXT:   5: A *a = new A [5];
 // CHECK-NEXT:   6: a
@@ -331,7 +344,8 @@
 // CHECK-NEXT:  3: [B1.2] (ImplicitCastExpr, ArrayToPointerDecay, int *)
 // CHECK-NEXT:  4: [B1.3] (ImplicitCastExpr, BitCast, void *)
 // CHECK-NEXT:  5: CFGNewAllocator(MyClass *)
-// CHECK-NEXT:  6:  (CXXConstructExpr, class MyClass)
+// WARNINGS-NEXT:  6:  (CXXConstructExpr, class MyClass)
+// ANALYZER-NEXT:  6:  (CXXConstructExpr, [B1.7], class MyClass)
 // CHECK-NEXT:  7: new ([B1.4]) MyClass([B1.6])
 // CHECK-NEXT:  8: MyClass *obj = new (buffer) MyClass();
 // CHECK-NEXT:  Preds (1): B2
@@ -363,7 +377,8 @@
 // CHECK-NEXT:  4: [B1.3] (ImplicitCastExpr, BitCast, void *)
 // CHECK-NEXT:  5: 5
 // CHECK-NEXT:  6: CFGNewAllocator(MyClass *)
-// CHECK-NEXT:  7:  (CXXConstructExpr, class MyClass [5])
+// WARNINGS-NEXT:  7:  (CXXConstructExpr, class MyClass [5])
+// ANALYZER-NEXT:  7:  (CXXConstructExpr, [B1.8], class MyClass [5])
 // CHECK-NEXT:  8: new ([B1.4]) MyClass {{\[\[}}B1.5]]
 // CHECK-NEXT:  9: MyClass *obj = new (buffer) MyClass [5];
 // CHECK-NEXT:  Preds (1): B2
Index: test/Analysis/cfg-rich-constructors.cpp
===
--- /dev/null
+++ test/Analysis/cfg-rich-constructors.cpp
@@ -0,0 +1,46 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=debug.DumpCFG -triple x86_64-apple-darwin12 -analyzer-config cfg-temporary-dtors=true -std=c++11 %s > %t 2>&1
+// RUN: FileCheck --input-file=%t %s
+
+class C {
+public:
+  C();
+  C(C *);
+};
+
+typedef __typeof(sizeof(int)) size_t;
+void *operator new(size_t size, void *placement);
+
+namespace operator_new {
+
+// CHECK: void operatorNewWithConstructor()
+// CHECK:  1: CFGNewAllocator(C *)
+// CHECK-NEXT: 2:  (CXXConstructExpr, [B1.3], class C)
+// CHECK-NEXT: 3: new C([B1.2])

[PATCH] D42672: [CFG] [analyzer] Heavier CFGConstructor elements.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added inline comments.



Comment at: lib/Analysis/CFG.cpp:3899
+  if (auto *CE = const_cast(NE->getConstructExpr()))
+CurrentConstructionContext = {/*Constructor=*/CE, /*Trigger=*/NE};
+

NoQ wrote:
> dcoughlin wrote:
> > Is it possible that there is already a CurrentConstructionContext? Will 
> > this overwrite it?
> > 
> > Can you write an assertion to make sure that this doesn't happen?
> > 
> > Generally I would expect a context to have a well-defined start and end. I 
> > think we should be explicit about where we expect it to start and end so we 
> > can find violations of our expectations.
> Yes, for now it'd be overwritten every time we meet a new constructor (this 
> wasn't the case in the first version of this revision). However, the 
> additional check (which should be eventually replaced with an assertion, but 
> is for now needed) that we're picking the right context in `CXXConstructExpr` 
> visit, together with only visiting every constructor once during CFG 
> construction during normal visits (because weird stuff like 
> `CXXDefaultArgExpr` isn't yet supported), guarantees that we're not doing 
> anything wrong.
> 
> I should have cleaned this up, but i don't want to invest attention into that 
> because subsequent patches will clearly make things way more complex than 
> that, whenever we start dealing with a multitude of construction contexts or 
> with partially-constructed contexts.
> 
> So for now it's a trivial kinda-safe solution.
> 
> I should document that though, for sure.
Fixed now - added the `VisitForConstructionContext()` wrapper which contains 
the assertion that checks that we're not overwriting any existing context.

The context is being cleaned up after it's consumed in `appendConstructor()`.


https://reviews.llvm.org/D42672



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

[PATCH] D42860: [ReleaseNotes] Add note for the new -fexperimental-isel flag.

[Amara Emerson via Phabricator via cfe-commits]

aemerson created this revision.
aemerson added reviewers: hans, qcolombet.

Add note for the new -fexperimental-isel flag.


Repository:
  rC Clang

https://reviews.llvm.org/D42860

Files:
  docs/ReleaseNotes.rst


Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -132,6 +132,11 @@
   difference between the ``-std=c17`` and ``-std=c11`` language modes is the
   value of the ``__STDC_VERSION__`` macro, as C17 is a bug fix release.
 
+- Added the ``-fexperimental-isel`` and ``-fno-experimental-isel`` flags to
+  enable/disable the new GlobalISel instruction selection framework. This
+  feature is enabled by default for AArch64 at the ``-O0`` optimization level.
+  Support for other targets or optimization levels is currently incomplete.
+
 Deprecated Compiler Flags
 -
 


Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -132,6 +132,11 @@
   difference between the ``-std=c17`` and ``-std=c11`` language modes is the
   value of the ``__STDC_VERSION__`` macro, as C17 is a bug fix release.
 
+- Added the ``-fexperimental-isel`` and ``-fno-experimental-isel`` flags to
+  enable/disable the new GlobalISel instruction selection framework. This
+  feature is enabled by default for AArch64 at the ``-O0`` optimization level.
+  Support for other targets or optimization levels is currently incomplete.
+
 Deprecated Compiler Flags
 -
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42829: Emit label names according to -discard-value-names.

[Eric Fiselier via Phabricator via cfe-commits]

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



Comment at: test/CodeGenCXX/discard-name-values.cpp:7
 
-// CHECK: ret i32 %bar
-// DISCARDVALUE: ret i32 %0
+extern "C" void branch();
+

aaron.ballman wrote:
> Indentation is a bit off here. Actually, it seems off for much of the file -- 
> can you reindent the comments as well?
Ack. Clang-format to the rescue!


https://reviews.llvm.org/D42829



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

[PATCH] D42829: Emit label names according to -discard-value-names.

[Eric Fiselier via Phabricator via cfe-commits]

EricWF updated this revision to Diff 132648.
EricWF marked an inline comment as done.
EricWF added a comment.

- Address inline comments.


https://reviews.llvm.org/D42829

Files:
  lib/CodeGen/CodeGenFunction.h
  test/CodeGenCXX/discard-name-values.cpp


Index: test/CodeGenCXX/discard-name-values.cpp
===
--- test/CodeGenCXX/discard-name-values.cpp
+++ test/CodeGenCXX/discard-name-values.cpp
@@ -1,10 +1,29 @@
-// RUN: %clang_cc1 -emit-llvm  -triple=armv7-apple-darwin -emit-llvm 
-std=c++11 %s -o - -O1 | FileCheck %s
-// RUN: %clang_cc1 -emit-llvm  -triple=armv7-apple-darwin -emit-llvm 
-std=c++11 %s -o - -O1 -discard-value-names | FileCheck %s 
--check-prefix=DISCARDVALUE
+// RUN: %clang_cc1 -emit-llvm  -triple=armv7-apple-darwin -std=c++11 %s -o - 
-O1 \
+// RUN:| FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -triple=armv7-apple-darwin -std=c++11 %s -o - 
-O1 \
+// RUN:-discard-value-names | FileCheck %s --check-prefix=DISCARDVALUE
 
-int foo(int bar) {
-  return bar;
-}
+extern "C" void branch();
+
+bool test(bool pred) {
+  // DISCARDVALUE: br i1 %0, label %2, label %3
+  // CHECK: br i1 %pred, label %if.then, label %if.end
+
+  if (pred) {
+// DISCARDVALUE: ; :2:
+// DISCARDVALUE-NEXT: tail call void @branch()
+// DISCARDVALUE-NEXT: br label %3
 
-// CHECK: ret i32 %bar
-// DISCARDVALUE: ret i32 %0
+// CHECK: if.then:
+// CHECK-NEXT: tail call void @branch()
+// CHECK-NEXT: br label %if.end
+branch();
+  }
 
+  // DISCARDVALUE: ; :3:
+  // DISCARDVALUE-NEXT: ret i1 %0
+
+  // CHECK: if.end:
+  // CHECK-NEXT: ret i1 %pred
+  return pred;
+}
Index: lib/CodeGen/CodeGenFunction.h
===
--- lib/CodeGen/CodeGenFunction.h
+++ lib/CodeGen/CodeGenFunction.h
@@ -1849,11 +1849,7 @@
   llvm::BasicBlock *createBasicBlock(const Twine &name = "",
  llvm::Function *parent = nullptr,
  llvm::BasicBlock *before = nullptr) {
-#ifdef NDEBUG
-return llvm::BasicBlock::Create(getLLVMContext(), "", parent, before);
-#else
 return llvm::BasicBlock::Create(getLLVMContext(), name, parent, before);
-#endif
   }
 
   /// getBasicBlockForLabel - Return the LLVM basicblock that the specified


Index: test/CodeGenCXX/discard-name-values.cpp
===
--- test/CodeGenCXX/discard-name-values.cpp
+++ test/CodeGenCXX/discard-name-values.cpp
@@ -1,10 +1,29 @@
-// RUN: %clang_cc1 -emit-llvm  -triple=armv7-apple-darwin -emit-llvm -std=c++11 %s -o - -O1 | FileCheck %s
-// RUN: %clang_cc1 -emit-llvm  -triple=armv7-apple-darwin -emit-llvm -std=c++11 %s -o - -O1 -discard-value-names | FileCheck %s --check-prefix=DISCARDVALUE
+// RUN: %clang_cc1 -emit-llvm  -triple=armv7-apple-darwin -std=c++11 %s -o - -O1 \
+// RUN:| FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -triple=armv7-apple-darwin -std=c++11 %s -o - -O1 \
+// RUN:-discard-value-names | FileCheck %s --check-prefix=DISCARDVALUE
 
-int foo(int bar) {
-  return bar;
-}
+extern "C" void branch();
+
+bool test(bool pred) {
+  // DISCARDVALUE: br i1 %0, label %2, label %3
+  // CHECK: br i1 %pred, label %if.then, label %if.end
+
+  if (pred) {
+// DISCARDVALUE: ; :2:
+// DISCARDVALUE-NEXT: tail call void @branch()
+// DISCARDVALUE-NEXT: br label %3
 
-// CHECK: ret i32 %bar
-// DISCARDVALUE: ret i32 %0
+// CHECK: if.then:
+// CHECK-NEXT: tail call void @branch()
+// CHECK-NEXT: br label %if.end
+branch();
+  }
 
+  // DISCARDVALUE: ; :3:
+  // DISCARDVALUE-NEXT: ret i1 %0
+
+  // CHECK: if.end:
+  // CHECK-NEXT: ret i1 %pred
+  return pred;
+}
Index: lib/CodeGen/CodeGenFunction.h
===
--- lib/CodeGen/CodeGenFunction.h
+++ lib/CodeGen/CodeGenFunction.h
@@ -1849,11 +1849,7 @@
   llvm::BasicBlock *createBasicBlock(const Twine &name = "",
  llvm::Function *parent = nullptr,
  llvm::BasicBlock *before = nullptr) {
-#ifdef NDEBUG
-return llvm::BasicBlock::Create(getLLVMContext(), "", parent, before);
-#else
 return llvm::BasicBlock::Create(getLLVMContext(), name, parent, before);
-#endif
   }
 
   /// getBasicBlockForLabel - Return the LLVM basicblock that the specified
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r324127 - Emit label names according to -discard-value-names.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Fri Feb  2 11:58:34 2018
New Revision: 324127

URL: http://llvm.org/viewvc/llvm-project?rev=324127&view=rev
Log:
 Emit label names according to -discard-value-names.

Summary:
Previously, Clang only emitted label names in assert builds.
However there is a CC1 option -discard-value-names that should have been used 
to control emission instead.

This patch removes the NDEBUG preprocessor block and instead allows LLVM to 
handle removing the names in accordance with the option.


Reviewers: erichkeane, aaron.ballman, majnemer

Reviewed By: aaron.ballman

Subscribers: cfe-commits

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

Modified:
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/test/CodeGenCXX/discard-name-values.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenFunction.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenFunction.h?rev=324127&r1=324126&r2=324127&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenFunction.h (original)
+++ cfe/trunk/lib/CodeGen/CodeGenFunction.h Fri Feb  2 11:58:34 2018
@@ -1849,11 +1849,7 @@ public:
   llvm::BasicBlock *createBasicBlock(const Twine &name = "",
  llvm::Function *parent = nullptr,
  llvm::BasicBlock *before = nullptr) {
-#ifdef NDEBUG
-return llvm::BasicBlock::Create(getLLVMContext(), "", parent, before);
-#else
 return llvm::BasicBlock::Create(getLLVMContext(), name, parent, before);
-#endif
   }
 
   /// getBasicBlockForLabel - Return the LLVM basicblock that the specified

Modified: cfe/trunk/test/CodeGenCXX/discard-name-values.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/discard-name-values.cpp?rev=324127&r1=324126&r2=324127&view=diff
==
--- cfe/trunk/test/CodeGenCXX/discard-name-values.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/discard-name-values.cpp Fri Feb  2 11:58:34 2018
@@ -1,10 +1,29 @@
-// RUN: %clang_cc1 -emit-llvm  -triple=armv7-apple-darwin -emit-llvm 
-std=c++11 %s -o - -O1 | FileCheck %s
-// RUN: %clang_cc1 -emit-llvm  -triple=armv7-apple-darwin -emit-llvm 
-std=c++11 %s -o - -O1 -discard-value-names | FileCheck %s 
--check-prefix=DISCARDVALUE
+// RUN: %clang_cc1 -emit-llvm  -triple=armv7-apple-darwin -std=c++11 %s -o - 
-O1 \
+// RUN:| FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -triple=armv7-apple-darwin -std=c++11 %s -o - 
-O1 \
+// RUN:-discard-value-names | FileCheck %s --check-prefix=DISCARDVALUE
 
-int foo(int bar) {
-  return bar;
-}
+extern "C" void branch();
+
+bool test(bool pred) {
+  // DISCARDVALUE: br i1 %0, label %2, label %3
+  // CHECK: br i1 %pred, label %if.then, label %if.end
+
+  if (pred) {
+// DISCARDVALUE: ; :2:
+// DISCARDVALUE-NEXT: tail call void @branch()
+// DISCARDVALUE-NEXT: br label %3
 
-// CHECK: ret i32 %bar
-// DISCARDVALUE: ret i32 %0
+// CHECK: if.then:
+// CHECK-NEXT: tail call void @branch()
+// CHECK-NEXT: br label %if.end
+branch();
+  }
 
+  // DISCARDVALUE: ; :3:
+  // DISCARDVALUE-NEXT: ret i1 %0
+
+  // CHECK: if.end:
+  // CHECK-NEXT: ret i1 %pred
+  return pred;
+}


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

[PATCH] D42829: Emit label names according to -discard-value-names.

[Eric Fiselier via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC324127:  Emit label names according to -discard-value-names. 
(authored by EricWF, committed by ).

Repository:
  rC Clang

https://reviews.llvm.org/D42829

Files:
  lib/CodeGen/CodeGenFunction.h
  test/CodeGenCXX/discard-name-values.cpp


Index: test/CodeGenCXX/discard-name-values.cpp
===
--- test/CodeGenCXX/discard-name-values.cpp
+++ test/CodeGenCXX/discard-name-values.cpp
@@ -1,10 +1,29 @@
-// RUN: %clang_cc1 -emit-llvm  -triple=armv7-apple-darwin -emit-llvm 
-std=c++11 %s -o - -O1 | FileCheck %s
-// RUN: %clang_cc1 -emit-llvm  -triple=armv7-apple-darwin -emit-llvm 
-std=c++11 %s -o - -O1 -discard-value-names | FileCheck %s 
--check-prefix=DISCARDVALUE
+// RUN: %clang_cc1 -emit-llvm  -triple=armv7-apple-darwin -std=c++11 %s -o - 
-O1 \
+// RUN:| FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -triple=armv7-apple-darwin -std=c++11 %s -o - 
-O1 \
+// RUN:-discard-value-names | FileCheck %s --check-prefix=DISCARDVALUE
 
-int foo(int bar) {
-  return bar;
-}
+extern "C" void branch();
+
+bool test(bool pred) {
+  // DISCARDVALUE: br i1 %0, label %2, label %3
+  // CHECK: br i1 %pred, label %if.then, label %if.end
+
+  if (pred) {
+// DISCARDVALUE: ; :2:
+// DISCARDVALUE-NEXT: tail call void @branch()
+// DISCARDVALUE-NEXT: br label %3
 
-// CHECK: ret i32 %bar
-// DISCARDVALUE: ret i32 %0
+// CHECK: if.then:
+// CHECK-NEXT: tail call void @branch()
+// CHECK-NEXT: br label %if.end
+branch();
+  }
 
+  // DISCARDVALUE: ; :3:
+  // DISCARDVALUE-NEXT: ret i1 %0
+
+  // CHECK: if.end:
+  // CHECK-NEXT: ret i1 %pred
+  return pred;
+}
Index: lib/CodeGen/CodeGenFunction.h
===
--- lib/CodeGen/CodeGenFunction.h
+++ lib/CodeGen/CodeGenFunction.h
@@ -1849,11 +1849,7 @@
   llvm::BasicBlock *createBasicBlock(const Twine &name = "",
  llvm::Function *parent = nullptr,
  llvm::BasicBlock *before = nullptr) {
-#ifdef NDEBUG
-return llvm::BasicBlock::Create(getLLVMContext(), "", parent, before);
-#else
 return llvm::BasicBlock::Create(getLLVMContext(), name, parent, before);
-#endif
   }
 
   /// getBasicBlockForLabel - Return the LLVM basicblock that the specified


Index: test/CodeGenCXX/discard-name-values.cpp
===
--- test/CodeGenCXX/discard-name-values.cpp
+++ test/CodeGenCXX/discard-name-values.cpp
@@ -1,10 +1,29 @@
-// RUN: %clang_cc1 -emit-llvm  -triple=armv7-apple-darwin -emit-llvm -std=c++11 %s -o - -O1 | FileCheck %s
-// RUN: %clang_cc1 -emit-llvm  -triple=armv7-apple-darwin -emit-llvm -std=c++11 %s -o - -O1 -discard-value-names | FileCheck %s --check-prefix=DISCARDVALUE
+// RUN: %clang_cc1 -emit-llvm  -triple=armv7-apple-darwin -std=c++11 %s -o - -O1 \
+// RUN:| FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -triple=armv7-apple-darwin -std=c++11 %s -o - -O1 \
+// RUN:-discard-value-names | FileCheck %s --check-prefix=DISCARDVALUE
 
-int foo(int bar) {
-  return bar;
-}
+extern "C" void branch();
+
+bool test(bool pred) {
+  // DISCARDVALUE: br i1 %0, label %2, label %3
+  // CHECK: br i1 %pred, label %if.then, label %if.end
+
+  if (pred) {
+// DISCARDVALUE: ; :2:
+// DISCARDVALUE-NEXT: tail call void @branch()
+// DISCARDVALUE-NEXT: br label %3
 
-// CHECK: ret i32 %bar
-// DISCARDVALUE: ret i32 %0
+// CHECK: if.then:
+// CHECK-NEXT: tail call void @branch()
+// CHECK-NEXT: br label %if.end
+branch();
+  }
 
+  // DISCARDVALUE: ; :3:
+  // DISCARDVALUE-NEXT: ret i1 %0
+
+  // CHECK: if.end:
+  // CHECK-NEXT: ret i1 %pred
+  return pred;
+}
Index: lib/CodeGen/CodeGenFunction.h
===
--- lib/CodeGen/CodeGenFunction.h
+++ lib/CodeGen/CodeGenFunction.h
@@ -1849,11 +1849,7 @@
   llvm::BasicBlock *createBasicBlock(const Twine &name = "",
  llvm::Function *parent = nullptr,
  llvm::BasicBlock *before = nullptr) {
-#ifdef NDEBUG
-return llvm::BasicBlock::Create(getLLVMContext(), "", parent, before);
-#else
 return llvm::BasicBlock::Create(getLLVMContext(), name, parent, before);
-#endif
   }
 
   /// getBasicBlockForLabel - Return the LLVM basicblock that the specified
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D42768: AST: add an extension to support SwiftCC on MS ABI

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

rsmith added inline comments.



Comment at: lib/AST/MicrosoftMangle.cpp:1061
+if (Ty->getAs()->getCallConv() == CC_Swift)
+  for (const char *NS : {"__swift_cc", "__Swift"})
+mangleSourceName(NS);

Do we really need both of these qualifiers? This seems redundant to me.



Comment at: lib/AST/MicrosoftMangle.cpp:1717
+Out << '8';
+for (const char *NS : {"__swift_cc", "__Swift"})
+  mangleSourceName(NS);

erichkeane wrote:
> When I implemented regcall, it was brought up that this was likely a bad 
> idea, and to just choose a letter for mangleCallingConvention.  It is a 
> really stable list as it is, and if you avoid ones in the immediate pattern, 
> you'll be fine.
If you can get someone at Microsoft to sign off on us using a specific letter, 
that seems fine. Otherwise, because we don't define the ABI, we don't get to 
invent extensions to it, and we should instead pick something (like this) that 
we can be confident won't conflict with future official mangling extensions


Repository:
  rC Clang

https://reviews.llvm.org/D42768



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

[PATCH] D42530: Clang permits assignment to vector/extvector elements in a const method

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

No, really, in CreateBuiltinArraySubscriptExpr and LookupMemberExpr, in the 
clauses where they handle vector types, you just need to propagate qualifiers 
from the base type like is done in BuildFieldReferenceExpr.  There's even a 
FIXME about it in the former.


https://reviews.llvm.org/D42530



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

[PATCH] D42768: AST: add an extension to support SwiftCC on MS ABI

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: lib/AST/MicrosoftMangle.cpp:1717
+Out << '8';
+for (const char *NS : {"__swift_cc", "__Swift"})
+  mangleSourceName(NS);

rsmith wrote:
> erichkeane wrote:
> > When I implemented regcall, it was brought up that this was likely a bad 
> > idea, and to just choose a letter for mangleCallingConvention.  It is a 
> > really stable list as it is, and if you avoid ones in the immediate 
> > pattern, you'll be fine.
> If you can get someone at Microsoft to sign off on us using a specific 
> letter, that seems fine. Otherwise, because we don't define the ABI, we don't 
> get to invent extensions to it, and we should instead pick something (like 
> this) that we can be confident won't conflict with future official mangling 
> extensions
Hmm... well, when we did it with RegCall, we didn't get them to 'sign off' so 
to speak, but simply alerted them about it after the fact and they promised to 
keep an eye on it.


Repository:
  rC Clang

https://reviews.llvm.org/D42768



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

r324131 - [clang-format] New format param ObjCBinPackProtocolList

[Ben Hamilton via cfe-commits]

Author: benhamilton
Date: Fri Feb  2 12:15:14 2018
New Revision: 324131

URL: http://llvm.org/viewvc/llvm-project?rev=324131&view=rev
Log:
[clang-format] New format param ObjCBinPackProtocolList

Summary:
This is an alternative approach to D42014 after some
investigation by stephanemoore@ and myself.

Previously, the format parameter `BinPackParameters` controlled both
C function parameter list bin-packing and Objective-C protocol conformance
list bin-packing.

We found in the Google style, some teams were changing
`BinPackParameters` from its default (`true`) to `false` so they could
lay out Objective-C protocol conformance list items one-per-line
instead of bin-packing them into as few lines as possible.

To allow teams to use one-per-line Objective-C protocol lists without
changing bin-packing for other areas like C function parameter lists,
this diff introduces a new LibFormat parameter
`ObjCBinPackProtocolList` to control the behavior just for ObjC
protocol conformance lists.

The new parameter is an enum which defaults to `Auto` to keep the
previous behavior (delegating to `BinPackParameters`).

Depends On D42649

Test Plan: New tests added. make -j12 FormatTests && 
./tools/clang/unittests/Format/FormatTests

Reviewers: jolesiak, stephanemoore, djasper

Reviewed By: stephanemoore

Subscribers: Wizard, hokein, cfe-commits, klimek

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

Modified:
cfe/trunk/include/clang/Format/Format.h
cfe/trunk/lib/Format/ContinuationIndenter.cpp
cfe/trunk/lib/Format/Format.cpp
cfe/trunk/unittests/Format/FormatTestObjC.cpp

Modified: cfe/trunk/include/clang/Format/Format.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Format/Format.h?rev=324131&r1=324130&r2=324131&view=diff
==
--- cfe/trunk/include/clang/Format/Format.h (original)
+++ cfe/trunk/include/clang/Format/Format.h Fri Feb  2 12:15:14 2018
@@ -390,6 +390,17 @@ struct FormatStyle {
   /// \endcode
   bool BinPackParameters;
 
+  /// \brief The style of wrapping parameters on the same line (bin-packed) or
+  /// on one line each.
+  enum BinPackStyle {
+/// Automatically determine parameter bin-packing behavior.
+BPS_Auto,
+/// Always bin-pack parameters.
+BPS_Always,
+/// Never bin-pack parameters.
+BPS_Never,
+  };
+
   /// \brief The style of breaking before or after binary operators.
   enum BinaryOperatorStyle {
 /// Break after operators.
@@ -1299,6 +1310,38 @@ struct FormatStyle {
   /// \brief The indentation used for namespaces.
   NamespaceIndentationKind NamespaceIndentation;
 
+  /// \brief Controls bin-packing Objective-C protocol conformance list
+  /// items into as few lines as possible when they go over ``ColumnLimit``.
+  ///
+  /// If ``Auto`` (the default), delegates to the value in
+  /// ``BinPackParameters``. If that is ``true``, bin-packs Objective-C
+  /// protocol conformance list items into as few lines as possible
+  /// whenever they go over ``ColumnLimit``.
+  ///
+  /// If ``Always``, always bin-packs Objective-C protocol conformance
+  /// list items into as few lines as possible whenever they go over
+  /// ``ColumnLimit``.
+  ///
+  /// If ``Never``, lays out Objective-C protocol conformance list items
+  /// onto individual lines whenever they go over ``ColumnLimit``.
+  ///
+  /// \code
+  ///Always (or Auto, if BinPackParameters=true):
+  ///@interface c () <
+  ///c, c,
+  ///c, c> {
+  ///}
+  ///
+  ///Never (or Auto, if BinPackParameters=false):
+  ///@interface d () <
+  ///d,
+  ///d,
+  ///d,
+  ///d> {
+  ///}
+  /// \endcode
+  BinPackStyle ObjCBinPackProtocolList;
+
   /// \brief The number of characters to use for indentation of ObjC blocks.
   /// \code{.objc}
   ///ObjCBlockIndentWidth: 4
@@ -1681,6 +1724,7 @@ struct FormatStyle {
MacroBlockEnd == R.MacroBlockEnd &&
MaxEmptyLinesToKeep == R.MaxEmptyLinesToKeep &&
NamespaceIndentation == R.NamespaceIndentation &&
+   ObjCBinPackProtocolList == R.ObjCBinPackProtocolList &&
ObjCBlockIndentWidth == R.ObjCBlockIndentWidth &&
ObjCSpaceAfterProperty == R.ObjCSpaceAfterProperty &&
ObjCSpaceBeforeProtocolList == R.ObjCSpaceBeforeProtocolList &&

Modified: cfe/trunk/lib/Format/ContinuationIndenter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/ContinuationIndenter.cpp?rev=324131&r1=324130&r2=324131&view=diff
==
--- cfe/trunk/lib/Format/ContinuationIndenter.cpp (original)
+++ cfe/trunk/lib/Format/ContinuationIndenter.cpp Fri Feb  2 12:15:14 2018
@@ -1222,9 +1222,20 @@ void ContinuationIndenter::moveStatePast
 Cu

[PATCH] D42650: [clang-format] New format param ObjCBinPackProtocolList

[Ben Hamilton via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC324131: [clang-format] New format param 
ObjCBinPackProtocolList (authored by benhamilton, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D42650?vs=132187&id=132650#toc

Repository:
  rC Clang

https://reviews.llvm.org/D42650

Files:
  include/clang/Format/Format.h
  lib/Format/ContinuationIndenter.cpp
  lib/Format/Format.cpp
  unittests/Format/FormatTestObjC.cpp

Index: include/clang/Format/Format.h
===
--- include/clang/Format/Format.h
+++ include/clang/Format/Format.h
@@ -390,6 +390,17 @@
   /// \endcode
   bool BinPackParameters;
 
+  /// \brief The style of wrapping parameters on the same line (bin-packed) or
+  /// on one line each.
+  enum BinPackStyle {
+/// Automatically determine parameter bin-packing behavior.
+BPS_Auto,
+/// Always bin-pack parameters.
+BPS_Always,
+/// Never bin-pack parameters.
+BPS_Never,
+  };
+
   /// \brief The style of breaking before or after binary operators.
   enum BinaryOperatorStyle {
 /// Break after operators.
@@ -1299,6 +1310,38 @@
   /// \brief The indentation used for namespaces.
   NamespaceIndentationKind NamespaceIndentation;
 
+  /// \brief Controls bin-packing Objective-C protocol conformance list
+  /// items into as few lines as possible when they go over ``ColumnLimit``.
+  ///
+  /// If ``Auto`` (the default), delegates to the value in
+  /// ``BinPackParameters``. If that is ``true``, bin-packs Objective-C
+  /// protocol conformance list items into as few lines as possible
+  /// whenever they go over ``ColumnLimit``.
+  ///
+  /// If ``Always``, always bin-packs Objective-C protocol conformance
+  /// list items into as few lines as possible whenever they go over
+  /// ``ColumnLimit``.
+  ///
+  /// If ``Never``, lays out Objective-C protocol conformance list items
+  /// onto individual lines whenever they go over ``ColumnLimit``.
+  ///
+  /// \code
+  ///Always (or Auto, if BinPackParameters=true):
+  ///@interface c () <
+  ///c, c,
+  ///c, c> {
+  ///}
+  ///
+  ///Never (or Auto, if BinPackParameters=false):
+  ///@interface d () <
+  ///d,
+  ///d,
+  ///d,
+  ///d> {
+  ///}
+  /// \endcode
+  BinPackStyle ObjCBinPackProtocolList;
+
   /// \brief The number of characters to use for indentation of ObjC blocks.
   /// \code{.objc}
   ///ObjCBlockIndentWidth: 4
@@ -1681,6 +1724,7 @@
MacroBlockEnd == R.MacroBlockEnd &&
MaxEmptyLinesToKeep == R.MaxEmptyLinesToKeep &&
NamespaceIndentation == R.NamespaceIndentation &&
+   ObjCBinPackProtocolList == R.ObjCBinPackProtocolList &&
ObjCBlockIndentWidth == R.ObjCBlockIndentWidth &&
ObjCSpaceAfterProperty == R.ObjCSpaceAfterProperty &&
ObjCSpaceBeforeProtocolList == R.ObjCSpaceBeforeProtocolList &&
Index: lib/Format/Format.cpp
===
--- lib/Format/Format.cpp
+++ lib/Format/Format.cpp
@@ -105,6 +105,14 @@
   }
 };
 
+template <> struct ScalarEnumerationTraits {
+  static void enumeration(IO &IO, FormatStyle::BinPackStyle &Value) {
+IO.enumCase(Value, "Auto", FormatStyle::BPS_Auto);
+IO.enumCase(Value, "Always", FormatStyle::BPS_Always);
+IO.enumCase(Value, "Never", FormatStyle::BPS_Never);
+  }
+};
+
 template <> struct ScalarEnumerationTraits {
   static void enumeration(IO &IO, FormatStyle::BinaryOperatorStyle &Value) {
 IO.enumCase(Value, "All", FormatStyle::BOS_All);
@@ -378,6 +386,7 @@
 IO.mapOptional("MacroBlockEnd", Style.MacroBlockEnd);
 IO.mapOptional("MaxEmptyLinesToKeep", Style.MaxEmptyLinesToKeep);
 IO.mapOptional("NamespaceIndentation", Style.NamespaceIndentation);
+IO.mapOptional("ObjCBinPackProtocolList", Style.ObjCBinPackProtocolList);
 IO.mapOptional("ObjCBlockIndentWidth", Style.ObjCBlockIndentWidth);
 IO.mapOptional("ObjCSpaceAfterProperty", Style.ObjCSpaceAfterProperty);
 IO.mapOptional("ObjCSpaceBeforeProtocolList",
@@ -637,6 +646,7 @@
   LLVMStyle.MaxEmptyLinesToKeep = 1;
   LLVMStyle.KeepEmptyLinesAtTheStartOfBlocks = true;
   LLVMStyle.NamespaceIndentation = FormatStyle::NI_None;
+  LLVMStyle.ObjCBinPackProtocolList = FormatStyle::BPS_Auto;
   LLVMStyle.ObjCBlockIndentWidth = 2;
   LLVMStyle.ObjCSpaceAfterProperty = false;
   LLVMStyle.ObjCSpaceBeforeProtocolList = true;
Index: lib/Format/ContinuationIndenter.cpp
===
--- lib/Format/ContinuationIndenter.cpp
+++ lib/Format/ContinuationIndenter.cpp
@@ -1222,9 +1222,20 @@
 Current.MatchingParen->getPreviousNonComment() &&
 Current.MatchingParen->getPreviousNonComment()->is(tok:

[PATCH] D42014: Disable BinPackArguments and BinPackParameters in Google Objective-C style ⚙️

[Stephane Moore via Phabricator via cfe-commits]

stephanemoore abandoned this revision.
stephanemoore added a comment.

After talking with Ben I think I will abandon this and we'll focus on 
separating Objective-C protocol list formatting out of BinPackParameters.


https://reviews.llvm.org/D42014



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

r324132 - [clang-proto-to-cxx] Accept protobufs with missing fields.

[Matt Morehouse via cfe-commits]

Author: morehouse
Date: Fri Feb  2 12:22:20 2018
New Revision: 324132

URL: http://llvm.org/viewvc/llvm-project?rev=324132&view=rev
Log:
[clang-proto-to-cxx] Accept protobufs with missing fields.

libprotobuf-mutator accepts protobufs with missing fields, which means
clang-proto-fuzzer does as well.  clang-proto-to-cxx should match this
behavior.

Modified:
cfe/trunk/tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.cpp

Modified: cfe/trunk/tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.cpp?rev=324132&r1=324131&r2=324132&view=diff
==
--- cfe/trunk/tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.cpp (original)
+++ cfe/trunk/tools/clang-fuzzer/proto-to-cxx/proto_to_cxx.cpp Fri Feb  2 
12:22:20 2018
@@ -94,7 +94,7 @@ std::string FunctionToString(const Funct
 }
 std::string ProtoToCxx(const uint8_t *data, size_t size) {
   Function message;
-  if (!message.ParseFromArray(data, size))
+  if (!message.ParsePartialFromArray(data, size))
 return "#error invalid proto\n";
   return FunctionToString(message);
 }


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

r324133 - Documentation cleanup, no functional change.

[James Dennett via cfe-commits]

Author: jdennett
Date: Fri Feb  2 12:22:29 2018
New Revision: 324133

URL: http://llvm.org/viewvc/llvm-project?rev=324133&view=rev
Log:
Documentation cleanup, no functional change.

Modified:
cfe/trunk/include/clang/AST/Decl.h

Modified: cfe/trunk/include/clang/AST/Decl.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=324133&r1=324132&r2=324133&view=diff
==
--- cfe/trunk/include/clang/AST/Decl.h (original)
+++ cfe/trunk/include/clang/AST/Decl.h Fri Feb  2 12:22:29 2018
@@ -76,7 +76,7 @@ class TypeLoc;
 class UnresolvedSetImpl;
 class VarTemplateDecl;
 
-/// \brief A container of type source information.
+/// A container of type source information.
 ///
 /// A client can read the relevant info using TypeLoc wrappers, e.g:
 /// @code
@@ -93,13 +93,13 @@ class LLVM_ALIGNAS(8) TypeSourceInfo {
   TypeSourceInfo(QualType ty) : Ty(ty) {}
 
 public:
-  /// \brief Return the type wrapped by this type source info.
+  /// Return the type wrapped by this type source info.
   QualType getType() const { return Ty; }
 
-  /// \brief Return the TypeLoc wrapper for the type source info.
+  /// Return the TypeLoc wrapper for the type source info.
   TypeLoc getTypeLoc() const; // implemented in TypeLoc.h
   
-  /// \brief Override the type stored in this TypeSourceInfo. Use with caution!
+  /// Override the type stored in this TypeSourceInfo. Use with caution!
   void overrideType(QualType T) { Ty = T; }
 };
 
@@ -134,7 +134,7 @@ public:
   }
 };
 
-/// \brief Represents a `#pragma comment` line. Always a child of
+/// Represents a `#pragma comment` line. Always a child of
 /// TranslationUnitDecl.
 class PragmaCommentDecl final
 : public Decl,
@@ -168,7 +168,7 @@ public:
   static bool classofKind(Kind K) { return K == PragmaComment; }
 };
 
-/// \brief Represents a `#pragma detect_mismatch` line. Always a child of
+/// Represents a `#pragma detect_mismatch` line. Always a child of
 /// TranslationUnitDecl.
 class PragmaDetectMismatchDecl final
 : public Decl,
@@ -201,7 +201,7 @@ public:
   static bool classofKind(Kind K) { return K == PragmaDetectMismatch; }
 };
 
-/// \brief Declaration context for names declared as extern "C" in C++. This
+/// Declaration context for names declared as extern "C" in C++. This
 /// is neither the semantic nor lexical context for such declarations, but is
 /// used to check for conflicts with other extern "C" declarations. Example:
 ///
@@ -240,10 +240,13 @@ public:
   }
 };
 
-/// NamedDecl - This represents a decl with a name.  Many decls have names such
+/// This represents a decl that may have a name.  Many decls have names such
 /// as ObjCMethodDecl, but not \@class, etc.
+///
+/// Note that not every NamedDecl is actually named (e.g., a struct might
+/// be anonymous), and not every name is an identifier.
 class NamedDecl : public Decl {
-  /// Name - The name of this declaration, which is typically a normal
+  /// The name of this declaration, which is typically a normal
   /// identifier but may also be a special kind of name (C++
   /// constructor, Objective-C selector, etc.)
   DeclarationName Name;
@@ -258,13 +261,15 @@ protected:
   : Decl(DK, DC, L), Name(N) {}
 
 public:
-  /// getIdentifier - Get the identifier that names this declaration,
-  /// if there is one. This will return NULL if this declaration has
-  /// no name (e.g., for an unnamed class) or if the name is a special
-  /// name (C++ constructor, Objective-C selector, etc.).
+  /// Get the identifier that names this declaration, if there is one.
+  ///
+  /// This will return NULL if this declaration has no name (e.g., for
+  /// an unnamed class) or if the name is a special name (C++ constructor,
+  /// Objective-C selector, etc.).
   IdentifierInfo *getIdentifier() const { return Name.getAsIdentifierInfo(); }
 
-  /// getName - Get the name of identifier for this declaration as a StringRef.
+  /// Get the name of identifier for this declaration as a StringRef.
+  ///
   /// This requires that the declaration have a name and that it be a simple
   /// identifier.
   StringRef getName() const {
@@ -272,11 +277,12 @@ public:
 return getIdentifier() ? getIdentifier()->getName() : "";
   }
 
-  /// getNameAsString - Get a human-readable name for the declaration, even if
-  /// it is one of the special kinds of names (C++ constructor, Objective-C
-  /// selector, etc).  Creating this name requires expensive string
-  /// manipulation, so it should be called only when performance doesn't 
matter.
-  /// For simple declarations, getNameAsCString() should suffice.
+  /// Get a human-readable name for the declaration, even if it is one of the
+  /// special kinds of names (C++ constructor, Objective-C selector, etc).
+  ///
+  /// Creating this name requires expensive string manipulation, so it should
+  /// be called only when performance doesn't matter. For simple declarations,
+  /// get

[PATCH] D42863: Make __has_unique_object_representations reject empty union types.

[Eric Fiselier via Phabricator via cfe-commits]

EricWF created this revision.
EricWF added reviewers: erichkeane, rsmith, aaron.ballman, majnemer.

Clang incorrectly reports empty unions as having a unique object 
representation. However, this is not correct since `sizeof(EmptyUnion) == 1` 
AKA it has 8 bits of padding. Therefore it should be treated the same as an 
empty struct and report `false`.

@erichkeane also suggested this fix should be merged into the 6.0 release 
branch, so the initial release of `__has_unique_object_representations` is as 
bug-free as possible.


https://reviews.llvm.org/D42863

Files:
  lib/AST/ASTContext.cpp
  test/SemaCXX/type-traits.cpp


Index: test/SemaCXX/type-traits.cpp
===
--- test/SemaCXX/type-traits.cpp
+++ test/SemaCXX/type-traits.cpp
@@ -2566,6 +2566,7 @@
 static_assert(!has_unique_object_representations::value, "No 
references!");
 static_assert(!has_unique_object_representations::value, 
"No references!");
 static_assert(!has_unique_object_representations::value, "No empty 
types!");
+static_assert(!has_unique_object_representations::value, "No empty 
types!");
 
 class Compressed : Empty {
   int x;
Index: lib/AST/ASTContext.cpp
===
--- lib/AST/ASTContext.cpp
+++ lib/AST/ASTContext.cpp
@@ -2145,7 +2145,7 @@
 if (FieldSize != UnionSize)
   return false;
   }
-  return true;
+  return !RD->field_empty();
 }
 
 static bool isStructEmpty(QualType Ty) {


Index: test/SemaCXX/type-traits.cpp
===
--- test/SemaCXX/type-traits.cpp
+++ test/SemaCXX/type-traits.cpp
@@ -2566,6 +2566,7 @@
 static_assert(!has_unique_object_representations::value, "No references!");
 static_assert(!has_unique_object_representations::value, "No references!");
 static_assert(!has_unique_object_representations::value, "No empty types!");
+static_assert(!has_unique_object_representations::value, "No empty types!");
 
 class Compressed : Empty {
   int x;
Index: lib/AST/ASTContext.cpp
===
--- lib/AST/ASTContext.cpp
+++ lib/AST/ASTContext.cpp
@@ -2145,7 +2145,7 @@
 if (FieldSize != UnionSize)
   return false;
   }
-  return true;
+  return !RD->field_empty();
 }
 
 static bool isStructEmpty(QualType Ty) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r324134 - Make __has_unique_object_representations reject empty union types.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Fri Feb  2 12:30:39 2018
New Revision: 324134

URL: http://llvm.org/viewvc/llvm-project?rev=324134&view=rev
Log:
Make __has_unique_object_representations reject empty union types.

Summary:
Clang incorrectly reports empty unions as having a unique object 
representation. However, this is not correct since `sizeof(EmptyUnion) == 1` 
AKA it has 8 bits of padding. Therefore it should be treated the same as an 
empty struct and report `false`.

@erichkeane also suggested this fix should be merged into the 6.0 release 
branch, so the initial release of `__has_unique_object_representations` is as 
bug-free as possible. 

Reviewers: erichkeane, rsmith, aaron.ballman, majnemer

Reviewed By: erichkeane

Subscribers: cfe-commits, erichkeane

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

Modified:
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/test/SemaCXX/type-traits.cpp

Modified: cfe/trunk/lib/AST/ASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTContext.cpp?rev=324134&r1=324133&r2=324134&view=diff
==
--- cfe/trunk/lib/AST/ASTContext.cpp (original)
+++ cfe/trunk/lib/AST/ASTContext.cpp Fri Feb  2 12:30:39 2018
@@ -2145,7 +2145,7 @@ static bool unionHasUniqueObjectRepresen
 if (FieldSize != UnionSize)
   return false;
   }
-  return true;
+  return !RD->field_empty();
 }
 
 static bool isStructEmpty(QualType Ty) {

Modified: cfe/trunk/test/SemaCXX/type-traits.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/type-traits.cpp?rev=324134&r1=324133&r2=324134&view=diff
==
--- cfe/trunk/test/SemaCXX/type-traits.cpp (original)
+++ cfe/trunk/test/SemaCXX/type-traits.cpp Fri Feb  2 12:30:39 2018
@@ -2566,6 +2566,7 @@ static_assert(!has_unique_object_represe
 static_assert(!has_unique_object_representations::value, "No 
references!");
 static_assert(!has_unique_object_representations::value, 
"No references!");
 static_assert(!has_unique_object_representations::value, "No empty 
types!");
+static_assert(!has_unique_object_representations::value, "No empty 
types!");
 
 class Compressed : Empty {
   int x;


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

[PATCH] D42650: [clang-format] New format param ObjCBinPackProtocolList

[Ben Hamilton via Phabricator via cfe-commits]

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



Comment at: lib/Format/ContinuationIndenter.cpp:1214
 // FIXME: We likely want to do this for more combinations of brackets.
 // Verify that it is wanted for ObjC, too.
 if (Current.is(tok::less) && Current.ParentBracket == tok::l_paren) {

benhamilton wrote:
> stephanemoore wrote:
> > With the new parameter does this comment still apply? Maybe we can remove 
> > it?
> Good point.
> 
> This is about <> brackets nested inside () parens, which I believe is 
> applicable to Objective-C 2.0 generics passed to C/C++ functions, but not to 
> protocol conformance lists.
> 
> I'll send out a separate diff to add tests and clean up this comment, since I 
> think the behavior is wanted for ObjC as well, but I think it's unrelated to 
> this diff.
Followup in D42864.


Repository:
  rC Clang

https://reviews.llvm.org/D42650



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

[PATCH] D42864: [clang-format] Add more tests for Objective-C 2.0 generic alignment

[Ben Hamilton via Phabricator via cfe-commits]

benhamilton created this revision.
benhamilton added reviewers: stephanemoore, jolesiak, djasper.
Herald added subscribers: cfe-commits, klimek.
benhamilton edited the summary of this revision.
benhamilton edited the summary of this revision.

In r236412, @djasper added a comment:

  // FIXME: We likely want to do this for more combinations of brackets.
  // Verify that it is wanted for ObjC, too.

In https://reviews.llvm.org/D42650, @stephanemoore asked me to confirm this.

This followup to https://reviews.llvm.org/D42650 adds more tests to verify the 
relative
alignment behavior for Objective-C 2.0 generics passed to functions
and removes the second half of the FIXME comment.

Test Plan:

  make -j12 FormatTests && \
  ./tools/clang/unittests/Format/FormatTests --gtest_filter=FormatTestObjC.\*


Repository:
  rC Clang

https://reviews.llvm.org/D42864

Files:
  lib/Format/ContinuationIndenter.cpp
  unittests/Format/FormatTestObjC.cpp


Index: unittests/Format/FormatTestObjC.cpp
===
--- unittests/Format/FormatTestObjC.cpp
+++ unittests/Format/FormatTestObjC.cpp
@@ -189,6 +189,17 @@
"}\n");
 }
 
+TEST_F(FormatTestObjC, FormatObjCGenerics) {
+  Style.ColumnLimit = 40;
+  verifyFormat("int (\n"
+   "NSArray\n"
+   "a);\n");
+  verifyFormat("int (\n"
+   "NSArray *>\n"
+   "a);\n");
+}
+
 TEST_F(FormatTestObjC, FormatObjCInterface) {
   verifyFormat("@interface Foo : NSObject  {\n"
"@public\n"
Index: lib/Format/ContinuationIndenter.cpp
===
--- lib/Format/ContinuationIndenter.cpp
+++ lib/Format/ContinuationIndenter.cpp
@@ -1211,7 +1211,6 @@
 // void SomeFunction(vector<  // break
 //   int> v);
 // FIXME: We likely want to do this for more combinations of brackets.
-// Verify that it is wanted for ObjC, too.
 if (Current.is(tok::less) && Current.ParentBracket == tok::l_paren) {
   NewIndent = std::max(NewIndent, State.Stack.back().Indent);
   LastSpace = std::max(LastSpace, State.Stack.back().Indent);


Index: unittests/Format/FormatTestObjC.cpp
===
--- unittests/Format/FormatTestObjC.cpp
+++ unittests/Format/FormatTestObjC.cpp
@@ -189,6 +189,17 @@
"}\n");
 }
 
+TEST_F(FormatTestObjC, FormatObjCGenerics) {
+  Style.ColumnLimit = 40;
+  verifyFormat("int (\n"
+   "NSArray\n"
+   "a);\n");
+  verifyFormat("int (\n"
+   "NSArray *>\n"
+   "a);\n");
+}
+
 TEST_F(FormatTestObjC, FormatObjCInterface) {
   verifyFormat("@interface Foo : NSObject  {\n"
"@public\n"
Index: lib/Format/ContinuationIndenter.cpp
===
--- lib/Format/ContinuationIndenter.cpp
+++ lib/Format/ContinuationIndenter.cpp
@@ -1211,7 +1211,6 @@
 // void SomeFunction(vector<  // break
 //   int> v);
 // FIXME: We likely want to do this for more combinations of brackets.
-// Verify that it is wanted for ObjC, too.
 if (Current.is(tok::less) && Current.ParentBracket == tok::l_paren) {
   NewIndent = std::max(NewIndent, State.Stack.back().Indent);
   LastSpace = std::max(LastSpace, State.Stack.back().Indent);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits