date:20180224

[libcxx] r326027 - Cleanup __config indention NFC

2018-02-24 Thread Logan Chien via cfe-commits

Author: logan
Date: Fri Feb 23 23:57:32 2018
New Revision: 326027

URL: http://llvm.org/viewvc/llvm-project?rev=326027&view=rev
Log:
Cleanup __config indention  NFC

This commit indents each level by two space characters, e.g.

#if defined(CONDITION)
#  define _LIBCPP_NAME VALUE
#else
#  define _LIBCPP_NAME VALUE
#endif

The simple #ifndef, #define, and #endif sequences are not indented, e.g.

#ifndef _LIBCPP_NAME
#define _LIBCPP_NAME ...
#endif

Modified:
libcxx/trunk/include/__config

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=326027&r1=326026&r2=326027&view=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Fri Feb 23 23:57:32 2018
@@ -12,9 +12,9 @@
 #define _LIBCPP_CONFIG
 
 #if defined(_MSC_VER) && !defined(__clang__)
-#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
-#define _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER
-#endif
+#  if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#define _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER
+#  endif
 #endif
 
 #ifndef _LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER
@@ -24,13 +24,13 @@
 #ifdef __cplusplus
 
 #ifdef __GNUC__
-#define _GNUC_VER (__GNUC__ * 100 + __GNUC_MINOR__)
+#  define _GNUC_VER (__GNUC__ * 100 + __GNUC_MINOR__)
 // The _GNUC_VER_NEW macro better represents the new GCC versioning scheme
 // introduced in GCC 5.0.
-#define _GNUC_VER_NEW (_GNUC_VER * 10 + __GNUC_PATCHLEVEL__)
+#  define _GNUC_VER_NEW (_GNUC_VER * 10 + __GNUC_PATCHLEVEL__)
 #else
-#define _GNUC_VER 0
-#define _GNUC_VER_NEW 0
+#  define _GNUC_VER 0
+#  define _GNUC_VER_NEW 0
 #endif
 
 #define _LIBCPP_VERSION 7000
@@ -40,63 +40,63 @@
 #endif
 
 #if defined(__ELF__)
-#define _LIBCPP_OBJECT_FORMAT_ELF   1
+#  define _LIBCPP_OBJECT_FORMAT_ELF   1
 #elif defined(__MACH__)
-#define _LIBCPP_OBJECT_FORMAT_MACHO 1
+#  define _LIBCPP_OBJECT_FORMAT_MACHO 1
 #elif defined(_WIN32)
-#define _LIBCPP_OBJECT_FORMAT_COFF  1
+#  define _LIBCPP_OBJECT_FORMAT_COFF  1
 #elif defined(__wasm__)
-#define _LIBCPP_OBJECT_FORMAT_WASM  1
+#  define _LIBCPP_OBJECT_FORMAT_WASM  1
 #else
-#error Unknown object file format
+#  error Unknown object file format
 #endif
 
 #if defined(_LIBCPP_ABI_UNSTABLE) || _LIBCPP_ABI_VERSION >= 2
 // Change short string representation so that string data starts at offset 0,
 // improving its alignment in some cases.
-#define _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
+#  define _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
 // Fix deque iterator type in order to support incomplete types.
-#define _LIBCPP_ABI_INCOMPLETE_TYPES_IN_DEQUE
+#  define _LIBCPP_ABI_INCOMPLETE_TYPES_IN_DEQUE
 // Fix undefined behavior in how std::list stores its linked nodes.
-#define _LIBCPP_ABI_LIST_REMOVE_NODE_POINTER_UB
+#  define _LIBCPP_ABI_LIST_REMOVE_NODE_POINTER_UB
 // Fix undefined behavior in  how __tree stores its end and parent nodes.
-#define _LIBCPP_ABI_TREE_REMOVE_NODE_POINTER_UB
+#  define _LIBCPP_ABI_TREE_REMOVE_NODE_POINTER_UB
 // Fix undefined behavior in how __hash_table stores its pointer types.
-#define _LIBCPP_ABI_FIX_UNORDERED_NODE_POINTER_UB
-#define _LIBCPP_ABI_FORWARD_LIST_REMOVE_NODE_POINTER_UB
-#define _LIBCPP_ABI_FIX_UNORDERED_CONTAINER_SIZE_TYPE
+#  define _LIBCPP_ABI_FIX_UNORDERED_NODE_POINTER_UB
+#  define _LIBCPP_ABI_FORWARD_LIST_REMOVE_NODE_POINTER_UB
+#  define _LIBCPP_ABI_FIX_UNORDERED_CONTAINER_SIZE_TYPE
 // Don't use a nullptr_t simulation type in C++03 instead using C++11 nullptr
 // provided under the alternate keyword __nullptr, which changes the mangling
 // of nullptr_t. This option is ABI incompatible with GCC in C++03 mode.
-#define _LIBCPP_ABI_ALWAYS_USE_CXX11_NULLPTR
+#  define _LIBCPP_ABI_ALWAYS_USE_CXX11_NULLPTR
 // Define the `pointer_safety` enum as a C++11 strongly typed enumeration
 // instead of as a class simulating an enum. If this option is enabled
 // `pointer_safety` and `get_pointer_safety()` will no longer be available
 // in C++03.
-#define _LIBCPP_ABI_POINTER_SAFETY_ENUM_TYPE
+#  define _LIBCPP_ABI_POINTER_SAFETY_ENUM_TYPE
 // Define a key function for `bad_function_call` in the library, to centralize
 // its vtable and typeinfo to libc++ rather than having all other libraries
 // using that class define their own copies.
-#define _LIBCPP_ABI_BAD_FUNCTION_CALL_KEY_FUNCTION
+#  define _LIBCPP_ABI_BAD_FUNCTION_CALL_KEY_FUNCTION
 // Enable optimized version of __do_get_(un)signed which avoids redundant 
copies.
-#define _LIBCPP_ABI_OPTIMIZED_LOCALE_NUM_GET
+#  define _LIBCPP_ABI_OPTIMIZED_LOCALE_NUM_GET
 // Use the smallest possible integer type to represent the index of the 
variant.
 // Previously libc++ used "unsigned int" exclusivly.
-#define _LIBCPP_ABI_VARIANT_INDEX_TYPE_OPTIMIZATION
+#  define _LIBCPP_ABI_VARIANT_INDEX_TYPE_OPTIMIZATION
 #elif _LIBCPP_ABI_VERSION == 1
-#if !defined(_LIBCPP_OBJECT_FORMAT_COFF)
+#  if !defined(_LIBCPP_OBJECT_FORMAT_COFF)
 // Enable compiling copies of now inl

[PATCH] D43696: Reduce hash collisions for reference and pointer types

2018-02-24 Thread Vassil Vassilev via Phabricator via cfe-commits

v.g.vassilev added inline comments.



Comment at: lib/AST/ODRHash.cpp:581
+  void VisitType(const Type *T) {
+ID.AddInteger(T->getTypeClass());
+  }

rtrieu wrote:
> rsmith wrote:
> > This looks redundant, the above `Visit(const Type*)` function seems to 
> > already do this.
> That's correct, VisitType is intended to be empty.  The TypeClass enum value 
> is added in Visit so that it is the first value added to the data stream.
Ok, then I am a little confused. If `VisitType` is supposed to be nop why we 
call it in all VisitXXX functions.


Repository:
  rC Clang

https://reviews.llvm.org/D43696



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

[PATCH] D43731: Fix documentation for SpaceAfterCStyleCast option

2018-02-24 Thread Eric Marti via Phabricator via cfe-commits

EricMarti created this revision.
EricMarti added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

I noticed that the example for SpaceAfterCStyleCast does not match its 
description. I fixed the example after testing it out.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D43731

Files:
  docs/ClangFormatStyleOptions.rst


Index: docs/ClangFormatStyleOptions.rst
===
--- docs/ClangFormatStyleOptions.rst
+++ docs/ClangFormatStyleOptions.rst
@@ -1662,7 +1662,7 @@
   .. code-block:: c++

  true:  false:
- (int)i;vs. (int) i;
+ (int) i;   vs. (int)i;

 **SpaceAfterTemplateKeyword** (``bool``)
   If ``true``, a space will be inserted after the 'template' keyword.


Index: docs/ClangFormatStyleOptions.rst
===
--- docs/ClangFormatStyleOptions.rst
+++ docs/ClangFormatStyleOptions.rst
@@ -1662,7 +1662,7 @@
   .. code-block:: c++

  true:  false:
- (int)i;vs. (int) i;
+ (int) i;   vs. (int)i;

 **SpaceAfterTemplateKeyword** (``bool``)
   If ``true``, a space will be inserted after the 'template' keyword.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43732: Resolve build bot problems in unittests/Format/FormatTest.cpp

2018-02-24 Thread Bjorn Pettersson via Phabricator via cfe-commits

bjope created this revision.
Herald added a subscriber: klimek.

Make the new GetStyleWithEmptyFileName test case independent
of the file system used when running the test. Since the
test is supposed to use the fallback "Google" style we now
use a InMemoryFileSystem to make sure that we do not accidentaly
find a .clang-format file in the real file system. That could
for example happen when having the build directory inside the
llvm och clang repo (as there is a .clang-format file inside
the repos).


Repository:
  rC Clang

https://reviews.llvm.org/D43732

Files:
  unittests/Format/FormatTest.cpp


Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -11724,7 +11724,8 @@
 }
 
 TEST(FormatStyle, GetStyleWithEmptyFileName) {
-  auto Style1 = getStyle("file", "", "Google");
+  vfs::InMemoryFileSystem FS;
+  auto Style1 = getStyle("file", "", "Google", "", &FS);
   ASSERT_TRUE((bool)Style1);
   ASSERT_EQ(*Style1, getGoogleStyle());
 }


Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -11724,7 +11724,8 @@
 }
 
 TEST(FormatStyle, GetStyleWithEmptyFileName) {
-  auto Style1 = getStyle("file", "", "Google");
+  vfs::InMemoryFileSystem FS;
+  auto Style1 = getStyle("file", "", "Google", "", &FS);
   ASSERT_TRUE((bool)Style1);
   ASSERT_EQ(*Style1, getGoogleStyle());
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43590: [clang-format] Fix regression when getStyle() called with empty filename

2018-02-24 Thread Bjorn Pettersson via Phabricator via cfe-commits

bjope added inline comments.



Comment at: unittests/Format/FormatTest.cpp:11727
+TEST(FormatStyle, GetStyleWithEmptyFileName) {
+  auto Style1 = getStyle("file", "", "Google");
+  ASSERT_TRUE((bool)Style1);

bjope wrote:
> Do you really want to try to find a ".clang-format" file here, with fallback 
> to "Google" if no such file is found?
> 
> When I'm building I usually end up having my build directory inside the llvm 
> repo. And since there is a .clang-format file checked in to llvm that file is 
> found, as it searches for a .clang-format file somewhere in the directory 
> structure above the current dir when running the test (if I remember 
> correctly?). We have had such problem before.
> 
> Can't you just as well do
>   auto Style1 = getStyle("Google", "", "Google");
> or is that not triggering the original bug?
> 
> Right now our build bots ends up like this (I guess it has found the 
> .clang-format in my llvm/clang repo and decided to use "LLVM" as format for 
> "Style1"):
> 
> ```
> FAIL: Clang-Unit :: 
> Format/./FormatTests/FormatStyle.GetStyleWithEmptyFileName (14009 of 36611)
>  TEST 'Clang-Unit :: 
> Format/./FormatTests/FormatStyle.GetStyleWithEmptyFileName' FAILED 
> 
> Note: Google Test filter = FormatStyle.GetStyleWithEmptyFileName
> [==] Running 1 test from 1 test case.
> [--] Global test environment set-up.
> [--] 1 test from FormatStyle
> [ RUN  ] FormatStyle.GetStyleWithEmptyFileName
> ../tools/clang/unittests/Format/FormatTest.cpp:11729: Failure
>   Expected: *Style1
>   Which is: 456-byte object  00-00 01-01 01-00 00-00 00-00 04-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 
> 00-00 01-01 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 ... 
> 00-00 00-00 00-00 00-00 01-01 01-00 01-01 6E-53 01-00 00-00 00-00 00-00 01-00 
> 00-00 00-01 00-00 00-00 00-00 01-00 00-00 08-00 00-00 00-00 00-00 10-73 77-01 
> 00-00 00-00 50-73 77-01 00-00 00-00>
> To be equal to: getGoogleStyle()
>   Which is: 456-byte object  00-00 01-01 01-00 00-00 00-00 04-00 00-00 01-01 00-00 00-00 00-00 00-00 00-00 
> 01-01 01-01 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 00-00 ... 
> 38-4A 77-01 00-00 00-00 01-01 01-00 01-01 00-00 01-00 00-00 00-00 00-00 02-00 
> 00-00 00-01 00-00 00-73 77-01 02-00 00-00 08-00 00-00 00-00 00-00 00-00 00-00 
> 00-00 00-00 00-00 00-00 00-00 00-00>
> [  FAILED  ] FormatStyle.GetStyleWithEmptyFileName (1 ms)
> [--] 1 test from FormatStyle (1 ms total)
> 
> [--] Global test environment tear-down
> [==] 1 test from 1 test case ran. (1 ms total)
> [  PASSED  ] 0 tests.
> [  FAILED  ] 1 test, listed below:
> [  FAILED  ] FormatStyle.GetStyleWithEmptyFileName
> 
> ```
> 
I've proposed a fix here: https://reviews.llvm.org/D43732
By using an InMemoryFileSystem to avoid relying on no .clang-format present in 
the path of the real file system when running the test.


Repository:
  rC Clang

https://reviews.llvm.org/D43590



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

[PATCH] D43732: Resolve build bot problems in unittests/Format/FormatTest.cpp

2018-02-24 Thread Bjorn Pettersson via Phabricator via cfe-commits

bjope added a comment.

This is an attempt to fix problems seen after https://reviews.llvm.org/D43590


Repository:
  rC Clang

https://reviews.llvm.org/D43732



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

[PATCH] D41102: Setup clang-doc frontend framework

2018-02-24 Thread Roman Lebedev via Phabricator via cfe-commits

lebedev.ri added a comment.

Thank you for working on this!
Some more thoughts.

Comment at: clang-doc/BitcodeWriter.cpp:191
+  Record.clear();
+  for (const char C : BlockIdNameMap[ID]) Record.push_back(C);
+  Stream.EmitRecord(llvm::bitc::BLOCKINFO_CODE_BLOCKNAME, Record);

Why do we have this indirection?
Is there a need to first to (unefficiently?) copy to `Record`, and then emit 
from there?
Wouldn't this work just as well?
```
Record.clear();
Stream.EmitRecord(llvm::bitc::BLOCKINFO_CODE_BLOCKNAME, BlockIdNameMap[ID]);
```

Comment at: clang-doc/BitcodeWriter.cpp:196
+/// \brief Emits a record name to the BLOCKINFO block.
+void ClangDocBitcodeWriter::emitRecordID(RecordId ID) {
+  assert(RecordIdNameMap[ID] && "Unknown Abbreviation");

Hmm, so i've been staring at this and 
http://llvm.org/doxygen/classllvm_1_1BitstreamWriter.html and i must say i'm 
not fond of this indirection.

What i don't understand is, in previous function, we don't store `BlockId`, why 
do we want to store `RecordId`?
Aren't they both unstable, and are implementation detail?
Do we want to store it (`RecordId`)? If yes, please explain it as a new comment 
in code.

If no, i guess this would work too?
```
assert(RecordIdNameMap[ID] && "Unknown Abbreviation");
Record.clear();
Stream.EmitRecord(llvm::bitc::BLOCKINFO_CODE_SETRECORDNAME, 
RecordIdNameMap[ID].Name);
```
And after that you can lower the default size of `SmallVector<> Record` down 
to, hm, `4`?

Comment at: clang-doc/BitcodeWriter.h:161
+
+  using RecordData = SmallVector;
+

This alias is used exactly once, for `Record` member variable in this class.
Is there any point in having this alias?

Comment at: clang-doc/BitcodeWriter.h:161
+
+  using RecordData = SmallVector;
+

lebedev.ri wrote:
> This alias is used exactly once, for `Record` member variable in this class.
> Is there any point in having this alias?
Also, why is `uint64_t` used?
We either push `char`, or `enum`, or `int`. Do we ever need 64-bit?

Comment at: clang-doc/ClangDoc.h:47
+   bool OmitFilenames)
+  : Mapper(Ctx, ECtx, OmitFilenames){};
+  void HandleTranslationUnit(clang::ASTContext &Context) override {

Please add space before `{}`, and drop unneeded `;`

Comment at: clang-doc/Mapper.h:56
+ private:
+  class ClangDocCommentVisitor
+  : public ConstCommentVisitor {

`ClangDocMapper` class is staring to look like a god-class.
I would recommend:
1. Rename `ClangDocMapper` to `ClangDocASTVisitor`.
 It's kind-of conventional to name `RecursiveASTVisitor`-based classes like 
that.
2. Move `ClangDocCommentVisitor` out of the `ClangDocMapper`, into `namespace 
{}` in `clang-doc/Mapper.cpp`
3. 
  * Split `ClangDocSerializer` into new .h/.cpp
  * Replace `ClangDocSerializer Serializer;` with  `ClangDocSerializer& 
Serializer;`
  * Instantiate `ClangDocSerializer` (in `MapperActionFactory`, i think?) 
before `ClangDocMapper`
  * Pass `ClangDocSerializer&` into `ClangDocMapper` ctor.

https://reviews.llvm.org/D41102

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

r325996 - bpf: Hook target feature "alu32" with LLVM

2018-02-24 Thread Yonghong Song via cfe-commits

Author: yhs
Date: Fri Feb 23 15:55:29 2018
New Revision: 325996

URL: http://llvm.org/viewvc/llvm-project?rev=325996&view=rev
Log:
bpf: Hook target feature "alu32" with LLVM

LLVM has supported a new target feature "alu32" which could be enabled or
disabled by "-mattr=[+|-]alu32" when using llc.

This patch link Clang with it, so it could be also done by passing related
options to Clang, for example:

  -Xclang -target-feature -Xclang +alu32

Signed-off-by: Jiong Wang 
Reviewed-by: Yonghong Song 

Modified:
cfe/trunk/lib/Basic/Targets/BPF.h

Modified: cfe/trunk/lib/Basic/Targets/BPF.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/BPF.h?rev=325996&r1=325995&r2=325996&view=diff
==
--- cfe/trunk/lib/Basic/Targets/BPF.h (original)
+++ cfe/trunk/lib/Basic/Targets/BPF.h Fri Feb 23 15:55:29 2018
@@ -46,7 +46,14 @@ public:
   void getTargetDefines(const LangOptions &Opts,
 MacroBuilder &Builder) const override;
 
-  bool hasFeature(StringRef Feature) const override { return Feature == "bpf"; 
}
+  bool hasFeature(StringRef Feature) const override {
+return Feature == "bpf" || Feature == "alu32";
+  }
+
+  void setFeatureEnabled(llvm::StringMap &Features, StringRef Name,
+ bool Enabled) const override {
+Features[Name] = Enabled;
+  }
 
   ArrayRef getTargetBuiltins() const override { return None; }
 


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

[PATCH] D43581: [clang-tidy/google] Improve the Objective-C global variable declaration check 🔧

2018-02-24 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman accepted this revision.
aaron.ballman added a comment.

This LGTM! Do you need someone to commit on your behalf?


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D43581



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

[PATCH] D41384: [analyzer] Suppress false positive warnings form security.insecureAPI.strcpy

2018-02-24 Thread András Leitereg via Phabricator via cfe-commits

leanil updated this revision to Diff 135795.
leanil marked an inline comment as done.
leanil added a comment.

Use `getTypeSizeInChars` to get array size.


https://reviews.llvm.org/D41384

Files:
  lib/StaticAnalyzer/Checkers/CheckSecuritySyntaxOnly.cpp
  test/Analysis/security-syntax-checks.m


Index: test/Analysis/security-syntax-checks.m
===
--- test/Analysis/security-syntax-checks.m
+++ test/Analysis/security-syntax-checks.m
@@ -146,6 +146,16 @@
   strcpy(x, y); //expected-warning{{Call to function 'strcpy' is insecure as 
it does not provide bounding of the memory buffer. Replace unbounded copy 
functions with analogous functions that support length arguments such as 
'strlcpy'. CWE-119}}
 }
 
+void test_strcpy_2() {
+  char x[4];
+  strcpy(x, "abcd"); //expected-warning{{Call to function 'strcpy' is insecure 
as it does not provide bounding of the memory buffer. Replace unbounded copy 
functions with analogous functions that support length arguments such as 
'strlcpy'. CWE-119}}
+}
+
+void test_strcpy_safe() {
+  char x[5];
+  strcpy(x, "abcd");
+}
+
 //===--===
 // strcat()
 //===--===
Index: lib/StaticAnalyzer/Checkers/CheckSecuritySyntaxOnly.cpp
===
--- lib/StaticAnalyzer/Checkers/CheckSecuritySyntaxOnly.cpp
+++ lib/StaticAnalyzer/Checkers/CheckSecuritySyntaxOnly.cpp
@@ -510,6 +510,17 @@
   if (!checkCall_strCommon(CE, FD))
 return;
 
+  const auto *Target = CE->getArg(0)->IgnoreImpCasts(),
+ *Source = CE->getArg(1)->IgnoreImpCasts();
+  if (const auto *DeclRef = dyn_cast(Target))
+if (const auto *Array = dyn_cast(DeclRef->getType())) {
+  auto ArraySize = BR.getContext().getTypeSizeInChars(Array).getQuantity();
+  if (const auto *String = dyn_cast(Source)) {
+if (ArraySize >= String->getLength() + 1)
+  return;
+  }
+}
+
   // Issue a warning.
   PathDiagnosticLocation CELoc =
 PathDiagnosticLocation::createBegin(CE, BR.getSourceManager(), AC);


Index: test/Analysis/security-syntax-checks.m
===
--- test/Analysis/security-syntax-checks.m
+++ test/Analysis/security-syntax-checks.m
@@ -146,6 +146,16 @@
   strcpy(x, y); //expected-warning{{Call to function 'strcpy' is insecure as it does not provide bounding of the memory buffer. Replace unbounded copy functions with analogous functions that support length arguments such as 'strlcpy'. CWE-119}}
 }
 
+void test_strcpy_2() {
+  char x[4];
+  strcpy(x, "abcd"); //expected-warning{{Call to function 'strcpy' is insecure as it does not provide bounding of the memory buffer. Replace unbounded copy functions with analogous functions that support length arguments such as 'strlcpy'. CWE-119}}
+}
+
+void test_strcpy_safe() {
+  char x[5];
+  strcpy(x, "abcd");
+}
+
 //===--===
 // strcat()
 //===--===
Index: lib/StaticAnalyzer/Checkers/CheckSecuritySyntaxOnly.cpp
===
--- lib/StaticAnalyzer/Checkers/CheckSecuritySyntaxOnly.cpp
+++ lib/StaticAnalyzer/Checkers/CheckSecuritySyntaxOnly.cpp
@@ -510,6 +510,17 @@
   if (!checkCall_strCommon(CE, FD))
 return;
 
+  const auto *Target = CE->getArg(0)->IgnoreImpCasts(),
+ *Source = CE->getArg(1)->IgnoreImpCasts();
+  if (const auto *DeclRef = dyn_cast(Target))
+if (const auto *Array = dyn_cast(DeclRef->getType())) {
+  auto ArraySize = BR.getContext().getTypeSizeInChars(Array).getQuantity();
+  if (const auto *String = dyn_cast(Source)) {
+if (ArraySize >= String->getLength() + 1)
+  return;
+  }
+}
+
   // Issue a warning.
   PathDiagnosticLocation CELoc =
 PathDiagnosticLocation::createBegin(CE, BR.getSourceManager(), AC);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43700: Emit proper CodeView even when not using the cl driver.

2018-02-24 Thread Reid Kleckner via Phabricator via cfe-commits

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

Lgtm

We should go farther, IMO. `clang -g` should default to emitting codeview in an 
MSVC environment.


https://reviews.llvm.org/D43700



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

Re: [libcxx] r324290 - Remove ; use instead. See https://libcxx.llvm.org/TS_deprecation.html

2018-02-24 Thread Marshall Clow via cfe-commits

On Thu, Feb 22, 2018 at 7:06 AM, Nico Weber  wrote:

> Out of interest, do you know why the non-experimental version doesn't have
> to_string()? What are folks supposed to use instead?
>

std::string has an (explicit) constructor from string_view.

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

[PATCH] D43273: [libcxx] [test] Fix MSVC warnings and errors.

2018-02-24 Thread Marshall Clow via Phabricator via cfe-commits

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

LGTM - thanks!


https://reviews.llvm.org/D43273



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

r326036 - Add a C++11 and C2x spelling for the availability attribute in the clang vendor namespace.

2018-02-24 Thread Aaron Ballman via cfe-commits

Author: aaronballman
Date: Sat Feb 24 09:16:42 2018
New Revision: 326036

URL: http://llvm.org/viewvc/llvm-project?rev=326036&view=rev
Log:
Add a C++11 and C2x spelling for the availability attribute in the clang vendor 
namespace.

This attribute has custom parsing rules that previously prevented it from being 
supported with square bracket notation. Rework the clang attribute argument 
parsing to be more easily extended for other custom-parsed attributes.

Added:
cfe/trunk/test/Sema/attr-availability-square-brackets.c
Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/lib/Parse/ParseDecl.cpp

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=326036&r1=326035&r2=326036&view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Sat Feb 24 09:16:42 2018
@@ -673,9 +673,7 @@ def AsmLabel : InheritableAttr {
 }
 
 def Availability : InheritableAttr {
-  // TODO: does not have a [[]] spelling because it requires custom parsing
-  // support.
-  let Spellings = [GNU<"availability">];
+  let Spellings = [Clang<"availability", 1>];
   let Args = [IdentifierArgument<"platform">, VersionArgument<"introduced">,
   VersionArgument<"deprecated">, VersionArgument<"obsoleted">,
   BoolArgument<"unavailable">, StringArgument<"message">,

Modified: cfe/trunk/lib/Parse/ParseDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseDecl.cpp?rev=326036&r1=326035&r2=326036&view=diff
==
--- cfe/trunk/lib/Parse/ParseDecl.cpp (original)
+++ cfe/trunk/lib/Parse/ParseDecl.cpp Sat Feb 24 09:16:42 2018
@@ -404,14 +404,20 @@ unsigned Parser::ParseClangAttributeArgs
   AttributeList::Kind AttrKind =
   AttributeList::getKind(AttrName, ScopeName, Syntax);
 
-  if (AttrKind == AttributeList::AT_ExternalSourceSymbol) {
+  switch (AttrKind) {
+  default:
+return ParseAttributeArgsCommon(AttrName, AttrNameLoc, Attrs, EndLoc,
+ScopeName, ScopeLoc, Syntax);
+  case AttributeList::AT_ExternalSourceSymbol:
 ParseExternalSourceSymbolAttribute(*AttrName, AttrNameLoc, Attrs, EndLoc,
ScopeName, ScopeLoc, Syntax);
-return Attrs.getList() ? Attrs.getList()->getNumArgs() : 0;
+break;
+  case AttributeList::AT_Availability:
+ParseAvailabilityAttribute(*AttrName, AttrNameLoc, Attrs, EndLoc, 
ScopeName,
+   ScopeLoc, Syntax);
+break;
   }
-
-  return ParseAttributeArgsCommon(AttrName, AttrNameLoc, Attrs, EndLoc,
-  ScopeName, ScopeLoc, Syntax);
+  return Attrs.getList() ? Attrs.getList()->getNumArgs() : 0;
 }
 
 bool Parser::ParseMicrosoftDeclSpecArgs(IdentifierInfo *AttrName,

Added: cfe/trunk/test/Sema/attr-availability-square-brackets.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/attr-availability-square-brackets.c?rev=326036&view=auto
==
--- cfe/trunk/test/Sema/attr-availability-square-brackets.c (added)
+++ cfe/trunk/test/Sema/attr-availability-square-brackets.c Sat Feb 24 09:16:42 
2018
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -triple x86_64-apple-darwin9 -fsyntax-only 
-fdouble-square-bracket-attributes -verify %s
+
+void f0() [[clang::availability(macosx,introduced=10.4,deprecated=10.2)]]; // 
expected-warning{{feature cannot be deprecated in macOS version 10.2 before it 
was introduced in version 10.4; attribute ignored}}
+void f1() [[clang::availability(ios,obsoleted=2.1,deprecated=3.0)]];  // 
expected-warning{{feature cannot be obsoleted in iOS version 2.1 before it was 
deprecated in version 3.0; attribute ignored}}
+void f2() [[clang::availability(ios,introduced=2.1,deprecated=2.1)]];
+
+extern void
+ATSFontGetName(const char *oName) 
[[clang::availability(macosx,introduced=8.0,deprecated=9.0, message="use 
CTFontCopyFullName")]]; // expected-note {{'ATSFontGetName' has been explicitly 
marked deprecated here}}
+
+void test_10095131() {
+  ATSFontGetName("Hello"); // expected-warning {{'ATSFontGetName' is 
deprecated: first deprecated in macOS 9.0 - use CTFontCopyFullName}}
+}
+
+enum
+[[clang::availability(macos, unavailable)]]
+{
+NSDataWritingFileProtectionWriteOnly = 0x3000,
+NSDataWritingFileProtectionCompleteUntilUserAuthentication = 0x4000,
+};
+
+extern int x [[clang::availability(macosx,introduced=10.5)]];
+extern int x;
+
+int i [[clang::availability(this, should = 1.0)]]; // expected-error 
{{'should' is not an availability stage; use 'introduced', 'deprecated', or 
'obsoleted'}} \
+   // expected-warning 
{{unknown platform 'this' in availability macro}}


___

[PATCH] D41228: [ObjC] Enable __strong pointers in structs under ARC

2018-02-24 Thread John McCall via Phabricator via cfe-commits

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

Thanks!  This looks ready; thank you for your patience in working this out.




Comment at: include/clang/AST/Type.h:1108
+PCK_ARCStrong,  // objc strong pointer.
+PCK_Struct   // non-trivial C struct.
+  };

ahatanak wrote:
> rjmccall wrote:
> > These should all be /// documentation comments, and they mostly shouldn't 
> > talk about fields since this is a query on QualType, not FieldDecl.  I 
> > would suggest something like:
> > 
> > for Trivial - The type does not fall into any of the following categories.  
> > Note that this case is zero-valued so that values of this enum can be used 
> > as a boolean condition for non-triviality.
> > 
> > for VolatileTrivial - The type would be trivial except that it is 
> > volatile-qualified.  Types that fall into one of the other non-trivial 
> > cases may additionally be volatile-qualified.
> > 
> > for ARCStrong - The type is an Objective-C retainable pointer type that is 
> > qualified with the ARC __strong qualifier.
> > 
> > for Struct - The type is a struct containing a field whose type is not 
> > PCK_Trivial.  Note that a C++ struct type does not necessarily match this; 
> > C++ copying semantics are too complex to express here, in part because they 
> > depend on the exact constructor or assignment operator that is chosen by 
> > overload resolution to do the copy.
> Thanks, I copied your comments verbatim except the comment on PCK_Struct: 
> types that are PCK_Struct have a field that is neither PCK_Trivial nor 
> PCK_VolatileTrivial. We can use the original comment once we start 
> distinguishing PCK_Trivial structs that have volatile fields from those that 
> don't. 
Yes, of course, that makes sense.


https://reviews.llvm.org/D41228



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

r326038 - Add a C++11 and C2x spelling for the objc_bridge_related attribute in the clang vendor namespace.

2018-02-24 Thread Aaron Ballman via cfe-commits

Author: aaronballman
Date: Sat Feb 24 09:37:37 2018
New Revision: 326038

URL: http://llvm.org/viewvc/llvm-project?rev=326038&view=rev
Log:
Add a C++11 and C2x spelling for the objc_bridge_related attribute in the clang 
vendor namespace.

This attribute has custom parsing rules that previously prevented it from being 
supported with square bracket notation.

Added:
cfe/trunk/test/Sema/attr-objc-bridge-related.m
Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/lib/Parse/ParseDecl.cpp

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=326038&r1=326037&r2=326038&view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Sat Feb 24 09:37:37 2018
@@ -1503,9 +1503,7 @@ def ObjCBridgeMutable : InheritableAttr
 }
 
 def ObjCBridgeRelated : InheritableAttr {
-  // TODO: this attribute does not have a [[]] spelling because it requires
-  // custom parsing support.
-  let Spellings = [GNU<"objc_bridge_related">];
+  let Spellings = [Clang<"objc_bridge_related", 1>];
   let Subjects = SubjectList<[Record], ErrorDiag>;
   let Args = [IdentifierArgument<"RelatedClass">,
   IdentifierArgument<"ClassMethod", 1>,

Modified: cfe/trunk/lib/Parse/ParseDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseDecl.cpp?rev=326038&r1=326037&r2=326038&view=diff
==
--- cfe/trunk/lib/Parse/ParseDecl.cpp (original)
+++ cfe/trunk/lib/Parse/ParseDecl.cpp Sat Feb 24 09:37:37 2018
@@ -416,6 +416,10 @@ unsigned Parser::ParseClangAttributeArgs
 ParseAvailabilityAttribute(*AttrName, AttrNameLoc, Attrs, EndLoc, 
ScopeName,
ScopeLoc, Syntax);
 break;
+  case AttributeList::AT_ObjCBridgeRelated:
+ParseObjCBridgeRelatedAttribute(*AttrName, AttrNameLoc, Attrs, EndLoc,
+ScopeName, ScopeLoc, Syntax);
+break;
   }
   return Attrs.getList() ? Attrs.getList()->getNumArgs() : 0;
 }

Added: cfe/trunk/test/Sema/attr-objc-bridge-related.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/attr-objc-bridge-related.m?rev=326038&view=auto
==
--- cfe/trunk/test/Sema/attr-objc-bridge-related.m (added)
+++ cfe/trunk/test/Sema/attr-objc-bridge-related.m Sat Feb 24 09:37:37 2018
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -verify -fsyntax-only -fdouble-square-bracket-attributes %s
+
+struct [[clang::objc_bridge_related(NSParagraphStyle,,)]] TestBridgedRef;
+
+struct [[clang::objc_bridge_related(NSColor,colorWithCGColor:,CGColor)]] 
CGColorRefOk;
+struct [[clang::objc_bridge_related(,colorWithCGColor:,CGColor)]] 
CGColorRef1NotOk; // expected-error {{expected a related ObjectiveC class name, 
e.g., 'NSColor'}}
+struct [[clang::objc_bridge_related(NSColor,colorWithCGColor::,CGColor)]] 
CGColorRef3NotOk; // expected-error {{expected a class method selector with 
single argument, e.g., 'colorWithCGColor:'}}


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

[PATCH] D43430: Omit nullptr check for sufficiently simple delete-expressions

2018-02-24 Thread John McCall via Phabricator via cfe-commits

rjmccall added a comment.

That is an extremely Google-specific analysis, actually; AFAIK almost nobody 
else uses static linking all the way down to and including the C and C++ 
standard libraries unless they're literally building an executable for a 
fully-static environment, like the kernel.  The C and C++ language standards 
state that `operator delete` and `free` are independently overridable by just 
defining those functions outside the stdlib, so they generally cannot be 
resolved as direct calls without the sort of whole-program analysis that the 
linker can only do when linking the final executable.

I think a more reasonable benchmark would be to build a standard Linux 
executable that dynamically links libc and lib{std,}c++, or perhaps something 
with the ADK or Darwin.

I'm quite open to the idea that the right thing to do is just to do this in all 
modes, but I do think we should understand the cost a little better.  (Xcode 
defaults release builds to `-Os`, so in practice my proposal of "-Os or -O0" or 
would enable this by default for almost all builds for us at Apple.)

You can check for -Os by just checking `getCodeGenOpts().OptimizeSize`.

It should be quite easy to collect null-deletion counts by (1) enabling your 
patch and (2) writing an `operator delete` that counts nulls before calling 
`free` and reports that count in a global destructor.  Then you just need to 
pick a C++-heavy program to count them in. :)  Clang compiling 403.gcc isn't an 
unreasonable choice, although LLVM's use of allocation pools does mean that 
we're likely to have fewer `delete` calls than you might think.


Repository:
  rC Clang

https://reviews.llvm.org/D43430



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

[PATCH] D43666: [analyzer] When constructing a temporary without construction context, track it for destruction anyway.

2018-02-24 Thread Devin Coughlin via Phabricator via cfe-commits

dcoughlin added inline comments.



Comment at: lib/StaticAnalyzer/Core/ExprEngine.cpp:2234
+  // should go away, but the assertion should remain, without the
+  // "DidCacheOutOnCleanup" part, of course.
+  bool DidCacheOutOnCleanup = false;

Can you add a comment explaining the criteria under which the 
DidCacheOutOnCleanup part can be removed?



Comment at: lib/StaticAnalyzer/Core/ExprEngine.cpp:2257
+  } else {
+Pred = *CleanUpTemporaries.begin();
+  }

I realize this isn't new code in this patch, but can you use the result of 
Bldr.generateNode() to determine whether we cached out and also to get the new 
Pred? That seems cleaner than querying the ExplodedNodeSet.



Comment at: lib/StaticAnalyzer/Core/ExprEngine.cpp:2262
+  assert(DidCacheOutOnCleanup ||
+ areInitializedTemporariesClear(Pred->getState(),
 Pred->getLocationContext(),

It sounds like this means if we did cache out then there are places where the 
initialized temporaries are not cleared (that is, we have extra gunk in the 
state that we don't want).

Is that true? If so, then this relaxation of the assertion doesn't seem right 
to me.

Do we need to introduce a new program point when calling `Bldr.generateNode` on 
the cleaned up state (for example, with a new tag or a new program point kind)? 
This would make it so that when we cache out when generating a node for the 
state with the cleaned up temporaries we know that it is safe to early return 
from processEndOfFunction(). It would be safe because we would know that the 
other node (the one we cached out because of) has already had its temporaries 
cleared and notified the checkers about the end of the function, etc.







Repository:
  rC Clang

https://reviews.llvm.org/D43666



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

r326039 - [X86] Remove some masked cvt builtins that can be replaced with legacy sse/avx buiiltins and a select.

2018-02-24 Thread Craig Topper via cfe-commits

Author: ctopper
Date: Sat Feb 24 10:55:13 2018
New Revision: 326039

URL: http://llvm.org/viewvc/llvm-project?rev=326039&view=rev
Log:
[X86] Remove some masked cvt builtins that can be replaced with legacy sse/avx 
buiiltins and a select.

Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/lib/Headers/avx512vlintrin.h
cfe/trunk/test/CodeGen/avx512vl-builtins.c

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=326039&r1=326038&r2=326039&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Sat Feb 24 10:55:13 2018
@@ -1195,26 +1195,15 @@ TARGET_BUILTIN(__builtin_ia32_compressst
 TARGET_BUILTIN(__builtin_ia32_compressstoresf256_mask, "vV8f*V8fUc", "", 
"avx512vl")
 TARGET_BUILTIN(__builtin_ia32_compressstoresi128_mask, "vV4i*V4iUc", "", 
"avx512vl")
 TARGET_BUILTIN(__builtin_ia32_compressstoresi256_mask, "vV8i*V8iUc", "", 
"avx512vl")
-TARGET_BUILTIN(__builtin_ia32_cvtdq2ps128_mask, "V4fV4iV4fUc", "", "avx512vl")
-TARGET_BUILTIN(__builtin_ia32_cvtdq2ps256_mask, "V8fV8iV8fUc", "", "avx512vl")
 TARGET_BUILTIN(__builtin_ia32_cvtpd2dq128_mask, "V4iV2dV4iUc", "", "avx512vl")
-TARGET_BUILTIN(__builtin_ia32_cvtpd2dq256_mask, "V4iV4dV4iUc", "", "avx512vl")
 TARGET_BUILTIN(__builtin_ia32_cvtpd2ps_mask, "V4fV2dV4fUc", "", "avx512vl")
-TARGET_BUILTIN(__builtin_ia32_cvtpd2ps256_mask, "V4fV4dV4fUc", "", "avx512vl")
 TARGET_BUILTIN(__builtin_ia32_cvtpd2udq128_mask, "V4iV2dV4iUc", "", "avx512vl")
 TARGET_BUILTIN(__builtin_ia32_cvtpd2udq256_mask, "V4iV4dV4iUc", "", "avx512vl")
-TARGET_BUILTIN(__builtin_ia32_cvtps2dq128_mask, "V4iV4fV4iUc", "", "avx512vl")
-TARGET_BUILTIN(__builtin_ia32_cvtps2dq256_mask, "V8iV8fV8iUc", "", "avx512vl")
-TARGET_BUILTIN(__builtin_ia32_cvtps2pd128_mask, "V2dV4fV2dUc", "", "avx512vl")
-TARGET_BUILTIN(__builtin_ia32_cvtps2pd256_mask, "V4dV4fV4dUc", "", "avx512vl")
 TARGET_BUILTIN(__builtin_ia32_cvtps2udq128_mask, "V4iV4fV4iUc", "", "avx512vl")
 TARGET_BUILTIN(__builtin_ia32_cvtps2udq256_mask, "V8iV8fV8iUc", "", "avx512vl")
 TARGET_BUILTIN(__builtin_ia32_cvttpd2dq128_mask, "V4iV2dV4iUc", "", "avx512vl")
-TARGET_BUILTIN(__builtin_ia32_cvttpd2dq256_mask, "V4iV4dV4iUc", "", "avx512vl")
 TARGET_BUILTIN(__builtin_ia32_cvttpd2udq128_mask, "V4iV2dV4iUc", "", 
"avx512vl")
 TARGET_BUILTIN(__builtin_ia32_cvttpd2udq256_mask, "V4iV4dV4iUc", "", 
"avx512vl")
-TARGET_BUILTIN(__builtin_ia32_cvttps2dq128_mask, "V4iV4fV4iUc", "", "avx512vl")
-TARGET_BUILTIN(__builtin_ia32_cvttps2dq256_mask, "V8iV8fV8iUc", "", "avx512vl")
 TARGET_BUILTIN(__builtin_ia32_cvttps2udq128_mask, "V4iV4fV4iUc", "", 
"avx512vl")
 TARGET_BUILTIN(__builtin_ia32_cvttps2udq256_mask, "V8iV8fV8iUc", "", 
"avx512vl")
 TARGET_BUILTIN(__builtin_ia32_cvtudq2ps128_mask, "V4fV4iV4fUc", "", "avx512vl")

Modified: cfe/trunk/lib/Headers/avx512vlintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/avx512vlintrin.h?rev=326039&r1=326038&r2=326039&view=diff
==
--- cfe/trunk/lib/Headers/avx512vlintrin.h (original)
+++ cfe/trunk/lib/Headers/avx512vlintrin.h Sat Feb 24 10:55:13 2018
@@ -1785,32 +1785,30 @@ _mm256_maskz_cvtepi32_pd (__mmask8 __U,
 
 static __inline__ __m128 __DEFAULT_FN_ATTRS
 _mm_mask_cvtepi32_ps (__m128 __W, __mmask8 __U, __m128i __A) {
-  return (__m128) __builtin_ia32_cvtdq2ps128_mask ((__v4si) __A,
-   (__v4sf) __W,
-   (__mmask8) __U);
+  return (__m128)__builtin_ia32_selectps_128((__mmask8)__U,
+ (__v4sf)_mm_cvtepi32_ps(__A),
+ (__v4sf)__W);
 }
 
 static __inline__ __m128 __DEFAULT_FN_ATTRS
 _mm_maskz_cvtepi32_ps (__mmask16 __U, __m128i __A) {
-  return (__m128) __builtin_ia32_cvtdq2ps128_mask ((__v4si) __A,
-   (__v4sf)
-   _mm_setzero_ps (),
-   (__mmask8) __U);
+  return (__m128)__builtin_ia32_selectps_128((__mmask8)__U,
+ (__v4sf)_mm_cvtepi32_ps(__A),
+ (__v4sf)_mm_setzero_ps());
 }
 
 static __inline__ __m256 __DEFAULT_FN_ATTRS
 _mm256_mask_cvtepi32_ps (__m256 __W, __mmask8 __U, __m256i __A) {
-  return (__m256) __builtin_ia32_cvtdq2ps256_mask ((__v8si) __A,
-   (__v8sf) __W,
-   (__mmask8) __U);
+  return (__m256)__builtin_ia32_selectps_256((__mmask8)__U,
+ (__v8sf)_mm256_cvtepi32_ps(__A),
+ (__v8sf)__W);
 }
 
 static __inline__ __m256 __DEFAULT_FN_ATTRS
 _mm256_maskz_cvtepi32_ps (__mmask16 __U, __m256i __A) {
-  return (__m256) __builtin_ia32_cvtdq2ps256_mask ((__v8si) __A,
-   (__v8sf)
-   _mm256_setzero_ps

[PATCH] D43689: [analyzer] Disable constructor inlining when lifetime extension through fields occurs.

2018-02-24 Thread Devin Coughlin via Phabricator via cfe-commits

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



Comment at: include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h:70
+/// by binding a smaller object within it to a reference.
+bool IsTemporaryLifetimeExtendedViaSubobject = false;
 

Would you be willing to add a tiny code example to the comment? I.e., `const 
int &x = C().x`



Comment at: lib/StaticAnalyzer/Core/ExprEngineCXX.cpp:177
+  assert(VD->getType()->isReferenceType());
+  if (VD->getType()->getPointeeType().getCanonicalType() !=
+  MTE->GetTemporaryExpr()->getType().getCanonicalType()) {

I *think* this is safe. But it seems like it would be more direct to use 
skipRValueSubobjectAdjustments() and check for sub-object adjustments since 
ultimately that is what you care about, right?


Repository:
  rC Clang

https://reviews.llvm.org/D43689



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

[PATCH] D43714: [analyzer] Don't do anything when trivial-copying an empty class object.

2018-02-24 Thread Devin Coughlin via Phabricator via cfe-commits

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

LGTM.


https://reviews.llvm.org/D43714



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

[PATCH] D43671: [clangd] Address FIXME and fix comment

2018-02-24 Thread Eric Liu via Phabricator via cfe-commits

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

Oops, just realized I forgot to push the "send" button!




Comment at: clangd/tool/ClangdMain.cpp:153
+  if (RunSynchronously) {
+if (WorkerThreadsCount.getNumOccurrences()) {
+  llvm::errs() << "-j option will be ignored because -run-synchronously is 
"

nit: no need for braces around one liners.

To make this an real one line, maybe `"Ignoring -j because -run-synchronously 
is set.\n"`?


https://reviews.llvm.org/D43671



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

[PATCH] D43689: [analyzer] Disable constructor inlining when lifetime extension through fields occurs.

2018-02-24 Thread Artem Dergachev via Phabricator via cfe-commits

NoQ added inline comments.

Comment at: lib/StaticAnalyzer/Core/ExprEngineCXX.cpp:177
+  assert(VD->getType()->isReferenceType());
+  if (VD->getType()->getPointeeType().getCanonicalType() !=
+  MTE->GetTemporaryExpr()->getType().getCanonicalType()) {

dcoughlin wrote:
> I *think* this is safe. But it seems like it would be more direct to use 
> skipRValueSubobjectAdjustments() and check for sub-object adjustments since 
> ultimately that is what you care about, right?
> skipRValueSubobjectAdjustments()

This function doesn't do anything anymore (since rC288563) (in most cases, at 
least). We now have lvalue sub-objects adjustments that are outside of 
`MaterializeTemporaryExpr`, and i'm trying to see if there are any by comparing 
the variable type with the temporary type. If there are still any rvalue 
sub-object adjustments present in the AST, then i'd have to skip them, as an 
additional step.

Repository:
  rC Clang

https://reviews.llvm.org/D43689

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

[PATCH] D43734: [RecordLayout] Don't align to non-power-of-2 sizes when using -mms-bitfields

2018-02-24 Thread Martin Storsjö via Phabricator via cfe-commits

mstorsjo created this revision.
mstorsjo added reviewers: compnerd, rnk, majnemer.

When targeting GNU/MinGW for i386, the size of the "long double" data type is 
12 bytes (while it is 8 bytes in MSVC). When building
with -mms-bitfields to have struct layouts match MSVC, data types are laid out 
in a struct with alignment according to their size. However, this doesn't make 
sense for the long double type, since it doesn't match MSVC at all, and 
aligning to a non-power-of-2 size triggers other asserts later.

This matches what GCC does, aligning a long double to 4 bytes in structs on 
i386 even when -mms-bitfields is specified.

This fixes asserts when using the max_align_t data type when building for 
MinGW/i386 with the -mms-bitfields flag.


Repository:
  rC Clang

https://reviews.llvm.org/D43734

Files:
  lib/AST/RecordLayoutBuilder.cpp
  test/CodeGen/mingw-long-double.c


Index: test/CodeGen/mingw-long-double.c
===
--- test/CodeGen/mingw-long-double.c
+++ test/CodeGen/mingw-long-double.c
@@ -1,5 +1,7 @@
 // RUN: %clang_cc1 -triple i686-windows-gnu -emit-llvm -o - %s \
 // RUN:| FileCheck %s --check-prefix=GNU32
+// RUN: %clang_cc1 -triple i686-windows-gnu -emit-llvm -o - %s -mms-bitfields \
+// RUN:| FileCheck %s --check-prefix=GNU32
 // RUN: %clang_cc1 -triple x86_64-windows-gnu -emit-llvm -o - %s \
 // RUN:| FileCheck %s --check-prefix=GNU64
 // RUN: %clang_cc1 -triple x86_64-windows-msvc -emit-llvm -o - %s \
Index: lib/AST/RecordLayoutBuilder.cpp
===
--- lib/AST/RecordLayoutBuilder.cpp
+++ lib/AST/RecordLayoutBuilder.cpp
@@ -1752,7 +1752,8 @@
   QualType T = Context.getBaseElementType(D->getType());
   if (const BuiltinType *BTy = T->getAs()) {
 CharUnits TypeSize = Context.getTypeSizeInChars(BTy);
-if (TypeSize > FieldAlign)
+if (TypeSize > FieldAlign &&
+llvm::isPowerOf2_64(TypeSize.getQuantity()))
   FieldAlign = TypeSize;
   }
 }


Index: test/CodeGen/mingw-long-double.c
===
--- test/CodeGen/mingw-long-double.c
+++ test/CodeGen/mingw-long-double.c
@@ -1,5 +1,7 @@
 // RUN: %clang_cc1 -triple i686-windows-gnu -emit-llvm -o - %s \
 // RUN:| FileCheck %s --check-prefix=GNU32
+// RUN: %clang_cc1 -triple i686-windows-gnu -emit-llvm -o - %s -mms-bitfields \
+// RUN:| FileCheck %s --check-prefix=GNU32
 // RUN: %clang_cc1 -triple x86_64-windows-gnu -emit-llvm -o - %s \
 // RUN:| FileCheck %s --check-prefix=GNU64
 // RUN: %clang_cc1 -triple x86_64-windows-msvc -emit-llvm -o - %s \
Index: lib/AST/RecordLayoutBuilder.cpp
===
--- lib/AST/RecordLayoutBuilder.cpp
+++ lib/AST/RecordLayoutBuilder.cpp
@@ -1752,7 +1752,8 @@
   QualType T = Context.getBaseElementType(D->getType());
   if (const BuiltinType *BTy = T->getAs()) {
 CharUnits TypeSize = Context.getTypeSizeInChars(BTy);
-if (TypeSize > FieldAlign)
+if (TypeSize > FieldAlign &&
+llvm::isPowerOf2_64(TypeSize.getQuantity()))
   FieldAlign = TypeSize;
   }
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43734: [RecordLayout] Don't align to non-power-of-2 sizes when using -mms-bitfields

2018-02-24 Thread Saleem Abdulrasool via Phabricator via cfe-commits

compnerd added inline comments.



Comment at: lib/AST/RecordLayoutBuilder.cpp:1755
 CharUnits TypeSize = Context.getTypeSizeInChars(BTy);
-if (TypeSize > FieldAlign)
+if (TypeSize > FieldAlign &&
+llvm::isPowerOf2_64(TypeSize.getQuantity()))

Can you add an assertion that the size is a power of two unless it is the GNU 
environment?


Repository:
  rC Clang

https://reviews.llvm.org/D43734



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

[PATCH] D43281: [AMDGPU] fixes for lds f32 builtins

2018-02-24 Thread Daniil Fukalov via Phabricator via cfe-commits

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

ping...


https://reviews.llvm.org/D43281



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

Re: [libcxx] r323971 - Remove ; use instead. See https://libcxx.llvm.org/TS_deprecation.html

2018-02-24 Thread Marshall Clow via cfe-commits

On Thu, Feb 22, 2018 at 7:58 AM, Nico Weber  wrote:

> I have a small personal project where I used to use this. I tried
> switching to  instead, but that apparently requires -std=c++17.
> With that, things build fine with my locally-built clang, but latest Xcode
> clang doesn't accept that flag yet. So I tried -std=c++1z, but latest Xcode
> (9.2) doesn't even include the  header yet. So now I have no way
> of being able to build my project with both trunk clang and Xcode clang.
> Maybe a one-year deprecation period is too short?
>

Nico --

I'm sorry you were caught out by this.

(It's not a huge deal, I have a optional<> implementation in my project for
> platforms that don't ship it yet, but things used to be fine on mac until
> this change at least. It's also not an important project, I just thought
> I'd point out that this makes life more complicated than it would be if the
> deletion period was longer.)
>

Yes, but it also makes life less complicated also.

In fact, optional was the poster child for removing stuff from experimental.
experimental::optional and std::optional have diverged, and are
significantly different today (and only going to get more different in the
future)

The cost for someone to move to std::optional will never be lower than it
is now. (they're only going to become more different).

I really didn't (and don't) want to maintain two closely related (but
different, and slowly diverging) code bases - and (repeatedly) explain to
people the difference between them.

As for Apple not shipping std::optional, I too am dismayed by that, but I
have no control over that. :-(  I don't know when Apple will ship
std::optional (they don't share their product plans with me), but it
requires an update to libc++.dylib, and in the past they have gone *years*
without updating the dylib.   Hopefully they will update before LLVM 7
ships in August.

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

[PATCH] D43581: [clang-tidy/google] Improve the Objective-C global variable declaration check 🔧

2018-02-24 Thread Stephane Moore via Phabricator via cfe-commits

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

In https://reviews.llvm.org/D43581#1018499, @aaron.ballman wrote:

> This LGTM! Do you need someone to commit on your behalf?


I would be happy to commit assuming that I am able to and can meet submission 
requirements.

I see a "Submit" button in Phabricator that I assume will land the commit if I 
press it?

I found some submission guidelines in the LLVM Developer Policy 
. Are there any other submission 
guidelines I should follow?

I ran the LLVM and Clang regression tests (by running `make check-all` from my 
LLVM build directory) and I encountered a failure in "Bindings/Go/go.test":

   TEST 'LLVM :: Bindings/Go/go.test' FAILED 

  Script:
  --
  /Users/mog/projects/llvm-build/bin/llvm-go go=/usr/local/go/bin/go test 
llvm.org/llvm/bindings/go/llvm
  --
  Exit Code: 1
  
  Command Output (stdout):
  --
  FAIL  llvm.org/llvm/bindings/go/llvm [build failed]
  
  --
  Command Output (stderr):
  --
  # llvm.org/llvm/bindings/go/llvm
  In file included from 
/var/folders/qh/4y215hgd4zqg30v9q04czw58005k3k/T/lit_tmp_7sZYWR/gopath735545420/src/llvm.org/llvm/bindings/go/llvm/analysis.go:17:
  In file included from /Users/mog/projects/llvm/include/llvm-c/Analysis.h:22:
  In file included from /Users/mog/projects/llvm/include/llvm-c/Types.h:17:
  /Users/mog/projects/llvm-build/include/llvm/Support/DataTypes.h:35:10: fatal 
error: 'math.h' file not found
  #include 
   ^~~~
  1 error generated.
  
  --
  
  

I reran these tests on a clean checkout and I still encountered the failure so 
I presume that this failure is unrelated?

I have also been trying to run the `test-suite` but I have been encountering 
Python exceptions while trying to run `lnt` 😕.

If someone wants to submit on my behalf that works for me. If not, I can also 
continue trying to drive this myself (though verification of submission 
requirements would be helpful in that case).


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D43581



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

[PATCH] D43581: [clang-tidy/google] Improve the Objective-C global variable declaration check 🔧

2018-02-24 Thread Yan Zhang via Phabricator via cfe-commits

Wizard added a comment.

In https://reviews.llvm.org/D43581#1018584, @stephanemoore wrote:

> In https://reviews.llvm.org/D43581#1018499, @aaron.ballman wrote:
>
> > This LGTM! Do you need someone to commit on your behalf?
>
>
> I would be happy to commit assuming that I am able to and can meet submission 
> requirements.
>
> I see a "Submit" button in Phabricator that I assume will land the commit if 
> I press it?
>
> I found some submission guidelines in the LLVM Developer Policy 
> . Are there any other submission 
> guidelines I should follow?
>
> I ran the LLVM and Clang regression tests (by running `make check-all` from 
> my LLVM build directory) and I encountered a failure in "Bindings/Go/go.test":
>
>    TEST 'LLVM :: Bindings/Go/go.test' FAILED 
> 
>   Script:
>   --
>   /Users/mog/projects/llvm-build/bin/llvm-go go=/usr/local/go/bin/go test 
> llvm.org/llvm/bindings/go/llvm
>   --
>   Exit Code: 1
>  
>   Command Output (stdout):
>   --
>   FAILllvm.org/llvm/bindings/go/llvm [build failed]
>  
>   --
>   Command Output (stderr):
>   --
>   # llvm.org/llvm/bindings/go/llvm
>   In file included from 
> /var/folders/qh/4y215hgd4zqg30v9q04czw58005k3k/T/lit_tmp_7sZYWR/gopath735545420/src/llvm.org/llvm/bindings/go/llvm/analysis.go:17:
>   In file included from /Users/mog/projects/llvm/include/llvm-c/Analysis.h:22:
>   In file included from /Users/mog/projects/llvm/include/llvm-c/Types.h:17:
>   /Users/mog/projects/llvm-build/include/llvm/Support/DataTypes.h:35:10: 
> fatal error: 'math.h' file not found
>   #include 
>^~~~
>   1 error generated.
>  
>   --
>  
>   
>
>
> I reran these tests on a clean checkout and I still encountered the failure 
> so I presume that this failure is unrelated?
>
> I have also been trying to run the `test-suite` but I have been encountering 
> Python exceptions while trying to run `lnt` 😕.
>
> If someone wants to submit on my behalf that works for me. If not, I can also 
> continue trying to drive this myself (though verification of submission 
> requirements would be helpful in that case).


You may wanna follow this 
http://llvm.org/docs/Phabricator.html#git-svn-and-arcanist to submit your 
changes. But as aaron.ballman@ mentioned, you may need someone who has acl to 
commit it for you. 
For the error you see it is likely because you only updated the tools/extra 
repo. Usually when we sync this repo, we will have to pull parent repos as well 
(i.e. clang repo and llvm repo).


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D43581



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

r326045 - [RISCV] Enable __int128_t and __uint128_t through clang flag

2018-02-24 Thread Mandeep Singh Grang via cfe-commits

Author: mgrang
Date: Sat Feb 24 19:58:23 2018
New Revision: 326045

URL: http://llvm.org/viewvc/llvm-project?rev=326045&view=rev
Log:
[RISCV] Enable __int128_t and __uint128_t through clang flag

Summary:
If the flag -fforce-enable-int128 is passed, it will enable support for 
__int128_t and __uint128_t types.
This flag can then be used to build compiler-rt for RISCV32.

Reviewers: asb, kito-cheng, apazos, efriedma

Reviewed By: asb, efriedma

Subscribers: shiva0217, efriedma, jfb, dschuff, sdardis, sbc100, 
jgravelle-google, aheejin, rbar, johnrusso, simoncook, jordy.potman.lists, 
sabuasal, niosHD, cfe-commits

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

Added:
cfe/trunk/test/Driver/types.c
Modified:
cfe/trunk/include/clang/Basic/TargetInfo.h
cfe/trunk/include/clang/Basic/TargetOptions.h
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/lib/Basic/Targets/Mips.h
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/CodeGen/riscv32-abi.c
cfe/trunk/test/Preprocessor/init.c

Modified: cfe/trunk/include/clang/Basic/TargetInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/TargetInfo.h?rev=326045&r1=326044&r2=326045&view=diff
==
--- cfe/trunk/include/clang/Basic/TargetInfo.h (original)
+++ cfe/trunk/include/clang/Basic/TargetInfo.h Sat Feb 24 19:58:23 2018
@@ -358,7 +358,7 @@ public:
 
   /// \brief Determine whether the __int128 type is supported on this target.
   virtual bool hasInt128Type() const {
-return getPointerWidth(0) >= 64;
+return (getPointerWidth(0) >= 64) || getTargetOpts().ForceEnableInt128;
   } // FIXME
 
   /// \brief Determine whether the __float128 type is supported on this target.

Modified: cfe/trunk/include/clang/Basic/TargetOptions.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/TargetOptions.h?rev=326045&r1=326044&r2=326045&view=diff
==
--- cfe/trunk/include/clang/Basic/TargetOptions.h (original)
+++ cfe/trunk/include/clang/Basic/TargetOptions.h Sat Feb 24 19:58:23 2018
@@ -60,6 +60,9 @@ public:
   /// \brief The list of OpenCL extensions to enable or disable, as written on
   /// the command line.
   std::vector OpenCLExtensionsAsWritten;
+
+  /// \brief If given, enables support for __int128_t and __uint128_t types.
+  bool ForceEnableInt128;
 };
 
 }  // end namespace clang

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=326045&r1=326044&r2=326045&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Sat Feb 24 19:58:23 2018
@@ -849,6 +849,12 @@ def fno_signaling_math : Flag<["-"], "fn
 def fjump_tables : Flag<["-"], "fjump-tables">, Group;
 def fno_jump_tables : Flag<["-"], "fno-jump-tables">, Group, 
Flags<[CC1Option]>,
   HelpText<"Do not use jump tables for lowering switches">;
+def fforce_enable_int128 : Flag<["-"], "fforce-enable-int128">,
+  Group, Flags<[CC1Option]>,
+  HelpText<"Enable support for int128_t type">;
+def fno_force_enable_int128 : Flag<["-"], "fno-force-enable-int128">,
+  Group, Flags<[CC1Option]>,
+  HelpText<"Disable support for int128_t type">;
 
 // Begin sanitizer flags. These should all be core options exposed in all 
driver
 // modes.

Modified: cfe/trunk/lib/Basic/Targets/Mips.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/Mips.h?rev=326045&r1=326044&r2=326045&view=diff
==
--- cfe/trunk/lib/Basic/Targets/Mips.h (original)
+++ cfe/trunk/lib/Basic/Targets/Mips.h Sat Feb 24 19:58:23 2018
@@ -392,7 +392,9 @@ public:
 return llvm::makeArrayRef(NewABIRegAliases);
   }
 
-  bool hasInt128Type() const override { return ABI == "n32" || ABI == "n64"; }
+  bool hasInt128Type() const override {
+return (ABI == "n32" || ABI == "n64") || getTargetOpts().ForceEnableInt128;
+  }
 
   bool validateTarget(DiagnosticsEngine &Diags) const override;
 };

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=326045&r1=326044&r2=326045&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Sat Feb 24 19:58:23 2018
@@ -4750,6 +4750,12 @@ void Clang::ConstructJob(Compilation &C,
 }
   }
 
+  if (Arg *A = Args.getLastArg(options::OPT_fforce_enable_int128,
+   options::OPT_fno_force_enable_int128)) {
+if (A->getOption().matches(options::OPT_fforce_enable_int128))
+  CmdArgs.push_

[PATCH] D43105: [RISCV] Enable __int128_t and __uint128_t through clang flag

2018-02-24 Thread Mandeep Singh Grang via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL326045: [RISCV] Enable __int128_t and __uint128_t through 
clang flag (authored by mgrang, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D43105?vs=135553&id=135807#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D43105

Files:
  cfe/trunk/include/clang/Basic/TargetInfo.h
  cfe/trunk/include/clang/Basic/TargetOptions.h
  cfe/trunk/include/clang/Driver/Options.td
  cfe/trunk/lib/Basic/Targets/Mips.h
  cfe/trunk/lib/Driver/ToolChains/Clang.cpp
  cfe/trunk/lib/Frontend/CompilerInvocation.cpp
  cfe/trunk/test/CodeGen/riscv32-abi.c
  cfe/trunk/test/Driver/types.c
  cfe/trunk/test/Preprocessor/init.c

Index: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp
@@ -4750,6 +4750,12 @@
 }
   }
 
+  if (Arg *A = Args.getLastArg(options::OPT_fforce_enable_int128,
+   options::OPT_fno_force_enable_int128)) {
+if (A->getOption().matches(options::OPT_fforce_enable_int128))
+  CmdArgs.push_back("-fforce-enable-int128");
+  }
+
   // Finally add the compile command to the compilation.
   if (Args.hasArg(options::OPT__SLASH_fallback) &&
   Output.getType() == types::TY_Object &&
Index: cfe/trunk/lib/Basic/Targets/Mips.h
===
--- cfe/trunk/lib/Basic/Targets/Mips.h
+++ cfe/trunk/lib/Basic/Targets/Mips.h
@@ -392,7 +392,9 @@
 return llvm::makeArrayRef(NewABIRegAliases);
   }
 
-  bool hasInt128Type() const override { return ABI == "n32" || ABI == "n64"; }
+  bool hasInt128Type() const override {
+return (ABI == "n32" || ABI == "n64") || getTargetOpts().ForceEnableInt128;
+  }
 
   bool validateTarget(DiagnosticsEngine &Diags) const override;
 };
Index: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
===
--- cfe/trunk/lib/Frontend/CompilerInvocation.cpp
+++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp
@@ -2781,6 +2781,7 @@
   if (Opts.Triple.empty())
 Opts.Triple = llvm::sys::getDefaultTargetTriple();
   Opts.OpenCLExtensionsAsWritten = Args.getAllArgValues(OPT_cl_ext_EQ);
+  Opts.ForceEnableInt128 = Args.hasArg(OPT_fforce_enable_int128);
 }
 
 bool CompilerInvocation::CreateFromArgs(CompilerInvocation &Res,
Index: cfe/trunk/include/clang/Driver/Options.td
===
--- cfe/trunk/include/clang/Driver/Options.td
+++ cfe/trunk/include/clang/Driver/Options.td
@@ -849,6 +849,12 @@
 def fjump_tables : Flag<["-"], "fjump-tables">, Group;
 def fno_jump_tables : Flag<["-"], "fno-jump-tables">, Group, Flags<[CC1Option]>,
   HelpText<"Do not use jump tables for lowering switches">;
+def fforce_enable_int128 : Flag<["-"], "fforce-enable-int128">,
+  Group, Flags<[CC1Option]>,
+  HelpText<"Enable support for int128_t type">;
+def fno_force_enable_int128 : Flag<["-"], "fno-force-enable-int128">,
+  Group, Flags<[CC1Option]>,
+  HelpText<"Disable support for int128_t type">;
 
 // Begin sanitizer flags. These should all be core options exposed in all driver
 // modes.
Index: cfe/trunk/include/clang/Basic/TargetOptions.h
===
--- cfe/trunk/include/clang/Basic/TargetOptions.h
+++ cfe/trunk/include/clang/Basic/TargetOptions.h
@@ -60,6 +60,9 @@
   /// \brief The list of OpenCL extensions to enable or disable, as written on
   /// the command line.
   std::vector OpenCLExtensionsAsWritten;
+
+  /// \brief If given, enables support for __int128_t and __uint128_t types.
+  bool ForceEnableInt128;
 };
 
 }  // end namespace clang
Index: cfe/trunk/include/clang/Basic/TargetInfo.h
===
--- cfe/trunk/include/clang/Basic/TargetInfo.h
+++ cfe/trunk/include/clang/Basic/TargetInfo.h
@@ -358,7 +358,7 @@
 
   /// \brief Determine whether the __int128 type is supported on this target.
   virtual bool hasInt128Type() const {
-return getPointerWidth(0) >= 64;
+return (getPointerWidth(0) >= 64) || getTargetOpts().ForceEnableInt128;
   } // FIXME
 
   /// \brief Determine whether the __float128 type is supported on this target.
Index: cfe/trunk/test/CodeGen/riscv32-abi.c
===
--- cfe/trunk/test/CodeGen/riscv32-abi.c
+++ cfe/trunk/test/CodeGen/riscv32-abi.c
@@ -1,4 +1,6 @@
 // RUN: %clang_cc1 -triple riscv32 -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple riscv32 -emit-llvm -fforce-enable-int128 %s -o - \
+// RUN: | FileCheck %s -check-prefixes=CHECK,CHECK-FORCEINT128
 
 #include 
 #include 
@@ -24,6 +26,11 @@
 // CHECK-LABEL: define i64 @f_scalar_4(i64 %x)
 int64_t f_scalar_4(int64_t x) { return x; }
 
+#ifdef __SIZE

[PATCH] D43105: [RISCV] Enable __int128_t and __uint128_t through clang flag

2018-02-24 Thread Mandeep Singh Grang via Phabricator via cfe-commits

mgrang added a comment.

After addressing comments, I have now committed this patch. Thanks for all the 
reviews!


Repository:
  rC Clang

https://reviews.llvm.org/D43105



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

[PATCH] D43737: Improve -Winfinite-recursion

2018-02-24 Thread Robert Widmann via Phabricator via cfe-commits

CodaFi created this revision.
CodaFi added a reviewer: rsmith.
Herald added a subscriber: cfe-commits.

Rewrites -Winfinite-recursion to remove the state dictionary and explore paths 
in loops - especially infinite loops.  The new check now detects recursion in 
loop bodies dominated by a recursive call.


Repository:
  rC Clang

https://reviews.llvm.org/D43737

Files:
  lib/Sema/AnalysisBasedWarnings.cpp
  test/SemaCXX/warn-infinite-recursion.cpp

Index: test/SemaCXX/warn-infinite-recursion.cpp
===
--- test/SemaCXX/warn-infinite-recursion.cpp
+++ test/SemaCXX/warn-infinite-recursion.cpp
@@ -29,8 +29,7 @@
 void e() { f(); }
 void f() { e(); }
 
-// Don't warn on infinite loops
-void g() {
+void g() {  // expected-warning{{call itself}}
   while (true)
 g();
 
@@ -54,6 +53,13 @@
   return 5 + j();
 }
 
+// Don't warn on infinite loops
+void k() {
+  while (true) {}
+
+  k();
+}
+
 class S {
   static void a();
   void b();
Index: lib/Sema/AnalysisBasedWarnings.cpp
===
--- lib/Sema/AnalysisBasedWarnings.cpp
+++ lib/Sema/AnalysisBasedWarnings.cpp
@@ -200,60 +200,43 @@
   return false;
 }
 
-// All blocks are in one of three states.  States are ordered so that blocks
-// can only move to higher states.
-enum RecursiveState {
-  FoundNoPath,
-  FoundPath,
-  FoundPathWithNoRecursiveCall
-};
-
 // Returns true if there exists a path to the exit block and every path
 // to the exit block passes through a call to FD.
 static bool checkForRecursiveFunctionCall(const FunctionDecl *FD, CFG *cfg) {
+  llvm::SmallPtrSet Visited;
+  llvm::SmallVector WorkList;
+  // Keep track of whether we found at least one recursive path.
+  bool foundRecursion = false;
 
   const unsigned ExitID = cfg->getExit().getBlockID();
+  auto analyzeSuccessor = [&](CFGBlock *CurBlock) -> bool {
+if (!Visited.insert(CurBlock).second)
+  return false;
 
-  // Mark all nodes as FoundNoPath, then set the status of the entry block.
-  SmallVector States(cfg->getNumBlockIDs(), FoundNoPath);
-  States[cfg->getEntry().getBlockID()] = FoundPathWithNoRecursiveCall;
+// If the successor block contains a recursive call, end analysis there.
+if (!hasRecursiveCallInPath(FD, *CurBlock)) {
+  WorkList.push_back(CurBlock);
+  return false;
+}
+return true;
+  };
 
-  // Make the processing stack and seed it with the entry block.
-  SmallVector Stack;
-  Stack.push_back(&cfg->getEntry());
+  // Seed the work list with the entry block.
+  foundRecursion |= analyzeSuccessor(&cfg->getEntry());
 
-  while (!Stack.empty()) {
-CFGBlock *CurBlock = Stack.back();
-Stack.pop_back();
-
+  while (!WorkList.empty()) {
+CFGBlock *CurBlock = WorkList.pop_back_val();
 unsigned ID = CurBlock->getBlockID();
-RecursiveState CurState = States[ID];
 
-if (CurState == FoundPathWithNoRecursiveCall) {
-  // Found a path to the exit node without a recursive call.
-  if (ExitID == ID)
-return false;
+// Found a path to the exit node without a recursive call.
+if (ExitID == ID)
+  return false;
 
-  // Only change state if the block has a recursive call.
-  if (hasRecursiveCallInPath(FD, *CurBlock))
-CurState = FoundPath;
-}
-
-// Loop over successor blocks and add them to the Stack if their state
-// changes.
 for (auto I = CurBlock->succ_begin(), E = CurBlock->succ_end(); I != E; ++I)
-  if (*I) {
-unsigned next_ID = (*I)->getBlockID();
-if (States[next_ID] < CurState) {
-  States[next_ID] = CurState;
-  Stack.push_back(*I);
-}
-  }
+  if (*I)
+foundRecursion |= analyzeSuccessor(*I);
   }
-
-  // Return true if the exit node is reachable, and only reachable through
-  // a recursive call.
-  return States[ExitID] == FoundPath;
+  return foundRecursion;
 }
 
 static void checkRecursiveFunction(Sema &S, const FunctionDecl *FD,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43581: [clang-tidy/google] Improve the Objective-C global variable declaration check 🔧

2018-02-24 Thread Yan Zhang via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL326046: [clang-tidy/google] Improve the Objective-C global 
variable declaration check 🔧 (authored by Wizard, committed by ).
Herald added subscribers: llvm-commits, klimek.

Changed prior to commit:
  https://reviews.llvm.org/D43581?vs=135745&id=135811#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D43581

Files:
  clang-tools-extra/trunk/clang-tidy/google/GlobalVariableDeclarationCheck.cpp
  
clang-tools-extra/trunk/test/clang-tidy/google-objc-global-variable-declaration.m


Index: 
clang-tools-extra/trunk/clang-tidy/google/GlobalVariableDeclarationCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/google/GlobalVariableDeclarationCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/google/GlobalVariableDeclarationCheck.cpp
@@ -72,7 +72,7 @@
   this);
   Finder->addMatcher(varDecl(hasGlobalStorage(), hasType(isConstQualified()),
  unless(isLocalVariable()),
- unless(matchesName("::k[A-Z]")))
+ unless(matchesName("::(k[A-Z]|[A-Z]{2,})")))
  .bind("global_const"),
  this);
 }
@@ -88,7 +88,7 @@
   if (const auto *Decl = Result.Nodes.getNodeAs("global_const")) {
 diag(Decl->getLocation(),
  "const global variable '%0' must have a name which starts with "
- "'k[A-Z]'")
+ "an appropriate prefix")
 << Decl->getName() << generateFixItHint(Decl, true);
   }
 }
Index: 
clang-tools-extra/trunk/test/clang-tidy/google-objc-global-variable-declaration.m
===
--- 
clang-tools-extra/trunk/test/clang-tidy/google-objc-global-variable-declaration.m
+++ 
clang-tools-extra/trunk/test/clang-tidy/google-objc-global-variable-declaration.m
@@ -2,7 +2,7 @@
 
 @class NSString;
 static NSString* const myConstString = @"hello";
-// CHECK-MESSAGES: :[[@LINE-1]]:24: warning: const global variable 
'myConstString' must have a name which starts with 'k[A-Z]' 
[google-objc-global-variable-declaration]
+// CHECK-MESSAGES: :[[@LINE-1]]:24: warning: const global variable 
'myConstString' must have a name which starts with an appropriate prefix 
[google-objc-global-variable-declaration]
 // CHECK-FIXES: static NSString* const kMyConstString = @"hello";
 
 static NSString* MyString = @"hi";
@@ -22,16 +22,24 @@
 // CHECK-FIXES: static NSString* gNoDef;
 
 static NSString* const _notAlpha = @"NotBeginWithAlpha";
-// CHECK-MESSAGES: :[[@LINE-1]]:24: warning: const global variable '_notAlpha' 
must have a name which starts with 'k[A-Z]' 
[google-objc-global-variable-declaration]
+// CHECK-MESSAGES: :[[@LINE-1]]:24: warning: const global variable '_notAlpha' 
must have a name which starts with an appropriate prefix 
[google-objc-global-variable-declaration]
 // CHECK-FIXES: static NSString* const _notAlpha = @"NotBeginWithAlpha";
 
 static NSString* const k_Alpha = @"SecondNotAlpha";
-// CHECK-MESSAGES: :[[@LINE-1]]:24: warning: const global variable 'k_Alpha' 
must have a name which starts with 'k[A-Z]' 
[google-objc-global-variable-declaration]
+// CHECK-MESSAGES: :[[@LINE-1]]:24: warning: const global variable 'k_Alpha' 
must have a name which starts with an appropriate prefix 
[google-objc-global-variable-declaration]
 // CHECK-FIXES: static NSString* const k_Alpha = @"SecondNotAlpha";
 
 static NSString* const kGood = @"hello";
+static NSString* const XYGood = @"hello";
 static NSString* gMyIntGood = 0;
 
+extern NSString* const GTLServiceErrorDomain;
+
+enum GTLServiceError {
+  GTLServiceErrorQueryResultMissing = -3000,
+  GTLServiceErrorWaitTimedOut   = -3001,
+};
+
 @implementation Foo
 - (void)f {
 int x = 0;


Index: clang-tools-extra/trunk/clang-tidy/google/GlobalVariableDeclarationCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/google/GlobalVariableDeclarationCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/google/GlobalVariableDeclarationCheck.cpp
@@ -72,7 +72,7 @@
   this);
   Finder->addMatcher(varDecl(hasGlobalStorage(), hasType(isConstQualified()),
  unless(isLocalVariable()),
- unless(matchesName("::k[A-Z]")))
+ unless(matchesName("::(k[A-Z]|[A-Z]{2,})")))
  .bind("global_const"),
  this);
 }
@@ -88,7 +88,7 @@
   if (const auto *Decl = Result.Nodes.getNodeAs("global_const")) {
 diag(Decl->getLocation(),
  "const global variable '%0' must have a name which starts with "
- "'k[A-Z]'")
+ "an appropriate prefix")
 << Decl->getName() << generateFixItHint(Decl, true);
   }
 }
Index: clang-tools-extra/trunk/test/clang-tidy/google-objc-global-variable-declaration.m

[PATCH] D43734: [RecordLayout] Don't align to non-power-of-2 sizes when using -mms-bitfields

2018-02-24 Thread Martin Storsjö via Phabricator via cfe-commits

mstorsjo updated this revision to Diff 135813.
mstorsjo added a comment.

Asserting that non power of 2 only occurs in gnu mode.


https://reviews.llvm.org/D43734

Files:
  lib/AST/RecordLayoutBuilder.cpp
  test/CodeGen/mingw-long-double.c


Index: test/CodeGen/mingw-long-double.c
===
--- test/CodeGen/mingw-long-double.c
+++ test/CodeGen/mingw-long-double.c
@@ -1,5 +1,7 @@
 // RUN: %clang_cc1 -triple i686-windows-gnu -emit-llvm -o - %s \
 // RUN:| FileCheck %s --check-prefix=GNU32
+// RUN: %clang_cc1 -triple i686-windows-gnu -emit-llvm -o - %s -mms-bitfields \
+// RUN:| FileCheck %s --check-prefix=GNU32
 // RUN: %clang_cc1 -triple x86_64-windows-gnu -emit-llvm -o - %s \
 // RUN:| FileCheck %s --check-prefix=GNU64
 // RUN: %clang_cc1 -triple x86_64-windows-msvc -emit-llvm -o - %s \
Index: lib/AST/RecordLayoutBuilder.cpp
===
--- lib/AST/RecordLayoutBuilder.cpp
+++ lib/AST/RecordLayoutBuilder.cpp
@@ -1752,7 +1752,12 @@
   QualType T = Context.getBaseElementType(D->getType());
   if (const BuiltinType *BTy = T->getAs()) {
 CharUnits TypeSize = Context.getTypeSizeInChars(BTy);
-if (TypeSize > FieldAlign)
+assert(
+(llvm::isPowerOf2_64(TypeSize.getQuantity()) ||
+ Context.getTargetInfo().getTriple().isWindowsGNUEnvironment()) &&
+"Non PowerOf2 size outside of GNU mode");
+if (TypeSize > FieldAlign &&
+llvm::isPowerOf2_64(TypeSize.getQuantity()))
   FieldAlign = TypeSize;
   }
 }


Index: test/CodeGen/mingw-long-double.c
===
--- test/CodeGen/mingw-long-double.c
+++ test/CodeGen/mingw-long-double.c
@@ -1,5 +1,7 @@
 // RUN: %clang_cc1 -triple i686-windows-gnu -emit-llvm -o - %s \
 // RUN:| FileCheck %s --check-prefix=GNU32
+// RUN: %clang_cc1 -triple i686-windows-gnu -emit-llvm -o - %s -mms-bitfields \
+// RUN:| FileCheck %s --check-prefix=GNU32
 // RUN: %clang_cc1 -triple x86_64-windows-gnu -emit-llvm -o - %s \
 // RUN:| FileCheck %s --check-prefix=GNU64
 // RUN: %clang_cc1 -triple x86_64-windows-msvc -emit-llvm -o - %s \
Index: lib/AST/RecordLayoutBuilder.cpp
===
--- lib/AST/RecordLayoutBuilder.cpp
+++ lib/AST/RecordLayoutBuilder.cpp
@@ -1752,7 +1752,12 @@
   QualType T = Context.getBaseElementType(D->getType());
   if (const BuiltinType *BTy = T->getAs()) {
 CharUnits TypeSize = Context.getTypeSizeInChars(BTy);
-if (TypeSize > FieldAlign)
+assert(
+(llvm::isPowerOf2_64(TypeSize.getQuantity()) ||
+ Context.getTargetInfo().getTriple().isWindowsGNUEnvironment()) &&
+"Non PowerOf2 size outside of GNU mode");
+if (TypeSize > FieldAlign &&
+llvm::isPowerOf2_64(TypeSize.getQuantity()))
   FieldAlign = TypeSize;
   }
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D43734: [RecordLayout] Don't align to non-power-of-2 sizes when using -mms-bitfields

2018-02-24 Thread Martin Storsjö via Phabricator via cfe-commits

mstorsjo added inline comments.



Comment at: lib/AST/RecordLayoutBuilder.cpp:1755
 CharUnits TypeSize = Context.getTypeSizeInChars(BTy);
-if (TypeSize > FieldAlign)
+if (TypeSize > FieldAlign &&
+llvm::isPowerOf2_64(TypeSize.getQuantity()))

compnerd wrote:
> Can you add an assertion that the size is a power of two unless it is the GNU 
> environment?
Sure, done.


https://reviews.llvm.org/D43734



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

[PATCH] D43671: [clangd] Address FIXME and fix comment

2018-02-24 Thread Kirill Bobyrev via Phabricator via cfe-commits

omtcyfz updated this revision to Diff 135815.
omtcyfz marked an inline comment as done.
omtcyfz added a comment.

Address Eric's nit: make warning message shorter so that it would fit into one 
line in order to omit braces for a single statement for compliance with the 
clang-tools-extra codestyle, as discussed with Alex a long while ago.


https://reviews.llvm.org/D43671

Files:
  clangd/Context.cpp
  clangd/tool/ClangdMain.cpp


Index: clangd/tool/ClangdMain.cpp
===
--- clangd/tool/ClangdMain.cpp
+++ clangd/tool/ClangdMain.cpp
@@ -149,10 +149,11 @@
 return 1;
   }
 
-  // Ignore -j option if -run-synchonously is used.
-  // FIXME: a warning should be shown here.
-  if (RunSynchronously)
+  if (RunSynchronously) {
+if (WorkerThreadsCount.getNumOccurrences())
+  llvm::errs() << "Ignoring -j because -run-synchronously is set.\n";
 WorkerThreadsCount = 0;
+  }
 
   // Validate command line arguments.
   llvm::Optional InputMirrorStream;
Index: clangd/Context.cpp
===
--- clangd/Context.cpp
+++ clangd/Context.cpp
@@ -13,7 +13,7 @@
 namespace clang {
 namespace clangd {
 
-Context Context::empty() { return Context(/*Data=*/nullptr); }
+Context Context::empty() { return Context(/*DataPtr=*/nullptr); }
 
 Context::Context(std::shared_ptr DataPtr)
 : DataPtr(std::move(DataPtr)) {}


Index: clangd/tool/ClangdMain.cpp
===
--- clangd/tool/ClangdMain.cpp
+++ clangd/tool/ClangdMain.cpp
@@ -149,10 +149,11 @@
 return 1;
   }
 
-  // Ignore -j option if -run-synchonously is used.
-  // FIXME: a warning should be shown here.
-  if (RunSynchronously)
+  if (RunSynchronously) {
+if (WorkerThreadsCount.getNumOccurrences())
+  llvm::errs() << "Ignoring -j because -run-synchronously is set.\n";
 WorkerThreadsCount = 0;
+  }
 
   // Validate command line arguments.
   llvm::Optional InputMirrorStream;
Index: clangd/Context.cpp
===
--- clangd/Context.cpp
+++ clangd/Context.cpp
@@ -13,7 +13,7 @@
 namespace clang {
 namespace clangd {
 
-Context Context::empty() { return Context(/*Data=*/nullptr); }
+Context Context::empty() { return Context(/*DataPtr=*/nullptr); }
 
 Context::Context(std::shared_ptr DataPtr)
 : DataPtr(std::move(DataPtr)) {}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r326051 - [clangd] Address FIXME and fix comment

2018-02-24 Thread Kirill Bobyrev via cfe-commits

Author: omtcyfz
Date: Sat Feb 24 23:21:16 2018
New Revision: 326051

URL: http://llvm.org/viewvc/llvm-project?rev=326051&view=rev
Log:
[clangd] Address FIXME and fix comment

* Address a FIXME by warning the user that both -run-synchronously and -j X are
  passed.
* Fix a comment to suppress clang-tidy warning by passing the correct argument
  name.

Reviewers: ioeric

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

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

Modified:
clang-tools-extra/trunk/clangd/Context.cpp
clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp

Modified: clang-tools-extra/trunk/clangd/Context.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Context.cpp?rev=326051&r1=326050&r2=326051&view=diff
==
--- clang-tools-extra/trunk/clangd/Context.cpp (original)
+++ clang-tools-extra/trunk/clangd/Context.cpp Sat Feb 24 23:21:16 2018
@@ -13,7 +13,7 @@
 namespace clang {
 namespace clangd {
 
-Context Context::empty() { return Context(/*Data=*/nullptr); }
+Context Context::empty() { return Context(/*DataPtr=*/nullptr); }
 
 Context::Context(std::shared_ptr DataPtr)
 : DataPtr(std::move(DataPtr)) {}

Modified: clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp?rev=326051&r1=326050&r2=326051&view=diff
==
--- clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp (original)
+++ clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp Sat Feb 24 23:21:16 2018
@@ -149,10 +149,11 @@ int main(int argc, char *argv[]) {
 return 1;
   }
 
-  // Ignore -j option if -run-synchonously is used.
-  // FIXME: a warning should be shown here.
-  if (RunSynchronously)
+  if (RunSynchronously) {
+if (WorkerThreadsCount.getNumOccurrences())
+  llvm::errs() << "Ignoring -j because -run-synchronously is set.\n";
 WorkerThreadsCount = 0;
+  }
 
   // Validate command line arguments.
   llvm::Optional InputMirrorStream;


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

[PATCH] D43671: [clangd] Address FIXME and fix comment

2018-02-24 Thread Kirill Bobyrev via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL326051: [clangd] Address FIXME and fix comment (authored by 
omtcyfz, committed by ).
Herald added subscribers: llvm-commits, klimek.

Changed prior to commit:
  https://reviews.llvm.org/D43671?vs=135815&id=135816#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D43671

Files:
  clang-tools-extra/trunk/clangd/Context.cpp
  clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp


Index: clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
@@ -149,10 +149,11 @@
 return 1;
   }
 
-  // Ignore -j option if -run-synchonously is used.
-  // FIXME: a warning should be shown here.
-  if (RunSynchronously)
+  if (RunSynchronously) {
+if (WorkerThreadsCount.getNumOccurrences())
+  llvm::errs() << "Ignoring -j because -run-synchronously is set.\n";
 WorkerThreadsCount = 0;
+  }
 
   // Validate command line arguments.
   llvm::Optional InputMirrorStream;
Index: clang-tools-extra/trunk/clangd/Context.cpp
===
--- clang-tools-extra/trunk/clangd/Context.cpp
+++ clang-tools-extra/trunk/clangd/Context.cpp
@@ -13,7 +13,7 @@
 namespace clang {
 namespace clangd {
 
-Context Context::empty() { return Context(/*Data=*/nullptr); }
+Context Context::empty() { return Context(/*DataPtr=*/nullptr); }
 
 Context::Context(std::shared_ptr DataPtr)
 : DataPtr(std::move(DataPtr)) {}


Index: clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
@@ -149,10 +149,11 @@
 return 1;
   }
 
-  // Ignore -j option if -run-synchonously is used.
-  // FIXME: a warning should be shown here.
-  if (RunSynchronously)
+  if (RunSynchronously) {
+if (WorkerThreadsCount.getNumOccurrences())
+  llvm::errs() << "Ignoring -j because -run-synchronously is set.\n";
 WorkerThreadsCount = 0;
+  }
 
   // Validate command line arguments.
   llvm::Optional InputMirrorStream;
Index: clang-tools-extra/trunk/clangd/Context.cpp
===
--- clang-tools-extra/trunk/clangd/Context.cpp
+++ clang-tools-extra/trunk/clangd/Context.cpp
@@ -13,7 +13,7 @@
 namespace clang {
 namespace clangd {
 
-Context Context::empty() { return Context(/*Data=*/nullptr); }
+Context Context::empty() { return Context(/*DataPtr=*/nullptr); }
 
 Context::Context(std::shared_ptr DataPtr)
 : DataPtr(std::move(DataPtr)) {}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

39 matches

Mail list logo