[PATCH] D59185: [PowerPC] Set the default PLT mode on musl to Secure PLT

2019-03-09 Thread A. Wilcox via Phabricator via cfe-commits
awilfox created this revision.
awilfox added reviewers: nemanjai, jhibbits.
Herald added subscribers: cfe-commits, jsji, kbarton.
Herald added a project: clang.

The musl libc only supports Secure PLT.


Repository:
  rC Clang

https://reviews.llvm.org/D59185

Files:
  lib/Driver/ToolChains/Arch/PPC.cpp


Index: lib/Driver/ToolChains/Arch/PPC.cpp
===
--- lib/Driver/ToolChains/Arch/PPC.cpp
+++ lib/Driver/ToolChains/Arch/PPC.cpp
@@ -115,7 +115,7 @@
   const ArgList ) {
   if (Args.getLastArg(options::OPT_msecure_plt))
 return ppc::ReadGOTPtrMode::SecurePlt;
-  if (Triple.isOSNetBSD() || Triple.isOSOpenBSD())
+  if (Triple.isOSNetBSD() || Triple.isOSOpenBSD() || Triple.isMusl())
 return ppc::ReadGOTPtrMode::SecurePlt;
   else
 return ppc::ReadGOTPtrMode::Bss;


Index: lib/Driver/ToolChains/Arch/PPC.cpp
===
--- lib/Driver/ToolChains/Arch/PPC.cpp
+++ lib/Driver/ToolChains/Arch/PPC.cpp
@@ -115,7 +115,7 @@
   const ArgList ) {
   if (Args.getLastArg(options::OPT_msecure_plt))
 return ppc::ReadGOTPtrMode::SecurePlt;
-  if (Triple.isOSNetBSD() || Triple.isOSOpenBSD())
+  if (Triple.isOSNetBSD() || Triple.isOSOpenBSD() || Triple.isMusl())
 return ppc::ReadGOTPtrMode::SecurePlt;
   else
 return ppc::ReadGOTPtrMode::Bss;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D59183: [clang-tidy] Expand cases covered by the abseil-duration-unnecessary-conversion check

2019-03-09 Thread Hyrum Wright via Phabricator via cfe-commits
hwright created this revision.
hwright added a reviewer: hokein.
Herald added subscribers: cfe-commits, xazax.hun.
Herald added a project: clang.

This adds coverage for expressions of these forms

  absl::Duration d2, d1;
  d2 = absl::Seconds(d1 / absl::Seconds(1));
  d2 = absl::Seconds(absl::FDivDuration(d1, absl::Seconds(1)));


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D59183

Files:
  clang-tidy/abseil/DurationUnnecessaryConversionCheck.cpp
  docs/clang-tidy/checks/abseil-duration-unnecessary-conversion.rst
  test/clang-tidy/Inputs/absl/time/time.h
  test/clang-tidy/abseil-duration-unnecessary-conversion.cpp

Index: test/clang-tidy/abseil-duration-unnecessary-conversion.cpp
===
--- test/clang-tidy/abseil-duration-unnecessary-conversion.cpp
+++ test/clang-tidy/abseil-duration-unnecessary-conversion.cpp
@@ -45,6 +45,44 @@
   // CHECK-MESSAGES: [[@LINE-1]]:8: warning: remove unnecessary absl::Duration conversions [abseil-duration-unnecessary-conversion]
   // CHECK-FIXES: d1
 
+  d2 = absl::Hours(d1 / absl::Hours(1));
+  // CHECK-MESSAGES: [[@LINE-1]]:8: warning: remove unnecessary absl::Duration conversions [abseil-duration-unnecessary-conversion]
+  // CHECK-FIXES: d1
+  d2 = absl::Minutes(d1 / absl::Minutes(1));
+  // CHECK-MESSAGES: [[@LINE-1]]:8: warning: remove unnecessary absl::Duration conversions [abseil-duration-unnecessary-conversion]
+  // CHECK-FIXES: d1
+  d2 = absl::Seconds(d1 / absl::Seconds(1));
+  // CHECK-MESSAGES: [[@LINE-1]]:8: warning: remove unnecessary absl::Duration conversions [abseil-duration-unnecessary-conversion]
+  // CHECK-FIXES: d1
+  d2 = absl::Milliseconds(d1 / absl::Milliseconds(1));
+  // CHECK-MESSAGES: [[@LINE-1]]:8: warning: remove unnecessary absl::Duration conversions [abseil-duration-unnecessary-conversion]
+  // CHECK-FIXES: d1
+  d2 = absl::Microseconds(d1 / absl::Microseconds(1));
+  // CHECK-MESSAGES: [[@LINE-1]]:8: warning: remove unnecessary absl::Duration conversions [abseil-duration-unnecessary-conversion]
+  // CHECK-FIXES: d1
+  d2 = absl::Nanoseconds(d1 / absl::Nanoseconds(1));
+  // CHECK-MESSAGES: [[@LINE-1]]:8: warning: remove unnecessary absl::Duration conversions [abseil-duration-unnecessary-conversion]
+  // CHECK-FIXES: d1
+
+  d2 = absl::Hours(absl::FDivDuration(d1, absl::Hours(1)));
+  // CHECK-MESSAGES: [[@LINE-1]]:8: warning: remove unnecessary absl::Duration conversions [abseil-duration-unnecessary-conversion]
+  // CHECK-FIXES: d1
+  d2 = absl::Minutes(absl::FDivDuration(d1, absl::Minutes(1)));
+  // CHECK-MESSAGES: [[@LINE-1]]:8: warning: remove unnecessary absl::Duration conversions [abseil-duration-unnecessary-conversion]
+  // CHECK-FIXES: d1
+  d2 = absl::Seconds(absl::FDivDuration(d1, absl::Seconds(1)));
+  // CHECK-MESSAGES: [[@LINE-1]]:8: warning: remove unnecessary absl::Duration conversions [abseil-duration-unnecessary-conversion]
+  // CHECK-FIXES: d1
+  d2 = absl::Milliseconds(absl::FDivDuration(d1, absl::Milliseconds(1)));
+  // CHECK-MESSAGES: [[@LINE-1]]:8: warning: remove unnecessary absl::Duration conversions [abseil-duration-unnecessary-conversion]
+  // CHECK-FIXES: d1
+  d2 = absl::Microseconds(absl::FDivDuration(d1, absl::Microseconds(1)));
+  // CHECK-MESSAGES: [[@LINE-1]]:8: warning: remove unnecessary absl::Duration conversions [abseil-duration-unnecessary-conversion]
+  // CHECK-FIXES: d1
+  d2 = absl::Nanoseconds(absl::FDivDuration(d1, absl::Nanoseconds(1)));
+  // CHECK-MESSAGES: [[@LINE-1]]:8: warning: remove unnecessary absl::Duration conversions [abseil-duration-unnecessary-conversion]
+  // CHECK-FIXES: d1
+
   // As macro argument
 #define PLUS_FIVE_S(x) x + absl::Seconds(5)
   d2 = PLUS_FIVE_S(absl::Seconds(absl::ToInt64Seconds(d1)));
@@ -66,4 +104,8 @@
   d2 = absl::Seconds(absl::ToDoubleMilliseconds(d1));
   d2 = absl::Seconds(4);
   int i = absl::ToInt64Milliseconds(d1);
+  d2 = absl::Hours(d1 / absl::Minutes(1));
+  d2 = absl::Seconds(d1 / absl::Seconds(30));
+  d2 = absl::Hours(absl::FDivDuration(d1, absl::Minutes(1)));
+  d2 = absl::Milliseconds(absl::FDivDuration(d1, absl::Milliseconds(20)));
 }
Index: test/clang-tidy/Inputs/absl/time/time.h
===
--- test/clang-tidy/Inputs/absl/time/time.h
+++ test/clang-tidy/Inputs/absl/time/time.h
@@ -21,6 +21,7 @@
 template  Duration operator*(Duration lhs, T rhs);
 template  Duration operator*(T lhs, Duration rhs);
 template  Duration operator/(Duration lhs, T rhs);
+int64_t operator/(Duration lhs, Duration rhs);
 
 class Time{};
 
@@ -86,4 +87,6 @@
 inline Time operator-(Time lhs, Duration rhs);
 inline Duration operator-(Time lhs, Time rhs);
 
+double FDivDuration(Duration num, Duration den);
+
 }  // namespace absl
Index: docs/clang-tidy/checks/abseil-duration-unnecessary-conversion.rst
===
--- 

[PATCH] D58878: [Diagnostics] Warn for assignments in bool contexts

2019-03-09 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:6738
+  "assignment to bool">,
+  InGroup;
 // Completely identical except off by default.

xbolva00 wrote:
> rjmccall wrote:
> > Sorry, I didn't mean to suggest that you should change the existing 
> > diagnostic.  You should add a second diagnostic in a new warning group 
> > (which should be implied by `-Wparentheses`) that you use just in this case.
> > 
> > We try to add new warnings this way — even when they're just 
> > generalizations of existing warnings — so that they can be independently 
> > disabled by e.g. the compiler teams at Apple and Google that need to 
> > periodically roll out new compilers across a large codebase.
> This is quite problematic to isolate this one since tha patch add 
> DiagnoseAssignmentAsCondition call into the PerformImplicitConversion so I 
> don't know how to see in PerformImplicitConversion whether we are in the 
> condition or not. So, this new warning note wins over current one "using the 
> result of an assignment as a condition without parentheses" always :/ 
`PerformImplicitConversion` is not being used for the expression-as-condition 
path.  You can tell because otherwise we'd be emitting the diagnostic twice: 
Clang doesn't have general code to eliminate redundant diagnostics, it just 
relies on not doing redundant checks.  So we know in 
`PerformImplicitConversion` that we're in an arbitrary conversion to `bool`, 
and the other (original) call site is from code that's specific to the 
expression-as-condition path.

There's another reason to distinguish between these cases, though: I'm not sure 
adding parentheses makes as much sense as a way to suppress the warning when 
the context is an implicit conversion instead of a condition.  The right 
suppression is to explicitly cast to `bool`.  So (1) we should look through 
parentheses for implicit conversions and (2) we should emit different notes.


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

https://reviews.llvm.org/D58878



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


[PATCH] D58777: [analyzer] Fix an assertation failurure for invalid sourcelocation, add a new debug checker

2019-03-09 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.

In D58777#1422248 , @NoQ wrote:

> Very nice! Crashing diagnostic locations are a fairly common issue. That 
> said, this still makes me wonder what sort of checker were you writing that 
> triggered this originally :)


Unfortunately, nothing fancy, I just made another debug checker to emit a 
warning on each macro location to test macro expansions in the plist output. I 
did encounter a crash (this one), but since creduce can only work on a 
preprocessed file, I created this checker to be able to get a sensible test 
case.


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

https://reviews.llvm.org/D58777



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


[PATCH] D57893: [analyzer] Fix function macro crash

2019-03-09 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.
Herald added a subscriber: whisperity.

This patch no longer applies cleanly to the latest version of clang -- could 
you rebase please?


Repository:
  rC Clang

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

https://reviews.llvm.org/D57893



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


[PATCH] D56160: [clang-tidy] modernize-use-trailing-return-type check

2019-03-09 Thread Bernhard Manfred Gruber via Phabricator via cfe-commits
bernhardmgruber updated this revision to Diff 189993.
bernhardmgruber marked 8 inline comments as done.
bernhardmgruber added a comment.

- added support for __restrict
- added two dots at end of comments


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

https://reviews.llvm.org/D56160

Files:
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/ModernizeTidyModule.cpp
  clang-tidy/modernize/UseTrailingReturnTypeCheck.cpp
  clang-tidy/modernize/UseTrailingReturnTypeCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/modernize-use-trailing-return-type.rst
  test/clang-tidy/modernize-use-trailing-return-type.cpp

Index: test/clang-tidy/modernize-use-trailing-return-type.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-use-trailing-return-type.cpp
@@ -0,0 +1,445 @@
+// RUN: %check_clang_tidy %s modernize-use-trailing-return-type %t -- -- --std=c++14 -fdeclspec
+
+namespace std {
+template 
+class vector;
+
+template 
+class array;
+
+class string;
+
+template 
+auto declval() -> T;
+}
+
+//
+// Functions
+//
+
+int f();
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
+// CHECK-FIXES: {{^}}auto f() -> int;{{$}}
+int ((f))();
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
+// CHECK-FIXES: {{^}}auto ((f))() -> int;{{$}}
+int f(int);
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
+// CHECK-FIXES: {{^}}auto f(int) -> int;{{$}}
+int f(int arg);
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
+// CHECK-FIXES: {{^}}auto f(int arg) -> int;{{$}}
+int f(int arg1, int arg2, int arg3);
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
+// CHECK-FIXES: {{^}}auto f(int arg1, int arg2, int arg3) -> int;{{$}}
+int f(int arg1, int arg2, int arg3, ...);
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
+// CHECK-FIXES: {{^}}auto f(int arg1, int arg2, int arg3, ...) -> int;{{$}}
+template  int f(T t);
+// CHECK-MESSAGES: :[[@LINE-1]]:27: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
+// CHECK-FIXES: {{^}}template  auto f(T t) -> int;{{$}}
+
+//
+// Functions with formatting
+//
+
+int a1() { return 42; }
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
+// CHECK-FIXES: {{^}}auto a1() -> int { return 42; }{{$}}
+int a2() {
+return 42;
+}
+// CHECK-MESSAGES: :[[@LINE-3]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
+// CHECK-FIXES: {{^}}auto a2() -> int {{{$}}
+int a3()
+{
+return 42;
+}
+// CHECK-MESSAGES: :[[@LINE-4]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
+// CHECK-FIXES: {{^}}auto a3() -> int{{$}}
+int a4(int   arg   )   ;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
+// CHECK-FIXES: {{^}}auto a4(int   arg   ) -> int   ;{{$}}
+int a5
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
+// CHECK-FIXES: {{^}}auto a5{{$}}
+(int arg);
+// CHECK-FIXES: {{^}}(int arg) -> int;{{$}}
+const
+int
+*
+a7
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
+()
+// CHECK-FIXES: {{^}}() -> const{{$}}
+// CHECK-FIXES: {{^}}int{{$}}
+// CHECK-FIXES: {{^}}*{{$}}
+;
+
+int*a7(int arg);
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
+// CHECK-FIXES: {{^}}auto a7(int arg) -> int*;{{$}}
+template class C>
+Ca8(int arg);
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
+// CHECK-FIXES: {{^}}auto a8(int arg) -> C;{{$}}
+
+
+//
+// Functions with qualifiers and specifiers
+//
+
+inline int d1(int arg);
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
+// CHECK-FIXES: {{^}}inline auto d1(int arg) -> int;{{$}}
+extern "C" int d2(int arg);
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: use a trailing return type for this function [modernize-use-trailing-return-type]
+// CHECK-FIXES: {{^}}extern "C" auto d2(int arg) -> int;{{$}}
+inline int d3(int arg) noexcept(true);
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: use a trailing return type for 

[PATCH] D55170: [clang-format]: Add NonEmptyParentheses spacing option

2019-03-09 Thread Reuben Thomas via Phabricator via cfe-commits
reuk added a comment.

Thanks for the review, and for approving this PR. It's very much appreciated!

I don't have merge rights - could someone commit this for me please?


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

https://reviews.llvm.org/D55170



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


[PATCH] D33029: [clang-format] add option for dangling parenthesis

2019-03-09 Thread Ryan Stringham via Phabricator via cfe-commits
stringham added a comment.

@MyDeveloperDay I am happy to write unit tests and clean up the change set but 
I don't want to spend more time on this if it has no chance of being merged.

I am looking for some agreement that this feature is worth adding to clang 
format and then I'd like to know that my general solution is reasonable and 
agree on what we should call the option.

Currently, we're just using a fork with this patch applied. It would be nice to 
get the changes merged upstream, but I don't know how to make that happen.


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

https://reviews.llvm.org/D33029



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


r355780 - Stop relying on allocator behaviour in modules unit test

2019-03-09 Thread Duncan P. N. Exon Smith via cfe-commits
Author: dexonsmith
Date: Sat Mar  9 12:15:01 2019
New Revision: 355780

URL: http://llvm.org/viewvc/llvm-project?rev=355780=rev
Log:
Stop relying on allocator behaviour in modules unit test

Another fixup for r355778 for Windows bots, this time to stop
accidentally relying on allocator behaviour for the test to pass.

Modified:
cfe/trunk/unittests/Serialization/InMemoryModuleCacheTest.cpp

Modified: cfe/trunk/unittests/Serialization/InMemoryModuleCacheTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Serialization/InMemoryModuleCacheTest.cpp?rev=355780=355779=355780=diff
==
--- cfe/trunk/unittests/Serialization/InMemoryModuleCacheTest.cpp (original)
+++ cfe/trunk/unittests/Serialization/InMemoryModuleCacheTest.cpp Sat Mar  9 
12:15:01 2019
@@ -71,12 +71,15 @@ TEST(InMemoryModuleCacheTest, addBuiltPC
 }
 
 TEST(InMemoryModuleCacheTest, tryToDropPCM) {
-  auto B = getBuffer(1);
-  auto *RawB = B.get();
+  auto B1 = getBuffer(1);
+  auto B2 = getBuffer(2);
+  auto *RawB1 = B1.get();
+  auto *RawB2 = B2.get();
+  ASSERT_NE(RawB1, RawB2);
 
   InMemoryModuleCache Cache;
   EXPECT_EQ(InMemoryModuleCache::Unknown, Cache.getPCMState("B"));
-  EXPECT_EQ(RawB, ("B", std::move(B)));
+  EXPECT_EQ(RawB1, ("B", std::move(B1)));
   EXPECT_FALSE(Cache.tryToDropPCM("B"));
   EXPECT_EQ(nullptr, Cache.lookupPCM("B"));
   EXPECT_EQ(InMemoryModuleCache::ToBuild, Cache.getPCMState("B"));
@@ -90,17 +93,13 @@ TEST(InMemoryModuleCacheTest, tryToDropP
   EXPECT_DEATH(Cache.finalizePCM("B"), "Trying to finalize a dropped PCM");
 #endif
 
-  B = getBuffer(2);
-  ASSERT_NE(RawB, B.get());
-  RawB = B.get();
-
   // Add a new one.
-  EXPECT_EQ(RawB, ("B", std::move(B)));
+  EXPECT_EQ(RawB2, ("B", std::move(B2)));
   EXPECT_TRUE(Cache.isPCMFinal("B"));
 
   // Can try to drop again, but this should error and do nothing.
   EXPECT_TRUE(Cache.tryToDropPCM("B"));
-  EXPECT_EQ(RawB, Cache.lookupPCM("B"));
+  EXPECT_EQ(RawB2, Cache.lookupPCM("B"));
 }
 
 TEST(InMemoryModuleCacheTest, finalizePCM) {


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


Re: r355182 - [clang-format] [NFC] clang-format the Format library

2019-03-09 Thread MyDeveloper Day via cfe-commits
Yes ideally I'd agree, It also says:

> Avoid committing formatting- or whitespace-only changes outside of code
you plan to make subsequent changes to.

This was getting to be a problem, every time we edited the file (with
auto-clang-format) a large number of other changes would also get made,
presumably because others hadn't been clang-formatting their commits
correctly! we'd have to merge out a lot of changes everytime.

And then its says this..

>Also, try to separate formatting or whitespace changes from functional
changes, either by correcting the format first (ideally) or afterward

which means you want those changes to be separate commits.. so ideally its
better we clang-format the file when there is no other related changes so
future revisions don't need to have a mixture of real changes and
whitespace changes.

I also think given we also encourage people to clang-format out code,  its
ironic clang-format itself is not clang-formatted!


On Fri, Mar 8, 2019 at 8:59 PM Michael Kruse 
wrote:

> Isn't this kind of commit discouraged?, as by
> https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access
>
> > Avoid committing formatting- or whitespace-only changes outside of code
> you plan to make subsequent changes to.
>
> and the discussion after which this has been added:
> https://lists.llvm.org/pipermail/llvm-dev/2018-July/124941.html
>
>
> Michael
>
> Am Fr., 1. März 2019 um 03:09 Uhr schrieb Paul Hoad via cfe-commits
> :
> >
> > Author: paulhoad
> > Date: Fri Mar  1 01:09:54 2019
> > New Revision: 355182
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=355182=rev
> > Log:
> > [clang-format] [NFC] clang-format the Format library
> >
> > Previously revisions commited non-clang-formatted changes to the Format
> library, this means submitting any revision e.g. {D55170} can cause
> additional whitespace changes to potentially be included in a revision.
> >
> > Commit a non functional change using latest build Windows clang-format
> r351376 with no other changes, to remove these differences
> >
> > All FormatTests
> > pass [==] 652 tests from 20 test cases ran.
> >
> > Modified:
> > cfe/trunk/lib/Format/BreakableToken.cpp
> > cfe/trunk/lib/Format/BreakableToken.h
> > cfe/trunk/lib/Format/ContinuationIndenter.cpp
> > cfe/trunk/lib/Format/Format.cpp
> > cfe/trunk/lib/Format/FormatToken.h
> > cfe/trunk/lib/Format/FormatTokenLexer.h
> > cfe/trunk/lib/Format/TokenAnnotator.cpp
> > cfe/trunk/lib/Format/UnwrappedLineFormatter.cpp
> > cfe/trunk/lib/Format/UnwrappedLineFormatter.h
> > cfe/trunk/lib/Format/UnwrappedLineParser.cpp
> > cfe/trunk/lib/Format/UnwrappedLineParser.h
> > cfe/trunk/lib/Format/WhitespaceManager.cpp
> >
> > Modified: cfe/trunk/lib/Format/BreakableToken.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/BreakableToken.cpp?rev=355182=355181=355182=diff
> >
> ==
> > --- cfe/trunk/lib/Format/BreakableToken.cpp (original)
> > +++ cfe/trunk/lib/Format/BreakableToken.cpp Fri Mar  1 01:09:54 2019
> > @@ -62,12 +62,10 @@ static StringRef getLineCommentIndentPre
> >return LongestPrefix;
> >  }
> >
> > -static BreakableToken::Split getCommentSplit(StringRef Text,
> > - unsigned
> ContentStartColumn,
> > - unsigned ColumnLimit,
> > - unsigned TabWidth,
> > - encoding::Encoding
> Encoding,
> > - const FormatStyle ) {
> > +static BreakableToken::Split
> > +getCommentSplit(StringRef Text, unsigned ContentStartColumn,
> > +unsigned ColumnLimit, unsigned TabWidth,
> > +encoding::Encoding Encoding, const FormatStyle ) {
> >LLVM_DEBUG(llvm::dbgs() << "Comment split: \"" << Text
> ><< "\", Column limit: " << ColumnLimit
> ><< ", Content start: " << ContentStartColumn
> << "\n");
> > @@ -191,7 +189,7 @@ bool switchesFormatting(const FormatToke
> >
> >  unsigned
> >  BreakableToken::getLengthAfterCompression(unsigned
> RemainingTokenColumns,
> > -  Split Split) const {
> > +  Split Split) const {
> >// Example: consider the content
> >// lala  lala
> >// - RemainingTokenColumns is the original number of columns, 10;
> > @@ -870,23 +868,20 @@ void BreakableLineCommentSection::reflow
> >  // the next line.
> >  unsigned WhitespaceLength =
> >  Lines[LineIndex].data() - tokenAt(LineIndex).TokenText.data() -
> Offset;
> > -Whitespaces.replaceWhitespaceInToken(*Tokens[LineIndex],
> > - Offset,
> > +Whitespaces.replaceWhitespaceInToken(*Tokens[LineIndex], Offset,
> >
>  

r355779 - Fix slashes in path references in -Rmodule-import test from r355778

2019-03-09 Thread Duncan P. N. Exon Smith via cfe-commits
Author: dexonsmith
Date: Sat Mar  9 11:33:32 2019
New Revision: 355779

URL: http://llvm.org/viewvc/llvm-project?rev=355779=rev
Log:
Fix slashes in path references in -Rmodule-import test from r355778

Fixup for r355778 to fix all the Windows bots.  Apparently I already
forgot the lesson from r355482 :/.

Modified:
cfe/trunk/test/Modules/implicit-invalidate-chain.c
cfe/trunk/test/Modules/relative-import-path.c

Modified: cfe/trunk/test/Modules/implicit-invalidate-chain.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/implicit-invalidate-chain.c?rev=355779=355778=355779=diff
==
--- cfe/trunk/test/Modules/implicit-invalidate-chain.c (original)
+++ cfe/trunk/test/Modules/implicit-invalidate-chain.c Sat Mar  9 11:33:32 2019
@@ -33,35 +33,35 @@
 // RUN: FileCheck %s -implicit-check-not "remark:"
 
 #include "A.h" // \
-   expected-remark-re{{importing module 'A' from '{{.*}}/A.pcm'}} \
-   expected-remark-re{{importing module 'B' into 'A' from '{{.*}}/B.pcm'}} \
-   expected-remark-re{{importing module 'C' into 'B' from '{{.*}}/C.pcm'}} \
-   expected-remark-re{{importing module 'D' into 'C' from '{{.*}}/D.pcm'}} \
-   expected-remark-re{{building module 'A' as '{{.*}}/A.pcm'}} \
+   expected-remark-re{{importing module 'A' from '{{.*[/\\]}}A.pcm'}} \
+   expected-remark-re{{importing module 'B' into 'A' from '{{.*[/\\]}}B.pcm'}} 
\
+   expected-remark-re{{importing module 'C' into 'B' from '{{.*[/\\]}}C.pcm'}} 
\
+   expected-remark-re{{importing module 'D' into 'C' from '{{.*[/\\]}}D.pcm'}} 
\
+   expected-remark-re{{building module 'A' as '{{.*[/\\]}}A.pcm'}} \
expected-remark{{finished building module 'A'}} \
-   expected-remark-re{{importing module 'A' from '{{.*}}/A.pcm'}} \
-   expected-remark-re{{importing module 'B' into 'A' from '{{.*}}/B.pcm'}} \
-   expected-remark-re{{importing module 'C' into 'B' from '{{.*}}/C.pcm'}} \
-   expected-remark-re{{importing module 'D' into 'C' from '{{.*}}/D.pcm'}}
-// CHECK: remark: importing module 'A' from '{{.*}}/A.pcm'
-// CHECK: remark: importing module 'B' into 'A' from '{{.*}}/B.pcm'
-// CHECK: remark: importing module 'C' into 'B' from '{{.*}}/C.pcm'
-// CHECK: remark: importing module 'D' into 'C' from '{{.*}}/D.pcm'
+   expected-remark-re{{importing module 'A' from '{{.*[/\\]}}A.pcm'}} \
+   expected-remark-re{{importing module 'B' into 'A' from '{{.*[/\\]}}B.pcm'}} 
\
+   expected-remark-re{{importing module 'C' into 'B' from '{{.*[/\\]}}C.pcm'}} 
\
+   expected-remark-re{{importing module 'D' into 'C' from '{{.*[/\\]}}D.pcm'}}
+// CHECK: remark: importing module 'A' from '{{.*[/\\]}}A.pcm'
+// CHECK: remark: importing module 'B' into 'A' from '{{.*[/\\]}}B.pcm'
+// CHECK: remark: importing module 'C' into 'B' from '{{.*[/\\]}}C.pcm'
+// CHECK: remark: importing module 'D' into 'C' from '{{.*[/\\]}}D.pcm'
 // CHECK: remark: building module 'A'
 // CHECK: remark: building module 'B'
 // CHECK: remark: building module 'C'
 // CHECK: remark: building module 'D'
 // CHECK: remark: finished building module 'D'
-// CHECK: remark: importing module 'D' from '{{.*}}/D.pcm'
+// CHECK: remark: importing module 'D' from '{{.*[/\\]}}D.pcm'
 // CHECK: remark: finished building module 'C'
-// CHECK: remark: importing module 'C' from '{{.*}}/C.pcm'
-// CHECK: remark: importing module 'D' into 'C' from '{{.*}}/D.pcm'
+// CHECK: remark: importing module 'C' from '{{.*[/\\]}}C.pcm'
+// CHECK: remark: importing module 'D' into 'C' from '{{.*[/\\]}}D.pcm'
 // CHECK: remark: finished building module 'B'
-// CHECK: remark: importing module 'B' from '{{.*}}/B.pcm'
-// CHECK: remark: importing module 'C' into 'B' from '{{.*}}/C.pcm'
-// CHECK: remark: importing module 'D' into 'C' from '{{.*}}/D.pcm'
+// CHECK: remark: importing module 'B' from '{{.*[/\\]}}B.pcm'
+// CHECK: remark: importing module 'C' into 'B' from '{{.*[/\\]}}C.pcm'
+// CHECK: remark: importing module 'D' into 'C' from '{{.*[/\\]}}D.pcm'
 // CHECK: remark: finished building module 'A'
-// CHECK: remark: importing module 'A' from '{{.*}}/A.pcm'
-// CHECK: remark: importing module 'B' into 'A' from '{{.*}}/B.pcm'
-// CHECK: remark: importing module 'C' into 'B' from '{{.*}}/C.pcm'
-// CHECK: remark: importing module 'D' into 'C' from '{{.*}}/D.pcm'
+// CHECK: remark: importing module 'A' from '{{.*[/\\]}}A.pcm'
+// CHECK: remark: importing module 'B' into 'A' from '{{.*[/\\]}}B.pcm'
+// CHECK: remark: importing module 'C' into 'B' from '{{.*[/\\]}}C.pcm'
+// CHECK: remark: importing module 'D' into 'C' from '{{.*[/\\]}}D.pcm'

Modified: cfe/trunk/test/Modules/relative-import-path.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/relative-import-path.c?rev=355779=355778=355779=diff
==
--- cfe/trunk/test/Modules/relative-import-path.c (original)
+++ cfe/trunk/test/Modules/relative-import-path.c Sat Mar  9 11:33:32 2019

[PATCH] D58893: Modules: Invalidate out-of-date PCMs as they're discovered

2019-03-09 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith closed this revision.
dexonsmith marked 2 inline comments as done.
dexonsmith added a comment.

Committed in r355778.




Comment at: clang/include/clang/Serialization/InMemoryModuleCache.h:37
 
 /// Track the timeline of when this was added to the cache.
+bool IsFinal = false;

bruno wrote:
> Now that generation count is gone, update (or remove) this comment?
Nice catch.  Updated in final patch.


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

https://reviews.llvm.org/D58893



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


r355778 - Modules: Invalidate out-of-date PCMs as they're discovered

2019-03-09 Thread Duncan P. N. Exon Smith via cfe-commits
Author: dexonsmith
Date: Sat Mar  9 09:44:01 2019
New Revision: 355778

URL: http://llvm.org/viewvc/llvm-project?rev=355778=rev
Log:
Modules: Invalidate out-of-date PCMs as they're discovered

Leverage the InMemoryModuleCache to invalidate a module the first time
it fails to import (and to lock a module as soon as it's built or
imported successfully).  For implicit module builds, this optimizes
importing deep graphs where the leaf module is out-of-date; see example
near the end of the commit message.

Previously the cache finalized ("locked in") all modules imported so far
when starting a new module build.  This was sufficient to prevent
loading two versions of the same module, but was somewhat arbitrary and
hard to reason about.

Now the cache explicitly tracks module state, where each module must be
one of:

- Unknown: module not in the cache (yet).
- Tentative: module in the cache, but not yet fully imported.
- ToBuild: module found on disk could not be imported; need to build.
- Final: module in the cache has been successfully built or imported.

Preventing repeated failed imports avoids variation in builds based on
shifting filesystem state.  Now it's guaranteed that a module is loaded
from disk exactly once.  It now seems safe to remove
FileManager::invalidateCache, but I'm leaving that for a later commit.

The new, precise logic uncovered a pre-existing problem in the cache:
the map key is the module filename, and different contexts use different
filenames for the same PCM file.  (In particular, the test
Modules/relative-import-path.c does not build without this commit.
r223577 started using a relative path to describe a module's base
directory when importing it within another module.  As a result, the
module cache sees an absolute path when (a) building the module or
importing it at the top-level, and a relative path when (b) importing
the module underneath another one.)

The "obvious" fix is to resolve paths using FileManager::getVirtualFile
and change the map key for the cache to a FileEntry, but some contexts
(particularly related to ASTUnit) have a shorter lifetime for their
FileManager than the InMemoryModuleCache.  This is worth pursuing
further in a later commit; perhaps by tying together the FileManager and
InMemoryModuleCache lifetime, or moving the in-memory PCM storage into a
VFS layer.

For now, use the PCM's base directory as-written for constructing the
filename to check the ModuleCache.

Example
===

To understand the build optimization, first consider the build of a
module graph TU -> A -> B -> C -> D with an empty cache:

TU builds A'
   A' builds B'
  B' builds C'
 C' builds D'
imports D'
  B' imports C'
 imports D'
   A' imports B'
  imports C'
  imports D'
TU imports A'
   imports B'
   imports C'
   imports D'

If we build TU again, where A, B, C, and D are in the cache and D is
out-of-date, we would previously get this build:

TU imports A
   imports B
   imports C
   imports D (out-of-date)
TU builds A'
   A' imports B
  imports C
  imports D (out-of-date)
  builds B'
  B' imports C
 imports D (out-of-date)
 builds C'
 C' imports D (out-of-date)
builds D'
imports D'
  B' imports C'
 imports D'
   A' imports B'
  imports C'
  imports D'
 TU imports A'
imports B'
imports C'
imports D'

After this commit, we'll immediateley invalidate A, B, C, and D when we
first observe that D is out-of-date, giving this build:

TU imports A
   imports B
   imports C
   imports D (out-of-date)
TU builds A' // The same graph as an empty cache.
   A' builds B'
  B' builds C'
 C' builds D'
imports D'
  B' imports C'
 imports D'
   A' imports B'
  imports C'
  imports D'
TU imports A'
   imports B'
   imports C'
   imports D'

The new build matches what we'd naively expect, pretty closely matching
the original build with the empty cache.

rdar://problem/48545366

Added:
cfe/trunk/test/Modules/Inputs/implicit-invalidate-chain/
cfe/trunk/test/Modules/Inputs/implicit-invalidate-chain/A.h
cfe/trunk/test/Modules/Inputs/implicit-invalidate-chain/B.h
cfe/trunk/test/Modules/Inputs/implicit-invalidate-chain/C.h
cfe/trunk/test/Modules/Inputs/implicit-invalidate-chain/module.modulemap
cfe/trunk/test/Modules/Inputs/relative-import-path/
cfe/trunk/test/Modules/Inputs/relative-import-path/A.h
cfe/trunk/test/Modules/Inputs/relative-import-path/B.h
cfe/trunk/test/Modules/Inputs/relative-import-path/C.h
cfe/trunk/test/Modules/Inputs/relative-import-path/module.modulemap
cfe/trunk/test/Modules/implicit-invalidate-chain.c

[PATCH] D58890: Modules: Rename MemoryBufferCache to InMemoryModuleCache

2019-03-09 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith closed this revision.
dexonsmith added a comment.

Committed in r355777.


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

https://reviews.llvm.org/D58890



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


r355777 - Modules: Rename MemoryBufferCache to InMemoryModuleCache

2019-03-09 Thread Duncan P. N. Exon Smith via cfe-commits
Author: dexonsmith
Date: Sat Mar  9 09:33:56 2019
New Revision: 355777

URL: http://llvm.org/viewvc/llvm-project?rev=355777=rev
Log:
Modules: Rename MemoryBufferCache to InMemoryModuleCache

Change MemoryBufferCache to InMemoryModuleCache, moving it from Basic to
Serialization.  Another patch will start using it to manage module build
more explicitly, but this is split out because it's mostly mechanical.

Because of the move to Serialization we can no longer abuse the
Preprocessor to forward it to the ASTReader.  Besides the rename and
file move, that means Preprocessor::Preprocessor has one fewer parameter
and ASTReader::ASTReader has one more.

Added:
cfe/trunk/include/clang/Serialization/InMemoryModuleCache.h
cfe/trunk/lib/Serialization/InMemoryModuleCache.cpp
cfe/trunk/unittests/Serialization/
cfe/trunk/unittests/Serialization/CMakeLists.txt
cfe/trunk/unittests/Serialization/InMemoryModuleCacheTest.cpp
Removed:
cfe/trunk/include/clang/Basic/MemoryBufferCache.h
cfe/trunk/lib/Basic/MemoryBufferCache.cpp
cfe/trunk/unittests/Basic/MemoryBufferCacheTest.cpp
Modified:
cfe/trunk/include/clang/Frontend/ASTUnit.h
cfe/trunk/include/clang/Frontend/CompilerInstance.h
cfe/trunk/include/clang/Lex/Preprocessor.h
cfe/trunk/include/clang/Serialization/ASTReader.h
cfe/trunk/include/clang/Serialization/ASTWriter.h
cfe/trunk/include/clang/Serialization/Module.h
cfe/trunk/include/clang/Serialization/ModuleManager.h
cfe/trunk/lib/Basic/CMakeLists.txt
cfe/trunk/lib/Frontend/ASTUnit.cpp
cfe/trunk/lib/Frontend/ChainedIncludesSource.cpp
cfe/trunk/lib/Frontend/CompilerInstance.cpp
cfe/trunk/lib/Frontend/FrontendActions.cpp
cfe/trunk/lib/Frontend/PrecompiledPreamble.cpp
cfe/trunk/lib/Frontend/Rewrite/FrontendActions.cpp
cfe/trunk/lib/Lex/Preprocessor.cpp
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp
cfe/trunk/lib/Serialization/CMakeLists.txt
cfe/trunk/lib/Serialization/GeneratePCH.cpp
cfe/trunk/lib/Serialization/ModuleManager.cpp
cfe/trunk/test/Modules/outofdate-rebuild.m
cfe/trunk/unittests/Basic/CMakeLists.txt
cfe/trunk/unittests/Basic/SourceManagerTest.cpp
cfe/trunk/unittests/CMakeLists.txt
cfe/trunk/unittests/Lex/HeaderSearchTest.cpp
cfe/trunk/unittests/Lex/LexerTest.cpp
cfe/trunk/unittests/Lex/PPCallbacksTest.cpp
cfe/trunk/unittests/Lex/PPConditionalDirectiveRecordTest.cpp

Removed: cfe/trunk/include/clang/Basic/MemoryBufferCache.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/MemoryBufferCache.h?rev=355776=auto
==
--- cfe/trunk/include/clang/Basic/MemoryBufferCache.h (original)
+++ cfe/trunk/include/clang/Basic/MemoryBufferCache.h (removed)
@@ -1,79 +0,0 @@
-//===- MemoryBufferCache.h - Cache for loaded memory buffers *- C++ 
-*-===//
-//
-// 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
-//
-//===--===//
-
-#ifndef LLVM_CLANG_BASIC_MEMORYBUFFERCACHE_H
-#define LLVM_CLANG_BASIC_MEMORYBUFFERCACHE_H
-
-#include "llvm/ADT/IntrusiveRefCntPtr.h"
-#include "llvm/ADT/StringMap.h"
-#include 
-
-namespace llvm {
-class MemoryBuffer;
-} // end namespace llvm
-
-namespace clang {
-
-/// Manage memory buffers across multiple users.
-///
-/// Ensures that multiple users have a consistent view of each buffer.  This is
-/// used by \a CompilerInstance when building PCMs to ensure that each \a
-/// ModuleManager sees the same files.
-///
-/// \a finalizeCurrentBuffers() should be called before creating a new user.
-/// This locks in the current buffers, ensuring that no buffer that has already
-/// been accessed can be purged, preventing use-after-frees.
-class MemoryBufferCache : public llvm::RefCountedBase {
-  struct BufferEntry {
-std::unique_ptr Buffer;
-
-/// Track the timeline of when this was added to the cache.
-unsigned Index;
-  };
-
-  /// Cache of buffers.
-  llvm::StringMap Buffers;
-
-  /// Monotonically increasing index.
-  unsigned NextIndex = 0;
-
-  /// Bumped to prevent "older" buffers from being removed.
-  unsigned FirstRemovableIndex = 0;
-
-public:
-  /// Store the Buffer under the Filename.
-  ///
-  /// \pre There is not already buffer is not already in the cache.
-  /// \return a reference to the buffer as a convenience.
-  llvm::MemoryBuffer (llvm::StringRef Filename,
-std::unique_ptr Buffer);
-
-  /// Try to remove a buffer from the cache.
-  ///
-  /// \return false on success, iff \c !isBufferFinal().
-  bool tryToRemoveBuffer(llvm::StringRef Filename);
-
-  /// Get a pointer to the buffer if it exists; else nullptr.
-  llvm::MemoryBuffer 

[PATCH] D59176: Modules: Add LangOptions::CacheGeneratedPCH

2019-03-09 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith created this revision.
dexonsmith added reviewers: bruno, rsmith, vsapsai, jordan_rose.
Herald added a subscriber: jdoerfert.

Add an option to cache the generated PCH in the ModuleCache when
emitting it.  This protects clients that build PCHs and read them in the
same process, allowing them to avoid race conditions between parallel
jobs the same way that Clang's implicit module build system does.


https://reviews.llvm.org/D59176

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Serialization/ASTWriter.h
  clang/lib/Frontend/FrontendActions.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Serialization/GeneratePCH.cpp
  clang/unittests/Frontend/FrontendActionTest.cpp

Index: clang/unittests/Frontend/FrontendActionTest.cpp
===
--- clang/unittests/Frontend/FrontendActionTest.cpp
+++ clang/unittests/Frontend/FrontendActionTest.cpp
@@ -6,18 +6,20 @@
 //
 //===--===//
 
+#include "clang/Frontend/FrontendAction.h"
 #include "clang/AST/ASTConsumer.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/CompilerInvocation.h"
-#include "clang/Frontend/FrontendAction.h"
 #include "clang/Frontend/FrontendActions.h"
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Lex/PreprocessorOptions.h"
 #include "clang/Sema/Sema.h"
+#include "clang/Serialization/InMemoryModuleCache.h"
 #include "llvm/ADT/Triple.h"
 #include "llvm/Support/MemoryBuffer.h"
+#include "llvm/Support/ToolOutputFile.h"
 #include "gtest/gtest.h"
 
 using namespace llvm;
@@ -253,4 +255,40 @@
   EXPECT_EQ("This is a note", TDC->Note.str().str());
 }
 
+TEST(GeneratePCHFrontendAction, CacheGeneratedPCH) {
+  // Create a temporary file for writing out the PCH that will be cleaned up.
+  int PCHFD;
+  llvm::SmallString<128> PCHFilename;
+  ASSERT_FALSE(
+  llvm::sys::fs::createTemporaryFile("test.h", "pch", PCHFD, PCHFilename));
+  llvm::ToolOutputFile PCHFile(PCHFilename, PCHFD);
+
+  for (bool ShouldCache : {false, true}) {
+auto Invocation = std::make_shared();
+Invocation->getLangOpts()->CacheGeneratedPCH = ShouldCache;
+Invocation->getPreprocessorOpts().addRemappedFile(
+"test.h",
+MemoryBuffer::getMemBuffer("int foo(void) { return 1; }\n").release());
+Invocation->getFrontendOpts().Inputs.push_back(
+FrontendInputFile("test.h", InputKind::C));
+Invocation->getFrontendOpts().OutputFile = StringRef(PCHFilename);
+Invocation->getFrontendOpts().ProgramAction = frontend::GeneratePCH;
+Invocation->getTargetOpts().Triple = "x86_64-apple-darwin19.0.0";
+CompilerInstance Compiler;
+Compiler.setInvocation(std::move(Invocation));
+Compiler.createDiagnostics();
+
+GeneratePCHAction TestAction;
+ASSERT_TRUE(Compiler.ExecuteAction(TestAction));
+
+// Check whether the PCH was cached.
+if (ShouldCache)
+  EXPECT_EQ(InMemoryModuleCache::Final,
+Compiler.getModuleCache().getPCMState(PCHFilename));
+else
+  EXPECT_EQ(InMemoryModuleCache::Unknown,
+Compiler.getModuleCache().getPCMState(PCHFilename));
+  }
+}
+
 } // anonymous namespace
Index: clang/lib/Serialization/GeneratePCH.cpp
===
--- clang/lib/Serialization/GeneratePCH.cpp
+++ clang/lib/Serialization/GeneratePCH.cpp
@@ -24,12 +24,14 @@
 const Preprocessor , InMemoryModuleCache ,
 StringRef OutputFile, StringRef isysroot, std::shared_ptr Buffer,
 ArrayRef> Extensions,
-bool AllowASTWithErrors, bool IncludeTimestamps)
+bool AllowASTWithErrors, bool IncludeTimestamps,
+bool ShouldCacheASTInMemory)
 : PP(PP), OutputFile(OutputFile), isysroot(isysroot.str()),
   SemaPtr(nullptr), Buffer(std::move(Buffer)), Stream(this->Buffer->Data),
   Writer(Stream, this->Buffer->Data, ModuleCache, Extensions,
  IncludeTimestamps),
-  AllowASTWithErrors(AllowASTWithErrors) {
+  AllowASTWithErrors(AllowASTWithErrors),
+  ShouldCacheASTInMemory(ShouldCacheASTInMemory) {
   this->Buffer->IsComplete = false;
 }
 
@@ -61,7 +63,8 @@
   Writer.WriteAST(*SemaPtr, OutputFile, Module, isysroot,
   // For serialization we are lenient if the errors were
   // only warn-as-error kind.
-  PP.getDiagnostics().hasUncompilableErrorOccurred());
+  PP.getDiagnostics().hasUncompilableErrorOccurred(),
+  ShouldCacheASTInMemory);
 
   Buffer->IsComplete = true;
 }
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -4595,7 +4595,8 @@
 ASTFileSignature ASTWriter::WriteAST(Sema ,
 

[PATCH] D53608: [builtins] Build float128 soft float builtins for x86_64.

2019-03-09 Thread Manoj Gupta via Phabricator via cfe-commits
manojgupta added a comment.

In D53608#1423692 , @LuoYuanke wrote:

> Hi
>  What's the status for __float128 support? Has it already been finished?


Sorry, haven't looked at time for a while. Consider this change abandoned for 
now :(


Repository:
  rCRT Compiler Runtime

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

https://reviews.llvm.org/D53608



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


[PATCH] D33029: [clang-format] add option for dangling parenthesis

2019-03-09 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.

This review lack unit tests, please add some for FormatTest to show its use 
cases, otherwise someone else will come along and break this later


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

https://reviews.llvm.org/D33029



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


[PATCH] D58878: [Diagnostics] Warn for assignments in bool contexts

2019-03-09 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 marked an inline comment as done.
xbolva00 added inline comments.



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:6738
+  "assignment to bool">,
+  InGroup;
 // Completely identical except off by default.

rjmccall wrote:
> Sorry, I didn't mean to suggest that you should change the existing 
> diagnostic.  You should add a second diagnostic in a new warning group (which 
> should be implied by `-Wparentheses`) that you use just in this case.
> 
> We try to add new warnings this way — even when they're just generalizations 
> of existing warnings — so that they can be independently disabled by e.g. the 
> compiler teams at Apple and Google that need to periodically roll out new 
> compilers across a large codebase.
This is quite problematic to isolate this one since tha patch add 
DiagnoseAssignmentAsCondition call into the PerformImplicitConversion so I 
don't know how to see in PerformImplicitConversion whether we are in the 
condition or not. So, this new warning note wins over current one "using the 
result of an assignment as a condition without parentheses" always :/ 


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

https://reviews.llvm.org/D58878



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


[PATCH] D55170: [clang-format]: Add NonEmptyParentheses spacing option

2019-03-09 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay accepted this revision.
MyDeveloperDay added a comment.
This revision is now accepted and ready to land.

I'm not the code owner but this LGTM,

Assuming the unit tests remain passing, I'd like to see more items like this in 
clang-format addressed, at present we seem to lack getting even bug fixes 
reviewed!

Thank you for breaking out the common code, I do think more functions like this 
in clang-format would help make the code more readable. I also think the 
various if clauses having comment helps break up these huge monolithic if 
statements

Thanks for the patch.


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

https://reviews.llvm.org/D55170



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


[PATCH] D53608: [builtins] Build float128 soft float builtins for x86_64.

2019-03-09 Thread LuoYuanke via Phabricator via cfe-commits
LuoYuanke added a comment.
Herald added a subscriber: jdoerfert.
Herald added projects: LLVM, Sanitizers.

Hi
What's the status for __float128 support? Has it already been finished?


Repository:
  rCRT Compiler Runtime

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

https://reviews.llvm.org/D53608



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


Re: [RFC 00/12] Introduce struct layout randomization feature

2019-03-09 Thread Roman Lebedev via cfe-commits
You probably want to submit this patchset to phabricator.
It will get lost in mailing list.

On Sat, Mar 9, 2019 at 1:38 AM Connor Kuehl via cfe-commits
 wrote:
>
> This patch set introduces structure field layout randomization into the Clang
> compiler. The Randstruct feature is a compile-time hardening technique that
> randomizes the field layout for designated structures of a code base.
> Admittedly, this is mostly useful for closed-source releases of code (since
> the randomization seed would be available for public and open source 
> application
> s). However, this patch set also enhances Clang’s feature parity with that
> of GCC which already has the Randstruct feature.
>
> This patch set is a from-scratch reimplementation of the Randstruct feature
> that was originally ported to GCC. The patches for this implementation in GCC
> can be found here:
>
> https://www.openwall.com/lists/kernel-hardening/2017/04/06/14.
>
> This feature identifies structures for randomization in two ways. The first
> method targets structures that are manually marked with the new
> “randomize_layout” attribute. The second is an optional feature that will
> automatically select and randomize structures that are found to consist 
> entirely
> of function pointers. This automatic selection feature can be extended to
> include other vulnerable structure types that are safe to randomize as they 
> are
> identified. You can also opt a specific structure out of this feature with the
> “no_randomize_layout” attribute. Automatic structure selection is enabled with
> the “-randstruct-auto” compiler flag. By default, Randstruct seeds on the 
> empty
> string, but a seed can be supplied with the “-randstruct-seed=” command line
> argument.
>
> This entire patch set is the sum total of an undergraduate computer science
> capstone team’s effort.
>
> Portland State University Clang Randstruct Capstone Team (Fall 2018-Winter 
> 2019):
>
> Co-authored-by: Cole Nixon 
> Co-authored-by: Connor Kuehl 
> Co-authored-by: James Foster 
> Co-authored-by: Jeff Takahashi 
> Co-authored-by: Jordan Cantrell 
> Co-authored-by: Nikk Forbus 
> Co-authored-by: Tim Pugh 
>
> Connor Kuehl (12):
>   Add documentation for randstruct attributes
>   Add randomize_layout attribute and handler
>   Add no_randomize_layout attribute and handler
>   Add randomize_layout warning for unions
>   Add warning for mutually exclusive attributes
>   Add globals to store command line arguments in
>   Add randstruct-seed compiler argument
>   Add automatic structure selection compiler switch
>   Implement record field randomization algorithms
>   Fix: Set tail pointer to null in field list
>   Forward declare RecordFieldReorganizer
>   Wire up Randstruct; intercept and randomize
>
>  clang/include/clang/AST/Decl.h|   1 +
>  clang/include/clang/AST/DeclBase.h|   2 +
>  clang/include/clang/AST/RandstructSeed.h  |   8 +
>  .../clang/AST/RecordFieldReorganizer.h|  59 
>  clang/include/clang/Basic/Attr.td |  14 +
>  clang/include/clang/Basic/AttrDocs.td |  45 +++
>  .../include/clang/Basic/DiagnosticASTKinds.td |   5 +
>  clang/include/clang/Driver/CC1Options.td  |   2 +
>  clang/include/clang/Driver/Options.td |   4 +
>  clang/lib/AST/CMakeLists.txt  |   1 +
>  clang/lib/AST/DeclBase.cpp|   3 +
>  clang/lib/AST/RecordFieldReorganizer.cpp  | 257 ++
>  clang/lib/AST/RecordLayoutBuilder.cpp |  20 ++
>  clang/lib/Driver/ToolChains/Clang.cpp |  10 +
>  clang/lib/Frontend/CompilerInvocation.cpp |   8 +
>  clang/lib/Sema/SemaDeclAttr.cpp   |   6 +
>  ...a-attribute-supported-attributes-list.test |   2 +
>  17 files changed, 447 insertions(+)
>  create mode 100644 clang/include/clang/AST/RandstructSeed.h
>  create mode 100644 clang/include/clang/AST/RecordFieldReorganizer.h
>  create mode 100644 clang/lib/AST/RecordFieldReorganizer.cpp
>
> --
> 2.17.1
>
> ___
> 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] D58367: [analyzer] NFC: Improve upon the concept of BugReporterVisitor.

2019-03-09 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun accepted this revision.
xazax.hun added a comment.

LG!

It is an interesting idea to use this facility for `trackExpressionValue`. But 
I would expect such a mechanism to trigger quite often. I wonder if the memory 
consumption would increase significantly by storing a lambda for almost every 
binding for each path.
Right now we reclaim the memory after we finished analyzing a top-level 
function. If memory proves to be a problem, we could maybe reclaim memory for 
every non-buggy path analyzed? Of course, I prefer the simplicity of the 
current solution and hope that we never need to consider more complicated 
cleanup logic :)




Comment at: 
clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h:400
+
+  friend class Factory;
+  friend class TagVisitor;

Isn't this redundant?



Comment at: clang/lib/StaticAnalyzer/Checkers/MIGChecker.cpp:165
 
-  C.addTransition(C.getState()->set(PVD));
+  const NoteTag *T = C.getNoteTag([this, PVD](BugReport ) -> std::string {
+if (() != )

I am not very familiar with this check but wonder don't you miss an 
"isInteresting" check somewhere? Where do we filter the notes that are 
unrelated to the bug paths?


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

https://reviews.llvm.org/D58367



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