[PATCH] D65997: Add options rounding and exceptions to pragma fp

2019-08-16 Thread Serge Pavlov via Phabricator via cfe-commits
sepavloff marked 2 inline comments as done.
sepavloff added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:3152
+rounding mode. This option is experimental; the compiler may ignore an explicit
+rounding mode in some situations.
+

andrew.w.kaylor wrote:
> You should say something about whether the rounding mode is applied or 
> assumed. The rounding mode argument in the constrained FP intrinsics is 
> assumed. The compiler is not required to do anything to force the hardware 
> into that rounding mode. I think we want that behavior here as well. I 
> believe this follows the semantics of the STDC FENV_ROUND pragmas that were 
> introduced by ISO TS-18661.
Hm. I understood the proposal as if pragma FENV_ROUND is applied. If I am 
wrong, and that pragma is only a hint to compiler, it is not suitable for our 
purposes. We need a mean to generate constrained intrinsics from C/C++ code. it 
would facilitate adaptation of LLVM passes for specific floating point options, 
including rounding, exception behavior, FENV_ACCESS an so on. It also would 
allow users to tune code generation. In this case `pragma FENV_ROUND` is a 
different functionality, which should be developed separately.



Comment at: clang/docs/LanguageExtensions.rst:3159
+This option is experimental; the compiler may ignore an explicit exception
+behavior in some situations.
+

andrew.w.kaylor wrote:
> I'm not sure what this is supposed to mean. What are the circumstances under 
> which the compiler may ignore an explicit exception behavior? Do you mean 
> that it isn't supposed to happen but it might while the feature is under 
> development?
The purpose is to have a tool that would allow developing support of 
constrained nodes in LLVM pipeline. So we discourage using this pragma by end 
users. Yes, you are right, it means a feature under development.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65997



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


[PATCH] D65997: Add options rounding and exceptions to pragma fp

2019-08-16 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

Since LLVM already has strict FP nodes, i'd personally like to see this RFC to 
not
discuss "let's add XYZ", but discuss what features it targets to accomplish,
what features are already achievable via strict FP nodes,
and instead of adding a third set of FP operations,
try to propose to extend strict FP nodes,


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65997



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


[PATCH] D66221: [clangd] Added highlighting for non type templates.

2019-08-16 Thread Johan Vikström via Phabricator via cfe-commits
jvikstrom marked an inline comment as done.
jvikstrom added inline comments.



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:231
+  if (TP->isFunctionPointerType()) {
+addToken(Loc, HighlightingKind::Function);
+return;

ilya-biryukov wrote:
> Why do we special-case template parameters, but not other kinds of variables?
> We definitely need a comment explaining why template parameters are handled 
> in a special way, but variables, parameters, fields are not.
Not quite sure what you mean about variables/parameters/fields not being 
handled in a special way.

The reason for special casing non type templates is because it probably gives 
more information/is more valuable to highlight a reference/pointer as a 
variable rather than a normal template parameter (same for methods/functions).

But maybe they all should just be highlighted as with the TemplateParameter 
kind instead?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66221



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


Re: r368940 - Fix handling of class member access into a vector type.

2019-08-16 Thread Hans Wennborg via cfe-commits
Not at all; merged it in r369087. Please let me know if there are any
follow-ups.

Thanks,
Hans

On Thu, Aug 15, 2019 at 7:08 PM Richard Smith  wrote:
>
> Hi Hans,
>
> This fixes a regression in Clang 9; is it too late to get this into the 
> release?
>
> -- Forwarded message -
> From: Richard Smith via cfe-commits 
> Date: Wed, 14 Aug 2019 at 15:56
> Subject: r368940 - Fix handling of class member access into a vector type.
> To: 
>
>
> Author: rsmith
> Date: Wed Aug 14 15:57:50 2019
> New Revision: 368940
>
> URL: http://llvm.org/viewvc/llvm-project?rev=368940&view=rev
> Log:
> Fix handling of class member access into a vector type.
>
> When handling a member access into a non-class, non-ObjC-object type, we
> would perform a lookup into the surrounding scope as if for an
> unqualified lookup. If the member access was followed by a '<' and this
> lookup (or the typo-correction for it) found a template name, we'd treat
> the member access as naming that template.
>
> Now we treat such accesses as never naming a template if the type of the
> object expression is of vector type, so that vector component accesses
> are never misinterpreted as naming something else. This is not entirely
> correct, since it is in fact valid to name a template from the enclosing
> scope in this context, when invoking a pseudo-destructor for the vector
> type via an alias template, but that's very much a corner case, and this
> change leaves that case only as broken as the corresponding case for
> Objective-C types is.
>
> This incidentally adds support for dr2292, which permits a 'template'
> keyword at the start of a member access naming a pseudo-destructor.
>
> Modified:
> cfe/trunk/lib/Sema/SemaExprCXX.cpp
> cfe/trunk/lib/Sema/SemaTemplate.cpp
> cfe/trunk/test/CXX/drs/dr22xx.cpp
> cfe/trunk/test/CXX/drs/dr4xx.cpp
> cfe/trunk/test/SemaCXX/cxx2a-adl-only-template-id.cpp
> cfe/trunk/test/SemaCXX/pseudo-destructors.cpp
> cfe/trunk/test/SemaCXX/vector.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaExprCXX.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExprCXX.cpp?rev=368940&r1=368939&r2=368940&view=diff
> ==
> --- cfe/trunk/lib/Sema/SemaExprCXX.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaExprCXX.cpp Wed Aug 14 15:57:50 2019
> @@ -6794,14 +6794,10 @@ ExprResult Sema::ActOnStartCXXMemberRefe
>// it's legal for the type to be incomplete if this is a pseudo-destructor
>// call.  We'll do more incomplete-type checks later in the lookup process,
>// so just skip this check for ObjC types.
> -  if (BaseType->isObjCObjectOrInterfaceType()) {
> +  if (!BaseType->isRecordType()) {
>  ObjectType = ParsedType::make(BaseType);
>  MayBePseudoDestructor = true;
>  return Base;
> -  } else if (!BaseType->isRecordType()) {
> -ObjectType = nullptr;
> -MayBePseudoDestructor = true;
> -return Base;
>}
>
>// The object type must be complete (or dependent), or
>
> Modified: cfe/trunk/lib/Sema/SemaTemplate.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplate.cpp?rev=368940&r1=368939&r2=368940&view=diff
> ==
> --- cfe/trunk/lib/Sema/SemaTemplate.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaTemplate.cpp Wed Aug 14 15:57:50 2019
> @@ -362,13 +362,27 @@ bool Sema::LookupTemplateName(LookupResu
>  // x->B::f, and we are looking into the type of the object.
>  assert(!SS.isSet() && "ObjectType and scope specifier cannot coexist");
>  LookupCtx = computeDeclContext(ObjectType);
> -IsDependent = !LookupCtx;
> +IsDependent = !LookupCtx && ObjectType->isDependentType();
>  assert((IsDependent || !ObjectType->isIncompleteType() ||
>  ObjectType->castAs()->isBeingDefined()) &&
> "Caller should have completed object type");
>
> -// Template names cannot appear inside an Objective-C class or object 
> type.
> -if (ObjectType->isObjCObjectOrInterfaceType()) {
> +// Template names cannot appear inside an Objective-C class or object 
> type
> +// or a vector type.
> +//
> +// FIXME: This is wrong. For example:
> +//
> +//   template using Vec = T 
> __attribute__((ext_vector_type(4)));
> +//   Vec vi;
> +//   vi.Vec::~Vec();
> +//
> +// ... should be accepted but we will not treat 'Vec' as a template name
> +// here. The right thing to do would be to check if the name is a valid
> +// vector component name, and look up a template name if not. And 
> similarly
> +// for lookups into Objective-C class and object types, where the same
> +// problem can arise.
> +if (ObjectType->isObjCObjectOrInterfaceType() ||
> +ObjectType->isVectorType()) {
>Found.clear();
>return false;
>  }
>
> Modified: cfe/trunk/test/CXX/drs/dr22xx.cpp
> URL: 
> http://llvm.o

[PATCH] D66333: NonNullParamChecker and CStringChecker parameter number in checker message

2019-08-16 Thread Tibor Brunner via Phabricator via cfe-commits
bruntib created this revision.
bruntib added reviewers: alexfh, NoQ, Szelethus, xazax.hun.
Herald added subscribers: cfe-commits, rnkovacs.
Herald added a project: clang.

There are some functions which can't be given a null pointer as parameter 
either because it has a nonnull attribute or it is declared to have undefined 
behavior (e.g. strcmp()). Sometimes it is hard to determine from the checker 
message which parameter is null at the invocation, so now this information is 
included in the message.

This commit fixes https://bugs.llvm.org/show_bug.cgi?id=39358


Repository:
  rC Clang

https://reviews.llvm.org/D66333

Files:
  clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/NonNullParamChecker.cpp
  clang/test/Analysis/Inputs/expected-plists/edges-new.mm.plist
  clang/test/Analysis/Inputs/expected-plists/plist-output.m.plist
  clang/test/Analysis/misc-ps-region-store.m
  clang/test/Analysis/null-deref-ps.c

Index: clang/test/Analysis/null-deref-ps.c
===
--- clang/test/Analysis/null-deref-ps.c
+++ clang/test/Analysis/null-deref-ps.c
@@ -88,21 +88,21 @@
 int bar(int* p, int q) __attribute__((nonnull));
 
 int f6(int *p) { 
-  return !p ? bar(p, 1) // expected-warning {{Null pointer passed as an argument to a 'nonnull' parameter}}
+  return !p ? bar(p, 1) // expected-warning {{Null pointer passed as an argument to a 'nonnull' 1st parameter}}
  : bar(p, 0);   // no-warning
 }
 
 int bar2(int* p, int q) __attribute__((nonnull(1)));
 
 int f6b(int *p) { 
-  return !p ? bar2(p, 1) // expected-warning {{Null pointer passed as an argument to a 'nonnull' parameter}}
+  return !p ? bar2(p, 1) // expected-warning {{Null pointer passed as an argument to a 'nonnull' 1st parameter}}
  : bar2(p, 0);   // no-warning
 }
 
 int bar3(int*p, int q, int *r) __attribute__((nonnull(1,3)));
 
 int f6c(int *p, int *q) {
-   return !p ? bar3(q, 2, p) // expected-warning {{Null pointer passed as an argument to a 'nonnull' parameter}}
+   return !p ? bar3(q, 2, p) // expected-warning {{Null pointer passed as an argument to a 'nonnull' 3rd parameter}}
  : bar3(p, 2, q); // no-warning
 }
 
Index: clang/test/Analysis/misc-ps-region-store.m
===
--- clang/test/Analysis/misc-ps-region-store.m
+++ clang/test/Analysis/misc-ps-region-store.m
@@ -1205,7 +1205,7 @@
 void rdar_8642434_funcB(struct rdar_8642434_typeA *x, struct rdar_8642434_typeA *y) {
   rdar_8642434_funcA(x);
   if (!y)
-rdar_8642434_funcA(y); // expected-warning{{Null pointer passed as an argument to a 'nonnull' parameter}}
+rdar_8642434_funcA(y); // expected-warning{{Null pointer passed as an argument to a 'nonnull' 1st parameter}}
 }
 
 //  - Handle loads and stores from a symbolic index
Index: clang/test/Analysis/Inputs/expected-plists/plist-output.m.plist
===
--- clang/test/Analysis/Inputs/expected-plists/plist-output.m.plist
+++ clang/test/Analysis/Inputs/expected-plists/plist-output.m.plist
@@ -6141,12 +6141,12 @@
  
  depth0
  extended_message
- Null pointer passed as an argument to a 'nonnull' parameter
+ Null pointer passed as an argument to a 'nonnull' 1st parameter
  message
- Null pointer passed as an argument to a 'nonnull' parameter
+ Null pointer passed as an argument to a 'nonnull' 1st parameter
 

-   descriptionNull pointer passed as an argument to a 'nonnull' parameter
+   descriptionNull pointer passed as an argument to a 'nonnull' 1st parameter
categoryAPI
typeArgument with 'nonnull' attribute passed null
check_namecore.NonNullParamChecker
Index: clang/test/Analysis/Inputs/expected-plists/edges-new.mm.plist
===
--- clang/test/Analysis/Inputs/expected-plists/edges-new.mm.plist
+++ clang/test/Analysis/Inputs/expected-plists/edges-new.mm.plist
@@ -10853,12 +10853,12 @@
  
  depth0
  extended_message
- Null pointer passed as an argument to a 'nonnull' parameter
+ Null pointer passed as an argument to a 'nonnull' 1st parameter
  message
- Null pointer passed as an argument to a 'nonnull' parameter
+ Null pointer passed as an argument to a 'nonnull' 1st parameter
 

-   descriptionNull pointer passed as an argument to a 'nonnull' parameter
+   descriptionNull pointer passed as an argument to a 'nonnull' 1st parameter
categoryAPI
typeArgument with 'nonnull' attribute passed null
check_namecore.NonNullParamChecker
Index: clang/lib/StaticAnalyzer/Checkers/NonNullParamChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/NonNullParamChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/NonNullParamChecker.cpp
@@ -36,7 +36,9 @@
   void checkPreCall(const CallEvent &Call, Check

[PATCH] D66221: [clangd] Added highlighting for non type templates.

2019-08-16 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added inline comments.



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:231
+  if (TP->isFunctionPointerType()) {
+addToken(Loc, HighlightingKind::Function);
+return;

jvikstrom wrote:
> ilya-biryukov wrote:
> > Why do we special-case template parameters, but not other kinds of 
> > variables?
> > We definitely need a comment explaining why template parameters are handled 
> > in a special way, but variables, parameters, fields are not.
> Not quite sure what you mean about variables/parameters/fields not being 
> handled in a special way.
> 
> The reason for special casing non type templates is because it probably gives 
> more information/is more valuable to highlight a reference/pointer as a 
> variable rather than a normal template parameter (same for methods/functions).
> 
> But maybe they all should just be highlighted as with the TemplateParameter 
> kind instead?
> Not quite sure what you mean about variables/parameters/fields not being 
> handled in a special way.
Non-type template parameters are very similar to global and local variables, 
function parameters, class fields, etc.
We could also match those on type and highlight differently based on the type.

> The reason for special casing non type templates is because it probably gives 
> more information/is more valuable to highlight a reference/pointer as a 
> variable rather than a normal template parameter (same for methods/functions).
However, if a global variable has a function pointer type we do not highlight 
it as a function. Why would this be different?

> But maybe they all should just be highlighted as with the TemplateParameter 
> kind instead?
I would personally vouch for this option. The highlighting functionality lets 
me understand what the name resolves to; if it's a template parameter and it 
would be highlighted as a variable instead, this would create confusion on my 
end. If I need to know the type I'll look at completion results or hover.

It is my personal preference and I'm ok with this going in a different 
direction if you feel the opposite is better. Just asking to put the rationale 
of this decision (why do this only for template parameters and not other 
things) in a comment somewhere in the source code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66221



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


[clang-tools-extra] r369089 - [clangd] Remove Bind, use C++14 lambda captures instead. NFC

2019-08-16 Thread Ilya Biryukov via cfe-commits
Author: ibiryukov
Date: Fri Aug 16 02:20:01 2019
New Revision: 369089

URL: http://llvm.org/viewvc/llvm-project?rev=369089&view=rev
Log:
[clangd] Remove Bind, use C++14 lambda captures instead. NFC

Modified:
clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
clang-tools-extra/trunk/clangd/Function.h
clang-tools-extra/trunk/clangd/unittests/SyncAPI.cpp

Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp?rev=369089&r1=369088&r2=369089&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp Fri Aug 16 02:20:01 2019
@@ -603,8 +603,11 @@ void ClangdLSPServer::onCommand(const Ex
 // 6. The editor applies the changes (applyEdit), and sends us a reply
 // 7. We unwrap the reply and send a reply to the editor.
 ApplyEdit(*Params.workspaceEdit,
-  Bind(ReplyAfterApplyingEdit, std::move(Reply),
-   std::string("Fix applied.")));
+  [Reply = std::move(Reply), ReplyAfterApplyingEdit](
+  llvm::Expected Response) mutable 
{
+ReplyAfterApplyingEdit(std::move(Reply), "Fix applied.",
+   std::move(Response));
+  });
   } else if (Params.command == ExecuteCommandParams::CLANGD_APPLY_TWEAK &&
  Params.tweakArgs) {
 auto Code = DraftMgr.getDraft(Params.tweakArgs->file.file());
@@ -624,8 +627,13 @@ void ClangdLSPServer::onCommand(const Ex
 WorkspaceEdit WE;
 WE.changes.emplace();
 (*WE.changes)[File.uri()] = replacementsToEdits(Code, *R->ApplyEdit);
-ApplyEdit(std::move(WE), Bind(ReplyAfterApplyingEdit, std::move(Reply),
-  std::string("Tweak applied.")));
+ApplyEdit(
+std::move(WE),
+[Reply = std::move(Reply), ReplyAfterApplyingEdit](
+llvm::Expected Response) mutable {
+  ReplyAfterApplyingEdit(std::move(Reply), "Tweak applied.",
+ std::move(Response));
+});
   }
   if (R->ShowMessage) {
 ShowMessageParams Msg;

Modified: clang-tools-extra/trunk/clangd/Function.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Function.h?rev=369089&r1=369088&r2=369089&view=diff
==
--- clang-tools-extra/trunk/clangd/Function.h (original)
+++ clang-tools-extra/trunk/clangd/Function.h Fri Aug 16 02:20:01 2019
@@ -27,62 +27,6 @@ namespace clangd {
 template 
 using Callback = llvm::unique_function)>;
 
-/// Stores a callable object (Func) and arguments (Args) and allows to call the
-/// callable with provided arguments later using `operator ()`. The arguments
-/// are std::forward'ed into the callable in the body of `operator()`. 
Therefore
-/// `operator()` can only be called once, as some of the arguments could be
-/// std::move'ed into the callable on first call.
-template  struct ForwardBinder {
-  using Tuple = std::tuple::type,
-   typename std::decay::type...>;
-  Tuple FuncWithArguments;
-#ifndef NDEBUG
-  bool WasCalled = false;
-#endif
-
-public:
-  ForwardBinder(Tuple FuncWithArguments)
-  : FuncWithArguments(std::move(FuncWithArguments)) {}
-
-private:
-  template 
-  auto CallImpl(std::integer_sequence Seq,
-RestArgs &&... Rest)
-  -> decltype(std::get<0>(this->FuncWithArguments)(
-  std::forward(std::get(this->FuncWithArguments))...,
-  std::forward(Rest)...)) {
-return std::get<0>(this->FuncWithArguments)(
-std::forward(std::get(this->FuncWithArguments))...,
-std::forward(Rest)...);
-  }
-
-public:
-  template 
-  auto operator()(RestArgs &&... Rest)
-  -> decltype(this->CallImpl(std::index_sequence_for(),
- std::forward(Rest)...)) {
-
-#ifndef NDEBUG
-assert(!WasCalled && "Can only call result of Bind once.");
-WasCalled = true;
-#endif
-return CallImpl(std::index_sequence_for(),
-std::forward(Rest)...);
-  }
-};
-
-/// Creates an object that stores a callable (\p F) and first arguments to the
-/// callable (\p As) and allows to call \p F with \Args at a later point.
-/// Similar to std::bind, but also works with move-only \p F and \p As.
-///
-/// The returned object must be called no more than once, as \p As are
-/// std::forwarded'ed (therefore can be moved) into \p F during the call.
-template 
-ForwardBinder Bind(Func F, Args &&... As) {
-  return ForwardBinder(
-  std::make_tuple(std::forward(F), std::forward(As)...));
-}
-
 /// An Event allows events of type T to be broadcast to listeners.
 template  class Event {
 public:

Modified: clang-tools-extra/trunk/clangd/unittest

[PATCH] D66221: [clangd] Added highlighting for non type templates.

2019-08-16 Thread Johan Vikström via Phabricator via cfe-commits
jvikstrom added inline comments.



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:231
+  if (TP->isFunctionPointerType()) {
+addToken(Loc, HighlightingKind::Function);
+return;

ilya-biryukov wrote:
> jvikstrom wrote:
> > ilya-biryukov wrote:
> > > Why do we special-case template parameters, but not other kinds of 
> > > variables?
> > > We definitely need a comment explaining why template parameters are 
> > > handled in a special way, but variables, parameters, fields are not.
> > Not quite sure what you mean about variables/parameters/fields not being 
> > handled in a special way.
> > 
> > The reason for special casing non type templates is because it probably 
> > gives more information/is more valuable to highlight a reference/pointer as 
> > a variable rather than a normal template parameter (same for 
> > methods/functions).
> > 
> > But maybe they all should just be highlighted as with the TemplateParameter 
> > kind instead?
> > Not quite sure what you mean about variables/parameters/fields not being 
> > handled in a special way.
> Non-type template parameters are very similar to global and local variables, 
> function parameters, class fields, etc.
> We could also match those on type and highlight differently based on the type.
> 
> > The reason for special casing non type templates is because it probably 
> > gives more information/is more valuable to highlight a reference/pointer as 
> > a variable rather than a normal template parameter (same for 
> > methods/functions).
> However, if a global variable has a function pointer type we do not highlight 
> it as a function. Why would this be different?
> 
> > But maybe they all should just be highlighted as with the TemplateParameter 
> > kind instead?
> I would personally vouch for this option. The highlighting functionality lets 
> me understand what the name resolves to; if it's a template parameter and it 
> would be highlighted as a variable instead, this would create confusion on my 
> end. If I need to know the type I'll look at completion results or hover.
> 
> It is my personal preference and I'm ok with this going in a different 
> direction if you feel the opposite is better. Just asking to put the 
> rationale of this decision (why do this only for template parameters and not 
> other things) in a comment somewhere in the source code.
> I would personally vouch for this option. The highlighting functionality lets 
> me understand what the name resolves to;

Very true actually, was a bit unsure what was the correct way to go but this is 
very true actually.

Changing to just highlight as TemplateParameter. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66221



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


[PATCH] D66221: [clangd] Added highlighting for non type templates.

2019-08-16 Thread Johan Vikström via Phabricator via cfe-commits
jvikstrom updated this revision to Diff 215544.
jvikstrom marked an inline comment as done.
jvikstrom added a comment.

Highlight as TemplateParameter.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66221

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -323,6 +323,59 @@
   $Primitive[[auto]] $Variable[[Form]] = 10.2 + 2 * 4;
   $Primitive[[decltype]]($Variable[[Form]]) $Variable[[F]] = 10;
   auto $Variable[[Fun]] = []()->$Primitive[[void]]{};
+)cpp",
+R"cpp(
+  class $Class[[G]] {};
+  template<$Class[[G]] *$TemplateParameter[[U]]>
+  class $Class[[GP]] {};
+  template<$Class[[G]] &$TemplateParameter[[U]]>
+  class $Class[[GR]] {};
+  template<$Primitive[[int]] *$TemplateParameter[[U]]>
+  class $Class[[IP]] {
+$Primitive[[void]] $Method[[f]]() {
+  *$TemplateParameter[[U]] += 5;
+}
+  };
+  template<$Primitive[[unsigned]] $TemplateParameter[[U]] = 2>
+  class $Class[[Foo]] {
+$Primitive[[void]] $Method[[f]]() {
+  for($Primitive[[int]] $Variable[[I]] = 0;
+$Variable[[I]] < $TemplateParameter[[U]];) {}
+}
+  };
+
+  $Class[[G]] $Variable[[L]];
+  $Primitive[[void]] $Function[[f]]() {
+$Class[[Foo]]<123> $Variable[[F]];
+$Class[[GP]]<&$Variable[[L]]> $Variable[[LL]];
+$Class[[GR]]<$Variable[[L]]> $Variable[[LLL]];
+  }
+)cpp",
+R"cpp(
+  template
+  struct $Class[[G]] {
+$Primitive[[void]] $Method[[foo]](
+$TemplateParameter[[T]] *$Variable[[O]]) {
+  ($Variable[[O]]->*$TemplateParameter[[method]])(10);
+}
+  };
+  struct $Class[[F]] {
+$Primitive[[void]] $Method[[f]]($Primitive[[int]]);
+  };
+  template<$Primitive[[void]] (*$TemplateParameter[[Func]])()>
+  struct $Class[[A]] {
+$Primitive[[void]] $Method[[f]]() {
+  (*$TemplateParameter[[Func]])();
+}
+  };
+
+  $Primitive[[void]] $Function[[foo]]() {
+$Class[[F]] $Variable[[FF]];
+$Class[[G]]<$Class[[F]], &$Class[[F]]::$Method[[f]]> $Variable[[GG]];
+$Variable[[GG]].$Method[[foo]](&$Variable[[FF]]);
+$Class[[A]]<$Function[[foo]]> $Variable[[AA]];
+  }
 )cpp"};
   for (const auto &TestCase : TestCases) {
 checkHighlightings(TestCase);
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -224,6 +224,10 @@
   addToken(Loc, HighlightingKind::TemplateParameter);
   return;
 }
+if (isa(D)) {
+  addToken(Loc, HighlightingKind::TemplateParameter);
+  return;
+}
   }
 
   void addToken(SourceLocation Loc, HighlightingKind Kind) {


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -323,6 +323,59 @@
   $Primitive[[auto]] $Variable[[Form]] = 10.2 + 2 * 4;
   $Primitive[[decltype]]($Variable[[Form]]) $Variable[[F]] = 10;
   auto $Variable[[Fun]] = []()->$Primitive[[void]]{};
+)cpp",
+R"cpp(
+  class $Class[[G]] {};
+  template<$Class[[G]] *$TemplateParameter[[U]]>
+  class $Class[[GP]] {};
+  template<$Class[[G]] &$TemplateParameter[[U]]>
+  class $Class[[GR]] {};
+  template<$Primitive[[int]] *$TemplateParameter[[U]]>
+  class $Class[[IP]] {
+$Primitive[[void]] $Method[[f]]() {
+  *$TemplateParameter[[U]] += 5;
+}
+  };
+  template<$Primitive[[unsigned]] $TemplateParameter[[U]] = 2>
+  class $Class[[Foo]] {
+$Primitive[[void]] $Method[[f]]() {
+  for($Primitive[[int]] $Variable[[I]] = 0;
+$Variable[[I]] < $TemplateParameter[[U]];) {}
+}
+  };
+
+  $Class[[G]] $Variable[[L]];
+  $Primitive[[void]] $Function[[f]]() {
+$Class[[Foo]]<123> $Variable[[F]];
+$Class[[GP]]<&$Variable[[L]]> $Variable[[LL]];
+$Class[[GR]]<$Variable[[L]]> $Variable[[LLL]];
+  }
+)cpp",
+R"cpp(
+  template
+  struct $Class[[G]] {
+$Primitive[[void]] $Method[[foo]](
+$TemplateParameter[[T]] *$Variable[[O]]) {
+  ($Variable[[O]]->*$TemplateParameter[[method]])(10);
+}
+  };
+  struct $Class[[F]] 

[PATCH] D65935: [ASTImporter] Import ctor initializers after setting flags.

2019-08-16 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added a comment.

LLDB probably does the import in other way. CTU test fails without the fix:

  FAIL: Clang :: Analysis/ctu-main.cpp (540 of 15341)
   TEST 'Clang :: Analysis/ctu-main.cpp' FAILED 

  Script:
  --
  : 'RUN: at line 1';   rm -rf 
build/Release/tools/clang/test/Analysis/Output/ctu-main.cpp.tmp && mkdir 
build/Release/tools/clang/test/Analysis/Output/ctu-main.cpp.tmp
  : 'RUN: at line 2';   mkdir -p 
build/Release/tools/clang/test/Analysis/Output/ctu-main.cpp.tmp/ctudir
  : 'RUN: at line 3';   build/Release/bin/clang -cc1 -internal-isystem 
build/Release/lib/clang/10.0.0/include -nostdsysteminc -triple 
x86_64-pc-linux-gnu-emit-pch -o 
build/Release/tools/clang/test/Analysis/Output/ctu-main.cpp.tmp/ctudir/ctu-other.cpp.ast
 llvm-project/clang/test/Analysis/Inputs/ctu-other.cpp
  : 'RUN: at line 5';   build/Release/bin/clang -cc1 -internal-isystem 
build/Release/lib/clang/10.0.0/include -nostdsysteminc -triple 
x86_64-pc-linux-gnu-emit-pch -o 
build/Release/tools/clang/test/Analysis/Output/ctu-main.cpp.tmp/ctudir/ctu-chain.cpp.ast
 llvm-project/clang/test/Analysis/Inputs/ctu-chain.cpp
  : 'RUN: at line 7';   cp 
llvm-project/clang/test/Analysis/Inputs/ctu-other.cpp.externalDefMap.txt 
build/Release/tools/clang/test/Analysis/Output/ctu-main.cpp.tmp/ctudir/externalDefMap.txt
  : 'RUN: at line 8';   build/Release/bin/clang -cc1 -internal-isystem 
build/Release/lib/clang/10.0.0/include -nostdsysteminc -analyze 
-analyzer-constraints=range -triple x86_64-pc-linux-gnu
-analyzer-checker=core,debug.ExprInspection-analyzer-config 
experimental-enable-naive-ctu-analysis=true-analyzer-config 
ctu-dir=build/Release/tools/clang/test/Analysis/Output/ctu-main.cpp.tmp/ctudir  
  -verify llvm-project/clang/test/Analysis/ctu-main.cpp
  : 'RUN: at line 13';   build/Release/bin/clang -cc1 -internal-isystem 
build/Release/lib/clang/10.0.0/include -nostdsysteminc -analyze 
-analyzer-constraints=range -triple x86_64-pc-linux-gnu
-analyzer-checker=core,debug.ExprInspection-analyzer-config 
experimental-enable-naive-ctu-analysis=true-analyzer-config 
ctu-dir=build/Release/tools/clang/test/Analysis/Output/ctu-main.cpp.tmp/ctudir  
  -analyzer-config display-ctu-progress=true 2>&1 
llvm-project/clang/test/Analysis/ctu-main.cpp | build/Release/bin/FileCheck 
llvm-project/clang/test/Analysis/ctu-main.cpp
  --
  Exit Code: 134
  
  Command Output (stderr):
  --
  clang: llvm-project/clang/lib/AST/DeclBase.cpp:939: bool 
clang::Decl::AccessDeclContextSanity() const: Assertion `Access != AS_none && 
"Access specifier is AS_none inside a record decl"' failed.
  Stack dump:
  0.  Program arguments: build/Release/bin/clang -cc1 -internal-isystem 
build/Release/lib/clang/10.0.0/include -nostdsysteminc -analyze 
-analyzer-constraints=range -triple x86_64-pc-linux-gnu 
-analyzer-checker=core,debug.ExprInspection -analyzer-config 
experimental-enable-naive-ctu-analysis=true -analyzer-config 
ctu-dir=build/Release/tools/clang/test/Analysis/Output/ctu-main.cpp.tmp/ctudir 
-verify llvm-project/clang/test/Analysis/ctu-main.cpp 
  1.   parser at end of file
  2.  While analyzing stack: 
  #0 Calling main
  3.  llvm-project/clang/test/Analysis/ctu-main.cpp:164:23: Error 
evaluating statement
  4.  llvm-project/clang/test/Analysis/ctu-main.cpp:164:23: Error 
evaluating statement
   #0 0x7f30c91a5efa llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
(build/Release/lib/libLLVMSupport.so.10svn+0x191efa)
   #1 0x7f30c91a3bd4 llvm::sys::RunSignalHandlers() 
(build/Release/lib/libLLVMSupport.so.10svn+0x18fbd4)
   #2 0x7f30c91a3d12 SignalHandler(int) 
(build/Release/lib/libLLVMSupport.so.10svn+0x18fd12)
   #3 0x7f30c6347f20 (/lib/x86_64-linux-gnu/libc.so.6+0x3ef20)
   #4 0x7f30c6347e97 raise 
/build/glibc-OTsEL5/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
   #5 0x7f30c6349801 abort 
/build/glibc-OTsEL5/glibc-2.27/stdlib/abort.c:81:0
   #6 0x7f30c633939a __assert_fail_base 
/build/glibc-OTsEL5/glibc-2.27/assert/assert.c:89:0
   #7 0x7f30c6339412 (/lib/x86_64-linux-gnu/libc.so.6+0x30412)
   #8 0x7f30c24ad3fc (build/Release/lib/libclangAST.so.10svn+0x27c3fc)
   #9 0x7f30c23c1f49 clang::Decl::getAccess() const 
(build/Release/lib/libclangAST.so.10svn+0x190f49)
  #10 0x7f30c2309f32 
IsStructurallyEquivalent(clang::StructuralEquivalenceContext&, 
clang::CXXMethodDecl*, clang::CXXMethodDecl*) 
(build/Release/lib/libclangAST.so.10svn+0xd8f32)
  #11 0x7f30c243cda9 
clang::StructuralEquivalenceContext::CheckKindSpecificEquivalence(clang::Decl*, 
clang::Decl*) (build/Release/lib/libclangAST.so.10svn+0x20bda9)
  #12 0x7f30c243d046 clang::StructuralEquivalenceContext::Finish() 
(build/Release/lib/libclangAST.so.10svn+0x20c046)
  #13 0x7f30c243da28 
clang::StructuralEquivalenceContext::IsEquivalent(clang::Decl*, clang::Decl*) 
(build/Release/lib/libclangAST.so.10svn+0x20ca28)
  #14 0x0

[PATCH] D66335: [clangd] Added special HighlightingKind for function parameters.

2019-08-16 Thread Johan Vikström via Phabricator via cfe-commits
jvikstrom created this revision.
jvikstrom added reviewers: hokein, ilya-biryukov.
Herald added subscribers: cfe-commits, kadircet, arphaman, jkorous, MaskRay.
Herald added a project: clang.

This means that function parameters are no longer highlighted as 
variable.other.cpp but instead as variable.parameter.cpp which is the more 
"correct" TextMate scope for them.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D66335

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/test/semantic-highlighting.test
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -32,6 +32,7 @@
 std::vector getExpectedTokens(Annotations &Test) {
   static const std::map KindToString{
   {HighlightingKind::Variable, "Variable"},
+  {HighlightingKind::Parameter, "Parameter"},
   {HighlightingKind::Function, "Function"},
   {HighlightingKind::Class, "Class"},
   {HighlightingKind::Enum, "Enum"},
@@ -104,11 +105,11 @@
   };
   struct {
   } $Variable[[S]];
-  $Primitive[[void]] $Function[[foo]]($Primitive[[int]] $Variable[[A]], $Class[[AS]] $Variable[[As]]) {
+  $Primitive[[void]] $Function[[foo]]($Primitive[[int]] $Parameter[[A]], $Class[[AS]] $Parameter[[As]]) {
 $Primitive[[auto]] $Variable[[VeryLongVariableName]] = 12312;
 $Class[[AS]] $Variable[[AA]];
-$Primitive[[auto]] $Variable[[L]] = $Variable[[AA]].$Field[[SomeMember]] + $Variable[[A]];
-auto $Variable[[FN]] = [ $Variable[[AA]]]($Primitive[[int]] $Variable[[A]]) -> $Primitive[[void]] {};
+$Primitive[[auto]] $Variable[[L]] = $Variable[[AA]].$Field[[SomeMember]] + $Parameter[[A]];
+auto $Variable[[FN]] = [ $Variable[[AA]]]($Primitive[[int]] $Parameter[[A]]) -> $Primitive[[void]] {};
 $Variable[[FN]](12312);
   }
 )cpp",
@@ -287,10 +288,10 @@
   struct $Class[[B]] {};
   struct $Class[[A]] {
 $Class[[B]] $Field[[BB]];
-$Class[[A]] &operator=($Class[[A]] &&$Variable[[O]]);
+$Class[[A]] &operator=($Class[[A]] &&$Parameter[[O]]);
   };
 
-  $Class[[A]] &$Class[[A]]::operator=($Class[[A]] &&$Variable[[O]]) = default;
+  $Class[[A]] &$Class[[A]]::operator=($Class[[A]] &&$Parameter[[O]]) = default;
 )cpp",
 R"cpp(
   enum $Enum[[En]] {
@@ -301,9 +302,9 @@
 $Class[[Foo]] $Field[[Fo]];
 $Enum[[En]] $Field[[E]];
 $Primitive[[int]] $Field[[I]];
-$Class[[Bar]] ($Class[[Foo]] $Variable[[F]],
-$Enum[[En]] $Variable[[E]])
-: $Field[[Fo]] ($Variable[[F]]), $Field[[E]] ($Variable[[E]]),
+$Class[[Bar]] ($Class[[Foo]] $Parameter[[F]],
+$Enum[[En]] $Parameter[[E]])
+: $Field[[Fo]] ($Parameter[[F]]), $Field[[E]] ($Parameter[[E]]),
   $Field[[I]] (123) {}
   };
   class $Class[[Bar2]] : public $Class[[Bar]] {
@@ -385,7 +386,7 @@
   std::vector ActualResults =
   toSemanticHighlightingInformation(Tokens);
   std::vector ExpectedResults = {
-  {3, "CAAEAAAEAAMAAQ=="}, {1, "AQAEAAA="}};
+  {3, "CAAEAAAEAAMAAg=="}, {1, "AQAEAAA="}};
   EXPECT_EQ(ActualResults, ExpectedResults);
 }
 
Index: clang-tools-extra/clangd/test/semantic-highlighting.test
===
--- clang-tools-extra/clangd/test/semantic-highlighting.test
+++ clang-tools-extra/clangd/test/semantic-highlighting.test
@@ -8,6 +8,9 @@
 # CHECK-NEXT:"variable.other.cpp"
 # CHECK-NEXT:  ],
 # CHECK-NEXT:  [
+# CHECK-NEXT:"variable.parameter.cpp"
+# CHECK-NEXT:  ],
+# CHECK-NEXT:  [
 # CHECK-NEXT:"entity.name.function.cpp"
 # CHECK-NEXT:  ],
 # CHECK-NEXT:  [
@@ -43,7 +46,7 @@
 # CHECK-NEXT:"lines": [
 # CHECK-NEXT:  {
 # CHECK-NEXT:"line": 0,
-# CHECK-NEXT:"tokens": "AAADAAkEAAEAAA=="
+# CHECK-NEXT:"tokens": "AAADAAoEAAEAAA=="
 # CHECK-NEXT:  }
 # CHECK-NEXT:],
 # CHECK-NEXT:"textDocument": {
@@ -58,11 +61,11 @@
 # CHECK-NEXT:"lines": [
 # CHECK-NEXT:  {
 # CHECK-NEXT:"line": 0,
-# CHECK-NEXT:"tokens": "AAADAAkEAAEAAA=="
+# CHECK-NEXT:"tokens": "AAADAAoEAAEAAA=="
 # CHECK-NEXT:  }
 # CHECK-NEXT:  {
 # CHECK-NEXT:"line": 1,
-# CHECK-NEXT:"tokens": "AAADAAkEAAEAAA=="
+# CHECK-NEXT:"tokens": "AAADAAoEAAEAAA=="
 # CHECK-NEXT:  }
 # CHECK-NEXT:],
 # CHECK-NEXT:"textDocument": {
@@ -77,7 +80,7 @@
 # CHECK-NEXT:"lines": [
 # CHECK-NEXT:  {
 # CHECK-NEXT: 

[PATCH] D66221: [clangd] Added highlighting for non type templates.

2019-08-16 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov accepted this revision.
ilya-biryukov added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66221



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


[clang-tools-extra] r369090 - [clangd] Added highlighting for non type templates.

2019-08-16 Thread Johan Vikstrom via cfe-commits
Author: jvikstrom
Date: Fri Aug 16 02:30:21 2019
New Revision: 369090

URL: http://llvm.org/viewvc/llvm-project?rev=369090&view=rev
Log:
[clangd] Added highlighting for non type templates.

Summary: Non type templates were not being highlighted. This highlights
them as TemplateParameters.

Reviewers: hokein, ilya-biryukov

Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

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

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

Modified: clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp?rev=369090&r1=369089&r2=369090&view=diff
==
--- clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp (original)
+++ clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp Fri Aug 16 02:30:21 
2019
@@ -224,6 +224,10 @@ private:
   addToken(Loc, HighlightingKind::TemplateParameter);
   return;
 }
+if (isa(D)) {
+  addToken(Loc, HighlightingKind::TemplateParameter);
+  return;
+}
   }
 
   void addToken(SourceLocation Loc, HighlightingKind Kind) {

Modified: clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp?rev=369090&r1=369089&r2=369090&view=diff
==
--- clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp 
(original)
+++ clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp Fri 
Aug 16 02:30:21 2019
@@ -323,6 +323,59 @@ TEST(SemanticHighlighting, GetsCorrectTo
   $Primitive[[auto]] $Variable[[Form]] = 10.2 + 2 * 4;
   $Primitive[[decltype]]($Variable[[Form]]) $Variable[[F]] = 10;
   auto $Variable[[Fun]] = []()->$Primitive[[void]]{};
+)cpp",
+R"cpp(
+  class $Class[[G]] {};
+  template<$Class[[G]] *$TemplateParameter[[U]]>
+  class $Class[[GP]] {};
+  template<$Class[[G]] &$TemplateParameter[[U]]>
+  class $Class[[GR]] {};
+  template<$Primitive[[int]] *$TemplateParameter[[U]]>
+  class $Class[[IP]] {
+$Primitive[[void]] $Method[[f]]() {
+  *$TemplateParameter[[U]] += 5;
+}
+  };
+  template<$Primitive[[unsigned]] $TemplateParameter[[U]] = 2>
+  class $Class[[Foo]] {
+$Primitive[[void]] $Method[[f]]() {
+  for($Primitive[[int]] $Variable[[I]] = 0;
+$Variable[[I]] < $TemplateParameter[[U]];) {}
+}
+  };
+
+  $Class[[G]] $Variable[[L]];
+  $Primitive[[void]] $Function[[f]]() {
+$Class[[Foo]]<123> $Variable[[F]];
+$Class[[GP]]<&$Variable[[L]]> $Variable[[LL]];
+$Class[[GR]]<$Variable[[L]]> $Variable[[LLL]];
+  }
+)cpp",
+R"cpp(
+  template
+  struct $Class[[G]] {
+$Primitive[[void]] $Method[[foo]](
+$TemplateParameter[[T]] *$Variable[[O]]) {
+  ($Variable[[O]]->*$TemplateParameter[[method]])(10);
+}
+  };
+  struct $Class[[F]] {
+$Primitive[[void]] $Method[[f]]($Primitive[[int]]);
+  };
+  template<$Primitive[[void]] (*$TemplateParameter[[Func]])()>
+  struct $Class[[A]] {
+$Primitive[[void]] $Method[[f]]() {
+  (*$TemplateParameter[[Func]])();
+}
+  };
+
+  $Primitive[[void]] $Function[[foo]]() {
+$Class[[F]] $Variable[[FF]];
+$Class[[G]]<$Class[[F]], &$Class[[F]]::$Method[[f]]> $Variable[[GG]];
+$Variable[[GG]].$Method[[foo]](&$Variable[[FF]]);
+$Class[[A]]<$Function[[foo]]> $Variable[[AA]];
+  }
 )cpp"};
   for (const auto &TestCase : TestCases) {
 checkHighlightings(TestCase);


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


[PATCH] D66302: [SVE][Inline-Asm] Support for SVE asm operands

2019-08-16 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen added a comment.

Thanks for this change @kmclaughlin.




Comment at: docs/LangRef.rst:3816
+- ``x``: Like w, but restricted to registers 0 to 15 inclusive.
+- ``y``: Like w, but restricted to registers 0 to 7 inclusive.
 

I noticed this comment does not match the code below, since `y` only seems to 
work for scalable vectors, which probably shows this case is missing a test.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D66302



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


[PATCH] D66221: [clangd] Added highlighting for non type templates.

2019-08-16 Thread Johan Vikström via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL369090: [clangd] Added highlighting for non type templates. 
(authored by jvikstrom, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D66221?vs=215544&id=215549#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D66221

Files:
  clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
  clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp


Index: clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
@@ -224,6 +224,10 @@
   addToken(Loc, HighlightingKind::TemplateParameter);
   return;
 }
+if (isa(D)) {
+  addToken(Loc, HighlightingKind::TemplateParameter);
+  return;
+}
   }
 
   void addToken(SourceLocation Loc, HighlightingKind Kind) {
Index: clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp
@@ -323,6 +323,59 @@
   $Primitive[[auto]] $Variable[[Form]] = 10.2 + 2 * 4;
   $Primitive[[decltype]]($Variable[[Form]]) $Variable[[F]] = 10;
   auto $Variable[[Fun]] = []()->$Primitive[[void]]{};
+)cpp",
+R"cpp(
+  class $Class[[G]] {};
+  template<$Class[[G]] *$TemplateParameter[[U]]>
+  class $Class[[GP]] {};
+  template<$Class[[G]] &$TemplateParameter[[U]]>
+  class $Class[[GR]] {};
+  template<$Primitive[[int]] *$TemplateParameter[[U]]>
+  class $Class[[IP]] {
+$Primitive[[void]] $Method[[f]]() {
+  *$TemplateParameter[[U]] += 5;
+}
+  };
+  template<$Primitive[[unsigned]] $TemplateParameter[[U]] = 2>
+  class $Class[[Foo]] {
+$Primitive[[void]] $Method[[f]]() {
+  for($Primitive[[int]] $Variable[[I]] = 0;
+$Variable[[I]] < $TemplateParameter[[U]];) {}
+}
+  };
+
+  $Class[[G]] $Variable[[L]];
+  $Primitive[[void]] $Function[[f]]() {
+$Class[[Foo]]<123> $Variable[[F]];
+$Class[[GP]]<&$Variable[[L]]> $Variable[[LL]];
+$Class[[GR]]<$Variable[[L]]> $Variable[[LLL]];
+  }
+)cpp",
+R"cpp(
+  template
+  struct $Class[[G]] {
+$Primitive[[void]] $Method[[foo]](
+$TemplateParameter[[T]] *$Variable[[O]]) {
+  ($Variable[[O]]->*$TemplateParameter[[method]])(10);
+}
+  };
+  struct $Class[[F]] {
+$Primitive[[void]] $Method[[f]]($Primitive[[int]]);
+  };
+  template<$Primitive[[void]] (*$TemplateParameter[[Func]])()>
+  struct $Class[[A]] {
+$Primitive[[void]] $Method[[f]]() {
+  (*$TemplateParameter[[Func]])();
+}
+  };
+
+  $Primitive[[void]] $Function[[foo]]() {
+$Class[[F]] $Variable[[FF]];
+$Class[[G]]<$Class[[F]], &$Class[[F]]::$Method[[f]]> $Variable[[GG]];
+$Variable[[GG]].$Method[[foo]](&$Variable[[FF]]);
+$Class[[A]]<$Function[[foo]]> $Variable[[AA]];
+  }
 )cpp"};
   for (const auto &TestCase : TestCases) {
 checkHighlightings(TestCase);


Index: clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
@@ -224,6 +224,10 @@
   addToken(Loc, HighlightingKind::TemplateParameter);
   return;
 }
+if (isa(D)) {
+  addToken(Loc, HighlightingKind::TemplateParameter);
+  return;
+}
   }
 
   void addToken(SourceLocation Loc, HighlightingKind Kind) {
Index: clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp
@@ -323,6 +323,59 @@
   $Primitive[[auto]] $Variable[[Form]] = 10.2 + 2 * 4;
   $Primitive[[decltype]]($Variable[[Form]]) $Variable[[F]] = 10;
   auto $Variable[[Fun]] = []()->$Primitive[[void]]{};
+)cpp",
+R"cpp(
+  class $Class[[G]] {};
+  template<$Class[[G]] *$TemplateParameter[[U]]>
+  class $Class[[GP]] {};
+  template<$Class[[G]] &$TemplateParameter[[U]]>
+  class $Class[[GR]] {};
+  template<$Primitive[[int]] *$TemplateParameter[[U]]>
+  class $Class[[IP]] {
+$Primitive[[void]] $Method[[f]]() {
+  *$TemplateParameter[[U]] += 5;
+}
+  };
+  template<$Primitive[[unsig

[PATCH] D66336: [ASTImporter] Add development internals docs

2019-08-16 Thread Gabor Marton via Phabricator via cfe-commits
martong created this revision.
martong added reviewers: a_sidorin, shafik, teemperor, gamesh411, balazske, 
dkrupp.
Herald added subscribers: cfe-commits, Szelethus, rnkovacs.
Herald added a reviewer: a.sidorin.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D66336

Files:
  clang/docs/InternalsManual.rst

Index: clang/docs/InternalsManual.rst
===
--- clang/docs/InternalsManual.rst
+++ clang/docs/InternalsManual.rst
@@ -1447,6 +1447,477 @@
 are not ``Redeclarable`` -- in that case, a ``Mergeable`` base class is used
 instead).
 
+The ASTImporter
+---
+
+The ``ASTImporter`` class imports nodes of an ``ASTContext`` into another
+``ASTContext``. Please refer to the document :doc:`ASTImporter: Merging Clang
+ASTs ` for an introduction. And please read through the
+high-level `description of the import algorithm
+`_, this is essential for
+understanding further implementation details of the importer.
+
+Abstract Syntax Graph
+^
+
+Despite the name, the Clang AST is not a tree. It is a directed graph with
+cycles. One example of a cycle is the connection between a
+``ClassTemplateDecl`` and its "templated" ``CXXRecordDecl``. The *templated*
+``CXXRecordDecl`` represents all the fields and methods inside the class
+template, while the ``ClassTemplateDecl`` holds the information which is
+related to being a template, i.e. template arguments, etc. We can get the
+*templated* class (the ``CXXRecordDecl``) of a ``ClassTemplateDecl`` with
+``ClassTemplateDecl::getTemplatedDec()``. And we can get back a pointer of the
+"described" class template from the *templated* class:
+``CXXRecordDecl::getDescribedTemplate()``. So, this is a cycle between two
+nodes: between the *templated* and the *described* node. There may be various
+other kinds of cycles in the AST especially in case of declarations.
+
+.. _structural-eq:
+
+Structural Equivalency
+^^
+
+Importing one AST node copies that node into the destination ``ASTContext``. To
+copy one node means that we create a new node in the "to" context then we set
+its properties to be equal to the properties of the source node. Before the
+copy, we make sure that the source node is not *structurally equivalent* to any
+existing node in the destination context. If it happens to be equivalent then
+we skip the copy.
+
+The informal definition of structural equivalency is the following:
+Two nodes are **structurally equivalent** if they are
+
+- builtin types and refer to the same type, e.g. ``int`` and ``int`` are
+  structurally equivalent,
+- function types and all their parameters have structurally equivalent types,
+- record types and all their fields in order of their definition have the same
+  identifier names and structurally equivalent types,
+- variable or function declarations and they have the same identifier name and
+  their types are structurally equivalent.
+
+In C, two types are structurally equivalent if they are *compatible types*. For
+a formal definition of *compatible types*, please refer to 6.2.7/1 in the C11
+standard. However, there is no definition for *compatible types* in the C++
+standard. Still, we extend the definition of structural equivalency to
+templates and their instantiations similarly: besides checking the previously
+mentioned properties, we have to check for equivalent template
+parameters/arguments, etc.
+
+The structural equivalent check can be and is used independently from the
+ASTImporter, e.g. the ``clang::Sema`` class uses it also.
+
+The equivalence of nodes may depend on the equivalency of other pairs of nodes.
+Thus, the check is implemented as a parallel graph traversal. We traverse
+through the nodes of both graphs at the same time. The actual implementation is
+similar to breadth-first-search. Let's say we start the traverse with the 
+pair of nodes. Whenever the traversal reaches a pair  then the following
+statements are true:
+
+- A and X are nodes from the same ASTContext.
+- B and Y are nodes from the same ASTContext.
+- A and B may or may not be from the same ASTContext.
+- if A == X (pointer equivalency) then (there is a cycle during the traverse)
+
+  - A and B are structurally equivalent if and only if
+
+- B and Y are part of the same redeclaration chain,
+- All dependent nodes on the path from  to  are structurally
+  equivalent.
+
+When we compare two classes or enums and one of them is incomplete or has
+unloaded external lexical declarations then we cannot descend to compare their
+contained declarations. So in these cases they are considered equal if they
+have the same names. This is the way how we compare forward declarations with
+definitions.
+
+.. TODO Should we elaborate the actual implementation of the graph traversal,
+.. which is a very weird BFS traversal?
+
+Redeclaration Chains
+
+
+The early version of the 

[PATCH] D54295: [RISCV] Add inline asm constraint A for RISC-V

2019-08-16 Thread Lewis Revill via Phabricator via cfe-commits
lewis-revill updated this revision to Diff 215414.
lewis-revill edited the summary of this revision.
lewis-revill added a comment.
Herald added subscribers: s.egerton, lenary, MaskRay.

Rebased prior to commit.


Repository:
  rC Clang

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

https://reviews.llvm.org/D54295

Files:
  lib/Basic/Targets/RISCV.cpp
  test/CodeGen/riscv-inline-asm.c


Index: test/CodeGen/riscv-inline-asm.c
===
--- test/CodeGen/riscv-inline-asm.c
+++ test/CodeGen/riscv-inline-asm.c
@@ -38,3 +38,9 @@
 // CHECK: call void asm sideeffect "", "f"(double [[FLT_ARG]])
   asm volatile ("" :: "f"(d));
 }
+
+void test_A(int *p) {
+// CHECK-LABEL: define void @test_A(i32* %p)
+// CHECK: call void asm sideeffect "", "*A"(i32* %p)
+  asm volatile("" :: "A"(*p));
+}
Index: lib/Basic/Targets/RISCV.cpp
===
--- lib/Basic/Targets/RISCV.cpp
+++ lib/Basic/Targets/RISCV.cpp
@@ -75,6 +75,10 @@
 // A floating-point register.
 Info.setAllowsRegister();
 return true;
+  case 'A':
+// An address that is held in a general-purpose register.
+Info.setAllowsMemory();
+return true;
   }
 }
 


Index: test/CodeGen/riscv-inline-asm.c
===
--- test/CodeGen/riscv-inline-asm.c
+++ test/CodeGen/riscv-inline-asm.c
@@ -38,3 +38,9 @@
 // CHECK: call void asm sideeffect "", "f"(double [[FLT_ARG]])
   asm volatile ("" :: "f"(d));
 }
+
+void test_A(int *p) {
+// CHECK-LABEL: define void @test_A(i32* %p)
+// CHECK: call void asm sideeffect "", "*A"(i32* %p)
+  asm volatile("" :: "A"(*p));
+}
Index: lib/Basic/Targets/RISCV.cpp
===
--- lib/Basic/Targets/RISCV.cpp
+++ lib/Basic/Targets/RISCV.cpp
@@ -75,6 +75,10 @@
 // A floating-point register.
 Info.setAllowsRegister();
 return true;
+  case 'A':
+// An address that is held in a general-purpose register.
+Info.setAllowsMemory();
+return true;
   }
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D63423: [Diagnostics] Diagnose misused xor as pow

2019-08-16 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

Any futher comments or is it OK now @jfb ? @aaron.ballman ?


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

https://reviews.llvm.org/D63423



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


r369093 - [RISCV] Add inline asm constraint A for RISC-V

2019-08-16 Thread Lewis Revill via cfe-commits
Author: lewis-revill
Date: Fri Aug 16 03:23:56 2019
New Revision: 369093

URL: http://llvm.org/viewvc/llvm-project?rev=369093&view=rev
Log:
[RISCV] Add inline asm constraint A for RISC-V

This allows the constraint A to be used in inline asm for RISC-V, which
allows an address held in a register to be used.

This patch adds the minimal amount of code required to get operands with
the right constraints to compile.

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


Modified:
cfe/trunk/lib/Basic/Targets/RISCV.cpp
cfe/trunk/test/CodeGen/riscv-inline-asm.c

Modified: cfe/trunk/lib/Basic/Targets/RISCV.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/RISCV.cpp?rev=369093&r1=369092&r2=369093&view=diff
==
--- cfe/trunk/lib/Basic/Targets/RISCV.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/RISCV.cpp Fri Aug 16 03:23:56 2019
@@ -75,6 +75,10 @@ bool RISCVTargetInfo::validateAsmConstra
 // A floating-point register.
 Info.setAllowsRegister();
 return true;
+  case 'A':
+// An address that is held in a general-purpose register.
+Info.setAllowsMemory();
+return true;
   }
 }
 

Modified: cfe/trunk/test/CodeGen/riscv-inline-asm.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/riscv-inline-asm.c?rev=369093&r1=369092&r2=369093&view=diff
==
--- cfe/trunk/test/CodeGen/riscv-inline-asm.c (original)
+++ cfe/trunk/test/CodeGen/riscv-inline-asm.c Fri Aug 16 03:23:56 2019
@@ -38,3 +38,9 @@ void test_f() {
 // CHECK: call void asm sideeffect "", "f"(double [[FLT_ARG]])
   asm volatile ("" :: "f"(d));
 }
+
+void test_A(int *p) {
+// CHECK-LABEL: define void @test_A(i32* %p)
+// CHECK: call void asm sideeffect "", "*A"(i32* %p)
+  asm volatile("" :: "A"(*p));
+}


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


[PATCH] D59692: [ASTImporter] Fix name conflict handling

2019-08-16 Thread Gabor Marton via Phabricator via cfe-commits
martong marked an inline comment as done.
martong added a comment.

In D59692#1632138 , @shafik wrote:

> Just wanted to see if you were planning on landing this soon, the fix `Name` 
> -> `SearchName` is probably an important one since we have seen several 
> issues w/ bugs like that but I really would like to see more tests. Are you 
> having issues coming up w/ tests?


Hey Shafik, I was busy lately with some non-ASTImporter related tasks, but just 
recently I could drive myself back to it.
I am planning to add the test cases in the following work days, but the latest 
by the end of the next week.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59692



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


[PATCH] D54295: [RISCV] Add inline asm constraint A for RISC-V

2019-08-16 Thread Lewis Revill via Phabricator via cfe-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL369093: [RISCV] Add inline asm constraint A for RISC-V 
(authored by lewis-revill, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D54295?vs=215414&id=215556#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D54295

Files:
  cfe/trunk/lib/Basic/Targets/RISCV.cpp
  cfe/trunk/test/CodeGen/riscv-inline-asm.c


Index: cfe/trunk/lib/Basic/Targets/RISCV.cpp
===
--- cfe/trunk/lib/Basic/Targets/RISCV.cpp
+++ cfe/trunk/lib/Basic/Targets/RISCV.cpp
@@ -75,6 +75,10 @@
 // A floating-point register.
 Info.setAllowsRegister();
 return true;
+  case 'A':
+// An address that is held in a general-purpose register.
+Info.setAllowsMemory();
+return true;
   }
 }
 
Index: cfe/trunk/test/CodeGen/riscv-inline-asm.c
===
--- cfe/trunk/test/CodeGen/riscv-inline-asm.c
+++ cfe/trunk/test/CodeGen/riscv-inline-asm.c
@@ -38,3 +38,9 @@
 // CHECK: call void asm sideeffect "", "f"(double [[FLT_ARG]])
   asm volatile ("" :: "f"(d));
 }
+
+void test_A(int *p) {
+// CHECK-LABEL: define void @test_A(i32* %p)
+// CHECK: call void asm sideeffect "", "*A"(i32* %p)
+  asm volatile("" :: "A"(*p));
+}


Index: cfe/trunk/lib/Basic/Targets/RISCV.cpp
===
--- cfe/trunk/lib/Basic/Targets/RISCV.cpp
+++ cfe/trunk/lib/Basic/Targets/RISCV.cpp
@@ -75,6 +75,10 @@
 // A floating-point register.
 Info.setAllowsRegister();
 return true;
+  case 'A':
+// An address that is held in a general-purpose register.
+Info.setAllowsMemory();
+return true;
   }
 }
 
Index: cfe/trunk/test/CodeGen/riscv-inline-asm.c
===
--- cfe/trunk/test/CodeGen/riscv-inline-asm.c
+++ cfe/trunk/test/CodeGen/riscv-inline-asm.c
@@ -38,3 +38,9 @@
 // CHECK: call void asm sideeffect "", "f"(double [[FLT_ARG]])
   asm volatile ("" :: "f"(d));
 }
+
+void test_A(int *p) {
+// CHECK-LABEL: define void @test_A(i32* %p)
+// CHECK: call void asm sideeffect "", "*A"(i32* %p)
+  asm volatile("" :: "A"(*p));
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D66335: [clangd] Added special HighlightingKind for function parameters.

2019-08-16 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov accepted this revision.
ilya-biryukov added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66335



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


[PATCH] D57450: [RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64 targets with atomics

2019-08-16 Thread Sam Elliott via Phabricator via cfe-commits
lenary added a comment.
Herald added subscribers: s.egerton, MaskRay.

Given this is an ABI-compatibility issue, I've been looking at how GCC and 
Clang differ in how they deal with issues around size and alignment of atomic 
objects.

All types of size less than or equal to `MaxAtomicPromoteWidth`, when they are 
turned into their atomic variant, will: a) have their size rounded up to a 
power of two, and b) have their alignment changed to that same power of two.

The following Gist contains:

- a C program which will print the size and alignment of a variety of strangely 
sized and aligned objects, and their atomic variants.
- the output of this program when run through gcc and clang, specifying 
`rv(32,64)ima(,fd)` and `(ilp32,lp64)(,f)` (matching ABIs to architectures). I 
used `riscv64-unknown-linux-gnu-gcc` for the avoidance of doubt (this compiler 
allows you to compile for rv32 by specifying a 32-bit -march value).
- the diffs in those outputs for an single ABI, between the two different 
compilers.

The gist is here: 
https://gist.github.com/lenary/2e977a8af33876ba8e0605e98c4e1b0d

There are some differences between GCC and Clang, that seem not to be risc-v 
specific (I saw them when running the C program on my mac)

- Clang ensures zero-sized objects become char-sized when they become atomic. 
GCC leaves them zero-sized. This is documented in ASTContext.cpp line 2130, to 
ensure the atomic operation is generated.
- GCC seems not to round up the size and alignment of non-power-of-two-sized 
structures.

I think this patch needs to be updated to ensure there are no differences in 
objects of power-of-two size. To do this, both riscv64 and riscv32, should have 
a `MaxAtomicPromoteWidth` of 128.

@jyknight does this reasoning make sense for ABI compatibility?


Repository:
  rC Clang

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

https://reviews.llvm.org/D57450



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


[PATCH] D64418: [Docs][OpenCL] Documentation of C++ for OpenCL mode

2019-08-16 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: docs/UsersManual.rst:2771
+
+There are only a few restrictions on allowed C++ features. For detailed 
information
+please refer to documentation on Extensions (:doc:`LanguageExtensions`).

svenvh wrote:
> Anastasia wrote:
> > kpet wrote:
> > > Everything is relative. I would keep this 100% factual: "there are 
> > > restrictions". This is not a sales pitch :).
> > I think it's fair to say few restrictions because the majority of C++ just 
> > works in OpenCL.
> I agree with @kpet and also prefer "There are restrictions" instead of an 
> unquantified statement.
Ok, I don't understand what value does it bring to make information less 
specific but potentially it's not important enough to continue the argument. 
The idea of this sentence was indeed to point out that the mode is just very 
close to C++ with very few restrictions. This isn't a program so it can't have 
a formal definition for every statement. :P


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

https://reviews.llvm.org/D64418



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


[PATCH] D64418: [Docs][OpenCL] Documentation of C++ for OpenCL mode

2019-08-16 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia updated this revision to Diff 215562.
Anastasia marked an inline comment as done and 2 inline comments as not done.
Anastasia added a comment.

- Addressed comments from Sven.


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

https://reviews.llvm.org/D64418

Files:
  docs/LanguageExtensions.rst
  docs/UsersManual.rst

Index: docs/UsersManual.rst
===
--- docs/UsersManual.rst
+++ docs/UsersManual.rst
@@ -2397,7 +2408,8 @@
 This will produce a generic test.bc file that can be used in vendor toolchains
 to perform machine code generation.
 
-Clang currently supports OpenCL C language standards up to v2.0.
+Clang currently supports OpenCL C language standards up to v2.0. Starting from
+clang 9 a C++ mode is available for OpenCL (see :ref:`C++ for OpenCL `).
 
 OpenCL Specific Options
 ---
@@ -2756,6 +2768,46 @@
   enqueue query functions from `section 6.13.17.5
   `_.
 
+.. _opencl_cpp:
+
+C++ for OpenCL
+--
+
+Starting from clang 9 kernel code can contain C++17 features: classes, templates,
+function overloading, type deduction, etc. Please note that this is not an
+implementation of `OpenCL C++
+`_ and
+there is no plan to support it in clang in any new releases in the near future.
+
+For detailed information about restrictions to allowed C++ features please
+refer to :doc:`LanguageExtensions`.
+
+Since C++ features are to be used on top of OpenCL C functionality, all existing
+restrictions from OpenCL C v2.0 will inherently apply. All OpenCL C builtin types
+and function libraries are supported and can be used in this mode.
+
+To enable the C++ for OpenCL mode, pass one of following command line options when
+compiling ``.cl`` file ``-cl-std=clc++``, ``-cl-std=CLC++``, ``-std=clc++`` or
+``-std=CLC++``.
+
+   .. code-block:: c++
+
+ template T add( T x, T y )
+ {
+   return x + y;
+ }
+
+ __kernel void test( __global float* a, __global float* b)
+ {
+   auto index = get_global_id(0);
+   a[index] = add(b[index], b[index+1]);
+ }
+
+
+   .. code-block:: console
+
+ clang -cl-std=clc++ test.cl
+
 .. _target_features:
 
 Target-Specific Features and Limitations
Index: docs/LanguageExtensions.rst
===
--- docs/LanguageExtensions.rst
+++ docs/LanguageExtensions.rst
@@ -1516,6 +1633,284 @@
 Query the presence of this new mangling with
 ``__has_feature(objc_protocol_qualifier_mangling)``.
 
+
+OpenCL Features
+===
+
+C++ for OpenCL
+--
+
+This functionality is built on top of OpenCL C v2.0 and C++17 enabling most of
+regular C++ features in OpenCL kernel code. Most functionality from OpenCL C
+is inherited. This section describes minor differences to OpenCL C and any
+limitations related to C++ support as well as interactions between OpenCL and
+C++ features that are not documented elsewhere.
+
+Restrictions to C++17
+^
+
+The following features are not supported:
+
+- Virtual functions
+- Exceptions
+- ``dynamic_cast`` operator
+- Non-placement ``new``/``delete`` operators
+- Standard C++ libraries. Currently there is no solution for alternative C++
+  libraries provided. Future release will feature library support.
+
+
+Interplay of OpenCL and C++ features
+
+
+Address space behavior
+""
+
+Address spaces are part of the type qualifiers; many rules are just inherited
+from the qualifier behavior documented in OpenCL C v2.0 s6.5 and Embedded C
+extension ISO/IEC JTC1 SC22 WG14 N1021 s3.1. Note that since the address space
+behavior in C++ is not documented formally, Clang extends existing concept
+from C and OpenCL. For example conversion rules are extended from qualification
+conversion but the compatibility is determined using notation of sets and
+overlapping of address spaces from Embedded C (ISO/IEC JTC1 SC22 WG14 N1021
+s3.1.3). For OpenCL it means that implicit conversions are allowed from
+a named address space (except for ``__constant``) to ``__generic`` (OpenCL C
+v2.0 6.5.5). Reverse conversion is only allowed explicitly. The ``__constant``
+address space does not overlap with any other and therefore no valid conversion
+between ``__constant`` and other address spaces exists. Most of the rules
+follow this logic.
+
+**Casts**
+
+C-style cast will follow OpenCL C v2.0 rules (s6.5.5). All cast operators will
+permit conversion to ``__generic`` implicitly. However converting from
+``__generic`` to named address spaces can only be done using ``addrspace_cast``.
+Note that conversions between ``__constant`` and any other is disallowed.
+
+.. _opencl_cpp_addrsp_deduction:
+
+**Deduction**
+
+Address spaces are not deduced for:
+
+- non-pointer/non-ref

[PATCH] D64464: [CodeGen] Emit destructor calls for non-trivial C structs

2019-08-16 Thread Gabor Marton via Phabricator via cfe-commits
martong added inline comments.



Comment at: test/Import/objc-arc/Inputs/cleanup-objects.m:6
+id getObj(int c, id a) {
+  // Commenting out the following line because AST importer crashes when trying
+  // to import a BlockExpr.

Perhaps then this patch depends on another patch which implements the import of 
a BlockExpr?
Or maybe the branch `if (auto *BD = From.dyn_cast())` should be 
left out from the ASTImporter code, and this way BlockExpr and BlockDecl would 
be implemented later in another patch.


Repository:
  rC Clang

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

https://reviews.llvm.org/D64464



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


r369098 - [ASTImporter] Import ctor initializers after setting flags.

2019-08-16 Thread Balazs Keri via cfe-commits
Author: balazske
Date: Fri Aug 16 05:10:03 2019
New Revision: 369098

URL: http://llvm.org/viewvc/llvm-project?rev=369098&view=rev
Log:
[ASTImporter] Import ctor initializers after setting flags.

Summary:
Code to import "ctor initializers" at import of functions
is moved to be after the flags in the newly created function
are imported. This fixes an error when the already created but
incomplete (flags are not set) function declaration is accessed.

Reviewers: martong, shafik, a_sidorin, a.sidorin

Reviewed By: shafik

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits

Tags: #clang

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

Modified:
cfe/trunk/lib/AST/ASTImporter.cpp
cfe/trunk/test/Analysis/Inputs/ctu-other.cpp
cfe/trunk/test/Analysis/Inputs/ctu-other.cpp.externalDefMap.txt
cfe/trunk/test/Analysis/ctu-main.cpp

Modified: cfe/trunk/lib/AST/ASTImporter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTImporter.cpp?rev=369098&r1=369097&r2=369098&view=diff
==
--- cfe/trunk/lib/AST/ASTImporter.cpp (original)
+++ cfe/trunk/lib/AST/ASTImporter.cpp Fri Aug 16 05:10:03 2019
@@ -3272,23 +3272,6 @@ ExpectedDecl ASTNodeImporter::VisitFunct
 // decl and its redeclarations may be required.
   }
 
-  // Import Ctor initializers.
-  if (auto *FromConstructor = dyn_cast(D)) {
-if (unsigned NumInitializers = FromConstructor->getNumCtorInitializers()) {
-  SmallVector CtorInitializers(NumInitializers);
-  // Import first, then allocate memory and copy if there was no error.
-  if (Error Err = ImportContainerChecked(
-  FromConstructor->inits(), CtorInitializers))
-return std::move(Err);
-  auto **Memory =
-  new (Importer.getToContext()) CXXCtorInitializer *[NumInitializers];
-  std::copy(CtorInitializers.begin(), CtorInitializers.end(), Memory);
-  auto *ToCtor = cast(ToFunction);
-  ToCtor->setCtorInitializers(Memory);
-  ToCtor->setNumCtorInitializers(NumInitializers);
-}
-  }
-
   ToFunction->setQualifierInfo(ToQualifierLoc);
   ToFunction->setAccess(D->getAccess());
   ToFunction->setLexicalDeclContext(LexicalDC);
@@ -3332,6 +3315,23 @@ ExpectedDecl ASTNodeImporter::VisitFunct
   return ToFTOrErr.takeError();
   }
 
+  // Import Ctor initializers.
+  if (auto *FromConstructor = dyn_cast(D)) {
+if (unsigned NumInitializers = FromConstructor->getNumCtorInitializers()) {
+  SmallVector CtorInitializers(NumInitializers);
+  // Import first, then allocate memory and copy if there was no error.
+  if (Error Err = ImportContainerChecked(
+  FromConstructor->inits(), CtorInitializers))
+return std::move(Err);
+  auto **Memory =
+  new (Importer.getToContext()) CXXCtorInitializer *[NumInitializers];
+  std::copy(CtorInitializers.begin(), CtorInitializers.end(), Memory);
+  auto *ToCtor = cast(ToFunction);
+  ToCtor->setCtorInitializers(Memory);
+  ToCtor->setNumCtorInitializers(NumInitializers);
+}
+  }
+
   if (D->doesThisDeclarationHaveABody()) {
 Error Err = ImportFunctionDeclBody(D, ToFunction);
 

Modified: cfe/trunk/test/Analysis/Inputs/ctu-other.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/Inputs/ctu-other.cpp?rev=369098&r1=369097&r2=369098&view=diff
==
--- cfe/trunk/test/Analysis/Inputs/ctu-other.cpp (original)
+++ cfe/trunk/test/Analysis/Inputs/ctu-other.cpp Fri Aug 16 05:10:03 2019
@@ -164,3 +164,14 @@ const int DefaultParmContext::I = 0;
 int DefaultParmContext::f() {
   return fDefaultParm();
 }
+
+class TestDelegateConstructor {
+public:
+  TestDelegateConstructor() : TestDelegateConstructor(2) {}
+  TestDelegateConstructor(int) {}
+};
+
+int testImportOfDelegateConstructor(int i) {
+  TestDelegateConstructor TDC;
+  return i;
+}

Modified: cfe/trunk/test/Analysis/Inputs/ctu-other.cpp.externalDefMap.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/Inputs/ctu-other.cpp.externalDefMap.txt?rev=369098&r1=369097&r2=369098&view=diff
==
--- cfe/trunk/test/Analysis/Inputs/ctu-other.cpp.externalDefMap.txt (original)
+++ cfe/trunk/test/Analysis/Inputs/ctu-other.cpp.externalDefMap.txt Fri Aug 16 
05:10:03 2019
@@ -27,3 +27,4 @@ c:@extSCC ctu-other.cpp.ast
 c:@extU ctu-other.cpp.ast
 c:@S@TestAnonUnionUSR@Test ctu-other.cpp.ast
 c:@F@testImportOfIncompleteDefaultParmDuringImport#I# ctu-other.cpp.ast
+c:@F@testImportOfDelegateConstructor#I# ctu-other.cpp.ast
\ No newline at end of file

Modified: cfe/trunk/test/Analysis/ctu-main.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/ctu-main.cpp?rev=369098&r1=369097&r2=369098&view=diff
==
--- cfe/trunk/test/Analysis/ctu-ma

[PATCH] D65935: [ASTImporter] Import ctor initializers after setting flags.

2019-08-16 Thread Balázs Kéri via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL369098: [ASTImporter] Import ctor initializers after setting 
flags. (authored by balazske, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65935?vs=215056&id=215567#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65935

Files:
  cfe/trunk/lib/AST/ASTImporter.cpp
  cfe/trunk/test/Analysis/Inputs/ctu-other.cpp
  cfe/trunk/test/Analysis/Inputs/ctu-other.cpp.externalDefMap.txt
  cfe/trunk/test/Analysis/ctu-main.cpp

Index: cfe/trunk/lib/AST/ASTImporter.cpp
===
--- cfe/trunk/lib/AST/ASTImporter.cpp
+++ cfe/trunk/lib/AST/ASTImporter.cpp
@@ -3272,23 +3272,6 @@
 // decl and its redeclarations may be required.
   }
 
-  // Import Ctor initializers.
-  if (auto *FromConstructor = dyn_cast(D)) {
-if (unsigned NumInitializers = FromConstructor->getNumCtorInitializers()) {
-  SmallVector CtorInitializers(NumInitializers);
-  // Import first, then allocate memory and copy if there was no error.
-  if (Error Err = ImportContainerChecked(
-  FromConstructor->inits(), CtorInitializers))
-return std::move(Err);
-  auto **Memory =
-  new (Importer.getToContext()) CXXCtorInitializer *[NumInitializers];
-  std::copy(CtorInitializers.begin(), CtorInitializers.end(), Memory);
-  auto *ToCtor = cast(ToFunction);
-  ToCtor->setCtorInitializers(Memory);
-  ToCtor->setNumCtorInitializers(NumInitializers);
-}
-  }
-
   ToFunction->setQualifierInfo(ToQualifierLoc);
   ToFunction->setAccess(D->getAccess());
   ToFunction->setLexicalDeclContext(LexicalDC);
@@ -3332,6 +3315,23 @@
   return ToFTOrErr.takeError();
   }
 
+  // Import Ctor initializers.
+  if (auto *FromConstructor = dyn_cast(D)) {
+if (unsigned NumInitializers = FromConstructor->getNumCtorInitializers()) {
+  SmallVector CtorInitializers(NumInitializers);
+  // Import first, then allocate memory and copy if there was no error.
+  if (Error Err = ImportContainerChecked(
+  FromConstructor->inits(), CtorInitializers))
+return std::move(Err);
+  auto **Memory =
+  new (Importer.getToContext()) CXXCtorInitializer *[NumInitializers];
+  std::copy(CtorInitializers.begin(), CtorInitializers.end(), Memory);
+  auto *ToCtor = cast(ToFunction);
+  ToCtor->setCtorInitializers(Memory);
+  ToCtor->setNumCtorInitializers(NumInitializers);
+}
+  }
+
   if (D->doesThisDeclarationHaveABody()) {
 Error Err = ImportFunctionDeclBody(D, ToFunction);
 
Index: cfe/trunk/test/Analysis/Inputs/ctu-other.cpp.externalDefMap.txt
===
--- cfe/trunk/test/Analysis/Inputs/ctu-other.cpp.externalDefMap.txt
+++ cfe/trunk/test/Analysis/Inputs/ctu-other.cpp.externalDefMap.txt
@@ -27,3 +27,4 @@
 c:@extU ctu-other.cpp.ast
 c:@S@TestAnonUnionUSR@Test ctu-other.cpp.ast
 c:@F@testImportOfIncompleteDefaultParmDuringImport#I# ctu-other.cpp.ast
+c:@F@testImportOfDelegateConstructor#I# ctu-other.cpp.ast
\ No newline at end of file
Index: cfe/trunk/test/Analysis/Inputs/ctu-other.cpp
===
--- cfe/trunk/test/Analysis/Inputs/ctu-other.cpp
+++ cfe/trunk/test/Analysis/Inputs/ctu-other.cpp
@@ -164,3 +164,14 @@
 int DefaultParmContext::f() {
   return fDefaultParm();
 }
+
+class TestDelegateConstructor {
+public:
+  TestDelegateConstructor() : TestDelegateConstructor(2) {}
+  TestDelegateConstructor(int) {}
+};
+
+int testImportOfDelegateConstructor(int i) {
+  TestDelegateConstructor TDC;
+  return i;
+}
Index: cfe/trunk/test/Analysis/ctu-main.cpp
===
--- cfe/trunk/test/Analysis/ctu-main.cpp
+++ cfe/trunk/test/Analysis/ctu-main.cpp
@@ -127,6 +127,8 @@
 
 extern int testImportOfIncompleteDefaultParmDuringImport(int);
 
+extern int testImportOfDelegateConstructor(int);
+
 int main() {
   clang_analyzer_eval(f(3) == 2); // expected-warning{{TRUE}}
   clang_analyzer_eval(f(4) == 3); // expected-warning{{TRUE}}
@@ -163,4 +165,6 @@
   clang_analyzer_eval(TestAnonUnionUSR::Test == 5); // expected-warning{{TRUE}}
 
   clang_analyzer_eval(testImportOfIncompleteDefaultParmDuringImport(9) == 9); // expected-warning{{TRUE}}
+
+  clang_analyzer_eval(testImportOfDelegateConstructor(10) == 10); // expected-warning{{TRUE}}
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r369099 - Fix typos in LibASTImporter.rst

2019-08-16 Thread Gabor Marton via cfe-commits
Author: martong
Date: Fri Aug 16 05:21:49 2019
New Revision: 369099

URL: http://llvm.org/viewvc/llvm-project?rev=369099&view=rev
Log:
Fix typos in LibASTImporter.rst

Modified:
cfe/trunk/docs/LibASTImporter.rst

Modified: cfe/trunk/docs/LibASTImporter.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LibASTImporter.rst?rev=369099&r1=369098&r2=369099&view=diff
==
--- cfe/trunk/docs/LibASTImporter.rst (original)
+++ cfe/trunk/docs/LibASTImporter.rst Fri Aug 16 05:21:49 2019
@@ -255,7 +255,7 @@ Putting this all together here is how th
 return 0;
   };
 
-We may extend the ``CmakeLists.txt`` under let's say ``clang/tools`` with the 
build and link instructions:
+We may extend the ``CMakeLists.txt`` under let's say ``clang/tools`` with the 
build and link instructions:
 
 .. code-block:: bash
 
@@ -554,7 +554,7 @@ What's more there is a third prototype d
 The functions are merged in a way that prototypes are added to the redecl 
chain if they refer to the same type, but we can have only one definition.
 The first two declarations are from ``bar.ast``, the third is from 
``main.ast``.
 
-Now, Let's create an object file from the merged AST:
+Now, let's create an object file from the merged AST:
 
 .. code-block:: bash
 


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


[PATCH] D66333: [analyzer] NonNullParamChecker and CStringChecker parameter number in checker message

2019-08-16 Thread Whisperity via Phabricator via cfe-commits
whisperity added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/NonNullParamChecker.cpp:195-196
+  llvm::raw_svector_ostream OS(SBuf);
+  OS << "Null pointer passed as an argument to a 'nonnull' ";
+  OS << Idx << llvm::getOrdinalSuffix(Idx) << " parameter";
+

It seems to be as if now you're able to present which parameter is the 
`[[nonnull]]` one. Because of this, the output to the user sounds really bad 
and unfriendly, at least to me.

How about this:

"null pointer passed to nth parameter, but it's marked 'nonnull'"?
"null pointer passed to nth parameter expecting 'nonnull'"?

Something along these lines.

To a parameter, we're always passing arguments, so saying "as an argument" 
seems redundant.

And because we have the index always in our hands, we don't need to use the 
indefinite article.


Repository:
  rC Clang

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

https://reviews.llvm.org/D66333



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


[PATCH] D65573: Add User docs for ASTImporter

2019-08-16 Thread Gabor Marton via Phabricator via cfe-commits
martong marked 3 inline comments as done.
martong added a comment.

In D65573#1625881 , @a_sidorin wrote:

> That's incredible. Thank you!


Thanks Alexei for the review! I commited a fix for the typos.




Comment at: cfe/trunk/docs/LibASTImporter.rst:215
+Node *Result =
+const_cast(MatchRes[0].template getNodeAs("bindStr"));
+assert(Result);

a_sidorin wrote:
> We can avoid const_cast if we change the example function signature to `const 
> Node *`.
Indeed... Still, I did not change that to keep consistency with other parts of 
the examples.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D65573



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


[PATCH] D66343: [clangd] Simplify code of ClangdLSPServer::onCommand

2019-08-16 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov created this revision.
ilya-biryukov added a reviewer: hokein.
Herald added subscribers: kadircet, arphaman, jkorous, MaskRay.
Herald added a project: clang.

By inlining a complicated lambda into its single call-site.

Also ensure we call Reply() exactly once even if tweaks return both
ShowMessage and ApplyEdit effects.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D66343

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp

Index: clang-tools-extra/clangd/ClangdLSPServer.cpp
===
--- clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -570,28 +570,28 @@
 
 void ClangdLSPServer::onCommand(const ExecuteCommandParams &Params,
 Callback Reply) {
-  auto ApplyEdit = [this](WorkspaceEdit WE,
-  Callback Reply) {
+  auto ApplyEdit = [this](WorkspaceEdit WE, std::string SuccessMessage,
+  decltype(Reply) Reply) {
 ApplyWorkspaceEditParams Edit;
 Edit.edit = std::move(WE);
-call("workspace/applyEdit", std::move(Edit), std::move(Reply));
+call(
+"workspace/applyEdit", std::move(Edit),
+[Reply = std::move(Reply), SuccessMessage = std::move(SuccessMessage)](
+llvm::Expected Response) mutable {
+  if (!Response)
+return Reply(Response.takeError());
+  if (!Response->applied) {
+std::string Reason = Response->failureReason
+ ? *Response->failureReason
+ : "unknown reason";
+return Reply(llvm::createStringError(
+llvm::inconvertibleErrorCode(),
+("edits were not applied: " + Reason).c_str()));
+  }
+  return Reply(SuccessMessage);
+});
   };
-  // FIXME: this lambda is tangled and confusing, refactor it.
-  auto ReplyAfterApplyingEdit =
-  [](decltype(Reply) Reply, std::string SuccessMessage,
- llvm::Expected Response) {
-if (!Response)
-  return Reply(Response.takeError());
-if (!Response->applied) {
-  std::string Reason = Response->failureReason
-   ? *Response->failureReason
-   : "unknown reason";
-  return Reply(llvm::createStringError(
-  llvm::inconvertibleErrorCode(),
-  ("edits were not applied: " + Reason).c_str()));
-}
-return Reply(SuccessMessage);
-  };
+
   if (Params.command == ExecuteCommandParams::CLANGD_APPLY_FIX_COMMAND &&
   Params.workspaceEdit) {
 // The flow for "apply-fix" :
@@ -602,12 +602,7 @@
 // 5. We unwrap the changes and send them back to the editor
 // 6. The editor applies the changes (applyEdit), and sends us a reply
 // 7. We unwrap the reply and send a reply to the editor.
-ApplyEdit(*Params.workspaceEdit,
-  [Reply = std::move(Reply), ReplyAfterApplyingEdit](
-  llvm::Expected Response) mutable {
-ReplyAfterApplyingEdit(std::move(Reply), "Fix applied.",
-   std::move(Response));
-  });
+ApplyEdit(*Params.workspaceEdit, "Fix applied.", std::move(Reply));
   } else if (Params.command == ExecuteCommandParams::CLANGD_APPLY_TWEAK &&
  Params.tweakArgs) {
 auto Code = DraftMgr.getDraft(Params.tweakArgs->file.file());
@@ -616,32 +611,29 @@
   llvm::inconvertibleErrorCode(),
   "trying to apply a code action for a non-added file"));
 
-auto Action = [this, ApplyEdit, ReplyAfterApplyingEdit,
-   Reply = std::move(Reply), File = Params.tweakArgs->file,
-   Code = std::move(*Code)](
+auto Action = [this, ApplyEdit, Reply = std::move(Reply),
+   File = Params.tweakArgs->file, Code = std::move(*Code)](
   llvm::Expected R) mutable {
   if (!R)
 return Reply(R.takeError());
 
-  if (R->ApplyEdit) {
-WorkspaceEdit WE;
-WE.changes.emplace();
-(*WE.changes)[File.uri()] = replacementsToEdits(Code, *R->ApplyEdit);
-ApplyEdit(
-std::move(WE),
-[Reply = std::move(Reply), ReplyAfterApplyingEdit](
-llvm::Expected Response) mutable {
-  ReplyAfterApplyingEdit(std::move(Reply), "Tweak applied.",
- std::move(Response));
-});
-  }
+  assert(R->ShowMessage || R->ApplyEdit && "tweak has no effect");
+
   if (R->ShowMessage) {
 ShowMessageParams Msg;
 Msg.message = *R->ShowMessage;
 Msg.type = MessageType::Info;
 notify("window/showMessage", Msg);
-Reply("Tweak applied.");
   }
+  if (R->ApplyEdit) {
+WorkspaceEdit WE;
+WE.changes.emplace();
+(*WE.changes)[File.ur

[PATCH] D66343: [clangd] Simplify code of ClangdLSPServer::onCommand

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

thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66343



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


[clang-tools-extra] r369100 - [clangd] Simplify code of ClangdLSPServer::onCommand

2019-08-16 Thread Ilya Biryukov via cfe-commits
Author: ibiryukov
Date: Fri Aug 16 05:46:41 2019
New Revision: 369100

URL: http://llvm.org/viewvc/llvm-project?rev=369100&view=rev
Log:
[clangd] Simplify code of ClangdLSPServer::onCommand

Summary:
By inlining a complicated lambda into its single call-site.

Also ensure we call Reply() exactly once even if tweaks return both
ShowMessage and ApplyEdit effects.

Reviewers: hokein

Reviewed By: hokein

Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

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

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

Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp?rev=369100&r1=369099&r2=369100&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp Fri Aug 16 05:46:41 2019
@@ -570,28 +570,28 @@ void ClangdLSPServer::onFileEvent(const
 
 void ClangdLSPServer::onCommand(const ExecuteCommandParams &Params,
 Callback Reply) {
-  auto ApplyEdit = [this](WorkspaceEdit WE,
-  Callback Reply) {
+  auto ApplyEdit = [this](WorkspaceEdit WE, std::string SuccessMessage,
+  decltype(Reply) Reply) {
 ApplyWorkspaceEditParams Edit;
 Edit.edit = std::move(WE);
-call("workspace/applyEdit", std::move(Edit), std::move(Reply));
+call(
+"workspace/applyEdit", std::move(Edit),
+[Reply = std::move(Reply), SuccessMessage = std::move(SuccessMessage)](
+llvm::Expected Response) mutable {
+  if (!Response)
+return Reply(Response.takeError());
+  if (!Response->applied) {
+std::string Reason = Response->failureReason
+ ? *Response->failureReason
+ : "unknown reason";
+return Reply(llvm::createStringError(
+llvm::inconvertibleErrorCode(),
+("edits were not applied: " + Reason).c_str()));
+  }
+  return Reply(SuccessMessage);
+});
   };
-  // FIXME: this lambda is tangled and confusing, refactor it.
-  auto ReplyAfterApplyingEdit =
-  [](decltype(Reply) Reply, std::string SuccessMessage,
- llvm::Expected Response) {
-if (!Response)
-  return Reply(Response.takeError());
-if (!Response->applied) {
-  std::string Reason = Response->failureReason
-   ? *Response->failureReason
-   : "unknown reason";
-  return Reply(llvm::createStringError(
-  llvm::inconvertibleErrorCode(),
-  ("edits were not applied: " + Reason).c_str()));
-}
-return Reply(SuccessMessage);
-  };
+
   if (Params.command == ExecuteCommandParams::CLANGD_APPLY_FIX_COMMAND &&
   Params.workspaceEdit) {
 // The flow for "apply-fix" :
@@ -602,12 +602,7 @@ void ClangdLSPServer::onCommand(const Ex
 // 5. We unwrap the changes and send them back to the editor
 // 6. The editor applies the changes (applyEdit), and sends us a reply
 // 7. We unwrap the reply and send a reply to the editor.
-ApplyEdit(*Params.workspaceEdit,
-  [Reply = std::move(Reply), ReplyAfterApplyingEdit](
-  llvm::Expected Response) mutable 
{
-ReplyAfterApplyingEdit(std::move(Reply), "Fix applied.",
-   std::move(Response));
-  });
+ApplyEdit(*Params.workspaceEdit, "Fix applied.", std::move(Reply));
   } else if (Params.command == ExecuteCommandParams::CLANGD_APPLY_TWEAK &&
  Params.tweakArgs) {
 auto Code = DraftMgr.getDraft(Params.tweakArgs->file.file());
@@ -616,32 +611,29 @@ void ClangdLSPServer::onCommand(const Ex
   llvm::inconvertibleErrorCode(),
   "trying to apply a code action for a non-added file"));
 
-auto Action = [this, ApplyEdit, ReplyAfterApplyingEdit,
-   Reply = std::move(Reply), File = Params.tweakArgs->file,
-   Code = std::move(*Code)](
+auto Action = [this, ApplyEdit, Reply = std::move(Reply),
+   File = Params.tweakArgs->file, Code = std::move(*Code)](
   llvm::Expected R) mutable {
   if (!R)
 return Reply(R.takeError());
 
-  if (R->ApplyEdit) {
-WorkspaceEdit WE;
-WE.changes.emplace();
-(*WE.changes)[File.uri()] = replacementsToEdits(Code, *R->ApplyEdit);
-ApplyEdit(
-std::move(WE),
-[Reply = std::move(Reply), ReplyAfterApplyingEdit](
-llvm::Expected Response) mutable {
-  ReplyAfterApplyingEdit(std::move(Reply), "Tweak applied.",
- 

[PATCH] D66333: [analyzer] NonNullParamChecker and CStringChecker parameter number in checker message

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

I really like the change, thanks! Let's settle on the diagnostic message then.




Comment at: clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp:202
+   SVal l,
+   unsigned idx = -1u) const;
   ProgramStateRef CheckLocation(CheckerContext &C,

I think `Optional` would be nicer. Also, `checkNonNull` as a function 
name doesn't scream about why we need an index parameter -- could you rename it 
to `IndexOfArg` or something similar?



Comment at: clang/lib/StaticAnalyzer/Checkers/NonNullParamChecker.cpp:195-196
+  llvm::raw_svector_ostream OS(SBuf);
+  OS << "Null pointer passed as an argument to a 'nonnull' ";
+  OS << Idx << llvm::getOrdinalSuffix(Idx) << " parameter";
+

whisperity wrote:
> It seems to be as if now you're able to present which parameter is the 
> `[[nonnull]]` one. Because of this, the output to the user sounds really bad 
> and unfriendly, at least to me.
> 
> How about this:
> 
> "null pointer passed to nth parameter, but it's marked 'nonnull'"?
> "null pointer passed to nth parameter expecting 'nonnull'"?
> 
> Something along these lines.
> 
> To a parameter, we're always passing arguments, so saying "as an argument" 
> seems redundant.
> 
> And because we have the index always in our hands, we don't need to use the 
> indefinite article.
Agreed.


Repository:
  rC Clang

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

https://reviews.llvm.org/D66333



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


[PATCH] D66343: [clangd] Simplify code of ClangdLSPServer::onCommand

2019-08-16 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL369100: [clangd] Simplify code of ClangdLSPServer::onCommand 
(authored by ibiryukov, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D66343?vs=215571&id=215573#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D66343

Files:
  clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp

Index: clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
===
--- clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
+++ clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
@@ -570,28 +570,28 @@
 
 void ClangdLSPServer::onCommand(const ExecuteCommandParams &Params,
 Callback Reply) {
-  auto ApplyEdit = [this](WorkspaceEdit WE,
-  Callback Reply) {
+  auto ApplyEdit = [this](WorkspaceEdit WE, std::string SuccessMessage,
+  decltype(Reply) Reply) {
 ApplyWorkspaceEditParams Edit;
 Edit.edit = std::move(WE);
-call("workspace/applyEdit", std::move(Edit), std::move(Reply));
+call(
+"workspace/applyEdit", std::move(Edit),
+[Reply = std::move(Reply), SuccessMessage = std::move(SuccessMessage)](
+llvm::Expected Response) mutable {
+  if (!Response)
+return Reply(Response.takeError());
+  if (!Response->applied) {
+std::string Reason = Response->failureReason
+ ? *Response->failureReason
+ : "unknown reason";
+return Reply(llvm::createStringError(
+llvm::inconvertibleErrorCode(),
+("edits were not applied: " + Reason).c_str()));
+  }
+  return Reply(SuccessMessage);
+});
   };
-  // FIXME: this lambda is tangled and confusing, refactor it.
-  auto ReplyAfterApplyingEdit =
-  [](decltype(Reply) Reply, std::string SuccessMessage,
- llvm::Expected Response) {
-if (!Response)
-  return Reply(Response.takeError());
-if (!Response->applied) {
-  std::string Reason = Response->failureReason
-   ? *Response->failureReason
-   : "unknown reason";
-  return Reply(llvm::createStringError(
-  llvm::inconvertibleErrorCode(),
-  ("edits were not applied: " + Reason).c_str()));
-}
-return Reply(SuccessMessage);
-  };
+
   if (Params.command == ExecuteCommandParams::CLANGD_APPLY_FIX_COMMAND &&
   Params.workspaceEdit) {
 // The flow for "apply-fix" :
@@ -602,12 +602,7 @@
 // 5. We unwrap the changes and send them back to the editor
 // 6. The editor applies the changes (applyEdit), and sends us a reply
 // 7. We unwrap the reply and send a reply to the editor.
-ApplyEdit(*Params.workspaceEdit,
-  [Reply = std::move(Reply), ReplyAfterApplyingEdit](
-  llvm::Expected Response) mutable {
-ReplyAfterApplyingEdit(std::move(Reply), "Fix applied.",
-   std::move(Response));
-  });
+ApplyEdit(*Params.workspaceEdit, "Fix applied.", std::move(Reply));
   } else if (Params.command == ExecuteCommandParams::CLANGD_APPLY_TWEAK &&
  Params.tweakArgs) {
 auto Code = DraftMgr.getDraft(Params.tweakArgs->file.file());
@@ -616,32 +611,29 @@
   llvm::inconvertibleErrorCode(),
   "trying to apply a code action for a non-added file"));
 
-auto Action = [this, ApplyEdit, ReplyAfterApplyingEdit,
-   Reply = std::move(Reply), File = Params.tweakArgs->file,
-   Code = std::move(*Code)](
+auto Action = [this, ApplyEdit, Reply = std::move(Reply),
+   File = Params.tweakArgs->file, Code = std::move(*Code)](
   llvm::Expected R) mutable {
   if (!R)
 return Reply(R.takeError());
 
-  if (R->ApplyEdit) {
-WorkspaceEdit WE;
-WE.changes.emplace();
-(*WE.changes)[File.uri()] = replacementsToEdits(Code, *R->ApplyEdit);
-ApplyEdit(
-std::move(WE),
-[Reply = std::move(Reply), ReplyAfterApplyingEdit](
-llvm::Expected Response) mutable {
-  ReplyAfterApplyingEdit(std::move(Reply), "Tweak applied.",
- std::move(Response));
-});
-  }
+  assert(R->ShowMessage || R->ApplyEdit && "tweak has no effect");
+
   if (R->ShowMessage) {
 ShowMessageParams Msg;
 Msg.message = *R->ShowMessage;
 Msg.type = MessageType::Info;
 notify("window/showMessage", Msg);
-Reply("Tweak applied.");
   }
+  if (R->ApplyEdit) {
+ 

[PATCH] D65526: [Clangd] Initial prototype version of ExtractFunction

2019-08-16 Thread Shaurya Gupta via Phabricator via cfe-commits
SureYeaah updated this revision to Diff 215574.
SureYeaah added a comment.

Fixed bug in getLocType


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65526

Files:
  clang-tools-extra/clangd/refactor/tweaks/CMakeLists.txt
  clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -599,6 +599,115 @@
 R"cpp(const char * x = "test")cpp");
 }
 
+TWEAK_TEST(ExtractFunction);
+TEST_F(ExtractFunctionTest, PrepareFunctionTest) {
+  Header = R"cpp(
+#define F(BODY) void FFF() { BODY }
+  )cpp";
+  Context = Function;
+  EXPECT_AVAILABLE(R"cpp(
+[[int sum = 0;
+for(;;)
+  sum++;]]
+for(int i = 0; i < 5; i++) {
+  sum += i;
+}
+  )cpp");
+  EXPECT_AVAILABLE(R"cpp([[int x;]])cpp");
+  // TODO: Add tests for macros after selectionTree works properly for macros.
+  // EXPECT_AVAILABLE(R"cpp( F (int x = 0; [[x = 1;]])cpp");
+  // FIXME: This should be unavailable since partially selected but
+  // selectionTree doesn't always work correctly for VarDecls.
+  //EXPECT_UNAVAILABLE(R"cpp(int [[x = 0]];)cpp");
+  EXPECT_UNAVAILABLE(R"cpp(
+int sum = 0;
+for(;;)
+  [[sum++;
+sum++;]]
+  )cpp");
+  // Expressions aren't extracted.
+  EXPECT_UNAVAILABLE(R"cpp(int x = 0; [[x++;]])cpp");
+  // FIXME: ExtractFunction should be unavailable inside loop construct
+  // initalizer/condition.
+  // EXPECT_UNAVAILABLE(R"cpp( for([[int i = 0; i < 5;]] i++) )cpp");
+}
+
+TEST_F(ExtractFunctionTest, PrepareMethodTest) {
+  EXPECT_UNAVAILABLE(R"cpp(
+class T {
+  void f() {
+[[int x;]]
+  }
+};
+  )cpp");
+}
+
+TEST_F(ExtractFunctionTest, ApplyTest) {
+  // We can extract from templated functions as long as no reference in the
+  // extraction depends on the template.
+  // Checks const qualifier and extraction parameters.
+  Header = R"cpp(
+  )cpp";
+  EXPECT_EQ(apply(
+R"cpp(
+struct FOO {
+  int x;
+};
+template
+void f(int a) {
+  int b = N; T t; const int c; FOO foo;
+  int *ptr = &a;
+  [[a += foo.x;
+  b = c; 
+  *ptr++;
+  int d = 5 /* check if comment is extracted */ ;]]
+})cpp"),
+R"cpp(
+struct FOO {
+  int x;
+};
+void extracted(int &a, int &b, const int &c, struct FOO &foo, int * &ptr) {
+a += foo.x;
+  b = c; 
+  *ptr++;
+  int d = 5 /* check if comment is extracted */ ;
+}
+template
+void f(int a) {
+  int b = N; T t; const int c; FOO foo;
+  int *ptr = &a;
+  extracted(a, b, c, foo, ptr);
+})cpp");
+  auto ShouldSucceed = [&](llvm::StringRef Code) {
+EXPECT_THAT(apply(Code), HasSubstr("extracted"));
+  };
+  auto ShouldFail = [&](llvm::StringRef Code) {
+EXPECT_THAT(apply(Code), StartsWith("fail:"));
+  };
+  // Ensure the last break isn't included in the Source since the end of source
+  // and beginning of break are adjacent.
+  ShouldSucceed(R"cpp(
+void f() {
+  for(;;) {
+[[{}]]break;
+  }
+}
+  )cpp");
+  // Don't extract because needs hoisting.
+  ShouldFail(R"cpp( void f() { [[int a = 5;]] a++;})cpp");
+  // Don't extract parameters that depend on template.
+  ShouldFail(R"cpp( template void f() { [[int a = N;]] })cpp");
+  ShouldFail(R"cpp( template void f() { [[T t;]] })cpp");
+  // Don't extract return
+  ShouldFail(R"cpp( int f() { int a = 5; [[return a;]]})cpp");
+  // Don't extract break and continue.
+  // FIXME: We should be able to extract this.
+  ShouldFail(R"cpp( int f() { [[for(;;) break;]]})cpp");
+  ShouldFail(R"cpp( int f() { for(;;) [[continue;]]})cpp");
+  // Don't extract when we need to make a function as a parameter.
+  ShouldFail(R"cpp( void f() { [[int a; f();]] } )cpp");
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
@@ -0,0 +1,537 @@
+//===--- ExtractFunction.cpp -*- 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
+//
+//===--===//
+#include "ClangdUnit.h"
+#include "Logger.h"
+#include "Selection.h"
+#include "SourceCode.h"
+#include "refactor/Tweak.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/DeclTemplate.h"
+#include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/AST/Stmt.h"
+#include "clang/Basic/LangOptions.h"
+#include "clang/Basic/SourceLocation.h"
+#include

[PATCH] D57450: [RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64 targets with atomics

2019-08-16 Thread Sam Elliott via Phabricator via cfe-commits
lenary commandeered this revision.
lenary added a reviewer: asb.
lenary added a comment.

Chatted to @asb and he wants me to take over this set of changes.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57450



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


[PATCH] D59692: [ASTImporter] Fix name conflict handling

2019-08-16 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 215579.
martong added a comment.

- Name -> SearchName
- Add tests for conflicting declarations


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59692

Files:
  clang/include/clang/AST/ASTImporter.h
  clang/lib/AST/ASTImporter.cpp
  clang/test/Analysis/Inputs/ctu-other.c
  clang/unittests/AST/ASTImporterTest.cpp

Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -1879,7 +1879,7 @@
   auto *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
   // We expect one (ODR) warning during the import.
   EXPECT_EQ(1u, ToTU->getASTContext().getDiagnostics().getNumWarnings());
-  EXPECT_EQ(2u,
+  EXPECT_EQ(1u,
 DeclCounter().match(ToTU, recordDecl(hasName("X";
 }
 
@@ -2432,6 +2432,62 @@
   EXPECT_EQ(ToD1, ToD2);
 }
 
+TEST_P(ImportFunctionTemplates,
+   ImportFunctionWhenThereIsAFunTemplateWithSameName) {
+  getToTuDecl(
+  R"(
+  template 
+  void foo(T) {}
+  void foo();
+  )",
+  Lang_CXX);
+  Decl *FromTU = getTuDecl("void foo();", Lang_CXX);
+  auto *FromD = FirstDeclMatcher().match(
+  FromTU, functionDecl(hasName("foo")));
+  auto *ImportedD = Import(FromD, Lang_CXX);
+  EXPECT_TRUE(ImportedD);
+}
+
+TEST_P(ImportFunctionTemplates,
+   ImportConstructorWhenThereIsAFunTemplateWithSameName) {
+  auto Code =
+  R"(
+  struct Foo {
+template 
+Foo(T) {}
+Foo();
+  };
+  )";
+  getToTuDecl(Code, Lang_CXX);
+  Decl *FromTU = getTuDecl(Code, Lang_CXX);
+  auto *FromD =
+  LastDeclMatcher().match(FromTU, cxxConstructorDecl());
+  auto *ImportedD = Import(FromD, Lang_CXX);
+  EXPECT_TRUE(ImportedD);
+}
+
+TEST_P(ImportFunctionTemplates,
+   ImportOperatorWhenThereIsAFunTemplateWithSameName) {
+  getToTuDecl(
+  R"(
+  template 
+  void operator<(T,T) {}
+  struct X{};
+  void operator<(X, X);
+  )",
+  Lang_CXX);
+  Decl *FromTU = getTuDecl(
+  R"(
+  struct X{};
+  void operator<(X, X);
+  )",
+  Lang_CXX);
+  auto *FromD = LastDeclMatcher().match(
+  FromTU, functionDecl(hasOverloadedOperatorName("<")));
+  auto *ImportedD = Import(FromD, Lang_CXX);
+  EXPECT_TRUE(ImportedD);
+}
+
 struct ImportFriendFunctions : ImportFunctions {};
 
 TEST_P(ImportFriendFunctions, ImportFriendFunctionRedeclChainProto) {
@@ -5127,15 +5183,6 @@
   }
 }
 
-INSTANTIATE_TEST_CASE_P(ParameterizedTests, ErrorHandlingTest,
-DefaultTestValuesForRunOptions, );
-
-INSTANTIATE_TEST_CASE_P(ParameterizedTests, DeclContextTest,
-::testing::Values(ArgVector()), );
-
-INSTANTIATE_TEST_CASE_P(ParameterizedTests, CanonicalRedeclChain,
-::testing::Values(ArgVector()), );
-
 TEST_P(ASTImporterOptionSpecificTestBase, LambdaInFunctionBody) {
   Decl *FromTU = getTuDecl(
   R"(
@@ -5233,8 +5280,8 @@
   // prototype (inside 'friend') for it comes first in the AST and is not
   // linked to the definition.
   EXPECT_EQ(ImportedDef, ToClassDef);
-}  
-  
+}
+
 struct LLDBLookupTest : ASTImporterOptionSpecificTestBase {
   LLDBLookupTest() {
 Creator = [](ASTContext &ToContext, FileManager &ToFileManager,
@@ -5362,10 +5409,214 @@
   EXPECT_EQ(ImportedX->isAggregate(), FromX->isAggregate());
 }
 
+struct ConflictingDeclsTest : ASTImporterOptionSpecificTestBase {};
+
+TEST_P(ConflictingDeclsTest, Typedef) {
+  getToTuDecl(
+  R"(
+  typedef int X;
+  )",
+  Lang_CXX11);
+  Decl *FromTU = getTuDecl(
+  R"(
+  typedef double X;
+  )",
+  Lang_CXX11);
+  auto *FromX = FirstDeclMatcher().match(
+  FromTU, typedefNameDecl(hasName("X")));
+  auto *ImportedX = Import(FromX, Lang_CXX11);
+  EXPECT_FALSE(ImportedX);
+  ASTImporter *Importer = findFromTU(FromX)->Importer.get();
+  Optional OptErr = Importer->getImportDeclErrorIfAny(FromX);
+  ASSERT_TRUE(OptErr);
+  EXPECT_EQ(OptErr->Error, ImportError::NameConflict);
+}
+
+TEST_P(ConflictingDeclsTest, TypeAlias) {
+  getToTuDecl(
+  R"(
+  using X = int;
+  )",
+  Lang_CXX11);
+  Decl *FromTU = getTuDecl(
+  R"(
+  using X = double;
+  )",
+  Lang_CXX11);
+  auto *FromX = FirstDeclMatcher().match(
+  FromTU, typedefNameDecl(hasName("X")));
+  auto *ImportedX = Import(FromX, Lang_CXX11);
+  EXPECT_FALSE(ImportedX);
+  ASTImporter *Importer = findFromTU(FromX)->Importer.get();
+  Optional OptErr = Importer->getImportDeclErrorIfAny(FromX);
+  ASSERT_TRUE(OptErr);
+  EXPECT_EQ(OptErr->Error, ImportError::NameConflict);
+}
+
+TEST_P(ConflictingDeclsTest, EnumDecl) {
+  getToTuDecl(
+  R"(
+  enum X { a, b };
+  )",
+  Lang_CXX11);
+  Decl *FromTU = getTuDecl(
+  R"(
+  enum X { a, b, c };
+  )",
+  Lang_CXX11);
+  auto 

[PATCH] D59692: [ASTImporter] Fix name conflict handling

2019-08-16 Thread Gabor Marton via Phabricator via cfe-commits
martong marked 2 inline comments as done.
martong added inline comments.



Comment at: clang/unittests/AST/ASTImporterTest.cpp:2392
 
+struct ImportFunctionTemplates : ASTImporterOptionSpecificTestBase {};
+

shafik wrote:
> What about tests for name conflicts for:
> 
> `NamespaceDecl` 
> `TypedefNameDecl`
> `TypeAliasTemplateDecl`
> `EnumConstantDecl`
> `RecordDecl`
> `VarDecl`
> 
> Who were also modified above.
I added several new tests with a new test suite `ConflictingDeclsTest`, they 
cover all the modifications in ASTImporter.cpp except for VarTemplateDecls.
In case of VarTemplateDecls we don't have a proper structural eq check 
implemented yet, so I disabled that test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59692



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


[PATCH] D65065: [clang-tidy] Possibility of displaying duplicate warnings

2019-08-16 Thread Alexander Kornienko via Phabricator via cfe-commits
alexfh added a comment.

Just FYI, https://bugs.llvm.org/show_bug.cgi?id=43019 is relevant.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D65065



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


[PATCH] D65065: [clang-tidy] Possibility of displaying duplicate warnings

2019-08-16 Thread Alexander Kornienko via Phabricator via cfe-commits
alexfh accepted this revision.
alexfh added a comment.
This revision is now accepted and ready to land.

LG. Thanks!


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D65065



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


[PATCH] D63423: [Diagnostics] Diagnose misused xor as pow

2019-08-16 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

This LGTM aside from a few nits, but please give a chance for other reviewers 
to weigh in on their comments.




Comment at: lib/Sema/SemaExpr.cpp:11025-11031
+  if (LHSStrRef.startswith("0b") || LHSStrRef.startswith("0B") ||
+  RHSStrRef.startswith("0b") || RHSStrRef.startswith("0B"))
+return;
+  // Do not diagnose hexadecimal literals.
+  if (LHSStrRef.startswith("0x") || LHSStrRef.startswith("0X") ||
+  RHSStrRef.startswith("0x") || RHSStrRef.startswith("0X"))
+return;

Might as well combine these.



Comment at: test/SemaCXX/warn-xor-as-pow.cpp:100-102
+  res = 10 ^ 5_xor;
+  res = 10 ^ 5_0b;
+  res = 10_0X ^ 5;

I'd also like to see a case like `res = 10_xor ^ 5;`


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

https://reviews.llvm.org/D63423



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


[PATCH] D66186: [Sema] Don't warn on printf('%hd', [char]) (PR41467)

2019-08-16 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman requested changes to this revision.
aaron.ballman added a comment.

In D66186#1632440 , 
@Nathan-Huckleberry wrote:

> As far as I can tell this case was just overlooked. The original commit 
> adding this change 
> https://reviews.llvm.org/rG0208793e41018ac168412a3da8b2fba70aba9716 only 
> allows chars to int and chars to chars. Another commit ignores typing of 
> chars https://reviews.llvm.org/rG74e82bd190017d59d5d78b07dedca5b06b4547da. I 
> did not see anything related to this particular case in previous commits.


Hmm, it looks like, at least from this review, someone thought the behavior was 
for demonstrating user intent: 
http://llvm.org/viewvc/llvm-project?view=revision&revision=157961.

I've convinced myself that -Wformat should disable that diagnostic by default, 
but there is utility in keeping it exposed through a different format warning 
flag. It seems like `-Wformat-pedantic` should still diagnose this case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66186



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


[PATCH] D66294: [Docs][OpenCL] Release 9.0 notes for OpenCL

2019-08-16 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia updated this revision to Diff 215591.
Anastasia marked 5 inline comments as done.

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

https://reviews.llvm.org/D66294

Files:
  docs/ReleaseNotes.rst

Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -46,6 +46,8 @@
 Major New Features
 --
 
+- Experimental support for :ref:`C++ for OpenCL ` has been
+  added.
 - ...
 
 Improvements to Clang's diagnostics
@@ -133,6 +135,14 @@
 C++ Language Changes in Clang
 -
 
+- Support for the address space attribute in various C++ features was improved,
+  refer to :ref:`C++ for OpenCL ` for more details. The following
+  features deviated from OpenCL:
+
+  (1) Address spaces as method qualifiers are not accepted yet;
+
+  (2) There is no address space deduction.
+
 - ...
 
 C++1z Feature Support
@@ -152,10 +162,88 @@
   // clang used to encode this as "^{NSArray=#}" instead of "@".
   const char *s0 = @encode(MyArray *);
 
-OpenCL C Language Changes in Clang
---
+OpenCL Kernel Language Changes in Clang
+---
+
+OpenCL C
+
+
+- Enabled use of variadic macro as a Clang extension.
+
+- Added initial support for implicitly including OpenCL builtin
+  fuctions using efficient trie lookup generated by TableGen.
+  A corresponding frontend-only flag ``-fdeclare-opencl-builtins``
+  has been added to enable trie during parsing.
+
+- Refactored header file to be used for common parts between
+  regular header added using ``-finclude-default-header`` and trie
+  based declarations added using ``-fdeclare-opencl-builtins``.
+
+- Improved string formatting diagnostics in printf for vector types.
+
+- Simplified the internal representation of blocks, including their
+  generation in IR. Furthermore, indirect calls to block function
+  has been changed to direct function calls.
+
+- Added diagnostics for conversions of nested pointers with
+  different address spaces.
+
+- Added ``cl_arm_integer_dot_product`` extension.
+
+- Fixed global samplers in OpenCL v2.0.
+
+- Improved math builtin functions with parameters of type ``long
+  long`` for x86. 
+
+.. _openclcpp:
+
+C++ for OpenCL
+^^
+
+Experimental support for C++17 features in OpenCL has been added
+and backwards compatibility with OpenCL C v2.0 was enabled.
+The documentation has been added for supported language features
+into :doc:`LanguageExtensions` and :doc:`UsersManual`. 
+
+Implemented features are:
+- Address space behavior is improved in majority of C++ features:
+
+  - Templates parameters and arguments
+
+  - Reference types;
+
+  - Type deduction;
+
+  - Objects and member functions, including special member
+functions;
+
+  - Builtin operators;
+
+  - Method qualifiers now include address space;
+
+  - Address space deduction has been extended for C++ use cases;
+
+  - Improved overload ranking rules.
+
+  - All standard cast operators now prevent converting address 
+spaces (except for conversions allowed implicitly). They
+can still be cast using C-style cast.
+
+- Vector types as in OpenCL C, including compound vector
+  initialization.
+
+- OpenCL-specific types: images, samplers, events, pipes, are
+  accepted with exception of blocks.
+
+- OpenCL standard header in Clang can be compiled in C++ mode.
+
+- Global constructors can be invoked from the host side using
+  a specific, compiler-generated kernel.
+
+- Overloads with generic address space are added to all atomic
+  builtin functions, including the ones from prior to OpenCL
+  v2.0.
 
-...
 
 ABI Changes in Clang
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D66294: [Docs][OpenCL] Release 9.0 notes for OpenCL

2019-08-16 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: docs/ReleaseNotes.rst:173
+
+- Added initial support for implicitly including OpenCL BIFs using
+  efficient trie lookup generated by TableGen. A corresponding

svenvh wrote:
> mantognini wrote:
> > If the BIF acronym wasn't introduced before, it should be replaced with 
> > "builtin functions". It seems we don't have more file context in this 
> > review so I cannot tell.
> BIFs -> built-in functions
builtin is a more common spelling in Clang docs.



Comment at: docs/ReleaseNotes.rst:176
+  frontend only flag ``-fadd-opencl-builtins`` has been added to
+  enable trie during parsing.
+

svenvh wrote:
> The option does not only "enable a trie" during parsing.  I'd suggest to just 
> drop "to enable trie during parsing".
We don't have to describe all details here btw, but just the main ones. I would 
like to say what the flag is used for explicitly rather than leaving the room 
for interpretations.

Btw, would it make sense to document this flag in UserManual? 
https://clang.llvm.org/docs/UsersManual.html#opencl-specific-options



Comment at: docs/ReleaseNotes.rst:220
+
+  - Method qualifiers are allowed with address spaces;
+

mantognini wrote:
> Maybe something along these line would be better?
> 
> Methods can be overloaded for different address spaces.
> 
> Or, if you want to emphasis the qualifiers,
> 
> Method qualifiers now include address space.
I prefer the second one, as the first one can be read as parameter address 
space.



Comment at: docs/ReleaseNotes.rst:222
+
+  - Address space deduction has been extended for C++ use cases;
+

mantognini wrote:
> This seems to be already included in previous point.
Do you mean method qualifiers? I don't see the connection?



Comment at: docs/ReleaseNotes.rst:232-233
+
+- OpenCL specific type: images, samplers, events, pipes, except
+  for blocks.
+

mantognini wrote:
> I would suggest this:
> 
> OpenCL-specific types, except within blocks: [...]
I mean  with the exception of blocks here.


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

https://reviews.llvm.org/D66294



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


[PATCH] D63423: [Diagnostics] Diagnose misused xor as pow

2019-08-16 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 updated this revision to Diff 215592.
xbolva00 added a comment.

Fixed nits.


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

https://reviews.llvm.org/D63423

Files:
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaExpr.cpp
  test/SemaCXX/warn-xor-as-pow.cpp

Index: test/SemaCXX/warn-xor-as-pow.cpp
===
--- test/SemaCXX/warn-xor-as-pow.cpp
+++ test/SemaCXX/warn-xor-as-pow.cpp
@@ -0,0 +1,105 @@
+// RUN: %clang_cc1 -x c -fsyntax-only -verify -Wxor-used-as-pow %s
+// RUN: %clang_cc1 -x c -fsyntax-only -verify %s
+// RUN: %clang_cc1 -x c -fsyntax-only -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
+
+// RUN: %clang_cc1 -x c++ -fsyntax-only -verify -Wxor-used-as-pow %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -verify %s
+// RUN: %clang_cc1 -x c++ -fsyntax-only -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s
+
+#define FOOBAR(x, y) (x * y)
+#define XOR(x, y) (x ^ y)
+#define TWO 2
+#define TEN 10
+#define TWO_ULL 2ULL
+#define EPSILON 10 ^ -300
+
+#define flexor 7
+
+#ifdef __cplusplus
+constexpr long long operator"" _xor(unsigned long long v) { return v; }
+
+constexpr long long operator"" _0b(unsigned long long v) { return v; }
+constexpr long long operator"" _0X(unsigned long long v) { return v; }
+#else
+#define xor^ // iso646.h
+#endif
+
+void test(unsigned a, unsigned b) {
+  unsigned res;
+  res = a ^ 5;
+  res = 2 ^ b;
+  res = a ^ b;
+  res = 2 ^ -1;
+  res = 2 ^ 0; // expected-warning {{result of '2 ^ 0' is 2; did you mean '1 << 0' (1)?}}
+   // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:9-[[@LINE-1]]:14}:"1"
+   // expected-note@-2 {{replace expression with '0x2 ^ 0' to silence this warning}}
+  res = 2 ^ 1; // expected-warning {{result of '2 ^ 1' is 3; did you mean '1 << 1' (2)?}}
+   // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:9-[[@LINE-1]]:14}:"1 << 1"
+   // expected-note@-2 {{replace expression with '0x2 ^ 1' to silence this warning}}
+  res = 2 ^ 2; // expected-warning {{result of '2 ^ 2' is 0; did you mean '1 << 2' (4)?}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:9-[[@LINE-1]]:14}:"1 << 2"
+  // expected-note@-2 {{replace expression with '0x2 ^ 2' to silence this warning}}
+  res = 2 ^ 8; // expected-warning {{result of '2 ^ 8' is 10; did you mean '1 << 8' (256)?}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:9-[[@LINE-1]]:14}:"1 << 8"
+  // expected-note@-2 {{replace expression with '0x2 ^ 8' to silence this warning}}
+  res = TWO ^ 8; // expected-warning {{result of 'TWO ^ 8' is 10; did you mean '1 << 8' (256)?}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:9-[[@LINE-1]]:16}:"1 << 8"
+  // expected-note@-2 {{replace expression with '0x2 ^ 8' to silence this warning}}
+  res = 2 ^ 16; // expected-warning {{result of '2 ^ 16' is 18; did you mean '1 << 16' (65536)?}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:9-[[@LINE-1]]:15}:"1 << 16"
+  // expected-note@-2 {{replace expression with '0x2 ^ 16' to silence this warning}}
+  res = 2 ^ TEN; // expected-warning {{result of '2 ^ TEN' is 8; did you mean '1 << TEN' (1024)?}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:9-[[@LINE-1]]:16}:"1 << TEN"
+  // expected-note@-2 {{replace expression with '0x2 ^ TEN' to silence this warning}}
+  res = 0x2 ^ 16;
+  res = 2 xor 16;
+
+  res = 2 ^ 0x4;
+  res = 2 ^ 04;
+  res = 0x2 ^ 10;
+  res = 0X2 ^ 10;
+  res = 02 ^ 10;
+  res = FOOBAR(2, 16);
+  res = 0b10 ^ 16;
+  res = 0B10 ^ 16;
+  res = 2 ^ 0b100;
+  res = XOR(2, 16);
+  unsigned char two = 2;
+  res = two ^ 16;
+  res = TWO_ULL ^ 16;
+  res = 2 ^ 32; // expected-warning {{result of '2 ^ 32' is 34; did you mean '1LL << 32'?}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:9-[[@LINE-1]]:15}:"1LL << 32"
+  // expected-note@-2 {{replace expression with '0x2 ^ 32' to silence this warning}}
+  res = 2 ^ 64;
+
+  res = EPSILON;
+  res = 10 ^ 0; // expected-warning {{result of '10 ^ 0' is 10; did you mean '1e0'?}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:9-[[@LINE-1]]:15}:"1e0"
+  // expected-note@-2 {{replace expression with '0xA ^ 0' to silence this warning}}
+  res = 10 ^ 1; // expected-warning {{result of '10 ^ 1' is 11; did you mean '1e1'?}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:9-[[@LINE-1]]:15}:"1e1"
+  // expected-note@-2 {{replace expression with '0xA ^ 1' to silence this warning}}
+  res = 10 ^ 2; // expected-warning {{result of '10 ^ 2' is 8; did you mean '1e2'?}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:9-[[@LINE-1]]:15}:"1e2"
+  // expected-note@-2 {{replace expression with '0xA ^ 2' to silence this warning}}
+  res = 10 ^ 4; // expected-warning {{result of '10 ^ 4' is 14; did you mean '1e4'?}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-1]]:9-[[@LINE-1]]:15}:"1e4"
+  // expected-note@-2 {{replace expression with '0xA ^ 4' to silence this warning}}
+  res = 10 ^ 10; // expected-warning {{result of '10 ^ 10' is 0; did you mean '1e10'?}}
+  // CHECK: fix-it:"{{.*}}":{[[@LI

[PATCH] D66348: [ASTImporter] Do not look up lambda classes

2019-08-16 Thread Gabor Marton via Phabricator via cfe-commits
martong created this revision.
martong added a reviewer: a_sidorin.
Herald added subscribers: cfe-commits, gamesh411, Szelethus, dkrupp, rnkovacs.
Herald added a reviewer: a.sidorin.
Herald added a reviewer: shafik.
Herald added a project: clang.

Consider this code:

  void f() {
auto L0 = [](){};
auto L1 = [](){};
  }

First we import `L0` then `L1`. Currently we end up having only one
CXXRecordDecl for the two different lambdas. And that is a problem if
the body of their op() is different. This happens because when we import
`L1` then lookup finds the existing `L0` and since they are structurally
equivalent we just map the imported L0 to be the counterpart of L1 
.

We have the same problem in this case:

  template 
  void f(F0 L0 = [](){}, F1 L1 = [](){}) {}

In StructuralEquivalenceContext we could distinquish lambdas only by
their source location in these cases. But we the lambdas are actually
structrually equivalent they differn only by the source location.

Thus, the  solution is to disable lookup completely if the decl in
the "from" context is a lambda.
However, that could have other problems: what if the lambda is defined
in a header file and included in several TUs? I think we'd have as many
duplicates as many includes we have. I think we could live with that,
because the lambda classes are TU local anyway, we cannot just access
them from another TU.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D66348

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


Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -5366,6 +5366,70 @@
 ::testing::Values(ArgVector{"-target",
 "aarch64-linux-gnu"}), );
 
+TEST_P(ASTImporterOptionSpecificTestBase, LambdasAreDifferentiated) {
+  Decl *FromTU = getTuDecl(
+  R"(
+  void f() {
+auto L0 = [](){};
+auto L1 = [](){};
+  }
+  )",
+  Lang_CXX11, "input0.cc");
+  auto Pattern = lambdaExpr();
+  CXXRecordDecl *FromL0 =
+  FirstDeclMatcher().match(FromTU, Pattern)->getLambdaClass();
+  CXXRecordDecl *FromL1 =
+  LastDeclMatcher().match(FromTU, Pattern)->getLambdaClass();
+  ASSERT_NE(FromL0, FromL1);
+
+  CXXRecordDecl *ToL0 = Import(FromL0, Lang_CXX11);
+  CXXRecordDecl *ToL1 = Import(FromL1, Lang_CXX11);
+  EXPECT_NE(ToL0, ToL1);
+}
+
+TEST_P(ASTImporterOptionSpecificTestBase,
+   LambdasInFunctionParamsAreDifferentiated) {
+  Decl *FromTU = getTuDecl(
+  R"(
+  template 
+  void f(F0 L0 = [](){}, F1 L1 = [](){}) {}
+  )",
+  Lang_CXX11, "input0.cc");
+  auto Pattern = cxxRecordDecl(isLambda());
+  CXXRecordDecl *FromL0 =
+  FirstDeclMatcher().match(FromTU, Pattern);
+  CXXRecordDecl *FromL1 =
+  LastDeclMatcher().match(FromTU, Pattern);
+  ASSERT_NE(FromL0, FromL1);
+
+  CXXRecordDecl *ToL0 = Import(FromL0, Lang_CXX11);
+  CXXRecordDecl *ToL1 = Import(FromL1, Lang_CXX11);
+  ASSERT_NE(ToL0, ToL1);
+}
+
+TEST_P(ASTImporterOptionSpecificTestBase,
+   LambdasInFunctionParamsAreDifferentiatedWhenMacroIsUsed) {
+  Decl *FromTU = getTuDecl(
+  R"(
+  #define LAMBDA [](){}
+  template 
+  void f(F0 L0 = LAMBDA, F1 L1 = LAMBDA) {}
+  )",
+  Lang_CXX11, "input0.cc");
+  auto Pattern = cxxRecordDecl(isLambda());
+  CXXRecordDecl *FromL0 =
+  FirstDeclMatcher().match(FromTU, Pattern);
+  CXXRecordDecl *FromL1 =
+  LastDeclMatcher().match(FromTU, Pattern);
+  ASSERT_NE(FromL0, FromL1);
+
+  Import(FromL0, Lang_CXX11);
+  Import(FromL1, Lang_CXX11);
+  CXXRecordDecl *ToL0 = Import(FromL0, Lang_CXX11);
+  CXXRecordDecl *ToL1 = Import(FromL1, Lang_CXX11);
+  ASSERT_NE(ToL0, ToL1);
+}
+
 INSTANTIATE_TEST_CASE_P(ParameterizedTests, ASTImporterLookupTableTest,
 DefaultTestValuesForRunOptions, );
 
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -2627,7 +2627,7 @@
 
   // We may already have a record of the same name; try to find and match it.
   RecordDecl *PrevDecl = nullptr;
-  if (!DC->isFunctionOrMethod()) {
+  if (!DC->isFunctionOrMethod() && !D->isLambda()) {
 SmallVector ConflictingDecls;
 auto FoundDecls =
 Importer.findDeclsInToCtx(DC, SearchName);


Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -5366,6 +5366,70 @@
 ::testing::Values(ArgVector{"-target",
 "aarch64-linux-gnu"}), );
 
+TEST_P(ASTImporterOptionSpecificTestBase, LambdasAreDifferentiated) {
+  

[PATCH] D64078: [ASTImporter] Fix structural ineq of lambdas with different sloc

2019-08-16 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

In D64078#1572675 , @a_sidorin wrote:

> Hi Gabor,
>  it is a nice design question if source locations can participate in 
> structural match or not. The comparison tells us that the same code written 
> in different files is not structurally equivalent and I cannot agree with it. 
> They can be not the same, but their structure is the same. The question is: 
> why do we get to this comparison? Do we find a non-equivalent decl by lookup? 
> I guess there can be another way to resolve this issue, and I'll be happy to 
> help if you share what is the problem behind the patch.


Hey Alexei, thanks for looking into this. I agree, that those lambdas are 
actually "structurally" equivalent even if they are defined in different 
locations...
But still we have to differentiate them somehow.
Consider this code:

  void f() {
auto L0 = [](){};
auto L1 = [](){};
  }

First we import `L0` then `L1`. Currently we end up having only one 
CXXRecordDecl for the two different lambdas. And that is a problem if the body 
of their op() is different.
This happens because when we import `L1` then lookup finds the existing `L0` 
and since they are structurally equivalent we just map the imported L0 to be 
the counterpart of L1 .

I tried to use `getLambdaManglingNumber()` as you suggested in 
https://reviews.llvm.org/D64075 and that does solve this particular case, but 
cannot solve to other issue we have in the test case 
`LambdasInFunctionParamsAreDifferentiated`:

  template 
  void f(F0 L0 = [](){}, F1 L1 = [](){}) {}

Here after importing L0, L1  is mapped to L0 again.

I tried an alternative solution, which is to disable lookup completely if the 
decl in the "from" context is a lambda. That passed all tests.
However, that could have other problems: what if the lambda is defined in a 
header file and included in several TUs? I think we'd have as many duplicates 
as many includes we have. I think we could live with that, because the lambda 
classes are TU local anyway, we cannot just access them from another TU.
I have created another patch for that solution: https://reviews.llvm.org/D66348


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64078



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


[PATCH] D66294: [Docs][OpenCL] Release 9.0 notes for OpenCL

2019-08-16 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia updated this revision to Diff 215598.

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

https://reviews.llvm.org/D66294

Files:
  docs/ReleaseNotes.rst

Index: docs/ReleaseNotes.rst
===
--- docs/ReleaseNotes.rst
+++ docs/ReleaseNotes.rst
@@ -46,6 +46,8 @@
 Major New Features
 --
 
+- Experimental support for :ref:`C++ for OpenCL ` has been
+  added.
 - ...
 
 Improvements to Clang's diagnostics
@@ -133,6 +135,14 @@
 C++ Language Changes in Clang
 -
 
+- Support for the address space attribute in various C++ features was improved,
+  refer to :ref:`C++ for OpenCL ` for more details. The following
+  features deviated from OpenCL:
+
+  (1) Address spaces as method qualifiers are not accepted yet;
+
+  (2) There is no address space deduction.
+
 - ...
 
 C++1z Feature Support
@@ -152,10 +162,86 @@
   // clang used to encode this as "^{NSArray=#}" instead of "@".
   const char *s0 = @encode(MyArray *);
 
-OpenCL C Language Changes in Clang
---
+OpenCL Kernel Language Changes in Clang
+---
 
-...
+OpenCL C
+
+
+- Enabled use of variadic macro as a Clang extension.
+
+- Added initial support for implicitly including OpenCL builtin
+  fuctions using efficient trie lookup generated by TableGen.
+  A corresponding frontend-only flag ``-fdeclare-opencl-builtins``
+  has been added to enable trie during parsing.
+
+- Refactored header file to be used for common parts between
+  regular header added using ``-finclude-default-header`` and trie
+  based declarations added using ``-fdeclare-opencl-builtins``.
+
+- Improved string formatting diagnostics in printf for vector types.
+
+- Simplified the internal representation of blocks, including their
+  generation in IR. Furthermore, indirect calls to block function
+  has been changed to direct function calls.
+
+- Added diagnostics for conversions of nested pointers with
+  different address spaces.
+
+- Added ``cl_arm_integer_dot_product`` extension.
+
+- Fixed global samplers in OpenCL v2.0.
+
+- Improved math builtin functions with parameters of type ``long
+  long`` for x86.
+
+.. _openclcpp:
+
+C++ for OpenCL
+^^
+
+Experimental support for C++17 features in OpenCL has been added
+and backwards compatibility with OpenCL C v2.0 was enabled.
+The documentation has been added for supported language features
+into :doc:`LanguageExtensions` and :doc:`UsersManual`.
+
+Implemented features are:
+- Address space behavior is improved in majority of C++ features:
+
+  - Templates parameters and arguments
+
+  - Reference types;
+
+  - Type deduction;
+
+  - Objects and member functions, including special member
+functions;
+
+  - Builtin operators;
+
+  - Method qualifiers now include address space;
+
+  - Address space deduction has been extended for C++ use cases;
+
+  - Improved overload ranking rules.
+
+  - All standard cast operators now prevent converting address
+spaces (except for conversions allowed implicitly). They
+can still be cast using C-style cast.
+
+- Vector types as in OpenCL C, including compound vector
+  initialization.
+
+- OpenCL-specific types: images, samplers, events, pipes, are
+  accepted with exception of blocks.
+
+- OpenCL standard header in Clang can be compiled in C++ mode.
+
+- Global constructors can be invoked from the host side using
+  a specific, compiler-generated kernel.
+
+- Overloads with generic address space are added to all atomic
+  builtin functions, including the ones prior to OpenCL v2.0.
 
 ABI Changes in Clang
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D66349: [clangd] Fix one testcase in XRefsTests.

2019-08-16 Thread Haojian Wu via Phabricator via cfe-commits
hokein created this revision.
hokein added a reviewer: ilya-biryukov.
Herald added subscribers: kadircet, arphaman, jkorous, MaskRay.
Herald added a project: clang.

The test didn't test anything actually -- it used "[]" as annotation which 
should be
"[[]]".

This patch also fixes a bug in XRef where we may return duplicated refs.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D66349

Files:
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp


Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -2037,35 +2037,36 @@
 TEST(FindReferences, ExplicitSymbols) {
   const char *Tests[] = {
   R"cpp(
-  struct Foo { Foo* [self]() const; };
+  struct Foo { Foo* [[self]]() const; };
   void f() {
-if (Foo* T = foo.[^self]()) {} // Foo member call expr.
+Foo foo;
+if (Foo* T = foo.[[^self]]()) {} // Foo member call expr.
   }
   )cpp",
 
   R"cpp(
   struct Foo { Foo(int); };
   Foo f() {
-int [b];
-return [^b]; // Foo constructor expr.
+int [[b]];
+return [[^b]]; // Foo constructor expr.
   }
   )cpp",
 
   R"cpp(
   struct Foo {};
   void g(Foo);
-  Foo [f]();
+  Foo [[f]]();
   void call() {
-g([^f]());  // Foo constructor expr.
+g([[^f]]());  // Foo constructor expr.
   }
   )cpp",
 
   R"cpp(
-  void [foo](int);
-  void [foo](double);
+  void [[foo]](int);
+  void [[foo]](double);
 
   namespace ns {
-  using ::[fo^o];
+  using ::[[fo^o]];
   }
   )cpp",
   };
@@ -2075,6 +2076,7 @@
 std::vector> ExpectedLocations;
 for (const auto &R : T.ranges())
   ExpectedLocations.push_back(RangeIs(R));
+ASSERT_TRUE(!ExpectedLocations.empty()) << "Testcase must provide ranges!";
 EXPECT_THAT(findReferences(AST, T.point(), 0),
 ElementsAreArray(ExpectedLocations))
 << Test;
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -383,18 +383,17 @@
   }
 
   std::vector take() && {
+// We only use the Loc to do the comparsion as a location can refer
+// to different declarations, e.g. usingDecl refers to overload functions.
 llvm::sort(References, [](const Reference &L, const Reference &R) {
-  return std::tie(L.Loc, L.CanonicalTarget, L.Role) <
- std::tie(R.Loc, R.CanonicalTarget, R.Role);
+  return L.Loc < R.Loc;
 });
 // We sometimes see duplicates when parts of the AST get traversed twice.
-References.erase(
-std::unique(References.begin(), References.end(),
-[](const Reference &L, const Reference &R) {
-  return std::tie(L.CanonicalTarget, L.Loc, L.Role) ==
- std::tie(R.CanonicalTarget, R.Loc, R.Role);
-}),
-References.end());
+References.erase(std::unique(References.begin(), References.end(),
+ [](const Reference &L, const Reference &R) {
+   return L.Loc == R.Loc;
+ }),
+ References.end());
 return std::move(References);
   }
 


Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -2037,35 +2037,36 @@
 TEST(FindReferences, ExplicitSymbols) {
   const char *Tests[] = {
   R"cpp(
-  struct Foo { Foo* [self]() const; };
+  struct Foo { Foo* [[self]]() const; };
   void f() {
-if (Foo* T = foo.[^self]()) {} // Foo member call expr.
+Foo foo;
+if (Foo* T = foo.[[^self]]()) {} // Foo member call expr.
   }
   )cpp",
 
   R"cpp(
   struct Foo { Foo(int); };
   Foo f() {
-int [b];
-return [^b]; // Foo constructor expr.
+int [[b]];
+return [[^b]]; // Foo constructor expr.
   }
   )cpp",
 
   R"cpp(
   struct Foo {};
   void g(Foo);
-  Foo [f]();
+  Foo [[f]]();
   void call() {
-g([^f]());  // Foo constructor expr.
+g([[^f]]());  // Foo constructor expr.
   }
   )cpp",
 
   R"cpp(
-  void [foo](int);
-  void [foo](double);
+  void [[foo]](int);
+  void [[foo]](double);
 
   namespace ns {
-  using ::[fo^o];
+  using ::[[fo^o]];
   }
   )cpp",
   };
@@ -2075,6 +2076,7 @@
 std::vector> ExpectedLocations;
 for (const auto &R : T.ranges())
   ExpectedLocations.push_back(RangeIs(R));
+ASSER

[PATCH] D66350: Rudimentary support for Doxygen \retval command

2019-08-16 Thread Stephan Bergmann via Phabricator via cfe-commits
sberg created this revision.
sberg added a reviewer: gribozavr.
sberg added a project: clang.
Herald added a subscriber: cfe-commits.

...so that at least a preceding \param etc. that lacks a description gets a 
-Wdocumentation warning (instead of erroneously treating the \retval ... text 
as its paragraph).


Repository:
  rC Clang

https://reviews.llvm.org/D66350

Files:
  clang/include/clang/AST/CommentCommands.td
  clang/test/Sema/warn-documentation.cpp


Index: clang/test/Sema/warn-documentation.cpp
===
--- clang/test/Sema/warn-documentation.cpp
+++ clang/test/Sema/warn-documentation.cpp
@@ -288,6 +288,11 @@
 /// \param x2 Ccc.
 int test_param22(int x1, int x2, int x3);
 
+// expected-warning@+1 {{empty paragraph passed to '\param' command}}
+/// \param a
+/// \retval 0 Blah blah.
+int test_param23(int a);
+
 //===---
 // Test that we treat typedefs to some non-function types as functions for the
 // purposes of documentation comment parsing.
Index: clang/include/clang/AST/CommentCommands.td
===
--- clang/include/clang/AST/CommentCommands.td
+++ clang/include/clang/AST/CommentCommands.td
@@ -139,6 +139,7 @@
 def Pre: BlockCommand<"pre">;
 def Remark : BlockCommand<"remark">;
 def Remarks: BlockCommand<"remarks">;
+def Retval : BlockCommand<"retval">;
 def Sa : BlockCommand<"sa">;
 def See: BlockCommand<"see">;
 def Since  : BlockCommand<"since">;


Index: clang/test/Sema/warn-documentation.cpp
===
--- clang/test/Sema/warn-documentation.cpp
+++ clang/test/Sema/warn-documentation.cpp
@@ -288,6 +288,11 @@
 /// \param x2 Ccc.
 int test_param22(int x1, int x2, int x3);
 
+// expected-warning@+1 {{empty paragraph passed to '\param' command}}
+/// \param a
+/// \retval 0 Blah blah.
+int test_param23(int a);
+
 //===---
 // Test that we treat typedefs to some non-function types as functions for the
 // purposes of documentation comment parsing.
Index: clang/include/clang/AST/CommentCommands.td
===
--- clang/include/clang/AST/CommentCommands.td
+++ clang/include/clang/AST/CommentCommands.td
@@ -139,6 +139,7 @@
 def Pre: BlockCommand<"pre">;
 def Remark : BlockCommand<"remark">;
 def Remarks: BlockCommand<"remarks">;
+def Retval : BlockCommand<"retval">;
 def Sa : BlockCommand<"sa">;
 def See: BlockCommand<"see">;
 def Since  : BlockCommand<"since">;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57450: [RISCV] Set MaxAtomicInlineWidth and MaxAtomicPromoteWidth for RV32/RV64 targets with atomics

2019-08-16 Thread Sam Elliott via Phabricator via cfe-commits
lenary planned changes to this revision.
lenary added a comment.

Upon further thought, I realise that `MaxAtomicPromoteWidth` should be set to 
128 regardless of whether a target `HasA`. I will be updating the patch with 
the new width and conditions early next week.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57450



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


[PATCH] D64943: [Clang][OpenMP offload] Eliminate use of OpenMP linker script

2019-08-16 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D64943#1619958 , @sdmitriev wrote:

> As I understand ‘atexit’ solution would be target dependent (‘__cxa_atexit’ 
> on Linux and ‘atexit’ on Windows) whereas @llvm.global_ctors/dtors variables 
> offer similar and platform neutral functionality 
> (http://llvm.org/docs/LangRef.html#the-llvm-global-ctors-global-variable). 
> Why do you think that ‘atexit’ is a better choice?


Because it does not work on Windows, better to have portable solution, if 
possible.




Comment at: clang/tools/clang-offload-wrapper/ClangOffloadWrapper.cpp:72
+private:
+  IntegerType *getSizeTTy() {
+switch (M.getDataLayout().getPointerTypeSize(Type::getInt8PtrTy(C))) {

1. Markt it `const`.
2. This still is not the best solution, since `size_t` not necessarily has the 
pointer size. I don't know if there is a better solution. @hfinkel? If this is 
the best, why not just to use `getIntPtrType(C)`?



Comment at: clang/tools/clang-offload-wrapper/ClangOffloadWrapper.cpp:135
+
+  // Creates binary descriptor for the given device images. Binary descriptor 
is
+  // an object that is passed to the offloading runtime at program startup and

Use `\\\` style for comments here



Comment at: clang/tools/clang-offload-wrapper/ClangOffloadWrapper.cpp:171
+  // Global variable that represents BinDesc is returned.
+  GlobalVariable *createBinDesc(const SmallVectorImpl &Bufs) {
+// Create external begin/end symbols for the offload entries table.

Use `ArrayRef` instead of `const SmallVectorImpl &`



Comment at: clang/tools/clang-offload-wrapper/ClangOffloadWrapper.cpp:330
+  BufferRefs.reserve(Inputs.size());
+  for (const auto &File : Inputs) {
+auto BufOrErr = MemoryBuffer::getFileOrSTDIN(File);

Use `std:string` instead of `auto`



Comment at: clang/tools/clang-offload-wrapper/ClangOffloadWrapper.cpp:331
+  for (const auto &File : Inputs) {
+auto BufOrErr = MemoryBuffer::getFileOrSTDIN(File);
+if (!BufOrErr) {

Also, better to specify type expplicitly.


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

https://reviews.llvm.org/D64943



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


[PATCH] D64943: [Clang][OpenMP offload] Eliminate use of OpenMP linker script

2019-08-16 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In D64943#1633164 , @ABataev wrote:

> In D64943#1619958 , @sdmitriev wrote:
>
> > As I understand ‘atexit’ solution would be target dependent (‘__cxa_atexit’ 
> > on Linux and ‘atexit’ on Windows) whereas @llvm.global_ctors/dtors 
> > variables offer similar and platform neutral functionality 
> > (http://llvm.org/docs/LangRef.html#the-llvm-global-ctors-global-variable). 
> > Why do you think that ‘atexit’ is a better choice?
>
>
> Because it does not work on Windows, better to have portable solution, if 
> possible.


Is there a bug # ?


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

https://reviews.llvm.org/D64943



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


[PATCH] D64943: [Clang][OpenMP offload] Eliminate use of OpenMP linker script

2019-08-16 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D64943#1633170 , @lebedev.ri wrote:

> In D64943#1633164 , @ABataev wrote:
>
> > In D64943#1619958 , @sdmitriev 
> > wrote:
> >
> > > As I understand ‘atexit’ solution would be target dependent 
> > > (‘__cxa_atexit’ on Linux and ‘atexit’ on Windows) whereas 
> > > @llvm.global_ctors/dtors variables offer similar and platform neutral 
> > > functionality 
> > > (http://llvm.org/docs/LangRef.html#the-llvm-global-ctors-global-variable).
> > >  Why do you think that ‘atexit’ is a better choice?
> >
> >
> > Because it does not work on Windows, better to have portable solution, if 
> > possible.
>
>
> Is there a bug # ?


@vzakhari?


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

https://reviews.llvm.org/D64943



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


[PATCH] D65065: [clang-tidy] Possibility of displaying duplicate warnings

2019-08-16 Thread Tibor Brunner via Phabricator via cfe-commits
bruntib added a comment.

Thank you for the valuable comments and the review!
I'm just planning to register to the bug tracker, because it is getting more 
relevant due to some other contributions as well.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D65065



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


[PATCH] D66349: [clangd] Fix one testcase in XRefsTests.

2019-08-16 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added inline comments.



Comment at: clang-tools-extra/clangd/XRefs.cpp:389
 llvm::sort(References, [](const Reference &L, const Reference &R) {
-  return std::tie(L.Loc, L.CanonicalTarget, L.Role) <
- std::tie(R.Loc, R.CanonicalTarget, R.Role);
+  return L.Loc < R.Loc;
 });

What are the elements `References` for the problematic case?

If we have duplicate elements, then `sort()` would now give us one of the 
items. Which exact `Decl` we're gonna end up seeing is not well-defined, i.e. 
it's non-deterministic.



Comment at: clang-tools-extra/clangd/unittests/XRefsTests.cpp:2079
   ExpectedLocations.push_back(RangeIs(R));
+ASSERT_TRUE(!ExpectedLocations.empty()) << "Testcase must provide ranges!";
 EXPECT_THAT(findReferences(AST, T.point(), 0),

NIT: use `ASSERT_THAT(ExpectedLocations, Not(IsEmpty()))` for more detailed 
output in case of assertion failures.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66349



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


[PATCH] D65526: [Clangd] Initial prototype version of ExtractFunction

2019-08-16 Thread Shaurya Gupta via Phabricator via cfe-commits
SureYeaah updated this revision to Diff 215615.
SureYeaah added a comment.

Fixed semicolon bug


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65526

Files:
  clang-tools-extra/clangd/refactor/tweaks/CMakeLists.txt
  clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -599,6 +599,117 @@
 R"cpp(const char * x = "test")cpp");
 }
 
+TWEAK_TEST(ExtractFunction);
+TEST_F(ExtractFunctionTest, PrepareFunctionTest) {
+  Header = R"cpp(
+#define F(BODY) void FFF() { BODY }
+  )cpp";
+  Context = Function;
+  EXPECT_AVAILABLE(R"cpp(
+[[int sum = 0;
+for(;;)
+  sum++;]]
+for(int i = 0; i < 5; i++) {
+  sum += i;
+}
+  )cpp");
+  EXPECT_AVAILABLE(R"cpp([[int x;]])cpp");
+  // TODO: Add tests for macros after selectionTree works properly for macros.
+  // EXPECT_AVAILABLE(R"cpp( F (int x = 0; [[x = 1;]])cpp");
+  // FIXME: This should be unavailable since partially selected but
+  // selectionTree doesn't always work correctly for VarDecls.
+  //EXPECT_UNAVAILABLE(R"cpp(int [[x = 0]];)cpp");
+  EXPECT_UNAVAILABLE(R"cpp(
+int sum = 0;
+for(;;)
+  [[sum++;
+sum++;]]
+  )cpp");
+  // Expressions aren't extracted.
+  EXPECT_UNAVAILABLE(R"cpp(int x = 0; [[x++;]])cpp");
+  // FIXME: ExtractFunction should be unavailable inside loop construct
+  // initalizer/condition.
+  // EXPECT_UNAVAILABLE(R"cpp( for([[int i = 0; i < 5;]] i++) )cpp");
+}
+
+TEST_F(ExtractFunctionTest, PrepareMethodTest) {
+  EXPECT_UNAVAILABLE(R"cpp(
+class T {
+  void f() {
+[[int x;]]
+  }
+};
+  )cpp");
+}
+
+TEST_F(ExtractFunctionTest, ApplyTest) {
+  // We can extract from templated functions as long as no reference in the
+  // extraction depends on the template.
+  // Checks const qualifier and extraction parameters.
+  Header = R"cpp(
+  )cpp";
+  EXPECT_EQ(apply(
+R"cpp(
+struct FOO {
+  int x;
+};
+template
+void f(int a) {
+  int b = N; T t; const int c; FOO foo;
+  int *ptr = &a;
+  [[a += foo.x;
+  b = c; 
+  *ptr++;
+  for(;;)
+int d = 5 /* check if comment is extracted */ ;]]
+})cpp"),
+R"cpp(
+struct FOO {
+  int x;
+};
+void extracted(int &a, int &b, const int &c, struct FOO &foo, int * &ptr) {
+a += foo.x;
+  b = c; 
+  *ptr++;
+  for(;;)
+int d = 5 /* check if comment is extracted */ ;
+}
+template
+void f(int a) {
+  int b = N; T t; const int c; FOO foo;
+  int *ptr = &a;
+  extracted(a, b, c, foo, ptr);
+})cpp");
+  auto ShouldSucceed = [&](llvm::StringRef Code) {
+EXPECT_THAT(apply(Code), HasSubstr("extracted"));
+  };
+  auto ShouldFail = [&](llvm::StringRef Code) {
+EXPECT_THAT(apply(Code), StartsWith("fail:"));
+  };
+  // Ensure the last break isn't included in the Source since the end of source
+  // and beginning of break are adjacent.
+  ShouldSucceed(R"cpp(
+void f() {
+  for(;;) {
+[[{}]]break;
+  }
+}
+  )cpp");
+  // Don't extract because needs hoisting.
+  ShouldFail(R"cpp( void f() { [[int a = 5;]] a++;})cpp");
+  // Don't extract parameters that depend on template.
+  ShouldFail(R"cpp( template void f() { [[int a = N;]] })cpp");
+  ShouldFail(R"cpp( template void f() { [[T t;]] })cpp");
+  // Don't extract return
+  ShouldFail(R"cpp( int f() { int a = 5; [[return a;]]})cpp");
+  // Don't extract break and continue.
+  // FIXME: We should be able to extract this.
+  ShouldFail(R"cpp( int f() { [[for(;;) break;]]})cpp");
+  ShouldFail(R"cpp( int f() { for(;;) [[continue;]]})cpp");
+  // Don't extract when we need to make a function as a parameter.
+  ShouldFail(R"cpp( void f() { [[int a; f();]] } )cpp");
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
@@ -0,0 +1,546 @@
+//===--- ExtractFunction.cpp -*- 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
+//
+//===--===//
+#include "ClangdUnit.h"
+#include "Logger.h"
+#include "Selection.h"
+#include "SourceCode.h"
+#include "refactor/Tweak.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/DeclTemplate.h"
+#include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/AST/Stmt.h"
+#include "clang/Basic/LangOptions.h"
+#include "clang/Basic/Sourc

[clang-tools-extra] r369123 - [clang-doc] Fix records in global namespace

2019-08-16 Thread Diego Astiazaran via cfe-commits
Author: diegoastiazaran
Date: Fri Aug 16 09:10:32 2019
New Revision: 369123

URL: http://llvm.org/viewvc/llvm-project?rev=369123&view=rev
Log:
[clang-doc] Fix records in global namespace

When a Record is declared in the global namespace, clang-doc serializes
it as a child of the global namespace, so the global namespace is now
one if its parent namespaces. This namespace was not being included in
the list of namespaces of the Info causing paths to be incorrect and the
index rendered incorrectly.
Affected tests have been fixed.

Differential revision: https://reviews.llvm.org/D66298

Modified:
clang-tools-extra/trunk/clang-doc/Serialize.cpp
clang-tools-extra/trunk/test/clang-doc/single-file-public.cpp
clang-tools-extra/trunk/unittests/clang-doc/SerializeTest.cpp

Modified: clang-tools-extra/trunk/clang-doc/Serialize.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-doc/Serialize.cpp?rev=369123&r1=369122&r2=369123&view=diff
==
--- clang-tools-extra/trunk/clang-doc/Serialize.cpp (original)
+++ clang-tools-extra/trunk/clang-doc/Serialize.cpp Fri Aug 16 09:10:32 2019
@@ -378,6 +378,14 @@ populateParentNamespaces(llvm::SmallVect
   Namespaces.emplace_back(getUSRForDecl(N), N->getNameAsString(),
   InfoType::IT_enum);
   }
+  // The global namespace should be added to the list of namespaces if the decl
+  // corresponds to a Record and if it doesn't have any namespace (because this
+  // means it's in the global namespace). Also if its outermost namespace is a
+  // record because that record matches the previous condition mentioned.
+  if ((Namespaces.empty() && dyn_cast(D)) ||
+  (!Namespaces.empty() && Namespaces.back().RefType == 
InfoType::IT_record))
+Namespaces.emplace_back(SymbolID(), "GlobalNamespace",
+InfoType::IT_namespace);
 }
 
 template 
@@ -528,16 +536,6 @@ emitInfo(const RecordDecl *D, const Full
   }
   I->Path = getInfoRelativePath(I->Namespace);
 
-  if (I->Namespace.empty()) {
-auto ParentI = std::make_unique();
-ParentI->USR = SymbolID();
-ParentI->ChildRecords.emplace_back(I->USR, I->Name, InfoType::IT_record,
-   getInfoRelativePath(I->Namespace));
-ParentI->Path = getInfoRelativePath(ParentI->Namespace);
-return {std::unique_ptr{std::move(I)},
-std::unique_ptr{std::move(ParentI)}};
-  }
-
   switch (I->Namespace[0].RefType) {
   case InfoType::IT_namespace: {
 auto ParentI = std::make_unique();
@@ -611,8 +609,6 @@ emitInfo(const CXXMethodDecl *D, const F
   // Wrap in enclosing scope
   auto ParentI = std::make_unique();
   ParentI->USR = ParentUSR;
-  if (Func.Namespace.empty())
-ParentI->Path = getInfoRelativePath(ParentI->Namespace);
   ParentI->ChildFunctions.emplace_back(std::move(Func));
   // Info is wrapped in its parent scope so it's returned in the second 
position
   return {nullptr, std::unique_ptr{std::move(ParentI)}};

Modified: clang-tools-extra/trunk/test/clang-doc/single-file-public.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-doc/single-file-public.cpp?rev=369123&r1=369122&r2=369123&view=diff
==
--- clang-tools-extra/trunk/test/clang-doc/single-file-public.cpp (original)
+++ clang-tools-extra/trunk/test/clang-doc/single-file-public.cpp Fri Aug 16 
09:10:32 2019
@@ -3,7 +3,7 @@
 // RUN: echo "" > %t/compile_flags.txt
 // RUN: cp "%s" "%t/test.cpp"
 // RUN: clang-doc --doxygen --public --executor=standalone -p %t %t/test.cpp 
-output=%t/docs
-// RUN: cat %t/docs/Record.yaml | FileCheck %s --check-prefix=CHECK
+// RUN: cat %t/docs/GlobalNamespace/Record.yaml | FileCheck %s 
--check-prefix=CHECK
 // RUN: rm -rf %t
 
 class Record {
@@ -21,8 +21,12 @@ void Record::function_public() {}
 // CHECK: ---
 // CHECK-NEXT: USR: 
'{{[0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z][0-9A-Z]}}'
 // CHECK-NEXT: Name:'Record'
+// CHECK-NEXT: Path:'GlobalNamespace'
+// CHECK-NEXT: Namespace:
+// CHECK-NEXT:   - Type: Namespace
+// CHECK-NEXT: Name: 'GlobalNamespace'
 // CHECK-NEXT: DefLocation:
-// CHECK-NEXT:   LineNumber:  [[@LINE-16]]
+// CHECK-NEXT:   LineNumber:  [[@LINE-20]]
 // CHECK-NEXT:   Filename:'{{.*}}'
 // CHECK-NEXT: TagType: Class
 // CHECK-NEXT: ChildFunctions:
@@ -32,11 +36,13 @@ void Record::function_public() {}
 // CHECK-NEXT:   - Type:Record
 // CHECK-NEXT: Name:'Record'
 // CHECK-NEXT: USR: 
'{{[0-9A-Z][0

[PATCH] D66328: [DebugInfo] Add debug location to dynamic atexit destructor

2019-08-16 Thread Adrian Prantl via Phabricator via cfe-commits
aprantl requested changes to this revision.
aprantl added inline comments.
This revision now requires changes to proceed.



Comment at: test/CodeGen/debug-info-no-location.cpp:4
+// CHECK-NEXT: ret void, !dbg !51
+// CHECK: !48 = distinct !DISubprogram(name: "`dynamic atexit destructor for 
'f'", scope: !3, file: !3, line: 16, type: !49, scopeLine: 16, spFlags: 
DISPFlagLocalToUnit | DISPFlagDefinition, unit: !27, retainedNodes: !29)
+// CHECK: !51 = !DILocation(line: 16, scope: !48)

Please don't hardcode metadata numbers in the tests, this is bound to break 
almost immediately.

It seems like this function is compiler-generated and thus should be marked as 
artificial?


Repository:
  rC Clang

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

https://reviews.llvm.org/D66328



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


[PATCH] D66298: [clang-doc] Fix records in global namespace

2019-08-16 Thread Diego Astiazarán via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL369123: [clang-doc] Fix records in global namespace 
(authored by DiegoAstiazaran, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D66298?vs=215537&id=215618#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D66298

Files:
  clang-tools-extra/trunk/clang-doc/Serialize.cpp
  clang-tools-extra/trunk/test/clang-doc/single-file-public.cpp
  clang-tools-extra/trunk/unittests/clang-doc/SerializeTest.cpp

Index: clang-tools-extra/trunk/unittests/clang-doc/SerializeTest.cpp
===
--- clang-tools-extra/trunk/unittests/clang-doc/SerializeTest.cpp
+++ clang-tools-extra/trunk/unittests/clang-doc/SerializeTest.cpp
@@ -137,7 +137,9 @@
10, /*Public=*/false, Infos);
 
   RecordInfo *E = InfoAsRecord(Infos[0].get());
-  RecordInfo ExpectedE(EmptySID, "E");
+  RecordInfo ExpectedE(EmptySID, /*Name=*/"E", /*Path=*/"GlobalNamespace");
+  ExpectedE.Namespace.emplace_back(EmptySID, "GlobalNamespace",
+   InfoType::IT_namespace);
   ExpectedE.TagType = TagTypeKind::TTK_Class;
   ExpectedE.DefLoc = Location(0, llvm::SmallString<16>{"test.cpp"});
   CheckRecordInfo(&ExpectedE, E);
@@ -150,6 +152,8 @@
   EConstructor.ReturnType = TypeInfo(EmptySID, "void", InfoType::IT_default);
   EConstructor.DefLoc = Location(0, llvm::SmallString<16>{"test.cpp"});
   EConstructor.Namespace.emplace_back(EmptySID, "E", InfoType::IT_record);
+  EConstructor.Namespace.emplace_back(EmptySID, "GlobalNamespace",
+  InfoType::IT_namespace);
   EConstructor.Access = AccessSpecifier::AS_public;
   EConstructor.IsMethod = true;
   ExpectedRecordWithEConstructor.ChildFunctions.emplace_back(
@@ -164,13 +168,17 @@
   Method.ReturnType = TypeInfo(EmptySID, "void", InfoType::IT_default);
   Method.Loc.emplace_back(0, llvm::SmallString<16>{"test.cpp"});
   Method.Namespace.emplace_back(EmptySID, "E", InfoType::IT_record);
+  Method.Namespace.emplace_back(EmptySID, "GlobalNamespace",
+InfoType::IT_namespace);
   Method.Access = AccessSpecifier::AS_protected;
   Method.IsMethod = true;
   ExpectedRecordWithMethod.ChildFunctions.emplace_back(std::move(Method));
   CheckRecordInfo(&ExpectedRecordWithMethod, RecordWithMethod);
 
   RecordInfo *F = InfoAsRecord(Infos[4].get());
-  RecordInfo ExpectedF(EmptySID, "F");
+  RecordInfo ExpectedF(EmptySID, /*Name=*/"F", /*Path=*/"GlobalNamespace");
+  ExpectedF.Namespace.emplace_back(EmptySID, "GlobalNamespace",
+   InfoType::IT_namespace);
   ExpectedF.TagType = TagTypeKind::TTK_Struct;
   ExpectedF.DefLoc = Location(0, llvm::SmallString<16>{"test.cpp"});
   CheckRecordInfo(&ExpectedF, F);
@@ -183,6 +191,8 @@
   TemplateMethod.ReturnType = TypeInfo(EmptySID, "void", InfoType::IT_default);
   TemplateMethod.Loc.emplace_back(0, llvm::SmallString<16>{"test.cpp"});
   TemplateMethod.Namespace.emplace_back(EmptySID, "F", InfoType::IT_record);
+  TemplateMethod.Namespace.emplace_back(EmptySID, "GlobalNamespace",
+InfoType::IT_namespace);
   TemplateMethod.Access = AccessSpecifier::AS_public;
   TemplateMethod.IsMethod = true;
   ExpectedRecordWithTemplateMethod.ChildFunctions.emplace_back(
@@ -201,6 +211,8 @@
  llvm::SmallString<16>{"test.cpp"});
   SpecializedTemplateMethod.Namespace.emplace_back(EmptySID, "F",
InfoType::IT_record);
+  SpecializedTemplateMethod.Namespace.emplace_back(EmptySID, "GlobalNamespace",
+   InfoType::IT_namespace);
   SpecializedTemplateMethod.Access = AccessSpecifier::AS_public;
   SpecializedTemplateMethod.IsMethod = true;
   ExpectedTemplatedRecord.ChildFunctions.emplace_back(
@@ -208,7 +220,9 @@
   CheckRecordInfo(&ExpectedTemplatedRecord, TemplatedRecord);
 
   RecordInfo *G = InfoAsRecord(Infos[8].get());
-  RecordInfo ExpectedG(EmptySID, "G");
+  RecordInfo ExpectedG(EmptySID, /*Name=*/"G", /*Path=*/"GlobalNamespace");
+  ExpectedG.Namespace.emplace_back(EmptySID, "GlobalNamespace",
+   InfoType::IT_namespace);
   ExpectedG.TagType = TagTypeKind::TTK_Struct;
   ExpectedG.DefLoc = Location(0, llvm::SmallString<16>{"test.cpp"});
   ExpectedG.IsTypeDef = true;
@@ -248,7 +262,9 @@
   ExtractInfosFromCode("class E;", 2, /*Public=*/false, Infos);
 
   RecordInfo *E = InfoAsRecord(Infos[0].get());
-  RecordInfo ExpectedE(EmptySID, "E");
+  RecordInfo ExpectedE(EmptySID, /*Name=*/"E", /*Path=*/"GlobalNamespace");
+  ExpectedE.Namespace.emplace_back(EmptySID, "GlobalNamespace",
+   InfoType::IT_nam

[PATCH] D66353: [clang-doc] Redesign of generated HTML files

2019-08-16 Thread Diego Astiazarán via Phabricator via cfe-commits
DiegoAstiazaran updated this revision to Diff 215624.
DiegoAstiazaran added a comment.

Run clang-format


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

https://reviews.llvm.org/D66353

Files:
  clang-tools-extra/clang-doc/HTMLGenerator.cpp
  clang-tools-extra/clang-doc/Representation.cpp
  clang-tools-extra/clang-doc/Representation.h
  clang-tools-extra/clang-doc/assets/clang-doc-default-stylesheet.css
  clang-tools-extra/clang-doc/assets/index.js
  clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
  clang-tools-extra/docs/clang-doc.rst
  clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp

Index: clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
===
--- clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
+++ clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
@@ -25,7 +25,8 @@
 ClangDocContext
 getClangDocContext(std::vector UserStylesheets = {},
StringRef RepositoryUrl = "") {
-  ClangDocContext CDCtx{{}, {}, {}, {}, RepositoryUrl, UserStylesheets, {}};
+  ClangDocContext CDCtx{
+  {}, "test-project", {}, {}, {}, RepositoryUrl, UserStylesheets, {}};
   CDCtx.UserStylesheets.insert(
   CDCtx.UserStylesheets.begin(),
   "../share/clang/clang-doc-default-stylesheet.css");
@@ -61,67 +62,75 @@
 
 
 
-
-
-  
-
-  Namespaces
-
-  
-  
-
-  Records
-
-  
-  
-
-  Functions
-
+test-project
+
+  
+  
+namespace Namespace
+Namespaces
 
   
-
-  OneFunction
-
+ChildNamespace
   
 
-  
-  
-
-  Enums
-
+Records
 
   
-
-  OneEnum
-
+ChildStruct
   
 
-  
-
-
-  namespace Namespace
-  Namespaces
-  
-
-  ChildNamespace
-
-  
-  Records
-  
-
-  ChildStruct
-
-  
-  Functions
-  
-OneFunction
-OneFunction()
+Functions
+
+  OneFunction
+  OneFunction()
+
+Enums
+
+  enum OneEnum
+
   
-  Enums
-  
-enum OneEnum
+  
+
+  
+
+  Namespaces
+
+  
+  
+
+  Records
+
+  
+  
+
+  Functions
+
+
+  
+
+  OneFunction
+
+  
+
+  
+  
+
+  Enums
+
+
+  
+
+  OneEnum
+
+  
+
+  
+
   
-
+
+
+  clang-doc version unknown
+
 )raw";
 
   EXPECT_EQ(Expected, Actual.str());
@@ -162,80 +171,88 @@
 class r
 
 
-
-
-  
-
-  Members
-
-  
-  
-
-  Records
-
-  
-  
-
-  Functions
-
+test-project
+
+  
+  
+class r
+
+  Defined at line 
+  http://www.repository.com/dir/test.cpp#10";>10
+   of file 
+  http://www.repository.com/dir/test.cpp";>test.cpp
+
+
+  Inherits from 
+  F
+  , G
+
+Members
 
   
-
-  OneFunction
-
+private 
+int
+ X
   
 
-  
-  
-
-  Enums
-
+Records
 
   
-
-  OneEnum
-
+ChildStruct
   
 
-  
-
-
-  class r
-  
-Defined at line 
-http://www.repository.com/dir/test.cpp#10";>10
- of file 
-http://www.repository.com/dir/test.cpp";>test.cpp
-  
-  
-Inherits from 
-F
-, G
-  
-  Members
-  
-
-  private 
-  int
-   X
-
-  
-  Records
-  
-
-  ChildStruct
-
-  
-  Functions
-  
-OneFunction
-public OneFunction()
+Functions
+
+  OneFunction
+  public OneFunction()
+
+Enums
+
+  enum OneEnum
+
   
-  Enums
-  
-enum OneEnum
+  
+
+  
+
+  Members
+
+  
+  
+
+  Records
+
+  
+  
+
+  Functions
+
+
+  
+
+  OneFunction
+
+  
+
+  
+  
+
+  Enums
+
+
+  
+
+  OneEnum
+
+  
+
+  
+
   
-
+
+
+  clang-doc version unknown
+
 )raw";
 
   EXPECT_EQ(Expected, Actual.str());
@@ -270,17 +287,24 @@
 
 
 
-
-
-  f
-  
-float
- f(
-int
- P)
-  
-  Defined at line 10 of file dir/test.cpp
-
+test-project
+
+  
+  
+f
+
+  float
+   f(
+  int
+   P)
+
+Defined at line 10 of file dir/test.cpp
+  
+  
+
+
+  clang-doc version unknown
+
 )raw";
 
   EXPECT_EQ(Expected, Actual.str());
@@ -309,19 +333,26 @@
 
 
 
-
-
-  enum class e
-  
-X
-  
-  
-Defined at line 
-https://www.repository.com/test.cpp#10";>10
- of file 
-https://www.repository.com/test.cpp";>test.cpp
-  
-
+test-project
+
+  
+  
+enum class e
+
+  X
+
+
+  Defined a

[PATCH] D63325: [Support][Time profiler] Make FE codegen blocks to be inside frontend blocks

2019-08-16 Thread Anton Afanasyev via Phabricator via cfe-commits
anton-afanasyev added a comment.

Ping!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63325



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


[PATCH] D66353: [clang-doc] Redesign of generated HTML files

2019-08-16 Thread Julie Hockett via Phabricator via cfe-commits
juliehockett added inline comments.



Comment at: clang-tools-extra/clang-doc/HTMLGenerator.cpp:487-489
+static std::unique_ptr
+genFileMainNode(StringRef InfoPath,
+std::vector> &MainContentInnerNodes,

Would you be able to briefly comment on each of these `gen*Node` functions on 
what exactly they're doing? I'm having trouble getting a picture of what the 
flow is there



Comment at: clang-tools-extra/clang-doc/HTMLGenerator.cpp:523
+  auto SpanNode =
+  std::make_unique(HTMLTag::TAG_SPAN, "clang-doc version 
unknown");
+  SpanNode->Attributes.emplace_back("class", "no-break");

Try using `getClangToolFullVersion` for here? 
https://clang.llvm.org/doxygen/namespaceclang.html#a35fdf9e05d2640414289e62cc837bf78



Comment at: clang-tools-extra/clang-doc/HTMLGenerator.cpp:828
+  std::vector> MainContentNodes;
+  std::make_unique(HTMLTag::TAG_DIV);
   Index InfoIndex;

This isn't doing anything


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

https://reviews.llvm.org/D66353



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


[PATCH] D66324: clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM

2019-08-16 Thread Paul Kirth via Phabricator via cfe-commits
paulkirth added a comment.

In D66324#1632653 , @lebedev.ri wrote:

> This is marked as child revision of D65300  
> but it seems like they both add
>  the same logic, just into different components, D65300 
>  to clang, this to llvm.
>  Is this duplication or are the diffs concurrent?


So this change extends and revises what is in D65300 
.  The diffs are somewhat concurrent. For 
example the backend changes rely on the frontend warning being available. i.e. 
diag::warn_profile_data_misexpect.  But yes the logic is mostly the same.

I'm also not terribly familiar with Phabricator, so maybe I should have 
uploaded a diff between my two revisions, rather than between the my changes 
and top of tree?

> Can D65300  be re-implemented to just use 
> this llvm code?

So it is possible to handle this completely in the backed, but the diagnostic 
output is not fantastic when using clang based instrumentation. In particular, 
we would need to emit the diagnostic in LowerExpectIntrisic.cpp by checking if 
the branch weight metadata already exists, and processing it there before it is 
overwritten. For some reason emitting the diagnostic at that point will not 
also emit the helpful source listing if there is a macro, even though a 
FullSourceLoc is available. This isn't an issue for either the handling in 
SampleProfile.cpp or in PGOInstrumentation.cpp.

In the end, I decided that it actually made sense for clang to handle the clang 
based instrumentation, and llvm to handle the IR/Sampling instrumentation.

> I'm also thinking the clang-misexpect *tool* should be a separate change,
>  it's misleading to have it here as it gives impression that it **has** to be 
> used,
>  which i'm not sure is so?

Sure, I can update this so that the standalone tool is in a separate change. 
The thought was to consolidate all the related changes needed for the 
standalone tool, but I see your point.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66324



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


[PATCH] D64943: [Clang][OpenMP offload] Eliminate use of OpenMP linker script

2019-08-16 Thread Vyacheslav Zakharin via Phabricator via cfe-commits
vzakhari added a comment.

In D64943#1633175 , @ABataev wrote:

> In D64943#1633170 , @lebedev.ri 
> wrote:
>
> > In D64943#1633164 , @ABataev wrote:
> >
> > > In D64943#1619958 , @sdmitriev 
> > > wrote:
> > >
> > > > As I understand ‘atexit’ solution would be target dependent 
> > > > (‘__cxa_atexit’ on Linux and ‘atexit’ on Windows) whereas 
> > > > @llvm.global_ctors/dtors variables offer similar and platform neutral 
> > > > functionality 
> > > > (http://llvm.org/docs/LangRef.html#the-llvm-global-ctors-global-variable).
> > > >  Why do you think that ‘atexit’ is a better choice?
> > >
> > >
> > > Because it does not work on Windows, better to have portable solution, if 
> > > possible.
> >
> >
> > Is there a bug # ?
>
>
> @vzakhari?


I do not have bug #, but the issue was introduced with the following commit:
commit f803b23879d9e1d9415ec1875713534dcc203df5 

Author: Reid Kleckner 
Date:   Fri Sep 7 23:07:55 2018 +

  [COFF] Implement llvm.global_ctors priorities for MSVC COFF targets
  
  Summary:
  MSVC and LLD sort sections ASCII-betically, so we need to use section
  names that sort between .CRT$XCA (the start) and .CRT$XCU (the default
  priority).
  
  In the general case, use .CRT$XCT12345 as the section name, and let the
  linker sort the zero-padded digits.
  
  Users with low priorities typically want to initialize as early as
  possible, so use .CRT$XCA00199 for prioties less than 200. This number
  is arbitrary.
  
  Implements PR38552.
  
  Reviewers: majnemer, mstorsjo
  
  Subscribers: hiraditya, llvm-commits
  
  Differential Revision: https://reviews.llvm.org/D51820
  
  llvm-svn: 341727

The destructors are still in .CRT$XT for default priority (65535) now, but for 
non-default priority they will go into .CRT$XC.  I will upload a fixing patch 
with a LIT test shortly.

This clang-offload-wrapper commit will work properly, if we use default 
priority for the destructors.


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

https://reviews.llvm.org/D64943



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


[PATCH] D64943: [Clang][OpenMP offload] Eliminate use of OpenMP linker script

2019-08-16 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In D64943#1633357 , @vzakhari wrote:

> In D64943#1633175 , @ABataev wrote:
>
> > In D64943#1633170 , @lebedev.ri 
> > wrote:
> >
> > > In D64943#1633164 , @ABataev 
> > > wrote:
> > >
> > > > In D64943#1619958 , @sdmitriev 
> > > > wrote:
> > > >
> > > > > As I understand ‘atexit’ solution would be target dependent 
> > > > > (‘__cxa_atexit’ on Linux and ‘atexit’ on Windows) whereas 
> > > > > @llvm.global_ctors/dtors variables offer similar and platform neutral 
> > > > > functionality 
> > > > > (http://llvm.org/docs/LangRef.html#the-llvm-global-ctors-global-variable).
> > > > >  Why do you think that ‘atexit’ is a better choice?
> > > >
> > > >
> > > > Because it does not work on Windows, better to have portable solution, 
> > > > if possible.
> > >
> > >
> > > Is there a bug # ?
> >
> >
> > @vzakhari?
>
>
> I do not have bug #, but the issue was introduced with the following commit:
>  commit f803b23879d9e1d9415ec1875713534dcc203df5 
> 
>  Author: Reid Kleckner 
>  Date:   Fri Sep 7 23:07:55 2018 +
>
>   [COFF] Implement llvm.global_ctors priorities for MSVC COFF targets
>   
>   Summary:
>   MSVC and LLD sort sections ASCII-betically, so we need to use section
>   names that sort between .CRT$XCA (the start) and .CRT$XCU (the default
>   priority).
>   
>   In the general case, use .CRT$XCT12345 as the section name, and let the
>   linker sort the zero-padded digits.
>   
>   Users with low priorities typically want to initialize as early as
>   possible, so use .CRT$XCA00199 for prioties less than 200. This number
>   is arbitrary.
>   
>   Implements PR38552.
>   
>   Reviewers: majnemer, mstorsjo
>   
>   Subscribers: hiraditya, llvm-commits
>   
>   Differential Revision: https://reviews.llvm.org/D51820
>   
>   llvm-svn: 341727
>   
>   
>
> The destructors are still in .CRT$XT for default priority (65535) now, but 
> for non-default priority they will go into .CRT$XC.  I will upload a fixing 
> patch with a LIT test shortly.
>
> This clang-offload-wrapper commit will work properly, if we use default 
> priority for the destructors.


'IMHO' if there is a problem with lowering of LLVM IR constructs for some
particular targets, that problem must be resolved instead of adding workarounds.


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

https://reviews.llvm.org/D64943



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


[PATCH] D64943: [Clang][OpenMP offload] Eliminate use of OpenMP linker script

2019-08-16 Thread Vyacheslav Zakharin via Phabricator via cfe-commits
vzakhari added a comment.

In D64943#1633372 , @lebedev.ri wrote:

> In D64943#1633357 , @vzakhari wrote:
>
> > In D64943#1633175 , @ABataev wrote:
> >
> > > In D64943#1633170 , @lebedev.ri 
> > > wrote:
> > >
> > > > In D64943#1633164 , @ABataev 
> > > > wrote:
> > > >
> > > > > In D64943#1619958 , 
> > > > > @sdmitriev wrote:
> > > > >
> > > > > > As I understand ‘atexit’ solution would be target dependent 
> > > > > > (‘__cxa_atexit’ on Linux and ‘atexit’ on Windows) whereas 
> > > > > > @llvm.global_ctors/dtors variables offer similar and platform 
> > > > > > neutral functionality 
> > > > > > (http://llvm.org/docs/LangRef.html#the-llvm-global-ctors-global-variable).
> > > > > >  Why do you think that ‘atexit’ is a better choice?
> > > > >
> > > > >
> > > > > Because it does not work on Windows, better to have portable 
> > > > > solution, if possible.
> > > >
> > > >
> > > > Is there a bug # ?
> > >
> > >
> > > @vzakhari?
> >
> >
> > I do not have bug #, but the issue was introduced with the following commit:
> >  commit f803b23879d9e1d9415ec1875713534dcc203df5 
> > 
> >  Author: Reid Kleckner 
> >  Date:   Fri Sep 7 23:07:55 2018 +
> >
> >   [COFF] Implement llvm.global_ctors priorities for MSVC COFF targets
> >   
> >   Summary:
> >   MSVC and LLD sort sections ASCII-betically, so we need to use section
> >   names that sort between .CRT$XCA (the start) and .CRT$XCU (the default
> >   priority).
> >   
> >   In the general case, use .CRT$XCT12345 as the section name, and let the
> >   linker sort the zero-padded digits.
> >   
> >   Users with low priorities typically want to initialize as early as
> >   possible, so use .CRT$XCA00199 for prioties less than 200. This number
> >   is arbitrary.
> >   
> >   Implements PR38552.
> >   
> >   Reviewers: majnemer, mstorsjo
> >   
> >   Subscribers: hiraditya, llvm-commits
> >   
> >   Differential Revision: https://reviews.llvm.org/D51820
> >   
> >   llvm-svn: 341727
> >   
> >   
> >
> > The destructors are still in .CRT$XT for default priority (65535) now, but 
> > for non-default priority they will go into .CRT$XC.  I will upload a fixing 
> > patch with a LIT test shortly.
> >
> > This clang-offload-wrapper commit will work properly, if we use default 
> > priority for the destructors.
>
>
> 'IMHO' if there is a problem with lowering of LLVM IR constructs for some
>  particular targets, that problem must be resolved instead of adding 
> workarounds.


I completely agree with you!  I am testing the patch for destructors.


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

https://reviews.llvm.org/D64943



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


[PATCH] D66332: [clang-format] Fix the bug that joins template closer and > or >>

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

LGTM


Repository:
  rC Clang

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

https://reviews.llvm.org/D66332



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


[PATCH] D66332: [clang-format] Fix the bug that joins template closer and > or >>

2019-08-16 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added a comment.

Drive-by observation: My experiments with 
https://zed0.co.uk/clang-format-configurator/ show that there is a similar bug 
where clang-format accidentally produces `>=` via reformatting of 
`template` `=0>`, `pi` `=3;`, and so on. Is it 
possible to fix that bug as part of this patch, and/or would you be interested 
in patching that bug as a follow-up to this one?


Repository:
  rC Clang

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

https://reviews.llvm.org/D66332



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


[PATCH] D66353: [clang-doc] Redesign of generated HTML files

2019-08-16 Thread Diego Astiazarán via Phabricator via cfe-commits
DiegoAstiazaran updated this revision to Diff 215642.
DiegoAstiazaran marked 3 inline comments as done.
DiegoAstiazaran added a comment.

Add comments.
Fix clang-doc version.


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

https://reviews.llvm.org/D66353

Files:
  clang-tools-extra/clang-doc/HTMLGenerator.cpp
  clang-tools-extra/clang-doc/Representation.cpp
  clang-tools-extra/clang-doc/Representation.h
  clang-tools-extra/clang-doc/assets/clang-doc-default-stylesheet.css
  clang-tools-extra/clang-doc/assets/index.js
  clang-tools-extra/clang-doc/tool/ClangDocMain.cpp
  clang-tools-extra/docs/clang-doc.rst
  clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp

Index: clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
===
--- clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
+++ clang-tools-extra/unittests/clang-doc/HTMLGeneratorTest.cpp
@@ -10,11 +10,15 @@
 #include "Generators.h"
 #include "Representation.h"
 #include "Serialize.h"
+#include "clang/Basic/Version.h"
 #include "gtest/gtest.h"
 
 namespace clang {
 namespace doc {
 
+static const std::string ClangDocVersion =
+clang::getClangToolFullVersion("clang-doc");
+
 std::unique_ptr getHTMLGenerator() {
   auto G = doc::findGeneratorByName("html");
   if (!G)
@@ -25,7 +29,8 @@
 ClangDocContext
 getClangDocContext(std::vector UserStylesheets = {},
StringRef RepositoryUrl = "") {
-  ClangDocContext CDCtx{{}, {}, {}, {}, RepositoryUrl, UserStylesheets, {}};
+  ClangDocContext CDCtx{
+  {}, "test-project", {}, {}, {}, RepositoryUrl, UserStylesheets, {}};
   CDCtx.UserStylesheets.insert(
   CDCtx.UserStylesheets.begin(),
   "../share/clang/clang-doc-default-stylesheet.css");
@@ -61,67 +66,76 @@
 
 
 
-
-
-  
-
-  Namespaces
-
-  
-  
-
-  Records
-
-  
-  
-
-  Functions
-
+test-project
+
+  
+  
+namespace Namespace
+Namespaces
 
   
-
-  OneFunction
-
+ChildNamespace
   
 
-  
-  
-
-  Enums
-
+Records
 
   
-
-  OneEnum
-
+ChildStruct
   
 
-  
-
-
-  namespace Namespace
-  Namespaces
-  
-
-  ChildNamespace
-
-  
-  Records
-  
-
-  ChildStruct
-
-  
-  Functions
-  
-OneFunction
-OneFunction()
+Functions
+
+  OneFunction
+  OneFunction()
+
+Enums
+
+  enum OneEnum
+
   
-  Enums
-  
-enum OneEnum
+  
+
+  
+
+  Namespaces
+
+  
+  
+
+  Records
+
+  
+  
+
+  Functions
+
+
+  
+
+  OneFunction
+
+  
+
+  
+  
+
+  Enums
+
+
+  
+
+  OneEnum
+
+  
+
+  
+
   
-
+
+
+  )raw" +
+ ClangDocVersion + R"raw(
+
 )raw";
 
   EXPECT_EQ(Expected, Actual.str());
@@ -162,80 +176,89 @@
 class r
 
 
-
-
-  
-
-  Members
-
-  
-  
-
-  Records
-
-  
-  
-
-  Functions
-
+test-project
+
+  
+  
+class r
+
+  Defined at line 
+  http://www.repository.com/dir/test.cpp#10";>10
+   of file 
+  http://www.repository.com/dir/test.cpp";>test.cpp
+
+
+  Inherits from 
+  F
+  , G
+
+Members
 
   
-
-  OneFunction
-
+private 
+int
+ X
   
 
-  
-  
-
-  Enums
-
+Records
 
   
-
-  OneEnum
-
+ChildStruct
   
 
-  
-
-
-  class r
-  
-Defined at line 
-http://www.repository.com/dir/test.cpp#10";>10
- of file 
-http://www.repository.com/dir/test.cpp";>test.cpp
-  
-  
-Inherits from 
-F
-, G
-  
-  Members
-  
-
-  private 
-  int
-   X
-
-  
-  Records
-  
-
-  ChildStruct
-
-  
-  Functions
-  
-OneFunction
-public OneFunction()
+Functions
+
+  OneFunction
+  public OneFunction()
+
+Enums
+
+  enum OneEnum
+
   
-  Enums
-  
-enum OneEnum
+  
+
+  
+
+  Members
+
+  
+  
+
+  Records
+
+  
+  
+
+  Functions
+
+
+  
+
+  OneFunction
+
+  
+
+  
+  
+
+  Enums
+
+
+  
+
+  OneEnum
+
+  
+
+  
+
   
-
+
+
+  )raw" +
+ ClangDocVersion + R"raw(
+
 )raw";
 
   EXPECT_EQ(Expected, Actual.str());
@@ -270,17 +293,25 @@
 
 
 
-
-
-  f
-  
-float
- f(
-int
- P)
-  
-  Defined at line 10 of file dir/test.cp

[PATCH] D66324: clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM

2019-08-16 Thread Paul Kirth via Phabricator via cfe-commits
paulkirth updated this revision to Diff 215643.
paulkirth edited the summary of this revision.
paulkirth added a comment.
Herald added subscribers: dexonsmith, steven_wu, mehdi_amini.

Removes standalone clang-misexpect from revision


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66324

Files:
  clang-tools-extra/CMakeLists.txt
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CMakeLists.txt
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/MisExpect.cpp
  clang/lib/CodeGen/MisExpect.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Profile/Inputs/misexpect-branch-nonconst-expect-arg.proftext
  clang/test/Profile/Inputs/misexpect-branch.proftext
  clang/test/Profile/Inputs/misexpect-switch-default-only.proftext
  clang/test/Profile/Inputs/misexpect-switch.proftext
  clang/test/Profile/misexpect-branch-cold.c
  clang/test/Profile/misexpect-branch-nonconst-expected-val.c
  clang/test/Profile/misexpect-branch.c
  clang/test/Profile/misexpect-no-warning-without-flag.c
  clang/test/Profile/misexpect-switch-default.c
  clang/test/Profile/misexpect-switch-nonconst.c
  clang/test/Profile/misexpect-switch-only-default-case.c
  clang/test/Profile/misexpect-switch.c
  llvm/include/llvm/IR/DiagnosticInfo.h
  llvm/include/llvm/IR/FixedMetadataKinds.def
  llvm/include/llvm/IR/MDBuilder.h
  llvm/include/llvm/Transforms/Utils/MisExpect.h
  llvm/lib/IR/DiagnosticInfo.cpp
  llvm/lib/IR/MDBuilder.cpp
  llvm/lib/Transforms/IPO/SampleProfile.cpp
  llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
  llvm/lib/Transforms/Scalar/LowerExpectIntrinsic.cpp
  llvm/lib/Transforms/Utils/CMakeLists.txt
  llvm/lib/Transforms/Utils/MisExpect.cpp
  llvm/test/ThinLTO/X86/lazyload_metadata.ll
  llvm/test/Transforms/LowerExpectIntrinsic/basic.ll

Index: llvm/test/Transforms/LowerExpectIntrinsic/basic.ll
===
--- llvm/test/Transforms/LowerExpectIntrinsic/basic.ll
+++ llvm/test/Transforms/LowerExpectIntrinsic/basic.ll
@@ -138,7 +138,7 @@
   %conv1 = sext i32 %conv to i64
   %expval = call i64 @llvm.expect.i64(i64 %conv1, i64 0)
   %tobool = icmp ne i64 %expval, 0
-; CHECK: !prof !1
+; CHECK: !prof !2
 ; CHECK-NOT: @llvm.expect
   br i1 %tobool, label %if.then, label %if.end
 
@@ -165,7 +165,7 @@
   %tmp = load i32, i32* %x.addr, align 4
   %conv = sext i32 %tmp to i64
   %expval = call i64 @llvm.expect.i64(i64 %conv, i64 1)
-; CHECK: !prof !2
+; CHECK: !prof !4
 ; CHECK-NOT: @llvm.expect
   switch i64 %expval, label %sw.epilog [
 i64 1, label %sw.bb
@@ -194,7 +194,7 @@
   %tmp = load i32, i32* %x.addr, align 4
   %conv = sext i32 %tmp to i64
   %expval = call i64 @llvm.expect.i64(i64 %conv, i64 1)
-; CHECK: !prof !3
+; CHECK: !prof !5
 ; CHECK-NOT: @llvm.expect
   switch i64 %expval, label %sw.epilog [
 i64 2, label %sw.bb
@@ -278,7 +278,7 @@
   %t7 = call i64 @llvm.expect.i64(i64 %t6, i64 0)
   %t8 = icmp ne i64 %t7, 0
   %t9 = select i1 %t8, i32 1, i32 2
-; CHECK: select{{.*}}, !prof !1
+; CHECK: select{{.*}}, !prof !2
   ret i32 %t9
 }
 
@@ -286,6 +286,6 @@
 declare i1 @llvm.expect.i1(i1, i1) nounwind readnone
 
 ; CHECK: !0 = !{!"branch_weights", i32 2000, i32 1}
-; CHECK: !1 = !{!"branch_weights", i32 1, i32 2000}
-; CHECK: !2 = !{!"branch_weights", i32 1, i32 2000, i32 1}
-; CHECK: !3 = !{!"branch_weights", i32 2000, i32 1, i32 1}
+; CHECK: !2 = !{!"branch_weights", i32 1, i32 2000}
+; CHECK: !4 = !{!"branch_weights", i32 1, i32 2000, i32 1}
+; CHECK: !5 = !{!"branch_weights", i32 2000, i32 1, i32 1}
Index: llvm/test/ThinLTO/X86/lazyload_metadata.ll
===
--- llvm/test/ThinLTO/X86/lazyload_metadata.ll
+++ llvm/test/ThinLTO/X86/lazyload_metadata.ll
@@ -10,13 +10,13 @@
 ; RUN: llvm-lto -thinlto-action=import %t2.bc -thinlto-index=%t3.bc \
 ; RUN:  -o /dev/null -stats \
 ; RUN:  2>&1 | FileCheck %s -check-prefix=LAZY
-; LAZY: 61 bitcode-reader  - Number of Metadata records loaded
+; LAZY: 63 bitcode-reader  - Number of Metadata records loaded
 ; LAZY: 2 bitcode-reader  - Number of MDStrings loaded
 
 ; RUN: llvm-lto -thinlto-action=import %t2.bc -thinlto-index=%t3.bc \
 ; RUN:  -o /dev/null -disable-ondemand-mds-loading -stats \
 ; RUN:  2>&1 | FileCheck %s -check-prefix=NOTLAZY
-; NOTLAZY: 70 bitcode-reader  - Number of Metadata records loaded
+; NOTLAZY: 72 bitcode-reader  - Number of Metadata records loaded
 ; NOTLAZY: 7 bitcode-reader  - Number of MDStrings loaded
 
 
Index: llvm/lib/Transforms/Utils/MisExpect.cpp
===
--- /dev/null
+++ llvm/lib/Transform

[PATCH] D66353: [clang-doc] Redesign of generated HTML files

2019-08-16 Thread Julie Hockett via Phabricator via cfe-commits
juliehockett accepted this revision.
juliehockett added a comment.
This revision is now accepted and ready to land.

LGTM


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

https://reviews.llvm.org/D66353



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


[PATCH] D66324: clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM

2019-08-16 Thread Paul Kirth via Phabricator via cfe-commits
paulkirth updated this revision to Diff 215646.
paulkirth added a comment.

Remove reference to clang-misexpect from CMakeLists.txt


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66324

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CMakeLists.txt
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/MisExpect.cpp
  clang/lib/CodeGen/MisExpect.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Profile/Inputs/misexpect-branch-nonconst-expect-arg.proftext
  clang/test/Profile/Inputs/misexpect-branch.proftext
  clang/test/Profile/Inputs/misexpect-switch-default-only.proftext
  clang/test/Profile/Inputs/misexpect-switch.proftext
  clang/test/Profile/misexpect-branch-cold.c
  clang/test/Profile/misexpect-branch-nonconst-expected-val.c
  clang/test/Profile/misexpect-branch.c
  clang/test/Profile/misexpect-no-warning-without-flag.c
  clang/test/Profile/misexpect-switch-default.c
  clang/test/Profile/misexpect-switch-nonconst.c
  clang/test/Profile/misexpect-switch-only-default-case.c
  clang/test/Profile/misexpect-switch.c
  llvm/include/llvm/IR/DiagnosticInfo.h
  llvm/include/llvm/IR/FixedMetadataKinds.def
  llvm/include/llvm/IR/MDBuilder.h
  llvm/include/llvm/Transforms/Utils/MisExpect.h
  llvm/lib/IR/DiagnosticInfo.cpp
  llvm/lib/IR/MDBuilder.cpp
  llvm/lib/Transforms/IPO/SampleProfile.cpp
  llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
  llvm/lib/Transforms/Scalar/LowerExpectIntrinsic.cpp
  llvm/lib/Transforms/Utils/CMakeLists.txt
  llvm/lib/Transforms/Utils/MisExpect.cpp
  llvm/test/ThinLTO/X86/lazyload_metadata.ll
  llvm/test/Transforms/LowerExpectIntrinsic/basic.ll

Index: llvm/test/Transforms/LowerExpectIntrinsic/basic.ll
===
--- llvm/test/Transforms/LowerExpectIntrinsic/basic.ll
+++ llvm/test/Transforms/LowerExpectIntrinsic/basic.ll
@@ -138,7 +138,7 @@
   %conv1 = sext i32 %conv to i64
   %expval = call i64 @llvm.expect.i64(i64 %conv1, i64 0)
   %tobool = icmp ne i64 %expval, 0
-; CHECK: !prof !1
+; CHECK: !prof !2
 ; CHECK-NOT: @llvm.expect
   br i1 %tobool, label %if.then, label %if.end
 
@@ -165,7 +165,7 @@
   %tmp = load i32, i32* %x.addr, align 4
   %conv = sext i32 %tmp to i64
   %expval = call i64 @llvm.expect.i64(i64 %conv, i64 1)
-; CHECK: !prof !2
+; CHECK: !prof !4
 ; CHECK-NOT: @llvm.expect
   switch i64 %expval, label %sw.epilog [
 i64 1, label %sw.bb
@@ -194,7 +194,7 @@
   %tmp = load i32, i32* %x.addr, align 4
   %conv = sext i32 %tmp to i64
   %expval = call i64 @llvm.expect.i64(i64 %conv, i64 1)
-; CHECK: !prof !3
+; CHECK: !prof !5
 ; CHECK-NOT: @llvm.expect
   switch i64 %expval, label %sw.epilog [
 i64 2, label %sw.bb
@@ -278,7 +278,7 @@
   %t7 = call i64 @llvm.expect.i64(i64 %t6, i64 0)
   %t8 = icmp ne i64 %t7, 0
   %t9 = select i1 %t8, i32 1, i32 2
-; CHECK: select{{.*}}, !prof !1
+; CHECK: select{{.*}}, !prof !2
   ret i32 %t9
 }
 
@@ -286,6 +286,6 @@
 declare i1 @llvm.expect.i1(i1, i1) nounwind readnone
 
 ; CHECK: !0 = !{!"branch_weights", i32 2000, i32 1}
-; CHECK: !1 = !{!"branch_weights", i32 1, i32 2000}
-; CHECK: !2 = !{!"branch_weights", i32 1, i32 2000, i32 1}
-; CHECK: !3 = !{!"branch_weights", i32 2000, i32 1, i32 1}
+; CHECK: !2 = !{!"branch_weights", i32 1, i32 2000}
+; CHECK: !4 = !{!"branch_weights", i32 1, i32 2000, i32 1}
+; CHECK: !5 = !{!"branch_weights", i32 2000, i32 1, i32 1}
Index: llvm/test/ThinLTO/X86/lazyload_metadata.ll
===
--- llvm/test/ThinLTO/X86/lazyload_metadata.ll
+++ llvm/test/ThinLTO/X86/lazyload_metadata.ll
@@ -10,13 +10,13 @@
 ; RUN: llvm-lto -thinlto-action=import %t2.bc -thinlto-index=%t3.bc \
 ; RUN:  -o /dev/null -stats \
 ; RUN:  2>&1 | FileCheck %s -check-prefix=LAZY
-; LAZY: 61 bitcode-reader  - Number of Metadata records loaded
+; LAZY: 63 bitcode-reader  - Number of Metadata records loaded
 ; LAZY: 2 bitcode-reader  - Number of MDStrings loaded
 
 ; RUN: llvm-lto -thinlto-action=import %t2.bc -thinlto-index=%t3.bc \
 ; RUN:  -o /dev/null -disable-ondemand-mds-loading -stats \
 ; RUN:  2>&1 | FileCheck %s -check-prefix=NOTLAZY
-; NOTLAZY: 70 bitcode-reader  - Number of Metadata records loaded
+; NOTLAZY: 72 bitcode-reader  - Number of Metadata records loaded
 ; NOTLAZY: 7 bitcode-reader  - Number of MDStrings loaded
 
 
Index: llvm/lib/Transforms/Utils/MisExpect.cpp
===
--- /dev/null
+++ llvm/lib/Transforms/Utils/MisExpect.cpp
@@ -0,0 +1,105 @@
+//===--- MisExpect.cpp - Check Use of __builtin_expect() with PGO data ===//
+//
+// Part of

[clang-tools-extra] r369139 - [clang-doc] Redesign of generated HTML files

2019-08-16 Thread Diego Astiazaran via cfe-commits
Author: diegoastiazaran
Date: Fri Aug 16 11:38:11 2019
New Revision: 369139

URL: http://llvm.org/viewvc/llvm-project?rev=369139&view=rev
Log:
[clang-doc] Redesign of generated HTML files

The new design includes a header (contains the project name), a main section, 
and a footer.
The main section is divided into three subsections. Left, middle, right. The 
left section contains the general index, the middle contains the info's data, 
and the right contains the index for the info's content.
The CSS has been updated.
A flag --project-name is added.
The Attributes attribute of the TagNode struct is now a vector of pairs because 
these attributes should be rendered in the insertion order.
The functions (cpp and js) that converts an Index tree structure into HTML were 
slightly modified; the first ul tag created is now a ol tag. The inner lists 
are still ul.

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

Modified:
clang-tools-extra/trunk/clang-doc/HTMLGenerator.cpp
clang-tools-extra/trunk/clang-doc/Representation.cpp
clang-tools-extra/trunk/clang-doc/Representation.h
clang-tools-extra/trunk/clang-doc/assets/clang-doc-default-stylesheet.css
clang-tools-extra/trunk/clang-doc/assets/index.js
clang-tools-extra/trunk/clang-doc/tool/ClangDocMain.cpp
clang-tools-extra/trunk/docs/clang-doc.rst
clang-tools-extra/trunk/unittests/clang-doc/HTMLGeneratorTest.cpp

Modified: clang-tools-extra/trunk/clang-doc/HTMLGenerator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-doc/HTMLGenerator.cpp?rev=369139&r1=369138&r2=369139&view=diff
==
--- clang-tools-extra/trunk/clang-doc/HTMLGenerator.cpp (original)
+++ clang-tools-extra/trunk/clang-doc/HTMLGenerator.cpp Fri Aug 16 11:38:11 2019
@@ -8,6 +8,7 @@
 
 #include "Generators.h"
 #include "Representation.h"
+#include "clang/Basic/Version.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/FileSystem.h"
@@ -29,12 +30,16 @@ public:
   enum TagType {
 TAG_A,
 TAG_DIV,
+TAG_FOOTER,
 TAG_H1,
 TAG_H2,
 TAG_H3,
+TAG_HEADER,
 TAG_LI,
 TAG_LINK,
+TAG_MAIN,
 TAG_META,
+TAG_OL,
 TAG_P,
 TAG_SCRIPT,
 TAG_SPAN,
@@ -84,7 +89,7 @@ struct TagNode : public HTMLNode {
 
   HTMLTag Tag; // Name of HTML Tag (p, div, h1)
   std::vector> Children; // List of child nodes
-  llvm::StringMap>
+  std::vector, llvm::SmallString<16>>>
   Attributes; // List of key-value attributes for tag
 
   void Render(llvm::raw_ostream &OS, int IndentationLevel) override;
@@ -112,10 +117,14 @@ bool HTMLTag::IsSelfClosing() const {
 return true;
   case HTMLTag::TAG_A:
   case HTMLTag::TAG_DIV:
+  case HTMLTag::TAG_FOOTER:
   case HTMLTag::TAG_H1:
   case HTMLTag::TAG_H2:
   case HTMLTag::TAG_H3:
+  case HTMLTag::TAG_HEADER:
   case HTMLTag::TAG_LI:
+  case HTMLTag::TAG_MAIN:
+  case HTMLTag::TAG_OL:
   case HTMLTag::TAG_P:
   case HTMLTag::TAG_SCRIPT:
   case HTMLTag::TAG_SPAN:
@@ -132,18 +141,26 @@ llvm::SmallString<16> HTMLTag::ToString(
 return llvm::SmallString<16>("a");
   case HTMLTag::TAG_DIV:
 return llvm::SmallString<16>("div");
+  case HTMLTag::TAG_FOOTER:
+return llvm::SmallString<16>("footer");
   case HTMLTag::TAG_H1:
 return llvm::SmallString<16>("h1");
   case HTMLTag::TAG_H2:
 return llvm::SmallString<16>("h2");
   case HTMLTag::TAG_H3:
 return llvm::SmallString<16>("h3");
+  case HTMLTag::TAG_HEADER:
+return llvm::SmallString<16>("header");
   case HTMLTag::TAG_LI:
 return llvm::SmallString<16>("li");
   case HTMLTag::TAG_LINK:
 return llvm::SmallString<16>("link");
+  case HTMLTag::TAG_MAIN:
+return llvm::SmallString<16>("main");
   case HTMLTag::TAG_META:
 return llvm::SmallString<16>("meta");
+  case HTMLTag::TAG_OL:
+return llvm::SmallString<16>("ol");
   case HTMLTag::TAG_P:
 return llvm::SmallString<16>("p");
   case HTMLTag::TAG_SCRIPT:
@@ -174,7 +191,7 @@ void TagNode::Render(llvm::raw_ostream &
   OS.indent(IndentationLevel * 2);
   OS << "<" << Tag.ToString();
   for (const auto &A : Attributes)
-OS << " " << A.getKey() << "=\"" << A.getValue() << "\"";
+OS << " " << A.first << "=\"" << A.second << "\"";
   if (Tag.IsSelfClosing()) {
 OS << "/>";
 return;
@@ -255,13 +272,13 @@ genStylesheetsHTML(StringRef InfoPath, c
   std::vector> Out;
   for (const auto &FilePath : CDCtx.UserStylesheets) {
 auto LinkNode = std::make_unique(HTMLTag::TAG_LINK);
-LinkNode->Attributes.try_emplace("rel", "stylesheet");
+LinkNode->Attributes.emplace_back("rel", "stylesheet");
 SmallString<128> StylesheetPath = computeRelativePath("", InfoPath);
 llvm::sys::path::append(StylesheetPath,
 llvm::sys::path::filename(FilePath));
 // Paths in HTML must be in posix-style
 llvm::sys::path::native(StylesheetPath, llvm::sys::path::Style::posix);
-   

[PATCH] D66353: [clang-doc] Redesign of generated HTML files

2019-08-16 Thread Diego Astiazarán via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL369139: [clang-doc] Redesign of generated HTML files 
(authored by DiegoAstiazaran, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D66353?vs=215642&id=215649#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D66353

Files:
  clang-tools-extra/trunk/clang-doc/HTMLGenerator.cpp
  clang-tools-extra/trunk/clang-doc/Representation.cpp
  clang-tools-extra/trunk/clang-doc/Representation.h
  clang-tools-extra/trunk/clang-doc/assets/clang-doc-default-stylesheet.css
  clang-tools-extra/trunk/clang-doc/assets/index.js
  clang-tools-extra/trunk/clang-doc/tool/ClangDocMain.cpp
  clang-tools-extra/trunk/docs/clang-doc.rst
  clang-tools-extra/trunk/unittests/clang-doc/HTMLGeneratorTest.cpp

Index: clang-tools-extra/trunk/unittests/clang-doc/HTMLGeneratorTest.cpp
===
--- clang-tools-extra/trunk/unittests/clang-doc/HTMLGeneratorTest.cpp
+++ clang-tools-extra/trunk/unittests/clang-doc/HTMLGeneratorTest.cpp
@@ -10,11 +10,15 @@
 #include "Generators.h"
 #include "Representation.h"
 #include "Serialize.h"
+#include "clang/Basic/Version.h"
 #include "gtest/gtest.h"
 
 namespace clang {
 namespace doc {
 
+static const std::string ClangDocVersion =
+clang::getClangToolFullVersion("clang-doc");
+
 std::unique_ptr getHTMLGenerator() {
   auto G = doc::findGeneratorByName("html");
   if (!G)
@@ -25,7 +29,8 @@
 ClangDocContext
 getClangDocContext(std::vector UserStylesheets = {},
StringRef RepositoryUrl = "") {
-  ClangDocContext CDCtx{{}, {}, {}, {}, RepositoryUrl, UserStylesheets, {}};
+  ClangDocContext CDCtx{
+  {}, "test-project", {}, {}, {}, RepositoryUrl, UserStylesheets, {}};
   CDCtx.UserStylesheets.insert(
   CDCtx.UserStylesheets.begin(),
   "../share/clang/clang-doc-default-stylesheet.css");
@@ -61,67 +66,76 @@
 
 
 
-
-
-  
-
-  Namespaces
-
-  
-  
-
-  Records
-
-  
-  
-
-  Functions
-
+test-project
+
+  
+  
+namespace Namespace
+Namespaces
 
   
-
-  OneFunction
-
+ChildNamespace
   
 
-  
-  
-
-  Enums
-
+Records
 
   
-
-  OneEnum
-
+ChildStruct
   
 
-  
-
-
-  namespace Namespace
-  Namespaces
-  
-
-  ChildNamespace
-
-  
-  Records
-  
-
-  ChildStruct
-
-  
-  Functions
-  
-OneFunction
-OneFunction()
+Functions
+
+  OneFunction
+  OneFunction()
+
+Enums
+
+  enum OneEnum
+
   
-  Enums
-  
-enum OneEnum
+  
+
+  
+
+  Namespaces
+
+  
+  
+
+  Records
+
+  
+  
+
+  Functions
+
+
+  
+
+  OneFunction
+
+  
+
+  
+  
+
+  Enums
+
+
+  
+
+  OneEnum
+
+  
+
+  
+
   
-
+
+
+  )raw" +
+ ClangDocVersion + R"raw(
+
 )raw";
 
   EXPECT_EQ(Expected, Actual.str());
@@ -162,80 +176,89 @@
 class r
 
 
-
-
-  
-
-  Members
-
-  
-  
-
-  Records
-
-  
-  
-
-  Functions
-
+test-project
+
+  
+  
+class r
+
+  Defined at line 
+  http://www.repository.com/dir/test.cpp#10";>10
+   of file 
+  http://www.repository.com/dir/test.cpp";>test.cpp
+
+
+  Inherits from 
+  F
+  , G
+
+Members
 
   
-
-  OneFunction
-
+private 
+int
+ X
   
 
-  
-  
-
-  Enums
-
+Records
 
   
-
-  OneEnum
-
+ChildStruct
   
 
-  
-
-
-  class r
-  
-Defined at line 
-http://www.repository.com/dir/test.cpp#10";>10
- of file 
-http://www.repository.com/dir/test.cpp";>test.cpp
-  
-  
-Inherits from 
-F
-, G
-  
-  Members
-  
-
-  private 
-  int
-   X
-
-  
-  Records
-  
-
-  ChildStruct
-
-  
-  Functions
-  
-OneFunction
-public OneFunction()
+Functions
+
+  OneFunction
+  public OneFunction()
+
+Enums
+
+  enum OneEnum
+
   
-  Enums
-  
-enum OneEnum
+  
+
+  
+
+  Members
+
+  
+  
+
+  Records
+
+  
+  
+
+  Functions
+
+
+  
+
+  OneFunction
+
+  
+
+  
+  
+
+  Enums
+
+
+  
+
+  OneEnum
+
+  
+

r369145 - Stop abusing SuppressAllDiagnostics when speculatively determining

2019-08-16 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Fri Aug 16 12:53:22 2019
New Revision: 369145

URL: http://llvm.org/viewvc/llvm-project?rev=369145&view=rev
Log:
Stop abusing SuppressAllDiagnostics when speculatively determining
whether an expression would be valid during error recovery.

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

Modified: cfe/trunk/lib/Parse/ParseExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseExpr.cpp?rev=369145&r1=369144&r2=369145&view=diff
==
--- cfe/trunk/lib/Parse/ParseExpr.cpp (original)
+++ cfe/trunk/lib/Parse/ParseExpr.cpp Fri Aug 16 12:53:22 2019
@@ -1772,12 +1772,12 @@ Parser::ParsePostfixExpressionSuffix(Exp
 OpKind == tok::arrow ? tok::period : tok::arrow;
 ExprResult CorrectedLHS(/*Invalid=*/true);
 if (getLangOpts().CPlusPlus && OrigLHS) {
-  const bool DiagsAreSuppressed = Diags.getSuppressAllDiagnostics();
-  Diags.setSuppressAllDiagnostics(true);
+  // FIXME: Creating a TentativeAnalysisScope from outside Sema is a
+  // hack.
+  Sema::TentativeAnalysisScope Trap(Actions);
   CorrectedLHS = Actions.ActOnStartCXXMemberReference(
   getCurScope(), OrigLHS, OpLoc, CorrectedOpKind, ObjectType,
   MayBePseudoDestructor);
-  Diags.setSuppressAllDiagnostics(DiagsAreSuppressed);
 }
 
 Expr *Base = LHS.get();

Modified: cfe/trunk/lib/Sema/Sema.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/Sema.cpp?rev=369145&r1=369144&r2=369145&view=diff
==
--- cfe/trunk/lib/Sema/Sema.cpp (original)
+++ cfe/trunk/lib/Sema/Sema.cpp Fri Aug 16 12:53:22 2019
@@ -1929,11 +1929,9 @@ bool Sema::tryExprAsCall(Expr &E, QualTy
   // member templates with defaults/deduction of template arguments, overloads
   // with default arguments, etc.
   if (IsMemExpr && !E.isTypeDependent()) {
-bool Suppress = getDiagnostics().getSuppressAllDiagnostics();
-getDiagnostics().setSuppressAllDiagnostics(true);
+Sema::TentativeAnalysisScope Trap(*this);
 ExprResult R = BuildCallToMemberFunction(nullptr, &E, SourceLocation(),
  None, SourceLocation());
-getDiagnostics().setSuppressAllDiagnostics(Suppress);
 if (R.isUsable()) {
   ZeroArgCallReturnTy = R.get()->getType();
   return true;

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=369145&r1=369144&r2=369145&view=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Fri Aug 16 12:53:22 2019
@@ -5798,8 +5798,7 @@ Expr *OpenMPIterationSpaceChecker::build
 Scope *S, Expr *Cond,
 llvm::MapVector &Captures) const {
   // Try to build LB  UB, where  is <, >, <=, or >=.
-  bool Suppress = SemaRef.getDiagnostics().getSuppressAllDiagnostics();
-  SemaRef.getDiagnostics().setSuppressAllDiagnostics(/*Val=*/true);
+  Sema::TentativeAnalysisScope Trap(SemaRef);
 
   ExprResult NewLB =
   InitDependOnLC ? LB : tryBuildCapture(SemaRef, LB, Captures);
@@ -5821,7 +5820,7 @@ Expr *OpenMPIterationSpaceChecker::build
   CondExpr.get(), SemaRef.Context.BoolTy, /*Action=*/Sema::AA_Casting,
   /*AllowExplicit=*/true);
   }
-  SemaRef.getDiagnostics().setSuppressAllDiagnostics(Suppress);
+
   // Otherwise use original loop condition and evaluate it in runtime.
   return CondExpr.isUsable() ? CondExpr.get() : Cond;
 }
@@ -6243,8 +6242,8 @@ static ExprResult buildCounterUpdate(
   if (VarRef.get()->getType()->isOverloadableType() ||
   NewStart.get()->getType()->isOverloadableType() ||
   Update.get()->getType()->isOverloadableType()) {
-bool Suppress = SemaRef.getDiagnostics().getSuppressAllDiagnostics();
-SemaRef.getDiagnostics().setSuppressAllDiagnostics(/*Val=*/true);
+Sema::TentativeAnalysisScope Trap(SemaRef);
+
 Update =
 SemaRef.BuildBinOp(S, Loc, BO_Assign, VarRef.get(), NewStart.get());
 if (Update.isUsable()) {
@@ -6256,7 +6255,6 @@ static ExprResult buildCounterUpdate(
 UpdateVal.get());
   }
 }
-SemaRef.getDiagnostics().setSuppressAllDiagnostics(Suppress);
   }
 
   // Second attempt: try to build 'VarRef = Start (+|-) Iter * Step'.
@@ -13605,11 +13603,13 @@ Sema::ActOnOpenMPDependClause(OpenMPDepe
 << RefExpr->getSourceRange();
 continue;
   }
-  bool Suppress = getDiagnostics().getSuppressAllDiagnostics();
-  getDiagnostics().setSuppressAllDiagnostics(/*Val=*/true);
-  ExprResult Res =
-  CreateBuiltinUnaryOp(ELoc, UO_AddrOf, 
RefExpr->IgnoreParenImpCasts());
-  getDiagnostics().setSuppre

[PATCH] D66361: Improve behavior in the case of stack exhaustion.

2019-08-16 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith created this revision.
rsmith added reviewers: rnk, aaron.ballman.
Herald added subscribers: cfe-commits, mgorny.
Herald added a project: clang.

Clang performs various recursive operations (such as template instantiation),
and may use non-trivial amounts of stack space in each recursive step (for
instance, due to recursive AST walks). While we try to keep the stack space
used by such steps to a minimum and we have explicit limits on the number of
such steps we perform, it's impractical to guarantee that we won't blow out the
stack on deeply recursive template instantiations on complex ASTs, even with
only a moderately high instantiation depth limit.

The user experience in these cases is generally terrible: we crash with
no hint of what went wrong. Under this patch, we attempt to do better:

- Detect when the stack is nearly exhausted, and produce a warning with a nice 
template instantiation backtrace, telling the user that we might run slowly or 
crash.
- For cases where we're forced to trigger recursive template instantiation in 
arbitrarily-deeply-nested contexts, check whether we're nearly out of stack 
space and allocate a new stack (by spawning a new thread) after producing the 
warning.


Repository:
  rC Clang

https://reviews.llvm.org/D66361

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/Stack.h
  include/clang/Sema/Sema.h
  lib/Basic/CMakeLists.txt
  lib/Basic/Stack.cpp
  lib/Frontend/CompilerInstance.cpp
  lib/Sema/Sema.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaInit.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaTemplate.cpp
  lib/Sema/SemaTemplateDeduction.cpp
  lib/Sema/SemaTemplateInstantiate.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Sema/SemaType.cpp
  test/SemaTemplate/stack-exhaustion.cpp
  tools/driver/driver.cpp

Index: tools/driver/driver.cpp
===
--- tools/driver/driver.cpp
+++ tools/driver/driver.cpp
@@ -13,6 +13,7 @@
 
 #include "clang/Driver/Driver.h"
 #include "clang/Basic/DiagnosticOptions.h"
+#include "clang/Basic/Stack.h"
 #include "clang/Driver/Compilation.h"
 #include "clang/Driver/DriverDiagnostic.h"
 #include "clang/Driver/Options.h"
@@ -319,6 +320,7 @@
 }
 
 int main(int argc_, const char **argv_) {
+  noteBottomOfStack();
   llvm::InitLLVM X(argc_, argv_);
   SmallVector argv(argv_, argv_ + argc_);
 
Index: test/SemaTemplate/stack-exhaustion.cpp
===
--- /dev/null
+++ test/SemaTemplate/stack-exhaustion.cpp
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -verify %s
+// expected-warning@* 0-1{{stack nearly exhausted}}
+// expected-note@* 0+{{}}
+
+template struct X : X {};
+template<> struct X<0> {};
+X<1000> x;
+
+template struct tuple {};
+template auto f(tuple t) -> decltype(f(tuple(t))) {} // expected-error {{exceeded maximum depth}}
+void g() { f(tuple()); }
+
+int f(X<0>);
+template auto f(X) -> f(X());
+
+int k = f(X<1000>());
Index: lib/Sema/SemaType.cpp
===
--- lib/Sema/SemaType.cpp
+++ lib/Sema/SemaType.cpp
@@ -7715,7 +7715,9 @@
 auto *Def = Var->getDefinition();
 if (!Def) {
   SourceLocation PointOfInstantiation = E->getExprLoc();
-  InstantiateVariableDefinition(PointOfInstantiation, Var);
+  runWithSufficientStackSpace(PointOfInstantiation, [&] {
+InstantiateVariableDefinition(PointOfInstantiation, Var);
+  });
   Def = Var->getDefinition();
 
   // If we don't already have a point of instantiation, and we managed
@@ -8053,9 +8055,11 @@
 } else if (auto *ClassTemplateSpec =
 dyn_cast(RD)) {
   if (ClassTemplateSpec->getSpecializationKind() == TSK_Undeclared) {
-Diagnosed = InstantiateClassTemplateSpecialization(
-Loc, ClassTemplateSpec, TSK_ImplicitInstantiation,
-/*Complain=*/Diagnoser);
+runWithSufficientStackSpace(Loc, [&] {
+  Diagnosed = InstantiateClassTemplateSpecialization(
+  Loc, ClassTemplateSpec, TSK_ImplicitInstantiation,
+  /*Complain=*/Diagnoser);
+});
 Instantiated = true;
   }
 } else {
@@ -8066,10 +8070,12 @@
 // This record was instantiated from a class within a template.
 if (MSI->getTemplateSpecializationKind() !=
 TSK_ExplicitSpecialization) {
-  Diagnosed = InstantiateClass(Loc, RD, Pattern,
-   getTemplateInstantiationArgs(RD),
-   TSK_ImplicitInstantiation,
-   /*Complain=*/Diagnoser);
+  runWithSufficientStackSpace(Loc, [&] {
+Diagnosed = InstantiateClass(Loc, RD, Pattern,
+ getTemplateInstantiationArgs(RD),
+ TSK_ImplicitInstantiation,
+ /*Compla

[PATCH] D66324: clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM

2019-08-16 Thread Paul Kirth via Phabricator via cfe-commits
paulkirth added a comment.



> So it is possible to handle this completely in the backed, but the diagnostic 
> output is not fantastic when using clang based instrumentation. In 
> particular, we would need to emit the diagnostic in LowerExpectIntrisic.cpp 
> by checking if the branch weight metadata already exists, and processing it 
> there before it is overwritten. For some reason emitting the diagnostic at 
> that point will not also emit the helpful source listing if there is a macro, 
> even though a FullSourceLoc is available. This isn't an issue for either the 
> handling in SampleProfile.cpp or in PGOInstrumentation.cpp.

Actually, I made a mistake evaluating the diagnostic output. I redid my test 
for handling everything the Clang based instrumentation in 
LowerExpectIntrinsic.cpp and the output now looks as expected, so I must have 
had a logic error somewhere.

I think this can be handled 100% in the backend.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66324



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


[PATCH] D66360: Expose constructing a virtual method dispatch through the include/clang/CodeGen APIs.

2019-08-16 Thread Parker Schuh via Phabricator via cfe-commits
pschuh created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

In swift, we want to be able to call c++ virtual methods by looking up in the 
virtual table. There appears to exist no way currently, via the standard APIs, 
to take a CXXMethodDecl and a llvm::Value representing a this-ptr and construct 
the llvm instructions necessary to extract the method from the virtual table as 
well as adjust the this-ptr.

For reference, this is used in https://github.com/apple/swift/pull/26658.


Repository:
  rC Clang

https://reviews.llvm.org/D66360

Files:
  include/clang/CodeGen/CodeGenABITypes.h
  include/clang/CodeGen/SwiftCallingConv.h
  lib/CodeGen/CodeGenABITypes.cpp
  lib/CodeGen/SwiftCallingConv.cpp

Index: lib/CodeGen/SwiftCallingConv.cpp
===
--- lib/CodeGen/SwiftCallingConv.cpp
+++ lib/CodeGen/SwiftCallingConv.cpp
@@ -11,9 +11,11 @@
 //===--===//
 
 #include "clang/CodeGen/SwiftCallingConv.h"
-#include "clang/Basic/TargetInfo.h"
+#include "CGCXXABI.h"
+#include "CodeGenFunction.h"
 #include "CodeGenModule.h"
 #include "TargetInfo.h"
+#include "clang/Basic/TargetInfo.h"
 
 using namespace clang;
 using namespace CodeGen;
@@ -862,3 +864,25 @@
 bool swiftcall::isSwiftErrorLoweredInRegister(CodeGenModule &CGM) {
   return getSwiftABIInfo(CGM).isSwiftErrorInRegister();
 }
+
+llvm::Value *swiftcall::lowerCXXVirtualMethodDeclReference(
+CodeGenModule &CGM, const CXXMethodDecl *MD, llvm::Value *&thisPtr,
+CharUnits alignment, llvm::FunctionType *type,
+llvm::IRBuilderBase *builder) {
+  assert(MD->isVirtual());
+
+  CodeGenFunction CGF(CGM, true);
+  CGF.Builder.SetInsertPoint(builder->GetInsertBlock(),
+ builder->GetInsertPoint());
+  Address thisAddr(thisPtr, alignment);
+  auto callee = CGCallee::forVirtual(nullptr, MD, thisAddr, type);
+  const CGCallee &concreteCallee = callee.prepareConcreteCallee(CGF);
+  Address newThisAddr =
+  CGM.getCXXABI().adjustThisArgumentForVirtualFunctionCall(CGF, MD,
+   thisAddr, true);
+  thisPtr = newThisAddr.getPointer();
+  auto *result = concreteCallee.getFunctionPointer();
+  builder->SetInsertPoint(CGF.Builder.GetInsertBlock(),
+  CGF.Builder.GetInsertPoint());
+  return result;
+}
Index: lib/CodeGen/CodeGenABITypes.cpp
===
--- lib/CodeGen/CodeGenABITypes.cpp
+++ lib/CodeGen/CodeGenABITypes.cpp
@@ -52,6 +52,17 @@
   return CGM.getTypes().arrangeCXXMethodType(RD, FTP, MD);
 }
 
+const CGFunctionInfo &
+CodeGen::arrangeCXXMethodDeclaration(CodeGenModule &CGM,
+ const CXXMethodDecl *MD) {
+  return CGM.getTypes().arrangeCXXMethodDeclaration(MD);
+}
+
+llvm::FunctionType *CodeGen::getFunctionType(CodeGenModule &CGM,
+ const CGFunctionInfo &FI) {
+  return CGM.getTypes().GetFunctionType(FI);
+}
+
 const CGFunctionInfo &
 CodeGen::arrangeFreeFunctionCall(CodeGenModule &CGM,
  CanQualType returnType,
Index: include/clang/CodeGen/SwiftCallingConv.h
===
--- include/clang/CodeGen/SwiftCallingConv.h
+++ include/clang/CodeGen/SwiftCallingConv.h
@@ -22,14 +22,18 @@
 namespace llvm {
   class IntegerType;
   class Type;
+  class Value;
   class StructType;
   class VectorType;
+  class FunctionType;
+  class IRBuilderBase;
 }
 
 namespace clang {
 class Decl;
 class FieldDecl;
 class ASTRecordLayout;
+class CXXMethodDecl;
 
 namespace CodeGen {
 class ABIArgInfo;
@@ -177,6 +181,14 @@
 /// Is swifterror lowered to a register by the target ABI?
 bool isSwiftErrorLoweredInRegister(CodeGenModule &CGM);
 
+/// Lookup a virtual method `MD` from the vtable and adjusts the this ptr.
+llvm::Value *lowerCXXVirtualMethodDeclReference(CodeGenModule &CGM,
+const CXXMethodDecl *MD,
+llvm::Value *&thisPtr,
+CharUnits alignment,
+llvm::FunctionType *type,
+llvm::IRBuilderBase *builder);
+
 } // end namespace swiftcall
 } // end namespace CodeGen
 } // end namespace clang
Index: include/clang/CodeGen/CodeGenABITypes.h
===
--- include/clang/CodeGen/CodeGenABITypes.h
+++ include/clang/CodeGen/CodeGenABITypes.h
@@ -65,6 +65,9 @@
const FunctionProtoType *FTP,
const CXXMethodDecl *MD);
 
+const CGFunctionInfo &arrangeCXXMethodDeclaration(CodeGenModule &CGM,
+   

r369146 - [OPENMP5.0]Diagnose global variables in lambda not marked as declare

2019-08-16 Thread Alexey Bataev via cfe-commits
Author: abataev
Date: Fri Aug 16 13:15:02 2019
New Revision: 369146

URL: http://llvm.org/viewvc/llvm-project?rev=369146&view=rev
Log:
[OPENMP5.0]Diagnose global variables in lambda not marked as declare
target.

According to OpenMP 5.0, if a lambda declaration and definition appears between 
a declare target directive and the matching end declare target directive, all 
variables that are captured by the lambda expression must also appear in a to 
clause.

Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/test/OpenMP/declare_target_messages.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=369146&r1=369145&r2=369146&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Aug 16 13:15:02 
2019
@@ -9318,6 +9318,8 @@ def err_omp_wrong_dependency_iterator_ty
   "expected an integer or a pointer type of the outer loop counter '%0' for 
non-rectangular nests">;
 def err_omp_unsupported_type : Error <
   "host requires %0 bit size %1 type support, but device '%2' does not support 
it">;
+def omp_lambda_capture_in_declare_target_not_to : Error<
+  "variable captured in declare target region must appear in a to clause">;
 } // end of OpenMP category
 
 let CategoryName = "Related Result Type Issue" in {

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=369146&r1=369145&r2=369146&view=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Fri Aug 16 13:15:02 2019
@@ -1796,7 +1796,8 @@ VarDecl *Sema::isOpenMPCapturedDecl(Valu
 if (isInOpenMPDeclareTargetContext()) {
   // Try to mark variable as declare target if it is used in capturing
   // regions.
-  if (!OMPDeclareTargetDeclAttr::isDeclareTargetDeclaration(VD))
+  if (LangOpts.OpenMP <= 45 &&
+  !OMPDeclareTargetDeclAttr::isDeclareTargetDeclaration(VD))
 checkDeclIsAllowedInOpenMPTarget(nullptr, VD);
   return nullptr;
 } else if (isInOpenMPTargetExecutionDirective()) {
@@ -15349,7 +15350,28 @@ static void checkDeclInTargetContext(Sou
   if (!D || !isa(D))
 return;
   auto *VD = cast(D);
-  if (OMPDeclareTargetDeclAttr::isDeclareTargetDeclaration(VD))
+  Optional MapTy =
+  OMPDeclareTargetDeclAttr::isDeclareTargetDeclaration(VD);
+  if (SemaRef.LangOpts.OpenMP >= 50 &&
+  (SemaRef.getCurLambda(/*IgnoreNonLambdaCapturingScope=*/true) ||
+   SemaRef.getCurBlock() || SemaRef.getCurCapturedRegion()) &&
+  VD->hasGlobalStorage()) {
+llvm::Optional MapTy =
+OMPDeclareTargetDeclAttr::isDeclareTargetDeclaration(VD);
+if (!MapTy || *MapTy != OMPDeclareTargetDeclAttr::MT_To) {
+  // OpenMP 5.0, 2.12.7 declare target Directive, Restrictions
+  // If a lambda declaration and definition appears between a
+  // declare target directive and the matching end declare target
+  // directive, all variables that are captured by the lambda
+  // expression must also appear in a to clause.
+  SemaRef.Diag(VD->getLocation(),
+   diag::omp_lambda_capture_in_declare_target_not_to);
+  SemaRef.Diag(SL, diag::note_var_explicitly_captured_here)
+  << VD << 0 << SR;
+  return;
+}
+  }
+  if (MapTy.hasValue())
 return;
   SemaRef.Diag(VD->getLocation(), diag::warn_omp_not_in_target_context);
   SemaRef.Diag(SL, diag::note_used_here) << SR;

Modified: cfe/trunk/test/OpenMP/declare_target_messages.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/declare_target_messages.cpp?rev=369146&r1=369145&r2=369146&view=diff
==
--- cfe/trunk/test/OpenMP/declare_target_messages.cpp (original)
+++ cfe/trunk/test/OpenMP/declare_target_messages.cpp Fri Aug 16 13:15:02 2019
@@ -1,10 +1,11 @@
 // RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify -fopenmp 
-fnoopenmp-use-tls -ferror-limit 100 -o - %s
+// RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify=expected,omp5 
-fopenmp -fopenmp-version=50 -fnoopenmp-use-tls -ferror-limit 100 -o - %s
 
 // RUN: %clang_cc1 -triple x86_64-apple-macos10.7.0 -verify -fopenmp-simd 
-fnoopenmp-use-tls -ferror-limit 100 -o - %s
 
 #pragma omp end declare target // expected-error {{unexpected OpenMP directive 
'#pragma omp end declare target'}}
 
-int a, b;
+int a, b, z; // omp5-error {{variable captured in declare target region must 
appear in a to clause}}
 __thread int t; // expected-note {{defined as threadprivate or thread local}}
 
 #pragma omp declare target . // expected-error {{expected '(' af

r369147 - [ARM] push LR before __gnu_mcount_nc

2019-08-16 Thread Jian Cai via cfe-commits
Author: jcai19
Date: Fri Aug 16 13:21:08 2019
New Revision: 369147

URL: http://llvm.org/viewvc/llvm-project?rev=369147&view=rev
Log:
[ARM] push LR before __gnu_mcount_nc

Push LR register before calling __gnu_mcount_nc as it expects the value of LR 
register to be the top value of
the stack on ARM32.

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

Modified:
cfe/trunk/lib/Basic/Targets/ARM.cpp

Modified: cfe/trunk/lib/Basic/Targets/ARM.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/ARM.cpp?rev=369147&r1=369146&r2=369147&view=diff
==
--- cfe/trunk/lib/Basic/Targets/ARM.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/ARM.cpp Fri Aug 16 13:21:08 2019
@@ -322,7 +322,7 @@ ARMTargetInfo::ARMTargetInfo(const llvm:
   if (Triple.getOS() == llvm::Triple::Linux ||
   Triple.getOS() == llvm::Triple::UnknownOS)
 this->MCountName = Opts.EABIVersion == llvm::EABI::GNU
-   ? "\01__gnu_mcount_nc"
+   ? "llvm.arm.gnu.eabi.mcount"
: "\01mcount";
 
   SoftFloatABI = llvm::is_contained(Opts.FeaturesAsWritten, "+soft-float-abi");


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


[PATCH] D65019: [ARM] push LR before __gnu_mcount_nc

2019-08-16 Thread Jian Cai via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL369147: [ARM] push LR before __gnu_mcount_nc (authored by 
jcai19, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D65019?vs=214945&id=215664#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65019

Files:
  cfe/trunk/lib/Basic/Targets/ARM.cpp
  llvm/trunk/include/llvm/IR/IntrinsicsARM.td
  llvm/trunk/lib/Target/ARM/ARMExpandPseudoInsts.cpp
  llvm/trunk/lib/Target/ARM/ARMISelLowering.cpp
  llvm/trunk/lib/Target/ARM/ARMISelLowering.h
  llvm/trunk/lib/Target/ARM/ARMInstrInfo.td
  llvm/trunk/lib/Target/ARM/ARMInstrThumb.td
  llvm/trunk/lib/Transforms/Utils/EntryExitInstrumenter.cpp
  llvm/trunk/test/CodeGen/ARM/gnu_mcount_nc.ll

Index: llvm/trunk/include/llvm/IR/IntrinsicsARM.td
===
--- llvm/trunk/include/llvm/IR/IntrinsicsARM.td
+++ llvm/trunk/include/llvm/IR/IntrinsicsARM.td
@@ -778,4 +778,9 @@
 def int_arm_neon_sdot : Neon_Dot_Intrinsic;
 
 
+// GNU eabi mcount
+def int_arm_gnu_eabi_mcount : Intrinsic<[],
+[],
+[IntrReadMem, IntrWriteMem]>;
+
 } // end TargetPrefix
Index: llvm/trunk/test/CodeGen/ARM/gnu_mcount_nc.ll
===
--- llvm/trunk/test/CodeGen/ARM/gnu_mcount_nc.ll
+++ llvm/trunk/test/CodeGen/ARM/gnu_mcount_nc.ll
@@ -0,0 +1,41 @@
+; RUN: llc -mtriple=armv7a-linux-gnueabihf -verify-machineinstrs %s -o - | FileCheck %s --check-prefix=CHECK-ARM
+; RUN: llc -mtriple=armv7a-linux-gnueabihf -verify-machineinstrs -fast-isel %s -o - | FileCheck %s --check-prefix=CHECK-ARM-FAST-ISEL
+; RUN: llc -mtriple=armv7a-linux-gnueabihf -verify-machineinstrs -global-isel -global-isel-abort=2 %s -o - | FileCheck %s --check-prefix=CHECK-ARM-GLOBAL-ISEL
+; RUN: llc -mtriple=thumbv7a-linux-gnueabihf -verify-machineinstrs %s -o - | FileCheck %s --check-prefix=CHECK-THUMB
+; RUN: llc -mtriple=thumbv7a-linux-gnueabihf -verify-machineinstrs -fast-isel %s -o - | FileCheck %s --check-prefix=CHECK-THUMB-FAST-ISEL
+; RUN: llc -mtriple=thumbv7a-linux-gnueabihf -verify-machineinstrs -global-isel -global-isel-abort=2 %s -o - | FileCheck %s --check-prefix=CHECK-THUMB-GLOBAL-ISEL
+
+define dso_local void @callee() #0 {
+; CHECK-ARM:stmdb   sp!, {lr}
+; CHECK-ARM-NEXT:   bl  __gnu_mcount_nc
+; CHECK-ARM-FAST-ISEL:  stmdb   sp!, {lr}
+; CHECK-ARM-FAST-ISEL-NEXT: bl  __gnu_mcount_nc
+; CHECK-ARM-GLOBAL-ISEL:stmdb   sp!, {lr}
+; CHECK-ARM-GLOBAL-ISEL-NEXT:   bl  __gnu_mcount_nc
+; CHECK-THUMB:  push{lr}
+; CHECK-THUMB-NEXT: bl  __gnu_mcount_nc
+; CHECK-THUMB-FAST-ISEL:push{lr}
+; CHECK-THUMB-FAST-ISEL-NEXT:   bl  __gnu_mcount_nc
+; CHECK-THUMB-GLOBAL-ISEL:  push{lr}
+; CHECK-THUMB-GLOBAL-ISEL-NEXT: bl  __gnu_mcount_nc
+  ret void
+}
+
+define dso_local void @caller() #0 {
+; CHECK-ARM:stmdb   sp!, {lr}
+; CHECK-ARM-NEXT:   bl  __gnu_mcount_nc
+; CHECK-ARM-FAST-ISEL:  stmdb   sp!, {lr}
+; CHECK-ARM-FAST-ISEL-NEXT: bl  __gnu_mcount_nc
+; CHECK-ARM-GLOBAL-ISEL:stmdb   sp!, {lr}
+; CHECK-ARM-GLOBAL-ISEL-NEXT:   bl  __gnu_mcount_nc
+; CHECK-THUMB:  push{lr}
+; CHECK-THUMB-NEXT: bl  __gnu_mcount_nc
+; CHECK-THUMB-FAST-ISEL:push{lr}
+; CHECK-THUMB-FAST-ISEL-NEXT:   bl  __gnu_mcount_nc
+; CHECK-THUMB-GLOBAL-ISEL:  push{lr}
+; CHECK-THUMB-GLOBAL-ISEL-NEXT: bl  __gnu_mcount_nc
+  call void @callee()
+  ret void
+}
+
+attributes #0 = { nofree nounwind "instrument-function-entry-inlined"="llvm.arm.gnu.eabi.mcount" }
Index: llvm/trunk/lib/Transforms/Utils/EntryExitInstrumenter.cpp
===
--- llvm/trunk/lib/Transforms/Utils/EntryExitInstrumenter.cpp
+++ llvm/trunk/lib/Transforms/Utils/EntryExitInstrumenter.cpp
@@ -24,7 +24,7 @@
 
   if (Func == "mcount" ||
   Func == ".mcount" ||
-  Func == "\01__gnu_mcount_nc" ||
+  Func == "llvm.arm.gnu.eabi.mcount" ||
   Func == "\01_mcount" ||
   Func == "\01mcount" ||
   Func == "__mcount" ||
Index: llvm/trunk/lib/Target/ARM/ARMExpandPseudoInsts.cpp
===
--- llvm/trunk/lib/Target/ARM/ARMExpandPseudoInsts.cpp
+++ llvm/trunk/lib/Target/ARM/ARMExpandPseudoInsts.cpp
@@ -1916,6 +1916,37 @@
 
 case ARM::CMP_SWAP_64:
   return ExpandCMP_SWAP_64(MBB, MBBI, NextMBBI);
+
+case ARM::tBL_PUSHLR:
+case ARM::BL_PUSHLR: {
+  const bool Thumb = Opcode == ARM::tBL_PUSHLR;
+  Register Reg = MI.getOperand(0).getReg();
+  assert(Reg == ARM::LR && "expect LR register!");
+  MachineInstrBuilder MIB;
+  if (Thumb) {
+// push 

[PATCH] D66364: Diagnose use of _Thread_local as an extension when appropriate

2019-08-16 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman created this revision.
aaron.ballman added a reviewer: rsmith.
Herald added a project: clang.

We currently accept use of _Thread_local in all C and C++ modes, but we do not 
issue a warning about it being an extension when used outside of C11 mode. This 
patch adds the warning and adjusts tests for the fallout.


Repository:
  rC Clang

https://reviews.llvm.org/D66364

Files:
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/test/PCH/thread-local.cpp
  clang/test/Sema/thread-specifier.c
  clang/test/SemaOpenCLCXX/restricted.cl

Index: clang/test/SemaOpenCLCXX/restricted.cl
===
--- clang/test/SemaOpenCLCXX/restricted.cl
+++ clang/test/SemaOpenCLCXX/restricted.cl
@@ -31,6 +31,8 @@
 // Test storage class qualifiers.
 __constant _Thread_local int a = 1;
 // expected-error@-1 {{C++ for OpenCL version 1.0 does not support the '_Thread_local' storage class specifier}}
+// expected-warning@-2 {{_Thread_local is a C11-specific feature}}
+
 __constant __thread int b = 2;
 // expected-error@-1 {{C++ for OpenCL version 1.0 does not support the '__thread' storage class specifier}}
 kernel void test_storage_classes() {
Index: clang/test/Sema/thread-specifier.c
===
--- clang/test/Sema/thread-specifier.c
+++ clang/test/Sema/thread-specifier.c
@@ -1,9 +1,10 @@
 // RUN: %clang_cc1 -triple i686-pc-linux-gnu -fsyntax-only -Wno-private-extern -verify -pedantic %s -DGNU
 // RUN: %clang_cc1 -triple i686-pc-linux-gnu -fsyntax-only -Wno-private-extern -verify -pedantic -x c++ %s -DGNU -std=c++98
-// RUN: %clang_cc1 -triple i686-pc-linux-gnu -fsyntax-only -Wno-private-extern -verify -pedantic %s -DC11 -D__thread=_Thread_local
-// RUN: %clang_cc1 -triple i686-pc-linux-gnu -fsyntax-only -Wno-private-extern -verify -pedantic -x c++ %s -DC11 -D__thread=_Thread_local -std=c++98
+// RUN: %clang_cc1 -triple i686-pc-linux-gnu -fsyntax-only -Wno-private-extern -verify -pedantic %s -std=c11 -DC11 -D__thread=_Thread_local
+// RUN: %clang_cc1 -triple i686-pc-linux-gnu -fsyntax-only -Wno-private-extern -verify -pedantic -x c++ %s -DC11 -D__thread=_Thread_local -std=c++98 -DWARN_ON_THREAD_LOCAL
 // RUN: %clang_cc1 -triple i686-pc-linux-gnu -fsyntax-only -Wno-private-extern -verify -pedantic -x c++ %s -DCXX11 -D__thread=thread_local -std=c++11 -Wno-deprecated
-// RUN: %clang_cc1 -triple i686-pc-linux-gnu -fsyntax-only -Wno-private-extern -verify -pedantic -x c++ %s -DC11 -D__thread=_Thread_local -std=c++11 -Wno-deprecated
+// RUN: %clang_cc1 -triple i686-pc-linux-gnu -fsyntax-only -Wno-private-extern -verify -pedantic -x c++ %s -DC11 -D__thread=_Thread_local -std=c++11 -Wno-deprecated -DWARN_ON_THREAD_LOCAL
+// RUN: %clang_cc1 -triple i686-pc-linux-gnu -fsyntax-only -Wno-private-extern -verify -pedantic %s -std=c99 -D__thread=_Thread_local -DWARN_ON_THREAD_LOCAL -DC99
 
 #ifdef __cplusplus
 // In C++, we define __private_extern__ to extern.
@@ -30,7 +31,7 @@
 __thread int t6();
 #if defined(GNU)
 // expected-error@-2 {{'__thread' is only allowed on variable declarations}}
-#elif defined(C11)
+#elif defined(C11) || defined(C99)
 // expected-error@-4 {{'_Thread_local' is only allowed on variable declarations}}
 #else
 // expected-error@-6 {{'thread_local' is only allowed on variable declarations}}
@@ -40,7 +41,7 @@
   __thread int t8;
 #if defined(GNU)
   // expected-error@-2 {{'__thread' variables must have global storage}}
-#elif defined(C11)
+#elif defined(C11) || defined(C99)
   // expected-error@-4 {{'_Thread_local' variables must have global storage}}
 #endif
   extern __thread int t9;
@@ -121,3 +122,41 @@
 #endif
 
 __thread int aggregate[10] = {0};
+
+#ifdef WARN_ON_THREAD_LOCAL
+// expected-warning@14 {{_Thread_local is a C11-specific feature}}
+// expected-warning@15 {{_Thread_local is a C11-specific feature}}
+// expected-warning@16 {{_Thread_local is a C11-specific feature}}
+// expected-warning@22 {{_Thread_local is a C11-specific feature}}
+// expected-warning@23 {{_Thread_local is a C11-specific feature}}
+// expected-warning@31 {{_Thread_local is a C11-specific feature}}
+// expected-warning@40 {{_Thread_local is a C11-specific feature}}
+// expected-warning@41 {{_Thread_local is a C11-specific feature}}
+// expected-warning@47 {{_Thread_local is a C11-specific feature}}
+// expected-warning@48 {{_Thread_local is a C11-specific feature}}
+// expected-warning@49 {{_Thread_local is a C11-specific feature}}
+#if __cplusplus < 201103L
+// expected-warning@51 {{_Thread_local is a C11-specific feature}}
+// expected-warning@52 {{_Thread_local is a C11-specific feature}}
+#elif !defined(CXX11)
+// expected-warning@54 {{_Thread_local is a C11-specific feature}}
+// expected-warning@55 {{_Thread_local is a C11-specific feature}}
+#endif
+// expected-warning@57 {{_Thread_local is a C11-specific feature}}
+// expected-warning@58 {

[PATCH] D66333: [analyzer] NonNullParamChecker and CStringChecker parameter number in checker message

2019-08-16 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ accepted this revision.
NoQ added a comment.
This revision is now accepted and ready to land.

Thanks! I'm happy to accept this as soon as other reviewers are happy.




Comment at: clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp:1548
 
-  state = checkNonNull(C, state, Dst, DstVal);
+  state = checkNonNull(C, state, Dst, DstVal, 1);
   if (!state)

You could also pass a description of the parameter (eg., "source" or 
"destination").


Repository:
  rC Clang

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

https://reviews.llvm.org/D66333



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


[PATCH] D65019: [ARM] push LR before __gnu_mcount_nc

2019-08-16 Thread Jian Cai via Phabricator via cfe-commits
jcai19 added a comment.

The changes have been upstreamed to r369147.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D65019



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


r369148 - [Test Commit] Fix typo in diagtool.rst

2019-08-16 Thread Troy A. Johnson via cfe-commits
Author: troyj
Date: Fri Aug 16 13:26:48 2019
New Revision: 369148

URL: http://llvm.org/viewvc/llvm-project?rev=369148&view=rev
Log:
[Test Commit] Fix typo in diagtool.rst

Test commit after obtaining commit access.

Modified:
cfe/trunk/docs/CommandGuide/diagtool.rst

Modified: cfe/trunk/docs/CommandGuide/diagtool.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/CommandGuide/diagtool.rst?rev=369148&r1=369147&r2=369148&view=diff
==
--- cfe/trunk/docs/CommandGuide/diagtool.rst (original)
+++ cfe/trunk/docs/CommandGuide/diagtool.rst Fri Aug 16 13:26:48 2019
@@ -9,7 +9,7 @@ SYNOPSIS
 DESCRIPTION
 ---
 
-:program:`diagtool` is a combination of four tool for dealing with diagnostics 
in :program:`clang`.
+:program:`diagtool` is a combination of four tools for dealing with 
diagnostics in :program:`clang`.
 
 SUBCOMMANDS
 ---


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


[PATCH] D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior

2019-08-16 Thread Melanie Blower via Phabricator via cfe-commits
mibintc marked 3 inline comments as not done.
mibintc added a comment.

I added an inline reply and unmarked some things that had been inadvertently 
marked done.




Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:126
+  case LangOptions::FPM_Precise:
+  case LangOptions::FPM_Fast:
+break;

mibintc wrote:
> kpn wrote:
> > Wait, so "fast" and "precise" are the same thing? That doesn't sound like 
> > where the documentation you put in the ticket says "the compiler preserves 
> > the source expression ordering and rounding properties of floating-point".
> > 
> > (Yes, I saw below where "fast" turns on the fast math flags but "precise" 
> > doesn't. That doesn't affect my point here.)
> "precise" doesn't necessitate the use of Constrained Intrinsics, And likewise 
> for "fast".   The words "compiler preserves the source expression ordering" 
> were copied from the msdn documentation for /fp:precise as you explained it 
> would be useful to have the msdn documentation for the option in case it goes 
> offline in, say, 30 years.  The ICL Intel compiler also provides equivalent 
> floating point options. The Intel documentation for precise is phrased 
> differently "Disables optimizations that are not value-safe on floating-point 
> data."  
> 
> fp-model=precise should enable contractions, if that's not true at default (I 
> mean, clang -c) then this patch is missing that.
> 
> fp-model=fast is the same as requesting ffast-math 
Well, we haven't heard from Andy yet, but he told me some time ago that 
/fp:precise corresponds more or less (there was wiggle room) to clang's default 
behavior.  It sounds like you think the description in the msdn of /fp:precise 
isn't describing clang's default behavior, @kpn can you say more about that, 
and do you think that ConstrainedIntrinsics should be created to provide the 
semantics of /fp:precise? 


Repository:
  rL LLVM

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

https://reviews.llvm.org/D62731



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


[PATCH] D66365: [clang-tidy] [readability-convert-member-functions-to-static] ignore functions that hide base class methods

2019-08-16 Thread Matthias Gehre via Phabricator via cfe-commits
mgehre created this revision.
mgehre added reviewers: aaron.ballman, Eugene.Zelenko.
Herald added a subscriber: xazax.hun.
Herald added a project: clang.

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


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D66365

Files:
  clang-tools-extra/clang-tidy/readability/ConvertMemberFunctionsToStatic.cpp
  
clang-tools-extra/test/clang-tidy/readability-convert-member-functions-to-static.cpp


Index: 
clang-tools-extra/test/clang-tidy/readability-convert-member-functions-to-static.cpp
===
--- 
clang-tools-extra/test/clang-tidy/readability-convert-member-functions-to-static.cpp
+++ 
clang-tools-extra/test/clang-tidy/readability-convert-member-functions-to-static.cpp
@@ -216,3 +216,21 @@
 return;
   }
 };
+
+class HiddingBase {
+  int f();
+
+  static int g();
+};
+
+class HiddingDerived : public HiddingBase {
+  int f() {
+return 0;
+  }
+
+  int g() {
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: method 'g' can be made static
+// CHECK-FIXES: {{^}}  static int g() {
+return 0;
+  }
+};
Index: 
clang-tools-extra/clang-tidy/readability/ConvertMemberFunctionsToStatic.cpp
===
--- clang-tools-extra/clang-tidy/readability/ConvertMemberFunctionsToStatic.cpp
+++ clang-tools-extra/clang-tidy/readability/ConvertMemberFunctionsToStatic.cpp
@@ -71,6 +71,31 @@
   return UsageOfThis.Used;
 }
 
+/// Does any base class have a non-static method with the same name?
+AST_MATCHER(CXXMethodDecl, isHiding) {
+  const IdentifierInfo *ThisIdentifier = Node.getIdentifier();
+  if (!ThisIdentifier)
+return false;
+
+  const CXXRecordDecl *Record = Node.getParent();
+
+  auto StaticOrDifferentName = [ThisIdentifier](const CXXMethodDecl *Method) {
+  if (Method->isStatic())
+return true;
+
+  const IdentifierInfo *Ident = 
Method->getIdentifier();
+  if (!Ident)
+return true;
+
+  return Ident->getName() != ThisIdentifier->getName();
+};
+
+  return !Record->forallBases([StaticOrDifferentName](const CXXRecordDecl 
*Base) {
+return llvm::all_of(Base->methods(),
+StaticOrDifferentName);
+  });
+}
+
 void ConvertMemberFunctionsToStatic::registerMatchers(MatchFinder *Finder) {
   Finder->addMatcher(
   cxxMethodDecl(
@@ -86,7 +111,8 @@
   // depending on template base class.
   ),
   isInsideMacroDefinition(),
-  hasCanonicalDecl(isInsideMacroDefinition()), usesThis(
+  hasCanonicalDecl(isInsideMacroDefinition()), isHiding(),
+  usesThis(
   .bind("x"),
   this);
 }


Index: clang-tools-extra/test/clang-tidy/readability-convert-member-functions-to-static.cpp
===
--- clang-tools-extra/test/clang-tidy/readability-convert-member-functions-to-static.cpp
+++ clang-tools-extra/test/clang-tidy/readability-convert-member-functions-to-static.cpp
@@ -216,3 +216,21 @@
 return;
   }
 };
+
+class HiddingBase {
+  int f();
+
+  static int g();
+};
+
+class HiddingDerived : public HiddingBase {
+  int f() {
+return 0;
+  }
+
+  int g() {
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: method 'g' can be made static
+// CHECK-FIXES: {{^}}  static int g() {
+return 0;
+  }
+};
Index: clang-tools-extra/clang-tidy/readability/ConvertMemberFunctionsToStatic.cpp
===
--- clang-tools-extra/clang-tidy/readability/ConvertMemberFunctionsToStatic.cpp
+++ clang-tools-extra/clang-tidy/readability/ConvertMemberFunctionsToStatic.cpp
@@ -71,6 +71,31 @@
   return UsageOfThis.Used;
 }
 
+/// Does any base class have a non-static method with the same name?
+AST_MATCHER(CXXMethodDecl, isHiding) {
+  const IdentifierInfo *ThisIdentifier = Node.getIdentifier();
+  if (!ThisIdentifier)
+return false;
+
+  const CXXRecordDecl *Record = Node.getParent();
+
+  auto StaticOrDifferentName = [ThisIdentifier](const CXXMethodDecl *Method) {
+  if (Method->isStatic())
+return true;
+
+  const IdentifierInfo *Ident = Method->getIdentifier();
+  if (!Ident)
+return true;
+
+  return Ident->getName() != ThisIdentifier->getName();
+};
+
+  return !Record->forallBases([StaticOrDifferentName](const CXXRecordDecl *Base) {
+return llvm::all_of(Base->methods(),
+StaticOrDifferentName);
+  });
+}
+
 void ConvertMemberFunctionsToStatic::registerMatchers(MatchFinder *Finder) {
   Finder->addMatcher(
   cxxMet

r369149 - Revert "[ARM] push LR before __gnu_mcount_nc"

2019-08-16 Thread Jian Cai via cfe-commits
Author: jcai19
Date: Fri Aug 16 13:40:21 2019
New Revision: 369149

URL: http://llvm.org/viewvc/llvm-project?rev=369149&view=rev
Log:
Revert "[ARM] push LR before __gnu_mcount_nc"

This reverts commit f4cf3b959333f62b7a7b2d7771f7010c9d8da388.

Modified:
cfe/trunk/lib/Basic/Targets/ARM.cpp

Modified: cfe/trunk/lib/Basic/Targets/ARM.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/ARM.cpp?rev=369149&r1=369148&r2=369149&view=diff
==
--- cfe/trunk/lib/Basic/Targets/ARM.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/ARM.cpp Fri Aug 16 13:40:21 2019
@@ -322,7 +322,7 @@ ARMTargetInfo::ARMTargetInfo(const llvm:
   if (Triple.getOS() == llvm::Triple::Linux ||
   Triple.getOS() == llvm::Triple::UnknownOS)
 this->MCountName = Opts.EABIVersion == llvm::EABI::GNU
-   ? "llvm.arm.gnu.eabi.mcount"
+   ? "\01__gnu_mcount_nc"
: "\01mcount";
 
   SoftFloatABI = llvm::is_contained(Opts.FeaturesAsWritten, "+soft-float-abi");


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


[PATCH] D66179: [LifetimeAnalysis] Support more STL idioms (template forward declaration and DependentNameType)

2019-08-16 Thread Matthias Gehre via Phabricator via cfe-commits
mgehre marked 4 inline comments as done.
mgehre added a comment.

I now start to wonder if we should instead put the attribute on all 
declarations (instead of just the canonical). Later redeclarations 
automatically inherit the attributes.
This would make both the checking easier (just check any declaration, no need 
to obtain the canonical first), and remove the special
case for adding to the definition of templated record for ClassTemplateDecls.




Comment at: clang/lib/Sema/SemaAttr.cpp:200
 CXXRecordDecl *Canonical = Record->getCanonicalDecl();
 if (Canonical->hasAttr() || Canonical->hasAttr())
   return;

gribozavr wrote:
> mgehre wrote:
> > gribozavr wrote:
> > > Should this code not do this short-circuit check? It is prone to going 
> > > out of sync with the code in `addGslOwnerPointerAttributeIfNotExisting`, 
> > > like it did just now.
> > > 
> > > If you want to check for attribute before doing the string search, you 
> > > could pass the string set into 
> > > `addGslOwnerPointerAttributeIfNotExisting`, and let that decide if it 
> > > should infer the attribute or not.
> > Yes, the `hasAttr` check here is an optimization to avoid the string 
> > search. I don't think I can move the string search into 
> > `addGslOwnerPointerAttributeIfNotExisting`, because that function is called 
> > from other call sites that don't care about a set of names.
> Sorry I wasn't clear enough -- the issue that I noticed is that this check 
> looks at the canonical decl, while `addGslOwnerPointerAttributeIfNotExisting` 
> attaches the attribute to the decl itself -- that's what I meant by "out of 
> sync".
I make sure that `addGslOwnerPointerAttributeIfNotExisting` is only called with 
the canonical decl as argument, which the caller usually has around. The only 
exception to this is when addGslOwnerPointerAttributeIfNotExisting calls itself 
to attach an attribute to the definition of templated class.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66179



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


[PATCH] D65453: [analyzer] Improve the accuracy of the Clang call graph analysis

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

I hope you dont mind me changing the revision title -- many of us are 
subscribed to the "analyzer" tag and like learning about whats changing :)

This is not an objection to the patch or anything of course, just adding some 
lurkers.


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

https://reviews.llvm.org/D65453



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


[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

2019-08-16 Thread Amy Huang via Phabricator via cfe-commits
akhuang added a comment.

> Address space have backend defined semantics, and aren’t really reserved for 
> front end use. I think the fact that non-0 address spaces on X86 codegen the 
> same as address space 0 and could be used for something by a front end is an 
> accident of how SelectionDAG is implemented. If X86 wants to reserve address 
> space ranges for frontend use, that would need to be decided and documented. 
> You don’t necessarily get the current behavior for free in GlobalISel since 
> pointer types are distinct, so this would specifically need to be implemented.

By this do you mean that this would be an instance of address spaces being used 
by the frontend? Or just that adding meaning to address spaces shouldn't be 
breaking other frontends?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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


[PATCH] D62731: [RFC] Add support for options -fp-model= and -fp-speculation= : specify floating point behavior

2019-08-16 Thread Melanie Blower via Phabricator via cfe-commits
mibintc updated this revision to Diff 215666.
mibintc marked an inline comment as not done.
mibintc edited the summary of this revision.
mibintc added a comment.

I addressed some comments from @kpn: I corrected the documentation formatting 
and added some details, and used Diag instead of llvm_unreachable.

I decided to change -fp-model=except- to -fp-model=noexcept

When the user requests -fp-model=strict I explicitly set the FMA Contraction 
mode to off.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D62731

Files:
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/CC1Options.td
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/fpconstrained.c
  clang/test/Driver/clang_f_opts.c

Index: clang/test/Driver/clang_f_opts.c
===
--- clang/test/Driver/clang_f_opts.c
+++ clang/test/Driver/clang_f_opts.c
@@ -217,6 +217,11 @@
 // RUN: %clang -### -S -fexec-charset=iso-8859-1 -o /dev/null %s 2>&1 | FileCheck -check-prefix=CHECK-INVALID-INPUT-CHARSET %s
 // CHECK-INVALID-INPUT-CHARSET: error: invalid value 'iso-8859-1' in '-fexec-charset=iso-8859-1'
 
+// RUN: %clang -### -S -fp-model=fast -fp-model=except -o /dev/null %s 2>&1 | FileCheck -check-prefix=CHECK-INVALID-FAST-EXCEPT %s
+// RUN: %clang -### -S -fp-model=fast -fp-model=except -o /dev/null %s 2>&1 | FileCheck -check-prefix=CHECK-INVALID-FAST-EXCEPT %s
+// CHECK-INVALID-FAST-EXCEPT: error: invalid argument 'fp-model=fast' not allowed with 'fp-model=except'
+//
+
 // Test that we don't error on these.
 // RUN: %clang -### -S -Werror\
 // RUN: -falign-functions -falign-functions=2 -fno-align-functions\
Index: clang/test/CodeGen/fpconstrained.c
===
--- /dev/null
+++ clang/test/CodeGen/fpconstrained.c
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -fp-model=strict -emit-llvm -o - %s | FileCheck %s -check-prefix=STRICT
+// RUN: %clang_cc1 -fp-model=strict -fp-model-except -emit-llvm -o - %s | FileCheck %s -check-prefix=STRICTEXCEPT
+// RUN: %clang_cc1 -fp-model=strict -no-fp-model-except -emit-llvm -o - %s | FileCheck %s -check-prefix=STRICTNOEXCEPT
+// RUN: %clang_cc1 -fp-model-except -emit-llvm -o - %s | FileCheck %s -check-prefix=EXCEPT
+// RUN: %clang_cc1 -no-fp-model-except -emit-llvm -o - %s | FileCheck %s -check-prefix=NOEXCEPT
+// RUN: %clang_cc1 -fp-model=precise -emit-llvm -o - %s | FileCheck %s -check-prefix=PRECISE
+// RUN: %clang_cc1 -fp-model=fast -emit-llvm -o - %s | FileCheck %s -check-prefix=FAST
+// RUN: %clang_cc1 -fp-model=fast -fp-speculation=fast -emit-llvm -o - %s | FileCheck %s -check-prefix=NOEXCEPT
+// RUN: %clang_cc1 -fp-model=fast -fp-speculation=strict -emit-llvm -o - %s | FileCheck %s -check-prefix=EXCEPT
+// RUN: %clang_cc1 -fp-model=fast -fp-speculation=safe -emit-llvm -o - %s | FileCheck %s -check-prefix=MAYTRAP
+float f0, f1, f2;
+
+void foo(void) {
+  // CHECK-LABEL: define {{.*}}void @foo()
+
+  // MAYTRAP: llvm.experimental.constrained.fadd.f32(float %0, float %1, metadata !"round.tonearest", metadata !"fpexcept.maytrap")
+  // EXCEPT: llvm.experimental.constrained.fadd.f32(float %0, float %1, metadata !"round.tonearest", metadata !"fpexcept.strict")
+  // NOEXCEPT: llvm.experimental.constrained.fadd.f32(float %0, float %1, metadata !"round.tonearest", metadata !"fpexcept.ignore")
+  // STRICT: llvm.experimental.constrained.fadd.f32(float %0, float %1, metadata !"round.dynamic", metadata !"fpexcept.strict")
+  // STRICTEXCEPT: llvm.experimental.constrained.fadd.f32(float %0, float %1, metadata !"round.dynamic", metadata !"fpexcept.strict")
+  // STRICTNOEXCEPT: llvm.experimental.constrained.fadd.f32(float %0, float %1, metadata !"round.dynamic", metadata !"fpexcept.ignore")
+  // PRECISE: fadd float
+  // FAST: fadd fast
+  f0 = f1 + f2;
+
+  // CHECK: ret
+}
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -3039,6 +3039,59 @@
   Diags.Report(diag::err_drv_invalid_value) << A->getAsString(Args) << Val;
   }
 
+  LangOptions::FPModelKind FPM = LangOptions::FPM_Off;
+  if (Arg *A = Args.getLastArg(OPT_fp_model_EQ)) {
+StringRef Val = A->getValue();
+if (Val == "precise")
+  FPM = LangOptions::FPM_Precise;
+else if (Val == "strict")
+  FPM = LangOptions::FPM_Strict;
+else if (Val == "fast")
+  FPM = LangOptions::FPM_Fast;
+else
+  llvm_unreachable("invalid -fp-model setting");
+  }
+  Opts.getFPMOptions().setFPModelSetting(FPM);
+
+  LangOptions::FPModelExceptKind FPME =

r369152 - [X86] Support -mlong-double-80

2019-08-16 Thread Troy A. Johnson via cfe-commits
Author: troyj
Date: Fri Aug 16 14:00:22 2019
New Revision: 369152

URL: http://llvm.org/viewvc/llvm-project?rev=369152&view=rev
Log:
[X86] Support -mlong-double-80

Add an option group for all of the -mlong-double-* options and make
-mlong-double-80 restore the default long double behavior for X86.  The
motivations are that GNU accepts the -mlong-double-80 option and that complex
Makefiles often need a way of undoing earlier options. Prior to this commit, if
one chooses 64-bit or 128-bit long double for X86, there is no way to undo that
choice and restore the 80-bit behavior.

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

Modified:
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/test/Driver/mlong-double-128.c

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=369152&r1=369151&r2=369152&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Fri Aug 16 14:00:22 2019
@@ -2040,9 +2040,14 @@ def malign_jumps_EQ : Joined<["-"], "mal
 def mfancy_math_387 : Flag<["-"], "mfancy-math-387">, 
Group;
 def mlong_calls : Flag<["-"], "mlong-calls">, Group,
   HelpText<"Generate branches with extended addressability, usually via 
indirect jumps.">;
-def mlong_double_64 : Flag<["-"], "mlong-double-64">, Group, 
Flags<[CC1Option]>,
+def LongDouble_Group : OptionGroup<"">, Group,
+  DocName<"Long double flags">,
+  DocBrief<[{Selects the long double implementation}]>;
+def mlong_double_64 : Flag<["-"], "mlong-double-64">, Group, 
Flags<[CC1Option]>,
   HelpText<"Force long double to be 64 bits">;
-def mlong_double_128 : Flag<["-"], "mlong-double-128">, Group, 
Flags<[CC1Option]>,
+def mlong_double_80 : Flag<["-"], "mlong-double-80">, Group, 
Flags<[CC1Option]>,
+  HelpText<"Force long double to be 80 bits, padded to 128 bits for storage">;
+def mlong_double_128 : Flag<["-"], "mlong-double-128">, 
Group, Flags<[CC1Option]>,
   HelpText<"Force long double to be 128 bits">;
 def mno_long_calls : Flag<["-"], "mno-long-calls">, Group,
   HelpText<"Restore the default behaviour of not generating long calls">;

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=369152&r1=369151&r2=369152&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Fri Aug 16 14:00:22 2019
@@ -4057,11 +4057,13 @@ void Clang::ConstructJob(Compilation &C,
 
   RenderFloatingPointOptions(TC, D, OFastEnabled, Args, CmdArgs);
 
-  if (Arg *A = Args.getLastArg(options::OPT_mlong_double_64,
-   options::OPT_mlong_double_128)) {
+  if (Arg *A = Args.getLastArg(options::OPT_LongDouble_Group)) {
 if (TC.getArch() == llvm::Triple::x86 ||
-TC.getArch() == llvm::Triple::x86_64 ||
-TC.getArch() == llvm::Triple::ppc || TC.getTriple().isPPC64())
+TC.getArch() == llvm::Triple::x86_64)
+  A->render(Args, CmdArgs);
+else if ((TC.getArch() == llvm::Triple::ppc ||
+  TC.getArch() == TC.getTriple().isPPC64()) &&
+ (A->getOption().getID() != options::OPT_mlong_double_80))
   A->render(Args, CmdArgs);
 else
   D.Diag(diag::err_drv_unsupported_opt_for_target)

Modified: cfe/trunk/test/Driver/mlong-double-128.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/mlong-double-128.c?rev=369152&r1=369151&r2=369152&view=diff
==
--- cfe/trunk/test/Driver/mlong-double-128.c (original)
+++ cfe/trunk/test/Driver/mlong-double-128.c Fri Aug 16 14:00:22 2019
@@ -2,10 +2,14 @@
 // RUN: %clang -target powerpc64-pc-freebsd12 -c -### %s -mlong-double-128 
2>&1 | FileCheck %s
 // RUN: %clang -target powerpc64le-linux-musl -c -### %s -mlong-double-128 
2>&1 | FileCheck %s
 // RUN: %clang -target i686-linux-gnu -c -### %s -mlong-double-128 2>&1 | 
FileCheck %s
-// RUN: %clang -target x86_64-linux-musl -c -### %s -mlong-double-128 2>&1 | 
FileCheck %s
+
+// RUN: %clang -target x86_64-linux-musl -c -### %s -mlong-double-128 
-mlong-double-80 2>&1 | FileCheck --implicit-check-not=-mlong-double- /dev/null
+// RUN: %clang -target x86_64-linux-musl -c -### %s -mlong-double-80 
-mlong-double-128 2>&1 | FileCheck %s
 
 // CHECK: "-mlong-double-128"
 
 // RUN: %clang -target aarch64 -c -### %s -mlong-double-128 2>&1 | FileCheck 
--check-prefix=ERR %s
+// RUN: %clang -target powerpc -c -### %s -mlong-double-80 2>&1 | FileCheck 
--check-prefix=ERR2 %s
 
 // ERR: error: unsupported option '-mlong-double-128' for target 'aarch64'
+// ERR2: error: unsupported option '-mlong-double-80' for target 
'powerpc-linux-musl'

[PATCH] D66361: Improve behavior in the case of stack exhaustion.

2019-08-16 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added inline comments.



Comment at: include/clang/Basic/Stack.h:42
+  llvm::function_ref Fn) {
+if (LLVM_UNLIKELY(isStackNearlyExhausted())) {
+  runWithSufficientStackSpaceSlow(Diag, Fn);

For LLVM_THREADS_DISABLED builds used by Chromium today, maybe we should skip 
this completely?



Comment at: lib/Basic/Stack.cpp:23
+  return __builtin_frame_address(0);
+#else
+  char CharOnStack = 0;

I think `_AddressOfReturnAddress()` ifdef _MSC_VER would be the proper way to 
ask MSVC for a reasonable stack pointer, if we're worried about returning the 
address of a local.



Comment at: lib/Basic/Stack.cpp:53-54
+  // If the stack pointer has a surprising value, we do not understand this
+  // stack usage scheme. (Perhaps the target allocates new stack regions on
+  // demand for us.) Don't try to guess what's going on.
+  if (StackUsage > DesiredStackSize)

So, for example, ASan with UAR, where frames are heap allocated. I suppose in 
that case we will go down the __builtin_frame_address path, though.



Comment at: test/SemaTemplate/stack-exhaustion.cpp:10
+template struct tuple {};
+template auto f(tuple t) -> decltype(f(tuple(t))) 
{} // expected-error {{exceeded maximum depth}}
+void g() { f(tuple()); }

This test seems like it could be fragile. If threads are disabled, it will 
probably crash.


Repository:
  rC Clang

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

https://reviews.llvm.org/D66361



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


[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

2019-08-16 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

In D64931#1633669 , @akhuang wrote:

> > Address space have backend defined semantics, and aren’t really reserved 
> > for front end use. I think the fact that non-0 address spaces on X86 
> > codegen the same as address space 0 and could be used for something by a 
> > front end is an accident of how SelectionDAG is implemented. If X86 wants 
> > to reserve address space ranges for frontend use, that would need to be 
> > decided and documented. You don’t necessarily get the current behavior for 
> > free in GlobalISel since pointer types are distinct, so this would 
> > specifically need to be implemented.
>
> By this do you mean that this would be an instance of address spaces being 
> used by the frontend? Or just that adding meaning to address spaces shouldn't 
> be breaking other frontends?


I mean if frontends are relying on current specific behavior for these address 
spaces, that’s not something that’s documented to work. It just happens to


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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


[PATCH] D65907: Introduce FileEntryRef and use it when handling includes to report correct dependencies when the FileManager is reused across invocations

2019-08-16 Thread Bruno Cardoso Lopes via Phabricator via cfe-commits
bruno added inline comments.



Comment at: clang/include/clang/Basic/FileManager.h:110
+/// A reference to a \c FileEntry that includes the name of the file as it was
+/// accessed by the FileManager's client.
+class FileEntryRef {

How does that work with the VFS? Will it keep the virtual path as the FileName 
to return with getName() or the external-content? Should it change when in face 
of `use-external-names` attribute?



Comment at: clang/include/clang/Basic/FileManager.h:249-251
+  /// This function is deprecated and will be removed at some point in the
+  /// future, new clients should use
+  ///  \c getFileRef.

Bigcheese wrote:
> `LLVM_DEPRECATED()`?  (or w/e the name is of our depreciation attribute 
> macro).
Probably can't be done until we move all uses over? There's probably still 
enough of them that the warning would be very annoying?



Comment at: clang/lib/Basic/FileManager.cpp:194
+static llvm::ErrorOr
+promoteFileRef(StringRef name, llvm::ErrorOr value) {
+  if (value)

I know the surrounding functions are not consistent with capitalization, but 
maybe `name` and `value` here should?


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

https://reviews.llvm.org/D65907



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


[PATCH] D65545: Handle some fs::remove failures

2019-08-16 Thread Bruno Cardoso Lopes via Phabricator via cfe-commits
bruno accepted this revision.
bruno added a comment.

LGTM with one minor change.




Comment at: clang/lib/Frontend/PrecompiledPreamble.cpp:38
 
+#define DEBUG_TYPE "pch"
+

`pch-preamble` is more accurate here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65545



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


  1   2   >