[PATCH] D91466: [WIP][clang][Fuchsia] Support HWASan for Fuchsia

[Petr Hosek via Phabricator via cfe-commits]

phosek added inline comments.



Comment at: clang/lib/Driver/ToolChains/Fuchsia.cpp:100-101
   Dyld += "tsan/";
+if (SanArgs.needsHwasanRt() && SanArgs.needsSharedRt())
+  Dyld += "hwasan/";
 Dyld += "ld.so.1";

Nit: can you move this above TSan so it's alphabetically sorted?



Comment at: clang/lib/Driver/ToolChains/Fuchsia.cpp:222
   .flag("+fno-exceptions"));
+  // ASan has higher priority because we always want the instrumentated 
version.
+  Multilibs.push_back(Multilib("hwasan", {}, {}, 6)





Comment at: clang/lib/Driver/ToolChains/Fuchsia.cpp:222-229
+  // ASan has higher priority because we always want the instrumentated 
version.
+  Multilibs.push_back(Multilib("hwasan", {}, {}, 6)
+  .flag("+fsanitize=hwaddress"));
+  // Use the asan+noexcept variant with ASan and -fno-exceptions.
+  Multilibs.push_back(Multilib("hwasan+noexcept", {}, {}, 7)
+  .flag("+fsanitize=hwaddress")
+  .flag("-fexceptions")

phosek wrote:
> 
Can you move this above relative-vtables so we keep all sanitizers together?



Comment at: clang/lib/Driver/ToolChains/Fuchsia.cpp:225
+  .flag("+fsanitize=hwaddress"));
+  // Use the asan+noexcept variant with ASan and -fno-exceptions.
+  Multilibs.push_back(Multilib("hwasan+noexcept", {}, {}, 7)





Comment at: compiler-rt/lib/hwasan/hwasan_fuchsia.cpp:122-124
+  // we wish to ignore. This (currently) only occurs on AArch64, as x64
+  // implementations use SIGTRAP to implement the failure, and thus do not go
+  // through the stack saver.

I don't think this applies to Fuchsia.



Comment at: compiler-rt/lib/hwasan/hwasan_poisoning.cpp:22
 
 uptr TagMemoryAligned(uptr p, uptr size, tag_t tag) {
   CHECK(IsAligned(p, kShadowAlignment));

It might be better to move this function to a per-platform file rather than 
conditionally compiling the entire body.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91466

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

[PATCH] D90448: [clang] Add type check for explicit instantiation of static data members

[Chuyang Chen via Phabricator via cfe-commits]

nomanous added a comment.

Ping @rsmith @dblaikie @MaskRay @haowei @Xiangling_L @lebedev.ri


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90448

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

[PATCH] D96719: [clang-tidy] Add new check 'bugprone-thread-canceltype-asynchronous' and alias 'cert-pos47-c'.

[Balázs Kéri via Phabricator via cfe-commits]

balazske added inline comments.



Comment at: clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp:169
 "bugprone-terminating-continue");
+CheckFactories.registerCheck(
+"bugprone-thread-canceltype-asynchronous");

aaron.ballman wrote:
> I think this check is likely better surfaced in the `concurrency` module. 
> WDYT?
It is really better in ``concurrency``, I was not aware of that module (it 
contains only one check).



Comment at: 
clang-tools-extra/clang-tidy/bugprone/ThreadCanceltypeAsynchronousCheck.cpp:29
+
+static Preprocessor *PP;
+

aaron.ballman wrote:
> Any particular reason to use a global variable here rather than making it a 
> member of `ThreadCanceltypeAsynchronousCheck`?
Member is better, I just copied the code from another file (that was added not 
long ago) and assumed that it is correct even if it looks not good.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/ThreadCanceltypeAsynchronousCheck.cpp:38
+};
+const auto TryExpandAsInteger =
+[](Preprocessor::macro_iterator It) -> Optional {

aaron.ballman wrote:
> Do we know that POSIX implementations always use a simple integer here, or do 
> we have to worry about code like:
> ```
> #define PTHREAD_CANCEL_ASYNCHRONOUS (1 << 0)
> ```
> or
> ```
> #define PTHREAD_CANCEL_ASYNCHRONOUS SOME_OTHER_MACRO
> ```
Theoretically it is possible that the macro is defined not as a simple number 
([[https://pubs.opengroup.org/onlinepubs/9699919799/ | at this page ]] see 
"Symbolic Constant"). But I am not sure if it is possible to get the value from 
the preprocessor for any constant expression.

There is a similar function `tryExpandAsInteger` already in clang 
(CheckerHelpers.cpp) that can be reused here, probably it retrieves the macro 
definition better. The function could be put into one of the "utils" files, 
maybe **LexerUtils.h**, it is already needed at 2 places 
(bad-signal-to-kill-thread and here).



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96719

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

[PATCH] D96944: [RecoveryAST] Add design doc to clang internal manual.

[Haojian Wu via Phabricator via cfe-commits]

hokein created this revision.
hokein added a reviewer: sammccall.
hokein requested review of this revision.
Herald added a project: clang.

Hopefully it would be useful for new developers.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96944

Files:
  clang/docs/InternalsManual.rst

Index: clang/docs/InternalsManual.rst
===
--- clang/docs/InternalsManual.rst
+++ clang/docs/InternalsManual.rst
@@ -1863,6 +1863,143 @@
 are not ``Redeclarable`` -- in that case, a ``Mergeable`` base class is used
 instead).
 
+Error Handling
+--
+
+Clang produces an AST even when the code contains errors. Clang won't generate
+and optimize code for it, but it's used as parsing continues to detect further
+errors in the input. Clang-based tools also depend on such ASTs, and IDEs in
+particular benefit from a high-quality AST for broken code.
+
+In presence of errors, clang uses a few error-recovery strategies to present the
+broken code in the AST:
+
+- correcting errors: in cases where clang is confident about the fix, it
+  provides a FixIt attaching to the error diagnostic and emits a corrected AST
+  (reflecting the written code with FixIts applied). The advantage of that is to
+  provide more accurate subsequent diagnostics. Typo correction is a typical
+  example.
+- representing invalid node: the invalid node is preserved in the AST in some
+  form, e.g. when the "declaration" part of the declaration contains semantic
+  errors, the Decl node is marked as invalid.
+- dropping invalid node: this often happens for errors that we don’t have
+  graceful recovery, prior to Recovery AST, a mismatched-argument function call
+  expression was dropped though a CallExpr was created for semantic analysis.
+
+With these strategies, clang surfaces nice diagnostics, and provides a rich AST
+reflecting the written source code as much as possible even for broken code to
+AST consumers.
+
+Recovery AST
+
+
+The idea of Recovery AST is to use recovery nodes which act as a placeholder to
+maintain the rough structure of the parsing tree, preserve locations and
+children but have no language semantics attached to them.
+
+For example, consider the following mismatched function call:
+
+.. code-block:: c++
+
+   int NoArg();
+   void test(int abc) {
+ NoArg(abc); // oops, mismatched function arguments.
+   }
+
+Without Recovery AST, the invalid function call expression (and its child
+expressions) was dropped in the AST:
+
+::
+
+|-FunctionDecl  NoArg 'int ()'
+`-FunctionDecl  test 'void (int)'
+ |-ParmVarDecl  col:15 used abc 'int'
+ `-CompoundStmt 
+
+
+With Recovery AST, the AST looks like:
+
+::
+
+|-FunctionDecl  NoArg 'int ()'
+`-FunctionDecl  test 'void (int)'
+  |-ParmVarDecl  used abc 'int'
+  `-CompoundStmt 
+`-RecoveryExpr  'int' contains-errors
+  |-UnresolvedLookupExpr  '' lvalue (ADL) = 'NoArg'
+  `-DeclRefExpr  'int' lvalue ParmVar 'abc' 'int'
+
+
+An alternative is to use existing Exprs, e.g. CallExpr for the above example.
+The basic trade off is that jamming the data we have into CallExpr forces us to
+weaken its invariants, e.g. arg count may be wrong. This would introduce a huge
+burden on consumers of the AST to handle such "impossible" cases. So when we're
+representing (rather than correcting) errors, we use a distinct recovery node
+type with extremely weak invariants instead.
+
+``RecoveryExpr`` is the only recovery node so far. In practice, broken decls
+need more detailed semantics preserved (the current ``Invalid`` flag works
+fairly well), and completely broken statements with interesting internal
+structure are rare (so dropping the statements is OK).
+
+Types and dependence
+
+
+``RecoveryExpr`` is an ``Expr``, so it must have a type. In many cases the true
+type can't really be known until the code is corrected (e.g. a call to a
+function that doesn't exist). And it means that we can't properly perform type
+checks on some containing constructs, such as ``return 42 + unknownFunction()``.
+
+To model this, we generalize the concept of dependence from C++ templates to
+mean dependence on a template parameter or how an error is repaired. The
+``RecoveryExpr`` ``unknownFunction()`` has the totally unknown type
+``DependentTy``, and this suppresses type-based analysis in the same way it
+would inside a template.
+
+In cases where we are confident about the concrete type (e.g. the return type
+for a broken non-overloaded function call), the ``RecoveryExpr`` will have this
+type. This allows more code to be typechecked, and produces a better AST and
+more diagnostics. For example:
+
+.. code-block:: C++
+
+   unknownFunction().size() // .size() is a CXXDependentScopeMemberExpr
+   std::string(42).size() // .size() is a resolved MemberExpr
+
+Whether or not the ``RecoveryExpr`` has a dependent type, it is always
+considered value-d

[PATCH] D89870: [clangd] Drop template argument lists from completions followed by

[Kadir Cetinkaya via Phabricator via cfe-commits]

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

thanks, lgtm!




Comment at: clang-tools-extra/clangd/CodeComplete.cpp:474
+//
+// fu^(42) -> function(42);
+if (Snippet->front() == '<') {

RHS should be `function(42)` right?



Comment at: clang-tools-extra/clangd/CodeComplete.cpp:480
+  unsigned Balance, Index;
+  for (Balance = 1, Index = 1; Balance && (Index != Snippet->size());
+   ++Index) {

nit:
```
int Balance = 0;
size_t I = 0;
do {
  if(Snippet[I] == '>') --Balance;
  else if(Snippet[I] == '<') ++Balance;
  ++I;
} while(Balance > 0);
return Snippet->substr(0, I);
```

This should handle both the case snippet starts with `<` and not. reducing the 
nesting a little and making the flow more uniform (i.e. getting rid of the 
second return statement).


Up to you though, if you keep the existing version please move definition of 
`Balance` into for-init statement, use `size_t` instead of `unsigned` and array 
subscripts instead of `at(Index)`.



Comment at: clang-tools-extra/clangd/CodeComplete.cpp:496
+  //
+  // fu^(42) -> function(42);
+  if (NextTokenKind == tok::less && Snippet->front() == '<')

i think it is better to omit `(42)` in this example.



Comment at: clang-tools-extra/clangd/CodeComplete.cpp:497
+  // fu^(42) -> function(42);
+  if (NextTokenKind == tok::less && Snippet->front() == '<')
+return "";

You've marked the previous nit as done, but this case still seems to be coming 
after the complicated case, just in case it slipped :D


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89870

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

[PATCH] D96838: CodeGen: Set !retain metadata on UsedAttr definitions for FreeBSD/Fuchsia/Linux

[Alexander Richardson via Phabricator via cfe-commits]

arichardson added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:2071
+  const llvm::Triple &T = getTarget().getTriple();
+  if (T.isOSFreeBSD() || T.isOSLinux())
+GO->setMetadata(llvm::LLVMContext::MD_retain,

phosek wrote:
> Would it be possible to also include Fuchsia?
Why does the IR metadata depend on the OS? Shouldn't this decision happen 
later? Alternatively maybe the check should be for ELF?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96838

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

[PATCH] D96270: [release][docs] Update contributions to LLVM 12 for scalable vectors.

[David Sherwood via Phabricator via cfe-commits]

david-arm closed this revision.
david-arm added a comment.

Merged to LLVM Release 12.x branch


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

https://reviews.llvm.org/D96270

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

[clang] 780ead4 - [Syntax] No crash on OpaqueValueExpr.

[Haojian Wu via cfe-commits]

Author: Haojian Wu
Date: 2021-02-18T10:32:04+01:00
New Revision: 780ead41e075eb7875874633cd9c6f2d5ceab95e

URL: 
https://github.com/llvm/llvm-project/commit/780ead41e075eb7875874633cd9c6f2d5ceab95e
DIFF: 
https://github.com/llvm/llvm-project/commit/780ead41e075eb7875874633cd9c6f2d5ceab95e.diff

LOG: [Syntax] No crash on OpaqueValueExpr.

OpaqueValueExpr doesn't correspond to the concrete syntax, it has
invalid source location, ignore them.

Reviewed By: kbobyrev

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

Added: 


Modified: 
clang/lib/Tooling/Syntax/BuildTree.cpp
clang/unittests/Tooling/Syntax/BuildTreeTest.cpp

Removed: 




diff  --git a/clang/lib/Tooling/Syntax/BuildTree.cpp 
b/clang/lib/Tooling/Syntax/BuildTree.cpp
index a5cb293832d9..07888b5c32fa 100644
--- a/clang/lib/Tooling/Syntax/BuildTree.cpp
+++ b/clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -856,6 +856,11 @@ class BuildTreeVisitor : public 
RecursiveASTVisitor {
 return RecursiveASTVisitor::TraverseStmt(S);
   }
 
+  bool TraverseOpaqueValueExpr(OpaqueValueExpr *VE) {
+// OpaqueValue doesn't correspond to concrete syntax, ignore it.
+return true;
+  }
+
   // Some expressions are not yet handled by syntax trees.
   bool WalkUpFromExpr(Expr *E) {
 assert(!isImplicitExpr(E) && "should be handled by TraverseStmt");

diff  --git a/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp 
b/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
index 299a2c320a4c..b6bcd4eb2da5 100644
--- a/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
+++ b/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
@@ -512,6 +512,25 @@ TranslationUnit Detached
 )txt"));
 }
 
+TEST_P(BuildSyntaxTreeTest, ConditionalOperator) {
+  // FIXME: conditional expression is not modeled yet.
+  EXPECT_TRUE(treeDumpEqualOnAnnotations(
+  R"cpp(
+void test() {
+  [[1?:2]];
+}
+)cpp",
+  {R"txt(
+UnknownExpression Expression
+|-IntegerLiteralExpression
+| `-'1' LiteralToken
+|-'?'
+|-':'
+`-IntegerLiteralExpression
+  `-'2' LiteralToken
+)txt"}));
+}
+
 TEST_P(BuildSyntaxTreeTest, UnqualifiedId_Identifier) {
   EXPECT_TRUE(treeDumpEqualOnAnnotations(
   R"cpp(



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

[PATCH] D96112: [Syntax] No crash on OpaqueValueExpr.

[Haojian Wu via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG780ead41e075: [Syntax] No crash on OpaqueValueExpr. 
(authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96112

Files:
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/unittests/Tooling/Syntax/BuildTreeTest.cpp


Index: clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
+++ clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
@@ -512,6 +512,25 @@
 )txt"));
 }
 
+TEST_P(BuildSyntaxTreeTest, ConditionalOperator) {
+  // FIXME: conditional expression is not modeled yet.
+  EXPECT_TRUE(treeDumpEqualOnAnnotations(
+  R"cpp(
+void test() {
+  [[1?:2]];
+}
+)cpp",
+  {R"txt(
+UnknownExpression Expression
+|-IntegerLiteralExpression
+| `-'1' LiteralToken
+|-'?'
+|-':'
+`-IntegerLiteralExpression
+  `-'2' LiteralToken
+)txt"}));
+}
+
 TEST_P(BuildSyntaxTreeTest, UnqualifiedId_Identifier) {
   EXPECT_TRUE(treeDumpEqualOnAnnotations(
   R"cpp(
Index: clang/lib/Tooling/Syntax/BuildTree.cpp
===
--- clang/lib/Tooling/Syntax/BuildTree.cpp
+++ clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -856,6 +856,11 @@
 return RecursiveASTVisitor::TraverseStmt(S);
   }
 
+  bool TraverseOpaqueValueExpr(OpaqueValueExpr *VE) {
+// OpaqueValue doesn't correspond to concrete syntax, ignore it.
+return true;
+  }
+
   // Some expressions are not yet handled by syntax trees.
   bool WalkUpFromExpr(Expr *E) {
 assert(!isImplicitExpr(E) && "should be handled by TraverseStmt");


Index: clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
+++ clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
@@ -512,6 +512,25 @@
 )txt"));
 }
 
+TEST_P(BuildSyntaxTreeTest, ConditionalOperator) {
+  // FIXME: conditional expression is not modeled yet.
+  EXPECT_TRUE(treeDumpEqualOnAnnotations(
+  R"cpp(
+void test() {
+  [[1?:2]];
+}
+)cpp",
+  {R"txt(
+UnknownExpression Expression
+|-IntegerLiteralExpression
+| `-'1' LiteralToken
+|-'?'
+|-':'
+`-IntegerLiteralExpression
+  `-'2' LiteralToken
+)txt"}));
+}
+
 TEST_P(BuildSyntaxTreeTest, UnqualifiedId_Identifier) {
   EXPECT_TRUE(treeDumpEqualOnAnnotations(
   R"cpp(
Index: clang/lib/Tooling/Syntax/BuildTree.cpp
===
--- clang/lib/Tooling/Syntax/BuildTree.cpp
+++ clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -856,6 +856,11 @@
 return RecursiveASTVisitor::TraverseStmt(S);
   }
 
+  bool TraverseOpaqueValueExpr(OpaqueValueExpr *VE) {
+// OpaqueValue doesn't correspond to concrete syntax, ignore it.
+return true;
+  }
+
   // Some expressions are not yet handled by syntax trees.
   bool WalkUpFromExpr(Expr *E) {
 assert(!isImplicitExpr(E) && "should be handled by TraverseStmt");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D96816: [ObjC] Encode pointers to C++ classes as "^v" if the encoded string would otherwise include template specialization types

[David Chisnall via Phabricator via cfe-commits]

theraven added inline comments.



Comment at: clang/include/clang/Driver/Options.td:2113
+def fno_objc_encode_cxx_class_template_spec :
+  Flag<["-"], "fno-objc-encode-cxx-class-template-spec">, Group;
 defm objc_convert_messages_to_runtime_calls : 
BoolFOption<"objc-convert-messages-to-runtime-calls",

I think there's some magic in Options.td for defining the thing and its no- 
variant together.  I don't think you want the f prefix in the name either if 
it's an f-option.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5784
+   options::OPT_fno_objc_encode_cxx_class_template_spec,
+   !Triple.isOSDarwin()))
+CmdArgs.push_back("-fobjc-encode-cxx-class-template-spec");

I don't think this should be guarded on Darwin, it should be guarded on whether 
the [ObjCRuntime is a NeXT-family 
runtime](https://github.com/llvm/llvm-project/blob/62ec4ac90738a5f2d209ed28c83e58aaaeb7/clang/include/clang/Basic/ObjCRuntime.h#L134).
  It might be fine to enable this for all non-GNUstep runtimes (the GCC ABI has 
typed selectors, but doesn't use the type information for dispatch and doesn't 
have non-fragile ivars.  I believe the ObjFW runtime is the same).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96816

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

[PATCH] D96856: [clangd] Narrow and document a loophole in blockUntilIdle

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

LG for the `blockUntilIdle` update, but feels like two patches wind up together 
:(


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96856

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

[PATCH] D96856: [clangd] Narrow and document a loophole in blockUntilIdle

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added inline comments.



Comment at: clang-tools-extra/clangd/ClangdServer.cpp:893
+  for (llvm::Optional Timeout :
+   {TimeoutSeconds, TimeoutSeconds, llvm::Optional(0)}) {
+if (!CDB.blockUntilIdle(timeoutSeconds(Timeout)))

this is extending the Deadline in theory, e.g. if user requested idleness in 10 
seconds, this can now wait for up to 20 seconds. but this was possible in the 
previous case too, e.g. CDB could block for 10 seconds, and then bgindex would 
block for another 10 seconds, and mentioned this is only for tests, so should 
be fine (but might be worth mentioning in the comments.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96856

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

[PATCH] D96825: [AArch64] Adding Neon Polynomial vadd Intrinsics

[David Spickett via Phabricator via cfe-commits]

DavidSpickett accepted this revision.
DavidSpickett added a comment.

LGTM


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

https://reviews.llvm.org/D96825

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

[PATCH] D96568: [CFE, SystemZ] Emit s390.tdc instrincic for __builtin_isnan in Constrained FP mode.

[Ulrich Weigand via Phabricator via cfe-commits]

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

LGTM as well, thanks!


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

https://reviews.llvm.org/D96568

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

[PATCH] D96751: [clangd] Populate detail field in document symbols

[WangWei via Phabricator via cfe-commits]

lightmelodies updated this revision to Diff 324582.
lightmelodies added a comment.

Change behavior of template and add unit tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96751

Files:
  clang-tools-extra/clangd/FindSymbols.cpp
  clang-tools-extra/clangd/test/symbols.test
  clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp

Index: clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
+++ clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
@@ -35,6 +35,7 @@
 }
 MATCHER_P(WithName, N, "") { return arg.name == N; }
 MATCHER_P(WithKind, Kind, "") { return arg.kind == Kind; }
+MATCHER_P(WithDetail, Detail, "") { return arg.detail == Detail; }
 MATCHER_P(SymRange, Range, "") { return arg.range == Range; }
 
 // GMock helpers for matching DocumentSymbol.
@@ -374,44 +375,55 @@
   EXPECT_THAT(
   getSymbols(TU.build()),
   ElementsAreArray(
-  {AllOf(WithName("Foo"), WithKind(SymbolKind::Class), Children()),
+  {AllOf(WithName("Foo"), WithKind(SymbolKind::Class),
+ WithDetail("class"), Children()),
AllOf(WithName("Foo"), WithKind(SymbolKind::Class),
- Children(AllOf(WithName("Foo"),
-WithKind(SymbolKind::Constructor), Children()),
-  AllOf(WithName("Foo"),
-WithKind(SymbolKind::Constructor), Children()),
-  AllOf(WithName("f"), WithKind(SymbolKind::Method),
-Children()),
-  AllOf(WithName("operator="),
-WithKind(SymbolKind::Method), Children()),
-  AllOf(WithName("~Foo"),
-WithKind(SymbolKind::Constructor), Children()),
-  AllOf(WithName("Nested"), WithKind(SymbolKind::Class),
-Children(AllOf(WithName("f"),
-   WithKind(SymbolKind::Method),
-   Children()),
-   AllOf(WithName("Friend"), WithKind(SymbolKind::Class), Children()),
-   AllOf(WithName("f1"), WithKind(SymbolKind::Function), Children()),
-   AllOf(WithName("f2"), WithKind(SymbolKind::Function), Children()),
-   AllOf(WithName("KInt"), WithKind(SymbolKind::Variable), Children()),
-   AllOf(WithName("kStr"), WithKind(SymbolKind::Variable), Children()),
-   AllOf(WithName("f1"), WithKind(SymbolKind::Function), Children()),
+ WithDetail("class"),
+ Children(
+ AllOf(WithName("Foo"), WithKind(SymbolKind::Constructor),
+   WithDetail("void ()"), Children()),
+ AllOf(WithName("Foo"), WithKind(SymbolKind::Constructor),
+   WithDetail("void (int)"), Children()),
+ AllOf(WithName("f"), WithKind(SymbolKind::Method),
+   WithDetail("void ()"), Children()),
+ AllOf(WithName("operator="), WithKind(SymbolKind::Method),
+   WithDetail("Foo &(const Foo &)"), Children()),
+ AllOf(WithName("~Foo"), WithKind(SymbolKind::Constructor),
+   WithDetail("void ()"), Children()),
+ AllOf(WithName("Nested"), WithKind(SymbolKind::Class),
+   WithDetail("class"),
+   Children(AllOf(
+   WithName("f"), WithKind(SymbolKind::Method),
+   WithDetail("void ()"), Children()),
+   AllOf(WithName("Friend"), WithKind(SymbolKind::Class),
+ WithDetail("class"), Children()),
+   AllOf(WithName("f1"), WithKind(SymbolKind::Function),
+ WithDetail("void ()"), Children()),
+   AllOf(WithName("f2"), WithKind(SymbolKind::Function),
+ WithDetail("void ()"), Children()),
+   AllOf(WithName("KInt"), WithKind(SymbolKind::Variable),
+ WithDetail("const int"), Children()),
+   AllOf(WithName("kStr"), WithKind(SymbolKind::Variable),
+ WithDetail("const char *"), Children()),
+   AllOf(WithName("f1"), WithKind(SymbolKind::Function),
+ WithDetail("void ()"), Children()),
AllOf(
-   WithName("foo"), WithKind(SymbolKind::Namespace),
-   Children(
-   AllOf(WithName("int32"), WithKind(SymbolKind::Class),
- Children()),
-   AllOf(WithName("int32_t"), WithKind(SymbolKind::Class),
- Children()),
-   AllOf(WithName("v1"), WithKind(Symb

[clang] 5a4a014 - [OpenCL] Move printf declaration to opencl-c-base.h

[Sven van Haastregt via cfe-commits]

Author: Sven van Haastregt
Date: 2021-02-18T11:27:19Z
New Revision: 5a4a01460f1a8f29db9aa3581097dd8bc105425c

URL: 
https://github.com/llvm/llvm-project/commit/5a4a01460f1a8f29db9aa3581097dd8bc105425c
DIFF: 
https://github.com/llvm/llvm-project/commit/5a4a01460f1a8f29db9aa3581097dd8bc105425c.diff

LOG: [OpenCL] Move printf declaration to opencl-c-base.h

Supporting `printf` with `-fdeclare-opencl-builtins` would require
special handling (for e.g. varargs and format attributes) for just
this one function.  Instead, move the `printf` declaration to the
shared base header.

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

Added: 


Modified: 
clang/lib/Headers/opencl-c-base.h
clang/lib/Headers/opencl-c.h

Removed: 




diff  --git a/clang/lib/Headers/opencl-c-base.h 
b/clang/lib/Headers/opencl-c-base.h
index fdd50324bd74..30ac9d19fbbd 100644
--- a/clang/lib/Headers/opencl-c-base.h
+++ b/clang/lib/Headers/opencl-c-base.h
@@ -460,6 +460,12 @@ typedef struct {
 
 #endif // defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= 
CL_VERSION_2_0)
 
+#if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= CL_VERSION_1_2)
+// OpenCL v1.2 s6.12.13, v2.0 s6.13.13 - printf
+
+int printf(__constant const char* st, ...) __attribute__((format(printf, 1, 
2)));
+#endif
+
 #ifdef cl_intel_device_side_avc_motion_estimation
 #pragma OPENCL EXTENSION cl_intel_device_side_avc_motion_estimation : begin
 

diff  --git a/clang/lib/Headers/opencl-c.h b/clang/lib/Headers/opencl-c.h
index ab665628c8e1..b686ff387788 100644
--- a/clang/lib/Headers/opencl-c.h
+++ b/clang/lib/Headers/opencl-c.h
@@ -14176,12 +14176,6 @@ half16 __ovld __cnfn shuffle2(half8 x, half8 y, 
ushort16 mask);
 half16 __ovld __cnfn shuffle2(half16 x, half16 y, ushort16 mask);
 #endif //cl_khr_fp16
 
-#if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= CL_VERSION_1_2)
-// OpenCL v1.2 s6.12.13, v2.0 s6.13.13 - printf
-
-int printf(__constant const char* st, ...) __attribute__((format(printf, 1, 
2)));
-#endif
-
 // OpenCL v1.1 s6.11.3, v1.2 s6.12.14, v2.0 s6.13.14 - Image Read and Write 
Functions
 
 #ifdef cl_khr_gl_msaa_sharing



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

[PATCH] D96789: [OpenCL] Move printf declaration to opencl-c-base.h

[Sven van Haastregt via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG5a4a01460f1a: [OpenCL] Move printf declaration to 
opencl-c-base.h (authored by svenvh).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96789

Files:
  clang/lib/Headers/opencl-c-base.h
  clang/lib/Headers/opencl-c.h


Index: clang/lib/Headers/opencl-c.h
===
--- clang/lib/Headers/opencl-c.h
+++ clang/lib/Headers/opencl-c.h
@@ -14176,12 +14176,6 @@
 half16 __ovld __cnfn shuffle2(half16 x, half16 y, ushort16 mask);
 #endif //cl_khr_fp16
 
-#if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= CL_VERSION_1_2)
-// OpenCL v1.2 s6.12.13, v2.0 s6.13.13 - printf
-
-int printf(__constant const char* st, ...) __attribute__((format(printf, 1, 
2)));
-#endif
-
 // OpenCL v1.1 s6.11.3, v1.2 s6.12.14, v2.0 s6.13.14 - Image Read and Write 
Functions
 
 #ifdef cl_khr_gl_msaa_sharing
Index: clang/lib/Headers/opencl-c-base.h
===
--- clang/lib/Headers/opencl-c-base.h
+++ clang/lib/Headers/opencl-c-base.h
@@ -460,6 +460,12 @@
 
 #endif // defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= 
CL_VERSION_2_0)
 
+#if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= CL_VERSION_1_2)
+// OpenCL v1.2 s6.12.13, v2.0 s6.13.13 - printf
+
+int printf(__constant const char* st, ...) __attribute__((format(printf, 1, 
2)));
+#endif
+
 #ifdef cl_intel_device_side_avc_motion_estimation
 #pragma OPENCL EXTENSION cl_intel_device_side_avc_motion_estimation : begin
 


Index: clang/lib/Headers/opencl-c.h
===
--- clang/lib/Headers/opencl-c.h
+++ clang/lib/Headers/opencl-c.h
@@ -14176,12 +14176,6 @@
 half16 __ovld __cnfn shuffle2(half16 x, half16 y, ushort16 mask);
 #endif //cl_khr_fp16
 
-#if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= CL_VERSION_1_2)
-// OpenCL v1.2 s6.12.13, v2.0 s6.13.13 - printf
-
-int printf(__constant const char* st, ...) __attribute__((format(printf, 1, 2)));
-#endif
-
 // OpenCL v1.1 s6.11.3, v1.2 s6.12.14, v2.0 s6.13.14 - Image Read and Write Functions
 
 #ifdef cl_khr_gl_msaa_sharing
Index: clang/lib/Headers/opencl-c-base.h
===
--- clang/lib/Headers/opencl-c-base.h
+++ clang/lib/Headers/opencl-c-base.h
@@ -460,6 +460,12 @@
 
 #endif // defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= CL_VERSION_2_0)
 
+#if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= CL_VERSION_1_2)
+// OpenCL v1.2 s6.12.13, v2.0 s6.13.13 - printf
+
+int printf(__constant const char* st, ...) __attribute__((format(printf, 1, 2)));
+#endif
+
 #ifdef cl_intel_device_side_avc_motion_estimation
 #pragma OPENCL EXTENSION cl_intel_device_side_avc_motion_estimation : begin
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D96948: [OpenCL] Move remaining defines to opencl-c-base.h

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh created this revision.
svenvh added a reviewer: Anastasia.
svenvh added a project: clang.
Herald added a subscriber: yaxunl.
svenvh requested review of this revision.
Herald added a subscriber: cfe-commits.

Move any remaining preprocessor defines from `opencl-c.h` to
`opencl-c-base.h`, such that they are shared with
`-fdeclare-opencl-builtins` too.

In particular, move:

- the `as_type` and `as_typen` definitions, and
- the `kernel_exec` and `__kernel_exec` definitions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96948

Files:
  clang/lib/Headers/opencl-c-base.h
  clang/lib/Headers/opencl-c.h

Index: clang/lib/Headers/opencl-c.h
===
--- clang/lib/Headers/opencl-c.h
+++ clang/lib/Headers/opencl-c.h
@@ -6339,101 +6339,6 @@
 
 #endif // cl_khr_fp16
 
-/**
- * OpenCL v1.1/1.2/2.0 s6.2.4.2 - as_type operators
- * Reinterprets a data type as another data type of the same size
- */
-#define as_char(x) __builtin_astype((x),   char)
-#define as_char2(x) __builtin_astype((x),  char2)
-#define as_char3(x) __builtin_astype((x),  char3)
-#define as_char4(x) __builtin_astype((x),  char4)
-#define as_char8(x) __builtin_astype((x),  char8)
-#define as_char16(x) __builtin_astype((x), char16)
-
-#define as_uchar(x) __builtin_astype((x),   uchar)
-#define as_uchar2(x) __builtin_astype((x),  uchar2)
-#define as_uchar3(x) __builtin_astype((x),  uchar3)
-#define as_uchar4(x) __builtin_astype((x),  uchar4)
-#define as_uchar8(x) __builtin_astype((x),  uchar8)
-#define as_uchar16(x) __builtin_astype((x), uchar16)
-
-#define as_short(x) __builtin_astype((x),   short)
-#define as_short2(x) __builtin_astype((x),  short2)
-#define as_short3(x) __builtin_astype((x),  short3)
-#define as_short4(x) __builtin_astype((x),  short4)
-#define as_short8(x) __builtin_astype((x),  short8)
-#define as_short16(x) __builtin_astype((x), short16)
-
-#define as_ushort(x) __builtin_astype((x),   ushort)
-#define as_ushort2(x) __builtin_astype((x),  ushort2)
-#define as_ushort3(x) __builtin_astype((x),  ushort3)
-#define as_ushort4(x) __builtin_astype((x),  ushort4)
-#define as_ushort8(x) __builtin_astype((x),  ushort8)
-#define as_ushort16(x) __builtin_astype((x), ushort16)
-
-#define as_int(x) __builtin_astype((x),   int)
-#define as_int2(x) __builtin_astype((x),  int2)
-#define as_int3(x) __builtin_astype((x),  int3)
-#define as_int4(x) __builtin_astype((x),  int4)
-#define as_int8(x) __builtin_astype((x),  int8)
-#define as_int16(x) __builtin_astype((x), int16)
-
-#define as_uint(x) __builtin_astype((x),   uint)
-#define as_uint2(x) __builtin_astype((x),  uint2)
-#define as_uint3(x) __builtin_astype((x),  uint3)
-#define as_uint4(x) __builtin_astype((x),  uint4)
-#define as_uint8(x) __builtin_astype((x),  uint8)
-#define as_uint16(x) __builtin_astype((x), uint16)
-
-#define as_long(x) __builtin_astype((x),   long)
-#define as_long2(x) __builtin_astype((x),  long2)
-#define as_long3(x) __builtin_astype((x),  long3)
-#define as_long4(x) __builtin_astype((x),  long4)
-#define as_long8(x) __builtin_astype((x),  long8)
-#define as_long16(x) __builtin_astype((x), long16)
-
-#define as_ulong(x) __builtin_astype((x),   ulong)
-#define as_ulong2(x) __builtin_astype((x),  ulong2)
-#define as_ulong3(x) __builtin_astype((x),  ulong3)
-#define as_ulong4(x) __builtin_astype((x),  ulong4)
-#define as_ulong8(x) __builtin_astype((x),  ulong8)
-#define as_ulong16(x) __builtin_astype((x), ulong16)
-
-#define as_float(x) __builtin_astype((x),   float)
-#define as_float2(x) __builtin_astype((x),  float2)
-#define as_float3(x) __builtin_astype((x),  float3)
-#define as_float4(x) __builtin_astype((x),  float4)
-#define as_float8(x) __builtin_astype((x),  float8)
-#define as_float16(x) __builtin_astype((x), float16)
-
-#ifdef cl_khr_fp64
-#define as_double(x) __builtin_astype((x),   double)
-#define as_double2(x) __builtin_astype((x),  double2)
-#define as_double3(x) __builtin_astype((x),  double3)
-#define as_double4(x) __builtin_astype((x),  double4)
-#define as_double8(x) __builtin_astype((x),  double8)
-#define as_double16(x) __builtin_astype((x), double16)
-#endif //cl_khr_fp64
-
-#ifdef cl_khr_fp16
-#define as_half(x) __builtin_astype((x),   half)
-#define as_half2(x) __builtin_astype((x),  half2)
-#define as_half3(x) __builtin_astype((x),  half3)
-#define as_half4(x) __builtin_astype((x),  half4)
-#define as_half8(x) __builtin_astype((x),  half8)
-#define as_half16(x) __builtin_astype((x), half16)
-#endif //cl_khr_fp16
-
-// OpenCL v1.1 s6.9, v1.2/2.0 s6.10 - Function qualifiers
-
-#define __kernel_exec(X, typen) __kernel \
-	__attribute__((work_group_size_hint(X, 1, 1))) \
-	__attribute__((vec_type_hint(typen)))
-
-#define kernel_exec(X, typen) __kernel \
-	__attribute__((work_group_size_hint(X, 1, 1))) \
-	__attribute__((vec_type_hint(typen)))
-
 // OpenCL v1.1 s6.11.1, v1.2 s6.12.1, v2.0 s6.13.1 - Work-item Functions
 
 /**
Index: clang/lib/Headers/opencl-c-base.h
=

[clang] 4bd08da - [flang][driver] Add debug dump options

[Faris Rehman via cfe-commits]

Author: Faris Rehman
Date: 2021-02-18T11:33:24Z
New Revision: 4bd08dab5ff99d094513f4adf4bf16bbce8f5a1f

URL: 
https://github.com/llvm/llvm-project/commit/4bd08dab5ff99d094513f4adf4bf16bbce8f5a1f
DIFF: 
https://github.com/llvm/llvm-project/commit/4bd08dab5ff99d094513f4adf4bf16bbce8f5a1f.diff

LOG: [flang][driver] Add debug dump options

Add the following options:
* -fdebug-dump-symbols
* -fdebug-dump-parse-tree
* -fdebug-dump-provenance

Summary of changes:
- Add 3 new frontend actions: DebugDumpSymbolsAction, DebugDumpParseTreeAction 
and DebugDumpProvenanceAction
- Add a unique pointer to the Semantics instance created in PrescanAndSemaAction
- Move fatal semantic error reporting to its own method, 
FrontendActions#reportFatalSemanticErrors
- Port most tests using `-fdebug-dump-symbols` and `-fdebug-dump-parse-tree` to 
the new driver if built, otherwise default to f18

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

Added: 
flang/test/Flang-Driver/debug-provenance.f90

Modified: 
clang/include/clang/Driver/Options.td
flang/include/flang/Frontend/FrontendActions.h
flang/include/flang/Frontend/FrontendOptions.h
flang/lib/Frontend/CompilerInvocation.cpp
flang/lib/Frontend/FrontendActions.cpp
flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
flang/test/Flang-Driver/driver-help.f90
flang/test/Semantics/data05.f90
flang/test/Semantics/data08.f90
flang/test/Semantics/data09.f90
flang/test/Semantics/offsets01.f90
flang/test/Semantics/offsets02.f90
flang/test/Semantics/offsets03.f90
flang/test/Semantics/resolve100.f90
flang/test/Semantics/rewrite01.f90

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 7312c1988efe..635af48cc051 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -4269,6 +4269,12 @@ def fdebug_unparse : Flag<["-"], "fdebug-unparse">, 
Group,
   HelpText<"Unparse and stop.">;
 def fdebug_unparse_with_symbols : Flag<["-"], "fdebug-unparse-with-symbols">, 
Group,
   HelpText<"Unparse and stop.">;
+def fdebug_dump_symbols : Flag<["-"], "fdebug-dump-symbols">, 
Group,
+  HelpText<"Dump symbols after the semantic analysis">;
+def fdebug_dump_parse_tree : Flag<["-"], "fdebug-dump-parse-tree">, 
Group,
+  HelpText<"Dump the parse tree">;
+def fdebug_dump_provenance : Flag<["-"], "fdebug-dump-provenance">, 
Group,
+  HelpText<"Dump provenance">;
 
 }
 

diff  --git a/flang/include/flang/Frontend/FrontendActions.h 
b/flang/include/flang/Frontend/FrontendActions.h
index 4c29d0d5a641..ebcb695cca72 100644
--- a/flang/include/flang/Frontend/FrontendActions.h
+++ b/flang/include/flang/Frontend/FrontendActions.h
@@ -10,6 +10,8 @@
 #define LLVM_FLANG_FRONTEND_FRONTENDACTIONS_H
 
 #include "flang/Frontend/FrontendAction.h"
+#include "flang/Semantics/semantics.h"
+#include 
 
 namespace Fortran::frontend {
 
@@ -37,12 +39,26 @@ class PrintPreprocessedAction : public PrescanAction {
   void ExecuteAction() override;
 };
 
+class DebugDumpProvenanceAction : public PrescanAction {
+  void ExecuteAction() override;
+};
+
 
//===--===//
 // PrescanAndSema Actions
 
//===--===//
 class PrescanAndSemaAction : public FrontendAction {
+  std::unique_ptr semantics_;
+
   void ExecuteAction() override = 0;
   bool BeginSourceFileAction(CompilerInstance &ci) override;
+
+public:
+  Fortran::semantics::Semantics &semantics() { return *semantics_; }
+  const Fortran::semantics::Semantics &semantics() const { return *semantics_; 
}
+
+  void setSemantics(std::unique_ptr semantics) {
+semantics_ = std::move(semantics);
+  }
 };
 
 class DebugUnparseWithSymbolsAction : public PrescanAndSemaAction {
@@ -53,6 +69,14 @@ class DebugUnparseAction : public PrescanAndSemaAction {
   void ExecuteAction() override;
 };
 
+class DebugDumpSymbolsAction : public PrescanAndSemaAction {
+  void ExecuteAction() override;
+};
+
+class DebugDumpParseTreeAction : public PrescanAndSemaAction {
+  void ExecuteAction() override;
+};
+
 class ParseSyntaxOnlyAction : public PrescanAndSemaAction {
   void ExecuteAction() override;
 };

diff  --git a/flang/include/flang/Frontend/FrontendOptions.h 
b/flang/include/flang/Frontend/FrontendOptions.h
index bcf59289d01d..a26e1e3d84c7 100644
--- a/flang/include/flang/Frontend/FrontendOptions.h
+++ b/flang/include/flang/Frontend/FrontendOptions.h
@@ -41,6 +41,15 @@ enum ActionKind {
   /// Fortran source file
   DebugUnparseWithSymbols,
 
+  /// Parse, run semantics and then output symbols from semantics
+  DebugDumpSymbols,
+
+  /// Parse, run semantics and then output the parse tree
+  DebugDumpParseTree,
+
+  /// Dump provenance
+  DebugDumpProvenance
+
   /// TODO: RunPreprocessor, EmitLLVM, EmitLLVMOnly,
   

[PATCH] D96716: [flang][driver] Add debug dump options

[Faris Rehman via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4bd08dab5ff9: [flang][driver] Add debug dump options 
(authored by FarisRehman).

Changed prior to commit:
  https://reviews.llvm.org/D96716?vs=324352&id=324586#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96716

Files:
  clang/include/clang/Driver/Options.td
  flang/include/flang/Frontend/FrontendActions.h
  flang/include/flang/Frontend/FrontendOptions.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  flang/test/Flang-Driver/debug-provenance.f90
  flang/test/Flang-Driver/driver-help.f90
  flang/test/Semantics/data05.f90
  flang/test/Semantics/data08.f90
  flang/test/Semantics/data09.f90
  flang/test/Semantics/offsets01.f90
  flang/test/Semantics/offsets02.f90
  flang/test/Semantics/offsets03.f90
  flang/test/Semantics/resolve100.f90
  flang/test/Semantics/rewrite01.f90

Index: flang/test/Semantics/rewrite01.f90
===
--- flang/test/Semantics/rewrite01.f90
+++ flang/test/Semantics/rewrite01.f90
@@ -1,4 +1,4 @@
-! RUN: %f18 -fdebug-dump-parse-tree %s 2>&1 | FileCheck %s
+! RUN: %flang_fc1 -fdebug-dump-parse-tree %s 2>&1 | FileCheck %s
 ! Ensure that READ(CVAR) [, item-list] is corrected when CVAR is a
 ! character variable so as to be a formatted read from the default
 ! unit, not an unformatted read from an internal unit (which is not
Index: flang/test/Semantics/resolve100.f90
===
--- flang/test/Semantics/resolve100.f90
+++ flang/test/Semantics/resolve100.f90
@@ -1,4 +1,4 @@
-!RUN: %f18 -fdebug-dump-symbols %s | FileCheck %s
+!RUN: %flang_fc1 -fdebug-dump-symbols %s | FileCheck %s
 
 program p
   ! CHECK: a size=4 offset=0: ObjectEntity type: LOGICAL(4)
Index: flang/test/Semantics/offsets03.f90
===
--- flang/test/Semantics/offsets03.f90
+++ flang/test/Semantics/offsets03.f90
@@ -1,4 +1,4 @@
-!RUN: %f18 -fdebug-dump-symbols %s | FileCheck %s
+!RUN: %flang_fc1 -fdebug-dump-symbols %s | FileCheck %s
 
 ! Size and alignment with EQUIVALENCE and COMMON
 
Index: flang/test/Semantics/offsets02.f90
===
--- flang/test/Semantics/offsets02.f90
+++ flang/test/Semantics/offsets02.f90
@@ -1,4 +1,4 @@
-!RUN: %f18 -fdebug-dump-symbols %s | FileCheck %s
+!RUN: %flang_fc1 -fdebug-dump-symbols %s | FileCheck %s
 
 ! Size and alignment of derived types
 
Index: flang/test/Semantics/offsets01.f90
===
--- flang/test/Semantics/offsets01.f90
+++ flang/test/Semantics/offsets01.f90
@@ -1,4 +1,4 @@
-!RUN: %f18 -fdebug-dump-symbols %s | FileCheck %s
+!RUN: %flang_fc1 -fdebug-dump-symbols %s | FileCheck %s
 
 ! Size and alignment of intrinsic types
 subroutine s1
Index: flang/test/Semantics/data09.f90
===
--- flang/test/Semantics/data09.f90
+++ flang/test/Semantics/data09.f90
@@ -1,4 +1,4 @@
-! RUN: %f18 -fsyntax-only -fdebug-dump-symbols %s 2>&1 | FileCheck %s
+! RUN: %flang_fc1 -fsyntax-only -fdebug-dump-symbols %s 2>&1 | FileCheck %s
 ! CHECK: init:[INTEGER(4)::1065353216_4,1073741824_4,1077936128_4,1082130432_4]
 ! Verify that the closure of EQUIVALENCE'd symbols with any DATA
 ! initialization produces a combined initializer.
Index: flang/test/Semantics/data08.f90
===
--- flang/test/Semantics/data08.f90
+++ flang/test/Semantics/data08.f90
@@ -1,4 +1,4 @@
-! RUN: %f18 -fdebug-dump-symbols %s 2>&1 | FileCheck %s
+! RUN: %flang_fc1 -fdebug-dump-symbols %s 2>&1 | FileCheck %s
 ! CHECK: DATA statement value initializes 'jx' of type 'INTEGER(4)' with CHARACTER
 ! CHECK: DATA statement value initializes 'jy' of type 'INTEGER(4)' with CHARACTER
 ! CHECK: DATA statement value initializes 'jz' of type 'INTEGER(4)' with CHARACTER
Index: flang/test/Semantics/data05.f90
===
--- flang/test/Semantics/data05.f90
+++ flang/test/Semantics/data05.f90
@@ -1,4 +1,4 @@
-!RUN: %f18 -fdebug-dump-symbols %s | FileCheck %s
+!RUN: %flang_fc1 -fdebug-dump-symbols %s | FileCheck %s
 module m
   interface
 integer function ifunc(n)
Index: flang/test/Flang-Driver/driver-help.f90
===
--- flang/test/Flang-Driver/driver-help.f90
+++ flang/test/Flang-Driver/driver-help.f90
@@ -56,6 +56,9 @@
 ! HELP-FC1-NEXT: -falternative-parameter-statement
 ! HELP-FC1-NEXT: Enable the old style PARAMETER statement
 ! HELP-FC1-NEXT: -fbackslashSpecify that backslash in stri

[PATCH] D96784: Pass the cmdline aapcs bitfield options to cc1

[Ties Stuij via Phabricator via cfe-commits]

stuij updated this revision to Diff 324589.
stuij added a comment.

added unit tests for the cmdline args


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96784

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/arm-aarch64-bitfield-flags.c


Index: clang/test/Driver/arm-aarch64-bitfield-flags.c
===
--- /dev/null
+++ clang/test/Driver/arm-aarch64-bitfield-flags.c
@@ -0,0 +1,18 @@
+// check -faapcs-bitfield-width/-fno-aapcs-bitfield-width
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main 
-faapcs-bitfield-width -### %s 2>&1 | FileCheck 
--check-prefixes=WIDTH,INVERSE-WIDTH %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main 
-faapcs-bitfield-width -### %s 2>&1 | FileCheck 
--check-prefixes=WIDTH,INVERSE-WIDTH %s
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main 
-fno-aapcs-bitfield-width -### %s 2>&1 | FileCheck 
--check-prefixes=NO-WIDTH,WIDTH %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main 
-fno-aapcs-bitfield-width -### %s 2>&1 | FileCheck 
--check-prefixes=NO-WIDTH,WIDTH %s
+// WIDTH-NOT: -faapcs-bitfield-width
+// NO-WIDTH: -fno-aapcs-bitfield-width
+
+// check -faapcs-bitfield-load
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main 
-faapcs-bitfield-load -### %s 2>&1 | FileCheck --check-prefix=LOAD %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main 
-faapcs-bitfield-load -### %s 2>&1 | FileCheck --check-prefix=LOAD %s
+// LOAD: -faapcs-bitfield-load
+
+// check absence of the above argument when not given
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main -### %s 2>&1 | 
FileCheck --check-prefixes=INVERSE-WIDTH,INVERSE-LOAD %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main -### %s 2>&1 
| FileCheck --check-prefixes=INVERSE-WIDTH,INVERSE-LOAD %s
+// INVERSE-WIDTH-NOT: -fno-aapcs-bitfield-width
+// INVERSE-LOAD-NOT: -fno-aapcs-bitfield-load
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -1522,6 +1522,15 @@
   }
 }
 
+void AddAAPCSVolatileBitfieldArgs(const ArgList &Args, ArgStringList &CmdArgs) 
{
+  if (!Args.hasFlag(options::OPT_faapcs_bitfield_width,
+options::OPT_fno_aapcs_bitfield_width, true))
+CmdArgs.push_back("-fno-aapcs-bitfield-width");
+
+  if (Args.getLastArg(options::OPT_ForceAAPCSBitfieldLoad))
+CmdArgs.push_back("-faapcs-bitfield-load");
+}
+
 namespace {
 void RenderARMABI(const llvm::Triple &Triple, const ArgList &Args,
   ArgStringList &CmdArgs) {
@@ -1580,6 +1589,8 @@
 
   if (Args.getLastArg(options::OPT_mcmse))
 CmdArgs.push_back("-mcmse");
+
+  AddAAPCSVolatileBitfieldArgs(Args, CmdArgs);
 }
 
 void Clang::RenderTargetOptions(const llvm::Triple &EffectiveTriple,
@@ -1768,6 +1779,8 @@
   D.Diag(diag::err_drv_unsupported_option_argument)
   << A->getOption().getName() << Val;
   }
+
+  AddAAPCSVolatileBitfieldArgs(Args, CmdArgs);
 }
 
 void Clang::AddMIPSTargetArgs(const ArgList &Args,


Index: clang/test/Driver/arm-aarch64-bitfield-flags.c
===
--- /dev/null
+++ clang/test/Driver/arm-aarch64-bitfield-flags.c
@@ -0,0 +1,18 @@
+// check -faapcs-bitfield-width/-fno-aapcs-bitfield-width
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main -faapcs-bitfield-width -### %s 2>&1 | FileCheck --check-prefixes=WIDTH,INVERSE-WIDTH %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main -faapcs-bitfield-width -### %s 2>&1 | FileCheck --check-prefixes=WIDTH,INVERSE-WIDTH %s
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main -fno-aapcs-bitfield-width -### %s 2>&1 | FileCheck --check-prefixes=NO-WIDTH,WIDTH %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main -fno-aapcs-bitfield-width -### %s 2>&1 | FileCheck --check-prefixes=NO-WIDTH,WIDTH %s
+// WIDTH-NOT: -faapcs-bitfield-width
+// NO-WIDTH: -fno-aapcs-bitfield-width
+
+// check -faapcs-bitfield-load
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main -faapcs-bitfield-load -### %s 2>&1 | FileCheck --check-prefix=LOAD %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main -faapcs-bitfield-load -### %s 2>&1 | FileCheck --check-prefix=LOAD %s
+// LOAD: -faapcs-bitfield-load
+
+// check absence of the above argument when not given
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main -### %s 2>&1 | FileCheck --check-prefixes=INVERSE-WIDTH,INVERSE-LOAD %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main -### %s 2>&1 | FileCheck --check-prefixes=INVERSE-WIDTH,INVERSE-LOAD %s
+// INVERSE-WIDTH-NOT: -fno-aapcs-bitfield-width
+// INVERSE-LOAD-NOT: -fno-aapcs-bitfield-load
Index: clang/lib/Driver/ToolChains/

[PATCH] D96784: Pass the cmdline aapcs bitfield options to cc1

[Ties Stuij via Phabricator via cfe-commits]

stuij added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:1525
 
+void AddAAPCSVolatileBitfieldArgs(const ArgList &Args, ArgStringList &CmdArgs) 
{
+  if (!Args.hasFlag(options::OPT_faapcs_bitfield_width,

DavidSpickett wrote:
> Name this AddARMAAPCSVolatileBitfieldArgs to match the other helpers.
I deliberately didn't add `ARM` to the name as this function is used by both 
the Arm and AArch64 targets, and `ARM` would cause confusion. I figured AAPCS 
is differentiating enough, as it implies Arm without choosing a specific arch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96784

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

[PATCH] D96884: [flang][driver] Add more -fdebug options

[Faris Rehman via Phabricator via cfe-commits]

FarisRehman updated this revision to Diff 324590.
FarisRehman added a comment.

Rebase off main

Rebase off main and add a comment to MeasurementVisitor.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96884

Files:
  clang/include/clang/Driver/Options.td
  flang/include/flang/Frontend/FrontendActions.h
  flang/include/flang/Frontend/FrontendOptions.h
  flang/lib/Frontend/CMakeLists.txt
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  flang/test/Flang-Driver/debug-measure-parse-tree.f90
  flang/test/Flang-Driver/debug-parsing-log.f90
  flang/test/Flang-Driver/driver-help.f90
  flang/test/Lower/pre-fir-tree01.f90
  flang/test/Lower/pre-fir-tree02.f90
  flang/test/Lower/pre-fir-tree03.f90
  flang/test/Lower/pre-fir-tree05.f90

Index: flang/test/Lower/pre-fir-tree05.f90
===
--- flang/test/Lower/pre-fir-tree05.f90
+++ flang/test/Lower/pre-fir-tree05.f90
@@ -1,4 +1,4 @@
-! RUN: %f18 -fdebug-pre-fir-tree -fsyntax-only -fopenacc %s | FileCheck %s
+! RUN: %flang_fc1 -fsyntax-only -fdebug-pre-fir-tree -fopenacc %s | FileCheck %s
 
 ! Test structure of the Pre-FIR tree with OpenACC construct
 
Index: flang/test/Lower/pre-fir-tree03.f90
===
--- flang/test/Lower/pre-fir-tree03.f90
+++ flang/test/Lower/pre-fir-tree03.f90
@@ -1,4 +1,4 @@
-! RUN: %f18 -fdebug-pre-fir-tree -fsyntax-only -fopenmp %s | FileCheck %s
+! RUN: %flang_fc1 -fsyntax-only -fdebug-pre-fir-tree -fopenmp %s | FileCheck %s
 
 ! Test Pre-FIR Tree captures OpenMP related constructs
 
Index: flang/test/Lower/pre-fir-tree02.f90
===
--- flang/test/Lower/pre-fir-tree02.f90
+++ flang/test/Lower/pre-fir-tree02.f90
@@ -1,4 +1,4 @@
-! RUN: %f18 -fdebug-pre-fir-tree -fsyntax-only %s | FileCheck %s
+! RUN: %flang_fc1 -fsyntax-only -fdebug-pre-fir-tree %s | FileCheck %s
 
 ! Test Pre-FIR Tree captures all the intended nodes from the parse-tree
 ! Coarray and OpenMP related nodes are tested in other files.
Index: flang/test/Lower/pre-fir-tree01.f90
===
--- flang/test/Lower/pre-fir-tree01.f90
+++ flang/test/Lower/pre-fir-tree01.f90
@@ -1,4 +1,4 @@
-! RUN: %f18 -fdebug-pre-fir-tree -fsyntax-only %s | FileCheck %s
+! RUN: %flang_fc1 -fsyntax-only -fdebug-pre-fir-tree %s | FileCheck %s
 
 ! Test structure of the Pre-FIR tree
 
Index: flang/test/Flang-Driver/driver-help.f90
===
--- flang/test/Flang-Driver/driver-help.f90
+++ flang/test/Flang-Driver/driver-help.f90
@@ -59,6 +59,10 @@
 ! HELP-FC1-NEXT: -fdebug-dump-parse-tree Dump the parse tree
 ! HELP-FC1-NEXT: -fdebug-dump-provenance Dump provenance
 ! HELP-FC1-NEXT: -fdebug-dump-symbolsDump symbols after the semantic analysis
+! HELP-FC1-NEXT: -fdebug-measure-parse-tree
+! HELP-FC1-NEXT: Measure the parse tree
+! HELP-FC1-NEXT: -fdebug-parsing-log Dump the parsing log
+! HELP-FC1-NEXT: -fdebug-pre-fir-treeDump the pre-FIR tree
 ! HELP-FC1-NEXT: -fdebug-unparse-with-symbols
 ! HELP-FC1-NEXT:Unparse and stop.
 ! HELP-FC1-NEXT: -fdebug-unparseUnparse and stop.
Index: flang/test/Flang-Driver/debug-parsing-log.f90
===
--- /dev/null
+++ flang/test/Flang-Driver/debug-parsing-log.f90
@@ -0,0 +1,25 @@
+! Ensure argument -fdebug-parsing-log works as expected.
+
+! REQUIRES: new-flang-driver
+
+!--
+! FLANG DRIVER (flang-new)
+!--
+! RUN: not %flang-new -fdebug-parsing-log %s  2>&1 | FileCheck %s --check-prefix=FLANG
+
+!
+! FRONTEND FLANG DRIVER (flang-new -fc1)
+!
+! RUN: %flang-new -fc1 -fdebug-parsing-log %s  2>&1 | FileCheck %s --check-prefix=FRONTEND
+
+!--
+! EXPECTED OUTPUT WITH `flang-new`
+!--
+! FLANG:warning: argument unused during compilation: '-fdebug-parsing-log'
+
+!---
+! EXPECTED OUTPUT WITH `flang-new -fc1`
+!---
+! FRONTEND:in the context: END PROGRAM statement
+
+INTEGER :: i = 1
Index: flang/test/Flang-Driver/debug-measure-parse-tree.f90
===
--- /dev/null
+++ flang/test/Flang-Driver/debug-measure-parse-tree.f90
@@ -0,0 +1,27 @@
+! Ensure argument -fdebug-measure-parse-tree works as expected.
+
+! REQUIRES: new-flang-driver
+
+!--
+! FLANG DRIVER (flang-new)
+!--
+! RUN: not %flang-new -fdebug-measure-parse-tree %s  2>&1 |

[PATCH] D96616: [OpenCL][Docs] Change decription for the OpenCL standard headers

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia updated this revision to Diff 324591.
Anastasia added a comment.

Added corrections from Sven.


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

https://reviews.llvm.org/D96616

Files:
  clang/docs/OpenCLSupport.rst
  clang/docs/UsersManual.rst

Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -2934,35 +2934,23 @@
 
 Some extra options are available to support special OpenCL features.
 
-.. option:: -finclude-default-header
+.. _opencl_cl_no_stdinc:
 
-Adds most of builtin types and function declarations during compilations. By
-default the OpenCL headers are not loaded and therefore certain builtin
-types and most of builtin functions are not declared. To load them
-automatically this flag can be passed to the frontend (see also :ref:`the
-section on the OpenCL Header `):
+.. option:: -cl-no-stdinc
 
-   .. code-block:: console
-
- $ clang -Xclang -finclude-default-header test.cl
-
-Note that this is a frontend-only flag and therefore it requires the use of
-flags that forward options to the frontend, e.g. ``-cc1`` or ``-Xclang``.
-
-Alternatively the internal header `opencl-c.h` containing the declarations
-can be included manually using ``-include`` or ``-I`` followed by the path
-to the header location. The header can be found in the clang source tree or
-installation directory.
+Allows to disable all extra types and functions that are not native to the compiler.
+This might reduce the compilation speed marginally but many declarations from the
+OpenCL standard will not be accessible. For example, the following will fail to
+compile.
 
.. code-block:: console
 
- $ clang -I/lib/Headers/opencl-c.h test.cl
- $ clang -I/lib/clang//include/opencl-c.h/opencl-c.h test.cl
-
-In this example it is assumed that the kernel code contains
-``#include `` just as a regular C include.
+ $ echo "bool is_wg_uniform(int i){return get_enqueued_local_size(i)==get_local_size(i);}" > test.cl
+ $ clang -cl-std=CL2.0 -cl-no-stdinc test.cl
+ error: use of undeclared identifier 'get_enqueued_local_size'
+ error: use of undeclared identifier 'get_local_size'
 
-More options are documented in :doc:`OpenCLSupport`.
+More information about the standard types and functions is provided in :ref:``.
 
 OpenCL Targets
 --
@@ -2999,11 +2987,8 @@
 
.. code-block:: console
 
-$ clang -cc1 -triple=spir test.cl
-$ clang -cc1 -triple=spir64 test.cl
-
-  Note that this is a frontend-only target and therefore it requires the use of
-  flags that forward options to the frontend e.g. ``-cc1`` or ``-Xclang``.
+$ clang -target spir test.cl -emit-llvm -c
+$ clang -target spir64 test.cl -emit-llvm -c
 
   All known OpenCL extensions are supported in the SPIR targets. Clang will
   generate SPIR v1.2 compatible IR for OpenCL versions up to 2.0 and SPIR v2.0
@@ -3026,31 +3011,17 @@
 OpenCL Header
 -
 
-By default Clang will not include standard headers and therefore OpenCL builtin
-functions and some types (i.e. vectors) are unknown during compilation. The
-default CL header is, however, provided in the Clang installation and can be
-enabled by passing the ``-finclude-default-header`` flag (see :ref:`flags
-description ` for more details).
+By default Clang will include standard headers and therefore most of OpenCL
+builtin functions and types are available during compilation. The
+default declarations of non-native compiler types and functions can be disabled
+by using flag :ref:``.
 
.. code-block:: console
 
  $ echo "bool is_wg_uniform(int i){return get_enqueued_local_size(i)==get_local_size(i);}" > test.cl
- $ clang -Xclang -finclude-default-header -cl-std=CL2.0 test.cl
-
-Because the header is very large and long to parse, PCH (:doc:`PCHInternals`)
-and modules (:doc:`Modules`) are used internally to improve the compilation
-speed.
-
-To enable modules for OpenCL:
-
-   .. code-block:: console
-
- $ clang -target spir-unknown-unknown -c -emit-llvm -Xclang -finclude-default-header -fmodules -fimplicit-module-maps -fmodules-cache-path= test.cl
+ $ clang -cl-std=CL2.0 test.cl
 
-Another way to circumvent long parsing latency for the OpenCL builtin
-declarations is to use mechanism enabled by ``-fdeclare-opencl-builtins`` flag
-that is available as an experimental feature (see more information in
-:doc:`OpenCLSupport`).
+More information about the default headers is provided in :doc:`OpenCLSupport`.
 
 OpenCL Extensions
 -
Index: clang/docs/OpenCLSupport.rst
===
--- clang/docs/OpenCLSupport.rst
+++ clang/docs/OpenCLSupport.rst
@@ -63,6 +63,10 @@
 In addition to the options described in :doc:`UsersManual` there are the
 following options specific to the OpenCL frontend.
 
+All the options in this section are frontend-only and therefore

[PATCH] D96616: [OpenCL][Docs] Change decription for the OpenCL standard headers

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added inline comments.



Comment at: clang/docs/UsersManual.rst:3016
 
.. code-block:: console
 

svenvh wrote:
> I wonder if we need to keep this example?  You're not referring to it from 
> the text and it's not demonstrating any special flags anymore.
it's still demonstrating the use of default clang driver invocation i.e. there 
are no flags needed to compile the code that uses BIFs.


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

https://reviews.llvm.org/D96616

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

[PATCH] D96906: [AMDGPU] gfx90a support

[Stanislav Mekhanoshin via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGa8d9d50762c4: [AMDGPU] gfx90a support (authored by rampitec).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D96906?vs=324434&id=324456#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96906

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Basic/BuiltinsAMDGPU.def
  clang/include/clang/Basic/Cuda.h
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Cuda.cpp
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/test/CodeGenOpenCL/amdgpu-features.cl
  clang/test/CodeGenOpenCL/builtins-amdgcn-mfma.cl
  clang/test/Driver/amdgpu-features.c
  clang/test/Driver/amdgpu-macros.cl
  clang/test/Driver/amdgpu-mcpu.cl
  clang/test/Driver/cuda-bad-arch.cu
  clang/test/Driver/hip-toolchain-features.hip
  clang/test/Misc/target-invalid-cpu-note.c
  clang/test/SemaOpenCL/builtins-amdgcn-error-gfx90a-param.cl
  llvm/docs/AMDGPUUsage.rst
  llvm/include/llvm/BinaryFormat/ELF.h
  llvm/include/llvm/IR/IntrinsicsAMDGPU.td
  llvm/include/llvm/Support/AMDHSAKernelDescriptor.h
  llvm/include/llvm/Support/TargetParser.h
  llvm/lib/Object/ELFObjectFile.cpp
  llvm/lib/ObjectYAML/ELFYAML.cpp
  llvm/lib/Support/TargetParser.cpp
  llvm/lib/Target/AMDGPU/AMDGPU.td
  llvm/lib/Target/AMDGPU/AMDGPUArgumentUsageInfo.h
  llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp
  llvm/lib/Target/AMDGPU/AMDGPUCallingConv.td
  llvm/lib/Target/AMDGPU/AMDGPUGISel.td
  llvm/lib/Target/AMDGPU/AMDGPUISelDAGToDAG.cpp
  llvm/lib/Target/AMDGPU/AMDGPUISelLowering.cpp
  llvm/lib/Target/AMDGPU/AMDGPUISelLowering.h
  llvm/lib/Target/AMDGPU/AMDGPUInstructionSelector.cpp
  llvm/lib/Target/AMDGPU/AMDGPUInstructionSelector.h
  llvm/lib/Target/AMDGPU/AMDGPULegalizerInfo.cpp
  llvm/lib/Target/AMDGPU/AMDGPURegisterBankInfo.cpp
  llvm/lib/Target/AMDGPU/AMDGPUSearchableTables.td
  llvm/lib/Target/AMDGPU/AMDGPUSubtarget.cpp
  llvm/lib/Target/AMDGPU/AMDGPUSubtarget.h
  llvm/lib/Target/AMDGPU/AMDGPUTargetTransformInfo.cpp
  llvm/lib/Target/AMDGPU/AsmParser/AMDGPUAsmParser.cpp
  llvm/lib/Target/AMDGPU/BUFInstructions.td
  llvm/lib/Target/AMDGPU/DSInstructions.td
  llvm/lib/Target/AMDGPU/Disassembler/AMDGPUDisassembler.cpp
  llvm/lib/Target/AMDGPU/Disassembler/AMDGPUDisassembler.h
  llvm/lib/Target/AMDGPU/FLATInstructions.td
  llvm/lib/Target/AMDGPU/GCNDPPCombine.cpp
  llvm/lib/Target/AMDGPU/GCNHazardRecognizer.cpp
  llvm/lib/Target/AMDGPU/GCNHazardRecognizer.h
  llvm/lib/Target/AMDGPU/GCNProcessors.td
  llvm/lib/Target/AMDGPU/GCNRegPressure.cpp
  llvm/lib/Target/AMDGPU/GCNRegPressure.h
  llvm/lib/Target/AMDGPU/GCNSchedStrategy.cpp
  llvm/lib/Target/AMDGPU/GCNSubtarget.h
  llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUInstPrinter.cpp
  llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUInstPrinter.h
  llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp
  llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.h
  llvm/lib/Target/AMDGPU/MCTargetDesc/SIMCCodeEmitter.cpp
  llvm/lib/Target/AMDGPU/MIMGInstructions.td
  llvm/lib/Target/AMDGPU/SIAddIMGInit.cpp
  llvm/lib/Target/AMDGPU/SIDefines.h
  llvm/lib/Target/AMDGPU/SIFoldOperands.cpp
  llvm/lib/Target/AMDGPU/SIFormMemoryClauses.cpp
  llvm/lib/Target/AMDGPU/SIFrameLowering.cpp
  llvm/lib/Target/AMDGPU/SIISelLowering.cpp
  llvm/lib/Target/AMDGPU/SIInsertWaitcnts.cpp
  llvm/lib/Target/AMDGPU/SIInstrFormats.td
  llvm/lib/Target/AMDGPU/SIInstrInfo.cpp
  llvm/lib/Target/AMDGPU/SIInstrInfo.h
  llvm/lib/Target/AMDGPU/SIInstrInfo.td
  llvm/lib/Target/AMDGPU/SIInstructions.td
  llvm/lib/Target/AMDGPU/SILoadStoreOptimizer.cpp
  llvm/lib/Target/AMDGPU/SIMemoryLegalizer.cpp
  llvm/lib/Target/AMDGPU/SIProgramInfo.h
  llvm/lib/Target/AMDGPU/SIRegisterInfo.cpp
  llvm/lib/Target/AMDGPU/SIRegisterInfo.h
  llvm/lib/Target/AMDGPU/SIRegisterInfo.td
  llvm/lib/Target/AMDGPU/SISchedule.td
  llvm/lib/Target/AMDGPU/SIWholeQuadMode.cpp
  llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp
  llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.h
  llvm/lib/Target/AMDGPU/VOP1Instructions.td
  llvm/lib/Target/AMDGPU/VOP2Instructions.td
  llvm/lib/Target/AMDGPU/VOP3Instructions.td
  llvm/lib/Target/AMDGPU/VOP3PInstructions.td
  llvm/lib/Target/AMDGPU/VOPInstructions.td
  llvm/test/Analysis/CostModel/AMDGPU/fadd.ll
  llvm/test/Analysis/CostModel/AMDGPU/fma.ll
  llvm/test/Analysis/CostModel/AMDGPU/fmul.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/fp64-atomics-gfx90a.ll
  llvm/test/CodeGen/AMDGPU/GlobalISel/inst-select-amdgpu-atomic-cmpxchg-flat.mir
  
llvm/test/CodeGen/AMDGPU/GlobalISel/inst-select-amdgpu-atomic-cmpxchg-global.mir
  llvm/test/CodeGen/AMDGPU/GlobalISel/inst-select-atomicrmw-add-flat.mir
  llvm/test/CodeGen/AMDGPU/GlobalISel/inst-select-atomicrmw-add-global.mir
  llvm/test/CodeGen/AMDGPU/GlobalISel/inst-select-copy.mir
 

[PATCH] D96906: [AMDGPU] gfx90a support

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

This is a pretty huge patch, with no details in the commit log.

One hour between sending the patch out and landing it is not sufficient for 
anyone to meaningfully 
review the patch and there are no mentions of the review done anywhere else.

While the code only changes AMDGPU back-end, it does not mean that the patch 
should be just rubber-stamped.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96906

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

[PATCH] D96906: [AMDGPU] gfx90a support

[Stanislav Mekhanoshin via Phabricator via cfe-commits]

rampitec added a comment.

In D96906#2570086 , @tra wrote:

> This is a pretty huge patch, with no details in the commit log.
>
> One hour between sending the patch out and landing it is not sufficient for 
> anyone to meaningfully 
> review the patch and there are no mentions of the review done anywhere else.
>
> While the code only changes AMDGPU back-end, it does not mean that the patch 
> should be just rubber-stamped.

It's a year of work necessarily downstream. Every line there was reviewed and 
tested in the downstream. I understand no one can reasonably review something 
that big, although I cannot break it into small patches after a year of changes 
and fixes. Not that I have too much choice.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96906

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

[PATCH] D96906: [AMDGPU] gfx90a support

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D96906#2570095 , @rampitec wrote:

> It's a year of work necessarily downstream. Every line there was reviewed and 
> tested in the downstream. I understand no one can reasonably review something 
> that big, although I cannot break it into small patches after a year of 
> changes and fixes. Not that I have too much choice.

The point is that nobody upstream even got a chance to chime in.

According to https://llvm.org/docs/CodeReview.html

> We expect significant patches to be reviewed before being committed.

This patch certainly qualifies as significant.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96906

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

[PATCH] D92715: [Clang][RISCV] Define RISC-V V builtin types

[Hsiangkai Wang via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG766ee1096f0b: [Clang][RISCV] Define RISC-V V builtin types 
(authored by HsiangKai).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92715

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Basic/RISCVVTypes.def
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/module.modulemap
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/AST/NSAPI.cpp
  clang/lib/AST/PrintfFormatString.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/RISCV.h
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/Index/USRGeneration.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/test/CodeGen/RISCV/riscv-v-debuginfo.c
  clang/test/Sema/riscv-types.c
  clang/tools/libclang/CIndex.cpp

Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -1548,6 +1548,8 @@
 #include "clang/Basic/AArch64SVEACLETypes.def"
 #define PPC_VECTOR_TYPE(Name, Id, Size) case BuiltinType::Id:
 #include "clang/Basic/PPCTypes.def"
+#define RVV_TYPE(Name, Id, SingletonId) case BuiltinType::Id:
+#include "clang/Basic/RISCVVTypes.def"
 #define BUILTIN_TYPE(Id, SingletonId)
 #define SIGNED_TYPE(Id, SingletonId) case BuiltinType::Id:
 #define UNSIGNED_TYPE(Id, SingletonId) case BuiltinType::Id:
Index: clang/test/Sema/riscv-types.c
===
--- /dev/null
+++ clang/test/Sema/riscv-types.c
@@ -0,0 +1,136 @@
+// RUN: %clang_cc1 -triple riscv64 -target-feature +experimental-v -ast-print %s \
+// RUN:| FileCheck %s
+
+void bar(void) {
+  // CHECK: __rvv_int64m1_t x0;
+  __rvv_int64m1_t x0;
+
+  // CHECK: __rvv_float64m1_t x1;
+  __rvv_float64m1_t x1;
+
+  // CHECK: __rvv_int64m2_t x2;
+  __rvv_int64m2_t x2;
+
+  // CHECK: __rvv_float64m2_t x3;
+  __rvv_float64m2_t x3;
+
+  // CHECK: __rvv_int64m4_t x4;
+  __rvv_int64m4_t x4;
+
+  // CHECK: __rvv_float64m4_t x5;
+  __rvv_float64m4_t x5;
+
+  // CHECK: __rvv_int64m8_t x6;
+  __rvv_int64m8_t x6;
+
+  // CHECK: __rvv_float64m8_t x7;
+  __rvv_float64m8_t x7;
+
+  // CHECK: __rvv_int32m1_t x8;
+  __rvv_int32m1_t x8;
+
+  // CHECK: __rvv_float32m1_t x9;
+  __rvv_float32m1_t x9;
+
+  // CHECK: __rvv_int32m2_t x10;
+  __rvv_int32m2_t x10;
+
+  // CHECK: __rvv_float32m2_t x11;
+  __rvv_float32m2_t x11;
+
+  // CHECK: __rvv_int32m4_t x12;
+  __rvv_int32m4_t x12;
+
+  // CHECK: __rvv_float32m4_t x13;
+  __rvv_float32m4_t x13;
+
+  // CHECK: __rvv_int32m8_t x14;
+  __rvv_int32m8_t x14;
+
+  // CHECK: __rvv_float32m8_t x15;
+  __rvv_float32m8_t x15;
+
+  // CHECK: __rvv_int16m1_t x16;
+  __rvv_int16m1_t x16;
+
+  // CHECK: __rvv_float16m1_t x17;
+  __rvv_float16m1_t x17;
+
+  // CHECK: __rvv_int16m2_t x18;
+  __rvv_int16m2_t x18;
+
+  // CHECK: __rvv_float16m2_t x19;
+  __rvv_float16m2_t x19;
+
+  // CHECK: __rvv_int16m4_t x20;
+  __rvv_int16m4_t x20;
+
+  // CHECK: __rvv_float16m4_t x21;
+  __rvv_float16m4_t x21;
+
+  // CHECK: __rvv_int16m8_t x22;
+  __rvv_int16m8_t x22;
+
+  // CHECK: __rvv_float16m8_t x23;
+  __rvv_float16m8_t x23;
+
+  // CHECK: __rvv_int8m1_t x24;
+  __rvv_int8m1_t x24;
+
+  // CHECK: __rvv_int8m2_t x25;
+  __rvv_int8m2_t x25;
+
+  // CHECK: __rvv_int8m4_t x26;
+  __rvv_int8m4_t x26;
+
+  // CHECK: __rvv_int8m8_t x27;
+  __rvv_int8m8_t x27;
+
+  // CHECK: __rvv_bool64_t x28;
+  __rvv_bool64_t x28;
+
+  // CHECK: __rvv_bool32_t x29;
+  __rvv_bool32_t x29;
+
+  // CHECK: __rvv_bool16_t x30;
+  __rvv_bool16_t x30;
+
+  // CHECK: __rvv_bool8_t x31;
+  __rvv_bool8_t x31;
+
+  // CHECK: __rvv_bool8_t x32;
+  __rvv_bool8_t x32;
+
+  // CHECK: __rvv_bool8_t x33;
+  __rvv_bool8_t x33;
+
+  // CHECK: __rvv_bool8_t x34;
+  __rvv_bool8_t x34;
+
+  // CHECK: __rvv_int32mf2_t x35;
+  __rvv_int32mf2_t x35;
+
+  // CHECK: __rvv_float32mf2_t x36;
+  __rvv_float32mf2_t x36;
+
+  // CHECK: __rvv_int16mf4_t x37;
+  __rvv_int16mf4_t x37;
+
+  // CHECK: __rvv_float16mf4_t x38;
+  __rvv_float16mf4_t x38;
+
+  // CHECK: __rvv_int16mf2_t x39;
+  __rvv_int16mf2_t x39;
+
+  // CHECK: __rvv_float16mf2_t x40;
+  __rvv_float16mf2_t x40;
+
+  // CHECK: __rvv_int8mf8_t x41;
+  __rvv_int8mf8_t x41;
+
+  // CHECK: __rvv_int8mf4_t x42;
+  __rvv_int8mf4_t x42;
+
+  // CHECK: __rvv_int8mf2_t x43;
+  __rvv_int8mf2_t x43;
+}
Ind

[PATCH] D96884: [flang][driver] Add more -fdebug options

[Andrzej Warzynski via Phabricator via cfe-commits]

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

Thank you for working on this @FarisRehman !

This semantics implemented here are identical to what `f18` does. 
`-fdebug-instrumented-parse` from `f18` becomes `-fdebug-parsing-log` in 
`flang-new -fc1`. This was proposed (and accepted) in the RFC 
.

I've left a few comments inline, but nothing major and otherwise this is ready 
to land.




Comment at: flang/include/flang/Frontend/FrontendActions.h:18
 
+struct MeasurementVisitor {
+  template  bool Pre(const A &) { return true; }

This should be shared with `f18.cpp`, but currently we don't have a good place 
for that (and we probably want to understand how much is going to be shared 
first). So IMO it is fine to keep it here.

Could you add a comment similar to [[ 
https://github.com/llvm/llvm-project/blob/adfd3c7083f9808d145239153c10f72eece485d8/flang/lib/Frontend/FrontendOptions.cpp#L29-L32
 | this ]] so that it is clear that this should be moved at some point?



Comment at: flang/lib/Frontend/FrontendActions.cpp:313
+  } else {
+llvm::errs() << "Pre FIR Tree is NULL.\n";
+  }

Could this use diagnostics instead? For example:
```
unsigned diagID = 
ci.diagnostics().getCustomDiagID(clang::DiagnosticsEngine::Error, "Pre FIR Tree 
is NULL.");
ci.diagnostics().Report(diagID);
```



Comment at: flang/test/Flang-Driver/debug-measure-parse-tree.f90:23-24
+!---
+! FRONTEND:18 objects
+! FRONTEND:1496 total bytes
+

The output for this test is:
```
Parse tree comprises 18 objects and occupies 1496 total bytes.
```
I think that the actual size (i.e. 18 and 1496) is not that relevant here and 
also prone to change (which may cause the test to become fragile). 

Instead, I suggest that we verify that `-fdebug-measure-parse-tree`  indeed 
instructs the driver to measure the parse and print the result. So, perhaps 
this instead:
```
Parse tree comprises {{[0-9]+}} objects and occupies {{[0-9]+}} total bytes.
```



Comment at: flang/test/Flang-Driver/debug-parsing-log.f90:23
+!---
+! FRONTEND:in the context: END PROGRAM statement
+

IIUC, this output is not really specific to `-fdebug-parsing-log` 
(`-fsyntax-only` prints this too). I think that this would be more specific to 
this flag:
```
! FRONTEN: fail 1
! FRONTEN: fail 2
! FRONTEN: fail 3
```
This is still not great, but looking at the log itself I struggle to notice 
anything that would stand out.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96884

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

[PATCH] D96719: [clang-tidy] Add new check 'bugprone-thread-canceltype-asynchronous' and alias 'cert-pos47-c'.

[Balázs Kéri via Phabricator via cfe-commits]

balazske updated this revision to Diff 324592.
balazske added a comment.

Moving to module `concurrency` from `bugprone`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96719

Files:
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/clang-tidy/cert/CMakeLists.txt
  clang-tools-extra/clang-tidy/concurrency/CMakeLists.txt
  clang-tools-extra/clang-tidy/concurrency/ConcurrencyTidyModule.cpp
  clang-tools-extra/clang-tidy/concurrency/ThreadCanceltypeAsynchronousCheck.cpp
  clang-tools-extra/clang-tidy/concurrency/ThreadCanceltypeAsynchronousCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-pos47-c.rst
  
clang-tools-extra/docs/clang-tidy/checks/concurrency-thread-canceltype-asynchronous.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/concurrency-thread-canceltype-asynchronous.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/concurrency-thread-canceltype-asynchronous.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/concurrency-thread-canceltype-asynchronous.cpp
@@ -0,0 +1,32 @@
+// RUN: %check_clang_tidy %s concurrency-thread-canceltype-asynchronous %t
+
+#define PTHREAD_CANCEL_DEFERRED 0
+#define PTHREAD_CANCEL_ASYNCHRONOUS 1
+
+int pthread_setcanceltype(int type, int *oldtype);
+
+int main() {
+  int result, oldtype;
+
+  if ((result = pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, &oldtype)) != 0) {
+// CHECK-MESSAGES: :[[@LINE-1]]:17: warning: asynchronous cancelability type should not be used [concurrency-thread-canceltype-asynchronous]
+return 1;
+  }
+
+  if ((result = pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, &oldtype)) != 0) {
+return 1;
+  }
+
+  return 0;
+}
+
+int f() {
+  int result, oldtype;
+
+  if ((result = pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, &oldtype)) != 0) {
+// CHECK-MESSAGES: :[[@LINE-1]]:17: warning: asynchronous cancelability type should not be used [concurrency-thread-canceltype-asynchronous]
+return 1;
+  }
+
+  return 0;
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -95,6 +95,7 @@
`bugprone-suspicious-string-compare `_, "Yes"
`bugprone-swapped-arguments `_, "Yes"
`bugprone-terminating-continue `_, "Yes"
+   `bugprone-thread-canceltype-asynchronous `_, "No"
`bugprone-throw-keyword-missing `_,
`bugprone-too-small-loop-variable `_,
`bugprone-undefined-memory-manipulation `_,
@@ -334,6 +335,7 @@
`cert-oop11-cpp `_, `performance-move-constructor-init `_, "Yes"
`cert-oop54-cpp `_, `bugprone-unhandled-self-assignment `_,
`cert-pos44-c `_, `bugprone-bad-signal-to-kill-thread `_,
+   `cert-pos47-c `_, `bugprone-thread-canceltype-asynchronous `_,
`cert-str34-c `_, `bugprone-signed-char-misuse `_,
`clang-analyzer-core.CallAndMessage `_, `Clang Static Analyzer `_,
`clang-analyzer-core.DivideZero `_, `Clang Static Analyzer `_,
Index: clang-tools-extra/docs/clang-tidy/checks/concurrency-thread-canceltype-asynchronous.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/concurrency-thread-canceltype-asynchronous.rst
@@ -0,0 +1,19 @@
+.. title:: clang-tidy - concurrency-thread-canceltype-asynchronous
+
+concurrency-thread-canceltype-asynchronous
+==
+
+Finds ``pthread_setcanceltype`` function calls where a thread's cancellation
+type is set to asynchronous. Asynchronous cancellation type
+(``PTHREAD_CANCEL_ASYNCHRONOUS``) is generally unsafe, use type
+``PTHREAD_CANCEL_DEFERRED`` instead which is the default. Even with deferred
+cancellation, a cancellation point in an asynchronous signal handler may still
+be acted upon and the effect is as if it was an asynchronous cancellation.
+
+.. code-block: c++
+
+  pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, &oldtype);
+
+This check corresponds to the CERT C Coding Standard rule
+`POS47-C. Do not use threads that can be canceled asynchronously
+`_.
Index: clang-tools-extra/docs/clang-tidy/checks/cert-pos47-c.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/cert-pos47-c.rst
@@ -0,0 +1,9 @@
+.. title:: clang-tidy - cert-pos47-c
+.. meta::
+   :http-equiv=refresh: 5;URL=concurrency-thread-canceltype-asynchronous.html
+
+cert-pos47-c
+
+
+The cert-pos47-c chec

[PATCH] D89870: [clangd] Drop template argument lists from completions followed by

[Kirill Bobyrev via Phabricator via cfe-commits]

kbobyrev updated this revision to Diff 324593.
kbobyrev marked 4 inline comments as done.
kbobyrev added a comment.

Address review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89870

Files:
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -3114,10 +3114,13 @@
   Contains(AllOf(Labeled("Container(int Size)"),
  SnippetSuffix("<${1:typename T}>(${2:int Size})"),
  Kind(CompletionItemKind::Constructor;
-  // FIXME(kirillbobyrev): It would be nice to still produce the template
-  // snippet part: in this case it should be "<${1:typename T}>".
   EXPECT_THAT(
   completions(Context + "Container c = Cont^()", {}, Opts).Completions,
+  Contains(AllOf(Labeled("Container(int Size)"),
+ SnippetSuffix("<${1:typename T}>"),
+ Kind(CompletionItemKind::Constructor;
+  EXPECT_THAT(
+  completions(Context + "Container c = Cont^()", {}, 
Opts).Completions,
   Contains(AllOf(Labeled("Container(int Size)"),
  SnippetSuffix(""),
  Kind(CompletionItemKind::Constructor;
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -452,18 +452,52 @@
   std::string summarizeSnippet() const {
 if (IsUsingDeclaration)
   return "";
-// Suppress function argument snippets if args are already present.
-if ((Completion.Kind == CompletionItemKind::Function ||
- Completion.Kind == CompletionItemKind::Method ||
- Completion.Kind == CompletionItemKind::Constructor) &&
-NextTokenKind == tok::l_paren)
-  return "";
 auto *Snippet = onlyValue<&BundledEntry::SnippetSuffix>();
 if (!Snippet)
   // All bundles are function calls.
   // FIXME(ibiryukov): sometimes add template arguments to a snippet, e.g.
   // we need to complete 'forward<$1>($0)'.
   return "($0)";
+// Suppress function argument snippets cursor is followed by left
+// parenthesis (and potentially arguments) or if there are potentially
+// template arguments. There are cases where it would be wrong (e.g. next
+// '<' token is a comparison rather than template argument list start) but
+// it is less common and suppressing snippet provides better UX.
+if (Completion.Kind == CompletionItemKind::Function ||
+Completion.Kind == CompletionItemKind::Method ||
+Completion.Kind == CompletionItemKind::Constructor) {
+  // If there is a potential template argument list, drop snippet and just
+  // complete symbol name. Ideally, this could generate an edit that would
+  // paste function arguments after template argument list but it would be
+  // complicated. Example:
+  //
+  // fu^ -> function
+  if (NextTokenKind == tok::less && Snippet->front() == '<')
+return "";
+  // Potentially followed by argument list.
+  if (NextTokenKind == tok::l_paren) {
+// If snippet contains template arguments we will emit them and drop
+// function arguments. Example:
+//
+// fu^(42) -> function(42);
+if (Snippet->front() == '<') {
+  // Find matching '>'. Snippet->find('>') will not work in cases like
+  // template >. Hence, iterate through
+  // the snippet until the angle bracket balance reaches zero.
+  int Balance = 0;
+  size_t I = 0;
+  do {
+if (Snippet->at(I) == '>')
+  --Balance;
+else if (Snippet->at(I) == '<')
+  ++Balance;
+++I;
+  } while (Balance > 0);
+  return Snippet->substr(0, I);
+}
+return "";
+  }
+}
 if (EnableFunctionArgSnippets)
   return *Snippet;
 


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -3114,10 +3114,13 @@
   Contains(AllOf(Labeled("Container(int Size)"),
  SnippetSuffix("<${1:typename T}>(${2:int Size})"),
  Kind(CompletionItemKind::Constructor;
-  // FIXME(kirillbobyrev): It would be nice to still produce the template
-  // snippet part: in this case it should be "<${1:typename T}>".
   EXPECT_THAT(
   completions(Context + "Container c = Cont^()", {}, Opts).Complet

[clang-tools-extra] 19db870 - [clangd] Drop template argument lists from completions followed by

[Kirill Bobyrev via cfe-commits]

Author: Kirill Bobyrev
Date: 2021-02-18T13:06:11+01:00
New Revision: 19db870a0dd1416b2d4a346e2cb17be197193a94

URL: 
https://github.com/llvm/llvm-project/commit/19db870a0dd1416b2d4a346e2cb17be197193a94
DIFF: 
https://github.com/llvm/llvm-project/commit/19db870a0dd1416b2d4a346e2cb17be197193a94.diff

LOG: [clangd] Drop template argument lists from completions followed by <

Now, given `template  foo() {}` when user types `fo^()` the
completion snippet will not contain `()`.

Also, when the next token is opening parenthesis (`(`) and completion snippet
contains template argument list, it is still emitted.

This patch complements D81380.

Related issue: https://github.com/clangd/clangd/issues/387

Reviewed By: kadircet

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

Added: 


Modified: 
clang-tools-extra/clangd/CodeComplete.cpp
clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/CodeComplete.cpp 
b/clang-tools-extra/clangd/CodeComplete.cpp
index 1d1027319dfb..e0bfd120c1b0 100644
--- a/clang-tools-extra/clangd/CodeComplete.cpp
+++ b/clang-tools-extra/clangd/CodeComplete.cpp
@@ -452,18 +452,52 @@ struct CodeCompletionBuilder {
   std::string summarizeSnippet() const {
 if (IsUsingDeclaration)
   return "";
-// Suppress function argument snippets if args are already present.
-if ((Completion.Kind == CompletionItemKind::Function ||
- Completion.Kind == CompletionItemKind::Method ||
- Completion.Kind == CompletionItemKind::Constructor) &&
-NextTokenKind == tok::l_paren)
-  return "";
 auto *Snippet = onlyValue<&BundledEntry::SnippetSuffix>();
 if (!Snippet)
   // All bundles are function calls.
   // FIXME(ibiryukov): sometimes add template arguments to a snippet, e.g.
   // we need to complete 'forward<$1>($0)'.
   return "($0)";
+// Suppress function argument snippets cursor is followed by left
+// parenthesis (and potentially arguments) or if there are potentially
+// template arguments. There are cases where it would be wrong (e.g. next
+// '<' token is a comparison rather than template argument list start) but
+// it is less common and suppressing snippet provides better UX.
+if (Completion.Kind == CompletionItemKind::Function ||
+Completion.Kind == CompletionItemKind::Method ||
+Completion.Kind == CompletionItemKind::Constructor) {
+  // If there is a potential template argument list, drop snippet and just
+  // complete symbol name. Ideally, this could generate an edit that would
+  // paste function arguments after template argument list but it would be
+  // complicated. Example:
+  //
+  // fu^ -> function
+  if (NextTokenKind == tok::less && Snippet->front() == '<')
+return "";
+  // Potentially followed by argument list.
+  if (NextTokenKind == tok::l_paren) {
+// If snippet contains template arguments we will emit them and drop
+// function arguments. Example:
+//
+// fu^(42) -> function(42);
+if (Snippet->front() == '<') {
+  // Find matching '>'. Snippet->find('>') will not work in cases like
+  // template >. Hence, iterate through
+  // the snippet until the angle bracket balance reaches zero.
+  int Balance = 0;
+  size_t I = 0;
+  do {
+if (Snippet->at(I) == '>')
+  --Balance;
+else if (Snippet->at(I) == '<')
+  ++Balance;
+++I;
+  } while (Balance > 0);
+  return Snippet->substr(0, I);
+}
+return "";
+  }
+}
 if (EnableFunctionArgSnippets)
   return *Snippet;
 

diff  --git a/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp 
b/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
index 9403cda57cfe..b7a40179aa98 100644
--- a/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ b/clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -3114,10 +3114,13 @@ TEST(CompletionTest, FunctionArgsExist) {
   Contains(AllOf(Labeled("Container(int Size)"),
  SnippetSuffix("<${1:typename T}>(${2:int Size})"),
  Kind(CompletionItemKind::Constructor;
-  // FIXME(kirillbobyrev): It would be nice to still produce the template
-  // snippet part: in this case it should be "<${1:typename T}>".
   EXPECT_THAT(
   completions(Context + "Container c = Cont^()", {}, Opts).Completions,
+  Contains(AllOf(Labeled("Container(int Size)"),
+ SnippetSuffix("<${1:typename T}>"),
+ Kind(CompletionItemKind::Constructor;
+  EXPECT_THAT(
+  completions(Context + "Container c = Cont^()", {}, 
Opts).Completions,
   Contains(AllOf(Labeled("Container(int Size)"),
  SnippetSuffix("")

[PATCH] D89870: [clangd] Drop template argument lists from completions followed by

[Kirill Bobyrev via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG19db870a0dd1: [clangd] Drop template argument lists from 
completions followed by < (authored by kbobyrev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89870

Files:
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -3114,10 +3114,13 @@
   Contains(AllOf(Labeled("Container(int Size)"),
  SnippetSuffix("<${1:typename T}>(${2:int Size})"),
  Kind(CompletionItemKind::Constructor;
-  // FIXME(kirillbobyrev): It would be nice to still produce the template
-  // snippet part: in this case it should be "<${1:typename T}>".
   EXPECT_THAT(
   completions(Context + "Container c = Cont^()", {}, Opts).Completions,
+  Contains(AllOf(Labeled("Container(int Size)"),
+ SnippetSuffix("<${1:typename T}>"),
+ Kind(CompletionItemKind::Constructor;
+  EXPECT_THAT(
+  completions(Context + "Container c = Cont^()", {}, 
Opts).Completions,
   Contains(AllOf(Labeled("Container(int Size)"),
  SnippetSuffix(""),
  Kind(CompletionItemKind::Constructor;
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -452,18 +452,52 @@
   std::string summarizeSnippet() const {
 if (IsUsingDeclaration)
   return "";
-// Suppress function argument snippets if args are already present.
-if ((Completion.Kind == CompletionItemKind::Function ||
- Completion.Kind == CompletionItemKind::Method ||
- Completion.Kind == CompletionItemKind::Constructor) &&
-NextTokenKind == tok::l_paren)
-  return "";
 auto *Snippet = onlyValue<&BundledEntry::SnippetSuffix>();
 if (!Snippet)
   // All bundles are function calls.
   // FIXME(ibiryukov): sometimes add template arguments to a snippet, e.g.
   // we need to complete 'forward<$1>($0)'.
   return "($0)";
+// Suppress function argument snippets cursor is followed by left
+// parenthesis (and potentially arguments) or if there are potentially
+// template arguments. There are cases where it would be wrong (e.g. next
+// '<' token is a comparison rather than template argument list start) but
+// it is less common and suppressing snippet provides better UX.
+if (Completion.Kind == CompletionItemKind::Function ||
+Completion.Kind == CompletionItemKind::Method ||
+Completion.Kind == CompletionItemKind::Constructor) {
+  // If there is a potential template argument list, drop snippet and just
+  // complete symbol name. Ideally, this could generate an edit that would
+  // paste function arguments after template argument list but it would be
+  // complicated. Example:
+  //
+  // fu^ -> function
+  if (NextTokenKind == tok::less && Snippet->front() == '<')
+return "";
+  // Potentially followed by argument list.
+  if (NextTokenKind == tok::l_paren) {
+// If snippet contains template arguments we will emit them and drop
+// function arguments. Example:
+//
+// fu^(42) -> function(42);
+if (Snippet->front() == '<') {
+  // Find matching '>'. Snippet->find('>') will not work in cases like
+  // template >. Hence, iterate through
+  // the snippet until the angle bracket balance reaches zero.
+  int Balance = 0;
+  size_t I = 0;
+  do {
+if (Snippet->at(I) == '>')
+  --Balance;
+else if (Snippet->at(I) == '<')
+  ++Balance;
+++I;
+  } while (Balance > 0);
+  return Snippet->substr(0, I);
+}
+return "";
+  }
+}
 if (EnableFunctionArgSnippets)
   return *Snippet;
 


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -3114,10 +3114,13 @@
   Contains(AllOf(Labeled("Container(int Size)"),
  SnippetSuffix("<${1:typename T}>(${2:int Size})"),
  Kind(CompletionItemKind::Constructor;
-  // FIXME(kirillbobyrev): It would be nice to still produce the template
-  // snippet part: in this case it sho

[PATCH] D96784: Pass the cmdline aapcs bitfield options to cc1

[David Spickett via Phabricator via cfe-commits]

DavidSpickett added a comment.

LGTM with /// for the comments in the test.




Comment at: clang/lib/Driver/ToolChains/Clang.cpp:1525
 
+void AddAAPCSVolatileBitfieldArgs(const ArgList &Args, ArgStringList &CmdArgs) 
{
+  if (!Args.hasFlag(options::OPT_faapcs_bitfield_width,

stuij wrote:
> DavidSpickett wrote:
> > Name this AddARMAAPCSVolatileBitfieldArgs to match the other helpers.
> I deliberately didn't add `ARM` to the name as this function is used by both 
> the Arm and AArch64 targets, and `ARM` would cause confusion. I figured AAPCS 
> is differentiating enough, as it implies Arm without choosing a specific arch.
Good point. At least one of the A's stands for Arm in any case.



Comment at: clang/test/Driver/arm-aarch64-bitfield-flags.c:2
+// check -faapcs-bitfield-width/-fno-aapcs-bitfield-width
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main 
-faapcs-bitfield-width -### %s 2>&1 | FileCheck 
--check-prefixes=WIDTH,INVERSE-WIDTH %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main 
-faapcs-bitfield-width -### %s 2>&1 | FileCheck 
--check-prefixes=WIDTH,INVERSE-WIDTH %s

Nit: Use /// for comments that aren't run/check lines.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96784

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

[PATCH] D96944: [RecoveryAST] Add design doc to clang internal manual.

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

thanks! i think this mostly looks great, leaving a couple of suggestions and 
questions in comments.




Comment at: clang/docs/InternalsManual.rst:1882
+  example.
+- representing invalid node: the invalid node is preserved in the AST in some
+  form, e.g. when the "declaration" part of the declaration contains semantic

rather than `some form` maybe say `while indicating the error` ?



Comment at: clang/docs/InternalsManual.rst:1886
+- dropping invalid node: this often happens for errors that we don’t have
+  graceful recovery, prior to Recovery AST, a mismatched-argument function call
+  expression was dropped though a CallExpr was created for semantic analysis.

so far we've always been talking about the current state right? comparison to 
past seems surprising now. can we have a couple of examples for the cases that 
we still drop the nodes today?



Comment at: clang/docs/InternalsManual.rst:1889
+
+With these strategies, clang surfaces nice diagnostics, and provides a rich AST
+reflecting the written source code as much as possible even for broken code to

s/nice/better



Comment at: clang/docs/InternalsManual.rst:1890
+With these strategies, clang surfaces nice diagnostics, and provides a rich AST
+reflecting the written source code as much as possible even for broken code to
+AST consumers.

maybe drop `to AST consumers` or move it to the begining of the statement i.e.
`provides AST consumers with a rich AST reflecting the written source code as 
`



Comment at: clang/docs/InternalsManual.rst:1910
+Without Recovery AST, the invalid function call expression (and its child
+expressions) was dropped in the AST:
+

s/was/would be



Comment at: clang/docs/InternalsManual.rst:1933
+
+An alternative is to use existing Exprs, e.g. CallExpr for the above example.
+The basic trade off is that jamming the data we have into CallExpr forces us to

this talks about why it would be hard to make use of `CallExpr`s but doesn't 
say what we would gain by doing so. I suppose it would come with the benefit of 
preserving more details about the source code, like locations for parantheses 
and knowing the type of the expr? (or are these still accessible e.g. do we 
have an enum in RecoveryExpr telling us about its type?)



Comment at: clang/docs/InternalsManual.rst:1959
+
+In cases where we are confident about the concrete type (e.g. the return type
+for a broken non-overloaded function call), the ``RecoveryExpr`` will have this

that's great to know! i would expect it to be there already, but i think we 
should have this as a comment within the code too, so that future maintainers 
can feel confident when setting the type of a recovery expr.



Comment at: clang/docs/InternalsManual.rst:1971
+considered value-dependent, because its value isn't well-defined until the 
error
+is resolved. Among other things, this means that clang doesn't emit more errors
+where a RecoveryExpr is used as a constant (e.g. array size), but also won't 
try

IIRC, there were other problems with clang trying to emit secondary diags on 
such cases. It might be worth mentioning those too, again to warn future 
travellers about the side effects of making this non-value-dependent.



Comment at: clang/docs/InternalsManual.rst:1978
+
+Beyond the template dependence bits, we add a new “ContainsErrors” bit to
+express “Does this expression or this or anything within it contain errors”

might be worth mentioning this only exists for expressions.



Comment at: clang/docs/InternalsManual.rst:1979
+Beyond the template dependence bits, we add a new “ContainsErrors” bit to
+express “Does this expression or this or anything within it contain errors”
+semantic, this bit is always set for RecoveryExpr, and propagated to parent

not sure what second `this` is for



Comment at: clang/docs/InternalsManual.rst:1980
+express “Does this expression or this or anything within it contain errors”
+semantic, this bit is always set for RecoveryExpr, and propagated to parent
+nodes, this provides a fast way to query whether any (recursive) child of an

this sounds like it is propagated all the way to the TUDecl, but i suppose 
that's not the case. can you elaborate on when the propagation stops?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96944

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

[PATCH] D96561: [clang-tidy] add -use-color option to clang-tidy-diff.py

[Jonas Otto via Phabricator via cfe-commits]

ottojo added a comment.

I can't commit this myself, as i don't have commit access to the repo.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96561

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

[clang] b80357d - [PowerPC] Add option for ROP Protection

[Stefan Pintilie via cfe-commits]

Author: Stefan Pintilie
Date: 2021-02-18T12:15:50Z
New Revision: b80357d46e229ace904a8580e0a93e3f9b91720b

URL: 
https://github.com/llvm/llvm-project/commit/b80357d46e229ace904a8580e0a93e3f9b91720b
DIFF: 
https://github.com/llvm/llvm-project/commit/b80357d46e229ace904a8580e0a93e3f9b91720b.diff

LOG: [PowerPC] Add option for ROP Protection

Added -mrop-protection for Power PC to turn on codegen that provides some
protection from ROP attacks.

The option is off by default and can be turned on for Power 8, Power 9 and
Power 10.

This patch is for the option only. The feature will be implemented by a later
patch.

Reviewed By: amyk

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

Added: 
clang/test/Driver/ppc-mrop-protection-support-check.c

Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Basic/Targets/PPC.cpp
clang/lib/Basic/Targets/PPC.h
clang/test/Preprocessor/init-ppc64.c
llvm/lib/Target/PowerPC/PPC.td
llvm/lib/Target/PowerPC/PPCSubtarget.cpp
llvm/lib/Target/PowerPC/PPCSubtarget.h
llvm/test/CodeGen/PowerPC/future-check-features.ll

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 635af48cc051..0e09958b36e1 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -3181,6 +3181,8 @@ def mno_longcall : Flag<["-"], "mno-longcall">,
 Group;
 def mmma: Flag<["-"], "mmma">, Group;
 def mno_mma: Flag<["-"], "mno-mma">, Group;
+def mrop_protection : Flag<["-"], "mrop-protection">,
+Group;
 def maix_struct_return : Flag<["-"], "maix-struct-return">,
   Group, Flags<[CC1Option]>,
   HelpText<"Return all structs in memory (PPC32 only)">;

diff  --git a/clang/lib/Basic/Targets/PPC.cpp b/clang/lib/Basic/Targets/PPC.cpp
index ff09c0fa2a23..73ecc05f2015 100644
--- a/clang/lib/Basic/Targets/PPC.cpp
+++ b/clang/lib/Basic/Targets/PPC.cpp
@@ -66,6 +66,8 @@ bool 
PPCTargetInfo::handleTargetFeatures(std::vector &Features,
   PairedVectorMemops = true;
 } else if (Feature == "+mma") {
   HasMMA = true;
+} else if (Feature == "+rop-protection") {
+  HasROPProtection = true;
 }
 // TODO: Finish this list and add an assert that we've handled them
 // all.
@@ -193,6 +195,8 @@ void PPCTargetInfo::getTargetDefines(const LangOptions 
&Opts,
 Builder.defineMacro("__POWER9_VECTOR__");
   if (HasMMA)
 Builder.defineMacro("__MMA__");
+  if (HasROPProtection)
+Builder.defineMacro("__ROP_PROTECTION__");
   if (HasP10Vector)
 Builder.defineMacro("__POWER10_VECTOR__");
 
@@ -319,6 +323,9 @@ bool PPCTargetInfo::initFeatureMap(
 .Case("pwr8", true)
 .Default(false);
 
+  // ROP Protection is off by default.
+  Features["rop-protection"] = false;
+
   Features["spe"] = llvm::StringSwitch(CPU)
 .Case("8548", true)
 .Case("e500", true)
@@ -355,6 +362,13 @@ bool PPCTargetInfo::initFeatureMap(
 return false;
   }
 
+  if (!(ArchDefs & ArchDefinePwr8) &&
+  llvm::find(FeaturesVec, "+rop-protection") != FeaturesVec.end()) {
+// We can turn on ROP Protection on Power 8 and above.
+Diags.Report(diag::err_opt_not_valid_with_opt) << "-mrop-protection" << 
CPU;
+return false;
+  }
+
   return TargetInfo::initFeatureMap(Features, Diags, CPU, FeaturesVec);
 }
 
@@ -393,6 +407,7 @@ bool PPCTargetInfo::hasFeature(StringRef Feature) const {
   .Case("pcrelative-memops", HasPCRelativeMemops)
   .Case("spe", HasSPE)
   .Case("mma", HasMMA)
+  .Case("rop-protection", HasROPProtection)
   .Default(false);
 }
 

diff  --git a/clang/lib/Basic/Targets/PPC.h b/clang/lib/Basic/Targets/PPC.h
index 56c8f33ef221..d3bff015760f 100644
--- a/clang/lib/Basic/Targets/PPC.h
+++ b/clang/lib/Basic/Targets/PPC.h
@@ -59,6 +59,7 @@ class LLVM_LIBRARY_VISIBILITY PPCTargetInfo : public 
TargetInfo {
   // Target cpu features.
   bool HasAltivec = false;
   bool HasMMA = false;
+  bool HasROPProtection = false;
   bool HasVSX = false;
   bool HasP8Vector = false;
   bool HasP8Crypto = false;

diff  --git a/clang/test/Driver/ppc-mrop-protection-support-check.c 
b/clang/test/Driver/ppc-mrop-protection-support-check.c
new file mode 100644
index ..c2761d21c9d1
--- /dev/null
+++ b/clang/test/Driver/ppc-mrop-protection-support-check.c
@@ -0,0 +1,26 @@
+// RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
+// RUN:   -mcpu=pwr10 -mrop-protection %s 2>&1 | FileCheck %s 
--check-prefix=HASROP
+// RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
+// RUN:   -mcpu=power10 -mrop-protection %s 2>&1 | FileCheck %s 
--check-prefix=HASROP
+// RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
+// RUN:   -mcpu=pwr9 -mrop-protection %s 2>&1 | FileCheck %s 
--check-prefix=HASROP
+// RUN: not %clang -target po

[PATCH] D96512: [PowerPC] Add option for ROP Protection

[Stefan Pintilie via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGb80357d46e22: [PowerPC] Add option for ROP Protection 
(authored by stefanp).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96512

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/Basic/Targets/PPC.h
  clang/test/Driver/ppc-mrop-protection-support-check.c
  clang/test/Preprocessor/init-ppc64.c
  llvm/lib/Target/PowerPC/PPC.td
  llvm/lib/Target/PowerPC/PPCSubtarget.cpp
  llvm/lib/Target/PowerPC/PPCSubtarget.h
  llvm/test/CodeGen/PowerPC/future-check-features.ll

Index: llvm/test/CodeGen/PowerPC/future-check-features.ll
===
--- llvm/test/CodeGen/PowerPC/future-check-features.ll
+++ llvm/test/CodeGen/PowerPC/future-check-features.ll
@@ -1,7 +1,7 @@
-; RUN: llc -mattr=pcrelative-memops,prefix-instrs,paired-vector-memops,mma \
+; RUN: llc -mattr=pcrelative-memops,prefix-instrs,paired-vector-memops,mma,rop-protection \
 ; RUN:   -verify-machineinstrs -mtriple=powerpc64le-unknown-unknown \
 ; RUN:   -ppc-asm-full-reg-names %s -o - 2>&1 | FileCheck %s
-; RUN: llc -mattr=pcrelative-memops,prefix-instrs,paired-vector-memops,mma \
+; RUN: llc -mattr=pcrelative-memops,prefix-instrs,paired-vector-memops,mma,rop-protection \
 ; RUN:   -verify-machineinstrs -mtriple=powerpc64-unknown-unknown \
 ; RUN:   -ppc-asm-full-reg-names %s -o - 2>&1 | FileCheck %s
 
Index: llvm/lib/Target/PowerPC/PPCSubtarget.h
===
--- llvm/lib/Target/PowerPC/PPCSubtarget.h
+++ llvm/lib/Target/PowerPC/PPCSubtarget.h
@@ -112,6 +112,7 @@
   bool HasPrefixInstrs;
   bool HasPCRelativeMemops;
   bool HasMMA;
+  bool HasROPProtection;
   bool HasFCPSGN;
   bool HasFSQRT;
   bool HasFRE, HasFRES, HasFRSQRTE, HasFRSQRTES;
@@ -273,6 +274,7 @@
   bool hasPrefixInstrs() const { return HasPrefixInstrs; }
   bool hasPCRelativeMemops() const { return HasPCRelativeMemops; }
   bool hasMMA() const { return HasMMA; }
+  bool hasROPProtection() const { return HasROPProtection; }
   bool pairedVectorMemops() const { return PairedVectorMemops; }
   bool hasMFOCRF() const { return HasMFOCRF; }
   bool hasISEL() const { return HasISEL; }
Index: llvm/lib/Target/PowerPC/PPCSubtarget.cpp
===
--- llvm/lib/Target/PowerPC/PPCSubtarget.cpp
+++ llvm/lib/Target/PowerPC/PPCSubtarget.cpp
@@ -87,6 +87,7 @@
   HasP9Vector = false;
   HasP9Altivec = false;
   HasMMA = false;
+  HasROPProtection = false;
   HasP10Vector = false;
   HasPrefixInstrs = false;
   HasPCRelativeMemops = false;
Index: llvm/lib/Target/PowerPC/PPC.td
===
--- llvm/lib/Target/PowerPC/PPC.td
+++ llvm/lib/Target/PowerPC/PPC.td
@@ -252,6 +252,9 @@
   "Enable MMA instructions",
   [FeatureP8Vector, FeatureP9Altivec,
FeaturePairedVectorMemops]>;
+def FeatureROPProtection :
+  SubtargetFeature<"rop-protection", "HasROPProtection", "false",
+   "Add ROP protection">;
 
 def FeaturePredictableSelectIsExpensive :
   SubtargetFeature<"predictable-select-expensive",
@@ -320,7 +323,8 @@
  FeatureDirectMove,
  FeatureICBT,
  FeaturePartwordAtomic,
- FeaturePredictableSelectIsExpensive
+ FeaturePredictableSelectIsExpensive,
+ FeatureROPProtection
 ];
 
   list P8SpecificFeatures = [FeatureAddiLoadFusion,
Index: clang/test/Preprocessor/init-ppc64.c
===
--- clang/test/Preprocessor/init-ppc64.c
+++ clang/test/Preprocessor/init-ppc64.c
@@ -566,6 +566,7 @@
 // PPCPWR8-NOT:#define _ARCH_PWR6X 1
 // PPCPWR8:#define _ARCH_PWR7 1
 // PPCPWR8:#define _ARCH_PWR8 1
+// PPCPWR8-NOT:#define __ROP_PROTECTION__ 1
 //
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-none-none -target-cpu power8 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPCPOWER8 %s
 //
@@ -583,6 +584,7 @@
 // PPCPOWER8-NOT:#define _ARCH_PWR6X 1
 // PPCPOWER8:#define _ARCH_PWR7 1
 // PPCPOWER8:#define _ARCH_PWR8 1
+// PPCPOWER8-NOT:#define __ROP_PROTECTION__ 1
 //
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-none-none -target-cpu pwr9 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPCPWR9 %s
 //
@@ -597,6 +599,7 @@
 // PPCPWR9-NOT:#define _ARCH_PWR6X 1
 // PPCPWR9:#define _ARCH_PWR7 1
 // PPCPWR9:#define _ARCH_PWR9 1
+// PPCPWR9-NOT:#define __ROP_PROTECTION__ 1
 //
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-none-none -target-cpu power9 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPCPOWER9 %s
 //
@@ -611,6 +614,7 @@
 // 

[PATCH] D96070: [clang] [driver] Enable static linking to libc++

[Timm Bäder via Phabricator via cfe-commits]

tbaeder abandoned this revision.
tbaeder added a comment.

Thanks for the input everyone.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96070

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

[PATCH] D96751: [clangd] Populate detail field in document symbols

[WangWei via Phabricator via cfe-commits]

lightmelodies updated this revision to Diff 324599.

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

https://reviews.llvm.org/D96751

Files:
  clang-tools-extra/clangd/FindSymbols.cpp
  clang-tools-extra/clangd/test/symbols.test
  clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp

Index: clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
+++ clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
@@ -35,6 +35,7 @@
 }
 MATCHER_P(WithName, N, "") { return arg.name == N; }
 MATCHER_P(WithKind, Kind, "") { return arg.kind == Kind; }
+MATCHER_P(WithDetail, Detail, "") { return arg.detail == Detail; }
 MATCHER_P(SymRange, Range, "") { return arg.range == Range; }
 
 // GMock helpers for matching DocumentSymbol.
@@ -374,44 +375,55 @@
   EXPECT_THAT(
   getSymbols(TU.build()),
   ElementsAreArray(
-  {AllOf(WithName("Foo"), WithKind(SymbolKind::Class), Children()),
+  {AllOf(WithName("Foo"), WithKind(SymbolKind::Class),
+ WithDetail("class"), Children()),
AllOf(WithName("Foo"), WithKind(SymbolKind::Class),
- Children(AllOf(WithName("Foo"),
-WithKind(SymbolKind::Constructor), Children()),
-  AllOf(WithName("Foo"),
-WithKind(SymbolKind::Constructor), Children()),
-  AllOf(WithName("f"), WithKind(SymbolKind::Method),
-Children()),
-  AllOf(WithName("operator="),
-WithKind(SymbolKind::Method), Children()),
-  AllOf(WithName("~Foo"),
-WithKind(SymbolKind::Constructor), Children()),
-  AllOf(WithName("Nested"), WithKind(SymbolKind::Class),
-Children(AllOf(WithName("f"),
-   WithKind(SymbolKind::Method),
-   Children()),
-   AllOf(WithName("Friend"), WithKind(SymbolKind::Class), Children()),
-   AllOf(WithName("f1"), WithKind(SymbolKind::Function), Children()),
-   AllOf(WithName("f2"), WithKind(SymbolKind::Function), Children()),
-   AllOf(WithName("KInt"), WithKind(SymbolKind::Variable), Children()),
-   AllOf(WithName("kStr"), WithKind(SymbolKind::Variable), Children()),
-   AllOf(WithName("f1"), WithKind(SymbolKind::Function), Children()),
+ WithDetail("class"),
+ Children(
+ AllOf(WithName("Foo"), WithKind(SymbolKind::Constructor),
+   WithDetail("void ()"), Children()),
+ AllOf(WithName("Foo"), WithKind(SymbolKind::Constructor),
+   WithDetail("void (int)"), Children()),
+ AllOf(WithName("f"), WithKind(SymbolKind::Method),
+   WithDetail("void ()"), Children()),
+ AllOf(WithName("operator="), WithKind(SymbolKind::Method),
+   WithDetail("Foo &(const Foo &)"), Children()),
+ AllOf(WithName("~Foo"), WithKind(SymbolKind::Constructor),
+   WithDetail("void ()"), Children()),
+ AllOf(WithName("Nested"), WithKind(SymbolKind::Class),
+   WithDetail("class"),
+   Children(AllOf(
+   WithName("f"), WithKind(SymbolKind::Method),
+   WithDetail("void ()"), Children()),
+   AllOf(WithName("Friend"), WithKind(SymbolKind::Class),
+ WithDetail("class"), Children()),
+   AllOf(WithName("f1"), WithKind(SymbolKind::Function),
+ WithDetail("void ()"), Children()),
+   AllOf(WithName("f2"), WithKind(SymbolKind::Function),
+ WithDetail("void ()"), Children()),
+   AllOf(WithName("KInt"), WithKind(SymbolKind::Variable),
+ WithDetail("const int"), Children()),
+   AllOf(WithName("kStr"), WithKind(SymbolKind::Variable),
+ WithDetail("const char *"), Children()),
+   AllOf(WithName("f1"), WithKind(SymbolKind::Function),
+ WithDetail("void ()"), Children()),
AllOf(
-   WithName("foo"), WithKind(SymbolKind::Namespace),
-   Children(
-   AllOf(WithName("int32"), WithKind(SymbolKind::Class),
- Children()),
-   AllOf(WithName("int32_t"), WithKind(SymbolKind::Class),
- Children()),
-   AllOf(WithName("v1"), WithKind(SymbolKind::Variable),
- Children()),
-   AllOf(WithName("bar"), WithKind(SymbolKind

[PATCH] D96807: Modify TypePrinter to differentiate between anonymous struct and unnamed struct

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM!


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

https://reviews.llvm.org/D96807

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

[PATCH] D96950: [clang][CodeComplete] Ensure there are no crashes when completing with ParenListExprs as LHS

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet created this revision.
kadircet added a reviewer: sammccall.
kadircet requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D96950

Files:
  clang/lib/Sema/SemaCodeComplete.cpp


Index: clang/lib/Sema/SemaCodeComplete.cpp
===
--- clang/lib/Sema/SemaCodeComplete.cpp
+++ clang/lib/Sema/SemaCodeComplete.cpp
@@ -5257,11 +5257,21 @@
 
   // Peel off the ParenListExpr by chosing the last one, as they don't have a
   // predefined type.
-  if (auto *PLE = llvm::dyn_cast(Base))
+  if (auto *PLE = llvm::dyn_cast(Base)) {
+// FIXME: Get rid of this check once we are sure the ParenListExpr in here
+// cannot be empty. This is assumed to ultimately be a chain of comma
+// operators. We expect other ParenListExprs to be resolved to e.g.
+// constructor calls before getting here. Same for OtherOpBase.
+if (PLE->getNumExprs() == 0)
+  return;
 Base = PLE->getExpr(PLE->getNumExprs() - 1);
+  }
   if (OtherOpBase) {
-if (auto *PLE = llvm::dyn_cast(OtherOpBase))
+if (auto *PLE = llvm::dyn_cast(OtherOpBase)) {
+  if (PLE->getNumExprs() == 0)
+return;
   OtherOpBase = PLE->getExpr(PLE->getNumExprs() - 1);
+}
   }
 
   ExprResult ConvertedBase = PerformMemberExprBaseConversion(Base, IsArrow);
@@ -5698,8 +5708,15 @@
 
   // If we have a ParenListExpr for LHS, peel it off by chosing the last expr.
   // As ParenListExprs don't have a predefined type.
-  if (auto *PLE = llvm::dyn_cast(Fn))
+  if (auto *PLE = llvm::dyn_cast(Fn)) {
+// FIXME: Get rid of this check once we are sure the ParenListExpr in here
+// cannot be empty. This is assumed to ultimately be a chain of comma
+// operators. We expect other ParenListExprs to be resolved to e.g.
+// constructor calls before getting here.
+if (PLE->getNumExprs() == 0)
+  return QualType();
 Fn = PLE->getExpr(PLE->getNumExprs() - 1);
+  }
 
   // FIXME: Provide support for variadic template functions.
   // Ignore type-dependent call expressions entirely.


Index: clang/lib/Sema/SemaCodeComplete.cpp
===
--- clang/lib/Sema/SemaCodeComplete.cpp
+++ clang/lib/Sema/SemaCodeComplete.cpp
@@ -5257,11 +5257,21 @@
 
   // Peel off the ParenListExpr by chosing the last one, as they don't have a
   // predefined type.
-  if (auto *PLE = llvm::dyn_cast(Base))
+  if (auto *PLE = llvm::dyn_cast(Base)) {
+// FIXME: Get rid of this check once we are sure the ParenListExpr in here
+// cannot be empty. This is assumed to ultimately be a chain of comma
+// operators. We expect other ParenListExprs to be resolved to e.g.
+// constructor calls before getting here. Same for OtherOpBase.
+if (PLE->getNumExprs() == 0)
+  return;
 Base = PLE->getExpr(PLE->getNumExprs() - 1);
+  }
   if (OtherOpBase) {
-if (auto *PLE = llvm::dyn_cast(OtherOpBase))
+if (auto *PLE = llvm::dyn_cast(OtherOpBase)) {
+  if (PLE->getNumExprs() == 0)
+return;
   OtherOpBase = PLE->getExpr(PLE->getNumExprs() - 1);
+}
   }
 
   ExprResult ConvertedBase = PerformMemberExprBaseConversion(Base, IsArrow);
@@ -5698,8 +5708,15 @@
 
   // If we have a ParenListExpr for LHS, peel it off by chosing the last expr.
   // As ParenListExprs don't have a predefined type.
-  if (auto *PLE = llvm::dyn_cast(Fn))
+  if (auto *PLE = llvm::dyn_cast(Fn)) {
+// FIXME: Get rid of this check once we are sure the ParenListExpr in here
+// cannot be empty. This is assumed to ultimately be a chain of comma
+// operators. We expect other ParenListExprs to be resolved to e.g.
+// constructor calls before getting here.
+if (PLE->getNumExprs() == 0)
+  return QualType();
 Fn = PLE->getExpr(PLE->getNumExprs() - 1);
+  }
 
   // FIXME: Provide support for variadic template functions.
   // Ignore type-dependent call expressions entirely.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D94355: [Passes] Add relative lookup table generator pass

[Hans Wennborg via Phabricator via cfe-commits]

hans added a comment.

Thanks for pushing this forward! I think this will be a nice transformation 
once all the details are worked out.




Comment at: clang/test/CodeGen/switch-to-lookup-table.c:2
+// Check switch to lookup optimization in fPIC and fno-PIC mode
+// RUN: %clang_cc1 %s -triple=aarch64-unknown-fuchsia -O2 -fno-PIC -S 
-emit-llvm -o - | FileCheck %s --check-prefix=CHECK --check-prefix=FNOPIC
+// RUN: %clang_cc1 %s -triple=aarch64-unknown-fuchsia -O2 -fPIC -S -emit-llvm 
-o - | FileCheck %s --check-prefix=CHECK --check-prefix=FPIC

gulfem wrote:
> hans wrote:
> > Clang codegen tests are not normally used to test LLVM optimizations. I 
> > think the tests for this should all live in LLVM, not Clang.
> > 
> > (Also aarch64 is not guaranteed to be included as a target in the LLVM 
> > build, so this test would not necessarily run.)
> I'm not able to use -fPIC and -fno-PIC options in the `opt` tool.
> I am setting the `PIC Level` flag to enable -fPIC in `opt.
> I thought that testing -fPIC and -fno-PIC in the same file seems easier and 
> more readable  in CodeGen tests.
> Please let me know if you have a good suggestion how to do that with `opt`.
> 
> I changed the target to `x86_64-linux` in this test.
Buildbots may not have x86_64 as a registered target, so this test will break 
some buildbots.

I think the opt flags -relocation-model=pic and -relocation-model=static will 
do the right thing (see for example 
llvm/test/Transforms/SimplifyCFG/ARM/switch-to-lookup-table.ll



Comment at: llvm/include/llvm/InitializePasses.h:321
 void initializeNameAnonGlobalLegacyPassPass(PassRegistry&);
+void initializeRelLookupTableConverterPassPass(PassRegistry &);
 void initializeUniqueInternalLinkageNamesLegacyPassPass(PassRegistry &);

In some places the pass is referred to as a generator and here it's a 
converter. I think converter is a better name, and it should be consistent.



Comment at: llvm/include/llvm/Transforms/Utils/RelLookupTableGenerator.h:10
+// This file implements relative lookup table generator that converts
+// lookup tables to relative lookup tables to make them PIC-friendly.
+//

For this kind of pass, I think it would be helpful to have a small example in 
the comment that shows what kind of IR it's looking for, and what it will be 
transformed to. (Either here or in the .cpp file.)



Comment at: llvm/include/llvm/Transforms/Utils/RelLookupTableGenerator.h:22
+
+// Simple pass that converts lookup tables to relative lookup tables.
+class RelLookupTableGeneratorPass

No need to call it simple :)



Comment at: llvm/include/llvm/Transforms/Utils/RelLookupTableGenerator.h:33
+
+#endif // LLVM_TRANSFORMS_RELLOOKUPTABLEGENERATOR_H

As clang-tidy points out, the comment doesn't match the actual macro name.



Comment at: llvm/lib/Transforms/Utils/RelLookupTableGenerator.cpp:25
+
+namespace llvm {
+

Since the function below are only used within this file, they should be static 
or in an anonymous namespace. Since you're already using an anonymous namespace 
for the RelLookupTableConverterPass class, I'd suggest using that for these 
functions too.



Comment at: llvm/lib/Transforms/Utils/RelLookupTableGenerator.cpp:28
+bool shouldGenerateRelLookupTables(Module &M) {
+  // If not in x86 or aarch64 mode, do not generate a relative lookup table.
+  Triple TargetTriple(M.getTargetTriple());

This explains the "what" of what the code does, but not the "why". Why should 
the transformation only run for these two targets?



Comment at: llvm/lib/Transforms/Utils/RelLookupTableGenerator.cpp:34
+
+  // If not tiny or small code model, do not generate a relative lookup table.
+  Optional CodeModel = M.getCodeModel();

This also needs the "why".



Comment at: llvm/lib/Transforms/Utils/RelLookupTableGenerator.cpp:39
+
+  // If not in PIC mode, do not generate a relative lookup table.
+  if (M.getPICLevel() == PICLevel::NotPIC)

Again, this needs the "why".
And perhaps it would make sense to put this check first.



Comment at: llvm/lib/Transforms/Utils/RelLookupTableGenerator.cpp:58
+GlobalVariable *GlobalVarOp = dyn_cast(Operand);
+/// If any of the pointer values in the lookup table is not a global value
+/// or dso_local, do not generate a relative lookup table.

The comment doesn't match the code exactly I think, since further down you also 
allow GetElementPtr expressions. Maybe the comment could be clearer.



Comment at: llvm/lib/Transforms/Utils/RelLookupTableGenerator.cpp:78
+  /// do not generate a relative lookup table.
+  if (!GlobalVar.hasOneUser())
+return false;

Should it be hasOneUse() or hasOneUser()?

Also maybe this ch

[PATCH] D96950: [clang][CodeComplete] Ensure there are no crashes when completing with ParenListExprs as LHS

[Sam McCall via Phabricator via cfe-commits]

sammccall added inline comments.



Comment at: clang/lib/Sema/SemaCodeComplete.cpp:5258
 
   // Peel off the ParenListExpr by chosing the last one, as they don't have a
   // predefined type.

I think we should merge the two comments, something like...

```
/// If LHS is ParenListExpr, assume a chain of comma operators and pick the 
last expr.
/// We expect other ParenListExprs to be resolved to e.g. constructor calls 
before here.
/// (So the ParenListExpr should be nonempty, but check just in case)
```



Comment at: clang/lib/Sema/SemaCodeComplete.cpp:5260
   // predefined type.
-  if (auto *PLE = llvm::dyn_cast(Base))
+  if (auto *PLE = llvm::dyn_cast(Base)) {
+// FIXME: Get rid of this check once we are sure the ParenListExpr in here

now this is getting a little more complicated, we could pull out a function 
Expr* unwrapParenList(Expr*) and avoid duplicating code & comments, but up to 
you.



Comment at: clang/lib/Sema/SemaCodeComplete.cpp:5261
+  if (auto *PLE = llvm::dyn_cast(Base)) {
+// FIXME: Get rid of this check once we are sure the ParenListExpr in here
+// cannot be empty. This is assumed to ultimately be a chain of comma

I'm not actually sure we should fix this. Nonempty is a subtle invariant that 
could also be violated by e.g. broken code. And the check is cheap.



Comment at: clang/lib/Sema/SemaCodeComplete.cpp:5272
+  if (PLE->getNumExprs() == 0)
+return;
   OtherOpBase = PLE->getExpr(PLE->getNumExprs() - 1);

I think you want OtherOpBase = null here, not return


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96950

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

[PATCH] D87146: [analyzer] Implement shared semantics checks for XNU functions in PthreadLockChecker

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.

@steakhal

> Could you please give a few links to some documentation about the functions 
> you are trying to model?

Yes, you a re right. I've edited the summary with the link.


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

https://reviews.llvm.org/D87146

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

[PATCH] D95246: [test] Use host platform specific error message substitution in lit tests

[Abhina Sree via Phabricator via cfe-commits]

abhina.sreeskantharajan added a comment.

In D95246#2568084 , @ASDenysPetrov 
wrote:

> @jhenderson
>
>> @ASDenysPetrov, could you provide your link command-line for one of the 
>> tools that produces the failing message, please, e.g. llvm-ar?
>
> Here is output of running tests in llvm-ar folder: F15562458: 
> fail_output_llvm_ar.txt 
>
>> Not that I'm saying we shouldn't try to fix your use-case, but if you aren't 
>> using Cygwin, it's worth noting that 
>> https://llvm.org/docs/GettingStarted.html#hardware states that only Visual 
>> Studio builds (whether via the IDE or some other tool like ninja) are known 
>> to work for Windows.
>
> I'm using MSYS2 instead of Cygwin. I found it as a better alternative. I'm 
> using GCC+MSYS2+Ninja.

MSYS2 is based on a modified version of Cygwin according to its description, 
maybe if we can detect that in config.py this will solve your issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95246

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

[PATCH] D96944: [RecoveryAST] Add design doc to clang internal manual.

[Sam McCall via Phabricator via cfe-commits]

sammccall accepted this revision.
sammccall added reviewers: rsmith, kadircet.
sammccall added a comment.
This revision is now accepted and ready to land.

I've reviewed this previously and am happy with how it ended up.
But Kadir's comments are good, and we should also wait a few days in case 
others want changes.




Comment at: clang/docs/InternalsManual.rst:1886
+- dropping invalid node: this often happens for errors that we don’t have
+  graceful recovery, prior to Recovery AST, a mismatched-argument function call
+  expression was dropped though a CallExpr was created for semantic analysis.

kadircet wrote:
> so far we've always been talking about the current state right? comparison to 
> past seems surprising now. can we have a couple of examples for the cases 
> that we still drop the nodes today?
nit: "graceful recovery. Prior to..."



Comment at: clang/docs/InternalsManual.rst:1933
+
+An alternative is to use existing Exprs, e.g. CallExpr for the above example.
+The basic trade off is that jamming the data we have into CallExpr forces us to

kadircet wrote:
> this talks about why it would be hard to make use of `CallExpr`s but doesn't 
> say what we would gain by doing so. I suppose it would come with the benefit 
> of preserving more details about the source code, like locations for 
> parantheses and knowing the type of the expr? (or are these still accessible 
> e.g. do we have an enum in RecoveryExpr telling us about its type?)
Ooh, you're right: this says "the trade off" but only mentions one side :-)

Maybe "This would capture more call details and allow it to be treated 
uniformly with valid CallExprs. However, jamming..."



Comment at: clang/docs/InternalsManual.rst:1971
+considered value-dependent, because its value isn't well-defined until the 
error
+is resolved. Among other things, this means that clang doesn't emit more errors
+where a RecoveryExpr is used as a constant (e.g. array size), but also won't 
try

kadircet wrote:
> IIRC, there were other problems with clang trying to emit secondary diags on 
> such cases. It might be worth mentioning those too, again to warn future 
> travellers about the side effects of making this non-value-dependent.
Do you have an example? I chatted with Haojian offline about this and we 
couldn't find a good one apart from constant contexts. (And the wording of the 
standard suggests that value-dependence is a concept that's only interesting in 
constant contexts)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96944

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

[PATCH] D96875: [flang][driver] Add -fdebug-module-writer option

[Arnamoy B via Phabricator via cfe-commits]

arnamoy10 updated this revision to Diff 324606.
arnamoy10 added a comment.

Added some setters to work with.

Modified the test case to include `flang-new -fc1` as well.


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

https://reviews.llvm.org/D96875

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Frontend/CompilerInvocation.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/test/Semantics/mod-file-rewriter.f90

Index: flang/test/Semantics/mod-file-rewriter.f90
===
--- flang/test/Semantics/mod-file-rewriter.f90
+++ flang/test/Semantics/mod-file-rewriter.f90
@@ -3,6 +3,14 @@
 ! RUN: %f18 -fsyntax-only -fdebug-module-writer %s 2>&1 | FileCheck %s --check-prefix CHECK_UNCHANGED
 ! RUN: %f18 -fsyntax-only -fdebug-module-writer %p/Inputs/mod-file-unchanged.f90 2>&1 | FileCheck %s --check-prefix CHECK_UNCHANGED
 ! RUN: %f18 -fsyntax-only -fdebug-module-writer %p/Inputs/mod-file-changed.f90 2>&1 | FileCheck %s --check-prefix CHECK_CHANGED
+! RUN: %flang-new -fsyntax-only -fdebug-module-writer %s 2>&1 | FileCheck %s --check-prefix CHECK_CHANGED
+! RUN: %flang-new -fsyntax-only -fdebug-module-writer %s 2>&1 | FileCheck %s --check-prefix CHECK_UNCHANGED
+! RUN: %flang-new -fsyntax-only -fdebug-module-writer %p/Inputs/mod-file-unchanged.f90 2>&1 | FileCheck %s --check-prefix CHECK_UNCHANGED
+! RUN: %flang-new -fsyntax-only -fdebug-module-writer %p/Inputs/mod-file-changed.f90 2>&1 | FileCheck %s --check-prefix CHECK_CHANGED
+! RUN: %flang-new -fc1 -fsyntax-only -fdebug-module-writer %s 2>&1 | FileCheck %s --check-prefix CHECK_CHANGED
+! RUN: %flang-new -fc1 -fsyntax-only -fdebug-module-writer %s 2>&1 | FileCheck %s --check-prefix CHECK_UNCHANGED
+! RUN: %flang-new -fc1 -fsyntax-only -fdebug-module-writer %p/Inputs/mod-file-unchanged.f90 2>&1 | FileCheck %s --check-prefix CHECK_UNCHANGED
+! RUN: %flang-new -fc1 -fsyntax-only -fdebug-module-writer %p/Inputs/mod-file-changed.f90 2>&1 | FileCheck %s --check-prefix CHECK_CHANGED
 
 module m
   real :: x(10)
Index: flang/lib/Frontend/FrontendActions.cpp
===
--- flang/lib/Frontend/FrontendActions.cpp
+++ flang/lib/Frontend/FrontendActions.cpp
@@ -134,7 +134,7 @@
 
   // Prepare semantics
   Fortran::semantics::Semantics semantics{ci.invocation().semanticsContext(),
-  parseTree, ci.parsing().cooked().AsCharBlock()};
+  parseTree, ci.parsing().cooked().AsCharBlock(),ci.invocation().debugModuleDir()};
 
   // Run semantic checks
   semantics.Perform();
Index: flang/lib/Frontend/CompilerInvocation.cpp
===
--- flang/lib/Frontend/CompilerInvocation.cpp
+++ flang/lib/Frontend/CompilerInvocation.cpp
@@ -227,9 +227,10 @@
 
 /// Parses all semantic related arguments and populates the variables
 /// options accordingly.
-static void parseSemaArgs(std::string &moduleDir, llvm::opt::ArgList &args,
+static void parseSemaArgs(CompilerInvocation &res, llvm::opt::ArgList &args,
 clang::DiagnosticsEngine &diags) {
 
+  // -J/module-dir option
   auto moduleDirList =
   args.getAllArgValues(clang::driver::options::OPT_module_dir);
   // User can only specify -J/-module-dir once
@@ -241,7 +242,12 @@
 diags.Report(diagID);
   }
   if (moduleDirList.size() == 1)
-moduleDir = moduleDirList[0];
+res.SetModuleDir(moduleDirList[0]);
+
+  // -fdebug-module-writer option
+  if (args.hasArg(clang::driver::options::OPT_fdebug_module_writer)) {
+res.SetDebugModuleDir(true);
+  }
 }
 
 /// Parses all Dialect related arguments and populates the variables
@@ -316,7 +322,7 @@
   // Parse the preprocessor args
   parsePreprocessorArgs(res.preprocessorOpts(), args);
   // Parse semantic args
-  parseSemaArgs(res.moduleDir(), args, diags);
+  parseSemaArgs(res, args, diags);
   // Parse dialect arguments
   parseDialectArgs(res, args, diags);
 
@@ -429,7 +435,6 @@
   semanticsContext_ = std::make_unique(
   defaultKinds(), fortranOptions.features, allCookedSources);
 
-  auto &moduleDirJ = moduleDir();
-  semanticsContext_->set_moduleDirectory(moduleDirJ)
+  semanticsContext_->set_moduleDirectory(moduleDir())
   .set_searchDirectories(fortranOptions.searchDirectories);
 }
Index: flang/include/flang/Frontend/CompilerInvocation.h
===
--- flang/include/flang/Frontend/CompilerInvocation.h
+++ flang/include/flang/Frontend/CompilerInvocation.h
@@ -69,6 +69,8 @@
   // of options.
   std::string moduleDir_ = ".";
 
+  bool debugModuleDir_ = false;
+
   // Fortran Dialect options
   Fortran::common::IntrinsicTypeDefaultKinds defaultKinds_;
 
@@ -91,6 +93,9 @@
   std::string &moduleDir() { return moduleDir_; }
   const std::string &moduleDir() const { return moduleDir_; }
 
+  bool &debugModuleDir() { return

[PATCH] D96875: [flang][driver] Add -fdebug-module-writer option

[Arnamoy B via Phabricator via cfe-commits]

arnamoy10 added inline comments.



Comment at: flang/test/Semantics/mod-file-rewriter.f90:9
+! RUN: %flang-new -fsyntax-only -fdebug-module-writer 
%p/Inputs/mod-file-unchanged.f90 2>&1 | FileCheck %s --check-prefix 
CHECK_UNCHANGED
+! RUN: %flang-new -fsyntax-only -fdebug-module-writer 
%p/Inputs/mod-file-changed.f90 2>&1 | FileCheck %s --check-prefix CHECK_CHANGED
 

tskeith wrote:
> Why do you need to duplicate these lines? Doesn't it work to use `%flang`?
`%flang` will unfortunately invoke `f18` currently.


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

https://reviews.llvm.org/D96875

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

[PATCH] D35137: [Driver] Honor -isysroot for Linux targets

[Yen Chi Hsuan via Phabricator via cfe-commits]

yan12125 abandoned this revision.
yan12125 added a comment.

Seems the issue has been fixed in https://reviews.llvm.org/D31495


Repository:
  rL LLVM

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

https://reviews.llvm.org/D35137

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

[PATCH] D96803: EntryExitInstrumenter: Move to a module pass and enable at all optimization levels (PR49143)

[Adhemerval Zanella via Phabricator via cfe-commits]

zatrazz added a comment.

In D96803#2569436 , @aeubanks wrote:

> In D96803#2568179 , @zatrazz wrote:
>
>> In D96803#2566322 , @aeubanks wrote:
>>
>>> why is this now a module pass?
>>
>> Mainly to avoid the default rule from new pass manager to *not* apply any 
>> FunctionPass for optnone (which is the main issue for PR49143). Is there a 
>> better way to accomplish it? I noted also that 
>> createModuleToFunctionPassAdaptor basically creates a adaptor that applies 
>> the pass to all function on the module.
>
> It's always good to make the pass as specific as possible (e.g. prefer a 
> function pass rather than a module pass) so it doesn't have to worry about 
> infra. For example, just iterating over functions doesn't skip declarations.

I modeled it after AlwaysInlinerPass, since it seems that it was enabled at -O0 
as well. To keep EntryExitInstrumenterPass a function pass and enable it with 
-O0 I think we will need a way to communicate to the pass manager that the pass 
should be run even with optnone, my understanding was that a ModulePass will 
the way to do it. Do we have a way to advertise that a function pass should be 
run regardless of ' optnone' ?

> The whole point of `isRequired()` is to make the pass always run when it's 
> added to the pipeline, so making it a module pass shouldn't be necessary with 
> that line.

Indeed, I have added to fix a testcase but it does seem unrequired. I will 
remove it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96803

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

[PATCH] D96875: [flang][driver] Add -fdebug-module-writer option

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski added a comment.

Thank you for submitting this @arnamoy10 ! Comments inline.




Comment at: clang/include/clang/Driver/Options.td:4232-4233
   HelpText<"Use INTEGER(KIND=8) for the result type in size-related 
intrinsics.">;
+def fdebug_module_writer : Flag<["-"],"fdebug-module-writer">, Group, 
+  HelpText<"Enables showing debug messages while writing module files.">;
 }

IMO this should be a frontend-only option. Compiler end-users are unlikely to 
need this in their regular workflows, right?  I recommend moving it [[ 
https://github.com/llvm/llvm-project/blob/adfd3c7083f9808d145239153c10f72eece485d8/clang/include/clang/Driver/Options.td#L4262-L4272
 | here ]].



Comment at: flang/test/Semantics/mod-file-rewriter.f90:9
+! RUN: %flang-new -fsyntax-only -fdebug-module-writer 
%p/Inputs/mod-file-unchanged.f90 2>&1 | FileCheck %s --check-prefix 
CHECK_UNCHANGED
+! RUN: %flang-new -fsyntax-only -fdebug-module-writer 
%p/Inputs/mod-file-changed.f90 2>&1 | FileCheck %s --check-prefix CHECK_CHANGED
 

arnamoy10 wrote:
> tskeith wrote:
> > Why do you need to duplicate these lines? Doesn't it work to use `%flang`?
> `%flang` will unfortunately invoke `f18` currently.
That depends on the value of `FLANG_BUILD_NEW_DRIVER`, which is translated into 
`include_flang_new_driver_test` [[ 
https://github.com/llvm/llvm-project/blob/adfd3c7083f9808d145239153c10f72eece485d8/flang/test/lit.cfg.py#L74-L85
 | here ]]. I also think that this should work fine with `%flang`.

Also, I suggest that we only have tests with `flang_fc1` and keep this as a 
frontend-only option.


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

https://reviews.llvm.org/D96875

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

[PATCH] D96751: [clangd] Populate detail field in document symbols

[Sam McCall via Phabricator via cfe-commits]

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

Nice! This looks good to land as-is, I just have some suggestions where we may 
want to mark behavior to revisit later, and some places where we could trim the 
tests a bit.

Do you have commit access, or want me to land this for you? (I'd need an 
address for the commit)




Comment at: clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp:384
+ AllOf(WithName("Foo"), WithKind(SymbolKind::Constructor),
+   WithDetail("void ()"), Children()),
+ AllOf(WithName("Foo"), WithKind(SymbolKind::Constructor),

the void return type isn't really meaningful

may want a FIXME here that `()` or `constructor()` would probably be better

(no need to fix though)



Comment at: clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp:392
+ AllOf(WithName("~Foo"), WithKind(SymbolKind::Constructor),
+   WithDetail("void ()"), Children()),
+ AllOf(WithName("Nested"), WithKind(SymbolKind::Class),

for destructors I think we should probably suppress detail entirely - signature 
is always the same and it's clear from the name it's a destructor.



Comment at: clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp:490
+  ElementsAre(
+  AllOf(WithName("foo"), WithDetail("void ()")),
+  AllOf(WithName("Foo"), WithDetail("class")),

up to you, but we don't need to add WithDetail() assertions everywhere, 
probably just enough to ensure we cover the interesting cases.

We could leave out these ones, exportContext, noLocals etc that are really 
testing other things.



Comment at: clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp:588
   AllOf(WithName("Tmpl"), WithKind(SymbolKind::Struct),
-Children(WithName("y"))),
+WithDetail("struct"),
+Children(AllOf(WithName("y"), WithDetail("int",

feels like this could benefit from being "specialization struct" or so, 
"specialization int" below etc.

Again, this is a possible FIXME comment, not something that needs to be done 
now.



Comment at: clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp:630
   ElementsAreArray<::testing::Matcher>(
-  {AllOf(WithName("ans1"),
- Children(AllOf(WithName("ai1"), Children()),
-  AllOf(WithName("ans2"), Children(WithName("ai2"),
-   AllOf(WithName("(anonymous namespace)"), 
Children(WithName("test"))),
-   AllOf(WithName("na"),
- Children(AllOf(WithName("nb"), Children(WithName("Foo"),
-   AllOf(WithName("na"),
- Children(AllOf(WithName("nb"), 
Children(WithName("Bar")}));
+  {AllOf(WithName("ans1"), WithDetail(""),
+ Children(AllOf(WithName("ai1"), WithDetail("int"), 
Children()),

(all these WithDetail("")s seem pretty redundant)


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

https://reviews.llvm.org/D96751

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

[PATCH] D92220: [clangd] Add support for static fields in rename

[Kirill Bobyrev via Phabricator via cfe-commits]

kbobyrev abandoned this revision.
kbobyrev added a comment.

Yeah this does indeed already work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92220

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

[PATCH] D96719: [clang-tidy] Add new check 'bugprone-thread-canceltype-asynchronous' and alias 'cert-pos47-c'.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/ThreadCanceltypeAsynchronousCheck.cpp:38
+};
+const auto TryExpandAsInteger =
+[](Preprocessor::macro_iterator It) -> Optional {

balazske wrote:
> aaron.ballman wrote:
> > Do we know that POSIX implementations always use a simple integer here, or 
> > do we have to worry about code like:
> > ```
> > #define PTHREAD_CANCEL_ASYNCHRONOUS (1 << 0)
> > ```
> > or
> > ```
> > #define PTHREAD_CANCEL_ASYNCHRONOUS SOME_OTHER_MACRO
> > ```
> Theoretically it is possible that the macro is defined not as a simple number 
> ([[https://pubs.opengroup.org/onlinepubs/9699919799/ | at this page ]] see 
> "Symbolic Constant"). But I am not sure if it is possible to get the value 
> from the preprocessor for any constant expression.
> 
> There is a similar function `tryExpandAsInteger` already in clang 
> (CheckerHelpers.cpp) that can be reused here, probably it retrieves the macro 
> definition better. The function could be put into one of the "utils" files, 
> maybe **LexerUtils.h**, it is already needed at 2 places 
> (bad-signal-to-kill-thread and here).
> 
Having a single place to get this information would be an improvement, but not 
necessary for this patch. If you don't know of a POSIX implementation that uses 
something other than a positive integer literal for the expansion, I think the 
current code is fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96719

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

[PATCH] D96856: [clangd] Narrow and document a loophole in blockUntilIdle

[Sam McCall via Phabricator via cfe-commits]

sammccall updated this revision to Diff 324609.
sammccall added a comment.

Revert unintended changes, add FIXME


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96856

Files:
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h


Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -335,6 +335,8 @@
 
   // Blocks the main thread until the server is idle. Only for use in tests.
   // Returns false if the timeout expires.
+  // FIXME: various subcomponents each get the full timeout, so it's more of
+  // an order of magnitude than a hard deadline.
   LLVM_NODISCARD bool
   blockUntilIdleForTest(llvm::Optional TimeoutSeconds = 10);
 
Index: clang-tools-extra/clangd/ClangdServer.cpp
===
--- clang-tools-extra/clangd/ClangdServer.cpp
+++ clang-tools-extra/clangd/ClangdServer.cpp
@@ -859,10 +859,34 @@
 
 LLVM_NODISCARD bool
 ClangdServer::blockUntilIdleForTest(llvm::Optional TimeoutSeconds) {
-  return WorkScheduler.blockUntilIdle(timeoutSeconds(TimeoutSeconds)) &&
- CDB.blockUntilIdle(timeoutSeconds(TimeoutSeconds)) &&
- (!BackgroundIdx ||
-  BackgroundIdx->blockUntilIdleForTest(TimeoutSeconds));
+  // Order is important here: we don't want to block on A and then B,
+  // if B might schedule work on A.
+
+  // Nothing else can schedule work on TUScheduler, because it's not threadsafe
+  // and we're blocking the main thread.
+  if (!WorkScheduler.blockUntilIdle(timeoutSeconds(TimeoutSeconds)))
+return false;
+
+  // Unfortunately we don't have strict topological order between the rest of
+  // the components. E.g. CDB broadcast triggers backrgound indexing.
+  // This queries the CDB which may discover new work if disk has changed.
+  //
+  // So try each one a few times in a loop.
+  // If there are no tricky interactions then all after the first are no-ops.
+  // Then on the last iteration, verify they're idle without waiting.
+  //
+  // There's a small chance they're juggling work and we didn't catch them :-(
+  for (llvm::Optional Timeout :
+   {TimeoutSeconds, TimeoutSeconds, llvm::Optional(0)}) {
+if (!CDB.blockUntilIdle(timeoutSeconds(Timeout)))
+  return false;
+if (BackgroundIdx && !BackgroundIdx->blockUntilIdleForTest(Timeout))
+  return false;
+  }
+
+  assert(WorkScheduler.blockUntilIdle(Deadline::zero()) &&
+ "Something scheduled work while we're blocking the main thread!");
+  return true;
 }
 
 void ClangdServer::profile(MemoryTree &MT) const {


Index: clang-tools-extra/clangd/ClangdServer.h
===
--- clang-tools-extra/clangd/ClangdServer.h
+++ clang-tools-extra/clangd/ClangdServer.h
@@ -335,6 +335,8 @@
 
   // Blocks the main thread until the server is idle. Only for use in tests.
   // Returns false if the timeout expires.
+  // FIXME: various subcomponents each get the full timeout, so it's more of
+  // an order of magnitude than a hard deadline.
   LLVM_NODISCARD bool
   blockUntilIdleForTest(llvm::Optional TimeoutSeconds = 10);
 
Index: clang-tools-extra/clangd/ClangdServer.cpp
===
--- clang-tools-extra/clangd/ClangdServer.cpp
+++ clang-tools-extra/clangd/ClangdServer.cpp
@@ -859,10 +859,34 @@
 
 LLVM_NODISCARD bool
 ClangdServer::blockUntilIdleForTest(llvm::Optional TimeoutSeconds) {
-  return WorkScheduler.blockUntilIdle(timeoutSeconds(TimeoutSeconds)) &&
- CDB.blockUntilIdle(timeoutSeconds(TimeoutSeconds)) &&
- (!BackgroundIdx ||
-  BackgroundIdx->blockUntilIdleForTest(TimeoutSeconds));
+  // Order is important here: we don't want to block on A and then B,
+  // if B might schedule work on A.
+
+  // Nothing else can schedule work on TUScheduler, because it's not threadsafe
+  // and we're blocking the main thread.
+  if (!WorkScheduler.blockUntilIdle(timeoutSeconds(TimeoutSeconds)))
+return false;
+
+  // Unfortunately we don't have strict topological order between the rest of
+  // the components. E.g. CDB broadcast triggers backrgound indexing.
+  // This queries the CDB which may discover new work if disk has changed.
+  //
+  // So try each one a few times in a loop.
+  // If there are no tricky interactions then all after the first are no-ops.
+  // Then on the last iteration, verify they're idle without waiting.
+  //
+  // There's a small chance they're juggling work and we didn't catch them :-(
+  for (llvm::Optional Timeout :
+   {TimeoutSeconds, TimeoutSeconds, llvm::Optional(0)}) {
+if (!CDB.blockUntilIdle(timeoutSeconds(Timeout)))
+  return false;
+if (BackgroundIdx && !BackgroundIdx->blockUntilIdleForTest(Timeout))
+  

[PATCH] D96856: [clangd] Narrow and document a loophole in blockUntilIdle

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

Doh, sorry about the garbled patch




Comment at: clang-tools-extra/clangd/ClangdServer.cpp:893
+  for (llvm::Optional Timeout :
+   {TimeoutSeconds, TimeoutSeconds, llvm::Optional(0)}) {
+if (!CDB.blockUntilIdle(timeoutSeconds(Timeout)))

kadircet wrote:
> this is extending the Deadline in theory, e.g. if user requested idleness in 
> 10 seconds, this can now wait for up to 20 seconds. but this was possible in 
> the previous case too, e.g. CDB could block for 10 seconds, and then bgindex 
> would block for another 10 seconds, and mentioned this is only for tests, so 
> should be fine (but might be worth mentioning in the comments.)
Right - the idea with Deadline is it's something absolute you can pass around, 
and here we are creating a new one for each call.

This is wrong, but it's consistent with the code before this patch and I'd 
rather not fix both at once. Added a FIXME to the header.

(To fix this we'd want to change the signature of BackgroundIndex to take a 
Deadline too)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96856

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

[PATCH] D96719: [clang-tidy] Add new check 'bugprone-thread-canceltype-asynchronous' and alias 'cert-pos47-c'.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp:114
 "cert-pos44-c");
+
CheckFactories.registerCheck(
+"cert-pos47-c");

80-col issue?



Comment at: 
clang-tools-extra/clang-tidy/concurrency/ThreadCanceltypeAsynchronousCheck.cpp:34
+  if (!PthreadCancelAsynchronousValue) {
+const auto IsAsynchronous = [](const auto &KeyValue) -> bool {
+  return KeyValue.first->getName() == "PTHREAD_CANCEL_ASYNCHRONOUS" &&

Drop the top-level `const` unless it's a pointer/reference to a `const` object 
(here and elsewhere in the patch).



Comment at: clang-tools-extra/docs/clang-tidy/checks/list.rst:98
`bugprone-terminating-continue `_, "Yes"
+   `bugprone-thread-canceltype-asynchronous 
`_, "No"
`bugprone-throw-keyword-missing `_,

It looks like this file needs to be updated from the rename.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96719

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

[PATCH] D96875: [flang][driver] Add -fdebug-module-writer option

[Arnamoy B via Phabricator via cfe-commits]

arnamoy10 added inline comments.



Comment at: clang/include/clang/Driver/Options.td:4232-4233
   HelpText<"Use INTEGER(KIND=8) for the result type in size-related 
intrinsics.">;
+def fdebug_module_writer : Flag<["-"],"fdebug-module-writer">, Group, 
+  HelpText<"Enables showing debug messages while writing module files.">;
 }

awarzynski wrote:
> IMO this should be a frontend-only option. Compiler end-users are unlikely to 
> need this in their regular workflows, right?  I recommend moving it [[ 
> https://github.com/llvm/llvm-project/blob/adfd3c7083f9808d145239153c10f72eece485d8/clang/include/clang/Driver/Options.td#L4262-L4272
>  | here ]].
Yes, it makes sense to keep it as frontend-only option, let me submit an 
updated patch.



Comment at: flang/test/Semantics/mod-file-rewriter.f90:9
+! RUN: %flang-new -fsyntax-only -fdebug-module-writer 
%p/Inputs/mod-file-unchanged.f90 2>&1 | FileCheck %s --check-prefix 
CHECK_UNCHANGED
+! RUN: %flang-new -fsyntax-only -fdebug-module-writer 
%p/Inputs/mod-file-changed.f90 2>&1 | FileCheck %s --check-prefix CHECK_CHANGED
 

awarzynski wrote:
> arnamoy10 wrote:
> > tskeith wrote:
> > > Why do you need to duplicate these lines? Doesn't it work to use `%flang`?
> > `%flang` will unfortunately invoke `f18` currently.
> That depends on the value of `FLANG_BUILD_NEW_DRIVER`, which is translated 
> into `include_flang_new_driver_test` [[ 
> https://github.com/llvm/llvm-project/blob/adfd3c7083f9808d145239153c10f72eece485d8/flang/test/lit.cfg.py#L74-L85
>  | here ]]. I also think that this should work fine with `%flang`.
> 
> Also, I suggest that we only have tests with `flang_fc1` and keep this as a 
> frontend-only option.
Sounds good.


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

https://reviews.llvm.org/D96875

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

[clang-tools-extra] af06ff1 - add -use-color option to clang-tidy-diff.py

[Aaron Ballman via cfe-commits]

Author: Jonas Otto
Date: 2021-02-18T09:12:48-05:00
New Revision: af06ff1cf87ecd387a65a6f7d4d00e0b06e983fb

URL: 
https://github.com/llvm/llvm-project/commit/af06ff1cf87ecd387a65a6f7d4d00e0b06e983fb
DIFF: 
https://github.com/llvm/llvm-project/commit/af06ff1cf87ecd387a65a6f7d4d00e0b06e983fb.diff

LOG: add -use-color option to clang-tidy-diff.py

Clang-tidy seems to output color only when printing directly to
terminal, but an option to force color-output has been added in
https://reviews.llvm.org/D7947

Added: 


Modified: 
clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/tool/clang-tidy-
diff .py b/clang-tools-extra/clang-tidy/tool/clang-tidy-
diff .py
index 17086d15053e..6bd05531333b 100755
--- a/clang-tools-extra/clang-tidy/tool/clang-tidy-
diff .py
+++ b/clang-tools-extra/clang-tidy/tool/clang-tidy-
diff .py
@@ -142,6 +142,8 @@ def main():
   help='checks filter, when not specified, use clang-tidy '
   'default',
   default='')
+  parser.add_argument('-use-color', action='store_true',
+  help='Use colors in output')
   parser.add_argument('-path', dest='build_path',
   help='Path used to read a compile command database.')
   if yaml:
@@ -225,6 +227,8 @@ def main():
 common_clang_tidy_args.append('-quiet')
   if args.build_path is not None:
 common_clang_tidy_args.append('-p=%s' % args.build_path)
+  if args.use_color:
+common_clang_tidy_args.append('--use-color')
   for arg in args.extra_arg:
 common_clang_tidy_args.append('-extra-arg=%s' % arg)
   for arg in args.extra_arg_before:



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

[PATCH] D96561: [clang-tidy] add -use-color option to clang-tidy-diff.py

[Aaron Ballman via Phabricator via cfe-commits]

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

In D96561#2571193 , @ottojo wrote:

> I can't commit this myself, as i don't have commit access to the repo.

Thanks for letting me know -- I've commit on your behalf in 
af06ff1cf87ecd387a65a6f7d4d00e0b06e983fb 
. Thank 
you for the patch!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96561

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

[PATCH] D96944: [RecoveryAST] Add design doc to clang internal manual.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 324616.
hokein marked 4 inline comments as done.
hokein added a comment.

address review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96944

Files:
  clang/docs/InternalsManual.rst

Index: clang/docs/InternalsManual.rst
===
--- clang/docs/InternalsManual.rst
+++ clang/docs/InternalsManual.rst
@@ -1863,6 +1863,144 @@
 are not ``Redeclarable`` -- in that case, a ``Mergeable`` base class is used
 instead).
 
+Error Handling
+--
+
+Clang produces an AST even when the code contains errors. Clang won't generate
+and optimize code for it, but it's used as parsing continues to detect further
+errors in the input. Clang-based tools also depend on such ASTs, and IDEs in
+particular benefit from a high-quality AST for broken code.
+
+In presence of errors, clang uses a few error-recovery strategies to present the
+broken code in the AST:
+
+- correcting errors: in cases where clang is confident about the fix, it
+  provides a FixIt attaching to the error diagnostic and emits a corrected AST
+  (reflecting the written code with FixIts applied). The advantage of that is to
+  provide more accurate subsequent diagnostics. Typo correction is a typical
+  example.
+- representing invalid node: the invalid node is preserved in the AST in some
+  form, e.g. when the "declaration" part of the declaration contains semantic
+  errors, the Decl node is marked as invalid.
+- dropping invalid node: this often happens for errors that we don’t have
+  graceful recovery. Prior to Recovery AST, a mismatched-argument function call
+  expression was dropped though a CallExpr was created for semantic analysis.
+
+With these strategies, clang surfaces better diagnostics, and provides AST
+consumers a rich AST reflecting the written source code as much as possible even
+for broken code.
+
+Recovery AST
+
+
+The idea of Recovery AST is to use recovery nodes which act as a placeholder to
+maintain the rough structure of the parsing tree, preserve locations and
+children but have no language semantics attached to them.
+
+For example, consider the following mismatched function call:
+
+.. code-block:: c++
+
+   int NoArg();
+   void test(int abc) {
+ NoArg(abc); // oops, mismatched function arguments.
+   }
+
+Without Recovery AST, the invalid function call expression (and its child
+expressions) would be dropped in the AST:
+
+::
+
+|-FunctionDecl  NoArg 'int ()'
+`-FunctionDecl  test 'void (int)'
+ |-ParmVarDecl  col:15 used abc 'int'
+ `-CompoundStmt 
+
+
+With Recovery AST, the AST looks like:
+
+::
+
+|-FunctionDecl  NoArg 'int ()'
+`-FunctionDecl  test 'void (int)'
+  |-ParmVarDecl  used abc 'int'
+  `-CompoundStmt 
+`-RecoveryExpr  'int' contains-errors
+  |-UnresolvedLookupExpr  '' lvalue (ADL) = 'NoArg'
+  `-DeclRefExpr  'int' lvalue ParmVar 'abc' 'int'
+
+
+An alternative is to use existing Exprs, e.g. CallExpr for the above example.
+This would capture more call details (e.g. locations of parentheses) and allow
+it to be treated uniformly with valid CallExprs. However, jamming the data we
+have into CallExpr forces us to weaken its invariants, e.g. arg count may be
+wrong. This would introduce a huge burden on consumers of the AST to handle such
+"impossible" cases. So when we're representing (rather than correcting) errors,
+we use a distinct recovery node type with extremely weak invariants instead.
+
+``RecoveryExpr`` is the only recovery node so far. In practice, broken decls
+need more detailed semantics preserved (the current ``Invalid`` flag works
+fairly well), and completely broken statements with interesting internal
+structure are rare (so dropping the statements is OK).
+
+Types and dependence
+
+
+``RecoveryExpr`` is an ``Expr``, so it must have a type. In many cases the true
+type can't really be known until the code is corrected (e.g. a call to a
+function that doesn't exist). And it means that we can't properly perform type
+checks on some containing constructs, such as ``return 42 + unknownFunction()``.
+
+To model this, we generalize the concept of dependence from C++ templates to
+mean dependence on a template parameter or how an error is repaired. The
+``RecoveryExpr`` ``unknownFunction()`` has the totally unknown type
+``DependentTy``, and this suppresses type-based analysis in the same way it
+would inside a template.
+
+In cases where we are confident about the concrete type (e.g. the return type
+for a broken non-overloaded function call), the ``RecoveryExpr`` will have this
+type. This allows more code to be typechecked, and produces a better AST and
+more diagnostics. For example:
+
+.. code-block:: C++
+
+   unknownFunction().size() // .size() is a CXXDependentScopeMemberExpr
+   std::string(42).size() // 

[PATCH] D96944: [RecoveryAST] Add design doc to clang internal manual.

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: clang/docs/InternalsManual.rst:1882
+  example.
+- representing invalid node: the invalid node is preserved in the AST in some
+  form, e.g. when the "declaration" part of the declaration contains semantic

kadircet wrote:
> rather than `some form` maybe say `while indicating the error` ?
I'm not sure this will be better. `indicating error` seems to be a bit strong.

e.g. `if () {}`, this ill-formed statement, the AST node  is like below, which 
doesn't have an obvious error signal (we could argue the `OpaqueValueExpr` is )

```
`-IfStmt
   |-OpaqueValueExpr 'bool'
   `-CompoundStmt 
```



Comment at: clang/docs/InternalsManual.rst:1886
+- dropping invalid node: this often happens for errors that we don’t have
+  graceful recovery, prior to Recovery AST, a mismatched-argument function call
+  expression was dropped though a CallExpr was created for semantic analysis.

kadircet wrote:
> so far we've always been talking about the current state right? comparison to 
> past seems surprising now. can we have a couple of examples for the cases 
> that we still drop the nodes today?
> . can we have a couple of examples for the cases that we still drop the nodes 
> today?

The concern of giving a dropped example is that it might be stale once it gets 
preserved and recovered in the future. So personally, I'd prefer to give a true 
example, it was the mismatched-argument function call.

I guess this is not too hard for readers to come up with an example, a pretty 
broken statement would be the case.



Comment at: clang/docs/InternalsManual.rst:1933
+
+An alternative is to use existing Exprs, e.g. CallExpr for the above example.
+The basic trade off is that jamming the data we have into CallExpr forces us to

kadircet wrote:
> this talks about why it would be hard to make use of `CallExpr`s but doesn't 
> say what we would gain by doing so. I suppose it would come with the benefit 
> of preserving more details about the source code, like locations for 
> parantheses and knowing the type of the expr? (or are these still accessible 
> e.g. do we have an enum in RecoveryExpr telling us about its type?)
yeah, this is good point. added.





Comment at: clang/docs/InternalsManual.rst:1959
+
+In cases where we are confident about the concrete type (e.g. the return type
+for a broken non-overloaded function call), the ``RecoveryExpr`` will have this

kadircet wrote:
> that's great to know! i would expect it to be there already, but i think we 
> should have this as a comment within the code too, so that future maintainers 
> can feel confident when setting the type of a recovery expr.
yeah, we already have this in the comment of `RecoveryExpr`.



Comment at: clang/docs/InternalsManual.rst:1971
+considered value-dependent, because its value isn't well-defined until the 
error
+is resolved. Among other things, this means that clang doesn't emit more errors
+where a RecoveryExpr is used as a constant (e.g. array size), but also won't 
try

kadircet wrote:
> IIRC, there were other problems with clang trying to emit secondary diags on 
> such cases. It might be worth mentioning those too, again to warn future 
> travellers about the side effects of making this non-value-dependent.
I think the existing `doesn't emit more errors` texts already indicate we 
suppress the secondary diags etc.



Comment at: clang/docs/InternalsManual.rst:1978
+
+Beyond the template dependence bits, we add a new “ContainsErrors” bit to
+express “Does this expression or this or anything within it contain errors”

kadircet wrote:
> might be worth mentioning this only exists for expressions.
in reality, they are complicated, these bits (template, contains-errors) are 
not only for expressions, but also for Type, NestedNameSpecifier, 
TemplateArgument.



Comment at: clang/docs/InternalsManual.rst:1979
+Beyond the template dependence bits, we add a new “ContainsErrors” bit to
+express “Does this expression or this or anything within it contain errors”
+semantic, this bit is always set for RecoveryExpr, and propagated to parent

kadircet wrote:
> not sure what second `this` is for
oh, removed it.



Comment at: clang/docs/InternalsManual.rst:1980
+express “Does this expression or this or anything within it contain errors”
+semantic, this bit is always set for RecoveryExpr, and propagated to parent
+nodes, this provides a fast way to query whether any (recursive) child of an

kadircet wrote:
> this sounds like it is propagated all the way to the TUDecl, but i suppose 
> that's not the case. can you elaborate on when the propagation stops?
you're right, but the whole propagation process is complex, I think it needs 
more words to explain how and when it stops

[PATCH] D96381: [AArch64] Adding SHA3 Intrinsics support

[David Spickett via Phabricator via cfe-commits]

DavidSpickett added a comment.

The approach for xar looks fine to me, matches how we handled vcvt_n_* 
(https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics?search=vcvt_n_).




Comment at: clang/include/clang/Basic/arm_neon.td:1139
+def BCAX : SInst<"vbcax", "", "QUcQUsQUiQUlQsQcQiQl">;
+def EOR3 : SInst<"veor3", "", "QUcQUsQUiQUlQsQcQiQl">;
+def RAX1 : SInst<"vrax1", "...", "QUl">;

Put the second set in c-s-i-l order like the first.



Comment at: llvm/lib/Target/AArch64/AArch64InstrInfo.td:928
+
+class SHA512H_pattern
+  : Pat<(v2i64 (OpNode (v2i64 V128:$Vd), (v2i64 V128:$Vn), (v2i64 V128:$Vm))),

This is unused.



Comment at: llvm/test/CodeGen/AArch64/neon-sha3.ll:105
+declare <4 x i32> @llvm.aarch64.crypto.eor3s.v4i32(<4 x i32>, <4 x i32>, <4 x 
i32>)
+declare <2 x i64> @llvm.aarch64.crypto.eor3s.v2i64(<2 x i64>, <2 x i64>, <2 x 
i64>)
+

I'm not sure you need to declare variants you aren't using but in any case you 
should test the missing ones e.g. crypto.eor3u.v8i16.
Maybe there's an argument that it isn't very useful to test them all like this 
but the other files follow this pattern so might as well.


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

https://reviews.llvm.org/D96381

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

[PATCH] D96832: [Clang][Attributes] Allow not_tail_called attribute to be applied to virtual function.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:4109
-  [[clang::not_tail_called]] int foo2() override;
-};
   }];

ahatanak wrote:
> Quuxplusone wrote:
> > (Moving into a thread)
> > 
> > > This patch doesn't prevent the call to method in the code below from 
> > > being tail called,
> > > but I suppose users would expect the attribute to prevent the tail call?
> > ```
> > struct B {
> >   virtual void method();  
> > };
> > struct D : B {
> >   [[clang::not_tail_called]] void method() override; 
> > };
> > ```
> > 
> > The way virtual calls are handled in C++ is, all attributes and properties 
> > of the call are determined based on the //static// type at the call site; 
> > and then the //runtime destination// of the call is determined from the 
> > pointer in the vtable. Attributes and properties have no runtime existence, 
> > and so they physically cannot affect anything at runtime. Consider 
> > https://godbolt.org/z/P3799e :
> > 
> > ```
> > struct Ba {
> >   virtual Ba *method(int x = 1);  
> > };
> > struct Da : Ba {
> >   [[clang::not_tail_called]] [[nodiscard]] Da *method(int x = 2) noexcept 
> > override; 
> > };
> > auto callera(Da& da) {
> > Ba& ba = da;
> > ba.method();
> > }
> > ```
> > Here the call that is made is a //virtual// call (because `Ba::method` is 
> > virtual); with a default argument value of `1` (because `Ba::method`'s `x` 
> > parameter has a default value of `1`); and it returns something of type 
> > `Ba*` (because that's what `Ba::method` returns); and it is not considered 
> > to be noexcept (because `Ba::method` isn't marked noexcept); and it's okay 
> > to discard the result (because `Ba::method` is not nodiscard) and it is 
> > tail-called (because `Ba::method` doesn't disallow tail calls). All of 
> > these attributes and properties are based on the //static// type of 
> > variable `ba`, despite the fact that //at runtime// we'll end up jumping to 
> > the code for `Da::method`. According to the source code, statically, 
> > `Da::method` has a default argument of `2`, returns `Da*`, is noexcept, and 
> > is nodiscard, and disallows tail-calls. But we're not calling 
> > `da.method()`, we're calling `ba.method()`; so none of that matters to our 
> > call site at `callera`.
> > 
> > I think this patch is a good thing.
> OK, I see. I think this patch is fine then.
> 
> Should we add an explanation of how virtual functions are handled? The doc 
> currently just says the attribute prevents tail-call optimization on 
> statically bound calls.
> I think this patch is a good thing.

I agree with your explanation but I'm not certain I agree with your conclusion. 
:-) I think the examples you point out are more often a source of confusion for 
users than not because of the nature of static vs dynamic dispatch, and so 
saying "this behavior can be consistent with all of these other things people 
often get confused by" may be justifiable but also seems a bit user-hostile.

Taking a slightly different example:
```
struct Ba {
  [[clang::not_tail_called]] virtual Ba *method();  
};
struct Da : Ba {
  Ba *method() override; 
};

void callera(Da& da) {
Ba& ba = da;
ba.method();
}
```
There's no guarantee that `Ba::method()` and `Da::method()` have the same 
not-tail-called properties. The codegen for this case will still attach 
`notail` to the call site even though the dynamic target may not meet that 
requirement.

tl;dr: I think `notail` is a property of the call expression and the only way 
to know that's valid is when you know what's being called, so the current 
behavior is more user-friendly for avoiding optimization issues. I'd prefer not 
to relax that unless there was a significantly motivating example beyond what's 
presented here so far.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96832

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

[PATCH] D96719: [clang-tidy] Add new check 'bugprone-thread-canceltype-asynchronous' and alias 'cert-pos47-c'.

[Balázs Kéri via Phabricator via cfe-commits]

balazske added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/ThreadCanceltypeAsynchronousCheck.cpp:38
+};
+const auto TryExpandAsInteger =
+[](Preprocessor::macro_iterator It) -> Optional {

aaron.ballman wrote:
> balazske wrote:
> > aaron.ballman wrote:
> > > Do we know that POSIX implementations always use a simple integer here, 
> > > or do we have to worry about code like:
> > > ```
> > > #define PTHREAD_CANCEL_ASYNCHRONOUS (1 << 0)
> > > ```
> > > or
> > > ```
> > > #define PTHREAD_CANCEL_ASYNCHRONOUS SOME_OTHER_MACRO
> > > ```
> > Theoretically it is possible that the macro is defined not as a simple 
> > number ([[https://pubs.opengroup.org/onlinepubs/9699919799/ | at this page 
> > ]] see "Symbolic Constant"). But I am not sure if it is possible to get the 
> > value from the preprocessor for any constant expression.
> > 
> > There is a similar function `tryExpandAsInteger` already in clang 
> > (CheckerHelpers.cpp) that can be reused here, probably it retrieves the 
> > macro definition better. The function could be put into one of the "utils" 
> > files, maybe **LexerUtils.h**, it is already needed at 2 places 
> > (bad-signal-to-kill-thread and here).
> > 
> Having a single place to get this information would be an improvement, but 
> not necessary for this patch. If you don't know of a POSIX implementation 
> that uses something other than a positive integer literal for the expansion, 
> I think the current code is fine.
I found that it is good to rely on `isExpandedFromMacro` AST matcher instead of 
this whole `tryExpandAsInteger` function. The current solution can find only 
cases where the macro is defined as an integer literal. If 
`isExpandedFromMacro` is used it will work at least in all cases regardless of 
the value of the macro. It will not work if a variable is used to pass the 
value, but this does not work in the current code either.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96719

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

[PATCH] D96113: [ASTMatchers] Fix hasParent while ignoring unwritten nodes

[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.

In D96113#2569441 , @steveire wrote:

> Update

Thanks for the extra context, that's useful -- LGTM!




Comment at: clang/lib/AST/ParentMapContext.cpp:174
+{
+  auto AncestorNodes = matchParents(
+  ParentList, this);

steveire wrote:
> aaron.ballman wrote:
> > Not needing to be solved in this patch, but do we eventually need to do 
> > something for `ObjCForCollectionStmt` the same as we do for 
> > `CXXForRangeStmt`?
> Perhaps. I'm not familiar with it.
I'm not super familiar with it myself, but I know it uses `for (element in 
expression)` as the syntax which seems awfully similar to `for (auto decl : 
expr)` in C++ which is why I thought of it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96113

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

[PATCH] D96719: [clang-tidy] Add new check 'bugprone-thread-canceltype-asynchronous' and alias 'cert-pos47-c'.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/ThreadCanceltypeAsynchronousCheck.cpp:38
+};
+const auto TryExpandAsInteger =
+[](Preprocessor::macro_iterator It) -> Optional {

balazske wrote:
> aaron.ballman wrote:
> > balazske wrote:
> > > aaron.ballman wrote:
> > > > Do we know that POSIX implementations always use a simple integer here, 
> > > > or do we have to worry about code like:
> > > > ```
> > > > #define PTHREAD_CANCEL_ASYNCHRONOUS (1 << 0)
> > > > ```
> > > > or
> > > > ```
> > > > #define PTHREAD_CANCEL_ASYNCHRONOUS SOME_OTHER_MACRO
> > > > ```
> > > Theoretically it is possible that the macro is defined not as a simple 
> > > number ([[https://pubs.opengroup.org/onlinepubs/9699919799/ | at this 
> > > page ]] see "Symbolic Constant"). But I am not sure if it is possible to 
> > > get the value from the preprocessor for any constant expression.
> > > 
> > > There is a similar function `tryExpandAsInteger` already in clang 
> > > (CheckerHelpers.cpp) that can be reused here, probably it retrieves the 
> > > macro definition better. The function could be put into one of the 
> > > "utils" files, maybe **LexerUtils.h**, it is already needed at 2 places 
> > > (bad-signal-to-kill-thread and here).
> > > 
> > Having a single place to get this information would be an improvement, but 
> > not necessary for this patch. If you don't know of a POSIX implementation 
> > that uses something other than a positive integer literal for the 
> > expansion, I think the current code is fine.
> I found that it is good to rely on `isExpandedFromMacro` AST matcher instead 
> of this whole `tryExpandAsInteger` function. The current solution can find 
> only cases where the macro is defined as an integer literal. If 
> `isExpandedFromMacro` is used it will work at least in all cases regardless 
> of the value of the macro. It will not work if a variable is used to pass the 
> value, but this does not work in the current code either.
That's a good point! I don't think it's important to handle the case where a 
variable or an integer literal is used as the function call argument; we can 
tackle those cases if they crop up in practice and there's a need.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96719

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

[PATCH] D96542: [clang-tidy] Fix `TransformerClangTidyCheck`'s handling of include insertions.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added inline comments.



Comment at: clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.cpp:108
+  Diag << Inserter.createIncludeInsertion(
+  Result.SourceManager->getFileID(T.Range.getBegin()), T.Replacement);
   break;

alexfh wrote:
> Can this be a macro file id? I'd suggest to add tests (probably for checks 
> using this functionality) with a few nested includes and fixes in normal 
> code, code in macros declared and expanded in different files, locations in 
> macro bodies, macro arguments, and some tricky cases like fix pointing to a 
> pasted token.
> Can this be a macro file id? I'd suggest to add tests (probably for checks 
> using this functionality) with a few nested includes and fixes in normal 
> code, code in macros declared and expanded in different files, locations in 
> macro bodies, macro arguments, and some tricky cases like fix pointing to a 
> pasted token.

Unlikely, given that API that populates the location. Most use a default verion 
which explicitly maps the location to the expansion location. However, it is 
possible. Also, Transformer rejects changes inside macros (except arguments) so 
that would also be hard to engineer.

Still, I'll look into better tests in the check itself. I did try that but 
mostly failed because the lit tests don't support checking anything in headers. 
However, the macro checks sound worth it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96542

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

[clang] e4d5f00 - [ASTMatchers] Fix hasParent while ignoring unwritten nodes

[Stephen Kelly via cfe-commits]

Author: Stephen Kelly
Date: 2021-02-18T15:04:03Z
New Revision: e4d5f00093bec4099f1d0496181dc670c42ac220

URL: 
https://github.com/llvm/llvm-project/commit/e4d5f00093bec4099f1d0496181dc670c42ac220
DIFF: 
https://github.com/llvm/llvm-project/commit/e4d5f00093bec4099f1d0496181dc670c42ac220.diff

LOG: [ASTMatchers] Fix hasParent while ignoring unwritten nodes

For example, before this patch we can use has() to get from a
cxxRewrittenBinaryOperator to its operand, but hasParent doesn't get
back to the cxxRewrittenBinaryOperator.  This patch fixes that.

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

Added: 


Modified: 
clang/include/clang/AST/ParentMapContext.h
clang/lib/AST/ParentMapContext.cpp
clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp

Removed: 




diff  --git a/clang/include/clang/AST/ParentMapContext.h 
b/clang/include/clang/AST/ParentMapContext.h
index a0412380a864..2edbc987850d 100644
--- a/clang/include/clang/AST/ParentMapContext.h
+++ b/clang/include/clang/AST/ParentMapContext.h
@@ -64,9 +64,10 @@ class ParentMapContext {
   Expr *traverseIgnored(Expr *E) const;
   DynTypedNode traverseIgnored(const DynTypedNode &N) const;
 
+  class ParentMap;
+
 private:
   ASTContext &ASTCtx;
-  class ParentMap;
   TraversalKind Traversal = TK_AsIs;
   std::unique_ptr Parents;
 };

diff  --git a/clang/lib/AST/ParentMapContext.cpp 
b/clang/lib/AST/ParentMapContext.cpp
index cb4995312efa..4a3e0a99c8a6 100644
--- a/clang/lib/AST/ParentMapContext.cpp
+++ b/clang/lib/AST/ParentMapContext.cpp
@@ -49,7 +49,17 @@ DynTypedNode ParentMapContext::traverseIgnored(const 
DynTypedNode &N) const {
   return N;
 }
 
+template 
+std::tuple
+matchParents(const DynTypedNodeList &NodeList,
+ ParentMapContext::ParentMap *ParentMap);
+
+template  struct MatchParents;
+
 class ParentMapContext::ParentMap {
+
+  template  friend struct ::MatchParents;
+
   /// Contains parents of a node.
   using ParentVector = llvm::SmallVector;
 
@@ -117,11 +127,72 @@ class ParentMapContext::ParentMap {
 if (Node.getNodeKind().hasPointerIdentity()) {
   auto ParentList =
   getDynNodeFromMap(Node.getMemoizationData(), PointerParents);
-  if (ParentList.size() == 1 && TK == TK_IgnoreUnlessSpelledInSource) {
-const auto *E = ParentList[0].get();
-const auto *Child = Node.get();
-if (E && Child)
-  return AscendIgnoreUnlessSpelledInSource(E, Child);
+  if (ParentList.size() > 0 && TK == TK_IgnoreUnlessSpelledInSource) {
+
+const auto *ChildExpr = Node.get();
+
+{
+  // Don't match explicit node types because 
diff erent stdlib
+  // implementations implement this in 
diff erent ways and have
+  // 
diff erent intermediate nodes.
+  // Look up 4 levels for a cxxRewrittenBinaryOperator as that is
+  // enough for the major stdlib implementations.
+  auto RewrittenBinOpParentsList = ParentList;
+  int I = 0;
+  while (ChildExpr && RewrittenBinOpParentsList.size() == 1 &&
+ I++ < 4) {
+const auto *S = RewrittenBinOpParentsList[0].get();
+if (!S)
+  break;
+
+const auto *RWBO = dyn_cast(S);
+if (!RWBO) {
+  RewrittenBinOpParentsList = getDynNodeFromMap(S, PointerParents);
+  continue;
+}
+if (RWBO->getLHS()->IgnoreUnlessSpelledInSource() != ChildExpr &&
+RWBO->getRHS()->IgnoreUnlessSpelledInSource() != ChildExpr)
+  break;
+return DynTypedNode::create(*RWBO);
+  }
+}
+
+const auto *ParentExpr = ParentList[0].get();
+if (ParentExpr && ChildExpr)
+  return AscendIgnoreUnlessSpelledInSource(ParentExpr, ChildExpr);
+
+{
+  auto AncestorNodes =
+  matchParents(ParentList, this);
+  if (std::get(AncestorNodes) &&
+  std::get(AncestorNodes)
+  ->getLoopVarStmt() ==
+  std::get(AncestorNodes))
+return std::get(AncestorNodes);
+}
+{
+  auto AncestorNodes = matchParents(
+  ParentList, this);
+  if (std::get(AncestorNodes) &&
+  std::get(AncestorNodes)
+  ->getRangeStmt() ==
+  std::get(AncestorNodes))
+return std::get(AncestorNodes);
+}
+{
+  auto AncestorNodes =
+  matchParents(ParentList,
+ this);
+  if (std::get(AncestorNodes))
+return std::get(AncestorNodes);
+}
+{
+  auto AncestorNodes =
+  matchParents(
+  ParentList, this);
+  if (std::get(AncestorNodes))
+return std::get(AncestorNodes);
+}
   }

[PATCH] D96113: [ASTMatchers] Fix hasParent while ignoring unwritten nodes

[Stephen Kelly via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGe4d5f00093be: [ASTMatchers] Fix hasParent while ignoring 
unwritten nodes (authored by stephenkelly).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96113

Files:
  clang/include/clang/AST/ParentMapContext.h
  clang/lib/AST/ParentMapContext.cpp
  clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -2933,6 +2933,37 @@
 EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
 EXPECT_FALSE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
   }
+  {
+auto M = ifStmt(hasParent(compoundStmt(hasParent(cxxForRangeStmt();
+EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
+EXPECT_TRUE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
+  }
+  {
+auto M = cxxForRangeStmt(
+has(varDecl(hasName("i"), hasParent(cxxForRangeStmt();
+EXPECT_FALSE(matches(Code, traverse(TK_AsIs, M)));
+EXPECT_TRUE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
+  }
+  {
+auto M = cxxForRangeStmt(hasDescendant(varDecl(
+hasName("i"), hasParent(declStmt(hasParent(cxxForRangeStmt()));
+EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
+EXPECT_FALSE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
+  }
+  {
+auto M = cxxForRangeStmt(hasRangeInit(declRefExpr(
+to(varDecl(hasName("arr"))), hasParent(cxxForRangeStmt();
+EXPECT_FALSE(matches(Code, traverse(TK_AsIs, M)));
+EXPECT_TRUE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
+  }
+
+  {
+auto M = cxxForRangeStmt(hasRangeInit(declRefExpr(
+to(varDecl(hasName("arr"))), hasParent(varDecl(hasParent(declStmt(
+ hasParent(cxxForRangeStmt();
+EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
+EXPECT_FALSE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
+  }
 
   Code = R"cpp(
   struct Range {
@@ -3035,6 +3066,15 @@
 matchesConditionally(Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
  true, {"-std=c++20"}));
   }
+  {
+auto M = cxxForRangeStmt(hasInitStatement(declStmt(
+hasSingleDecl(varDecl(hasName("a"))), hasParent(cxxForRangeStmt();
+EXPECT_TRUE(
+matchesConditionally(Code, traverse(TK_AsIs, M), true, {"-std=c++20"}));
+EXPECT_TRUE(
+matchesConditionally(Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+ true, {"-std=c++20"}));
+  }
 
   Code = R"cpp(
   struct Range {
@@ -3511,6 +3551,20 @@
forFunction(functionDecl(hasName("func13"))),
   langCxx20OrLater()));
 
+  EXPECT_TRUE(matches(Code,
+  traverse(TK_IgnoreUnlessSpelledInSource,
+   compoundStmt(hasParent(lambdaExpr(forFunction(
+   functionDecl(hasName("func13"))),
+  langCxx20OrLater()));
+
+  EXPECT_TRUE(matches(
+  Code,
+  traverse(TK_IgnoreUnlessSpelledInSource,
+   templateTypeParmDecl(hasName("TemplateType"),
+hasParent(lambdaExpr(forFunction(
+functionDecl(hasName("func14"))),
+  langCxx20OrLater()));
+
   EXPECT_TRUE(matches(
   Code,
   traverse(TK_IgnoreUnlessSpelledInSource,
@@ -3635,6 +3689,16 @@
 matchesConditionally(Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
  true, {"-std=c++20"}));
   }
+  {
+auto M = cxxRewrittenBinaryOperator(
+hasLHS(expr(hasParent(cxxRewrittenBinaryOperator(,
+hasRHS(expr(hasParent(cxxRewrittenBinaryOperator();
+EXPECT_FALSE(
+matchesConditionally(Code, traverse(TK_AsIs, M), true, {"-std=c++20"}));
+EXPECT_TRUE(
+matchesConditionally(Code, traverse(TK_IgnoreUnlessSpelledInSource, M),
+ true, {"-std=c++20"}));
+  }
   {
 EXPECT_TRUE(matchesConditionally(
 Code,
Index: clang/lib/AST/ParentMapContext.cpp
===
--- clang/lib/AST/ParentMapContext.cpp
+++ clang/lib/AST/ParentMapContext.cpp
@@ -49,7 +49,17 @@
   return N;
 }
 
+template 
+std::tuple
+matchParents(const DynTypedNodeList &NodeList,
+ ParentMapContext::ParentMap *ParentMap);
+
+template  struct MatchParents;
+
 class ParentMapContext::ParentMap {
+
+  template  friend struct ::MatchParents;
+
   /// Contains parents of a node.
   using ParentVector = llvm::SmallVector;
 
@@ -117,11 +127,72 @@
 if (Node.getNodeKind().ha

[PATCH] D96832: [Clang][Attributes] Allow not_tail_called attribute to be applied to virtual function.

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:4109
-  [[clang::not_tail_called]] int foo2() override;
-};
   }];

aaron.ballman wrote:
> ahatanak wrote:
> > Quuxplusone wrote:
> > > (Moving into a thread)
> > > 
> > > > This patch doesn't prevent the call to method in the code below from 
> > > > being tail called,
> > > > but I suppose users would expect the attribute to prevent the tail call?
> > > ```
> > > struct B {
> > >   virtual void method();  
> > > };
> > > struct D : B {
> > >   [[clang::not_tail_called]] void method() override; 
> > > };
> > > ```
> > > 
> > > The way virtual calls are handled in C++ is, all attributes and 
> > > properties of the call are determined based on the //static// type at the 
> > > call site; and then the //runtime destination// of the call is determined 
> > > from the pointer in the vtable. Attributes and properties have no runtime 
> > > existence, and so they physically cannot affect anything at runtime. 
> > > Consider https://godbolt.org/z/P3799e :
> > > 
> > > ```
> > > struct Ba {
> > >   virtual Ba *method(int x = 1);  
> > > };
> > > struct Da : Ba {
> > >   [[clang::not_tail_called]] [[nodiscard]] Da *method(int x = 2) noexcept 
> > > override; 
> > > };
> > > auto callera(Da& da) {
> > > Ba& ba = da;
> > > ba.method();
> > > }
> > > ```
> > > Here the call that is made is a //virtual// call (because `Ba::method` is 
> > > virtual); with a default argument value of `1` (because `Ba::method`'s 
> > > `x` parameter has a default value of `1`); and it returns something of 
> > > type `Ba*` (because that's what `Ba::method` returns); and it is not 
> > > considered to be noexcept (because `Ba::method` isn't marked noexcept); 
> > > and it's okay to discard the result (because `Ba::method` is not 
> > > nodiscard) and it is tail-called (because `Ba::method` doesn't disallow 
> > > tail calls). All of these attributes and properties are based on the 
> > > //static// type of variable `ba`, despite the fact that //at runtime// 
> > > we'll end up jumping to the code for `Da::method`. According to the 
> > > source code, statically, `Da::method` has a default argument of `2`, 
> > > returns `Da*`, is noexcept, and is nodiscard, and disallows tail-calls. 
> > > But we're not calling `da.method()`, we're calling `ba.method()`; so none 
> > > of that matters to our call site at `callera`.
> > > 
> > > I think this patch is a good thing.
> > OK, I see. I think this patch is fine then.
> > 
> > Should we add an explanation of how virtual functions are handled? The doc 
> > currently just says the attribute prevents tail-call optimization on 
> > statically bound calls.
> > I think this patch is a good thing.
> 
> I agree with your explanation but I'm not certain I agree with your 
> conclusion. :-) I think the examples you point out are more often a source of 
> confusion for users than not because of the nature of static vs dynamic 
> dispatch, and so saying "this behavior can be consistent with all of these 
> other things people often get confused by" may be justifiable but also seems 
> a bit user-hostile.
> 
> Taking a slightly different example:
> ```
> struct Ba {
>   [[clang::not_tail_called]] virtual Ba *method();  
> };
> struct Da : Ba {
>   Ba *method() override; 
> };
> 
> void callera(Da& da) {
> Ba& ba = da;
> ba.method();
> }
> ```
> There's no guarantee that `Ba::method()` and `Da::method()` have the same 
> not-tail-called properties. The codegen for this case will still attach 
> `notail` to the call site even though the dynamic target may not meet that 
> requirement.
> 
> tl;dr: I think `notail` is a property of the call expression and the only way 
> to know that's valid is when you know what's being called, so the current 
> behavior is more user-friendly for avoiding optimization issues. I'd prefer 
> not to relax that unless there was a significantly motivating example beyond 
> what's presented here so far.
> saying "this behavior can be consistent with all of these other things people 
> often get confused by" may be justifiable but also seems a bit user-hostile.

I disagree. In areas where (we agree that) users are already a bit confused, I 
want to treat consistency-of-interface as a virtue. Imagine a student being 
confused for weeks about the behavior of attributes on virtual methods — "I put 
`[[nodiscard]]`/`[[noreturn]]`/`[[deprecated]]` on the child method, but the 
compiler isn't warning me when I call the parent method!" — and then 
//finally// someone asks him to repeat it slowly, and the lightbulb goes on: 
"Oh, right, I'm calling the //parent// method..." So now he "gets it." Oh, 
except, the entire mental model breaks down again for the `[[not_tail_called]]` 
attribute, because that attribute uses different rules.

Let's just skip that very last step. Let's have all attributes use the same 
rules, so that the mental model for one c

[PATCH] D96719: [clang-tidy] Add new check 'bugprone-thread-canceltype-asynchronous' and alias 'cert-pos47-c'.

[Balázs Kéri via Phabricator via cfe-commits]

balazske updated this revision to Diff 324629.
balazske marked 3 inline comments as done.
balazske added a comment.

- Fixed remaining formatting and rename problems.
- Removed tryExpandAsInteger, use matcher instead.
- Improved test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96719

Files:
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/clang-tidy/cert/CMakeLists.txt
  clang-tools-extra/clang-tidy/concurrency/CMakeLists.txt
  clang-tools-extra/clang-tidy/concurrency/ConcurrencyTidyModule.cpp
  clang-tools-extra/clang-tidy/concurrency/ThreadCanceltypeAsynchronousCheck.cpp
  clang-tools-extra/clang-tidy/concurrency/ThreadCanceltypeAsynchronousCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-pos47-c.rst
  
clang-tools-extra/docs/clang-tidy/checks/concurrency-thread-canceltype-asynchronous.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/concurrency-thread-canceltype-asynchronous.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/concurrency-thread-canceltype-asynchronous.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/concurrency-thread-canceltype-asynchronous.cpp
@@ -0,0 +1,52 @@
+// RUN: %check_clang_tidy %s concurrency-thread-canceltype-asynchronous %t
+
+#define ONE (1 << 0)
+
+#define PTHREAD_CANCEL_DEFERRED 0
+// define the macro intentionally complex
+#define PTHREAD_CANCEL_ASYNCHRONOUS ONE
+
+#define ASYNCHR PTHREAD_CANCEL_ASYNCHRONOUS
+
+int pthread_setcanceltype(int type, int *oldtype);
+
+int main() {
+  int result, oldtype;
+
+  if ((result = pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, &oldtype)) != 0) {
+// CHECK-MESSAGES: :[[@LINE-1]]:17: warning: the cancel type for a pthread should not be 'PTHREAD_CANCEL_ASYNCHRONOUS' [concurrency-thread-canceltype-asynchronous]
+return 1;
+  }
+
+  if ((result = pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, &oldtype)) != 0) {
+return 1;
+  }
+
+  return 0;
+}
+
+int f1() {
+  int result, oldtype;
+
+  if ((result = pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, &oldtype)) != 0) {
+// CHECK-MESSAGES: :[[@LINE-1]]:17: warning: the cancel type for a pthread should not be 'PTHREAD_CANCEL_ASYNCHRONOUS' [concurrency-thread-canceltype-asynchronous]
+return 1;
+  }
+
+  if ((result = pthread_setcanceltype(ASYNCHR, &oldtype)) != 0) {
+// CHECK-MESSAGES: :[[@LINE-1]]:17: warning: the cancel type for a pthread should not be 'PTHREAD_CANCEL_ASYNCHRONOUS' [concurrency-thread-canceltype-asynchronous]
+return 1;
+  }
+
+  return 0;
+}
+
+int f2(int type) {
+  int result, oldtype;
+
+  if ((result = pthread_setcanceltype(type, &oldtype)) != 0) {
+return 1;
+  }
+
+  return 0;
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -140,6 +140,7 @@
`clang-analyzer-valist.Uninitialized `_,
`clang-analyzer-valist.Unterminated `_,
`concurrency-mt-unsafe `_,
+   `concurrency-thread-canceltype-asynchronous `_,
`cppcoreguidelines-avoid-goto `_,
`cppcoreguidelines-avoid-non-const-global-variables `_,
`cppcoreguidelines-init-variables `_, "Yes"
@@ -334,6 +335,7 @@
`cert-oop11-cpp `_, `performance-move-constructor-init `_, "Yes"
`cert-oop54-cpp `_, `bugprone-unhandled-self-assignment `_,
`cert-pos44-c `_, `bugprone-bad-signal-to-kill-thread `_,
+   `cert-pos47-c `_, `concurrency-thread-canceltype-asynchronous `_,
`cert-str34-c `_, `bugprone-signed-char-misuse `_,
`clang-analyzer-core.CallAndMessage `_, `Clang Static Analyzer `_,
`clang-analyzer-core.DivideZero `_, `Clang Static Analyzer `_,
Index: clang-tools-extra/docs/clang-tidy/checks/concurrency-thread-canceltype-asynchronous.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/concurrency-thread-canceltype-asynchronous.rst
@@ -0,0 +1,19 @@
+.. title:: clang-tidy - concurrency-thread-canceltype-asynchronous
+
+concurrency-thread-canceltype-asynchronous
+==
+
+Finds ``pthread_setcanceltype`` function calls where a thread's cancellation
+type is set to asynchronous. Asynchronous cancellation type
+(``PTHREAD_CANCEL_ASYNCHRONOUS``) is generally unsafe, use type
+``PTHREAD_CANCEL_DEFERRED`` instead which is the default. Even with deferred
+cancellation, a cancellation point in an asynchronous signal handler may still
+be acted upon and the effect is as if it was an asynchronous cancellation.
+
+.. code-block: c++
+
+  pthread_setcanceltype(PTHR

[PATCH] D96751: [clangd] Populate detail field in document symbols

[WangWei via Phabricator via cfe-commits]

lightmelodies updated this revision to Diff 324626.
lightmelodies added a comment.

Better printing for C++ constructor and destructor. Remove unnecessary test 
cases.


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

https://reviews.llvm.org/D96751

Files:
  clang-tools-extra/clangd/FindSymbols.cpp
  clang-tools-extra/clangd/test/symbols.test
  clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp

Index: clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
+++ clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
@@ -35,6 +35,7 @@
 }
 MATCHER_P(WithName, N, "") { return arg.name == N; }
 MATCHER_P(WithKind, Kind, "") { return arg.kind == Kind; }
+MATCHER_P(WithDetail, Detail, "") { return arg.detail == Detail; }
 MATCHER_P(SymRange, Range, "") { return arg.range == Range; }
 
 // GMock helpers for matching DocumentSymbol.
@@ -374,44 +375,55 @@
   EXPECT_THAT(
   getSymbols(TU.build()),
   ElementsAreArray(
-  {AllOf(WithName("Foo"), WithKind(SymbolKind::Class), Children()),
+  {AllOf(WithName("Foo"), WithKind(SymbolKind::Class),
+ WithDetail("class"), Children()),
AllOf(WithName("Foo"), WithKind(SymbolKind::Class),
- Children(AllOf(WithName("Foo"),
-WithKind(SymbolKind::Constructor), Children()),
-  AllOf(WithName("Foo"),
-WithKind(SymbolKind::Constructor), Children()),
-  AllOf(WithName("f"), WithKind(SymbolKind::Method),
-Children()),
-  AllOf(WithName("operator="),
-WithKind(SymbolKind::Method), Children()),
-  AllOf(WithName("~Foo"),
-WithKind(SymbolKind::Constructor), Children()),
-  AllOf(WithName("Nested"), WithKind(SymbolKind::Class),
-Children(AllOf(WithName("f"),
-   WithKind(SymbolKind::Method),
-   Children()),
-   AllOf(WithName("Friend"), WithKind(SymbolKind::Class), Children()),
-   AllOf(WithName("f1"), WithKind(SymbolKind::Function), Children()),
-   AllOf(WithName("f2"), WithKind(SymbolKind::Function), Children()),
-   AllOf(WithName("KInt"), WithKind(SymbolKind::Variable), Children()),
-   AllOf(WithName("kStr"), WithKind(SymbolKind::Variable), Children()),
-   AllOf(WithName("f1"), WithKind(SymbolKind::Function), Children()),
+ WithDetail("class"),
+ Children(
+ AllOf(WithName("Foo"), WithKind(SymbolKind::Constructor),
+   WithDetail("()"), Children()),
+ AllOf(WithName("Foo"), WithKind(SymbolKind::Constructor),
+   WithDetail("(int)"), Children()),
+ AllOf(WithName("f"), WithKind(SymbolKind::Method),
+   WithDetail("void ()"), Children()),
+ AllOf(WithName("operator="), WithKind(SymbolKind::Method),
+   WithDetail("Foo &(const Foo &)"), Children()),
+ AllOf(WithName("~Foo"), WithKind(SymbolKind::Constructor),
+   WithDetail(""), Children()),
+ AllOf(WithName("Nested"), WithKind(SymbolKind::Class),
+   WithDetail("class"),
+   Children(AllOf(
+   WithName("f"), WithKind(SymbolKind::Method),
+   WithDetail("void ()"), Children()),
+   AllOf(WithName("Friend"), WithKind(SymbolKind::Class),
+ WithDetail("class"), Children()),
+   AllOf(WithName("f1"), WithKind(SymbolKind::Function),
+ WithDetail("void ()"), Children()),
+   AllOf(WithName("f2"), WithKind(SymbolKind::Function),
+ WithDetail("void ()"), Children()),
+   AllOf(WithName("KInt"), WithKind(SymbolKind::Variable),
+ WithDetail("const int"), Children()),
+   AllOf(WithName("kStr"), WithKind(SymbolKind::Variable),
+ WithDetail("const char *"), Children()),
+   AllOf(WithName("f1"), WithKind(SymbolKind::Function),
+ WithDetail("void ()"), Children()),
AllOf(
-   WithName("foo"), WithKind(SymbolKind::Namespace),
-   Children(
-   AllOf(WithName("int32"), WithKind(SymbolKind::Class),
- Children()),
-   AllOf(WithName("int32_t"), WithKind(SymbolKind::Class),
- Children()),
-   AllOf(WithName("v1"), WithKind(SymbolKind::Variable),
-

[PATCH] D96816: [ObjC] Encode pointers to C++ classes as "^v" if the encoded string would otherwise include template specialization types

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak updated this revision to Diff 324628.
ahatanak marked 2 inline comments as done.
ahatanak added a comment.

- Use `BoolFOption` to define both the positive and negative options.
- Enable the optimization if the ObjC runtime is a NeXT-family runtime.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96816

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/AST/ASTContext.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGenObjCXX/encode.mm
  clang/test/Driver/objc-encode-cxx-class-template-spec.m

Index: clang/test/Driver/objc-encode-cxx-class-template-spec.m
===
--- /dev/null
+++ clang/test/Driver/objc-encode-cxx-class-template-spec.m
@@ -0,0 +1,7 @@
+// RUN: %clang -target arm64-apple-ios11 -### %s -o - 2>&1 | FileCheck -check-prefix=DISABLE-ENC %s
+// RUN: %clang -target arm64-apple-ios11 -fobjc-encode-cxx-class-template-spec -### %s -o - 2>&1 | FileCheck -check-prefix=ENABLE-ENC %s
+// RUN: %clang -target x86_64-linux-gnu -fobjc-runtime=gnustep -### %s -o - 2>&1 | FileCheck -check-prefix=ENABLE-ENC %s
+// RUN: %clang -target x86_64-linux-gnu -fobjc-runtime=gnustep -fno-objc-encode-cxx-class-template-spec -### %s -o - 2>&1 |  FileCheck -check-prefix=DISABLE-ENC %s
+
+// DISABLE-ENC-NOT: -fobjc-encode-cxx-class-template-spec
+// ENABLE-ENC: -fobjc-encode-cxx-class-template-spec
Index: clang/test/CodeGenObjCXX/encode.mm
===
--- clang/test/CodeGenObjCXX/encode.mm
+++ clang/test/CodeGenObjCXX/encode.mm
@@ -1,5 +1,6 @@
-// RUN: %clang_cc1 -Wno-objc-root-class -std=gnu++98 %s -triple=x86_64-apple-darwin10 -emit-llvm -o - | FileCheck --check-prefixes CHECK,CHECKCXX98 %s
-// RUN: %clang_cc1 -Wno-objc-root-class -std=gnu++20 %s -triple=x86_64-apple-darwin10 -emit-llvm -o - | FileCheck --check-prefixes CHECK,CHECKCXX20 %s
+// RUN: %clang_cc1 -Wno-objc-root-class -std=gnu++98 %s -triple=x86_64-apple-darwin10 -emit-llvm -o - | FileCheck --check-prefixes CHECK,CHECKCXX98,CHECK-NO-TEMP-SPEC %s
+// RUN: %clang_cc1 -Wno-objc-root-class -std=gnu++20 %s -triple=x86_64-apple-darwin10 -emit-llvm -o - | FileCheck --check-prefixes CHECK,CHECKCXX20,CHECK-NO-TEMP-SPEC %s
+// RUN: %clang_cc1 -Wno-objc-root-class -std=gnu++20 %s -triple=x86_64-apple-darwin10 -fobjc-encode-cxx-class-template-spec -emit-llvm -o - | FileCheck --check-prefixes CHECK,CHECKCXX20,CHECK-TEMP-SPEC %s
 
 // CHECK: v17@0:8{vector=}16
 // CHECK: {vector=}
@@ -260,3 +261,82 @@
   extern const char x[] = @encode(I);
 }
 #endif
+
+namespace test_cxx_template_specialization {
+template 
+struct B0 {
+  T a;
+};
+struct D0 : B0 {};
+struct D1 : D0 {};
+struct D2 : virtual B0 {};
+struct S0 {
+  B0 a;
+};
+struct S1 {
+  B0 *a;
+};
+struct S2 {
+  S1 *a;
+};
+template 
+union U0 {
+  T a;
+};
+typedef B0 TD0;
+typedef B0 *Array0[4];
+
+template 
+struct Outer0 {
+  struct Inner0 {
+int a;
+  };
+  template 
+  struct Inner1 {
+T a;
+T1 b;
+  };
+};
+
+// CHECK: @[[STR22:.*]] = {{.*}} [12 x i8] c"{B0=i}\00"
+// CHECK: @_ZN32test_cxx_template_specialization2b0E = {{.*}} ([12 x i8], [12 x i8]* @[[STR22]], i32 0, i32 0)
+// CHECK-NO-TEMP-SPEC: @[[STR23:.*]] = {{.*}} [3 x i8] c"^v\00"
+// CHECK-NO-TEMP-SPEC: @_ZN32test_cxx_template_specialization3b01E = {{.*}} ([3 x i8], [3 x i8]* @[[STR23]], i32 0, i32 0)
+// CHECK-TEMP-SPEC: @[[STR23:.*]] = {{.*}} [13 x i8] c"^{B0=i}\00"
+// CHECK-TEMP-SPEC: @_ZN32test_cxx_template_specialization3b01E = {{.*}} ([13 x i8], [13 x i8]* @[[STR23]], i32 0, i32 0)
+// CHECK-NO-TEMP-SPEC: @_ZN32test_cxx_template_specialization3b02E = {{.*}} ([3 x i8], [3 x i8]* @[[STR23]], i32 0, i32 0)
+// CHECK-NO-TEMP-SPEC: @_ZN32test_cxx_template_specialization2d0E = {{.*}} ([3 x i8], [3 x i8]* @[[STR23]], i32 0, i32 0)
+// CHECK-NO-TEMP-SPEC: @_ZN32test_cxx_template_specialization2d1E = {{.*}} ([3 x i8], [3 x i8]* @[[STR23]], i32 0, i32 0)
+// CHECK-NO-TEMP-SPEC: @_ZN32test_cxx_template_specialization2d2E = {{.*}} ([3 x i8], [3 x i8]* @[[STR23]], i32 0, i32 0)
+// CHECK: @[[STR24:.*]] = {{.*}} [7 x i8] c"^^{D2}\00"
+// CHECK: @_ZN32test_cxx_template_specialization3d21E = {{.*}} ([7 x i8], [7 x i8]* @[[STR24]], i32 0, i32 0)
+// CHECK-NO-TEMP-SPEC: @_ZN32test_cxx_template_specialization2s0E = {{.*}} ([3 x i8], [3 x i8]* @[[STR23]], i32 0, i32 0)
+// CHECK-NO-TEMP-SPEC: @_ZN32test_cxx_template_specialization2s1E = {{.*}} ([3 x i8], [3 x i8]* @[[STR23]], i32 0, i32 0)
+// CHECK: @[[STR25:.*]] = {{.*}} [12 x i8] c"^{S2=^{S1}}\00"
+// CHECK: @_ZN32test_cxx_template_specialization2s2E = {{.*}} ([12 x i8], [12 x i8]* @[[STR25]], i32 0, i32 0)
+// CHECK-NO-TEMP-SPEC: @_ZN32test_cxx_template_specialization2u0E = {{.*}} ([3 x i8], [3 x i8]* @[[STR23]], i32 0, i32 0)
+// CHECK-NO-TEMP-SPEC: @_ZN32test_cxx_template_specialization3td0E = {{.*}} ([3 x i8], [3 x i8]* @[[STR23]]

[PATCH] D96751: [clangd] Populate detail field in document symbols

[WangWei via Phabricator via cfe-commits]

lightmelodies added a comment.

In D96751#2571346 , @sammccall wrote:

> Nice! This looks good to land as-is, I just have some suggestions where we 
> may want to mark behavior to revisit later, and some places where we could 
> trim the tests a bit.
>
> Do you have commit access, or want me to land this for you? (I'd need an 
> address for the commit)

I don't have commit access yet, it will be appreciated if you can land this for 
me (just use lightmelodies(lightmelod...@outlook.com))


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

https://reviews.llvm.org/D96751

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

[PATCH] D96751: [clangd] Populate detail field in document symbols

[Sam McCall via Phabricator via cfe-commits]

sammccall accepted this revision.
sammccall added a comment.

Fantastic, thank you!




Comment at: clang-tools-extra/clangd/FindSymbols.cpp:189
+if (isa(VD)) {
+  std::string CCD;
+  llvm::raw_string_ostream OSC(CCD);

I think equivalent and a little safer is

std::string ConstructorType = VD->getType().getAsString(P);
llvm::StringRef WithoutVoid = ConstructorType;
WithoutVoid.consume_front("void");
OS << WithoutVoid;

(I'll apply this when landing)


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

https://reviews.llvm.org/D96751

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

[PATCH] D96751: [clangd] Populate detail field in document symbols

[WangWei via Phabricator via cfe-commits]

lightmelodies added a comment.

In D96751#2571563 , @sammccall wrote:

> Fantastic, thank you!

Maybe WithoutVoid.consume_front("void ");


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

https://reviews.llvm.org/D96751

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

[PATCH] D96832: [Clang][Attributes] Allow not_tail_called attribute to be applied to virtual function.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:4109
-  [[clang::not_tail_called]] int foo2() override;
-};
   }];

Quuxplusone wrote:
> aaron.ballman wrote:
> > ahatanak wrote:
> > > Quuxplusone wrote:
> > > > (Moving into a thread)
> > > > 
> > > > > This patch doesn't prevent the call to method in the code below from 
> > > > > being tail called,
> > > > > but I suppose users would expect the attribute to prevent the tail 
> > > > > call?
> > > > ```
> > > > struct B {
> > > >   virtual void method();  
> > > > };
> > > > struct D : B {
> > > >   [[clang::not_tail_called]] void method() override; 
> > > > };
> > > > ```
> > > > 
> > > > The way virtual calls are handled in C++ is, all attributes and 
> > > > properties of the call are determined based on the //static// type at 
> > > > the call site; and then the //runtime destination// of the call is 
> > > > determined from the pointer in the vtable. Attributes and properties 
> > > > have no runtime existence, and so they physically cannot affect 
> > > > anything at runtime. Consider https://godbolt.org/z/P3799e :
> > > > 
> > > > ```
> > > > struct Ba {
> > > >   virtual Ba *method(int x = 1);  
> > > > };
> > > > struct Da : Ba {
> > > >   [[clang::not_tail_called]] [[nodiscard]] Da *method(int x = 2) 
> > > > noexcept override; 
> > > > };
> > > > auto callera(Da& da) {
> > > > Ba& ba = da;
> > > > ba.method();
> > > > }
> > > > ```
> > > > Here the call that is made is a //virtual// call (because `Ba::method` 
> > > > is virtual); with a default argument value of `1` (because 
> > > > `Ba::method`'s `x` parameter has a default value of `1`); and it 
> > > > returns something of type `Ba*` (because that's what `Ba::method` 
> > > > returns); and it is not considered to be noexcept (because `Ba::method` 
> > > > isn't marked noexcept); and it's okay to discard the result (because 
> > > > `Ba::method` is not nodiscard) and it is tail-called (because 
> > > > `Ba::method` doesn't disallow tail calls). All of these attributes and 
> > > > properties are based on the //static// type of variable `ba`, despite 
> > > > the fact that //at runtime// we'll end up jumping to the code for 
> > > > `Da::method`. According to the source code, statically, `Da::method` 
> > > > has a default argument of `2`, returns `Da*`, is noexcept, and is 
> > > > nodiscard, and disallows tail-calls. But we're not calling 
> > > > `da.method()`, we're calling `ba.method()`; so none of that matters to 
> > > > our call site at `callera`.
> > > > 
> > > > I think this patch is a good thing.
> > > OK, I see. I think this patch is fine then.
> > > 
> > > Should we add an explanation of how virtual functions are handled? The 
> > > doc currently just says the attribute prevents tail-call optimization on 
> > > statically bound calls.
> > > I think this patch is a good thing.
> > 
> > I agree with your explanation but I'm not certain I agree with your 
> > conclusion. :-) I think the examples you point out are more often a source 
> > of confusion for users than not because of the nature of static vs dynamic 
> > dispatch, and so saying "this behavior can be consistent with all of these 
> > other things people often get confused by" may be justifiable but also 
> > seems a bit user-hostile.
> > 
> > Taking a slightly different example:
> > ```
> > struct Ba {
> >   [[clang::not_tail_called]] virtual Ba *method();  
> > };
> > struct Da : Ba {
> >   Ba *method() override; 
> > };
> > 
> > void callera(Da& da) {
> > Ba& ba = da;
> > ba.method();
> > }
> > ```
> > There's no guarantee that `Ba::method()` and `Da::method()` have the same 
> > not-tail-called properties. The codegen for this case will still attach 
> > `notail` to the call site even though the dynamic target may not meet that 
> > requirement.
> > 
> > tl;dr: I think `notail` is a property of the call expression and the only 
> > way to know that's valid is when you know what's being called, so the 
> > current behavior is more user-friendly for avoiding optimization issues. 
> > I'd prefer not to relax that unless there was a significantly motivating 
> > example beyond what's presented here so far.
> > saying "this behavior can be consistent with all of these other things 
> > people often get confused by" may be justifiable but also seems a bit 
> > user-hostile.
> 
> I disagree. In areas where (we agree that) users are already a bit confused, 
> I want to treat consistency-of-interface as a virtue. Imagine a student being 
> confused for weeks about the behavior of attributes on virtual methods — "I 
> put `[[nodiscard]]`/`[[noreturn]]`/`[[deprecated]]` on the child method, but 
> the compiler isn't warning me when I call the parent method!" — and then 
> //finally// someone asks him to repeat it slowly, and the lightbulb goes on: 
> "Oh, right, I'm calling the //parent// method..." So now he "gets it." Oh, 
> except

[PATCH] D96771: [OpenCL] Add distinct file extension for C++ for OpenCL

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski added a comment.

Hi @Anastasia , thank you for working on this!

IIUC, this patch introduces:

- new input types: `TY_CLCXX` and `TY_CLCXXHeader`
- new language: `OpenCLCXX`

Based on the attached test, this is only to remove the need for 
`-cl-std=clc++`. Do you expect any other benefits of introducing the above ^^^? 
And are you planning to to update the OpenCL C++ tests not to use  
`-cl-std=clc++`? Just trying to make sure I understand the reason behind this :)




Comment at: clang/lib/Driver/Types.cpp:163
 
-bool types::isOpenCL(ID Id) { return Id == TY_CL; }
+bool types::isOpenCL(ID Id) {
+  switch (Id) {

This is not used.


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

https://reviews.llvm.org/D96771

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

[clang] 5f7715d - Pass the cmdline aapcs bitfield options to cc1

[Ties Stuij via cfe-commits]

Author: Ties Stuij
Date: 2021-02-18T15:41:20Z
New Revision: 5f7715d8780a1d16ad023995d282a7d94cb923a9

URL: 
https://github.com/llvm/llvm-project/commit/5f7715d8780a1d16ad023995d282a7d94cb923a9
DIFF: 
https://github.com/llvm/llvm-project/commit/5f7715d8780a1d16ad023995d282a7d94cb923a9.diff

LOG: Pass the cmdline aapcs bitfield options to cc1

The following commits added commandline arguments to control following the Arm
Procedure Call Standard for certain volatile bitfield operations:
- https://reviews.llvm.org/D67399
- https://reviews.llvm.org/D72932

This commit fixes the oversight that these args weren't passed from the driver
to cc1 if appropriate.

Where *appropriate* means:
- `-faapcs-bitfield-width`: is the default, so won't be passed
- `-fno-aapcs-bitfield-width`: should be passed
- `-faapcs-bitfield-load`: should be passed

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

Added: 
clang/test/Driver/arm-aarch64-bitfield-flags.c

Modified: 
clang/lib/Driver/ToolChains/Clang.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index eaaef6b78ffb..2fe5bbe2f06c 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -1528,6 +1528,15 @@ static void renderRemarksOptions(const ArgList &Args, 
ArgStringList &CmdArgs,
   }
 }
 
+void AddAAPCSVolatileBitfieldArgs(const ArgList &Args, ArgStringList &CmdArgs) 
{
+  if (!Args.hasFlag(options::OPT_faapcs_bitfield_width,
+options::OPT_fno_aapcs_bitfield_width, true))
+CmdArgs.push_back("-fno-aapcs-bitfield-width");
+
+  if (Args.getLastArg(options::OPT_ForceAAPCSBitfieldLoad))
+CmdArgs.push_back("-faapcs-bitfield-load");
+}
+
 namespace {
 void RenderARMABI(const llvm::Triple &Triple, const ArgList &Args,
   ArgStringList &CmdArgs) {
@@ -1586,6 +1595,8 @@ void Clang::AddARMTargetArgs(const llvm::Triple &Triple, 
const ArgList &Args,
 
   if (Args.getLastArg(options::OPT_mcmse))
 CmdArgs.push_back("-mcmse");
+
+  AddAAPCSVolatileBitfieldArgs(Args, CmdArgs);
 }
 
 void Clang::RenderTargetOptions(const llvm::Triple &EffectiveTriple,
@@ -1774,6 +1785,8 @@ void Clang::AddAArch64TargetArgs(const ArgList &Args,
   D.Diag(diag::err_drv_unsupported_option_argument)
   << A->getOption().getName() << Val;
   }
+
+  AddAAPCSVolatileBitfieldArgs(Args, CmdArgs);
 }
 
 void Clang::AddMIPSTargetArgs(const ArgList &Args,

diff  --git a/clang/test/Driver/arm-aarch64-bitfield-flags.c 
b/clang/test/Driver/arm-aarch64-bitfield-flags.c
new file mode 100644
index ..a7961c6eedc3
--- /dev/null
+++ b/clang/test/Driver/arm-aarch64-bitfield-flags.c
@@ -0,0 +1,18 @@
+/// check -faapcs-bitfield-width/-fno-aapcs-bitfield-width
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main 
-faapcs-bitfield-width -### %s 2>&1 | FileCheck 
--check-prefixes=WIDTH,INVERSE-WIDTH %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main 
-faapcs-bitfield-width -### %s 2>&1 | FileCheck 
--check-prefixes=WIDTH,INVERSE-WIDTH %s
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main 
-fno-aapcs-bitfield-width -### %s 2>&1 | FileCheck 
--check-prefixes=NO-WIDTH,WIDTH %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main 
-fno-aapcs-bitfield-width -### %s 2>&1 | FileCheck 
--check-prefixes=NO-WIDTH,WIDTH %s
+// WIDTH-NOT: -faapcs-bitfield-width
+// NO-WIDTH: -fno-aapcs-bitfield-width
+
+/// check -faapcs-bitfield-load
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main 
-faapcs-bitfield-load -### %s 2>&1 | FileCheck --check-prefix=LOAD %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main 
-faapcs-bitfield-load -### %s 2>&1 | FileCheck --check-prefix=LOAD %s
+// LOAD: -faapcs-bitfield-load
+
+/// check absence of the above argument when not given
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main -### %s 2>&1 | 
FileCheck --check-prefixes=INVERSE-WIDTH,INVERSE-LOAD %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main -### %s 2>&1 
| FileCheck --check-prefixes=INVERSE-WIDTH,INVERSE-LOAD %s
+// INVERSE-WIDTH-NOT: -fno-aapcs-bitfield-width
+// INVERSE-LOAD-NOT: -fno-aapcs-bitfield-load



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

[PATCH] D96784: Pass the cmdline aapcs bitfield options to cc1

[Ties Stuij via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG5f7715d8780a: Pass the cmdline aapcs bitfield options to cc1 
(authored by stuij).

Changed prior to commit:
  https://reviews.llvm.org/D96784?vs=324589&id=324631#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96784

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/arm-aarch64-bitfield-flags.c


Index: clang/test/Driver/arm-aarch64-bitfield-flags.c
===
--- /dev/null
+++ clang/test/Driver/arm-aarch64-bitfield-flags.c
@@ -0,0 +1,18 @@
+/// check -faapcs-bitfield-width/-fno-aapcs-bitfield-width
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main 
-faapcs-bitfield-width -### %s 2>&1 | FileCheck 
--check-prefixes=WIDTH,INVERSE-WIDTH %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main 
-faapcs-bitfield-width -### %s 2>&1 | FileCheck 
--check-prefixes=WIDTH,INVERSE-WIDTH %s
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main 
-fno-aapcs-bitfield-width -### %s 2>&1 | FileCheck 
--check-prefixes=NO-WIDTH,WIDTH %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main 
-fno-aapcs-bitfield-width -### %s 2>&1 | FileCheck 
--check-prefixes=NO-WIDTH,WIDTH %s
+// WIDTH-NOT: -faapcs-bitfield-width
+// NO-WIDTH: -fno-aapcs-bitfield-width
+
+/// check -faapcs-bitfield-load
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main 
-faapcs-bitfield-load -### %s 2>&1 | FileCheck --check-prefix=LOAD %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main 
-faapcs-bitfield-load -### %s 2>&1 | FileCheck --check-prefix=LOAD %s
+// LOAD: -faapcs-bitfield-load
+
+/// check absence of the above argument when not given
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main -### %s 2>&1 | 
FileCheck --check-prefixes=INVERSE-WIDTH,INVERSE-LOAD %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main -### %s 2>&1 
| FileCheck --check-prefixes=INVERSE-WIDTH,INVERSE-LOAD %s
+// INVERSE-WIDTH-NOT: -fno-aapcs-bitfield-width
+// INVERSE-LOAD-NOT: -fno-aapcs-bitfield-load
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -1528,6 +1528,15 @@
   }
 }
 
+void AddAAPCSVolatileBitfieldArgs(const ArgList &Args, ArgStringList &CmdArgs) 
{
+  if (!Args.hasFlag(options::OPT_faapcs_bitfield_width,
+options::OPT_fno_aapcs_bitfield_width, true))
+CmdArgs.push_back("-fno-aapcs-bitfield-width");
+
+  if (Args.getLastArg(options::OPT_ForceAAPCSBitfieldLoad))
+CmdArgs.push_back("-faapcs-bitfield-load");
+}
+
 namespace {
 void RenderARMABI(const llvm::Triple &Triple, const ArgList &Args,
   ArgStringList &CmdArgs) {
@@ -1586,6 +1595,8 @@
 
   if (Args.getLastArg(options::OPT_mcmse))
 CmdArgs.push_back("-mcmse");
+
+  AddAAPCSVolatileBitfieldArgs(Args, CmdArgs);
 }
 
 void Clang::RenderTargetOptions(const llvm::Triple &EffectiveTriple,
@@ -1774,6 +1785,8 @@
   D.Diag(diag::err_drv_unsupported_option_argument)
   << A->getOption().getName() << Val;
   }
+
+  AddAAPCSVolatileBitfieldArgs(Args, CmdArgs);
 }
 
 void Clang::AddMIPSTargetArgs(const ArgList &Args,


Index: clang/test/Driver/arm-aarch64-bitfield-flags.c
===
--- /dev/null
+++ clang/test/Driver/arm-aarch64-bitfield-flags.c
@@ -0,0 +1,18 @@
+/// check -faapcs-bitfield-width/-fno-aapcs-bitfield-width
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main -faapcs-bitfield-width -### %s 2>&1 | FileCheck --check-prefixes=WIDTH,INVERSE-WIDTH %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main -faapcs-bitfield-width -### %s 2>&1 | FileCheck --check-prefixes=WIDTH,INVERSE-WIDTH %s
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main -fno-aapcs-bitfield-width -### %s 2>&1 | FileCheck --check-prefixes=NO-WIDTH,WIDTH %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main -fno-aapcs-bitfield-width -### %s 2>&1 | FileCheck --check-prefixes=NO-WIDTH,WIDTH %s
+// WIDTH-NOT: -faapcs-bitfield-width
+// NO-WIDTH: -fno-aapcs-bitfield-width
+
+/// check -faapcs-bitfield-load
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main -faapcs-bitfield-load -### %s 2>&1 | FileCheck --check-prefix=LOAD %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main -faapcs-bitfield-load -### %s 2>&1 | FileCheck --check-prefix=LOAD %s
+// LOAD: -faapcs-bitfield-load
+
+/// check absence of the above argument when not given
+// RUN: %clang -target arm-arm-none-eabi -march=armv8-m.main -### %s 2>&1 | FileCheck --check-prefixes=INVERSE-WIDTH,INVERSE-LOAD %s
+// RUN: %clang -target aarch64-arm-none-eabi -march=armv8-m.main -### %s 2>&1 | FileCheck --check-prefixes=IN

[PATCH] D96719: [clang-tidy] Add new check 'bugprone-thread-canceltype-asynchronous' and alias 'cert-pos47-c'.

[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.

Wow, that really simplified the implementation of the check nicely. LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96719

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

[PATCH] D96816: [ObjC] Encode pointers to C++ classes as "^v" if the encoded string would otherwise include template specialization types

[David Chisnall via Phabricator via cfe-commits]

theraven accepted this revision.
theraven 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/D96816/new/

https://reviews.llvm.org/D96816

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

[PATCH] D96751: [clangd] Populate detail field in document symbols

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D96751#2571579 , @lightmelodies 
wrote:

> In D96751#2571563 , @sammccall wrote:
>
>> Fantastic, thank you!
>
> Maybe WithoutVoid.consume_front("void ");

Oh wow, yes... sizeof() was really doing some heavy lifting :-)


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

https://reviews.llvm.org/D96751

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

[clang-tools-extra] 2e851c4 - [clangd] Populate detail field in document symbols

[Sam McCall via cfe-commits]

Author: lightmelodies
Date: 2021-02-18T16:53:41+01:00
New Revision: 2e851c4172a35cc37fe6bf4ce8150c628fd66c0c

URL: 
https://github.com/llvm/llvm-project/commit/2e851c4172a35cc37fe6bf4ce8150c628fd66c0c
DIFF: 
https://github.com/llvm/llvm-project/commit/2e851c4172a35cc37fe6bf4ce8150c628fd66c0c.diff

LOG: [clangd] Populate detail field in document symbols

This commit fix https://github.com/clangd/clangd/issues/520 and 
https://github.com/clangd/clangd/issues/601.
{F15544293}

Reviewed By: sammccall

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

Added: 


Modified: 
clang-tools-extra/clangd/FindSymbols.cpp
clang-tools-extra/clangd/test/symbols.test
clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/FindSymbols.cpp 
b/clang-tools-extra/clangd/FindSymbols.cpp
index e75a74b4b05c..ca4b8dafa5a0 100644
--- a/clang-tools-extra/clangd/FindSymbols.cpp
+++ b/clang-tools-extra/clangd/FindSymbols.cpp
@@ -172,6 +172,38 @@ getWorkspaceSymbols(llvm::StringRef Query, int Limit,
 }
 
 namespace {
+std::string getSymbolDetail(ASTContext &Ctx, const NamedDecl &ND) {
+  PrintingPolicy P(Ctx.getPrintingPolicy());
+  P.SuppressScope = true;
+  P.SuppressUnwrittenScope = true;
+  P.AnonymousTagLocations = false;
+  P.PolishForDeclaration = true;
+  std::string Detail;
+  llvm::raw_string_ostream OS(Detail);
+  if (ND.getDescribedTemplateParams()) {
+OS << "template ";
+  }
+  if (const auto *VD = dyn_cast(&ND)) {
+// FIXME: better printing for dependent type
+if (isa(VD)) {
+  std::string ConstructorType = VD->getType().getAsString(P);
+  // Print constructor type as "(int)" instead of "void (int)".
+  llvm::StringRef WithoutVoid = ConstructorType;
+  WithoutVoid.consume_front("void ");
+  OS << WithoutVoid;
+} else if (!isa(VD)) {
+  VD->getType().print(OS, P);
+}
+  } else if (const auto *TD = dyn_cast(&ND)) {
+OS << TD->getKindName();
+  } else if (isa(&ND)) {
+OS << "type alias";
+  } else if (isa(&ND)) {
+OS << "concept";
+  }
+  return std::move(OS.str());
+}
+
 llvm::Optional declToSym(ASTContext &Ctx, const NamedDecl &ND) 
{
   auto &SM = Ctx.getSourceManager();
 
@@ -193,6 +225,7 @@ llvm::Optional declToSym(ASTContext &Ctx, 
const NamedDecl &ND) {
   SI.deprecated = ND.isDeprecated();
   SI.range = Range{sourceLocToPosition(SM, SymbolRange->getBegin()),
sourceLocToPosition(SM, SymbolRange->getEnd())};
+  SI.detail = getSymbolDetail(Ctx, ND);
 
   SourceLocation NameLoc = ND.getLocation();
   SourceLocation FallbackNameLoc;

diff  --git a/clang-tools-extra/clangd/test/symbols.test 
b/clang-tools-extra/clangd/test/symbols.test
index 6ab058da8836..af5d74123630 100644
--- a/clang-tools-extra/clangd/test/symbols.test
+++ b/clang-tools-extra/clangd/test/symbols.test
@@ -1,5 +1,5 @@
 # RUN: clangd --index-file=%S/Inputs/symbols.test.yaml -lit-test < %s | 
FileCheck %s
-{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{"workspace":{"symbol":{"symbolKind":{"valueSet":
 
[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26],"trace":"off"}}
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{"textDocument":{"documentSymbol":{"hierarchicalDocumentSymbolSupport":true}},"workspace":{"symbol":{"symbolKind":{"valueSet":
 
[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26],"trace":"off"}}
 ---
 
{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///main.cpp","languageId":"cpp","version":1,"text":"void
 foo(); int main() { foo(); }\n"}}}
 ---
@@ -34,40 +34,54 @@
 # CHECK-NEXT:  "jsonrpc": "2.0",
 # CHECK-NEXT:"result": [
 # CHECK-NEXT:  {
-# CHECK-NEXT:"containerName": "",
+# CHECK-NEXT:"detail": "void ()",
 # CHECK-NEXT:"kind": 12,
-# CHECK-NEXT:"location": {
-# CHECK-NEXT:  "range": {
-# CHECK-NEXT:"end": {
-# CHECK-NEXT:  "character": {{.*}},
-# CHECK-NEXT:  "line": {{.*}}
-# CHECK-NEXT:},
-# CHECK-NEXT:"start": {
-# CHECK-NEXT:  "character": {{.*}},
-# CHECK-NEXT:  "line": {{.*}}
-# CHECK-NEXT:}
+# CHECK-NEXT:"name": "foo",
+# CHECK-NEXT:"range": {
+# CHECK-NEXT:  "end": {
+# CHECK-NEXT:"character": {{.*}},
+# CHECK-NEXT:"line": {{.*}}
 # CHECK-NEXT:  },
-# CHECK-NEXT:  "uri": "file://{{.*}}/main.cpp"
+# CHECK-NEXT:  "start": {
+# CHECK-NEXT:"character": {{.*}},
+# CHECK-NEXT:"line": {{.*}}
+# CHECK-NEXT:  }
 # CHECK-NEXT:},
-# CHECK-NEXT:"name": "foo"
-# CHECK-NEXT:  }
+# CHECK-NEXT:"selectionRange": {
+# CHECK-NEXT:  "end"

[PATCH] D96751: [clangd] Populate detail field in document symbols

[Sam McCall via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG2e851c4172a3: [clangd] Populate detail field in document 
symbols (authored by lightmelodies, committed by sammccall).

Changed prior to commit:
  https://reviews.llvm.org/D96751?vs=324626&id=324639#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96751

Files:
  clang-tools-extra/clangd/FindSymbols.cpp
  clang-tools-extra/clangd/test/symbols.test
  clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp

Index: clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
+++ clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
@@ -35,6 +35,7 @@
 }
 MATCHER_P(WithName, N, "") { return arg.name == N; }
 MATCHER_P(WithKind, Kind, "") { return arg.kind == Kind; }
+MATCHER_P(WithDetail, Detail, "") { return arg.detail == Detail; }
 MATCHER_P(SymRange, Range, "") { return arg.range == Range; }
 
 // GMock helpers for matching DocumentSymbol.
@@ -374,44 +375,55 @@
   EXPECT_THAT(
   getSymbols(TU.build()),
   ElementsAreArray(
-  {AllOf(WithName("Foo"), WithKind(SymbolKind::Class), Children()),
+  {AllOf(WithName("Foo"), WithKind(SymbolKind::Class),
+ WithDetail("class"), Children()),
AllOf(WithName("Foo"), WithKind(SymbolKind::Class),
- Children(AllOf(WithName("Foo"),
-WithKind(SymbolKind::Constructor), Children()),
-  AllOf(WithName("Foo"),
-WithKind(SymbolKind::Constructor), Children()),
-  AllOf(WithName("f"), WithKind(SymbolKind::Method),
-Children()),
-  AllOf(WithName("operator="),
-WithKind(SymbolKind::Method), Children()),
-  AllOf(WithName("~Foo"),
-WithKind(SymbolKind::Constructor), Children()),
-  AllOf(WithName("Nested"), WithKind(SymbolKind::Class),
-Children(AllOf(WithName("f"),
-   WithKind(SymbolKind::Method),
-   Children()),
-   AllOf(WithName("Friend"), WithKind(SymbolKind::Class), Children()),
-   AllOf(WithName("f1"), WithKind(SymbolKind::Function), Children()),
-   AllOf(WithName("f2"), WithKind(SymbolKind::Function), Children()),
-   AllOf(WithName("KInt"), WithKind(SymbolKind::Variable), Children()),
-   AllOf(WithName("kStr"), WithKind(SymbolKind::Variable), Children()),
-   AllOf(WithName("f1"), WithKind(SymbolKind::Function), Children()),
+ WithDetail("class"),
+ Children(
+ AllOf(WithName("Foo"), WithKind(SymbolKind::Constructor),
+   WithDetail("()"), Children()),
+ AllOf(WithName("Foo"), WithKind(SymbolKind::Constructor),
+   WithDetail("(int)"), Children()),
+ AllOf(WithName("f"), WithKind(SymbolKind::Method),
+   WithDetail("void ()"), Children()),
+ AllOf(WithName("operator="), WithKind(SymbolKind::Method),
+   WithDetail("Foo &(const Foo &)"), Children()),
+ AllOf(WithName("~Foo"), WithKind(SymbolKind::Constructor),
+   WithDetail(""), Children()),
+ AllOf(WithName("Nested"), WithKind(SymbolKind::Class),
+   WithDetail("class"),
+   Children(AllOf(
+   WithName("f"), WithKind(SymbolKind::Method),
+   WithDetail("void ()"), Children()),
+   AllOf(WithName("Friend"), WithKind(SymbolKind::Class),
+ WithDetail("class"), Children()),
+   AllOf(WithName("f1"), WithKind(SymbolKind::Function),
+ WithDetail("void ()"), Children()),
+   AllOf(WithName("f2"), WithKind(SymbolKind::Function),
+ WithDetail("void ()"), Children()),
+   AllOf(WithName("KInt"), WithKind(SymbolKind::Variable),
+ WithDetail("const int"), Children()),
+   AllOf(WithName("kStr"), WithKind(SymbolKind::Variable),
+ WithDetail("const char *"), Children()),
+   AllOf(WithName("f1"), WithKind(SymbolKind::Function),
+ WithDetail("void ()"), Children()),
AllOf(
-   WithName("foo"), WithKind(SymbolKind::Namespace),
-   Children(
-   AllOf(WithName("int32"), WithKind(SymbolKind::Class),
- Children()),
-   AllO

[PATCH] D96906: [AMDGPU] gfx90a support

[Jay Foad via Phabricator via cfe-commits]

foad added inline comments.



Comment at: llvm/test/CodeGen/AMDGPU/llvm.amdgcn.workitem.id.ll:23
+
+; CO-V3: .amdhsa_system_vgpr_workitem_id 0
+; PACKED-TID: .amdhsa_system_vgpr_workitem_id 0

CO-V3 isn't tested by any RUN line. I think FileCheck might complain about this 
in future.



Comment at: llvm/test/CodeGen/AMDGPU/llvm.amdgcn.workitem.id.ll:41
+
+; UNPACKED-TID-NOT: v1
+; UNPACKED-TID: {{buffer|flat}}_store_dword {{.*}}v1

UNPACKED-TID isn't tested by any RUN line.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96906

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

[PATCH] D50106: [libc++] Fix tuple assignment from types derived from a tuple-like

[Louis Dionne via Phabricator via cfe-commits]

ldionne updated this revision to Diff 324645.
ldionne added a comment.

Fix build on GCC (or at least I think it should)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D50106

Files:
  libcxx/include/tuple
  
libcxx/test/libcxx/utilities/tuple/tuple.tuple/tuple.assign/const_array.pass.cpp
  
libcxx/test/libcxx/utilities/tuple/tuple.tuple/tuple.assign/rvalue_array.pass.cpp
  
libcxx/test/libcxx/utilities/tuple/tuple.tuple/tuple.assign/tuple_array_template_depth.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/const_pair.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/convert_copy.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/convert_move.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/copy.pass.cpp
  
libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/derived_from_tuple_like.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/laziness.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/move.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/move_pair.pass.cpp
  
libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/tuple_array_template_depth.pass.cpp
  libcxx/test/support/propagate_value_category.hpp

Index: libcxx/test/support/propagate_value_category.hpp
===
--- /dev/null
+++ libcxx/test/support/propagate_value_category.hpp
@@ -0,0 +1,153 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef TEST_SUPPORT_PROPAGATE_VALUE_CATEGORY
+#define TEST_SUPPORT_PROPAGATE_VALUE_CATEGORY
+
+#include "test_macros.h"
+#include 
+
+#if TEST_STD_VER < 11
+#error this header may only be used in C++11
+#endif
+
+using UnderlyingVCType = unsigned;
+enum ValueCategory : UnderlyingVCType {
+  VC_None = 0,
+  VC_LVal = 1 << 0,
+  VC_RVal = 1 << 1,
+  VC_Const = 1 << 2,
+  VC_Volatile = 1 << 3,
+  VC_ConstVolatile = VC_Const | VC_Volatile
+};
+
+inline constexpr ValueCategory operator&(ValueCategory LHS, ValueCategory RHS) {
+  return ValueCategory(LHS & (UnderlyingVCType)RHS);
+}
+
+inline constexpr ValueCategory operator|(ValueCategory LHS, ValueCategory RHS) {
+  return ValueCategory(LHS | (UnderlyingVCType)RHS);
+}
+
+inline constexpr ValueCategory operator^(ValueCategory LHS, ValueCategory RHS) {
+  return ValueCategory(LHS ^ (UnderlyingVCType)RHS);
+}
+
+inline constexpr bool isValidValueCategory(ValueCategory VC) {
+  return (VC & (VC_LVal | VC_RVal)) != (VC_LVal | VC_RVal);
+}
+
+inline constexpr bool hasValueCategory(ValueCategory Arg, ValueCategory Key) {
+  return Arg == Key || ((Arg & Key) == Key);
+}
+
+template 
+using UnCVRef =
+typename std::remove_cv::type>::type;
+
+template 
+constexpr ValueCategory getReferenceQuals() {
+  return std::is_lvalue_reference::value
+ ? VC_LVal
+ : (std::is_rvalue_reference::value ? VC_RVal : VC_None);
+}
+static_assert(getReferenceQuals() == VC_None, "");
+static_assert(getReferenceQuals() == VC_LVal, "");
+static_assert(getReferenceQuals() == VC_RVal, "");
+
+template 
+constexpr ValueCategory getCVQuals() {
+  using Vp = typename std::remove_reference::type;
+  return std::is_const::value && std::is_volatile::value
+ ? VC_ConstVolatile
+ : (std::is_const::value
+? VC_Const
+: (std::is_volatile::value ? VC_Volatile : VC_None));
+}
+static_assert(getCVQuals() == VC_None, "");
+static_assert(getCVQuals() == VC_Const, "");
+static_assert(getCVQuals() == VC_Volatile, "");
+static_assert(getCVQuals() == VC_ConstVolatile, "");
+static_assert(getCVQuals() == VC_None, "");
+static_assert(getCVQuals() == VC_Const, "");
+
+template 
+inline constexpr ValueCategory getValueCategory() {
+  return getReferenceQuals() | getCVQuals();
+}
+static_assert(getValueCategory() == VC_None, "");
+static_assert(getValueCategory() == (VC_LVal | VC_Const), "");
+static_assert(getValueCategory() ==
+  (VC_RVal | VC_ConstVolatile),
+  "");
+
+template 
+struct ApplyValueCategory {
+private:
+  static_assert(isValidValueCategory(VC), "");
+
+  template 
+  using CondT = typename std::conditional::type;
+
+public:
+  template >
+  using ApplyCVQuals = CondT<
+  hasValueCategory(VC, VC_ConstVolatile), typename std::add_cv::type,
+  CondT::type,
+CondT::type, Tp>>>;
+
+  template ::type>
+  using ApplyReferenceQuals =
+  CondT::type,
+CondT::type, Vp>>;
+
+  template 
+  using Apply = ApplyReferenceQuals>>;
+
+  template ::type = true>
+  static

[PATCH] D50106: [libc++] Fix tuple assignment from types derived from a tuple-like

[Louis Dionne via Phabricator via cfe-commits]

ldionne updated this revision to Diff 324648.
ldionne added a comment.

Address Arthur's comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D50106

Files:
  libcxx/include/tuple
  
libcxx/test/libcxx/utilities/tuple/tuple.tuple/tuple.assign/const_array.pass.cpp
  
libcxx/test/libcxx/utilities/tuple/tuple.tuple/tuple.assign/rvalue_array.pass.cpp
  
libcxx/test/libcxx/utilities/tuple/tuple.tuple/tuple.assign/tuple_array_template_depth.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/const_pair.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/convert_copy.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/convert_move.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/copy.pass.cpp
  
libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/derived_from_tuple_like.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/laziness.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/move.pass.cpp
  libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/move_pair.pass.cpp
  
libcxx/test/std/utilities/tuple/tuple.tuple/tuple.assign/tuple_array_template_depth.pass.cpp
  libcxx/test/support/propagate_value_category.hpp

Index: libcxx/test/support/propagate_value_category.hpp
===
--- /dev/null
+++ libcxx/test/support/propagate_value_category.hpp
@@ -0,0 +1,153 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef TEST_SUPPORT_PROPAGATE_VALUE_CATEGORY
+#define TEST_SUPPORT_PROPAGATE_VALUE_CATEGORY
+
+#include "test_macros.h"
+#include 
+
+#if TEST_STD_VER < 11
+#error this header may only be used in C++11
+#endif
+
+using UnderlyingVCType = unsigned;
+enum ValueCategory : UnderlyingVCType {
+  VC_None = 0,
+  VC_LVal = 1 << 0,
+  VC_RVal = 1 << 1,
+  VC_Const = 1 << 2,
+  VC_Volatile = 1 << 3,
+  VC_ConstVolatile = VC_Const | VC_Volatile
+};
+
+inline constexpr ValueCategory operator&(ValueCategory LHS, ValueCategory RHS) {
+  return ValueCategory(LHS & (UnderlyingVCType)RHS);
+}
+
+inline constexpr ValueCategory operator|(ValueCategory LHS, ValueCategory RHS) {
+  return ValueCategory(LHS | (UnderlyingVCType)RHS);
+}
+
+inline constexpr ValueCategory operator^(ValueCategory LHS, ValueCategory RHS) {
+  return ValueCategory(LHS ^ (UnderlyingVCType)RHS);
+}
+
+inline constexpr bool isValidValueCategory(ValueCategory VC) {
+  return (VC & (VC_LVal | VC_RVal)) != (VC_LVal | VC_RVal);
+}
+
+inline constexpr bool hasValueCategory(ValueCategory Arg, ValueCategory Key) {
+  return Arg == Key || ((Arg & Key) == Key);
+}
+
+template 
+using UnCVRef =
+typename std::remove_cv::type>::type;
+
+template 
+constexpr ValueCategory getReferenceQuals() {
+  return std::is_lvalue_reference::value
+ ? VC_LVal
+ : (std::is_rvalue_reference::value ? VC_RVal : VC_None);
+}
+static_assert(getReferenceQuals() == VC_None, "");
+static_assert(getReferenceQuals() == VC_LVal, "");
+static_assert(getReferenceQuals() == VC_RVal, "");
+
+template 
+constexpr ValueCategory getCVQuals() {
+  using Vp = typename std::remove_reference::type;
+  return std::is_const::value && std::is_volatile::value
+ ? VC_ConstVolatile
+ : (std::is_const::value
+? VC_Const
+: (std::is_volatile::value ? VC_Volatile : VC_None));
+}
+static_assert(getCVQuals() == VC_None, "");
+static_assert(getCVQuals() == VC_Const, "");
+static_assert(getCVQuals() == VC_Volatile, "");
+static_assert(getCVQuals() == VC_ConstVolatile, "");
+static_assert(getCVQuals() == VC_None, "");
+static_assert(getCVQuals() == VC_Const, "");
+
+template 
+inline constexpr ValueCategory getValueCategory() {
+  return getReferenceQuals() | getCVQuals();
+}
+static_assert(getValueCategory() == VC_None, "");
+static_assert(getValueCategory() == (VC_LVal | VC_Const), "");
+static_assert(getValueCategory() ==
+  (VC_RVal | VC_ConstVolatile),
+  "");
+
+template 
+struct ApplyValueCategory {
+private:
+  static_assert(isValidValueCategory(VC), "");
+
+  template 
+  using CondT = typename std::conditional::type;
+
+public:
+  template >
+  using ApplyCVQuals = CondT<
+  hasValueCategory(VC, VC_ConstVolatile), typename std::add_cv::type,
+  CondT::type,
+CondT::type, Tp>>>;
+
+  template ::type>
+  using ApplyReferenceQuals =
+  CondT::type,
+CondT::type, Vp>>;
+
+  template 
+  using Apply = ApplyReferenceQuals>>;
+
+  template ::type = true>
+  static Apply> cast(Tp &&t) {

[PATCH] D91948: [WIP][analyzer][doc] Add Container- and IteratorModeling developer docs

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus requested changes to this revision.
Szelethus added a comment.
This revision now requires changes to proceed.

As far as content goes, here are my thoughts:

There is a huge block of comments in the source code: 
https://github.com/llvm/llvm-project/blob/main/clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp#L13.
 You have not mentioned these iterator categories: are they still a thing? If 
so, lets move those comments here, if not, just remove them altogether.

Please mention these docs on the top of iterator checker files.

Everything else:

In general, you have some meaningless sentences that I always catch myself 
writing as well: "There are a variety of techniques.". Its better to just list 
them straight away.




Comment at: clang/docs/analyzer/developer-docs/ContainerModeling.rst:105-106
+
+A container is modeled if it has an associated ``MemRegion``, and this 
``MemRegion``,
+or rather the ``const MemRegion*`` (and pointers to its subclasses), that is 
accessible
+by the ``MemRegionManager`` is what uniquely identifies a container. Temporary

I think `const MemRegion *` is implied.



Comment at: clang/docs/analyzer/developer-docs/ContainerModeling.rst:107-108
+or rather the ``const MemRegion*`` (and pointers to its subclasses), that is 
accessible
+by the ``MemRegionManager`` is what uniquely identifies a container. Temporary
+containers do not necessarily have a ``MemRegion``, these are not modeled.
+

Fair enough, is this true though for containers whose lifetime was extended? 
Maybe I should know this myself :^)



Comment at: clang/docs/analyzer/developer-docs/ContainerModeling.rst:132-140
+Apart from identifying the container with a ``MemRegion``, in order to 
interact with
+iterator modeling, the symbolic begin and end positions of the container are 
also tracked.
+The size (and as a special case, whether the container is empty or not) are 
properties that
+should also be tracked.
+
+.. note::
+  Currently, the implementation does not handle size and emptiness tracking, 
but patches

Huh, interesting, considering the earlier point about how you track iterator 
positions. Couldn't you just say that ` =  + `? I mean, onbviously not, because if it was that simple it 
would have landed already, but why is that so difficult? Half a sentence about 
this should suffice.



Comment at: clang/docs/analyzer/developer-docs/ContainerModeling.rst:213-214
+Iterators are modeled in the GDM with 2 kinds of keys:
+  - Region (``const MemRegion*``)
+  - Symbol (``SymbolRef``)
+There are therefore 2 maps which model iterators, one is called the RegionMap, 
the other is the SymbolMap.

whisperity wrote:
> 
This is the juicy part. I want some more thoughts in here: why? Can I have some 
examples?



Comment at: clang/docs/analyzer/developer-docs/ContainerModeling.rst:290-313
+Contrary to the container-modeling, not only lvalue iterators are tracked. 
This is the reason
+why 2 different keys are used in the GDM for iterators. An lvalue iterator has 
a Region
+(``const MemRegion*``) and it is used if available. If no Region is found for 
an iterator value
+then a Symbol is used (``SymbolRef``).
+
+In the case of pointer iterators (where std::is_pointer::value is true for 
the type T of the iterator),
+the modeling of the symbolic value is simpler. The lifetime of such values is 
simple to model,

whisperity wrote:
> whisperity wrote:
> > 
> Previously, `lvalue` was written as `LValue`!
Ah, there it is. Move it to where I placed my other inline! :) 



Comment at: clang/docs/analyzer/developer-docs/ContainerModeling.rst:301-305
+.. code-block:: cpp
+
+  int * it = cont.begin();
+  int * it = it + 1 + 1;
+  // SVal of it + 1 subexpression: NonLoc kind (designates an RValue)

This example is here to explain the previous two paragraphs, yet I'm left 
confused. I heard these things:

"If no Region is found for an iterator value then a Symbol is used 
(`SymbolRef`)."

Do we have a region here, or not? If we do, then this example doesn't 
demonstrate what was said highlighted in the first paragraph, so lets do that. 
There is no region here? Why?

"In the case of pointer iterators, the modeling of the symbolic value is 
simpler. The lifetime of such values is simple to model,
there is no need for constructors, destructors and copy-elision rules to be 
taken into consideration."

Do I gather correctly that we need to keep around a memregion and a symbolic 
value implementation anyways, so we might as well pick the easier one when 
possible? This look clunky, even if its true. With that said, a paragraph 
guiding me through the example outlining why its preferable to model `it` as a 
symbolic value would be appreciated.



Comment at: clang/docs/analyzer/developer-docs/ContainerModeling.rst:319
+RegionM

[PATCH] D95561: [Clang] Introduce Swift async calling convention.

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

LGTM other than the TargetInfo thing.




Comment at: clang/include/clang/Basic/TargetInfo.h:1424
+   triple.isAArch64();
+  }
+

As I commented in the other patch, I think this would be cleaner in the long 
term if you just implemented it directly in the various target subclasses.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95561

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

[PATCH] D96456: [ThinLTO, NewPM] Register sanitizers with OptimizerLastPassBuilderHook

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added inline comments.



Comment at: clang/lib/CodeGen/BackendUtil.cpp:1070-1071
+// ThinLTOIndexFile is provideds so we must be in ThinLTO PostLink.
+// For -O0 ThinLTO PreLink does basic optimization and triggers
+// OptimizerLastEPCallbacks. PostLink will not
+// run optimizations and this callback should

vitalybuka wrote:
> vitalybuka wrote:
> > tejohnson wrote:
> > > vitalybuka wrote:
> > > > aeubanks wrote:
> > > > > We could fix this. It doesn't make sense for only -O0 to run 
> > > > > OptimizerLastEPCallbacks prelink. Would that help simplify this?
> > > > Do you mean move optimizer of -O0 into PostLink as well?
> > > > Yes, this would be more consistent.
> > > > Still I guess it should a separate patch.
> > > > 
> > > Or does it make sense to go the other way, i.e. find a way to add the 
> > > sanitizer passes to the end of the pre-link of ThinLTO like for regular 
> > > LTO? The ThinLTO pre-link doesn't execute the module optimization 
> > > pipeline, but presumably at the end of buildThinLTOPreLinkDefaultPipeline 
> > > we could invoke the OptimizerLastEPCallbacks? That avoids the issue of 
> > > trying to get this working separately for in-process ThinLTO. And would 
> > > be more consistent with regular LTO.
> > I started from PreLink approach but @aeubanks advised the PostLink. At this 
> > point I slightly prefer it over PreLink. 
> > 
> > Sanitizers In PostLink pros:
> > + instrumentation of optimized code produces smaller binary
> > + optimizer called after instrumentation may removes some checks and we 
> > miss some bugs (It's the case for non-LTO for at least msan. It stops 
> > reporting some bugs. Maybe just a bug in msan.)
> > + StackSafetyAnalysis supports ThinLTO and can be used to optimize 
> > sanitizers.
> > + consistent with non-LTO pipeline
> > + OptimizerLastEPCallbacks called once per module (I guess not true for 
> > full LTO).
> > 
> > 
> > Sanitizers In PreLink pros:
> > + in-process ThinLTO. does not need special handling
> > + Simpler patch
> > + Can keep inconsistent -O0 pipeline (not sure why)
> > + consistent with regular LTO (but why regular LTO is not consistent with 
> > ThinLTO here?)
> > 
> > WDYT if ThinLTO PreLink with sanitizer use buildO0DefaultPipeline?
> > Sanitizers In PostLink pros:
> > + instrumentation of optimized code produces smaller binary
> 
> Strangely it's an opposite. On our "internal large binary" I see smaller 
> Asan/Msan sizes if we instrument PreLink.
> So this pro can be discarded.
> 
> At this point I don't have strong preference.
> 
> How can we agree which approach to use?
> 
I like the approach of doing the instrumentation in the prelink for now. The 
consistency with O0 and with regular LTO is a bonus, and the ability to handle 
in-process ThinLTO is a big benefit.

It may have some benefits as you found with the binary size because we can 
apply ThinLTO optimizations to the instrumented code.

I'm curious - what is the issue with StackSafetyAnalysis when this is done in 
the pre link?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96456

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

[PATCH] D96320: [ThinLTO, NewPM] Run OptimizerLastEPCallbacks from buildThinLTOPreLinkDefaultPipeline

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added a comment.

I tend to like this approach better for the reasons listed in D96456 
. @aeubanks any objections?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96320

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

[clang] 46757cc - [clang] functions with the 'const' or 'pure' attribute must always return.

[Jeroen Dobbelaere via cfe-commits]

Author: Jeroen Dobbelaere
Date: 2021-02-18T17:29:46+01:00
New Revision: 46757ccb49ab88da54ca8ddd43665d5255ee80f7

URL: 
https://github.com/llvm/llvm-project/commit/46757ccb49ab88da54ca8ddd43665d5255ee80f7
DIFF: 
https://github.com/llvm/llvm-project/commit/46757ccb49ab88da54ca8ddd43665d5255ee80f7.diff

LOG: [clang] functions with the 'const' or 'pure' attribute must always return.

As described in
* 
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-pure-function-attribute
* 
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-const-function-attribute

An `__attribute__((pure))` function must always return, as well as an 
`__attribute__((const))` function.

Reviewed By: jdoerfert

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

Added: 


Modified: 
clang/lib/CodeGen/CGCall.cpp
clang/test/CodeGen/complex-builtins.c
clang/test/CodeGen/complex-libcalls.c
clang/test/CodeGen/function-attributes.c
clang/test/CodeGenCXX/2009-05-04-PureConstNounwind.cpp
clang/test/Sema/libbuiltins-ctype-powerpc64.c
clang/test/Sema/libbuiltins-ctype-x86_64.c

Removed: 




diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index 405b4d2e1980..992e87319943 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -1994,9 +1994,14 @@ void CodeGenModule::ConstructAttributeList(
 if (TargetDecl->hasAttr()) {
   FuncAttrs.addAttribute(llvm::Attribute::ReadNone);
   FuncAttrs.addAttribute(llvm::Attribute::NoUnwind);
+  // gcc specifies that 'const' functions have greater restrictions than
+  // 'pure' functions, so they also cannot have infinite loops.
+  FuncAttrs.addAttribute(llvm::Attribute::WillReturn);
 } else if (TargetDecl->hasAttr()) {
   FuncAttrs.addAttribute(llvm::Attribute::ReadOnly);
   FuncAttrs.addAttribute(llvm::Attribute::NoUnwind);
+  // gcc specifies that 'pure' functions cannot have infinite loops.
+  FuncAttrs.addAttribute(llvm::Attribute::WillReturn);
 } else if (TargetDecl->hasAttr()) {
   FuncAttrs.addAttribute(llvm::Attribute::ArgMemOnly);
   FuncAttrs.addAttribute(llvm::Attribute::NoUnwind);

diff  --git a/clang/test/CodeGen/complex-builtins.c 
b/clang/test/CodeGen/complex-builtins.c
index 96c0e7117016..6fea8a9f028c 100644
--- a/clang/test/CodeGen/complex-builtins.c
+++ b/clang/test/CodeGen/complex-builtins.c
@@ -133,7 +133,7 @@ void foo(float f) {
 // NO__ERRNO: declare { x86_fp80, x86_fp80 } @cprojl({ x86_fp80, x86_fp80 }* 
byval({ x86_fp80, x86_fp80 }) align 16) [[NOT_READNONE]]
 // HAS_ERRNO: declare { double, double } @cproj(double, double) 
[[READNONE:#[0-9]+]]
 // HAS_ERRNO: declare <2 x float> @cprojf(<2 x float>) [[READNONE]]
-// HAS_ERRNO: declare { x86_fp80, x86_fp80 } @cprojl({ x86_fp80, x86_fp80 }* 
byval({ x86_fp80, x86_fp80 }) align 16) [[NOT_READNONE]]
+// HAS_ERRNO: declare { x86_fp80, x86_fp80 } @cprojl({ x86_fp80, x86_fp80 }* 
byval({ x86_fp80, x86_fp80 }) align 16) [[WILLRETURN_NOT_READNONE:#[0-9]+]]
 
   __builtin_cpow(f,f);   __builtin_cpowf(f,f);  __builtin_cpowl(f,f);
 
@@ -202,3 +202,4 @@ void foo(float f) {
 
 // HAS_ERRNO: attributes [[NOT_READNONE]] = { nounwind {{.*}} }
 // HAS_ERRNO: attributes [[READNONE]] = { {{.*}}readnone{{.*}} }
+// HAS_ERRNO: attributes [[WILLRETURN_NOT_READNONE]] = { nounwind willreturn 
{{.*}} }

diff  --git a/clang/test/CodeGen/complex-libcalls.c 
b/clang/test/CodeGen/complex-libcalls.c
index 9bd419a83821..44d6849c0a71 100644
--- a/clang/test/CodeGen/complex-libcalls.c
+++ b/clang/test/CodeGen/complex-libcalls.c
@@ -133,7 +133,7 @@ void foo(float f) {
 // NO__ERRNO: declare { x86_fp80, x86_fp80 } @cprojl({ x86_fp80, x86_fp80 }* 
byval({ x86_fp80, x86_fp80 }) align 16) [[NOT_READNONE]]
 // HAS_ERRNO: declare { double, double } @cproj(double, double) 
[[READNONE:#[0-9]+]]
 // HAS_ERRNO: declare <2 x float> @cprojf(<2 x float>) [[READNONE]]
-// HAS_ERRNO: declare { x86_fp80, x86_fp80 } @cprojl({ x86_fp80, x86_fp80 }* 
byval({ x86_fp80, x86_fp80 }) align 16) [[NOT_READNONE]]
+// HAS_ERRNO: declare { x86_fp80, x86_fp80 } @cprojl({ x86_fp80, x86_fp80 }* 
byval({ x86_fp80, x86_fp80 }) align 16) [[WILLRETURN_NOT_READNONE:#[0-9]+]]
 
   cpow(f,f);   cpowf(f,f);  cpowl(f,f);
 
@@ -202,3 +202,4 @@ void foo(float f) {
 
 // HAS_ERRNO: attributes [[NOT_READNONE]] = { nounwind {{.*}} }
 // HAS_ERRNO: attributes [[READNONE]] = { {{.*}}readnone{{.*}} }
+// HAS_ERRNO: attributes [[WILLRETURN_NOT_READNONE]] = { nounwind willreturn 
{{.*}} }

diff  --git a/clang/test/CodeGen/function-attributes.c 
b/clang/test/CodeGen/function-attributes.c
index ffb86a6cd272..f14f24801006 100644
--- a/clang/test/CodeGen/function-attributes.c
+++ b/clang/test/CodeGen/function-attributes.c
@@ -115,5 +115,5 @@ void f20(void) {
 // CHECK: attributes [[SR]] = { nounwind optsize{{.*}} "stackrealign"{{.*}} }
 // CHECK: 

[PATCH] D96960: [clang] functions with the 'const' or 'pure' attribute must always return.

[Jeroen Dobbelaere via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG46757ccb49ab: [clang] functions with the 'const' 
or 'pure' attribute must always return. (authored by 
jeroen.dobbelaere).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96960

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/complex-builtins.c
  clang/test/CodeGen/complex-libcalls.c
  clang/test/CodeGen/function-attributes.c
  clang/test/CodeGenCXX/2009-05-04-PureConstNounwind.cpp
  clang/test/Sema/libbuiltins-ctype-powerpc64.c
  clang/test/Sema/libbuiltins-ctype-x86_64.c

Index: clang/test/Sema/libbuiltins-ctype-x86_64.c
===
--- clang/test/Sema/libbuiltins-ctype-x86_64.c
+++ clang/test/Sema/libbuiltins-ctype-x86_64.c
@@ -62,4 +62,4 @@
 // CHECK: declare i32 @toupper(i32) [[NUW_RO:#[0-9]+]]
 
 // CHECK: attributes [[NUW_RO]] = { nounwind readonly{{.*}} }
-// CHECK: attributes [[NUW_RO_CALL]] = { nounwind readonly }
+// CHECK: attributes [[NUW_RO_CALL]] = { nounwind readonly willreturn }
Index: clang/test/Sema/libbuiltins-ctype-powerpc64.c
===
--- clang/test/Sema/libbuiltins-ctype-powerpc64.c
+++ clang/test/Sema/libbuiltins-ctype-powerpc64.c
@@ -62,4 +62,4 @@
 // CHECK: declare signext i32 @toupper(i32 signext) [[NUW_RO:#[0-9]+]]
 
 // CHECK: attributes [[NUW_RO]] = { nounwind readonly{{.*}} }
-// CHECK: attributes [[NUW_RO_CALL]] = { nounwind readonly }
+// CHECK: attributes [[NUW_RO_CALL]] = { nounwind readonly willreturn }
Index: clang/test/CodeGenCXX/2009-05-04-PureConstNounwind.cpp
===
--- clang/test/CodeGenCXX/2009-05-04-PureConstNounwind.cpp
+++ clang/test/CodeGenCXX/2009-05-04-PureConstNounwind.cpp
@@ -15,8 +15,8 @@
 // CHECK: declare i32 @_Z1tv() [[TF2:#[0-9]+]]
 
 // CHECK: attributes [[TF]] = { {{.*}} }
-// CHECK: attributes [[NUW_RN]] = { nounwind readnone{{.*}} }
-// CHECK: attributes [[NUW_RO]] = { nounwind readonly{{.*}} }
+// CHECK: attributes [[NUW_RN]] = { nounwind readnone willreturn{{.*}} }
+// CHECK: attributes [[NUW_RO]] = { nounwind readonly willreturn{{.*}} }
 // CHECK: attributes [[TF2]] = { {{.*}} }
-// CHECK: attributes [[NUW_RN_CALL]] = { nounwind readnone }
-// CHECK: attributes [[NUW_RO_CALL]] = { nounwind readonly }
+// CHECK: attributes [[NUW_RN_CALL]] = { nounwind readnone willreturn }
+// CHECK: attributes [[NUW_RO_CALL]] = { nounwind readonly willreturn }
Index: clang/test/CodeGen/function-attributes.c
===
--- clang/test/CodeGen/function-attributes.c
+++ clang/test/CodeGen/function-attributes.c
@@ -115,5 +115,5 @@
 // CHECK: attributes [[SR]] = { nounwind optsize{{.*}} "stackrealign"{{.*}} }
 // CHECK: attributes [[RT]] = { nounwind optsize returns_twice{{.*}} }
 // CHECK: attributes [[NR]] = { noreturn optsize }
-// CHECK: attributes [[NUW_RN]] = { nounwind optsize readnone }
+// CHECK: attributes [[NUW_RN]] = { nounwind optsize readnone willreturn }
 // CHECK: attributes [[RT_CALL]] = { optsize returns_twice }
Index: clang/test/CodeGen/complex-libcalls.c
===
--- clang/test/CodeGen/complex-libcalls.c
+++ clang/test/CodeGen/complex-libcalls.c
@@ -133,7 +133,7 @@
 // NO__ERRNO: declare { x86_fp80, x86_fp80 } @cprojl({ x86_fp80, x86_fp80 }* byval({ x86_fp80, x86_fp80 }) align 16) [[NOT_READNONE]]
 // HAS_ERRNO: declare { double, double } @cproj(double, double) [[READNONE:#[0-9]+]]
 // HAS_ERRNO: declare <2 x float> @cprojf(<2 x float>) [[READNONE]]
-// HAS_ERRNO: declare { x86_fp80, x86_fp80 } @cprojl({ x86_fp80, x86_fp80 }* byval({ x86_fp80, x86_fp80 }) align 16) [[NOT_READNONE]]
+// HAS_ERRNO: declare { x86_fp80, x86_fp80 } @cprojl({ x86_fp80, x86_fp80 }* byval({ x86_fp80, x86_fp80 }) align 16) [[WILLRETURN_NOT_READNONE:#[0-9]+]]
 
   cpow(f,f);   cpowf(f,f);  cpowl(f,f);
 
@@ -202,3 +202,4 @@
 
 // HAS_ERRNO: attributes [[NOT_READNONE]] = { nounwind {{.*}} }
 // HAS_ERRNO: attributes [[READNONE]] = { {{.*}}readnone{{.*}} }
+// HAS_ERRNO: attributes [[WILLRETURN_NOT_READNONE]] = { nounwind willreturn {{.*}} }
Index: clang/test/CodeGen/complex-builtins.c
===
--- clang/test/CodeGen/complex-builtins.c
+++ clang/test/CodeGen/complex-builtins.c
@@ -133,7 +133,7 @@
 // NO__ERRNO: declare { x86_fp80, x86_fp80 } @cprojl({ x86_fp80, x86_fp80 }* byval({ x86_fp80, x86_fp80 }) align 16) [[NOT_READNONE]]
 // HAS_ERRNO: declare { double, double } @cproj(double, double) [[READNONE:#[0-9]+]]
 // HAS_ERRNO: declare <2 x float> @cprojf(<2 x float>) [[READNONE]]
-// HAS_ERRNO: declare { x86_fp80, x86_fp80 } @cprojl({ x86_fp80, x86_fp80 }* byval({ x86_

[PATCH] D96616: [OpenCL][Docs] Change decription for the OpenCL standard headers

[Sven van Haastregt via Phabricator via cfe-commits]

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

LGTM!




Comment at: clang/docs/UsersManual.rst:3016
 
.. code-block:: console
 

Anastasia wrote:
> svenvh wrote:
> > I wonder if we need to keep this example?  You're not referring to it from 
> > the text and it's not demonstrating any special flags anymore.
> it's still demonstrating the use of default clang driver invocation i.e. 
> there are no flags needed to compile the code that uses BIFs.
Okay, if you want to make that explicit then I would suggest to add a line like:
```The following example shows how an OpenCL program that calls various 
standard builtin functions can be compiled without the need for any explicit 
includes or compiler flags.```


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

https://reviews.llvm.org/D96616

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

[PATCH] D96771: [OpenCL] Add distinct file extension for C++ for OpenCL

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D96771#2571582 , @awarzynski wrote:

> Hi @Anastasia , thank you for working on this!
>
> IIUC, this patch introduces:
>
> - new input types: `TY_CLCXX` and `TY_CLCXXHeader`
> - new language: `OpenCLCXX`
>
> Based on the attached test, this is only to remove the need for 
> `-cl-std=clc++`. Do you expect any other benefits of introducing the above 
> ^^^?

This is only the initial patch and for the moment the primary goal is to remove 
the need for the flag at least from the clang perspective.

> And are you planning to to update the OpenCL C++ tests not to use  
> `-cl-std=clc++`?

I was not sure about this. I just dislike the fact that moving files in the 
repo complicates the commit history lookup so I was not sure if the renaming 
was good or bad thing. Do you have any suggestions?

I was thinking to introduce as a guideline that the new tests should definitely 
use the new extension though.

I find the way driver is setup for the languages quite different so I was 
wondering if we have any guidelines?




Comment at: clang/lib/Driver/Types.cpp:163
 
-bool types::isOpenCL(ID Id) { return Id == TY_CL; }
+bool types::isOpenCL(ID Id) {
+  switch (Id) {

awarzynski wrote:
> This is not used.
This is used in the patch that is planned to be committed hopefully soon: 
https://reviews.llvm.org/D96515


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

https://reviews.llvm.org/D96771

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