[PATCH] D57404: build: remove use of llvm-config

2019-02-01 Thread Michał Górny via Phabricator via cfe-commits
mgorny added a comment.
Herald added a project: clang.

Could you please update this to match the LLD version?


Repository:
  rC Clang

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

https://reviews.llvm.org/D57404



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


[PATCH] D57388: [clangd] Implement textDocument/declaration from LSP 3.14

2019-02-01 Thread Haojian Wu via Phabricator via cfe-commits
hokein accepted this revision.
hokein added inline comments.
This revision is now accepted and ready to land.



Comment at: clangd/XRefs.cpp:38
+  // Only a single declaration is allowed.
+  if (isa(D)) // except cases above
+return D;

sammccall wrote:
> hokein wrote:
> > is this a case that we were missing before? can we add a unittest for it (I 
> > didn't find a related change in the unittest).
> Previously, this function only had to be correct for things that can be 
> declared and defined separately.
> For some decls that are always definitions (e.g. member variables) we would 
> return nullptr here, and treat them as decl-only ... but that was OK, because 
> the return value was just "a list of locations" and it didn't matter whether 
> we treated them as decls or defs when there's just one.
> 
> However now the return type is "here's the decl, and here's the def". Without 
> this change, we have Definition == llvm::None for e.g. member variables. 
> While the LSP method falls back from def->decl so you probably can't observe 
> this problem, API users can.
> 
> This is in fact covered by the tests, though it's kind of indirect (this is a 
> private helper function, after all).
> 
Thanks for the explanation. Maybe add more in the comment?



Comment at: unittests/clangd/XRefsTests.cpp:339
+if (!T.ranges("def").empty())
+  WantDecl = T.range("def");
+

hokein wrote:
> I think this should be `WantDef`? 
what about this comment?


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D57388



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


[clang-tools-extra] r352841 - [clangd] Fix -DBUILD_SHARED_LIBS=ON build - SwapIfBranches needs clangAST.

2019-02-01 Thread Roman Lebedev via cfe-commits
Author: lebedevri
Date: Fri Feb  1 00:23:23 2019
New Revision: 352841

URL: http://llvm.org/viewvc/llvm-project?rev=352841&view=rev
Log:
[clangd] Fix -DBUILD_SHARED_LIBS=ON build - SwapIfBranches needs clangAST.

Else, fails with:

[1/2] Linking CXX executable bin/clangd
FAILED: bin/clangd
: && /usr/bin/g++  -pipe -O2 -g0 -UNDEBUG -fPIC -fvisibility-inlines-hidden 
-Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic 
-Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized 
-Wno-class-memaccess -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment 
-fdiagnostics-color -ffunction-sections -fdata-sections -fno-common 
-Woverloaded-virtual -fno-strict-aliasing -pipe -O2 -g0 -UNDEBUG  -fuse-ld=lld 
-Wl,--color-diagnostics -Wl,-allow-shlib-undefined -Wl,-O3 
-Wl,--gc-sections 
tools/clang/tools/extra/clangd/refactor/tweaks/CMakeFiles/obj.clangDaemonTweaks.dir/SwapIfBranches.cpp.o
 tools/clang/tools/extra/clangd/tool/CMakeFiles/clangd.dir/ClangdMain.cpp.o  -o 
bin/clangd  -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMSupport.so.9svn -lpthread 
lib/libclangBasic.so.9svn lib/libclangTidy.so.9svn lib/libclangDaemon.so.9svn 
lib/libclangFormat.so.9svn lib/libclangFrontend.so.9svn 
lib/libclangSema.so.9svn lib/libclangTooling.so.9svn 
lib/libclangToolingCore.so.9svn && :
ld.lld: error: undefined symbol: 
clang::FunctionDecl::getBody(clang::FunctionDecl const*&) const
>>> referenced by SwapIfBranches.cpp
>>>   
>>> tools/clang/tools/extra/clangd/refactor/tweaks/CMakeFiles/obj.clangDaemonTweaks.dir/SwapIfBranches.cpp.o:(clang::FunctionDecl::getBody()
>>>  const)

and so on.

Modified:
clang-tools-extra/trunk/clangd/tool/CMakeLists.txt

Modified: clang-tools-extra/trunk/clangd/tool/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/tool/CMakeLists.txt?rev=352841&r1=352840&r2=352841&view=diff
==
--- clang-tools-extra/trunk/clangd/tool/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clangd/tool/CMakeLists.txt Fri Feb  1 00:23:23 2019
@@ -17,6 +17,7 @@ endif()
 
 target_link_libraries(clangd
   PRIVATE
+  clangAST
   clangBasic
   clangTidy
   clangDaemon


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


[PATCH] D57553: [Fixed Point Arithmetic] Check against source value when converting during saturation

2019-02-01 Thread Bevin Hansson via Phabricator via cfe-commits
ebevhan added a comment.

This doesn't seem to address the particular case in the integer conversion 
patch. In fact, I don't see those conversions at all.




Comment at: clang/test/Frontend/fixed_point_add.c:382
+  // CHECK-NEXT: [[USE_MIN:%[0-9]+]] = icmp slt i39 [[SUM]], -32768
+  // CHECK-NEXT: [[RES3:%[a-z0-9]+]] = select i1 [[USE_MIN]], i16 -32768, i16 
[[RES2]]
   // CHECK-NEXT: store i16 [[RES3]], i16* %sa_sat, align 2

Hm, there's a weakness with this emission. This is no longer a min-max pattern, 
which means it will be a lot harder to generate code for.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57553



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


[clang-tools-extra] r352843 - [clangd] clangDaemonTweaks - fix -DBUILD_SHARED_LIBS=ON build

2019-02-01 Thread Roman Lebedev via cfe-commits
Author: lebedevri
Date: Fri Feb  1 00:58:37 2019
New Revision: 352843

URL: http://llvm.org/viewvc/llvm-project?rev=352843&view=rev
Log:
[clangd] clangDaemonTweaks - fix -DBUILD_SHARED_LIBS=ON build

Followup for rL352841.

Modified:
clang-tools-extra/trunk/clangd/refactor/tweaks/CMakeLists.txt

Modified: clang-tools-extra/trunk/clangd/refactor/tweaks/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/refactor/tweaks/CMakeLists.txt?rev=352843&r1=352842&r2=352843&view=diff
==
--- clang-tools-extra/trunk/clangd/refactor/tweaks/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clangd/refactor/tweaks/CMakeLists.txt Fri Feb  1 
00:58:37 2019
@@ -1,5 +1,9 @@
 include_directories(${CMAKE_CURRENT_SOURCE_DIR}/../..)
 
+set(LLVM_LINK_COMPONENTS
+  support
+  )
+
 # A target containing all code tweaks (i.e. mini-refactorings) provided by
 # clangd.
 # Built as an object library to make sure linker does not remove global
@@ -9,4 +13,9 @@ include_directories(${CMAKE_CURRENT_SOUR
 # clangd/tool/CMakeLists.txt for an example.
 add_clang_library(clangDaemonTweaks OBJECT
   SwapIfBranches.cpp
+
+  LINK_LIBS
+  clangAST
+  clangDaemon
+  clangToolingCore
   )


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


[PATCH] D57571: [clang-tidy] A new OpenMP module

2019-02-01 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri created this revision.
lebedev.ri added reviewers: JonasToth, aaron.ballman, alexfh, xazax.hun, hokein.
lebedev.ri added projects: clang-tools-extra, OpenMP.
Herald added subscribers: openmp-commits, arphaman, guansong, rnkovacs, mgorny.
Herald added a project: clang.

Just the empty skeleton.
Previously reviewed as part of D57113 .


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D57571

Files:
  clang-tidy/CMakeLists.txt
  clang-tidy/ClangTidyForceLinker.h
  clang-tidy/openmp/CMakeLists.txt
  clang-tidy/openmp/OpenMPTidyModule.cpp
  clang-tidy/plugin/CMakeLists.txt
  clang-tidy/tool/CMakeLists.txt
  docs/ReleaseNotes.rst
  docs/clang-tidy/index.rst

Index: docs/clang-tidy/index.rst
===
--- docs/clang-tidy/index.rst
+++ docs/clang-tidy/index.rst
@@ -73,6 +73,7 @@
means "C++11") language constructs.
 ``mpi-``   Checks related to MPI (Message Passing Interface).
 ``objc-``  Checks related to Objective-C coding conventions.
+``openmp-``Checks related to OpenMP API.
 ``performance-``   Checks that target performance-related issues.
 ``portability-``   Checks that target portability-related issues that don't
relate to any particular coding style.
Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -67,6 +67,10 @@
 Improvements to clang-tidy
 --
 
+- New OpenMP module.
+
+  For checks specific to `OpenMP `_ API.
+
 - New :doc:`abseil-duration-addition
   ` check.
 
Index: clang-tidy/tool/CMakeLists.txt
===
--- clang-tidy/tool/CMakeLists.txt
+++ clang-tidy/tool/CMakeLists.txt
@@ -30,6 +30,7 @@
   clangTidyMiscModule
   clangTidyModernizeModule
   clangTidyObjCModule
+  clangTidyOpenMPModule
   clangTidyPerformanceModule
   clangTidyPortabilityModule
   clangTidyReadabilityModule
Index: clang-tidy/plugin/CMakeLists.txt
===
--- clang-tidy/plugin/CMakeLists.txt
+++ clang-tidy/plugin/CMakeLists.txt
@@ -21,6 +21,7 @@
   clangTidyMiscModule
   clangTidyModernizeModule
   clangTidyObjCModule
+  clangTidyOpenMPModule
   clangTidyPerformanceModule
   clangTidyPortabilityModule
   clangTidyReadabilityModule
Index: clang-tidy/openmp/OpenMPTidyModule.cpp
===
--- /dev/null
+++ clang-tidy/openmp/OpenMPTidyModule.cpp
@@ -0,0 +1,35 @@
+//===--- OpenMPTidyModule.cpp - clang-tidy===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "../ClangTidy.h"
+#include "../ClangTidyModule.h"
+#include "../ClangTidyModuleRegistry.h"
+
+namespace clang {
+namespace tidy {
+namespace openmp {
+
+/// This module is for OpenMP-specific checks.
+class OpenMPModule : public ClangTidyModule {
+public:
+  void addCheckFactories(ClangTidyCheckFactories &CheckFactories) override {
+  }
+};
+
+// Register the OpenMPTidyModule using this statically initialized variable.
+static ClangTidyModuleRegistry::Add
+X("openmp-module", "Adds OpenMP-specific checks.");
+
+} // namespace openmp
+
+// This anchor is used to force the linker to link in the generated object file
+// and thus register the OpenMPModule.
+volatile int OpenMPModuleAnchorSource = 0;
+
+} // namespace tidy
+} // namespace clang
Index: clang-tidy/openmp/CMakeLists.txt
===
--- /dev/null
+++ clang-tidy/openmp/CMakeLists.txt
@@ -0,0 +1,11 @@
+set(LLVM_LINK_COMPONENTS support)
+
+add_clang_library(clangTidyOpenMPModule
+  OpenMPTidyModule.cpp
+
+  LINK_LIBS
+  clangAST
+  clangASTMatchers
+  clangBasic
+  clangTidy
+  )
Index: clang-tidy/ClangTidyForceLinker.h
===
--- clang-tidy/ClangTidyForceLinker.h
+++ clang-tidy/ClangTidyForceLinker.h
@@ -77,6 +77,11 @@
 MPIModuleAnchorSource;
 #endif
 
+// This anchor is used to force the linker to link the OpenMPModule.
+extern volatile int OpenMPModuleAnchorSource;
+static int LLVM_ATTRIBUTE_UNUSED OpenMPModuleAnchorDestination =
+OpenMPModuleAnchorSource;
+
 // This anchor is used to force the linker to link the PerformanceModule.
 extern volatile int PerformanceModuleAnchorSource;
 static int LLVM_ATTRIBUTE_UNUSED PerformanceModuleAnchorDestination =
Index: clang-tidy/CMakeLists.txt
===
--- clang-tidy/CMakeLists.txt
+++ cl

[PATCH] D57113: [clang-tidy] openmp-use-default-none - a new check

2019-02-01 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri updated this revision to Diff 184692.
lebedev.ri retitled this revision from "[clang-tidy] openmp-use-default-none - 
a new module and a check" to "[clang-tidy] openmp-use-default-none - a new 
check".
lebedev.ri edited the summary of this revision.
lebedev.ri added a parent revision: D57571: [clang-tidy] A new OpenMP module.
lebedev.ri added a comment.
Herald added a project: clang.
Herald added a subscriber: openmp-commits.

NFC, rebased, split the new check from the new module into separate 
differentials.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D57113

Files:
  clang-tidy/openmp/CMakeLists.txt
  clang-tidy/openmp/OpenMPTidyModule.cpp
  clang-tidy/openmp/UseDefaultNoneCheck.cpp
  clang-tidy/openmp/UseDefaultNoneCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/openmp-use-default-none.rst
  test/clang-tidy/openmp-use-default-none.cpp

Index: test/clang-tidy/openmp-use-default-none.cpp
===
--- /dev/null
+++ test/clang-tidy/openmp-use-default-none.cpp
@@ -0,0 +1,160 @@
+// RUN: %check_clang_tidy %s openmp-use-default-none %t -- -- -x c++ -fopenmp -fopenmp-version=40
+// RUN: %check_clang_tidy %s openmp-use-default-none %t -- -- -x c   -fopenmp -fopenmp-version=40
+
+////
+// Null cases.
+////
+
+// 'for' directive can not have 'default' clause, no diagnostics.
+void n0(const int a) {
+#pragma omp for
+  for (int b = 0; b < a; b++)
+;
+}
+
+////
+// Single-directive positive cases.
+////
+
+// 'parallel' directive.
+
+// 'parallel' directive can have 'default' clause, but said clause is not
+// specified, diagnosed.
+void p0_0() {
+#pragma omp parallel
+  ;
+  // CHECK-NOTES: :[[@LINE-2]]:9: warning: OpenMP directive 'parallel' does not specify 'default' clause. Consider specifying 'default(none)' clause.
+}
+
+// 'parallel' directive can have 'default' clause, and said clause is specified,
+// with 'none' kind, all good.
+void p0_1() {
+#pragma omp parallel default(none)
+  ;
+}
+
+// 'parallel' directive can have 'default' clause, and said clause is specified,
+// but with 'shared' kind, which is not 'none', diagnose.
+void p0_2() {
+#pragma omp parallel default(shared)
+  ;
+  // CHECK-NOTES: :[[@LINE-2]]:9: warning: OpenMP directive 'parallel' specifies 'default(shared)' clause. Consider using 'default(none)' clause instead.
+  // CHECK-NOTES: :[[@LINE-3]]:22: note: Existing 'default' clause is specified here.
+}
+
+// 'task' directive.
+
+// 'task' directive can have 'default' clause, but said clause is not
+// specified, diagnosed.
+void p1_0() {
+#pragma omp task
+  ;
+  // CHECK-NOTES: :[[@LINE-2]]:9: warning: OpenMP directive 'task' does not specify 'default' clause. Consider specifying 'default(none)' clause.
+}
+
+// 'task' directive can have 'default' clause, and said clause is specified,
+// with 'none' kind, all good.
+void p1_1() {
+#pragma omp task default(none)
+  ;
+}
+
+// 'task' directive can have 'default' clause, and said clause is specified,
+// but with 'shared' kind, which is not 'none', diagnose.
+void p1_2() {
+#pragma omp task default(shared)
+  ;
+  // CHECK-NOTES: :[[@LINE-2]]:9: warning: OpenMP directive 'task' specifies 'default(shared)' clause. Consider using 'default(none)' clause instead.
+  // CHECK-NOTES: :[[@LINE-3]]:18: note: Existing 'default' clause is specified here.
+}
+
+// 'teams' directive. (has to be inside of 'target' directive)
+
+// 'teams' directive can have 'default' clause, but said clause is not
+// specified, diagnosed.
+void p2_0() {
+#pragma omp target
+#pragma omp teams
+  ;
+  // CHECK-NOTES: :[[@LINE-2]]:9: warning: OpenMP directive 'teams' does not specify 'default' clause. Consider specifying 'default(none)' clause.
+}
+
+// 'teams' directive can have 'default' clause, and said clause is specified,
+// with 'none' kind, all good.
+void p2_1() {
+#pragma omp target
+#pragma omp teams default(none)
+  ;
+}
+
+// 'teams' directive can have 'default' clause, and said clause is specified,
+// but with 'shared' kind, which is not 'none', diagnose.
+void p2_2() {
+#pragma omp target
+#pragma omp teams default(shared)
+  ;
+  // CHECK-NOTES: :[[@LINE-2]]:9: warning: OpenMP directive 'teams' specifies 'default(shared)' clause. Consider using 'default(none)' clause instead.
+  // CHECK-NOTES: :[[@LINE-3]]:19: note: Existing 'default' clause is specified here.
+}
+
+// 'taskloop' directive.
+
+// 'taskloop' directive can have 'default' clause, but said clause is not
+// specified, diagnosed.
+void p3_0(const int a) {
+#pragma omp taskloop
+  for (int b

[PATCH] D57322: [ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way

2019-02-01 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 184694.
martong marked 2 inline comments as done.
martong added a comment.
Herald added a project: clang.

- Remove unrelated hunks


Repository:
  rC Clang

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

https://reviews.llvm.org/D57322

Files:
  unittests/AST/ASTImporterTest.cpp

Index: unittests/AST/ASTImporterTest.cpp
===
--- unittests/AST/ASTImporterTest.cpp
+++ unittests/AST/ASTImporterTest.cpp
@@ -58,23 +58,31 @@
 // Common base for the different families of ASTImporter tests that are
 // parameterized on the compiler options which may result a different AST. E.g.
 // -fms-compatibility or -fdelayed-template-parsing.
-struct ParameterizedTestsFixture : ::testing::TestWithParam {
+class CompilerOptionSpecificTest : public ::testing::Test {
+protected:
+  // Return the extra arguments appended to runtime options at compilation.
+  virtual ArgVector getExtraArgs() const { return ArgVector(); }
 
   // Returns the argument vector used for a specific language option, this set
   // can be tweaked by the test parameters.
   ArgVector getArgVectorForLanguage(Language Lang) const {
 ArgVector Args = getBasicRunOptionsForLanguage(Lang);
-ArgVector ExtraArgs = GetParam();
+ArgVector ExtraArgs = getExtraArgs();
 for (const auto &Arg : ExtraArgs) {
   Args.push_back(Arg);
 }
 return Args;
   }
-
 };
 
+auto DefaultTestValuesForRunOptions = ::testing::Values(
+ArgVector(), ArgVector{"-fdelayed-template-parsing"},
+ArgVector{"-fms-compatibility"},
+ArgVector{"-fdelayed-template-parsing", "-fms-compatibility"});
+
 // Base class for those tests which use the family of `testImport` functions.
-class TestImportBase : public ParameterizedTestsFixture {
+class TestImportBase : public CompilerOptionSpecificTest,
+   public ::testing::WithParamInterface {
 
   template 
   NodeType importNode(ASTUnit *From, ASTUnit *To, ASTImporter &Importer,
@@ -159,6 +167,9 @@
 VerificationMatcher);
   }
 
+protected:
+  ArgVector getExtraArgs() const override { return GetParam(); }
+
 public:
 
   /// Test how AST node named "declToImport" located in the translation unit
@@ -284,7 +295,7 @@
 // This class provides generic methods to write tests which can check internal
 // attributes of AST nodes like getPreviousDecl(), isVirtual(), etc. Also,
 // this fixture makes it possible to import from several "From" contexts.
-class ASTImporterTestBase : public ParameterizedTestsFixture {
+class ASTImporterTestBase : public CompilerOptionSpecificTest {
 
   const char *const InputFileName = "input.cc";
   const char *const OutputFileName = "output.cc";
@@ -473,11 +484,18 @@
   }
 };
 
+class ASTImporterOptionSpecificTestBase
+: public ASTImporterTestBase,
+  public ::testing::WithParamInterface {
+protected:
+  ArgVector getExtraArgs() const override { return GetParam(); }
+};
+
 struct ImportExpr : TestImportBase {};
 struct ImportType : TestImportBase {};
 struct ImportDecl : TestImportBase {};
 
-struct CanonicalRedeclChain : ASTImporterTestBase {};
+struct CanonicalRedeclChain : ASTImporterOptionSpecificTestBase {};
 
 TEST_P(CanonicalRedeclChain, ShouldBeConsequentWithMatchers) {
   Decl *FromTU = getTuDecl("void f();", Lang_CXX);
@@ -1000,7 +1018,7 @@
  has(declStmt(hasSingleDecl(varDecl(hasName("d");
 }
 
-TEST_P(ASTImporterTestBase, ImportRecordTypeInFunc) {
+TEST_P(ASTImporterOptionSpecificTestBase, ImportRecordTypeInFunc) {
   Decl *FromTU = getTuDecl("int declToImport() { "
"  struct data_t {int a;int b;};"
"  struct data_t d;"
@@ -1015,7 +1033,7 @@
   EXPECT_FALSE(ToType.isNull());
 }
 
-TEST_P(ASTImporterTestBase, ImportRecordDeclInFuncParams) {
+TEST_P(ASTImporterOptionSpecificTestBase, ImportRecordDeclInFuncParams) {
   // This construct is not supported by ASTImporter.
   Decl *FromTU = getTuDecl(
   "int declToImport(struct data_t{int a;int b;} ***d){ return 0; }",
@@ -1027,7 +1045,7 @@
   EXPECT_EQ(To, nullptr);
 }
 
-TEST_P(ASTImporterTestBase, ImportRecordDeclInFuncFromMacro) {
+TEST_P(ASTImporterOptionSpecificTestBase, ImportRecordDeclInFuncFromMacro) {
   Decl *FromTU = getTuDecl(
   "#define NONAME_SIZEOF(type) sizeof(struct{type *dummy;}) \n"
   "int declToImport(){ return NONAME_SIZEOF(int); }",
@@ -1042,7 +1060,8 @@
hasDescendant(unaryExprOrTypeTraitExpr();
 }
 
-TEST_P(ASTImporterTestBase, ImportRecordDeclInFuncParamsFromMacro) {
+TEST_P(ASTImporterOptionSpecificTestBase,
+   ImportRecordDeclInFuncParamsFromMacro) {
   // This construct is not supported by ASTImporter.
   Decl *FromTU = getTuDecl(
   "#define PAIR_STRUCT(type) struct data_t{type a;type b;} \n"
@@ -1194,7 +1213,8 @@
   has(fieldDecl(hasType(dependentSizedArrayType(;
 }
 
-TEST_P(ASTImporterTestBase, ImportOfTemplated

[PATCH] D57322: [ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way

2019-02-01 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

Update: I just removed the unrelated changes.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57322



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


[PATCH] D57232: [ASTImporter] Check visibility/linkage of functions and variables

2019-02-01 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 184697.
martong added a comment.
Herald added a project: clang.

- Move hunks into this patch from parent patch


Repository:
  rC Clang

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

https://reviews.llvm.org/D57232

Files:
  include/clang/AST/ASTImporter.h
  lib/AST/ASTImporter.cpp
  unittests/AST/ASTImporterTest.cpp

Index: unittests/AST/ASTImporterTest.cpp
===
--- unittests/AST/ASTImporterTest.cpp
+++ unittests/AST/ASTImporterTest.cpp
@@ -10,6 +10,10 @@
 //
 //===--===//
 
+// Define this to have ::testing::Combine available.
+// FIXME: Better solution for this?
+#define GTEST_HAS_COMBINE 1
+
 #include "clang/AST/ASTImporter.h"
 #include "MatchVerifier.h"
 #include "clang/AST/ASTContext.h"
@@ -461,6 +465,10 @@
 return FromTU->import(*LookupTablePtr, ToAST.get(), From);
   }
 
+  template  DeclT *Import(DeclT *From, Language Lang) {
+return cast_or_null(Import(cast(From), Lang));
+  }
+
   QualType ImportType(QualType FromType, Decl *TUDecl, Language ToLang) {
 lazyInitToAST(ToLang, "", OutputFileName);
 TU *FromTU = findFromTU(TUDecl);
@@ -2256,6 +2264,266 @@
 }).match(ToTU, functionDecl()));
 }
 
+//FIXME Move these tests to a separate test file.
+namespace TypeAndValueParameterizedTests {
+
+// Type parameters for type-parameterized test fixtures.
+struct GetFunPattern {
+  using DeclTy = FunctionDecl;
+  BindableMatcher operator()() { return functionDecl(hasName("f")); }
+};
+struct GetVarPattern {
+  using DeclTy = VarDecl;
+  BindableMatcher operator()() { return varDecl(hasName("v")); }
+};
+
+// Values for the value-parameterized test fixtures.
+// FunctionDecl:
+auto *ExternF = "void f();";
+auto *StaticF = "static void f();";
+auto *AnonF = "namespace { void f(); }";
+// VarDecl:
+auto *ExternV = "extern int v;";
+auto *StaticV = "static int v;";
+auto *AnonV = "namespace { extern int v; }";
+
+// First value in tuple: Compile options.
+// Second value in tuple: Source code to be used in the test.
+using ImportVisibilityChainParams =
+::testing::WithParamInterface>;
+// Fixture to test the redecl chain of Decls with the same visibility.  Gtest
+// makes it possible to have either value-parameterized or type-parameterized
+// fixtures.  However, we cannot have both value- and type-parameterized test
+// fixtures.  This is a value-parameterized test fixture in the gtest sense. We
+// intend to mimic gtest's type-parameters via the PatternFactory template
+// parameter.  We manually instantiate the different tests with the each types.
+template 
+class ImportVisibilityChain
+: public ASTImporterTestBase, public ImportVisibilityChainParams {
+protected:
+  using DeclTy = typename PatternFactory::DeclTy;
+  ArgVector getExtraArgs() const override { return std::get<0>(GetParam()); }
+  std::string getCode() const { return std::get<1>(GetParam()); }
+  BindableMatcher getPattern() const { return PatternFactory()(); }
+
+  // Type-parameterized test.
+  void TypedTest_ImportChain() {
+std::string Code = getCode() + getCode();
+auto Pattern = getPattern();
+
+TranslationUnitDecl *FromTu = getTuDecl(Code, Lang_CXX, "input0.cc");
+
+auto *FromF0 = FirstDeclMatcher().match(FromTu, Pattern);
+auto *FromF1 = LastDeclMatcher().match(FromTu, Pattern);
+
+auto *ToF0 = Import(FromF0, Lang_CXX);
+auto *ToF1 = Import(FromF1, Lang_CXX);
+
+EXPECT_TRUE(ToF0);
+ASSERT_TRUE(ToF1);
+EXPECT_NE(ToF0, ToF1);
+EXPECT_EQ(ToF1->getPreviousDecl(), ToF0);
+  }
+};
+
+// Manual instantiation of the fixture with each type.
+using ImportFunctionsVisibilityChain = ImportVisibilityChain;
+using ImportVariablesVisibilityChain = ImportVisibilityChain;
+// Value-parameterized test for the first type.
+TEST_P(ImportFunctionsVisibilityChain, ImportChain) {
+  TypedTest_ImportChain();
+}
+// Value-parameterized test for the second type.
+TEST_P(ImportVariablesVisibilityChain, ImportChain) {
+  TypedTest_ImportChain();
+}
+
+// Automatic instantiation of the value-parameterized tests.
+INSTANTIATE_TEST_CASE_P(ParameterizedTests, ImportFunctionsVisibilityChain,
+::testing::Combine(
+   DefaultTestValuesForRunOptions,
+   ::testing::Values(ExternF, StaticF, AnonF)), );
+INSTANTIATE_TEST_CASE_P(
+ParameterizedTests, ImportVariablesVisibilityChain,
+::testing::Combine(
+DefaultTestValuesForRunOptions,
+// There is no point to instantiate with StaticV, because in C++ we can
+// forward declare a variable only with the 'extern' keyword.
+// Consequently, each fwd declared variable has external linkage.  This
+// is different in the C language where any declaration without an
+// initializer is a tentative definition, subsequent definitions may be
+  

[PATCH] D57573: Disable tidy checks with too many hits

2019-02-01 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov created this revision.
ilya-biryukov added a reviewer: alexfh.
Herald added projects: clang, LLVM.

Some tidy checks have too many hits in the codebase, making it hard to spot
other results from clang-tidy, therefore rendering the tool less useful.

Two checks were disabled:

- misc-non-private-member-variable-in-classes in the whole LLVM monorepo, it is 
very common to have those in LLVM and the style guide does not forbid them.
- readability-identifier-naming in the clang subtree. There are thousands of 
violations in 'Sema.h' alone.

Before the change, 'Sema.h' had >1000 tidy warnings, after the change the number
dropped to 3 warnings (unterminated namespace comments).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D57573

Files:
  .clang-tidy
  clang/.clang-tidy


Index: clang/.clang-tidy
===
--- clang/.clang-tidy
+++ clang/.clang-tidy
@@ -1,4 +1,7 @@
-Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-readability-identifier-naming'
+# Note that the naming checks are disabled, there are too many violations in 
the codebase.
+# Naming settings are kept for documentation purposes and in cases where one 
would enable the check by
+# overriding this configuration file.
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase
Index: .clang-tidy
===
--- .clang-tidy
+++ .clang-tidy
@@ -1,4 +1,4 @@
-Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,readability-identifier-naming'
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase


Index: clang/.clang-tidy
===
--- clang/.clang-tidy
+++ clang/.clang-tidy
@@ -1,4 +1,7 @@
-Checks: '-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: '-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-readability-identifier-naming'
+# Note that the naming checks are disabled, there are too many violations in the codebase.
+# Naming settings are kept for documentation purposes and in cases where one would enable the check by
+# overriding this configuration file.
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase
Index: .clang-tidy
===
--- .clang-tidy
+++ .clang-tidy
@@ -1,4 +1,4 @@
-Checks: '-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: '-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,readability-identifier-naming'
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57573: Disable tidy checks with too many hits

2019-02-01 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov updated this revision to Diff 184704.
ilya-biryukov added a comment.

- Also disable 'misc-non-private-member-variables-in-classes' in 
llvm/.clang-tidy


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57573

Files:
  .clang-tidy
  clang/.clang-tidy
  llvm/.clang-tidy


Index: llvm/.clang-tidy
===
--- llvm/.clang-tidy
+++ llvm/.clang-tidy
@@ -1,4 +1,4 @@
-Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,readability-identifier-naming'
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase
Index: clang/.clang-tidy
===
--- clang/.clang-tidy
+++ clang/.clang-tidy
@@ -1,4 +1,7 @@
-Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-readability-identifier-naming'
+# Note that the naming checks are disabled, there are too many violations in 
the codebase.
+# Naming settings are kept for documentation purposes and in cases where one 
would enable the check by
+# overriding this configuration file.
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase
Index: .clang-tidy
===
--- .clang-tidy
+++ .clang-tidy
@@ -1,4 +1,4 @@
-Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,readability-identifier-naming'
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase


Index: llvm/.clang-tidy
===
--- llvm/.clang-tidy
+++ llvm/.clang-tidy
@@ -1,4 +1,4 @@
-Checks: '-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: '-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,readability-identifier-naming'
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase
Index: clang/.clang-tidy
===
--- clang/.clang-tidy
+++ clang/.clang-tidy
@@ -1,4 +1,7 @@
-Checks: '-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: '-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-readability-identifier-naming'
+# Note that the naming checks are disabled, there are too many violations in the codebase.
+# Naming settings are kept for documentation purposes and in cases where one would enable the check by
+# overriding this configuration file.
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase
Index: .clang-tidy
===
--- .clang-tidy
+++ .clang-tidy
@@ -1,4 +1,4 @@
-Checks: '-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: '-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,readability-identifier-naming'
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57242: [RISCV] Specify MaxAtomicInlineWidth for RISC-V

2019-02-01 Thread Lewis Revill via Phabricator via cfe-commits
lewis-revill abandoned this revision.
lewis-revill added a comment.
Herald added a project: clang.

Abandoned in favour of D57450 


Repository:
  rC Clang

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

https://reviews.llvm.org/D57242



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


Re: r352672 - Don't define __has_feature(objc_fixed_enum) in non-objc mode

2019-02-01 Thread Hans Wennborg via cfe-commits
Sure, r352854.

On Wed, Jan 30, 2019 at 10:16 PM Erik Pilkington
 wrote:
>
> Hans, can you cherry-pick this into LLVM 8?
>
> Thanks!
>
> On 1/30/19 1:14 PM, Erik Pilkington via cfe-commits wrote:
> > Author: epilk
> > Date: Wed Jan 30 13:14:08 2019
> > New Revision: 352672
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=352672&view=rev
> > Log:
> > Don't define __has_feature(objc_fixed_enum) in non-objc mode
> >
> > This is only a formal language feature in ObjC, otherwise its just an
> > extension. Making this change was also an ABI break.
> >
> > Modified:
> >  cfe/trunk/include/clang/Basic/Features.def
> >  cfe/trunk/test/SemaObjC/enum-fixed-type.m
> >
> > Modified: cfe/trunk/include/clang/Basic/Features.def
> > URL: 
> > http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Features.def?rev=352672&r1=352671&r2=352672&view=diff
> > ==
> > --- cfe/trunk/include/clang/Basic/Features.def (original)
> > +++ cfe/trunk/include/clang/Basic/Features.def Wed Jan 30 13:14:08 2019
> > @@ -95,7 +95,7 @@ FEATURE(objc_arc, LangOpts.ObjCAutoRefCo
> >   FEATURE(objc_arc_fields, true)
> >   FEATURE(objc_arc_weak, LangOpts.ObjCWeak)
> >   FEATURE(objc_default_synthesize_properties, LangOpts.ObjC)
> > -FEATURE(objc_fixed_enum, true)
> > +FEATURE(objc_fixed_enum, LangOpts.ObjC)
> >   FEATURE(objc_instancetype, LangOpts.ObjC)
> >   FEATURE(objc_kindof, LangOpts.ObjC)
> >   FEATURE(objc_modules, LangOpts.ObjC && LangOpts.Modules)
> >
> > Modified: cfe/trunk/test/SemaObjC/enum-fixed-type.m
> > URL: 
> > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaObjC/enum-fixed-type.m?rev=352672&r1=352671&r2=352672&view=diff
> > ==
> > --- cfe/trunk/test/SemaObjC/enum-fixed-type.m (original)
> > +++ cfe/trunk/test/SemaObjC/enum-fixed-type.m Wed Jan 30 13:14:08 2019
> > @@ -1,9 +1,11 @@
> >   // RUN: %clang_cc1 -fsyntax-only -pedantic -verify %s
> >   // RUN: %clang_cc1 -fsyntax-only -verify -xc %s
> >
> > +#ifdef __OBJC__
> >   #if !__has_feature(objc_fixed_enum)
> >   #  error Enumerations with a fixed underlying type are not supported
> >   #endif
> > +#endif
> >
> >   #if !__has_extension(cxx_fixed_enum)
> >   #  error Enumerations with a fixed underlying type are not supported
> >
> >
> > ___
> > cfe-commits mailing list
> > cfe-commits@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57388: [clangd] Implement textDocument/declaration from LSP 3.14

2019-02-01 Thread Sam McCall via Phabricator via cfe-commits
sammccall updated this revision to Diff 184710.
sammccall added a comment.

address review comments


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D57388

Files:
  clangd/ClangdLSPServer.cpp
  clangd/ClangdLSPServer.h
  clangd/ClangdServer.cpp
  clangd/ClangdServer.h
  clangd/XRefs.cpp
  clangd/XRefs.h
  test/clangd/initialize-params.test
  unittests/clangd/ClangdTests.cpp
  unittests/clangd/SyncAPI.cpp
  unittests/clangd/SyncAPI.h
  unittests/clangd/TUSchedulerTests.cpp
  unittests/clangd/XRefsTests.cpp

Index: unittests/clangd/XRefsTests.cpp
===
--- unittests/clangd/XRefsTests.cpp
+++ unittests/clangd/XRefsTests.cpp
@@ -17,6 +17,7 @@
 #include "index/SymbolCollector.h"
 #include "clang/Index/IndexingAction.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/ScopedPrinter.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
@@ -25,7 +26,6 @@
 namespace {
 
 using testing::ElementsAre;
-using testing::Field;
 using testing::IsEmpty;
 using testing::Matcher;
 using testing::UnorderedElementsAreArray;
@@ -95,9 +95,35 @@
   }
 }
 
+MATCHER_P3(Sym, Name, Decl, DefOrNone, "") {
+  llvm::Optional Def = DefOrNone;
+  if (Name != arg.Name) {
+*result_listener << "Name is " << arg.Name;
+return false;
+  }
+  if (Decl != arg.PreferredDeclaration.range) {
+*result_listener << "Declaration is "
+ << llvm::to_string(arg.PreferredDeclaration);
+return false;
+  }
+  if (Def && !arg.Definition) {
+*result_listener << "Has no definition";
+return false;
+  }
+  if (Def && arg.Definition->range != *Def) {
+*result_listener << "Definition is " << llvm::to_string(arg.Definition);
+return false;
+  }
+  return true;
+}
+testing::Matcher Sym(std::string Name, Range Decl) {
+  return Sym(Name, Decl, llvm::None);
+}
+MATCHER_P(Sym, Name, "") { return arg.Name == Name; }
+
 MATCHER_P(RangeIs, R, "") { return arg.range == R; }
 
-TEST(GoToDefinition, WithIndex) {
+TEST(LocateSymbol, WithIndex) {
   Annotations SymbolHeader(R"cpp(
 class $forward[[Forward]];
 class $foo[[Foo]] {};
@@ -115,9 +141,9 @@
   TU.Code = SymbolCpp.code();
   TU.HeaderCode = SymbolHeader.code();
   auto Index = TU.index();
-  auto runFindDefinitionsWithIndex = [&Index](const Annotations &Main) {
+  auto LocateWithIndex = [&Index](const Annotations &Main) {
 auto AST = TestTU::withCode(Main.code()).build();
-return clangd::findDefinitions(AST, Main.point(), Index.get());
+return clangd::locateSymbolAt(AST, Main.point(), Index.get());
   };
 
   Annotations Test(R"cpp(// only declaration in AST.
@@ -126,9 +152,8 @@
   ^f1();
 }
   )cpp");
-  EXPECT_THAT(runFindDefinitionsWithIndex(Test),
-  testing::ElementsAreArray(
-  {RangeIs(SymbolCpp.range("f1")), RangeIs(Test.range())}));
+  EXPECT_THAT(LocateWithIndex(Test),
+  ElementsAre(Sym("f1", Test.range(), SymbolCpp.range("f1";
 
   Test = Annotations(R"cpp(// definition in AST.
 void [[f1]]() {}
@@ -136,30 +161,30 @@
   ^f1();
 }
   )cpp");
-  EXPECT_THAT(runFindDefinitionsWithIndex(Test),
-  testing::ElementsAreArray(
-  {RangeIs(Test.range()), RangeIs(SymbolHeader.range("f1"))}));
+  EXPECT_THAT(LocateWithIndex(Test),
+  ElementsAre(Sym("f1", SymbolHeader.range("f1"), Test.range(;
 
   Test = Annotations(R"cpp(// forward declaration in AST.
 class [[Foo]];
 F^oo* create();
   )cpp");
-  EXPECT_THAT(runFindDefinitionsWithIndex(Test),
-  testing::ElementsAreArray(
-  {RangeIs(SymbolHeader.range("foo")), RangeIs(Test.range())}));
+  EXPECT_THAT(LocateWithIndex(Test),
+  ElementsAre(Sym("Foo", Test.range(), SymbolHeader.range("foo";
 
   Test = Annotations(R"cpp(// defintion in AST.
 class [[Forward]] {};
 F^orward create();
   )cpp");
-  EXPECT_THAT(runFindDefinitionsWithIndex(Test),
-  testing::ElementsAreArray({
-  RangeIs(Test.range()),
-  RangeIs(SymbolHeader.range("forward")),
-  }));
+  EXPECT_THAT(
+  LocateWithIndex(Test),
+  ElementsAre(Sym("Forward", SymbolHeader.range("forward"), Test.range(;
 }
 
-TEST(GoToDefinition, All) {
+TEST(LocateSymbol, All) {
+  // Ranges in tests:
+  //   $decl is the declaration location (if absent, no symbol is located)
+  //   $def is the definition location (if absent, symbol has no definition)
+  //   unnamed range becomes both $decl and $def.
   const char *Tests[] = {
   R"cpp(// Local variable
 int main() {
@@ -186,7 +211,7 @@
   )cpp",
 
   R"cpp(// Function declaration via call
-int [[foo]](int);
+int $decl[[foo]](int);
 int main() {
   return ^foo(42);
 }
@@ -222,7 +247,7 @@
   )cpp

[PATCH] D57388: [clangd] Implement textDocument/declaration from LSP 3.14

2019-02-01 Thread Sam McCall via Phabricator via cfe-commits
sammccall marked 2 inline comments as done.
sammccall added inline comments.



Comment at: clangd/XRefs.cpp:38
+  // Only a single declaration is allowed.
+  if (isa(D)) // except cases above
+return D;

hokein wrote:
> sammccall wrote:
> > hokein wrote:
> > > is this a case that we were missing before? can we add a unittest for it 
> > > (I didn't find a related change in the unittest).
> > Previously, this function only had to be correct for things that can be 
> > declared and defined separately.
> > For some decls that are always definitions (e.g. member variables) we would 
> > return nullptr here, and treat them as decl-only ... but that was OK, 
> > because the return value was just "a list of locations" and it didn't 
> > matter whether we treated them as decls or defs when there's just one.
> > 
> > However now the return type is "here's the decl, and here's the def". 
> > Without this change, we have Definition == llvm::None for e.g. member 
> > variables. While the LSP method falls back from def->decl so you probably 
> > can't observe this problem, API users can.
> > 
> > This is in fact covered by the tests, though it's kind of indirect (this is 
> > a private helper function, after all).
> > 
> Thanks for the explanation. Maybe add more in the comment?
Added a little bit - there's not really so much to say, because the new 
behavior is kind of the obvious one.
The old behavior ("just return nullptr if it doesn't matter") maybe deserved a 
longer comment, but we didn't notice.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D57388



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


Re: r350920 - [Sema] Make canPassInRegisters return true if the CXXRecordDecl passed

2019-02-01 Thread Hans Wennborg via cfe-commits
Thanks! I've merged r352822 to the branch in r352855.

On Fri, Feb 1, 2019 at 1:37 AM Shoaib Meenai  wrote:
>
> +Hans for managing the 8.0 branch.
>
> On 1/31/19, 4:15 PM, "ahatan...@apple.com on behalf of Akira Hatanaka" 
>  wrote:
>
> Reverted patch in r352822. I’ll send a new patch later that disallows 
> trivial_abi on classes without non-deleted copy or move constructors.
>
> > On Jan 31, 2019, at 3:52 PM, Richard Smith  
> wrote:
> >
> > Given that there's uncertainty as to how to proceed and this patch
> > affects the ABI, I would prefer that we revert it for trunk and 8.0.
> >
> > The suggested alternative of disallowing trivial_abi in the case where
> > all copy/move constructors are deleted seems reasonable to me.
> >
> > On Thu, 31 Jan 2019 at 14:31, Shoaib Meenai via cfe-commits
> >  wrote:
> >>
> >> Just wanted to point out that r350920 is on the 8.0 release branch as 
> well. I don't know if there are any additional considerations there.
> >>
> >> On 1/31/19, 2:20 PM, "cfe-commits on behalf of John McCall via 
> cfe-commits"  cfe-commits@lists.llvm.org> wrote:
> >>
> >>
> >>
> >>On 31 Jan 2019, at 16:57, Akira Hatanaka wrote:
> >>
> >>> Would it be better if we disallowed trivial_abi if the class’ copy
> >>> and move destructors were all deleted (and revert r350920)? I think
> >>> that would make it easier to reason about when you are allowed to use
> >>> trivial_abi and what effect the attribute has (which is to override
> >>> the trivialness for the purpose of calls).
> >>>
> >>> Sorry for my late reply. It took a while to understand that the patch
> >>> I committed might not be the right way to fix the problem.
> >>
> >>I'd be fine with that.  If nothing else, we can generalize it later 
> if
> >>we decide that's an important use-case.
> >>
> >>John.
> >>
> >>>
>  On Jan 16, 2019, at 8:37 PM, John McCall via cfe-commits
>   wrote:
> 
>  On 16 Jan 2019, at 20:03, Richard Smith wrote:
> 
> > On Wed, 16 Jan 2019 at 16:20, John McCall via cfe-commits <
> > cfe-commits@lists.llvm.org> wrote:
> >
> >> On 16 Jan 2019, at 18:32, Richard Smith wrote:
> >>
> >>> On Wed, 16 Jan 2019 at 09:10, John McCall via cfe-commits <
> >>> cfe-commits@lists.llvm.org> wrote:
> >>>
>  On 16 Jan 2019, at 9:13, Aaron Ballman wrote:
> 
> > On Wed, Jan 16, 2019 at 1:57 AM Akira Hatanaka
> > 
> > wrote:
> >>
> >> Yes, the behavior of the compiler doesn’t match what’s
> >> explained
> >> in the documentation anymore.
> >>
> >> Please take a look at the attached patch, which updates the
> >> documentation.
> >
> > Patch mostly LGTM, but I did have one wording suggestion.
> >
> >> diff --git a/include/clang/Basic/AttrDocs.td
> >> b/include/clang/Basic/AttrDocs.td
> >> index 5773a92c9c..ca3cfcf9b2 100644
> >> --- a/include/clang/Basic/AttrDocs.td
> >> +++ b/include/clang/Basic/AttrDocs.td
> >> @@ -2478,15 +2478,20 @@ def TrivialABIDocs : Documentation {
> >>  let Category = DocCatVariable;
> >>  let Content = [{
> >> The ``trivial_abi`` attribute can be applied to a C++ class,
> >> struct,
> >> or union.
> >> -It instructs the compiler to pass and return the type using
> >> the C
> >> ABI for the
> >> +``trivial_abi`` has the following effects:
> >> +
> >> +- It instructs the compiler to pass and return the type using
> >> the C
> >> ABI for the
> >> underlying type when the type would otherwise be considered
> >> non-trivial for the
> >> purpose of calls.
> >> -A class annotated with `trivial_abi` can have non-trivial
> >> destructors or copy/move constructors without automatically
> >> becoming
> >> non-trivial for the purposes of calls. For example:
> >> +- It makes the destructor and copy and move constructors of
> >> the
> >> class trivial
> >> +that would otherwise be considered non-trivial under the C++
> >> ABI
> >> rules.
> >
> > How about: It makes the destructor, copy constructors, and move
> > constructors of the class trivial even if they would otherwise
> > be
> > non-trivial under the C++ ABI rules.
> 
>  Let's not say that it makes them trivial, because it doesn't.  It
>  causes
>  their imme

[PATCH] D57573: Disable tidy checks with too many hits

2019-02-01 Thread Haojian Wu via Phabricator via cfe-commits
hokein accepted this revision.
hokein added a comment.
This revision is now accepted and ready to land.

I'm +1 on disabling these checks as they add too much noise in editors (even 
though the naming check is correct, we can't do a global cleanup on the 
codebase). Let's commit it, we could revert it if someone has other concerns.




Comment at: clang/.clang-tidy:2
+Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-readability-identifier-naming'
+# Note that the naming checks are disabled, there are too many violations in 
the codebase.
+# Naming settings are kept for documentation purposes and in cases where one 
would enable the check by

"naming checks" => `readability-identifier-naming check`. Maybe also mention 
these violations add too much noise in editors?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57573



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


[PATCH] D57532: [Index] Make sure c-index-test finds libc++ on Mac

2019-02-01 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov updated this revision to Diff 184712.
ilya-biryukov added a comment.

- Revert "changes to main"
- Compute the path in parseTranslationUnit2


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57532

Files:
  clang/test/Index/record-completion-invocation.c
  clang/test/Index/record-parsing-invocation.c
  clang/tools/libclang/CIndex.cpp


Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -3543,12 +3543,18 @@
 const char *const *command_line_args, int num_command_line_args,
 struct CXUnsavedFile *unsaved_files, unsigned num_unsaved_files,
 unsigned options, CXTranslationUnit *out_TU) {
+  llvm::SmallString<128> MockClangPath;
+  llvm::sys::path::append(
+  MockClangPath, static_cast(CIdx)->getClangToolchainPath(),
+  "bin", "clang");
+
   SmallVector Args;
-  Args.push_back("clang");
+  Args.push_back(MockClangPath.c_str());
   Args.append(command_line_args, command_line_args + num_command_line_args);
-  return clang_parseTranslationUnit2FullArgv(
+  CXErrorCode Ret = clang_parseTranslationUnit2FullArgv(
   CIdx, source_filename, Args.data(), Args.size(), unsaved_files,
   num_unsaved_files, options, out_TU);
+  return Ret;
 }
 
 enum CXErrorCode clang_parseTranslationUnit2FullArgv(
Index: clang/test/Index/record-parsing-invocation.c
===
--- clang/test/Index/record-parsing-invocation.c
+++ clang/test/Index/record-parsing-invocation.c
@@ -24,5 +24,5 @@
 #  pragma clang __debug parser_crash
 #endif
 
-// CHECK: 
{"toolchain":"{{.*}}","libclang.operation":"parse","libclang.opts":1,"args":["clang","-fno-spell-checking","{{.*}}record-parsing-invocation.c","-Xclang","-detailed-preprocessing-record","-fallow-editor-placeholders"]}
-// CHECK-UNSAVED: 
{"toolchain":"{{.*}}","libclang.operation":"parse","libclang.opts":1,"args":["clang","-fno-spell-checking","{{.*}}record-parsing-invocation.c","-Xclang","-detailed-preprocessing-record","-fallow-editor-placeholders"],"unsaved_file_hashes":[{"name":"{{.*}}record-parsing-invocation.c","md5":"aee23773de90e665992b48209351d70e"}]}
+// CHECK: 
{"toolchain":"{{.*}}","libclang.operation":"parse","libclang.opts":1,"args":["{{.*}}clang","-fno-spell-checking","{{.*}}record-parsing-invocation.c","-Xclang","-detailed-preprocessing-record","-fallow-editor-placeholders"]}
+// CHECK-UNSAVED: 
{"toolchain":"{{.*}}","libclang.operation":"parse","libclang.opts":1,"args":["{{.*}}clang","-fno-spell-checking","{{.*}}record-parsing-invocation.c","-Xclang","-detailed-preprocessing-record","-fallow-editor-placeholders"],"unsaved_file_hashes":[{"name":"{{.*}}record-parsing-invocation.c","md5":"aee23773de90e665992b48209351d70e"}]}
Index: clang/test/Index/record-completion-invocation.c
===
--- clang/test/Index/record-completion-invocation.c
+++ clang/test/Index/record-completion-invocation.c
@@ -8,4 +8,4 @@
 // RUN: env LIBCLANG_DISABLE_CRASH_RECOVERY=1 
CINDEXTEST_INVOCATION_EMISSION_PATH=%t not --crash c-index-test 
-code-completion-at=%s:10:1 
"-remap-file=%s,%S/Inputs/record-parsing-invocation-remap.c" %s
 // RUN: cat %t/libclang-* | FileCheck %s
 
-// CHECK: 
{"toolchain":"{{.*}}","libclang.operation":"complete","libclang.opts":1,"args":["clang","-fno-spell-checking","{{.*}}record-completion-invocation.c","-Xclang","-detailed-preprocessing-record","-fallow-editor-placeholders"],"invocation-args":["-code-completion-at={{.*}}record-completion-invocation.c:10:1"],"unsaved_file_hashes":[{"name":"{{.*}}record-completion-invocation.c","md5":"aee23773de90e665992b48209351d70e"}]}
+// CHECK: 
{"toolchain":"{{.*}}","libclang.operation":"complete","libclang.opts":1,"args":["{{.*}}clang","-fno-spell-checking","{{.*}}record-completion-invocation.c","-Xclang","-detailed-preprocessing-record","-fallow-editor-placeholders"],"invocation-args":["-code-completion-at={{.*}}record-completion-invocation.c:10:1"],"unsaved_file_hashes":[{"name":"{{.*}}record-completion-invocation.c","md5":"aee23773de90e665992b48209351d70e"}]}


Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -3543,12 +3543,18 @@
 const char *const *command_line_args, int num_command_line_args,
 struct CXUnsavedFile *unsaved_files, unsigned num_unsaved_files,
 unsigned options, CXTranslationUnit *out_TU) {
+  llvm::SmallString<128> MockClangPath;
+  llvm::sys::path::append(
+  MockClangPath, static_cast(CIdx)->getClangToolchainPath(),
+  "bin", "clang");
+
   SmallVector Args;
-  Args.push_back("clang");
+  Args.push_back(MockClangPath.c_str());
   Args.append(command_line_args, command_line_args + num_command_line_args);

[clang-tools-extra] r352857 - [clangd] Unbreak fuzzer target

2019-02-01 Thread Sam McCall via cfe-commits
Author: sammccall
Date: Fri Feb  1 03:09:06 2019
New Revision: 352857

URL: http://llvm.org/viewvc/llvm-project?rev=352857&view=rev
Log:
[clangd] Unbreak fuzzer target

Modified:
clang-tools-extra/trunk/clangd/fuzzer/ClangdFuzzer.cpp

Modified: clang-tools-extra/trunk/clangd/fuzzer/ClangdFuzzer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/fuzzer/ClangdFuzzer.cpp?rev=352857&r1=352856&r2=352857&view=diff
==
--- clang-tools-extra/trunk/clangd/fuzzer/ClangdFuzzer.cpp (original)
+++ clang-tools-extra/trunk/clangd/fuzzer/ClangdFuzzer.cpp Fri Feb  1 03:09:06 
2019
@@ -15,6 +15,7 @@
 #include "ClangdLSPServer.h"
 #include "ClangdServer.h"
 #include "CodeComplete.h"
+#include "FSProvider.h"
 #include 
 #include 
 
@@ -29,12 +30,13 @@ extern "C" int LLVMFuzzerTestOneInput(ui
   auto Transport = newJSONTransport(In, llvm::nulls(),
 /*InMirror=*/nullptr, /*Pretty=*/false,
 /*Style=*/JSONStreamStyle::Standard);
+  RealFileSystemProvider FS;
   CodeCompleteOptions CCOpts;
   CCOpts.EnableSnippets = false;
   ClangdServer::Options Opts;
 
   // Initialize and run ClangdLSPServer.
-  ClangdLSPServer LSPServer(*Transport, CCOpts, llvm::None, false, Opts);
+  ClangdLSPServer LSPServer(*Transport, FS, CCOpts, llvm::None, false, Opts);
   LSPServer.run();
   return 0;
 }


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


[PATCH] D57532: [Index] Make sure c-index-test finds libc++ on Mac

2019-02-01 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added a comment.

@arphaman, thanks for pointing this out. It's definitely nice to change stuff 
only in one place.
There are two issues still pending:

- `index-file.cu` still fails, I haven't looked into it closely yet, any idea 
why that might be happening?; repro is simple, just patch this in locally and 
run the test.
- I'm not sure it's safe to use temporary storage for `argv[0]` in 
`clang_parseTranslationUnit2`. The resulting translation units probably holds 
references to `argv` and is free to read the data later. A simple and safe 
alternative would be to store this string in `CIndexer` and return a reference 
here. Does that LG?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57532



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


Re: r352156 - [AArch64] Make the test for rsr and rsr64 stricter

2019-02-01 Thread Hans Wennborg via cfe-commits
Merged to 8.0 in r352859.

On Fri, Jan 25, 2019 at 3:42 AM Petr Hosek via cfe-commits
 wrote:
>
> Author: phosek
> Date: Thu Jan 24 18:42:30 2019
> New Revision: 352156
>
> URL: http://llvm.org/viewvc/llvm-project?rev=352156&view=rev
> Log:
> [AArch64] Make the test for rsr and rsr64 stricter
>
> ACLE specifies that return type for rsr and rsr64 is uint32_t and
> uint64_t respectively. D56852 change the return type of rsr64 from
> unsigned long to unsigned long long which at least on Linux doesn't
> match uint64_t, but the test isn't strict enough to detect that
> because compiler implicitly converts unsigned long long to uint64_t,
> but it breaks other uses such as printf with PRIx64 type specifier.
> This change makes the test stricter enforcing that the return type
> of rsr and rsr64 builtins is what is actually specified in ACLE.
>
> Differential Revision: https://reviews.llvm.org/D57210
>
> Modified:
> cfe/trunk/test/CodeGen/builtins-arm64.c
>
> Modified: cfe/trunk/test/CodeGen/builtins-arm64.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtins-arm64.c?rev=352156&r1=352155&r2=352156&view=diff
> ==
> --- cfe/trunk/test/CodeGen/builtins-arm64.c (original)
> +++ cfe/trunk/test/CodeGen/builtins-arm64.c Thu Jan 24 18:42:30 2019
> @@ -1,4 +1,5 @@
>  // RUN: %clang_cc1 -triple arm64-unknown-linux -disable-O0-optnone 
> -emit-llvm -o - %s | opt -S -mem2reg | FileCheck %s
> +#include 
>
>  void f0(void *a, void *b) {
> __clear_cache(a,b);
> @@ -49,13 +50,17 @@ void prefetch() {
>  // CHECK: call {{.*}} @llvm.prefetch(i8* null, i32 0, i32 3, i32 0)
>  }
>
> -unsigned rsr() {
> +__typeof__(__builtin_arm_rsr("1:2:3:4:5")) rsr(void);
> +
> +uint32_t rsr() {
>// CHECK: [[V0:[%A-Za-z0-9.]+]] = call i64 
> @llvm.read_register.i64(metadata ![[M0:[0-9]]])
>// CHECK-NEXT: trunc i64 [[V0]] to i32
>return __builtin_arm_rsr("1:2:3:4:5");
>  }
>
> -unsigned long rsr64() {
> +__typeof__(__builtin_arm_rsr64("1:2:3:4:5")) rsr64(void);
> +
> +uint64_t rsr64() {
>// CHECK: call i64 @llvm.read_register.i64(metadata ![[M0:[0-9]]])
>return __builtin_arm_rsr64("1:2:3:4:5");
>  }
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r352463 - [AArch64] Update int64_t ACLE builtin arguments

2019-02-01 Thread Hans Wennborg via cfe-commits
Merged to 8.0 in r352860.

On Tue, Jan 29, 2019 at 10:03 AM Sam Parker via cfe-commits
 wrote:
>
> Author: sam_parker
> Date: Tue Jan 29 01:04:03 2019
> New Revision: 352463
>
> URL: http://llvm.org/viewvc/llvm-project?rev=352463&view=rev
> Log:
> [AArch64] Update int64_t ACLE builtin arguments
>
> Re-applying r351740 with fixes (changing LL to W).
>
> Differential Revision: https://reviews.llvm.org/D56852
>
> Modified:
> cfe/trunk/include/clang/Basic/BuiltinsAArch64.def
> cfe/trunk/test/CodeGen/arm64-crc32.c
> cfe/trunk/test/CodeGen/builtins-arm64.c
>
> Modified: cfe/trunk/include/clang/Basic/BuiltinsAArch64.def
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsAArch64.def?rev=352463&r1=352462&r2=352463&view=diff
> ==
> --- cfe/trunk/include/clang/Basic/BuiltinsAArch64.def (original)
> +++ cfe/trunk/include/clang/Basic/BuiltinsAArch64.def Tue Jan 29 01:04:03 2019
> @@ -32,7 +32,7 @@ BUILTIN(__builtin_arm_clrex, "v", "")
>
>  // Bit manipulation
>  BUILTIN(__builtin_arm_rbit, "UiUi", "nc")
> -BUILTIN(__builtin_arm_rbit64, "LUiLUi", "nc")
> +BUILTIN(__builtin_arm_rbit64, "WUiWUi", "nc")
>
>  // HINT
>  BUILTIN(__builtin_arm_nop, "v", "")
> @@ -49,8 +49,8 @@ BUILTIN(__builtin_arm_crc32h, "UiUiUs",
>  BUILTIN(__builtin_arm_crc32ch, "UiUiUs", "nc")
>  BUILTIN(__builtin_arm_crc32w, "UiUiUi", "nc")
>  BUILTIN(__builtin_arm_crc32cw, "UiUiUi", "nc")
> -BUILTIN(__builtin_arm_crc32d, "UiUiLUi", "nc")
> -BUILTIN(__builtin_arm_crc32cd, "UiUiLUi", "nc")
> +BUILTIN(__builtin_arm_crc32d, "UiUiWUi", "nc")
> +BUILTIN(__builtin_arm_crc32cd, "UiUiWUi", "nc")
>
>  // Memory barrier
>  BUILTIN(__builtin_arm_dmb, "vUi", "nc")
> @@ -62,10 +62,10 @@ BUILTIN(__builtin_arm_prefetch, "vvC*UiU
>
>  // System Registers
>  BUILTIN(__builtin_arm_rsr, "UicC*", "nc")
> -BUILTIN(__builtin_arm_rsr64, "LUicC*", "nc")
> +BUILTIN(__builtin_arm_rsr64, "WUicC*", "nc")
>  BUILTIN(__builtin_arm_rsrp, "v*cC*", "nc")
>  BUILTIN(__builtin_arm_wsr, "vcC*Ui", "nc")
> -BUILTIN(__builtin_arm_wsr64, "vcC*LUi", "nc")
> +BUILTIN(__builtin_arm_wsr64, "vcC*WUi", "nc")
>  BUILTIN(__builtin_arm_wsrp, "vcC*vC*", "nc")
>
>  // MSVC
>
> Modified: cfe/trunk/test/CodeGen/arm64-crc32.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm64-crc32.c?rev=352463&r1=352462&r2=352463&view=diff
> ==
> --- cfe/trunk/test/CodeGen/arm64-crc32.c (original)
> +++ cfe/trunk/test/CodeGen/arm64-crc32.c Tue Jan 29 01:04:03 2019
> @@ -1,54 +1,57 @@
>  // REQUIRES: aarch64-registered-target
>  // RUN: %clang_cc1 -triple arm64-none-linux-gnu \
>  // RUN:  -disable-O0-optnone -S -emit-llvm -o - %s | opt -S -mem2reg | 
> FileCheck %s
> +// RUN: %clang_cc1 -triple aarch64-windows \
> +// RUN:  -disable-O0-optnone -S -emit-llvm -o - %s | opt -S -mem2reg | 
> FileCheck %s
> +#include 
>
> -int crc32b(int a, char b)
> +uint32_t crc32b(uint32_t a, uint8_t b)
>  {
>  return __builtin_arm_crc32b(a,b);
>  // CHECK: [[T0:%[0-9]+]] = zext i8 %b to i32
>  // CHECK: call i32 @llvm.aarch64.crc32b(i32 %a, i32 [[T0]])
>  }
>
> -int crc32cb(int a, char b)
> +uint32_t crc32cb(uint32_t a, uint8_t b)
>  {
>  return __builtin_arm_crc32cb(a,b);
>  // CHECK: [[T0:%[0-9]+]] = zext i8 %b to i32
>  // CHECK: call i32 @llvm.aarch64.crc32cb(i32 %a, i32 [[T0]])
>  }
>
> -int crc32h(int a, short b)
> +uint32_t crc32h(uint32_t a, uint16_t b)
>  {
>  return __builtin_arm_crc32h(a,b);
>  // CHECK: [[T0:%[0-9]+]] = zext i16 %b to i32
>  // CHECK: call i32 @llvm.aarch64.crc32h(i32 %a, i32 [[T0]])
>  }
>
> -int crc32ch(int a, short b)
> +uint32_t crc32ch(uint32_t a, uint16_t b)
>  {
>  return __builtin_arm_crc32ch(a,b);
>  // CHECK: [[T0:%[0-9]+]] = zext i16 %b to i32
>  // CHECK: call i32 @llvm.aarch64.crc32ch(i32 %a, i32 [[T0]])
>  }
>
> -int crc32w(int a, int b)
> +uint32_t crc32w(uint32_t a, uint32_t b)
>  {
>  return __builtin_arm_crc32w(a,b);
>  // CHECK: call i32 @llvm.aarch64.crc32w(i32 %a, i32 %b)
>  }
>
> -int crc32cw(int a, int b)
> +uint32_t crc32cw(uint32_t a, uint32_t b)
>  {
>  return __builtin_arm_crc32cw(a,b);
>  // CHECK: call i32 @llvm.aarch64.crc32cw(i32 %a, i32 %b)
>  }
>
> -int crc32d(int a, long b)
> +uint32_t crc32d(uint32_t a, uint64_t b)
>  {
>  return __builtin_arm_crc32d(a,b);
>  // CHECK: call i32 @llvm.aarch64.crc32x(i32 %a, i64 %b)
>  }
>
> -int crc32cd(int a, long b)
> +uint32_t crc32cd(uint32_t a, uint64_t b)
>  {
>  return __builtin_arm_crc32cd(a,b);
>  // CHECK: call i32 @llvm.aarch64.crc32cx(i32 %a, i64 %b)
>
> Modified: cfe/trunk/test/CodeGen/builtins-arm64.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtins-arm64.c?rev=352463&r1=352462&r2=352463&view=diff
> ==
> --- cfe/trunk/test/CodeGen/builtins-arm64.c 

Re: r351740 - [AArch64] Use LL for 64-bit intrinsic arguments

2019-02-01 Thread Hans Wennborg via cfe-commits
Merged in r352860.

On Tue, Jan 29, 2019 at 2:48 PM Hans Wennborg  wrote:
>
> Thanks! I'll merge it after it's been in trunk for a little. Please
> let me know if there are any issues or follow-up commits.
>
> Cheers,
> Hans
>
> On Tue, Jan 29, 2019 at 4:04 AM Sam Parker  wrote:
> >
> > Hi Hans,
> >
> >
> > I've recommitted the change in r352463.
> >
> >
> > cheers,
> >
> > Sam
> >
> >
> > Sam Parker
> >
> > Compilation Tools Engineer | Arm
> >
> > . . . . . . . . . . . . . . . . . . . . . . . . . . .
> >
> > Arm.com
> >
> > 
> > From: Hans Wennborg 
> > Sent: 25 January 2019 18:26:48
> > To: Sam Parker
> > Cc: cfe-commits
> > Subject: Re: r351740 - [AArch64] Use LL for 64-bit intrinsic arguments
> >
> > I see this was reverted later, but please keep me posted on the
> > resolution as I think we might want to merge this to the 8.0 release
> > branch as well.
> >
> > Thanks,
> > Hans
> >
> > On Mon, Jan 21, 2019 at 3:01 AM Sam Parker via cfe-commits
> >  wrote:
> > >
> > > Author: sam_parker
> > > Date: Mon Jan 21 03:01:05 2019
> > > New Revision: 351740
> > >
> > > URL: http://llvm.org/viewvc/llvm-project?rev=351740&view=rev
> > > Log:
> > > [AArch64] Use LL for 64-bit intrinsic arguments
> > >
> > > The ACLE states that 64-bit crc32, wsr, rsr and rbit operands are
> > > uint64_t so we should have the clang builtin match this description
> > > - which is what we already do for AArch32.
> > >
> > > Differential Revision: https://reviews.llvm.org/D56852
> > >
> > > Modified:
> > > cfe/trunk/include/clang/Basic/BuiltinsAArch64.def
> > > cfe/trunk/test/CodeGen/arm64-crc32.c
> > > cfe/trunk/test/CodeGen/builtins-arm64.c
> > >
> > > Modified: cfe/trunk/include/clang/Basic/BuiltinsAArch64.def
> > > URL: 
> > > http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsAArch64.def?rev=351740&r1=351739&r2=351740&view=diff
> > > ==
> > > --- cfe/trunk/include/clang/Basic/BuiltinsAArch64.def (original)
> > > +++ cfe/trunk/include/clang/Basic/BuiltinsAArch64.def Mon Jan 21 03:01:05 
> > > 2019
> > > @@ -32,7 +32,7 @@ BUILTIN(__builtin_arm_clrex, "v", "")
> > >
> > >  // Bit manipulation
> > >  BUILTIN(__builtin_arm_rbit, "UiUi", "nc")
> > > -BUILTIN(__builtin_arm_rbit64, "LUiLUi", "nc")
> > > +BUILTIN(__builtin_arm_rbit64, "LLUiLLUi", "nc")
> > >
> > >  // HINT
> > >  BUILTIN(__builtin_arm_nop, "v", "")
> > > @@ -49,8 +49,8 @@ BUILTIN(__builtin_arm_crc32h, "UiUiUs",
> > >  BUILTIN(__builtin_arm_crc32ch, "UiUiUs", "nc")
> > >  BUILTIN(__builtin_arm_crc32w, "UiUiUi", "nc")
> > >  BUILTIN(__builtin_arm_crc32cw, "UiUiUi", "nc")
> > > -BUILTIN(__builtin_arm_crc32d, "UiUiLUi", "nc")
> > > -BUILTIN(__builtin_arm_crc32cd, "UiUiLUi", "nc")
> > > +BUILTIN(__builtin_arm_crc32d, "UiUiLLUi", "nc")
> > > +BUILTIN(__builtin_arm_crc32cd, "UiUiLLUi", "nc")
> > >
> > >  // Memory barrier
> > >  BUILTIN(__builtin_arm_dmb, "vUi", "nc")
> > > @@ -62,10 +62,10 @@ BUILTIN(__builtin_arm_prefetch, "vvC*UiU
> > >
> > >  // System Registers
> > >  BUILTIN(__builtin_arm_rsr, "UicC*", "nc")
> > > -BUILTIN(__builtin_arm_rsr64, "LUicC*", "nc")
> > > +BUILTIN(__builtin_arm_rsr64, "LLUicC*", "nc")
> > >  BUILTIN(__builtin_arm_rsrp, "v*cC*", "nc")
> > >  BUILTIN(__builtin_arm_wsr, "vcC*Ui", "nc")
> > > -BUILTIN(__builtin_arm_wsr64, "vcC*LUi", "nc")
> > > +BUILTIN(__builtin_arm_wsr64, "vcC*LLUi", "nc")
> > >  BUILTIN(__builtin_arm_wsrp, "vcC*vC*", "nc")
> > >
> > >  // MSVC
> > >
> > > Modified: cfe/trunk/test/CodeGen/arm64-crc32.c
> > > URL: 
> > > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm64-crc32.c?rev=351740&r1=351739&r2=351740&view=diff
> > > ==
> > > --- cfe/trunk/test/CodeGen/arm64-crc32.c (original)
> > > +++ cfe/trunk/test/CodeGen/arm64-crc32.c Mon Jan 21 03:01:05 2019
> > > @@ -1,54 +1,57 @@
> > >  // REQUIRES: aarch64-registered-target
> > >  // RUN: %clang_cc1 -triple arm64-none-linux-gnu \
> > >  // RUN:  -disable-O0-optnone -S -emit-llvm -o - %s | opt -S -mem2reg | 
> > > FileCheck %s
> > > +// RUN: %clang_cc1 -triple aarch64-windows \
> > > +// RUN:  -disable-O0-optnone -S -emit-llvm -o - %s | opt -S -mem2reg | 
> > > FileCheck %s
> > > +#include 
> > >
> > > -int crc32b(int a, char b)
> > > +uint32_t crc32b(uint32_t a, uint8_t b)
> > >  {
> > >  return __builtin_arm_crc32b(a,b);
> > >  // CHECK: [[T0:%[0-9]+]] = zext i8 %b to i32
> > >  // CHECK: call i32 @llvm.aarch64.crc32b(i32 %a, i32 [[T0]])
> > >  }
> > >
> > > -int crc32cb(int a, char b)
> > > +uint32_t crc32cb(uint32_t a, uint8_t b)
> > >  {
> > >  return __builtin_arm_crc32cb(a,b);
> > >  // CHECK: [[T0:%[0-9]+]] = zext i8 %b to i32
> > >  // CHECK: call i32 @llvm.aarch64.crc32cb(i32 %a, i32 [[T0]])
> > >  }
> > >
> > > -int crc32h(int a, short b)
> > > +uint32_t crc32h(uint32_t a, uint16_t b)
> > >  {
> > >  return __builtin_ar

[PATCH] D57573: Disable tidy checks with too many hits

2019-02-01 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov updated this revision to Diff 184714.
ilya-biryukov marked an inline comment as done.
ilya-biryukov added a comment.

- Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57573

Files:
  .clang-tidy
  clang/.clang-tidy
  llvm/.clang-tidy


Index: llvm/.clang-tidy
===
--- llvm/.clang-tidy
+++ llvm/.clang-tidy
@@ -1,4 +1,4 @@
-Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,readability-identifier-naming'
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase
Index: clang/.clang-tidy
===
--- clang/.clang-tidy
+++ clang/.clang-tidy
@@ -1,4 +1,9 @@
-Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-readability-identifier-naming'
+# Note that the readability-identifier-naming check is disabled, there are too
+# many violations in the codebase and they create too much noise in clang-tidy
+# results.
+# Naming settings are kept for documentation purposes and allowing to run the
+# check if the users would override this file, e.g. via a command-line arg.
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase
Index: .clang-tidy
===
--- .clang-tidy
+++ .clang-tidy
@@ -1,4 +1,4 @@
-Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,readability-identifier-naming'
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase


Index: llvm/.clang-tidy
===
--- llvm/.clang-tidy
+++ llvm/.clang-tidy
@@ -1,4 +1,4 @@
-Checks: '-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: '-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,readability-identifier-naming'
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase
Index: clang/.clang-tidy
===
--- clang/.clang-tidy
+++ clang/.clang-tidy
@@ -1,4 +1,9 @@
-Checks: '-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: '-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-readability-identifier-naming'
+# Note that the readability-identifier-naming check is disabled, there are too
+# many violations in the codebase and they create too much noise in clang-tidy
+# results.
+# Naming settings are kept for documentation purposes and allowing to run the
+# check if the users would override this file, e.g. via a command-line arg.
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase
Index: .clang-tidy
===
--- .clang-tidy
+++ .clang-tidy
@@ -1,4 +1,4 @@
-Checks: '-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: '-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,readability-identifier-naming'
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57573: Disable tidy checks with too many hits

2019-02-01 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC352862: Disable tidy checks with too many hits (authored by 
ibiryukov, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D57573?vs=184714&id=184715#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D57573

Files:
  .clang-tidy


Index: .clang-tidy
===
--- .clang-tidy
+++ .clang-tidy
@@ -1,4 +1,9 @@
-Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-readability-identifier-naming'
+# Note that the readability-identifier-naming check is disabled, there are too
+# many violations in the codebase and they create too much noise in clang-tidy
+# results.
+# Naming settings are kept for documentation purposes and allowing to run the
+# check if the users would override this file, e.g. via a command-line arg.
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase


Index: .clang-tidy
===
--- .clang-tidy
+++ .clang-tidy
@@ -1,4 +1,9 @@
-Checks: '-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: '-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-readability-identifier-naming'
+# Note that the readability-identifier-naming check is disabled, there are too
+# many violations in the codebase and they create too much noise in clang-tidy
+# results.
+# Naming settings are kept for documentation purposes and allowing to run the
+# check if the users would override this file, e.g. via a command-line arg.
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r352862 - Disable tidy checks with too many hits

2019-02-01 Thread Ilya Biryukov via cfe-commits
Author: ibiryukov
Date: Fri Feb  1 03:20:13 2019
New Revision: 352862

URL: http://llvm.org/viewvc/llvm-project?rev=352862&view=rev
Log:
Disable tidy checks with too many hits

Summary:
Some tidy checks have too many hits in the codebase, making it hard to spot
other results from clang-tidy, therefore rendering the tool less useful.

Two checks were disabled:
  - misc-non-private-member-variable-in-classes in the whole LLVM monorepo,
it is very common to have those in LLVM and the style guide does not forbid
them.
  - readability-identifier-naming in the clang subtree. There are thousands of
violations in 'Sema.h' alone.

Before the change, 'Sema.h' had >1000 tidy warnings, after the change the number
dropped to 3 warnings (unterminated namespace comments).

Reviewers: alexfh, hokein

Reviewed By: hokein

Subscribers: llvm-commits, cfe-commits

Tags: #clang, #llvm

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

Modified:
cfe/trunk/.clang-tidy

Modified: cfe/trunk/.clang-tidy
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/.clang-tidy?rev=352862&r1=352861&r2=352862&view=diff
==
--- cfe/trunk/.clang-tidy (original)
+++ cfe/trunk/.clang-tidy Fri Feb  1 03:20:13 2019
@@ -1,4 +1,9 @@
-Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming'
+Checks: 
'-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-readability-identifier-naming'
+# Note that the readability-identifier-naming check is disabled, there are too
+# many violations in the codebase and they create too much noise in clang-tidy
+# results.
+# Naming settings are kept for documentation purposes and allowing to run the
+# check if the users would override this file, e.g. via a command-line arg.
 CheckOptions:
   - key: readability-identifier-naming.ClassCase
 value:   CamelCase


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


[PATCH] D57577: Make predefined FLT16 macros conditional on support for the type

2019-02-01 Thread Nemanja Ivanovic via Phabricator via cfe-commits
nemanjai created this revision.
nemanjai added reviewers: rogfer01, bruno, ahatanak, scanon.
Herald added subscribers: aheejin, jgravelle-google, sbc100, dschuff.
Herald added a project: clang.

We unconditionally predefine these macros. However, they may be used to 
determine if the type is supported. In that case, there are unnecessary 
failures to compile the code.
This is the proposed fix for https://bugs.llvm.org/show_bug.cgi?id=40559


Repository:
  rC Clang

https://reviews.llvm.org/D57577

Files:
  lib/Basic/Targets/WebAssembly.h
  lib/Frontend/InitPreprocessor.cpp
  test/Headers/float16.c


Index: test/Headers/float16.c
===
--- test/Headers/float16.c
+++ test/Headers/float16.c
@@ -1,7 +1,11 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c89 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c99 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c11 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 -x c++ -ffreestanding %s
+// RUN: %clang_cc1 -triple=aarch64-none-none -fsyntax-only -verify -std=c89 \
+// RUN:   -ffreestanding %s
+// RUN: %clang_cc1 -triple=wasm64-unknown-unknown -fsyntax-only -verify \
+// RUN:   -std=c99 -ffreestanding %s
+// RUN: %clang_cc1 -triple=aarch64-none-none -fsyntax-only -verify -std=c11 \
+// RUN:   -ffreestanding %s
+// RUN: %clang_cc1 -triple=wasm64-unknown-unknown -fsyntax-only -verify \
+// RUN:   -std=c++11 -x c++ -ffreestanding %s
 // expected-no-diagnostics
 
 #define __STDC_WANT_IEC_60559_TYPES_EXT__
Index: lib/Frontend/InitPreprocessor.cpp
===
--- lib/Frontend/InitPreprocessor.cpp
+++ lib/Frontend/InitPreprocessor.cpp
@@ -830,7 +830,8 @@
   DefineFmt("__UINTPTR", TI.getUIntPtrType(), TI, Builder);
   DefineTypeWidth("__UINTPTR_WIDTH__", TI.getUIntPtrType(), TI, Builder);
 
-  DefineFloatMacros(Builder, "FLT16", &TI.getHalfFormat(), "F16");
+  if (TI.hasFloat16Type())
+DefineFloatMacros(Builder, "FLT16", &TI.getHalfFormat(), "F16");
   DefineFloatMacros(Builder, "FLT", &TI.getFloatFormat(), "F");
   DefineFloatMacros(Builder, "DBL", &TI.getDoubleFormat(), "");
   DefineFloatMacros(Builder, "LDBL", &TI.getLongDoubleFormat(), "L");
Index: lib/Basic/Targets/WebAssembly.h
===
--- lib/Basic/Targets/WebAssembly.h
+++ lib/Basic/Targets/WebAssembly.h
@@ -52,6 +52,7 @@
 SizeType = UnsignedLong;
 PtrDiffType = SignedLong;
 IntPtrType = SignedLong;
+HasFloat16 = true;
   }
 
 protected:


Index: test/Headers/float16.c
===
--- test/Headers/float16.c
+++ test/Headers/float16.c
@@ -1,7 +1,11 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c89 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c99 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c11 -ffreestanding %s
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 -x c++ -ffreestanding %s
+// RUN: %clang_cc1 -triple=aarch64-none-none -fsyntax-only -verify -std=c89 \
+// RUN:   -ffreestanding %s
+// RUN: %clang_cc1 -triple=wasm64-unknown-unknown -fsyntax-only -verify \
+// RUN:   -std=c99 -ffreestanding %s
+// RUN: %clang_cc1 -triple=aarch64-none-none -fsyntax-only -verify -std=c11 \
+// RUN:   -ffreestanding %s
+// RUN: %clang_cc1 -triple=wasm64-unknown-unknown -fsyntax-only -verify \
+// RUN:   -std=c++11 -x c++ -ffreestanding %s
 // expected-no-diagnostics
 
 #define __STDC_WANT_IEC_60559_TYPES_EXT__
Index: lib/Frontend/InitPreprocessor.cpp
===
--- lib/Frontend/InitPreprocessor.cpp
+++ lib/Frontend/InitPreprocessor.cpp
@@ -830,7 +830,8 @@
   DefineFmt("__UINTPTR", TI.getUIntPtrType(), TI, Builder);
   DefineTypeWidth("__UINTPTR_WIDTH__", TI.getUIntPtrType(), TI, Builder);
 
-  DefineFloatMacros(Builder, "FLT16", &TI.getHalfFormat(), "F16");
+  if (TI.hasFloat16Type())
+DefineFloatMacros(Builder, "FLT16", &TI.getHalfFormat(), "F16");
   DefineFloatMacros(Builder, "FLT", &TI.getFloatFormat(), "F");
   DefineFloatMacros(Builder, "DBL", &TI.getDoubleFormat(), "");
   DefineFloatMacros(Builder, "LDBL", &TI.getLongDoubleFormat(), "L");
Index: lib/Basic/Targets/WebAssembly.h
===
--- lib/Basic/Targets/WebAssembly.h
+++ lib/Basic/Targets/WebAssembly.h
@@ -52,6 +52,7 @@
 SizeType = UnsignedLong;
 PtrDiffType = SignedLong;
 IntPtrType = SignedLong;
+HasFloat16 = true;
   }
 
 protected:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57524: Fix ICE on attempt to add an addr space qual to a type qualified by an addr space

2019-02-01 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia marked an inline comment as done.
Anastasia added inline comments.



Comment at: lib/Sema/SemaInit.cpp:4693
+T2Quals.addAddressSpace(AS2);
+  QualType WithAScv1T4 = S.Context.getQualifiedType(IgnoreAScv2T2, 
T1Quals);
+  Sequence.AddQualificationConversionStep(WithAScv1T4, ValueKind);

rjmccall wrote:
> `Qualifiers::addQualifiers` should let you do this in a single step.  Also, 
> you seem to be modifying `T2Quals` here after the last use of it.
Ok, I will update to use Qualifies methods directly.

As for `T2Quals` I was thinking it might make sense to restore the original 
value in case some code later will be added to use it (to prevent bugs)... but 
may be it's too hypothetical. :)

Thanks!


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

https://reviews.llvm.org/D57524



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


[PATCH] D57577: Make predefined FLT16 macros conditional on support for the type

2019-02-01 Thread Nemanja Ivanovic via Phabricator via cfe-commits
nemanjai marked an inline comment as done.
nemanjai added inline comments.



Comment at: lib/Basic/Targets/WebAssembly.h:55
 IntPtrType = SignedLong;
+HasFloat16 = true;
   }

There are test cases that check for the macros for WebAssembly so I assumed 
they probably want the type to be valid on the target. If that's not the case, 
I can change the test case.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57577



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


[clang-tools-extra] r352863 - [clangd] Use delimited style to make life easier for the fuzzer

2019-02-01 Thread Sam McCall via cfe-commits
Author: sammccall
Date: Fri Feb  1 03:20:20 2019
New Revision: 352863

URL: http://llvm.org/viewvc/llvm-project?rev=352863&view=rev
Log:
[clangd] Use delimited style to make life easier for the fuzzer

Modified:
clang-tools-extra/trunk/clangd/fuzzer/ClangdFuzzer.cpp

Modified: clang-tools-extra/trunk/clangd/fuzzer/ClangdFuzzer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/fuzzer/ClangdFuzzer.cpp?rev=352863&r1=352862&r2=352863&view=diff
==
--- clang-tools-extra/trunk/clangd/fuzzer/ClangdFuzzer.cpp (original)
+++ clang-tools-extra/trunk/clangd/fuzzer/ClangdFuzzer.cpp Fri Feb  1 03:20:20 
2019
@@ -29,7 +29,7 @@ extern "C" int LLVMFuzzerTestOneInput(ui
   std::FILE *In = fmemopen(data, size, "r");
   auto Transport = newJSONTransport(In, llvm::nulls(),
 /*InMirror=*/nullptr, /*Pretty=*/false,
-/*Style=*/JSONStreamStyle::Standard);
+/*Style=*/JSONStreamStyle::Delimited);
   RealFileSystemProvider FS;
   CodeCompleteOptions CCOpts;
   CCOpts.EnableSnippets = false;


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


[clang-tools-extra] r352864 - [clangd] Implement textDocument/declaration from LSP 3.14

2019-02-01 Thread Sam McCall via cfe-commits
Author: sammccall
Date: Fri Feb  1 03:26:13 2019
New Revision: 352864

URL: http://llvm.org/viewvc/llvm-project?rev=352864&view=rev
Log:
[clangd] Implement textDocument/declaration from LSP 3.14

Summary:
LSP now reflects the declaration/definition distinction.

Language server changes:
 - textDocument/definition now returns a definition if one is found, otherwise
   the declaration. It no longer returns declaration + definition if they are
   distinct.
 - textDocument/declaration returns the best declaration we can find.
 - For macros, the active macro definition is returned for both methods.
 - For include directive, the top of the target file is returned for both.
There doesn't appear to be a discovery mechanism (we can't return everything to
clients that only know about definition), so this changes existing behavior.
In practice, it should greatly reduce the fraction of the time we need to show
the user a menu of options.

C++ API changes:
 - findDefinitions is replaced by locateSymbolAt, which returns a
   vector - one for each symbol under the cursor.
 - this contains the preferred declaration, the definition (if found), and
   the symbol name
This API enables some potentially-neat extensions, like swapping between decl
and def, and exposing the symbol name to the UI in the case of multiple symbols.

Reviewers: hokein

Subscribers: ilya-biryukov, javed.absar, ioeric, MaskRay, jkorous, arphaman, 
kadircet, cfe-commits

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

Modified:
clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
clang-tools-extra/trunk/clangd/ClangdLSPServer.h
clang-tools-extra/trunk/clangd/ClangdServer.cpp
clang-tools-extra/trunk/clangd/ClangdServer.h
clang-tools-extra/trunk/clangd/XRefs.cpp
clang-tools-extra/trunk/clangd/XRefs.h
clang-tools-extra/trunk/test/clangd/initialize-params.test
clang-tools-extra/trunk/unittests/clangd/ClangdTests.cpp
clang-tools-extra/trunk/unittests/clangd/SyncAPI.cpp
clang-tools-extra/trunk/unittests/clangd/SyncAPI.h
clang-tools-extra/trunk/unittests/clangd/TUSchedulerTests.cpp
clang-tools-extra/trunk/unittests/clangd/XRefsTests.cpp

Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp?rev=352864&r1=352863&r2=352864&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp Fri Feb  1 03:26:13 2019
@@ -354,6 +354,7 @@ void ClangdLSPServer::onInitialize(const
  llvm::json::Object{
  {"triggerCharacters", {"(", ","}},
  }},
+{"declarationProvider", true},
 {"definitionProvider", true},
 {"documentHighlightProvider", true},
 {"hoverProvider", true},
@@ -727,8 +728,37 @@ void ClangdLSPServer::onSignatureHelp(co
 
 void ClangdLSPServer::onGoToDefinition(const TextDocumentPositionParams 
&Params,
Callback> Reply) {
-  Server->findDefinitions(Params.textDocument.uri.file(), Params.position,
-  std::move(Reply));
+  Server->locateSymbolAt(
+  Params.textDocument.uri.file(), Params.position,
+  Bind(
+  [&](decltype(Reply) Reply,
+  llvm::Expected> Symbols) {
+if (!Symbols)
+  return Reply(Symbols.takeError());
+std::vector Defs;
+for (const auto &S : *Symbols)
+  Defs.push_back(S.Definition.getValueOr(S.PreferredDeclaration));
+Reply(std::move(Defs));
+  },
+  std::move(Reply)));
+}
+
+void ClangdLSPServer::onGoToDeclaration(
+const TextDocumentPositionParams &Params,
+Callback> Reply) {
+  Server->locateSymbolAt(
+  Params.textDocument.uri.file(), Params.position,
+  Bind(
+  [&](decltype(Reply) Reply,
+  llvm::Expected> Symbols) {
+if (!Symbols)
+  return Reply(Symbols.takeError());
+std::vector Decls;
+for (const auto &S : *Symbols)
+  Decls.push_back(S.PreferredDeclaration);
+Reply(std::move(Decls));
+  },
+  std::move(Reply)));
 }
 
 void ClangdLSPServer::onSwitchSourceHeader(const TextDocumentIdentifier 
&Params,
@@ -814,6 +844,7 @@ ClangdLSPServer::ClangdLSPServer(class T
   MsgHandler->bind("textDocument/completion", &ClangdLSPServer::onCompletion);
   MsgHandler->bind("textDocument/signatureHelp", 
&ClangdLSPServer::onSignatureHelp);
   MsgHandler->bind("textDocument/definition", 
&ClangdLSPServer::onGoToDefinition);
+  MsgHandler->bind("textDocument/declaration", 
&ClangdLSPServer::onGoToDeclaration);
   MsgHandler->bind("textDocument/references", &ClangdLSPServer::onReference);
   MsgHandler->bind("textDocument/switchSourceHeader", 
&ClangdLSPServer::onSwitchSourceHead

[PATCH] D57388: [clangd] Implement textDocument/declaration from LSP 3.14

2019-02-01 Thread Sam McCall via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rCTE352864: [clangd] Implement textDocument/declaration from 
LSP 3.14 (authored by sammccall, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D57388?vs=184710&id=184718#toc

Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D57388

Files:
  clangd/ClangdLSPServer.cpp
  clangd/ClangdLSPServer.h
  clangd/ClangdServer.cpp
  clangd/ClangdServer.h
  clangd/XRefs.cpp
  clangd/XRefs.h
  test/clangd/initialize-params.test
  unittests/clangd/ClangdTests.cpp
  unittests/clangd/SyncAPI.cpp
  unittests/clangd/SyncAPI.h
  unittests/clangd/TUSchedulerTests.cpp
  unittests/clangd/XRefsTests.cpp

Index: unittests/clangd/ClangdTests.cpp
===
--- unittests/clangd/ClangdTests.cpp
+++ unittests/clangd/ClangdTests.cpp
@@ -43,8 +43,9 @@
 using ::testing::Pair;
 using ::testing::UnorderedElementsAre;
 
-MATCHER_P2(FileRange, File, Range, "") {
-  return Location{URIForFile::canonicalize(File, testRoot()), Range} == arg;
+MATCHER_P2(DeclAt, File, Range, "") {
+  return arg.PreferredDeclaration ==
+ Location{URIForFile::canonicalize(File, testRoot()), Range};
 }
 
 bool diagsContainErrors(const std::vector &Diagnostics) {
@@ -458,10 +459,9 @@
   UnorderedElementsAre(Pair(FooCpp, false), Pair(BarCpp, true),
Pair(BazCpp, false)));
 
-  auto Locations = runFindDefinitions(Server, FooCpp, FooSource.point());
+  auto Locations = runLocateSymbolAt(Server, FooCpp, FooSource.point());
   EXPECT_TRUE(bool(Locations));
-  EXPECT_THAT(*Locations,
-  ElementsAre(FileRange(FooCpp, FooSource.range("one";
+  EXPECT_THAT(*Locations, ElementsAre(DeclAt(FooCpp, FooSource.range("one";
 
   // Undefine MACRO, close baz.cpp.
   CDB.ExtraClangFlags.clear();
@@ -474,10 +474,9 @@
   EXPECT_THAT(DiagConsumer.filesWithDiags(),
   UnorderedElementsAre(Pair(FooCpp, false), Pair(BarCpp, false)));
 
-  Locations = runFindDefinitions(Server, FooCpp, FooSource.point());
+  Locations = runLocateSymbolAt(Server, FooCpp, FooSource.point());
   EXPECT_TRUE(bool(Locations));
-  EXPECT_THAT(*Locations,
-  ElementsAre(FileRange(FooCpp, FooSource.range("two";
+  EXPECT_THAT(*Locations, ElementsAre(DeclAt(FooCpp, FooSource.range("two";
 }
 
 TEST_F(ClangdVFSTest, MemoryUsage) {
@@ -532,7 +531,7 @@
   runAddDocument(Server, FooCpp, "int main() {}");
 
   EXPECT_EQ(runDumpAST(Server, FooCpp), "");
-  EXPECT_ERROR(runFindDefinitions(Server, FooCpp, Position()));
+  EXPECT_ERROR(runLocateSymbolAt(Server, FooCpp, Position()));
   EXPECT_ERROR(runFindDocumentHighlights(Server, FooCpp, Position()));
   EXPECT_ERROR(runRename(Server, FooCpp, Position(), "new_name"));
   // FIXME: codeComplete and signatureHelp should also return errors when they
@@ -717,7 +716,7 @@
clangd::CodeCompleteOptions()));
 };
 
-auto FindDefinitionsRequest = [&]() {
+auto LocateSymbolRequest = [&]() {
   unsigned FileIndex = FileIndexDist(RandGen);
   // Make sure we don't violate the ClangdServer's contract.
   if (ReqStats[FileIndex].FileIsRemoved)
@@ -727,13 +726,13 @@
   Pos.line = LineDist(RandGen);
   Pos.character = ColumnDist(RandGen);
 
-  ASSERT_TRUE(!!runFindDefinitions(Server, FilePaths[FileIndex], Pos));
+  ASSERT_TRUE(!!runLocateSymbolAt(Server, FilePaths[FileIndex], Pos));
 };
 
 std::vector> AsyncRequests = {
 AddDocumentRequest, ForceReparseRequest, RemoveDocumentRequest};
 std::vector> BlockingRequests = {
-CodeCompletionRequest, FindDefinitionsRequest};
+CodeCompletionRequest, LocateSymbolRequest};
 
 // Bash requests to ClangdServer in a loop.
 std::uniform_int_distribution AsyncRequestIndexDist(
Index: unittests/clangd/SyncAPI.cpp
===
--- unittests/clangd/SyncAPI.cpp
+++ unittests/clangd/SyncAPI.cpp
@@ -84,10 +84,10 @@
   return std::move(*Result);
 }
 
-llvm::Expected>
-runFindDefinitions(ClangdServer &Server, PathRef File, Position Pos) {
-  llvm::Optional>> Result;
-  Server.findDefinitions(File, Pos, capture(Result));
+llvm::Expected>
+runLocateSymbolAt(ClangdServer &Server, PathRef File, Position Pos) {
+  llvm::Optional>> Result;
+  Server.locateSymbolAt(File, Pos, capture(Result));
   return std::move(*Result);
 }
 
Index: unittests/clangd/SyncAPI.h
===
--- unittests/clangd/SyncAPI.h
+++ unittests/clangd/SyncAPI.h
@@ -32,8 +32,8 @@
 llvm::Expected runSignatureHelp(ClangdServer &Server,
PathRef File, Position Pos);
 
-llvm::Expected>
-runFindDefinitions(ClangdServer &Server, PathRef File, Position Pos);
+llvm::Expected>
+runLocateSymb

r352865 - [CUDA] Relax lit test condition after r352798.

2019-02-01 Thread Eric Liu via cfe-commits
Author: ioeric
Date: Fri Feb  1 03:36:23 2019
New Revision: 352865

URL: http://llvm.org/viewvc/llvm-project?rev=352865&view=rev
Log:
[CUDA] Relax lit test condition after r352798.

Clang executable doesn't match clang.* in all test environment.

Modified:
cfe/trunk/test/Driver/cuda-detect.cu

Modified: cfe/trunk/test/Driver/cuda-detect.cu
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cuda-detect.cu?rev=352865&r1=352864&r2=352865&view=diff
==
--- cfe/trunk/test/Driver/cuda-detect.cu (original)
+++ cfe/trunk/test/Driver/cuda-detect.cu Fri Feb  1 03:36:23 2019
@@ -178,14 +178,14 @@
 // CHECK-CXXINCLUDE-SAME: {{.*}}"-internal-isystem" "{{.+}}/include/c++/4.8"
 // CHECK-CXXINCLUDE: ld{{.*}}"
 
-// CUDA80: clang{{.*}} "-cc1" "-triple" "nvptx64-nvidia-cuda"
+// CUDA80: "-cc1" "-triple" "nvptx64-nvidia-cuda"
 // CUDA80-SAME: -target-sdk-version=8.0
-// CUDA80: clang{{.*}} "-cc1" "-triple" "x86_64-unknown-linux-gnu"
+// CUDA80: "-cc1" "-triple" "x86_64-unknown-linux-gnu"
 // CUDA80-SAME: -target-sdk-version=8.0
 // CUDA80: ld{{.*}}"
 
-// CUDA70: clang{{.*}} "-cc1" "-triple" "nvptx64-nvidia-cuda"
+// CUDA70: "-cc1" "-triple" "nvptx64-nvidia-cuda"
 // CUDA70-SAME: -target-sdk-version=7.0
-// CUDA70: clang{{.*}} "-cc1" "-triple" "x86_64-unknown-linux-gnu"
+// CUDA70: "-cc1" "-triple" "x86_64-unknown-linux-gnu"
 // CUDA70-SAME: -target-sdk-version=7.0
 // CUDA70: ld{{.*}}"


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


[PATCH] D57571: [clang-tidy] A new OpenMP module

2019-02-01 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth accepted this revision.
JonasToth added a comment.
This revision is now accepted and ready to land.

LGTM. Committing both revision together would be good :)


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D57571



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


[PATCH] D57571: [clang-tidy] A new OpenMP module

2019-02-01 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In D57571#1380421 , @JonasToth wrote:

> LGTM.




In D57571#1380421 , @JonasToth wrote:

> Committing both revision together would be good :)


Yes.
I can't land them since D57112  has no review 
feedback as of yet.
Hopefully not for too long. Though i'm not sure when i can reasonably ping it,
updating the review probably counts as a ping, i think.

I have split it up so i can work on the second check, `openmp-exception-escape`.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D57571



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


[PATCH] D57464: Generalize method overloading on addr spaces to C++

2019-02-01 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia marked 2 inline comments as done.
Anastasia added inline comments.



Comment at: lib/Parse/ParseDeclCXX.cpp:2313
+}
+  }
 

ebevhan wrote:
> Anastasia wrote:
> > Anastasia wrote:
> > > ebevhan wrote:
> > > > Is there a reason that the attributes are parsed here and not in 
> > > > `ParseFunctionDeclarator` like the rest of the ref-qualifiers (and the 
> > > > OpenCL++ ASes)?
> > > > 
> > > > That is possibly why the parser is getting confused with the trailing 
> > > > return.
> > > Good question! I have a feeling that this was done to unify parsing of 
> > > all CXX members, not just methods. For collecting the method qualifiers 
> > > it would certainly help making flow more coherent if this was moved to 
> > > `ParseFunctionDeclarator`. I will try to experiment with this a bit more. 
> > > What I found strange that the attributes here are attached to the 
> > > function type itself instead of its  qualifiers. May be @rjmccall can 
> > > shed some more light on the overall flow...
> > I looked at this a bit more and it seems that all the GNU attributes other 
> > than addr spaces belong to the function (not to be applied to `this`) for 
> > example 
> > https://blog.timac.org/2016/0716-constructor-and-destructor-attributes/. It 
> > seems correct to parse them here and apply to the function type. Although 
> > we could separate parsing of addr space attribute only and move into 
> > `ParseFunctionDeclarator`.  However this will only be needed for the 
> > function type not for the data members. So not sure whether it will make 
> > the flow any cleaner.
> > I looked at this a bit more and it seems that all the GNU attributes other 
> > than addr spaces belong to the function (not to be applied to this) 
> 
> Hm, I know what you mean. It's why Clang usually complains when you try 
> placing an AS attribute after a function declarator, because it's trying to 
> apply it to the function rather than the method qualifiers.
> 
> > However this will only be needed for the function type not for the data 
> > members. 
> 
> But we aren't really interested in data members, are we? Like struct fields, 
> non-static data members cannot be qualified with ASes (they should 'inherit' 
> the AS from the object type), and static ones should probably just accept 
> ASes as part of the member type itself.
> 
> These patches are to enable AS-qualifiers on methods, so it only stands to 
> reason that those ASes would be parsed along with the other method qualifiers.
> 
> ParseFunctionDeclarator calls ParseTypeQualifierListOpt to get the 
> cv-qualifier-seq for the method qualifiers. Currently it's set to 
> `AR_NoAttributesParsed`. If we enable parsing attributes there, then the 
> qualifier parsing might 'eat' attributes that were possibly meant for the 
> function.
> 
> This is just a guess, but what I think you could do is include attributes in 
> the cv-qualifier parsing with `AR_GNUAttributesParsed`, look for any AS 
> attributes, take their AS and mark them invalid, then move the attributes 
> (somehow) from the qualifier-DeclSpec to the `FnAttrs` function attribute 
> list.
> 
> (The reason I'm concerned about where/how the qualifiers are parsed is 
> because this approach only works for custom ASes applied with the GNU 
> attribute directly. It won't work if custom address spaces are given with a 
> custom keyword qualifier, like in OpenCL. If the ASes are parsed into the 
> DeclSpec used for the other ref-qualifiers, then both of these cases should 
> 'just work'.)
> But we aren't really interested in data members, are we? Like struct fields, 
> non-static data members cannot be qualified with ASes (they should 'inherit' 
> the AS from the object type), and static ones should probably just accept 
> ASes as part of the member type itself.
 
Pointer data members can be qualified by and address space, but this should be 
parsed before.


> This is just a guess, but what I think you could do is include attributes in 
> the cv-qualifier parsing with AR_GNUAttributesParsed, look for any AS 
> attributes, take their AS and mark them invalid, then move the attributes 
> (somehow) from the qualifier-DeclSpec to the FnAttrs function attribute list.

Ok, I will try that. Thanks for sharing your ideas!




Comment at: test/SemaCXX/address-space-method-overloading.cpp:28
+   //inas4.bar();
+   noas.bar(); // expected-error{{call to member function 'bar' is ambiguous}}
+}

ebevhan wrote:
> Just as an aside (I think I mentioned this on one of the earlier patches as 
> well); treating a non-AS-qualified object as being in a 'generic' AS even for 
> normal C++ isn't a great idea IMO. The object initialization code should be 
> checking if the ASes of the actual object and the desired object type are 
> compatible, and only if so, permit the overload.
I think changing this would require changing AS compatibility rules in general, 
not just for overloading

[PATCH] D57521: [CMake] External compiler-rt-configure requires LLVMTestingSupport when including tests

2019-02-01 Thread Stefan Gränitz via Phabricator via cfe-commits
sgraenitz added a comment.

In D57521#1379837 , @beanz wrote:

> @phosek, does LLVM’s runtime directory do this correctly?
>
> At some point we should try and deprecate and remove this option in favor of 
> the LLVM directory because the LLVM approach is much more complete and robust.


My 2¢: ideally compiler-rt used imported targets. Please see my note added in 
D55891 .


Repository:
  rC Clang

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

https://reviews.llvm.org/D57521



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


[PATCH] D57521: [CMake] External compiler-rt-configure requires LLVMTestingSupport when including tests

2019-02-01 Thread Michał Górny via Phabricator via cfe-commits
mgorny added a comment.

Ideally we wouldn't introduce such a complex dependency for 2 test cases.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57521



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


[PATCH] D57236: [ASTImporter] Unify redecl chain tests as type parameterized tests

2019-02-01 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.
Herald added a project: clang.

Ping


Repository:
  rC Clang

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

https://reviews.llvm.org/D57236



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


r352842 - Test commit: fix typo

2019-02-01 Thread Sergi Mateo Bellido via cfe-commits
Author: smateo
Date: Fri Feb  1 00:39:01 2019
New Revision: 352842

URL: http://llvm.org/viewvc/llvm-project?rev=352842&view=rev
Log:
Test commit: fix typo

Modified:
cfe/trunk/lib/Sema/SemaOpenMP.cpp

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=352842&r1=352841&r2=352842&view=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Fri Feb  1 00:39:01 2019
@@ -4583,7 +4583,7 @@ Expr *OpenMPIterationSpaceChecker::build
   /*AllowExplicit=*/true);
   }
   SemaRef.getDiagnostics().setSuppressAllDiagnostics(Suppress);
-  // Otherwise use original loop conditon and evaluate it in runtime.
+  // Otherwise use original loop condition and evaluate it in runtime.
   return CondExpr.isUsable() ? CondExpr.get() : Cond;
 }
 


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


r352838 - Fix isInSystemMacro to handle pasted macros

2019-02-01 Thread Serge Guelton via cfe-commits
Author: serge_sans_paille
Date: Thu Jan 31 22:11:44 2019
New Revision: 352838

URL: http://llvm.org/viewvc/llvm-project?rev=352838&view=rev
Log:
Fix isInSystemMacro to handle pasted macros

Token pasted by the preprocessor (through ##) have a Spelling pointing to 
scratch buffer.
As a result they are not recognized at system macro, even though the pasting 
happened in
a system macro. Fix that by looking into the parent macro if the original 
lookup finds a
scratch buffer.

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

This effectively fixes https://bugs.llvm.org/show_bug.cgi?id=35268,

Added:
cfe/trunk/test/Misc/no-warn-in-system-macro.c
cfe/trunk/test/Misc/no-warn-in-system-macro.c.inc
cfe/trunk/test/Misc/warn-in-system-macro-def.c
cfe/trunk/test/Misc/warn-in-system-macro-def.c.inc
Modified:
cfe/trunk/include/clang/Basic/SourceManager.h

Modified: cfe/trunk/include/clang/Basic/SourceManager.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/SourceManager.h?rev=352838&r1=352837&r2=352838&view=diff
==
--- cfe/trunk/include/clang/Basic/SourceManager.h (original)
+++ cfe/trunk/include/clang/Basic/SourceManager.h Thu Jan 31 22:11:44 2019
@@ -1440,6 +1440,12 @@ public:
 return Filename.equals("");
   }
 
+  /// Returns whether \p Loc is located in a  file.
+  bool isWrittenInScratchSpace(SourceLocation Loc) const {
+StringRef Filename(getPresumedLoc(Loc).getFilename());
+return Filename.equals("");
+  }
+
   /// Returns if a SourceLocation is in a system header.
   bool isInSystemHeader(SourceLocation Loc) const {
 return isSystem(getFileCharacteristic(Loc));
@@ -1452,7 +1458,17 @@ public:
 
   /// Returns whether \p Loc is expanded from a macro in a system header.
   bool isInSystemMacro(SourceLocation loc) const {
-return loc.isMacroID() && isInSystemHeader(getSpellingLoc(loc));
+if(!loc.isMacroID())
+  return false;
+
+// This happens when the macro is the result of a paste, in that case
+// its spelling is the scratch memory, so we take the parent context.
+if (isWrittenInScratchSpace(getSpellingLoc(loc))) {
+  return isInSystemHeader(getSpellingLoc(getImmediateMacroCallerLoc(loc)));
+}
+else {
+  return isInSystemHeader(getSpellingLoc(loc));
+}
   }
 
   /// The size of the SLocEntry that \p FID represents.

Added: cfe/trunk/test/Misc/no-warn-in-system-macro.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/no-warn-in-system-macro.c?rev=352838&view=auto
==
--- cfe/trunk/test/Misc/no-warn-in-system-macro.c (added)
+++ cfe/trunk/test/Misc/no-warn-in-system-macro.c Thu Jan 31 22:11:44 2019
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -isystem %S -Wdouble-promotion -fsyntax-only %s  2>&1 | 
FileCheck -allow-empty %s
+// CHECK-NOT: warning:
+
+#include 
+
+int main(void)
+{
+   double foo = 1.0;
+
+   if (isnan(foo))
+   return 1;
+   return 0;
+}

Added: cfe/trunk/test/Misc/no-warn-in-system-macro.c.inc
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/no-warn-in-system-macro.c.inc?rev=352838&view=auto
==
--- cfe/trunk/test/Misc/no-warn-in-system-macro.c.inc (added)
+++ cfe/trunk/test/Misc/no-warn-in-system-macro.c.inc Thu Jan 31 22:11:44 2019
@@ -0,0 +1,9 @@
+extern int __isnanf(float f);
+extern int __isnan(double f);
+extern int __isnanl(long double f);
+#define isnan(x) \
+   (sizeof (x) == sizeof (float)\
+   ? __isnanf (x)\
+   : sizeof (x) == sizeof (double)   \
+   ? __isnan (x) : __isnanl (x))
+

Added: cfe/trunk/test/Misc/warn-in-system-macro-def.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/warn-in-system-macro-def.c?rev=352838&view=auto
==
--- cfe/trunk/test/Misc/warn-in-system-macro-def.c (added)
+++ cfe/trunk/test/Misc/warn-in-system-macro-def.c Thu Jan 31 22:11:44 2019
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -isystem %S -Wdouble-promotion -fsyntax-only %s  2>&1 | 
FileCheck -allow-empty %s
+// CHECK: warning:
+// CHECK: expanded from macro 'ISNAN'
+// CHECK: expanded from macro 'isnan'
+
+#include 
+
+#define isnan(x) \
+   (sizeof (x) == sizeof (float)\
+   ? __isnanf (x)\
+   : sizeof (x) == sizeof (double)   \
+   ? __isnan (x) : __isnanl (x))
+
+int main(void)
+{
+   double foo = 1.0;
+
+   if (ISNAN(foo))
+   return 1;
+   return 0;
+}

Added: cfe/trunk/test/Misc/warn-in-system-macro-def.c.inc
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/warn-in-system-macro-def.c.inc?rev=352838&view=auto

r352849 - Provide reason messages for unviable inlining

2019-02-01 Thread Yevgeny Rouban via cfe-commits
Author: yrouban
Date: Fri Feb  1 02:44:43 2019
New Revision: 352849

URL: http://llvm.org/viewvc/llvm-project?rev=352849&view=rev
Log:
Provide reason messages for unviable inlining

InlineCost's isInlineViable() is changed to return InlineResult
instead of bool. This provides messages for failure reasons and
allows to get more specific messages for cases where callsites
are not viable for inlining.

Reviewed By: xbolva00, anemet

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

Modified:
cfe/trunk/test/Frontend/optimization-remark-with-hotness.c

Modified: cfe/trunk/test/Frontend/optimization-remark-with-hotness.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/optimization-remark-with-hotness.c?rev=352849&r1=352848&r2=352849&view=diff
==
--- cfe/trunk/test/Frontend/optimization-remark-with-hotness.c (original)
+++ cfe/trunk/test/Frontend/optimization-remark-with-hotness.c Fri Feb  1 
02:44:43 2019
@@ -66,7 +66,7 @@ void bar(int x) {
 
 int main(int argc, const char *argv[]) {
   for (int i = 0; i < 30; i++)
-// expected-remark@+1 {{bar not inlined into main because it should never 
be inlined (cost=never): always inliner (hotness:}}
+// expected-remark@+1 {{bar not inlined into main because it should never 
be inlined (cost=never): no alwaysinline attribute (hotness:}}
 bar(argc);
   return sum;
 }


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


[clang-tools-extra] r352868 - [clangd] Penalize file-scope symbols in the ranking for non-completion queries

2019-02-01 Thread Sam McCall via cfe-commits
Author: sammccall
Date: Fri Feb  1 05:07:37 2019
New Revision: 352868

URL: http://llvm.org/viewvc/llvm-project?rev=352868&view=rev
Log:
[clangd] Penalize file-scope symbols in the ranking for non-completion queries

Patch by Nathan Ridge!

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

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

Modified: clang-tools-extra/trunk/clangd/Quality.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Quality.cpp?rev=352868&r1=352867&r2=352868&view=diff
==
--- clang-tools-extra/trunk/clangd/Quality.cpp (original)
+++ clang-tools-extra/trunk/clangd/Quality.cpp Fri Feb  1 05:07:37 2019
@@ -282,12 +282,12 @@ computeScope(const NamedDecl *D) {
 }
 
 void SymbolRelevanceSignals::merge(const Symbol &IndexResult) {
-  // FIXME: Index results always assumed to be at global scope. If Scope 
becomes
-  // relevant to non-completion requests, we should recognize class members 
etc.
-
   SymbolURI = IndexResult.CanonicalDeclaration.FileURI;
   SymbolScope = IndexResult.Scope;
   IsInstanceMember |= isInstanceMember(IndexResult.SymInfo);
+  if (!(IndexResult.Flags & Symbol::VisibleOutsideFile)) {
+Scope = AccessibleScope::FileScope;
+  }
 }
 
 void SymbolRelevanceSignals::merge(const CodeCompletionResult &SemaCCResult) {
@@ -365,7 +365,7 @@ float SymbolRelevanceSignals::evaluate()
 case GlobalScope:
   break;
 case FileScope:
-  Score *= 1.5;
+  Score *= 1.5f;
   break;
 case ClassScope:
   Score *= 2;
@@ -374,6 +374,19 @@ float SymbolRelevanceSignals::evaluate()
   Score *= 4;
   break;
 }
+  } else {
+// For non-completion queries, the wider the scope where a symbol is
+// visible, the more likely it is to be relevant.
+switch (Scope) {
+case GlobalScope:
+  break;
+case FileScope:
+  Score *= 0.5f;
+  break;
+default:
+  // TODO: Handle other scopes as we start to use them for index results.
+  break;
+}
   }
 
   if (TypeMatchesPreferred)

Modified: clang-tools-extra/trunk/unittests/clangd/QualityTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clangd/QualityTests.cpp?rev=352868&r1=352867&r2=352868&view=diff
==
--- clang-tools-extra/trunk/unittests/clangd/QualityTests.cpp (original)
+++ clang-tools-extra/trunk/unittests/clangd/QualityTests.cpp Fri Feb  1 
05:07:37 2019
@@ -178,6 +178,16 @@ TEST(QualityTests, SymbolRelevanceSignal
   BaseMember.InBaseClass = true;
   Relevance.merge(BaseMember);
   EXPECT_TRUE(Relevance.InBaseClass);
+
+  auto Index = Test.index();
+  Symbol X;
+  FuzzyFindRequest Req;
+  Req.Query = "X";
+  Req.AnyScope = true;
+  Index->fuzzyFind(Req, [&X](const Symbol& S){ X = S; });
+  Relevance = {};
+  Relevance.merge(X);
+  EXPECT_EQ(Relevance.Scope, SymbolRelevanceSignals::FileScope);
 }
 
 // Do the signals move the scores in the direction we expect?
@@ -264,7 +274,7 @@ TEST(QualityTests, SymbolRelevanceSignal
 
   SymbolRelevanceSignals Scoped;
   Scoped.Scope = SymbolRelevanceSignals::FileScope;
-  EXPECT_EQ(Scoped.evaluate(), Default.evaluate());
+  EXPECT_LT(Scoped.evaluate(), Default.evaluate());
   Scoped.Query = SymbolRelevanceSignals::CodeComplete;
   EXPECT_GT(Scoped.evaluate(), Default.evaluate());
 


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


[PATCH] D57581: Explicitly add language standard option to test cases that rely on the C++14 default

2019-02-01 Thread Nemanja Ivanovic via Phabricator via cfe-commits
nemanjai created this revision.
nemanjai added reviewers: ilya-biryukov, jfb, takuto.ikuta, rjmccall, rsmith, 
SjoerdMeijer, t.p.northover, erichkeane.
Herald added a subscriber: eraman.
Herald added a project: clang.

One of the platforms on which we do regular builds has some system headers that 
are not compatible with C++14. As a result, we can't compile any code 
(including `test-suite` tests) if we leave the default as is. So what we do is 
set the CMake option that allows us to set clang's default language level (we 
set it to `gnu++11` in our case). However, this causes failures in all of the 
lit tests attached.

This patch simply adds the `-std=gnu++14` option to match the typical default 
for clang that the test cases rely on.

I've tried to add people that have added/modified the tests as reviewers to 
this patch - so I am sorry about the very long list of reviewers. Please let me 
know if this is an acceptable change.


Repository:
  rC Clang

https://reviews.llvm.org/D57581

Files:
  test/CodeCompletion/crash-skipped-bodies-template-inst.cpp
  test/CodeCompletion/skip-auto-funcs.cpp
  test/CodeGenCXX/auto-var-init.cpp
  test/CodeGenCXX/dllexport-no-dllexport-inlines.cpp
  test/CodeGenCXX/new-overflow.cpp
  test/CodeGenCXX/new.cpp
  test/Lexer/cxx-features.cpp
  test/Lexer/half-literal.cpp
  test/Modules/friend-definition-2.cpp
  test/Modules/merge-lambdas.cpp
  test/SemaCXX/int-ptr-cast-SFINAE.cpp
  test/SemaTemplate/argument-dependent-lookup.cpp
  test/SemaTemplate/class-template-decl.cpp
  test/SemaTemplate/typo-dependent-name.cpp

Index: test/SemaTemplate/typo-dependent-name.cpp
===
--- test/SemaTemplate/typo-dependent-name.cpp
+++ test/SemaTemplate/typo-dependent-name.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -std=gnu++14 -fsyntax-only -verify %s
 
 using nullptr_t = decltype(nullptr);
 
Index: test/SemaTemplate/class-template-decl.cpp
===
--- test/SemaTemplate/class-template-decl.cpp
+++ test/SemaTemplate/class-template-decl.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -std=gnu++14 -fsyntax-only -verify %s
 
 template class A;
 
Index: test/SemaTemplate/argument-dependent-lookup.cpp
===
--- test/SemaTemplate/argument-dependent-lookup.cpp
+++ test/SemaTemplate/argument-dependent-lookup.cpp
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -verify %s
-// RUN: %clang_cc1 -verify %s -DHAVE_UNQUALIFIED_LOOKUP_RESULTS
+// RUN: %clang_cc1 -std=gnu++14 -verify %s
+// RUN: %clang_cc1 -std=gnu++14 -verify %s -DHAVE_UNQUALIFIED_LOOKUP_RESULTS
 // expected-no-diagnostics
 
 namespace address_of {
Index: test/SemaCXX/int-ptr-cast-SFINAE.cpp
===
--- test/SemaCXX/int-ptr-cast-SFINAE.cpp
+++ test/SemaCXX/int-ptr-cast-SFINAE.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=gnu++14
 // RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++17
 
 void foo(int* a, int *b) {
Index: test/Modules/merge-lambdas.cpp
===
--- test/Modules/merge-lambdas.cpp
+++ test/Modules/merge-lambdas.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fmodules -verify %s -emit-llvm-only
+// RUN: %clang_cc1 -std=gnu++14 -fmodules -verify %s -emit-llvm-only
 // expected-no-diagnostics
 
 #pragma clang module build A
Index: test/Modules/friend-definition-2.cpp
===
--- test/Modules/friend-definition-2.cpp
+++ test/Modules/friend-definition-2.cpp
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -fmodules %s -verify
-// RUN: %clang_cc1 -fmodules %s -verify -triple i686-windows
+// RUN: %clang_cc1 -std=gnu++14 -fmodules %s -verify
+// RUN: %clang_cc1 -std=gnu++14 -fmodules %s -verify -triple i686-windows
 // expected-no-diagnostics
 #pragma clang module build A
 module A {}
Index: test/Lexer/half-literal.cpp
===
--- test/Lexer/half-literal.cpp
+++ test/Lexer/half-literal.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -pedantic -triple aarch64-linux-gnu %s
+// RUN: %clang_cc1 -std=gnu++14 -fsyntax-only -verify -pedantic -triple aarch64-linux-gnu %s
 float a = 1.0h; // expected-error{{no matching literal operator for call to 'operator""h' with argument of type 'long double' or 'const char *', and no matching literal operator template}}
 float b = 1.0H; // expected-error{{invalid suffix 'H' on floating constant}}
 
Index: test/Lexer/cxx-features.cpp
===
--- test/Lexer/cxx-features.cpp
+++ test/Lexer/cxx-features.cpp
@@ -6,9 +6,9 @@
 //
 // RUN: %clang_cc1 -std=c++17 -fcxx-exceptions -fsized-deallocation -frelaxed-temp

[PATCH] D57472: [AST] Extract ASTDumpTraverser class from ASTDumper

2019-02-01 Thread 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.
Herald added a project: clang.

LGTM with a renaming request.




Comment at: include/clang/AST/ASTDumpTraverser.h:83
+
+  NodeVisitorType &getNodeVisitor() { return getDerived().doGetNodeVisitor(); }
+  Derived &getDerived() { return *static_cast(this); }

steveire wrote:
> aaron.ballman wrote:
> > Given that `ASTDumpTraverser` is itself a visitor of nodes, I wonder if a 
> > better name for this would be `getNodeDumper()` or something (and similarly 
> > renaming the template parameter)?
> I'm not opposed to alternative names, but I do like the current name. We 
> `visit` each node before traversing.
> 
> `NodeVisitor` names make sense to me because 'dumping' isn't necessarily what 
> the delegate class does. It is more consistent with what 'Visitor' usually 
> means.
> 
> Perhaps a type name of `NodeDelegateType` and an accessor `NodeDelegateType 
> &getNodeDelegate()` would also make sense. Then we would have eg:
> 
> ```
>   void Visit(const Attr *A) {
> getNodeDelegate().AddChild([=] {
>   getNodeDelegate().Visit(A);
>   ConstAttrVisitor::Visit(A);
> });
>   }
> ```
> 
> NodeVisitor names make sense to me because 'dumping' isn't necessarily what 
> the delegate class does. It is more consistent with what 'Visitor' usually 
> means.

Very true.

> Perhaps a type name of NodeDelegateType and an accessor NodeDelegateType 
> &getNodeDelegate() would also make sense. 

I think this is an improvement over `getNodeVisitor()`  -- good suggestion!


Repository:
  rC Clang

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

https://reviews.llvm.org/D57472



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


[PATCH] D57540: [C++17] Don't crash while diagnosing different access specifier of a deduction guide.

2019-02-01 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a reviewer: aaron.ballman.
aaron.ballman added inline comments.
Herald added a project: clang.



Comment at: test/SemaCXX/cxx1z-class-template-argument-deduction.cpp:360-361
+  struct Type {
+Typo(); // expected-error{{deduction guide must be declared in the same 
scope}}
+// expected-error@-1{{deduction guide declaration without trailing return 
type}}
+  };

These errors are pretty unfortunate -- they don't really help the user to 
understand what's gone wrong here. They're an improvement over the crash, but I 
think we should try to make the errors more useful if we can.

Why is `Typo()` being treated as a deduction guide? Perhaps we could look to 
see if there is a `->` before making that determination?


Repository:
  rC Clang

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

https://reviews.llvm.org/D57540



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


[PATCH] D57581: Explicitly add language standard option to test cases that rely on the C++14 default

2019-02-01 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

This seems innocuous to me.  I don't see any problem with it, but please don't 
commit until the others have had time to look.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57581



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


[PATCH] D56555: Add Attribute to define nonlazy objc classes

2019-02-01 Thread 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!


Repository:
  rC Clang

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

https://reviews.llvm.org/D56555



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


[PATCH] D57581: Explicitly add language standard option to test cases that rely on the C++14 default

2019-02-01 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added a comment.

The change looks reasonable to me, given that you can change the default 
language version via a build argument.
I don't have the required experience with the lit-tests to give proper 
approval, though, would wait for someone more relevant to do this.

Do have a comment, though. Any, reason to use `-std=gnu++14` and not 
`-std=c++14`?
Most (all?) of the tests do not seem to have anything to do with the gnu 
extensions, so why enable them?


Repository:
  rC Clang

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

https://reviews.llvm.org/D57581



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


[PATCH] D57576: Adding support to the OpenMP mutexinoutset dependency type

2019-02-01 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev accepted this revision.
ABataev added a comment.
This revision is now accepted and ready to land.

LG


Repository:
  rC Clang

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

https://reviews.llvm.org/D57576



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


r352872 - [libclang] Fix -DBUILD_SHARED_LIBS=on build after rC352803

2019-02-01 Thread Fangrui Song via cfe-commits
Author: maskray
Date: Fri Feb  1 06:31:01 2019
New Revision: 352872

URL: http://llvm.org/viewvc/llvm-project?rev=352872&view=rev
Log:
[libclang] Fix -DBUILD_SHARED_LIBS=on build after rC352803

Modified:
cfe/trunk/tools/libclang/CMakeLists.txt

Modified: cfe/trunk/tools/libclang/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CMakeLists.txt?rev=352872&r1=352871&r2=352872&view=diff
==
--- cfe/trunk/tools/libclang/CMakeLists.txt (original)
+++ cfe/trunk/tools/libclang/CMakeLists.txt Fri Feb  1 06:31:01 2019
@@ -36,6 +36,7 @@ set(SOURCES
 set(LIBS
   clangAST
   clangBasic
+  clangDriver
   clangFrontend
   clangIndex
   clangLex


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


[PATCH] D57576: Adding support to the OpenMP mutexinoutset dependency type

2019-02-01 Thread Sergi Mateo Bellido via Phabricator via cfe-commits
smateo added a comment.

Thanks for the review, I will upload it shortly!


Repository:
  rC Clang

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

https://reviews.llvm.org/D57576



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


[PATCH] D46421: [analyzer][CrossTU] Extend CTU to VarDecls with initializer

2019-02-01 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added a comment.
Herald added a project: clang.

In D46421#1375147 , @r.stahl wrote:

> In D46421#1374807 , @NoQ wrote:
>
> > At the same time, i don't have any test cases for the actual change in 
> > behavior that such canonicalization causes. If the test case that you had 
> > in mind is indeed demonstrating this problem, i'd love to have it. If it 
> > turns out that your test case doesn't allow us to demonstrate the problem 
> > without CTU, then probably it has something to do with `ASTImporter` 
> > accidentally canonicalizing the the declaration in `DeclRefExpr` more 
> > rarely than the vanilla AST.
>
>
> This seems unrelated to CTU. The following subset of my test demonstrates 
> this:
>
>   // RUN: %clang_analyze_cc1 -analyzer-checker=core,debug.ExprInspection 
> -verify %s
>  
>   void clang_analyzer_eval(int);
>  
>   extern const int extInt;
>  
>   int main()
>   {
>   clang_analyzer_eval(extInt == 2); // expected-warning{{TRUE}}
>   }
>  
>   extern const int extInt = 2;
>  
>
>
>
>
>   Breakpoint 1, (anonymous namespace)::RegionStoreManager::getBindingForVar 
> (this=0xa7b420, B=..., R=0xa7d348)
>   at 
> /data/work/commitllvm/llvm/tools/clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1948
>   1948if (const Expr *Init = VD->getAnyInitializer()) {
>   (gdb) p VD->getInit()
>   $1 = (const clang::Expr *) 0x0
>   (gdb) p VD->getAnyInitializer()
>   $2 = (const clang::Expr *) 0xa4b630
>  
>


I know you probably tired of me making you split all the patches but I think if 
it is independent of CTU we should submit this fix as a separate commit. This 
way we could be more focused having one commit doing one thing.


Repository:
  rC Clang

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

https://reviews.llvm.org/D46421



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


[PATCH] D46421: [analyzer][CrossTU] Extend CTU to VarDecls with initializer

2019-02-01 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added a comment.

Thank you for working on this!

I have two concerns:

- The logic when should we import the initializer of a VarDecl is duplicated. I 
think to have better maintainability it would be better to have only one 
implementation of the decision in a function and call it multiple times.
- While the static analyzer is currently the only user of CTU lib it might 
change in the future. Only importing initializers of const variables is an 
analyzer specific decision which might not be good for other potential users of 
the CTU library. Maybe it would be better to be able to configure the 
ClangExtDefMapGen somehow, so it is able to both export only vardecls that are 
required by the analyzer or anything?




Comment at: lib/CrossTU/CrossTranslationUnit.cpp:163
+static bool hasBodyOrInit(const VarDecl *D, const VarDecl *&DefD) {
+  return D->getAnyInitializer(DefD) != nullptr;
+}

The `!= nullptr` part is usually not written in LLVM codebase.



Comment at: lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:357
+  return true;
+if (!RTy->hasConstFields())
+  return true;

I wonder what would happen with types that has const fields and user written 
constructors. In case we will not simulate the effect of the constructor and 
will not be able to set the const fields maybe we should exclude those as well?



Comment at: lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:362
+  // Only import if const.
+  if (!Ctx->getCanonicalType(VD->getType()).isConstQualified())
+return true;

Maybe this check could be hoisted so we do not need to repeat in both branches?



Comment at: lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:369
+
+if (VD->getAnyInitializer() != nullptr)
+  return true;

Redundant `!= nullptr`.



Comment at: tools/clang-extdef-mapping/ClangExtDefMapGen.cpp:68
+QualType VTy = VD->getType();
+bool containsConst = VTy.isConstQualified();
+if (!containsConst && !VTy.isNull())

Variables should start with a capital letter.


Repository:
  rC Clang

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

https://reviews.llvm.org/D46421



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


[PATCH] D57556: Fix for -DBUILD_SHARED_LIBS=ON build after rL352803

2019-02-01 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

Sorry I didn't notice this. D57345  has been 
fixed in rC352872 


Repository:
  rC Clang

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

https://reviews.llvm.org/D57556



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


[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

2019-02-01 Thread Lingda Li via Phabricator via cfe-commits
lildmh updated this revision to Diff 184740.
lildmh added a comment.
Herald added a subscriber: openmp-commits.

Rebase.

Hi Alexey,

Thanks a lot for the review! It seems no one else will review it. If you think 
it's ready to go, could you please accept this patch? I also need help to 
commit this patch since I don't have the privilege.


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

https://reviews.llvm.org/D56326

Files:
  include/clang/AST/DeclBase.h
  include/clang/AST/DeclCXX.h
  include/clang/AST/DeclOpenMP.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/Basic/DeclNodes.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/ASTDumper.cpp
  lib/AST/CXXInheritance.cpp
  lib/AST/DeclBase.cpp
  lib/AST/DeclOpenMP.cpp
  lib/AST/DeclPrinter.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/CodeGenModule.h
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriterDecl.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp
  tools/libclang/CIndex.cpp

Index: tools/libclang/CIndex.cpp
===
--- tools/libclang/CIndex.cpp
+++ tools/libclang/CIndex.cpp
@@ -6229,6 +6229,7 @@
   case Decl::Import:
   case Decl::OMPThreadPrivate:
   case Decl::OMPDeclareReduction:
+  case Decl::OMPDeclareMapper:
   case Decl::OMPRequires:
   case Decl::ObjCTypeParam:
   case Decl::BuiltinTemplate:
Index: test/OpenMP/declare_mapper_messages.cpp
===
--- /dev/null
+++ test/OpenMP/declare_mapper_messages.cpp
@@ -0,0 +1,70 @@
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 %s
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp -ferror-limit 100 -std=c++11 %s
+
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 -std=c++98 %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ferror-limit 100 -std=c++11 %s
+
+int temp; // expected-note {{'temp' declared here}}
+
+class vec { // expected-note {{definition of 'vec' is not complete until the closing '}'}}
+private:
+  int p;// expected-note {{declared private here}}
+public:
+  int len;
+#pragma omp declare mapper(id: vec v) map(v.len)// expected-error {{member access into incomplete type 'vec'}}
+  double *data;
+};
+
+#pragma omp declare mapper  // expected-error {{expected '(' after 'declare mapper'}}
+#pragma omp declare mapper {// expected-error {{expected '(' after 'declare mapper'}}
+#pragma omp declare mapper( // expected-error {{expected a type}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(#// expected-error {{expected a type}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(v// expected-error {{unknown type name 'v'}} expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(vec  // expected-error {{expected declarator on 'omp declare mapper' directive}}
+#pragma omp declare mapper(S v  // expected-error {{unknown type name 'S'}}
+#pragma omp declare mapper(vec v// expected-error {{expected ')'}} expected-note {{to match this '('}}
+#pragma omp declare mapper(aa: vec v)   // expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}}
+#pragma omp declare mapper(bb: vec v) private(v)// expected-error {{expected at least one clause on '#pragma omp declare mapper' directive}} // expected-error {{unexpected OpenMP clause 'private' in directive '#pragma omp declare mapper'}}
+#pragma omp declare mapper(cc: vec v) map(v) (  // expected-warning {{ext

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

2019-02-01 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev accepted this revision.
ABataev added a comment.
This revision is now accepted and ready to land.

Accepted, just was not marked as accepted for an unknown reason.


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

https://reviews.llvm.org/D56326



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


[clang-tools-extra] r352874 - [clangd] Lib to compute and represent selection under cursor.

2019-02-01 Thread Sam McCall via cfe-commits
Author: sammccall
Date: Fri Feb  1 07:05:11 2019
New Revision: 352874

URL: http://llvm.org/viewvc/llvm-project?rev=352874&view=rev
Log:
[clangd] Lib to compute and represent selection under cursor.

Summary:
The primary problem this solves is to expose the codeAction selection to
AST-based refactorings in a way that makes it easy and efficient for them to
bind to the right parts of the AST.

It should also allow us to make XRefs based features (textDocument/definition)
more robust, more easily implement textDocument/typeDefinition etc.
As an example, template parameter references can be identified without special
handling.
There should be slight speedup too: we can prune most of the AST traversal
in most cases.

Elephant in the room: this is similar-but-different to 
Tooling/Refactoring/ASTSelection.
That captures a smaller set of AST nodes, has a slightly different way of
representing selections, and generally has mare features and does more work.
The overall shape is pretty similar, and yet I can't quite get to behave as I
expect.

Reviewers: ilya-biryukov, kadircet

Subscribers: mgorny, ioeric, MaskRay, jkorous, mgrang, arphaman

Tags: #clang

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

Added:
clang-tools-extra/trunk/clangd/Selection.cpp
clang-tools-extra/trunk/clangd/Selection.h
clang-tools-extra/trunk/unittests/clangd/SelectionTests.cpp
Modified:
clang-tools-extra/trunk/clangd/CMakeLists.txt
clang-tools-extra/trunk/unittests/clangd/CMakeLists.txt

Modified: clang-tools-extra/trunk/clangd/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/CMakeLists.txt?rev=352874&r1=352873&r2=352874&view=diff
==
--- clang-tools-extra/trunk/clangd/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clangd/CMakeLists.txt Fri Feb  1 07:05:11 2019
@@ -46,6 +46,7 @@ add_clang_library(clangDaemon
   Protocol.cpp
   Quality.cpp
   RIFF.cpp
+  Selection.cpp
   SourceCode.cpp
   Threading.cpp
   Trace.cpp

Added: clang-tools-extra/trunk/clangd/Selection.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Selection.cpp?rev=352874&view=auto
==
--- clang-tools-extra/trunk/clangd/Selection.cpp (added)
+++ clang-tools-extra/trunk/clangd/Selection.cpp Fri Feb  1 07:05:11 2019
@@ -0,0 +1,301 @@
+//===--- Selection.h 
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "Selection.h"
+#include "ClangdUnit.h"
+#include "clang/AST/RecursiveASTVisitor.h"
+
+namespace clang {
+namespace clangd {
+namespace {
+using Node = SelectionTree::Node;
+using ast_type_traits::DynTypedNode;
+
+// We find the selection by visiting written nodes in the AST, looking for 
nodes
+// that intersect with the selected character range.
+//
+// While traversing, we maintain a parent stack. As nodes pop off the stack,
+// we decide whether to keep them or not. To be kept, they must either be
+// selected or contain some nodes that are.
+//
+// For simple cases (not inside macros) we prune subtrees that don't intersect.
+class SelectionVisitor : public RecursiveASTVisitor {
+public:
+  // Runs the visitor to gather selected nodes and their ancestors.
+  // If there is any selection, the root (TUDecl) is the first node.
+  static std::deque collect(ASTContext &AST, unsigned Begin,
+  unsigned End, FileID File) {
+SelectionVisitor V(AST, Begin, End, File);
+V.TraverseAST(AST);
+assert(V.Stack.size() == 1 && "Unpaired push/pop?");
+assert(V.Stack.top() == &V.Nodes.front());
+if (V.Nodes.size() == 1) // TUDecl, but no nodes under it.
+  V.Nodes.clear();
+return std::move(V.Nodes);
+  }
+
+  // We traverse all "well-behaved" nodes the same way:
+  //  - push the node onto the stack
+  //  - traverse its children recursively
+  //  - pop it from the stack
+  //  - hit testing: is intersection(node, selection) - union(children) empty?
+  //  - attach it to the tree if it or any children hit the selection
+  //
+  // Two categories of nodes are not "well-behaved":
+  //  - those without source range information, we don't record those
+  //  - those that can't be stored in DynTypedNode.
+  // We're missing some interesting things like Attr due to the latter.
+  bool TraverseDecl(Decl *X) {
+if (isa(X))
+  return Base::TraverseDecl(X); // Already pushed by constructor.
+return traverseNode(X, [&] { return Base::TraverseDecl(X); });
+  }
+  bool TraverseTypeLoc(TypeLoc X) {
+return traverseNode(&X, [&] { return Base::TraverseTypeLoc(X); });
+  }

[PATCH] D57585: [AST][OpenMP] OpenMP Sections / Section constructs contain Structured blocks

2019-02-01 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In D57585#1380673 , @ABataev wrote:

> LG


Okay, that sounds promising, thank you for the review!


Repository:
  rC Clang

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

https://reviews.llvm.org/D57585



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


[clang-tools-extra] r352875 - [clangd] Lib to compute and represent selection under cursor.

2019-02-01 Thread Sam McCall via cfe-commits
Author: sammccall
Date: Fri Feb  1 07:09:41 2019
New Revision: 352875

URL: http://llvm.org/viewvc/llvm-project?rev=352875&view=rev
Log:
[clangd] Lib to compute and represent selection under cursor.

Summary:
The primary problem this solves is to expose the codeAction selection to
AST-based refactorings in a way that makes it easy and efficient for them to
bind to the right parts of the AST.

It should also allow us to make XRefs based features (textDocument/definition)
more robust, more easily implement textDocument/typeDefinition etc.
As an example, template parameter references can be identified without special
handling.
There should be slight speedup too: we can prune most of the AST traversal
in most cases.

Elephant in the room: this is similar-but-different to 
Tooling/Refactoring/ASTSelection.
That captures a smaller set of AST nodes, has a slightly different way of
representing selections, and generally has mare features and does more work.
The overall shape is pretty similar, and yet I can't quite get to behave as I
expect.

Reviewers: ilya-biryukov, kadircet

Subscribers: mgorny, ioeric, MaskRay, jkorous, mgrang, arphaman

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clangd/Selection.cpp

Modified: clang-tools-extra/trunk/clangd/Selection.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Selection.cpp?rev=352875&r1=352874&r2=352875&view=diff
==
--- clang-tools-extra/trunk/clangd/Selection.cpp (original)
+++ clang-tools-extra/trunk/clangd/Selection.cpp Fri Feb  1 07:09:41 2019
@@ -112,9 +112,15 @@ private:
   // An optimization for a common case: nodes outside macro expansions that
   // don't intersect the selection may be recursively skipped.
   bool canSafelySkipNode(SourceRange S) {
+<<< HEAD
 auto B = SM.getDecomposedLoc(S.getBegin());
 auto E = SM.getDecomposedLoc(S.getEnd());
 if (B.first != SelFile || E.first != SelFile)
+===
+auto B = SM.getDecomposedLoc(S.getBegin()),
+ E = SM.getDecomposedLoc(S.getEnd());
+if (B.first != SM.getMainFileID() || E.first != SM.getMainFileID())
+>>> [clangd] Lib to compute and represent selection under cursor.
   return false;
 return B.second >= SelEnd || E.second < SelBeginTokenStart;
   }
@@ -156,6 +162,7 @@ private:
 // LOOP_FOREVER( ++x; )
 //   }
 // Selecting "++x" or "x" will do the right thing.
+<<< HEAD
 auto B = SM.getDecomposedLoc(SM.getTopMacroCallerLoc(S.getBegin()));
 auto E = SM.getDecomposedLoc(SM.getTopMacroCallerLoc(S.getEnd()));
 // Otherwise, nodes in macro expansions can't be selected.
@@ -164,6 +171,16 @@ private:
 // Cheap test: is there any overlap at all between the selection and range?
 // Note that E.second is the *start* of the last token, which is why we
 // compare against the "rounded-down" SelBegin.
+===
+auto B = SM.getDecomposedLoc(SM.getTopMacroCallerLoc(S.getBegin())),
+ E = SM.getDecomposedLoc(SM.getTopMacroCallerLoc(S.getEnd()));
+// Otherwise, nodes in macro expansions can't be selected.
+if (B.first != SM.getMainFileID() || E.first != SM.getMainFileID())
+  return SelectionTree::Unselected;
+// Cheap test: is there any overlap at all between the selection and range?
+// Note that E.second is the *start* of the last token, which is why we
+// compare against the "rounded-down" MinOffset.
+>>> [clangd] Lib to compute and represent selection under cursor.
 if (B.second >= SelEnd || E.second < SelBeginTokenStart)
   return SelectionTree::Unselected;
 
@@ -196,7 +213,11 @@ private:
   CharSourceRange R = SM.getExpansionRange(N->ASTNode.getSourceRange());
   auto B = SM.getDecomposedLoc(R.getBegin());
   auto E = SM.getDecomposedLoc(R.getEnd());
+<<< HEAD
   if (B.first != SelFile || E.first != SelFile)
+===
+  if (B.first != SM.getMainFileID() || E.first != SM.getMainFileID())
+>>> [clangd] Lib to compute and represent selection under cursor.
 continue;
   assert(R.isTokenRange());
   // Try to cover up to the next token, spaces between children don't 
count.
@@ -222,6 +243,7 @@ private:
   SourceManager &SM;
   const LangOptions &LangOpts;
   std::stack Stack;
+<<< HEAD
   std::deque Nodes; // Stable pointers as we add more nodes.
   // Half-open selection range.
   unsigned SelBegin;
@@ -233,6 +255,10 @@ private:
   // range.end + measureToken(range.end) < SelBegin (assuming range.end points
   // to a token), and it saves a lex every time.
   unsigned SelBeginTokenStart;
+===
+  std::deque Nodes;
+  unsigned SelBegin, SelEnd, SelBeginTokenStart;
+>>> [clangd] Lib to compute and represent selection under cursor.
 };
 
 } // namespace
@@ -252,9 +278,16 @@ void SelectionTree::print(llvm::raw_ostr
 }
 
 // Decide which selection emulates a "point" query in bet

[PATCH] D57585: [AST][OpenMP] OpenMP Sections / Section constructs contain Structured blocks

2019-02-01 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri created this revision.
lebedev.ri added reviewers: ABataev, OpenMP.
lebedev.ri added projects: clang, OpenMP.
Herald added subscribers: openmp-commits, guansong.

I'm working on a clang-tidy check, much like existing bugprone-exception-escape 
,
to detect when an exception might escape out of an OpenMP construct it isn't 
supposed to escape from.
For that i will be using the `nothrow` bit of `CapturedDecl`s.

While that bit is already correctly set for some constructs, e.g. `#pragma omp 
parallel`: https://godbolt.org/z/2La7pv
it isn't set for the `#pragma omp sections`, or `#pragma omp section`: 
https://godbolt.org/z/qZ-EbP

If i'm reading `OpenMP Application Programming Interface Version 5.0 November 
2018` 
 
correctly,
they should be, as per `2.8.1 sections Construct`, starting with page 86:

- The sections construct is a non-iterative worksharing construct that contains 
a set of **structured blocks** that are to be distributed among and executed by 
the threads in a team. Each **structured block** is executed once by one of the 
threads in the team in the context of its implicit task.
- The syntax of the sections construct is as follows: #pragma omp sections 
[clause[ [,] clause] ... ] new-line { [#pragma omp section new-line] 
**structured-block** ...
- Description Each **structured block** in the sections construct is preceded 
by a section directive except possibly **the first block**, for which a 
preceding section directive is optional.

- Restrictions • The code enclosed in a sections construct must be a 
**structured block**.
  - A throw executed inside a sections region must cause execution to resume 
within the same section of the sections region, and the same thread that threw 
the exception must catch it.


Repository:
  rC Clang

https://reviews.llvm.org/D57585

Files:
  lib/Sema/SemaOpenMP.cpp
  test/AST/ast-dump-openmp-sections.cpp


Index: test/AST/ast-dump-openmp-sections.cpp
===
--- /dev/null
+++ test/AST/ast-dump-openmp-sections.cpp
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -verify -fopenmp -ast-dump %s | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ast-dump %s | FileCheck %s
+// expected-no-diagnostics
+
+void sections() {
+#pragma omp sections
+  {
+#pragma omp section
+{
+}
+#pragma omp section
+{
+}
+  }
+}
+
+// CHECK: `-FunctionDecl
+// CHECK-NEXT:   `-CompoundStmt
+// CHECK-NEXT: `-OMPSectionsDirective
+// CHECK-NEXT:   `-CapturedStmt
+// CHECK-NEXT: `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   |-CompoundStmt
+// CHECK-NEXT:   | |-OMPSectionDirective
+// CHECK-NEXT:   | | `-CapturedStmt
+// CHECK-NEXT:   | |   `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   | | |-CompoundStmt
+// CHECK-NEXT:   | | `-ImplicitParamDecl
+// CHECK-NEXT:   | `-OMPSectionDirective
+// CHECK-NEXT:   |   `-CapturedStmt
+// CHECK-NEXT:   | `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   |   |-CompoundStmt
+// CHECK-NEXT:   |   `-ImplicitParamDecl
+// CHECK-NEXT:   |-ImplicitParamDecl
+// CHECK-NEXT:   |-CXXRecordDecl
+// CHECK-NEXT:   | |-DefinitionData
+// CHECK-NEXT:   | | |-DefaultConstructor
+// CHECK-NEXT:   | | |-CopyConstructor
+// CHECK-NEXT:   | | |-MoveConstructor
+// CHECK-NEXT:   | | |-CopyAssignment
+// CHECK-NEXT:   | | |-MoveAssignment
+// CHECK-NEXT:   | | `-Destructor
+// CHECK-NEXT:   | `-CapturedRecordAttr
+// CHECK-NEXT:   |-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   | |-CompoundStmt
+// CHECK-NEXT:   | `-ImplicitParamDecl
+// CHECK-NEXT:   |-CXXRecordDecl
+// CHECK-NEXT:   | |-DefinitionData
+// CHECK-NEXT:   | | |-DefaultConstructor
+// CHECK-NEXT:   | | |-CopyConstructor
+// CHECK-NEXT:   | | |-MoveConstructor
+// CHECK-NEXT:   | | |-CopyAssignment
+// CHECK-NEXT:   | | |-MoveAssignment
+// CHECK-NEXT:   | | `-Destructor
+// CHECK-NEXT:   | `-CapturedRecordAttr
+// CHECK-NEXT:   `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT: |-CompoundStmt
+// CHECK-NEXT: `-ImplicitParamDecl
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -5969,6 +5969,13 @@
 return StmtError();
   }
 
+  // 1.2.2 OpenMP Language Terminology
+  // Structured block - An executable statement with a single entry at the
+  // top and a single exit at the bottom.
+  // The point of exit cannot be a branch out of the structured block.
+  // longjmp() and throw() must not violate the entry/exit criteria.
+  cast(AStmt)->getCaptur

[PATCH] D57585: [AST][OpenMP] OpenMP Sections / Section constructs contain Structured blocks

2019-02-01 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev accepted this revision.
ABataev added a comment.
This revision is now accepted and ready to land.

LG


Repository:
  rC Clang

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

https://reviews.llvm.org/D57585



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


[PATCH] D57577: Make predefined FLT16 macros conditional on support for the type

2019-02-01 Thread Dan Gohman via Phabricator via cfe-commits
sunfish added a comment.

I think WebAssembly is in the same situation as most other architectures, as 
discussed here:

http://llvm.org/viewvc/llvm-project?view=revision&revision=352221

and should not enable _Float16 yet. The test/Preprocessor/init.c tests were 
semi-automatically generated, so it wasn't specifically intended to include 
tests for FLT16 macros for WebAssembly.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57577



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


[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

2019-02-01 Thread Lingda Li via Phabricator via cfe-commits
lildmh added a comment.

Thanks a lot Alexey!


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

https://reviews.llvm.org/D56326



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


[clang-tools-extra] r352876 - [clangd] Expose SelectionTree to code tweaks, and use it for swap if branches.

2019-02-01 Thread Sam McCall via cfe-commits
Author: sammccall
Date: Fri Feb  1 07:09:47 2019
New Revision: 352876

URL: http://llvm.org/viewvc/llvm-project?rev=352876&view=rev
Log:
[clangd] Expose SelectionTree to code tweaks, and use it for swap if branches.

Summary:
This reduces the per-check implementation burden and redundant work.
It also makes checks range-aware by default (treating the commonAncestor
as if it were a point selection should be good baseline behavior).

Reviewers: ilya-biryukov

Subscribers: ioeric, MaskRay, jkorous, arphaman, kadircet

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clangd/ClangdServer.cpp
clang-tools-extra/trunk/clangd/Selection.cpp
clang-tools-extra/trunk/clangd/refactor/Tweak.cpp
clang-tools-extra/trunk/clangd/refactor/Tweak.h
clang-tools-extra/trunk/clangd/refactor/tweaks/SwapIfBranches.cpp
clang-tools-extra/trunk/unittests/clangd/TweakTests.cpp

Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.cpp?rev=352876&r1=352875&r2=352876&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdServer.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdServer.cpp Fri Feb  1 07:09:47 2019
@@ -328,23 +328,28 @@ void ClangdServer::rename(PathRef File,
   "Rename", File, Bind(Action, File.str(), NewName.str(), std::move(CB)));
 }
 
+static llvm::Expected
+tweakSelection(const Range &Sel, const InputsAndAST &AST) {
+  auto Begin = positionToOffset(AST.Inputs.Contents, Sel.start);
+  if (!Begin)
+return Begin.takeError();
+  auto End = positionToOffset(AST.Inputs.Contents, Sel.end);
+  if (!End)
+return End.takeError();
+  return Tweak::Selection(AST.AST, *Begin, *End);
+}
+
 void ClangdServer::enumerateTweaks(PathRef File, Range Sel,
Callback> CB) {
   auto Action = [Sel](decltype(CB) CB, std::string File,
   Expected InpAST) {
 if (!InpAST)
   return CB(InpAST.takeError());
-
-auto &AST = InpAST->AST;
-auto CursorLoc = sourceLocationInMainFile(
-AST.getASTContext().getSourceManager(), Sel.start);
-if (!CursorLoc)
-  return CB(CursorLoc.takeError());
-Tweak::Selection Inputs = {InpAST->Inputs.Contents, InpAST->AST,
-   *CursorLoc};
-
+auto Selection = tweakSelection(Sel, *InpAST);
+if (!Selection)
+  return CB(Selection.takeError());
 std::vector Res;
-for (auto &T : prepareTweaks(Inputs))
+for (auto &T : prepareTweaks(*Selection))
   Res.push_back({T->id(), T->title()});
 CB(std::move(Res));
   };
@@ -359,20 +364,14 @@ void ClangdServer::applyTweak(PathRef Fi
   Expected InpAST) {
 if (!InpAST)
   return CB(InpAST.takeError());
-
-auto &AST = InpAST->AST;
-auto CursorLoc = sourceLocationInMainFile(
-AST.getASTContext().getSourceManager(), Sel.start);
-if (!CursorLoc)
-  return CB(CursorLoc.takeError());
-Tweak::Selection Inputs = {InpAST->Inputs.Contents, InpAST->AST,
-   *CursorLoc};
-
-auto A = prepareTweak(TweakID, Inputs);
+auto Selection = tweakSelection(Sel, *InpAST);
+if (!Selection)
+  return CB(Selection.takeError());
+auto A = prepareTweak(TweakID, *Selection);
 if (!A)
   return CB(A.takeError());
 // FIXME: run formatter on top of resulting replacements.
-return CB((*A)->apply(Inputs));
+return CB((*A)->apply(*Selection));
   };
   WorkScheduler.runWithAST(
   "ApplyTweak", File,

Modified: clang-tools-extra/trunk/clangd/Selection.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Selection.cpp?rev=352876&r1=352875&r2=352876&view=diff
==
--- clang-tools-extra/trunk/clangd/Selection.cpp (original)
+++ clang-tools-extra/trunk/clangd/Selection.cpp Fri Feb  1 07:09:47 2019
@@ -112,15 +112,9 @@ private:
   // An optimization for a common case: nodes outside macro expansions that
   // don't intersect the selection may be recursively skipped.
   bool canSafelySkipNode(SourceRange S) {
-<<< HEAD
 auto B = SM.getDecomposedLoc(S.getBegin());
 auto E = SM.getDecomposedLoc(S.getEnd());
 if (B.first != SelFile || E.first != SelFile)
-===
-auto B = SM.getDecomposedLoc(S.getBegin()),
- E = SM.getDecomposedLoc(S.getEnd());
-if (B.first != SM.getMainFileID() || E.first != SM.getMainFileID())
->>> [clangd] Lib to compute and represent selection under cursor.
   return false;
 return B.second >= SelEnd || E.second < SelBeginTokenStart;
   }
@@ -162,7 +156,6 @@ private:
 // LOOP_FOREVER( ++x; )
 //   }
 // Selecting "++x" or "x" will do the right thing.
-<<< HEAD
 auto B = SM.getDecomposedLoc(SM.getTopMacroCallerLoc(S.getB

[PATCH] D57521: [CMake] External compiler-rt-configure requires LLVMTestingSupport when including tests

2019-02-01 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL352881: [CMake] External compiler-rt-configure requires 
LLVMTestingSupport when… (authored by stefan.graenitz, committed by ).
Herald added a project: LLVM.

Repository:
  rL LLVM

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

https://reviews.llvm.org/D57521

Files:
  cfe/trunk/runtime/CMakeLists.txt


Index: cfe/trunk/runtime/CMakeLists.txt
===
--- cfe/trunk/runtime/CMakeLists.txt
+++ cfe/trunk/runtime/CMakeLists.txt
@@ -58,12 +58,16 @@
 endif()
   endforeach()
 
+  set(compiler_rt_configure_deps)
   if(TARGET cxx-headers)
-set(COMPILER_RT_LIBCXX_DEPENDENCY "cxx-headers")
+list(APPEND compiler_rt_configure_deps "cxx-headers")
+  endif()
+  if(LLVM_INCLUDE_TESTS)
+list(APPEND compiler_rt_configure_deps LLVMTestingSupport)
   endif()
 
   ExternalProject_Add(compiler-rt
-DEPENDS llvm-config clang ${COMPILER_RT_LIBCXX_DEPENDENCY}
+DEPENDS llvm-config clang ${compiler_rt_configure_deps}
 PREFIX ${COMPILER_RT_PREFIX}
 SOURCE_DIR ${COMPILER_RT_SRC_ROOT}
 STAMP_DIR ${STAMP_DIR}


Index: cfe/trunk/runtime/CMakeLists.txt
===
--- cfe/trunk/runtime/CMakeLists.txt
+++ cfe/trunk/runtime/CMakeLists.txt
@@ -58,12 +58,16 @@
 endif()
   endforeach()
 
+  set(compiler_rt_configure_deps)
   if(TARGET cxx-headers)
-set(COMPILER_RT_LIBCXX_DEPENDENCY "cxx-headers")
+list(APPEND compiler_rt_configure_deps "cxx-headers")
+  endif()
+  if(LLVM_INCLUDE_TESTS)
+list(APPEND compiler_rt_configure_deps LLVMTestingSupport)
   endif()
 
   ExternalProject_Add(compiler-rt
-DEPENDS llvm-config clang ${COMPILER_RT_LIBCXX_DEPENDENCY}
+DEPENDS llvm-config clang ${compiler_rt_configure_deps}
 PREFIX ${COMPILER_RT_PREFIX}
 SOURCE_DIR ${COMPILER_RT_SRC_ROOT}
 STAMP_DIR ${STAMP_DIR}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r352881 - [CMake] External compiler-rt-configure requires LLVMTestingSupport when including tests

2019-02-01 Thread Stefan Granitz via cfe-commits
Author: stefan.graenitz
Date: Fri Feb  1 07:35:25 2019
New Revision: 352881

URL: http://llvm.org/viewvc/llvm-project?rev=352881&view=rev
Log:
[CMake] External compiler-rt-configure requires LLVMTestingSupport when 
including tests

Summary:
Apparently `LLVMTestingSupport` must be built before `llvm-config` can be asked 
for it. Symptom with `LLVM_INCLUDE_TESTS=ON` is:
```
$ ./path/to/llvm-build/bin/llvm-config --ldflags --libs testingsupport
-L/path/to/llvm-build/lib -Wl,-search_paths_first 
-Wl,-headerpad_max_install_names
llvm-config: error: component libraries and shared library

llvm-config: error: missing: /path/to/llvm-build/lib/libLLVMTestingSupport.a
```

With `LLVMTestingSupport` as dependency of `compiler-rt-configure` we get the 
expected behavior:
```
$ ./path/to/llvm-build/bin/llvm-config --ldflags --libs testingsupport
-L/path/to/llvm-build/lib -Wl,-search_paths_first 
-Wl,-headerpad_max_install_names
-lLLVMTestingSupport -lLLVMSupport -lLLVMDemangle
```

Reviewers: ab, beanz

Subscribers: dberris, mgorny, erik.pilkington, llvm-commits, cfe-commits

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

Modified:
cfe/trunk/runtime/CMakeLists.txt

Modified: cfe/trunk/runtime/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/runtime/CMakeLists.txt?rev=352881&r1=352880&r2=352881&view=diff
==
--- cfe/trunk/runtime/CMakeLists.txt (original)
+++ cfe/trunk/runtime/CMakeLists.txt Fri Feb  1 07:35:25 2019
@@ -58,12 +58,16 @@ if(LLVM_BUILD_EXTERNAL_COMPILER_RT AND E
 endif()
   endforeach()
 
+  set(compiler_rt_configure_deps)
   if(TARGET cxx-headers)
-set(COMPILER_RT_LIBCXX_DEPENDENCY "cxx-headers")
+list(APPEND compiler_rt_configure_deps "cxx-headers")
+  endif()
+  if(LLVM_INCLUDE_TESTS)
+list(APPEND compiler_rt_configure_deps LLVMTestingSupport)
   endif()
 
   ExternalProject_Add(compiler-rt
-DEPENDS llvm-config clang ${COMPILER_RT_LIBCXX_DEPENDENCY}
+DEPENDS llvm-config clang ${compiler_rt_configure_deps}
 PREFIX ${COMPILER_RT_PREFIX}
 SOURCE_DIR ${COMPILER_RT_SRC_ROOT}
 STAMP_DIR ${STAMP_DIR}


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


r352882 - [AST][OpenMP] OpenMP Sections / Section constructs contain Structured blocks

2019-02-01 Thread Roman Lebedev via cfe-commits
Author: lebedevri
Date: Fri Feb  1 07:41:54 2019
New Revision: 352882

URL: http://llvm.org/viewvc/llvm-project?rev=352882&view=rev
Log:
[AST][OpenMP] OpenMP Sections / Section constructs contain Structured blocks

Summary:
I'm working on a clang-tidy check, much like existing [[ 
http://clang.llvm.org/extra/clang-tidy/checks/bugprone-exception-escape.html | 
bugprone-exception-escape ]],
to detect when an exception might escape out of an OpenMP construct it isn't 
supposed to escape from.
For that i will be using the `nothrow` bit of `CapturedDecl`s.

While that bit is already correctly set for some constructs, e.g. `#pragma omp 
parallel`: https://godbolt.org/z/2La7pv
it isn't set for the `#pragma omp sections`, or `#pragma omp section`: 
https://godbolt.org/z/qZ-EbP

If i'm reading [[ 
https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf | 
`OpenMP Application Programming Interface Version 5.0 November 2018` ]] 
correctly,
they should be, as per `2.8.1 sections Construct`, starting with page 86:
* The sections construct is a non-iterative worksharing construct that contains 
a set of **structured blocks**
  that are to be distributed among and executed by the threads in a team. Each 
**structured block** is executed
  once by one of the threads in the team in the context of its implicit task.
* The syntax of the sections construct is as follows:
  #pragma omp sections [clause[ [,] clause] ... ] new-line
{
  [#pragma omp section new-line]
**structured-block**
   ...
* Description
  Each **structured block** in the sections construct is preceded by a section 
directive except
  possibly **the first block**, for which a preceding section directive is 
optional.

* Restrictions
  • The code enclosed in a sections construct must be a **structured block**.
  * A throw executed inside a sections region must cause execution to resume 
within the same
section of the sections region, and the same thread that threw the 
exception must catch it.

Reviewers: ABataev, #openmp

Reviewed By: ABataev

Subscribers: guansong, openmp-commits, cfe-commits

Tags: #clang, #openmp

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

Added:
cfe/trunk/test/AST/ast-dump-openmp-sections.cpp
Modified:
cfe/trunk/lib/Sema/SemaOpenMP.cpp

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=352882&r1=352881&r2=352882&view=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Fri Feb  1 07:41:54 2019
@@ -5969,6 +5969,13 @@ StmtResult Sema::ActOnOpenMPSectionsDire
 return StmtError();
   }
 
+  // 1.2.2 OpenMP Language Terminology
+  // Structured block - An executable statement with a single entry at the
+  // top and a single exit at the bottom.
+  // The point of exit cannot be a branch out of the structured block.
+  // longjmp() and throw() must not violate the entry/exit criteria.
+  cast(AStmt)->getCapturedDecl()->setNothrow();
+
   setFunctionHasBranchProtectedScope();
 
   return OMPSectionsDirective::Create(Context, StartLoc, EndLoc, Clauses, 
AStmt,
@@ -5983,6 +5990,13 @@ StmtResult Sema::ActOnOpenMPSectionDirec
 
   assert(isa(AStmt) && "Captured statement expected");
 
+  // 1.2.2 OpenMP Language Terminology
+  // Structured block - An executable statement with a single entry at the
+  // top and a single exit at the bottom.
+  // The point of exit cannot be a branch out of the structured block.
+  // longjmp() and throw() must not violate the entry/exit criteria.
+  cast(AStmt)->getCapturedDecl()->setNothrow();
+
   setFunctionHasBranchProtectedScope();
   DSAStack->setParentCancelRegion(DSAStack->isCancelRegion());
 

Added: cfe/trunk/test/AST/ast-dump-openmp-sections.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/AST/ast-dump-openmp-sections.cpp?rev=352882&view=auto
==
--- cfe/trunk/test/AST/ast-dump-openmp-sections.cpp (added)
+++ cfe/trunk/test/AST/ast-dump-openmp-sections.cpp Fri Feb  1 07:41:54 2019
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -verify -fopenmp -ast-dump %s | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ast-dump %s | FileCheck %s
+// expected-no-diagnostics
+
+void sections() {
+#pragma omp sections
+  {
+#pragma omp section
+{
+}
+#pragma omp section
+{
+}
+  }
+}
+
+// CHECK: `-FunctionDecl
+// CHECK-NEXT:   `-CompoundStmt
+// CHECK-NEXT: `-OMPSectionsDirective
+// CHECK-NEXT:   `-CapturedStmt
+// CHECK-NEXT: `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   |-CompoundStmt
+// CHECK-NEXT:   | |-OMPSectionDirective
+// CHECK-NEXT:   | | `-CapturedStmt
+// CHECK-NEXT:   | |   `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   | | |-CompoundStmt
+// CHECK-NEXT:   | | `-ImplicitParamDecl
+

[PATCH] D57585: [AST][OpenMP] OpenMP Sections / Section constructs contain Structured blocks

2019-02-01 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC352882: [AST][OpenMP] OpenMP Sections / Section constructs 
contain Structured blocks (authored by lebedevri, committed by ).

Repository:
  rC Clang

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

https://reviews.llvm.org/D57585

Files:
  lib/Sema/SemaOpenMP.cpp
  test/AST/ast-dump-openmp-sections.cpp


Index: test/AST/ast-dump-openmp-sections.cpp
===
--- test/AST/ast-dump-openmp-sections.cpp
+++ test/AST/ast-dump-openmp-sections.cpp
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -verify -fopenmp -ast-dump %s | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ast-dump %s | FileCheck %s
+// expected-no-diagnostics
+
+void sections() {
+#pragma omp sections
+  {
+#pragma omp section
+{
+}
+#pragma omp section
+{
+}
+  }
+}
+
+// CHECK: `-FunctionDecl
+// CHECK-NEXT:   `-CompoundStmt
+// CHECK-NEXT: `-OMPSectionsDirective
+// CHECK-NEXT:   `-CapturedStmt
+// CHECK-NEXT: `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   |-CompoundStmt
+// CHECK-NEXT:   | |-OMPSectionDirective
+// CHECK-NEXT:   | | `-CapturedStmt
+// CHECK-NEXT:   | |   `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   | | |-CompoundStmt
+// CHECK-NEXT:   | | `-ImplicitParamDecl
+// CHECK-NEXT:   | `-OMPSectionDirective
+// CHECK-NEXT:   |   `-CapturedStmt
+// CHECK-NEXT:   | `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   |   |-CompoundStmt
+// CHECK-NEXT:   |   `-ImplicitParamDecl
+// CHECK-NEXT:   |-ImplicitParamDecl
+// CHECK-NEXT:   |-CXXRecordDecl
+// CHECK-NEXT:   | |-DefinitionData
+// CHECK-NEXT:   | | |-DefaultConstructor
+// CHECK-NEXT:   | | |-CopyConstructor
+// CHECK-NEXT:   | | |-MoveConstructor
+// CHECK-NEXT:   | | |-CopyAssignment
+// CHECK-NEXT:   | | |-MoveAssignment
+// CHECK-NEXT:   | | `-Destructor
+// CHECK-NEXT:   | `-CapturedRecordAttr
+// CHECK-NEXT:   |-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   | |-CompoundStmt
+// CHECK-NEXT:   | `-ImplicitParamDecl
+// CHECK-NEXT:   |-CXXRecordDecl
+// CHECK-NEXT:   | |-DefinitionData
+// CHECK-NEXT:   | | |-DefaultConstructor
+// CHECK-NEXT:   | | |-CopyConstructor
+// CHECK-NEXT:   | | |-MoveConstructor
+// CHECK-NEXT:   | | |-CopyAssignment
+// CHECK-NEXT:   | | |-MoveAssignment
+// CHECK-NEXT:   | | `-Destructor
+// CHECK-NEXT:   | `-CapturedRecordAttr
+// CHECK-NEXT:   `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT: |-CompoundStmt
+// CHECK-NEXT: `-ImplicitParamDecl
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -5969,6 +5969,13 @@
 return StmtError();
   }
 
+  // 1.2.2 OpenMP Language Terminology
+  // Structured block - An executable statement with a single entry at the
+  // top and a single exit at the bottom.
+  // The point of exit cannot be a branch out of the structured block.
+  // longjmp() and throw() must not violate the entry/exit criteria.
+  cast(AStmt)->getCapturedDecl()->setNothrow();
+
   setFunctionHasBranchProtectedScope();
 
   return OMPSectionsDirective::Create(Context, StartLoc, EndLoc, Clauses, 
AStmt,
@@ -5983,6 +5990,13 @@
 
   assert(isa(AStmt) && "Captured statement expected");
 
+  // 1.2.2 OpenMP Language Terminology
+  // Structured block - An executable statement with a single entry at the
+  // top and a single exit at the bottom.
+  // The point of exit cannot be a branch out of the structured block.
+  // longjmp() and throw() must not violate the entry/exit criteria.
+  cast(AStmt)->getCapturedDecl()->setNothrow();
+
   setFunctionHasBranchProtectedScope();
   DSAStack->setParentCancelRegion(DSAStack->isCancelRegion());
 


Index: test/AST/ast-dump-openmp-sections.cpp
===
--- test/AST/ast-dump-openmp-sections.cpp
+++ test/AST/ast-dump-openmp-sections.cpp
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -verify -fopenmp -ast-dump %s | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ast-dump %s | FileCheck %s
+// expected-no-diagnostics
+
+void sections() {
+#pragma omp sections
+  {
+#pragma omp section
+{
+}
+#pragma omp section
+{
+}
+  }
+}
+
+// CHECK: `-FunctionDecl
+// CHECK-NEXT:   `-CompoundStmt
+// CHECK-NEXT: `-OMPSectionsDirective
+// CHECK-NEXT:   `-CapturedStmt
+// CHECK-NEXT: `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   |-CompoundStmt
+// CHECK-NEXT:   | |-OMPSectionDirective
+// CHECK-NEXT:   | | `-CapturedStmt
+// CHECK-NEXT:   | |   `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT

[PATCH] D57162: [DEBUG_INFO][NVPTX] Generate correct data about variable address class.

2019-02-01 Thread Paul Robinson via Phabricator via cfe-commits
probinson accepted this revision.
probinson added a comment.
This revision is now accepted and ready to land.
Herald added a project: clang.

LGTM. I'll trust you on the actual address-class values.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57162



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


[PATCH] D57220: Test fix for isViableInline remark message

2019-02-01 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added inline comments.
Herald added a project: clang.



Comment at: test/Frontend/optimization-remark-with-hotness.c:63
   // NO_PGO: '-fdiagnostics-hotness-threshold=' requires profile-guided 
optimization information
   // expected-remark@+1 {{foo inlined into bar with (cost=always): always 
inliner (hotness:}}
   sum += foo(x, x - 2);

What about this line?


Repository:
  rC Clang

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

https://reviews.llvm.org/D57220



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


[PATCH] D57464: Generalize method overloading on addr spaces to C++

2019-02-01 Thread Bevin Hansson via Phabricator via cfe-commits
ebevhan added inline comments.



Comment at: lib/Parse/ParseDeclCXX.cpp:2313
+}
+  }
 

Anastasia wrote:
> ebevhan wrote:
> > Anastasia wrote:
> > > Anastasia wrote:
> > > > ebevhan wrote:
> > > > > Is there a reason that the attributes are parsed here and not in 
> > > > > `ParseFunctionDeclarator` like the rest of the ref-qualifiers (and 
> > > > > the OpenCL++ ASes)?
> > > > > 
> > > > > That is possibly why the parser is getting confused with the trailing 
> > > > > return.
> > > > Good question! I have a feeling that this was done to unify parsing of 
> > > > all CXX members, not just methods. For collecting the method qualifiers 
> > > > it would certainly help making flow more coherent if this was moved to 
> > > > `ParseFunctionDeclarator`. I will try to experiment with this a bit 
> > > > more. What I found strange that the attributes here are attached to the 
> > > > function type itself instead of its  qualifiers. May be @rjmccall can 
> > > > shed some more light on the overall flow...
> > > I looked at this a bit more and it seems that all the GNU attributes 
> > > other than addr spaces belong to the function (not to be applied to 
> > > `this`) for example 
> > > https://blog.timac.org/2016/0716-constructor-and-destructor-attributes/. 
> > > It seems correct to parse them here and apply to the function type. 
> > > Although we could separate parsing of addr space attribute only and move 
> > > into `ParseFunctionDeclarator`.  However this will only be needed for the 
> > > function type not for the data members. So not sure whether it will make 
> > > the flow any cleaner.
> > > I looked at this a bit more and it seems that all the GNU attributes 
> > > other than addr spaces belong to the function (not to be applied to this) 
> > 
> > Hm, I know what you mean. It's why Clang usually complains when you try 
> > placing an AS attribute after a function declarator, because it's trying to 
> > apply it to the function rather than the method qualifiers.
> > 
> > > However this will only be needed for the function type not for the data 
> > > members. 
> > 
> > But we aren't really interested in data members, are we? Like struct 
> > fields, non-static data members cannot be qualified with ASes (they should 
> > 'inherit' the AS from the object type), and static ones should probably 
> > just accept ASes as part of the member type itself.
> > 
> > These patches are to enable AS-qualifiers on methods, so it only stands to 
> > reason that those ASes would be parsed along with the other method 
> > qualifiers.
> > 
> > ParseFunctionDeclarator calls ParseTypeQualifierListOpt to get the 
> > cv-qualifier-seq for the method qualifiers. Currently it's set to 
> > `AR_NoAttributesParsed`. If we enable parsing attributes there, then the 
> > qualifier parsing might 'eat' attributes that were possibly meant for the 
> > function.
> > 
> > This is just a guess, but what I think you could do is include attributes 
> > in the cv-qualifier parsing with `AR_GNUAttributesParsed`, look for any AS 
> > attributes, take their AS and mark them invalid, then move the attributes 
> > (somehow) from the qualifier-DeclSpec to the `FnAttrs` function attribute 
> > list.
> > 
> > (The reason I'm concerned about where/how the qualifiers are parsed is 
> > because this approach only works for custom ASes applied with the GNU 
> > attribute directly. It won't work if custom address spaces are given with a 
> > custom keyword qualifier, like in OpenCL. If the ASes are parsed into the 
> > DeclSpec used for the other ref-qualifiers, then both of these cases should 
> > 'just work'.)
> > But we aren't really interested in data members, are we? Like struct 
> > fields, non-static data members cannot be qualified with ASes (they should 
> > 'inherit' the AS from the object type), and static ones should probably 
> > just accept ASes as part of the member type itself.
>  
> Pointer data members can be qualified by and address space, but this should 
> be parsed before.
> 
> 
> > This is just a guess, but what I think you could do is include attributes 
> > in the cv-qualifier parsing with AR_GNUAttributesParsed, look for any AS 
> > attributes, take their AS and mark them invalid, then move the attributes 
> > (somehow) from the qualifier-DeclSpec to the FnAttrs function attribute 
> > list.
> 
> Ok, I will try that. Thanks for sharing your ideas!
> 
> Pointer data members can be qualified by and address space, but this should 
> be parsed before.

Right, pointer-to-member is a thing. I always forget about those.



Comment at: test/SemaCXX/address-space-method-overloading.cpp:28
+   //inas4.bar();
+   noas.bar(); // expected-error{{call to member function 'bar' is ambiguous}}
+}

Anastasia wrote:
> ebevhan wrote:
> > Just as an aside (I think I mentioned this on one of the earlier patches as 
> > well); treating a non-AS-qualified object as being in a 'generic'

Re: r352055 - Fix failing buildbots

2019-02-01 Thread David Green via cfe-commits
Hello

Sorry for the late reply. I'm not sure this ifdef is quite correct. It will be 
testing the _host_ architecture, presuming the default target is the same. If 
they are different (for example if the default target is aarch64 on an x86 
machine), the test will presumably still fail.

I went looking through the buildbots and I think this hexagon bot builds that 
way:
http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/22699

Got any good suggestions how to fix it?

Thanks,
Dave





Author: martong
Date: Thu Jan 24 07:42:20 2019
New Revision: 352055

URL: http://llvm.org/viewvc/llvm-project?rev=352055&view=rev
Log:
Fix failing buildbots

Related commit which caused the buildbots to fail:
rL352050

Modified:
    cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp

Modified: cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp
URL:  
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp?rev=352055&r1=352054&r2=352055&view=diff
==
--- cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp (original)
+++ cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp Thu Jan 24 07:42:20 
2019
@@ -378,14 +378,17 @@ TEST_F(StructuralEquivalenceFunctionTest
   EXPECT_TRUE(testStructuralMatch(t));
 }
 
+// These calling conventions may not be available on certain platforms.
+#if defined(__x86_64__) && defined(__linux__)
 TEST_F(StructuralEquivalenceFunctionTest,
 FunctionsWithDifferentCallingConventions) {
   auto t = makeNamedDecls(
-  "__attribute__((fastcall)) void foo();",
+  "__attribute__((preserve_all)) void foo();",
   "__attribute__((ms_abi))   void foo();",
   Lang_C);
   EXPECT_FALSE(testStructuralMatch(t));
 }
+#endif
 
 TEST_F(StructuralEquivalenceFunctionTest, FunctionsWithDifferentSavedRegsAttr) 
{
   auto t = makeNamedDecls(


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

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


[PATCH] D46421: [analyzer][CrossTU] Extend CTU to VarDecls with initializer

2019-02-01 Thread Rafael Stahl via Phabricator via cfe-commits
r.stahl added a comment.

Thanks for the comments! All good points. Nice idea with the constructor, but 
that can probably happen in a follow up patch.

In D46421#1380619 , @xazax.hun wrote:

> I know you probably tired of me making you split all the patches but I think 
> if it is independent of CTU we should submit this fix as a separate commit. 
> This way we could be more focused having one commit doing one thing.


No problem if I should do that. However I'm concerned whether this change is 
correct. Previously this was not required since all VarDecls were canonical. 
Not sure if this change was intended. I did some digging, but am not familiar 
enough with the code base to figure out what changed. Does anyone have an idea 
about this?

But I agree that if it wasn't a deliberate change, we could canonicalize in the 
DeclRegion constructor - or VarRegion since only those are redeclarable.


Repository:
  rC Clang

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

https://reviews.llvm.org/D46421



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


[PATCH] D57162: [DEBUG_INFO][NVPTX] Generate correct data about variable address class.

2019-02-01 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D57162#1380795 , @probinson wrote:

> LGTM. I'll trust you on the actual address-class values.


Thanks, Paul! If you want, you can find those values in the table here 
https://docs.nvidia.com/cuda/archive/10.0/ptx-writers-guide-to-interoperability/index.html#cuda-specific-dwarf.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57162



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


[PATCH] D57581: Explicitly add language standard option to test cases that rely on the C++14 default

2019-02-01 Thread Nemanja Ivanovic via Phabricator via cfe-commits
nemanjai added a comment.

In D57581#1380609 , @ilya-biryukov 
wrote:

> ...
>  Do have a comment, though. Any, reason to use `-std=gnu++14` and not 
> `-std=c++14`?
>  Most (all?) of the tests do not seem to have anything to do with the gnu 
> extensions, so why enable them?


I only used `gnu++14` in the test cases to match the current default in clang 
(i.e. not change how clang handles the test case). But I have no problem 
whatsoever with making these standard C++.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57581



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


[PATCH] D57474: Update SanitizerCoverage doc regarding the issue with pc-table and gc-sections.

2019-02-01 Thread Max Moroz via Phabricator via cfe-commits
Dor1s updated this revision to Diff 184766.
Dor1s added a comment.
Herald added a project: clang.

Clarify that only linkers other than LLD are affected.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57474

Files:
  docs/SanitizerCoverage.rst


Index: docs/SanitizerCoverage.rst
===
--- docs/SanitizerCoverage.rst
+++ docs/SanitizerCoverage.rst
@@ -144,6 +144,11 @@
 
 **Experimental, may change or disappear in future**
 
+**Note:** this instrumentation might be incompatible with dead code stripping
+(``-Wl,-gc-sections``) for linkers other than LLD, thus resulting in a
+significant binary size overhead. For more information, see
+`Bug 34636 `_.
+
 With ``-fsanitize-coverage=pc-table`` the compiler will create a table of
 instrumented PCs. Requires either ``-fsanitize-coverage=inline-8bit-counters`` 
or
 ``-fsanitize-coverage=trace-pc-guard``.


Index: docs/SanitizerCoverage.rst
===
--- docs/SanitizerCoverage.rst
+++ docs/SanitizerCoverage.rst
@@ -144,6 +144,11 @@
 
 **Experimental, may change or disappear in future**
 
+**Note:** this instrumentation might be incompatible with dead code stripping
+(``-Wl,-gc-sections``) for linkers other than LLD, thus resulting in a
+significant binary size overhead. For more information, see
+`Bug 34636 `_.
+
 With ``-fsanitize-coverage=pc-table`` the compiler will create a table of
 instrumented PCs. Requires either ``-fsanitize-coverage=inline-8bit-counters`` or
 ``-fsanitize-coverage=trace-pc-guard``.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57474: Update SanitizerCoverage doc regarding the issue with pc-table and gc-sections.

2019-02-01 Thread Max Moroz via Phabricator via cfe-commits
Dor1s marked 2 inline comments as done.
Dor1s added inline comments.



Comment at: docs/SanitizerCoverage.rst:149
+(``-Wl,-gc-sections``), thus resulting in a significant binary size overhead.
+See `Bug 34636 `_ for more info.
+

morehouse wrote:
> Maybe add "for linkers other than LLD".  Dead stripping should work 100% for 
> LLD now.
Thanks, Matt! Done.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57474



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


[PATCH] D57474: Update SanitizerCoverage doc regarding the issue with pc-table and gc-sections.

2019-02-01 Thread Matt Morehouse via Phabricator via cfe-commits
morehouse accepted this revision.
morehouse added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rC Clang

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

https://reviews.llvm.org/D57474



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


[PATCH] D57581: Explicitly add language standard option to test cases that rely on the C++14 default

2019-02-01 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

I agree: if a test doesn't seem to require the GNU extensions, let's not use 
`-std=gnu++XX`.  Otherwise this LGTM.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57581



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


r352887 - Fix some sphinx doc errors.

2019-02-01 Thread James Y Knight via cfe-commits
Author: jyknight
Date: Fri Feb  1 09:06:41 2019
New Revision: 352887

URL: http://llvm.org/viewvc/llvm-project?rev=352887&view=rev
Log:
Fix some sphinx doc errors.

Modified:
cfe/trunk/docs/ClangTools.rst

Modified: cfe/trunk/docs/ClangTools.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ClangTools.rst?rev=352887&r1=352886&r2=352887&view=diff
==
--- cfe/trunk/docs/ClangTools.rst (original)
+++ cfe/trunk/docs/ClangTools.rst Fri Feb  1 09:06:41 2019
@@ -10,8 +10,8 @@ refactoring, etc.
 
 Only a couple of the most basic and fundamental tools are kept in the
 primary Clang tree. The rest of the tools are kept in a separate
-directory tree, ``clang-tools-extra
-``_.
+directory tree, `clang-tools-extra
+`_.
 
 This document describes a high-level overview of the organization of
 Clang Tools within the project as well as giving an introduction to some


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


[PATCH] D57524: Fix ICE on attempt to add an addr space qual to a type qualified by an addr space

2019-02-01 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: lib/Sema/SemaInit.cpp:4693
+T2Quals.addAddressSpace(AS2);
+  QualType WithAScv1T4 = S.Context.getQualifiedType(IgnoreAScv2T2, 
T1Quals);
+  Sequence.AddQualificationConversionStep(WithAScv1T4, ValueKind);

Anastasia wrote:
> rjmccall wrote:
> > `Qualifiers::addQualifiers` should let you do this in a single step.  Also, 
> > you seem to be modifying `T2Quals` here after the last use of it.
> Ok, I will update to use Qualifies methods directly.
> 
> As for `T2Quals` I was thinking it might make sense to restore the original 
> value in case some code later will be added to use it (to prevent bugs)... 
> but may be it's too hypothetical. :)
> 
> Thanks!
That's not unreasonable, but if you're going to do that, you should do it 
unconditionally, not just in a `AS1 != AS2` block — or better yet, make new 
locals for `T1QualsWithoutAS`.


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

https://reviews.llvm.org/D57524



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


[PATCH] D57474: Update SanitizerCoverage doc regarding the issue with pc-table and gc-sections.

2019-02-01 Thread Max Moroz via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Dor1s marked an inline comment as done.
Closed by commit rC352890: Update SanitizerCoverage doc regarding the issue 
with pc-table and gc-sections. (authored by Dor1s, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D57474?vs=184766&id=184770#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D57474

Files:
  docs/SanitizerCoverage.rst


Index: docs/SanitizerCoverage.rst
===
--- docs/SanitizerCoverage.rst
+++ docs/SanitizerCoverage.rst
@@ -144,6 +144,11 @@
 
 **Experimental, may change or disappear in future**
 
+**Note:** this instrumentation might be incompatible with dead code stripping
+(``-Wl,-gc-sections``) for linkers other than LLD, thus resulting in a
+significant binary size overhead. For more information, see
+`Bug 34636 `_.
+
 With ``-fsanitize-coverage=pc-table`` the compiler will create a table of
 instrumented PCs. Requires either ``-fsanitize-coverage=inline-8bit-counters`` 
or
 ``-fsanitize-coverage=trace-pc-guard``.


Index: docs/SanitizerCoverage.rst
===
--- docs/SanitizerCoverage.rst
+++ docs/SanitizerCoverage.rst
@@ -144,6 +144,11 @@
 
 **Experimental, may change or disappear in future**
 
+**Note:** this instrumentation might be incompatible with dead code stripping
+(``-Wl,-gc-sections``) for linkers other than LLD, thus resulting in a
+significant binary size overhead. For more information, see
+`Bug 34636 `_.
+
 With ``-fsanitize-coverage=pc-table`` the compiler will create a table of
 instrumented PCs. Requires either ``-fsanitize-coverage=inline-8bit-counters`` or
 ``-fsanitize-coverage=trace-pc-guard``.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r352055 - Fix failing buildbots

2019-02-01 Thread Gábor Márton via cfe-commits
Hi,

Thank you for catching this. I thought that the macros like __x86_64__ are
defined for the target. I just don't understand: If they are defined for
the host, that would mean we can't cross compile on the same host for
different targets, wouldn't it?

I couldn't find out which macros to use to get the target arch, so I see 2
possible solutions :
1. Create a new test binary for these two small tests and specify
explicitly the target. This seems overwhelming.
2. Simply remove those two test cases. This seems to be the simplest
solution.

Gábor


On Fri, 1 Feb 2019, 17:23 David Green  Hello
>
> Sorry for the late reply. I'm not sure this ifdef is quite correct. It
> will be testing the _host_ architecture, presuming the default target is
> the same. If they are different (for example if the default target is
> aarch64 on an x86 machine), the test will presumably still fail.
>
> I went looking through the buildbots and I think this hexagon bot builds
> that way:
> http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/22699
>
> Got any good suggestions how to fix it?
>
> Thanks,
> Dave
>
>
>
>
>
> Author: martong
> Date: Thu Jan 24 07:42:20 2019
> New Revision: 352055
>
> URL: http://llvm.org/viewvc/llvm-project?rev=352055&view=rev
> Log:
> Fix failing buildbots
>
> Related commit which caused the buildbots to fail:
> rL352050
>
> Modified:
> cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp
>
> Modified: cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp?rev=352055&r1=352054&r2=352055&view=diff
>
> ==
> --- cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp (original)
> +++ cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp Thu Jan 24
> 07:42:20 2019
> @@ -378,14 +378,17 @@ TEST_F(StructuralEquivalenceFunctionTest
>EXPECT_TRUE(testStructuralMatch(t));
>  }
>
> +// These calling conventions may not be available on certain platforms.
> +#if defined(__x86_64__) && defined(__linux__)
>  TEST_F(StructuralEquivalenceFunctionTest,
>  FunctionsWithDifferentCallingConventions) {
>auto t = makeNamedDecls(
> -  "__attribute__((fastcall)) void foo();",
> +  "__attribute__((preserve_all)) void foo();",
>"__attribute__((ms_abi))   void foo();",
>Lang_C);
>EXPECT_FALSE(testStructuralMatch(t));
>  }
> +#endif
>
>  TEST_F(StructuralEquivalenceFunctionTest,
> FunctionsWithDifferentSavedRegsAttr) {
>auto t = makeNamedDecls(
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r352890 - Update SanitizerCoverage doc regarding the issue with pc-table and gc-sections.

2019-02-01 Thread Max Moroz via cfe-commits
Author: dor1s
Date: Fri Feb  1 09:12:35 2019
New Revision: 352890

URL: http://llvm.org/viewvc/llvm-project?rev=352890&view=rev
Log:
Update SanitizerCoverage doc regarding the issue with pc-table and gc-sections.

Summary:
There is a bug for this: https://bugs.llvm.org/show_bug.cgi?id=34636
But it would be also helpful to leave a note in the docs to prevent users from
running into issues, e.g. https://crbug.com/926588.

Reviewers: morehouse

Reviewed By: morehouse

Subscribers: cfe-commits, llvm-commits, kcc

Tags: #clang

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

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=352890&r1=352889&r2=352890&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Fri Feb  1 09:12:35 2019
@@ -144,6 +144,11 @@ PC-Table
 
 **Experimental, may change or disappear in future**
 
+**Note:** this instrumentation might be incompatible with dead code stripping
+(``-Wl,-gc-sections``) for linkers other than LLD, thus resulting in a
+significant binary size overhead. For more information, see
+`Bug 34636 `_.
+
 With ``-fsanitize-coverage=pc-table`` the compiler will create a table of
 instrumented PCs. Requires either ``-fsanitize-coverage=inline-8bit-counters`` 
or
 ``-fsanitize-coverage=trace-pc-guard``.


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


[PATCH] D57592: Replace uses of %T with %t in from previous frontend test differential

2019-02-01 Thread Justice Adams via Phabricator via cfe-commits
justice_adams added a comment.

@stella.stamenova These are the changes from our previous discussion regarding 
the usage of %T


Repository:
  rC Clang

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

https://reviews.llvm.org/D57592



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


[PATCH] D57592: Replace uses of %T with %t in from previous frontend test differential

2019-02-01 Thread Justice Adams via Phabricator via cfe-commits
justice_adams created this revision.
justice_adams added reviewers: stella.stamenova, thakis.
justice_adams added a project: clang.

After committing a change I had made to a few frontend tests, it was pointed 
out to me that %T is being deprecated in LLVM in favor of %t. This change 
simply converts usages of %T to %t while maintaining the integrity of the test.

Previous revision where this discussion took place: 
https://reviews.llvm.org/D50563


Repository:
  rC Clang

https://reviews.llvm.org/D57592

Files:
  test/Frontend/output-failures.c
  test/Frontend/stats-file.c


Index: test/Frontend/stats-file.c
===
--- test/Frontend/stats-file.c
+++ test/Frontend/stats-file.c
@@ -4,5 +4,5 @@
 //  ... here come some json values ...
 // CHECK: }
 
-// RUN: %clang_cc1 -emit-llvm -o %t -stats-file=%T/doesnotexist/bla %s 2>&1 | 
FileCheck -check-prefix=OUTPUTFAIL %s
+// RUN: %clang_cc1 -emit-llvm -o %t -stats-file=%t/doesnotexist/bla %s 2>&1 | 
FileCheck -check-prefix=OUTPUTFAIL %s
 // OUTPUTFAIL: warning: unable to open statistics output file 
'{{.*}}doesnotexist{{.}}bla': '{{[Nn]}}o such file or directory'
Index: test/Frontend/output-failures.c
===
--- test/Frontend/output-failures.c
+++ test/Frontend/output-failures.c
@@ -1,4 +1,4 @@
-// RUN: not %clang_cc1 -emit-llvm -o %T/doesnotexist/somename %s 2> %t
+// RUN: not %clang_cc1 -emit-llvm -o %t/doesnotexist/somename %s 2> %t
 // RUN: FileCheck -check-prefix=OUTPUTFAIL -input-file=%t %s
 
 // OUTPUTFAIL: error: unable to open output file 
'{{.*}}doesnotexist{{.}}somename': '{{[nN]}}o such file or directory'


Index: test/Frontend/stats-file.c
===
--- test/Frontend/stats-file.c
+++ test/Frontend/stats-file.c
@@ -4,5 +4,5 @@
 //  ... here come some json values ...
 // CHECK: }
 
-// RUN: %clang_cc1 -emit-llvm -o %t -stats-file=%T/doesnotexist/bla %s 2>&1 | FileCheck -check-prefix=OUTPUTFAIL %s
+// RUN: %clang_cc1 -emit-llvm -o %t -stats-file=%t/doesnotexist/bla %s 2>&1 | FileCheck -check-prefix=OUTPUTFAIL %s
 // OUTPUTFAIL: warning: unable to open statistics output file '{{.*}}doesnotexist{{.}}bla': '{{[Nn]}}o such file or directory'
Index: test/Frontend/output-failures.c
===
--- test/Frontend/output-failures.c
+++ test/Frontend/output-failures.c
@@ -1,4 +1,4 @@
-// RUN: not %clang_cc1 -emit-llvm -o %T/doesnotexist/somename %s 2> %t
+// RUN: not %clang_cc1 -emit-llvm -o %t/doesnotexist/somename %s 2> %t
 // RUN: FileCheck -check-prefix=OUTPUTFAIL -input-file=%t %s
 
 // OUTPUTFAIL: error: unable to open output file '{{.*}}doesnotexist{{.}}somename': '{{[nN]}}o such file or directory'
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57464: Generalize method overloading on addr spaces to C++

2019-02-01 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: test/SemaCXX/address-space-method-overloading.cpp:28
+   //inas4.bar();
+   noas.bar(); // expected-error{{call to member function 'bar' is ambiguous}}
+}

ebevhan wrote:
> Anastasia wrote:
> > ebevhan wrote:
> > > Just as an aside (I think I mentioned this on one of the earlier patches 
> > > as well); treating a non-AS-qualified object as being in a 'generic' AS 
> > > even for normal C++ isn't a great idea IMO. The object initialization 
> > > code should be checking if the ASes of the actual object and the desired 
> > > object type are compatible, and only if so, permit the overload.
> > I think changing this would require changing AS compatibility rules in 
> > general, not just for overloading but for example for conversions too. This 
> > seems like a wider scope change that might affect backwards compatibility. 
> > We might need to start an RFC on this first. John has suggested adding a 
> > target setting  for this on the other review. I think that should work.  
> > Another idea could be to add some compiler directives to specify what 
> > generic address space is (if any).
> > 
> > Using default (no address space) as generic has a lot of advantages since 
> > it doesn't need many parser changes. In OpenCL we weren't lucky that 
> > initial implementation was added that used default for private memory and 
> > therefore when generic was introduced we had to map it to a new lang addr 
> > space value. That required a lot of changes in the parser. But once we fix 
> > those actually, anyone should be able  to map generic to anything. I 
> > initially thought it has no other use cases than in OpenCL but now I feel 
> > there might be a value to map default case (no address space) for something 
> > specific and then use generic to specify a placeholder address space on 
> > pointers or references. We could just expose generic address space 
> > generically and also have a mode with no generic address space. The latter 
> > means that conversions between different address spaces is never valid. 
> > Would this make sense?
> The big problem with the address space support in Clang is that it isn't 
> really very well formalized unless you're on OpenCL. There's no real way for 
> a target to express the relations between its address spaces; most of the 
> relations that exist are hard-coded.
> 
> The support should probably be generalized for both targets and for LangASes 
> like OpenCL's. Maybe:
> 
> * the ASes would be defined in a TableGen file which specifies which ASes 
> exist, which ones are compatible/subsets/supersets, etc,
> * or, just have a target hook that lets a target express that a conversion 
> from AS A to AS B is prohibited/permitted explicitly/permitted implicitly.
> 
> Just some loose ideas; an RFC for this is possibly the right way forward.
> 
> The reason I bring all of this up is primarily because in our target, the 
> 'default' AS is disjoint from our other ones, so there's no 'generic' AS to 
> be had. Both implicit and explicit conversion between these ASes is 
> prohibited.  Since Clang currently doesn't allow you to express that ASes are 
> truly incompatible, we have a flag that blocks such conversions 
> unconditionally. Ideally it would be target-expressible.
> 
> -
> 
> > I think changing this would require changing AS compatibility rules in 
> > general, not just for overloading but for example for conversions too. This 
> > seems like a wider scope change that might affect backwards compatibility. 
> > We might need to start an RFC on this first. John has suggested adding a 
> > target setting for this on the other review. I think that should work. 
> > Another idea could be to add some compiler directives to specify what 
> > generic address space is (if any).
> 
> I'm unsure whether any changes to the current semantics really need to be 
> done, at least for the overloading problem.
> 
> For example, explicit conversion from a non-address space qualified pointer 
> type to an address space qualified pointer type (and vice versa) is 
> permitted, but implicit conversion is an error in both C and C++: 
> https://godbolt.org/z/UhOC0g
> 
> For an overload candidate to be viable, there has to be an implicit 
> conversion sequence for the implicit object argument to the implicit object 
> parameter type. But no such implicit conversion sequence exists for types in 
> different ASes, even today, or the implicit example in the godbolt would 
> pass. So, an overload candidate with a different AS qualification than the 
> object should not be viable.
> 
> This is clearly not compatible with OpenCL's notion of the `__generic` AS, 
> but OpenCL already has logic for `__generic` in Qualifiers to handle that 
> case (`isAddressSpaceSupersetOf`). Arguably, that behavior should probably 
> not be hard coded, but that's how it is today.
> 
> (Also, just because an AS is a superset of another AS does 

[PATCH] D57592: Replace uses of %T with %t in from previous frontend test differential

2019-02-01 Thread Nico Weber via Phabricator via cfe-commits
thakis accepted this revision.
thakis added a comment.
This revision is now accepted and ready to land.

Normally when needing a directory you'd `mkdir %t.dir` before using it, but 
since you don't' want the directory to exist here this should be good as-is. 
Thanks!


Repository:
  rC Clang

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

https://reviews.llvm.org/D57592



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


[PATCH] D57594: [AST][OpenMP] OpenMP single Construct contains Structured block

2019-02-01 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri created this revision.
lebedev.ri added reviewers: ABataev, OpenMP.
lebedev.ri added projects: clang, OpenMP.
Herald added subscribers: openmp-commits, guansong.

`OpenMP Application Programming Interface Version 5.0 November 2018` 
, 
`2.8.2 single Construct`, starting with page 89:

- The `single` construct specifies that the associated **structured block** is 
executed by only one of the threads in the team (not necessarily the master 
thread), in the context of its implicit task.
- Restrictions • A throw executed inside a `single` region must cause execution 
to resume within the same `single` region, and the same thread that threw the 
exception must catch it.


Repository:
  rC Clang

https://reviews.llvm.org/D57594

Files:
  lib/Sema/SemaOpenMP.cpp
  test/AST/ast-dump-openmp-single.cpp


Index: test/AST/ast-dump-openmp-single.cpp
===
--- /dev/null
+++ test/AST/ast-dump-openmp-single.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -verify -fopenmp -ast-dump %s | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ast-dump %s | FileCheck %s
+// expected-no-diagnostics
+
+void single() {
+#pragma omp single
+  {
+  }
+}
+
+// CHECK:`-FunctionDecl
+// CHECK-NEXT:  `-CompoundStmt
+// CHECK-NEXT:`-OMPSingleDirective
+// CHECK-NEXT:  `-CapturedStmt
+// CHECK-NEXT:`-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:  |-CompoundStmt
+// CHECK-NEXT:  `-ImplicitParamDecl
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -6013,6 +6013,13 @@
 
   assert(isa(AStmt) && "Captured statement expected");
 
+  // 1.2.2 OpenMP Language Terminology
+  // Structured block - An executable statement with a single entry at the
+  // top and a single exit at the bottom.
+  // The point of exit cannot be a branch out of the structured block.
+  // longjmp() and throw() must not violate the entry/exit criteria.
+  cast(AStmt)->getCapturedDecl()->setNothrow();
+
   setFunctionHasBranchProtectedScope();
 
   // OpenMP [2.7.3, single Construct, Restrictions]


Index: test/AST/ast-dump-openmp-single.cpp
===
--- /dev/null
+++ test/AST/ast-dump-openmp-single.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -verify -fopenmp -ast-dump %s | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ast-dump %s | FileCheck %s
+// expected-no-diagnostics
+
+void single() {
+#pragma omp single
+  {
+  }
+}
+
+// CHECK:`-FunctionDecl
+// CHECK-NEXT:  `-CompoundStmt
+// CHECK-NEXT:`-OMPSingleDirective
+// CHECK-NEXT:  `-CapturedStmt
+// CHECK-NEXT:`-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:  |-CompoundStmt
+// CHECK-NEXT:  `-ImplicitParamDecl
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -6013,6 +6013,13 @@
 
   assert(isa(AStmt) && "Captured statement expected");
 
+  // 1.2.2 OpenMP Language Terminology
+  // Structured block - An executable statement with a single entry at the
+  // top and a single exit at the bottom.
+  // The point of exit cannot be a branch out of the structured block.
+  // longjmp() and throw() must not violate the entry/exit criteria.
+  cast(AStmt)->getCapturedDecl()->setNothrow();
+
   setFunctionHasBranchProtectedScope();
 
   // OpenMP [2.7.3, single Construct, Restrictions]
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D16951: [MS ABI] dllimport'd class cannot have constexpr ctors

2019-02-01 Thread Nico Weber via Phabricator via cfe-commits
thakis closed this revision.
thakis added a comment.

David landed a better fix in r260388.


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

https://reviews.llvm.org/D16951



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


[PATCH] D57594: [AST][OpenMP] OpenMP single Construct contains Structured block

2019-02-01 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev accepted this revision.
ABataev added a comment.
This revision is now accepted and ready to land.

LG


Repository:
  rC Clang

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

https://reviews.llvm.org/D57594



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


[PATCH] D46421: [analyzer][CrossTU] Extend CTU to VarDecls with initializer

2019-02-01 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

> Previously this was not required since all VarDecls were canonical. Not sure 
> if this change was intended. I did some digging, but am not familiar enough 
> with the code base to figure out what changed. Does anyone have an idea about 
> this?

We changed the ASTImporter a few months ago to import the redecl chains 
properly. That means we do not squash ever decl into one decl. Also we link a 
newly imported decl to an already existing (found by the lookup). We allow only 
one definition of course. In case of variables we allow only one initializer. 
This way we can preserve the original structure of the AST in the most precise 
way.
I don't think this could be a problem, since we may have redecl chains of 
variables (and other kind of decls) in a single TU too.


Repository:
  rC Clang

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

https://reviews.llvm.org/D46421



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


[PATCH] D57265: [PM/CC1] Add -f[no-]split-cold-code CC1 options to toggle splitting

2019-02-01 Thread Vedant Kumar via Phabricator via cfe-commits
vsk added a comment.

Ping.


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

https://reviews.llvm.org/D57265



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


Re: r352055 - Fix failing buildbots

2019-02-01 Thread David Green via cfe-commits
Hello


I think, because this is a unit-test, the compile will happen for the host 
(x86_64 in this case). So the binary will still be x86_64.


The compile that the test runs will pick up whatever the default target triple 
is (hexagon for the bot, aarch64 for us). I don't know a lot about these tests, 
but I presume that somewhere deep within testStructuralMatch or makeNamedDecls 
it will be picking this up and we can override it?


..


Looking at it now, I think the Args to buildASTFromCodeWithArgs will allow 
specific targets to be used. I'm not sure the best way to get that information 
through to there, but something like this would work:


diff --git a/unittests/AST/StructuralEquivalenceTest.cpp 
b/unittests/AST/StructuralEquivalenceTest.c
index e6c289a..52dba5e 100644
--- a/unittests/AST/StructuralEquivalenceTest.cpp
+++ b/unittests/AST/StructuralEquivalenceTest.cpp
@@ -28,6 +28,7 @@ struct StructuralEquivalenceTest : ::testing::Test {
 this->Code0 = SrcCode0;
 this->Code1 = SrcCode1;
 ArgVector Args = getBasicRunOptionsForLanguage(Lang);
+Args.push_back("--target=x86_64-unknown-linux-gnu");

 const char *const InputFileName = "input.cc";


I wouldn't recommend that, exactly, it would needlessly reduce the testing on 
other targets. And I think for the hexagon target the x86 backend will not even 
be registered I believe. Perhaps just something like this from another 
ASTMatchesNode test, to try and capture the same intent as the ifdefs:


TEST_F(StructuralEquivalenceFunctionTest, FunctionsWithDifferentSavedRegsAttr) {

  if (llvm::Triple(llvm::sys::getDefaultTargetTriple()).getArch() != 
llvm::Triple::x86_64)
return;
  ...


Dave



> Hi,
>
> Thank you for catching this. I thought that the macros like __x86_64__ are 
> defined for the target. I just don't understand: If they are defined for the 
> host, > that would mean we can't cross compile on the same host for different 
> targets, wouldn't it?
>
> I couldn't find out which macros to use to get the target arch, so I see 2 
> possible solutions :
> 1. Create a new test binary for these two small tests and specify explicitly 
> the target. This seems overwhelming.
> 2. Simply remove those two test cases. This seems to be the simplest solution.
>
> Gábor

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


[PATCH] D57592: Replace uses of %T with %t in from previous frontend test differential

2019-02-01 Thread Justice Adams via Phabricator via cfe-commits
justice_adams added a comment.

@thakis thanks for the review. I don't have commit access, would you mind 
committing this for me?


Repository:
  rC Clang

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

https://reviews.llvm.org/D57592



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


[PATCH] D35937: [clang-tidy] Add new readability non-idiomatic static access

2019-02-01 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added a comment.
Herald added subscribers: dkrupp, rnkovacs.
Herald added a project: LLVM.

Please look at recently filed PR40544.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D35937



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


[PATCH] D57532: [Index] Make sure c-index-test finds libc++ on Mac

2019-02-01 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman added a comment.

In D57532#1380383 , @ilya-biryukov 
wrote:

> @arphaman, thanks for pointing this out. It's definitely nice to change stuff 
> only in one place.
>  There are two issues still pending:
>
> - `index-file.cu` still fails, I haven't looked into it closely yet, any idea 
> why that might be happening?; repro is simple, just patch this in locally and 
> run the test.


No idea why it fails, I'll try to take a look.

> - I'm not sure it's safe to use temporary storage for `argv[0]` in 
> `clang_parseTranslationUnit2`. The resulting translation units probably holds 
> references to `argv` and is free to read the data later. A simple and safe 
> alternative would be to store this string in `CIndexer` and return a 
> reference here. Does that LG?

Yes, that would be better. Let's store the string in CIndexer like we do for 
toolchain path and the resource dir.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57532



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


Re: r352055 - Fix failing buildbots

2019-02-01 Thread Gábor Márton via cfe-commits
Dave,

The idea to check explicitly the triple inside the test function is quite
convincing. Will you try to fix it that way? Or if it can wait a bit, this
will be my first thing to do on Monday.

Gábor

On Fri, 1 Feb 2019, 19:39 David Green  Hello
>
>
> I think, because this is a unit-test, the compile will happen for the host
> (x86_64 in this case). So the binary will still be x86_64.
>
>
> The compile that the test runs will pick up whatever the default target
> triple is (hexagon for the bot, aarch64 for us). I don't know a lot about
> these tests, but I presume that somewhere deep within testStructuralMatch
> or makeNamedDecls it will be picking this up and we can override it?
>
>
> ..
>
>
> Looking at it now, I think the Args to buildASTFromCodeWithArgs will
> allow specific targets to be used. I'm not sure the best way to get that
> information through to there, but something like this would work:
>
>
> diff --git a/unittests/AST/StructuralEquivalenceTest.cpp
> b/unittests/AST/StructuralEquivalenceTest.c
> index e6c289a..52dba5e 100644
> --- a/unittests/AST/StructuralEquivalenceTest.cpp
> +++ b/unittests/AST/StructuralEquivalenceTest.cpp
> @@ -28,6 +28,7 @@ struct StructuralEquivalenceTest : ::testing::Test {
>  this->Code0 = SrcCode0;
>  this->Code1 = SrcCode1;
>  ArgVector Args = getBasicRunOptionsForLanguage(Lang);
> +Args.push_back("--target=x86_64-unknown-linux-gnu");
>
>  const char *const InputFileName = "input.cc";
>
>
> I wouldn't recommend that, exactly, it would needlessly reduce the testing
> on other targets. And I think for the hexagon target the x86 backend will
> not even be registered I believe. Perhaps just something like this from
> another ASTMatchesNode test, to try and capture the same intent as the
> ifdefs:
>
> TEST_F(StructuralEquivalenceFunctionTest,
> FunctionsWithDifferentSavedRegsAttr) {
>
>   if (llvm::Triple(llvm::sys::getDefaultTargetTriple()).getArch() !=
> llvm::Triple::x86_64)
> return;
>   ...
>
>
> Dave
>
>
>
> > Hi,
> >
> > Thank you for catching this. I thought that the macros like __x86_64__
> are defined for the target. I just don't understand: If they are defined
> for the host, > that would mean we can't cross compile on the same host
> for different targets, wouldn't it?
> >
> > I couldn't find out which macros to use to get the target arch, so I
> see 2 possible solutions :
> > 1. Create a new test binary for these two small tests and specify
> explicitly the target. This seems overwhelming.
> > 2. Simply remove those two test cases. This seems to be the simplest
> solution.
> >
> > Gábor
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


  1   2   >