[PATCH] D124060: [PowerPC] Enable CR bits support for Power8 and above.

[ChenZheng via Phabricator via cfe-commits]

shchenz added a comment.

> This patch turns on support for CR bit accesses for Power8 and above. The 
> reason why CR bits are turned on as the default for Power8 and above is that 
> because later architectures make use of builtins and instructions that 
> require CR bit accesses (such as the use of setbc in the vector string 
> isolate predicate and bcd builtins on Power10).

Maybe we also can add some comments in `docs/ClangCommandLineReference.rst` to 
explicitly say that `-mcrbits` will be default to on when PowerPC arch is no 
smaller than 8. I believe some cr-bit operations also exist on Power7 or even 
Power6?




Comment at: clang/lib/Basic/Targets/PPC.cpp:519
 .Default(false);
+  Features["crbits"] = llvm::StringSwitch(CPU)
+.Case("ppc64le", true)

If we set the `+crbits` by the arch name, do we still need the customization 
(Turn on crbits for O2 and above) in `computeFSAdditions()`? 



Comment at: clang/test/Driver/ppc-crbits.cpp:50
+// RUN: %clang -target powerpc64le-unknown-linux-gnu -mcpu=pwr7 -mno-crbits \
+// RUN:   -emit-llvm -S %s -o - | FileCheck %s --check-prefix=HAS-NOCRBITS
+

Do we need some cases for AIX?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124060

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

[PATCH] D124239: [analyzer] Fix ValistChecker false-positive involving symbolic pointers

[Balázs Benics via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGbe744da01f9d: [analyzer] Fix ValistChecker false-positive 
involving symbolic pointers (authored by steakhal).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124239

Files:
  clang/lib/StaticAnalyzer/Checkers/ValistChecker.cpp
  clang/test/Analysis/valist-uninitialized-no-undef.c


Index: clang/test/Analysis/valist-uninitialized-no-undef.c
===
--- clang/test/Analysis/valist-uninitialized-no-undef.c
+++ clang/test/Analysis/valist-uninitialized-no-undef.c
@@ -16,11 +16,20 @@
 
 void f6(va_list *fst, ...) {
   va_start(*fst, fst);
-  // FIXME: There should be no warning for this.
-  (void)va_arg(*fst, int); // expected-warning{{va_arg() is called on an 
uninitialized va_list}}
-  // expected-note@-1{{va_arg() is called on an uninitialized va_list}}
+  (void)va_arg(*fst, int);
   va_end(*fst);
-} 
+}
+
+int va_list_get_int(va_list *va) {
+  return va_arg(*va, int); // no-warning
+}
+
+struct MyVaList {
+  va_list l;
+};
+int va_list_get_int2(struct MyVaList *va) {
+  return va_arg(va->l, int); // no-warning
+}
 
 void call_vprintf_bad(int isstring, ...) {
   va_list va;
Index: clang/lib/StaticAnalyzer/Checkers/ValistChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/ValistChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/ValistChecker.cpp
@@ -178,7 +178,7 @@
 if (isa(DeclReg->getDecl()))
   Reg = C.getState()->getSVal(SV.castAs()).getAsRegion();
   }
-  IsSymbolic = Reg && Reg->getAs();
+  IsSymbolic = Reg && Reg->getBaseRegion()->getAs();
   // Some VarRegion based VA lists reach here as ElementRegions.
   const auto *EReg = dyn_cast_or_null(Reg);
   return (EReg && VaListModelledAsArray) ? EReg->getSuperRegion() : Reg;


Index: clang/test/Analysis/valist-uninitialized-no-undef.c
===
--- clang/test/Analysis/valist-uninitialized-no-undef.c
+++ clang/test/Analysis/valist-uninitialized-no-undef.c
@@ -16,11 +16,20 @@
 
 void f6(va_list *fst, ...) {
   va_start(*fst, fst);
-  // FIXME: There should be no warning for this.
-  (void)va_arg(*fst, int); // expected-warning{{va_arg() is called on an uninitialized va_list}}
-  // expected-note@-1{{va_arg() is called on an uninitialized va_list}}
+  (void)va_arg(*fst, int);
   va_end(*fst);
-} 
+}
+
+int va_list_get_int(va_list *va) {
+  return va_arg(*va, int); // no-warning
+}
+
+struct MyVaList {
+  va_list l;
+};
+int va_list_get_int2(struct MyVaList *va) {
+  return va_arg(va->l, int); // no-warning
+}
 
 void call_vprintf_bad(int isstring, ...) {
   va_list va;
Index: clang/lib/StaticAnalyzer/Checkers/ValistChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/ValistChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/ValistChecker.cpp
@@ -178,7 +178,7 @@
 if (isa(DeclReg->getDecl()))
   Reg = C.getState()->getSVal(SV.castAs()).getAsRegion();
   }
-  IsSymbolic = Reg && Reg->getAs();
+  IsSymbolic = Reg && Reg->getBaseRegion()->getAs();
   // Some VarRegion based VA lists reach here as ElementRegions.
   const auto *EReg = dyn_cast_or_null(Reg);
   return (EReg && VaListModelledAsArray) ? EReg->getSuperRegion() : Reg;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] be744da - [analyzer] Fix ValistChecker false-positive involving symbolic pointers

[Balazs Benics via cfe-commits]

Author: Balazs Benics
Date: 2022-04-26T08:49:05+02:00
New Revision: be744da01f9da0675ba5a3958c03bcd1fdc8ad60

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

LOG: [analyzer] Fix ValistChecker false-positive involving symbolic pointers

In the following example:

  int va_list_get_int(va_list *va) {
return va_arg(*va, int); // FP
  }

The `*va` expression will be something like `Element{SymRegion{va}, 0, 
va_list}`.
We use `ElementRegions` for representing the result of the dereference.
In this case, the `IsSymbolic` was set to `false` in the
`getVAListAsRegion()`.

Hence, before checking if the memregion is a SymRegion, we should take
the base of that region.

Analogously to the previous example, one can craft other cases:

  struct MyVaList {
va_list l;
  };
  int va_list_get_int(struct MyVaList va) {
return va_arg(va.l, int); // FP
  }

But it would also work if the `va_list` would be in the base or derived
part of a class. `ObjCIvarRegions` are likely also susceptible.
I'm not explicitly demonstrating these cases.

PS: Check the `MemRegion::getBaseRegion()` definition.

Fixes #55009

Reviewed By: xazax.hun

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

Added: 


Modified: 
clang/lib/StaticAnalyzer/Checkers/ValistChecker.cpp
clang/test/Analysis/valist-uninitialized-no-undef.c

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Checkers/ValistChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/ValistChecker.cpp
index 2ce95a9d47685..fbefd5f9ffdc9 100644
--- a/clang/lib/StaticAnalyzer/Checkers/ValistChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/ValistChecker.cpp
@@ -178,7 +178,7 @@ const MemRegion *ValistChecker::getVAListAsRegion(SVal SV, 
const Expr *E,
 if (isa(DeclReg->getDecl()))
   Reg = C.getState()->getSVal(SV.castAs()).getAsRegion();
   }
-  IsSymbolic = Reg && Reg->getAs();
+  IsSymbolic = Reg && Reg->getBaseRegion()->getAs();
   // Some VarRegion based VA lists reach here as ElementRegions.
   const auto *EReg = dyn_cast_or_null(Reg);
   return (EReg && VaListModelledAsArray) ? EReg->getSuperRegion() : Reg;

diff  --git a/clang/test/Analysis/valist-uninitialized-no-undef.c 
b/clang/test/Analysis/valist-uninitialized-no-undef.c
index 528ac86c14213..6d6542a6acf99 100644
--- a/clang/test/Analysis/valist-uninitialized-no-undef.c
+++ b/clang/test/Analysis/valist-uninitialized-no-undef.c
@@ -16,11 +16,20 @@ void call_inlined_uses_arg(int fst, ...) {
 
 void f6(va_list *fst, ...) {
   va_start(*fst, fst);
-  // FIXME: There should be no warning for this.
-  (void)va_arg(*fst, int); // expected-warning{{va_arg() is called on an 
uninitialized va_list}}
-  // expected-note@-1{{va_arg() is called on an uninitialized va_list}}
+  (void)va_arg(*fst, int);
   va_end(*fst);
-} 
+}
+
+int va_list_get_int(va_list *va) {
+  return va_arg(*va, int); // no-warning
+}
+
+struct MyVaList {
+  va_list l;
+};
+int va_list_get_int2(struct MyVaList *va) {
+  return va_arg(va->l, int); // no-warning
+}
 
 void call_vprintf_bad(int isstring, ...) {
   va_list va;



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

[PATCH] D124434: [Clang][Test] Run tests in C++14 mode explicitly.

[Jun Zhang via Phabricator via cfe-commits]

junaire created this revision.
junaire added reviewers: dblaikie, nikic, tstellar.
Herald added a subscriber: mstorsjo.
Herald added a project: All.
junaire requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

Some tests are not specify their langauge standard but using the default
value (currently is C++14), but this will cause problems when we want to
raise the default C++ version to C++17 in the future if the behavior
changes. This patch mostly just add `-std=c++14` or `-std=gnu++14` in
the RUN line, hopefully, it will remove one of the obstacles to out progress.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D124434

Files:
  clang/test/AST/ast-dump-openmp-begin-declare-variant_11.c
  clang/test/AST/ast-dump-openmp-begin-declare-variant_template_3.cpp
  clang/test/AST/ast-dump-undeduced-expr.cpp
  clang/test/AST/sourceranges.cpp
  clang/test/Analysis/blocks.m
  clang/test/CXX/basic/basic.stc/basic.stc.dynamic/p2.cpp
  clang/test/CXX/class.access/class.friend/p1.cpp
  clang/test/CXX/class/class.friend/p2.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.stc/p2.cpp
  clang/test/CXX/except/except.spec/p2-dynamic-types.cpp
  clang/test/CXX/except/except.spec/p9-dynamic.cpp
  clang/test/CXX/stmt.stmt/stmt.select/p3.cpp
  clang/test/CXX/temp/temp.arg/temp.arg.nontype/p1.cpp
  clang/test/CXX/temp/temp.res/temp.local/p3.cpp
  clang/test/CodeGen/typedef_alignment_mismatch_warning.cpp
  clang/test/CodeGenCXX/align-avx-complete-objects.cpp
  clang/test/CodeGenCXX/copy-constructor-elim-2.cpp
  clang/test/CodeGenCXX/debug-info-template-parameter.cpp
  clang/test/CodeGenCXX/debug-info-template-partial-specialization.cpp
  clang/test/CodeGenCXX/exception-spec-decay.cpp
  clang/test/CodeGenCXX/exceptions-cxx-ehsc.cpp
  clang/test/CodeGenCXX/exceptions-no-rtti.cpp
  clang/test/CodeGenCXX/global-init.cpp
  clang/test/CodeGenCXX/no-exceptions.cpp
  clang/test/CodeGenCXX/override-bit-field-layout.cpp
  clang/test/CodeGenCXX/override-layout.cpp
  clang/test/CodeGenCXX/reference-temporary-ms.cpp
  clang/test/CodeGenCXX/rtti-linkage.cpp
  clang/test/Layout/ms-x86-vtordisp.cpp
  clang/test/Modules/update-exception-spec.cpp
  clang/test/OpenMP/declare_mapper_messages.cpp
  clang/test/PCH/cxx-functions.cpp
  clang/test/Parser/cxx-casting.cpp
  clang/test/Parser/cxx-class.cpp
  clang/test/Parser/cxx-template-argument.cpp
  clang/test/Parser/cxx-template-decl.cpp
  clang/test/Parser/cxx1z-nested-namespace-definition.cpp
  clang/test/Sema/ms_class_layout.cpp
  clang/test/SemaCXX/MicrosoftExtensions.cpp
  clang/test/SemaCXX/PR12778.cpp
  clang/test/SemaCXX/altivec.cpp
  clang/test/SemaCXX/bool.cpp
  clang/test/SemaCXX/default2.cpp
  clang/test/SemaCXX/exception-spec-no-exceptions.cpp
  clang/test/SemaCXX/exceptions.cpp
  clang/test/SemaCXX/expressions.cpp
  clang/test/SemaCXX/inline.cpp
  clang/test/SemaCXX/libstdcxx_is_pod_hack.cpp
  clang/test/SemaCXX/linkage2.cpp
  clang/test/SemaCXX/member-pointer.cpp
  clang/test/SemaCXX/missing-namespace-qualifier-typo-corrections.cpp
  clang/test/SemaCXX/new-delete.cpp
  clang/test/SemaCXX/static-data-member.cpp
  clang/test/SemaCXX/type-definition-in-specifier.cpp
  clang/test/SemaCXX/user-defined-conversions.cpp
  clang/test/SemaCXX/warn-new-overaligned-3.cpp
  clang/test/SemaCXX/warn-new-overaligned.cpp
  clang/test/SemaCXX/writable-strings-deprecated.cpp
  clang/test/SemaSYCL/zero-length-arrays.cpp
  clang/test/SemaTemplate/class-template-id.cpp
  clang/test/SemaTemplate/constructor-template.cpp
  clang/test/SemaTemplate/explicit-instantiation.cpp
  clang/test/SemaTemplate/instantiate-exception-spec.cpp
  clang/test/SemaTemplate/instantiation-default-2.cpp
  clang/test/SemaTemplate/temp_arg.cpp
  clang/test/SemaTemplate/temp_arg_template.cpp
  clang/test/SemaTemplate/typename-specifier-3.cpp
  clang/unittests/AST/ASTTraverserTest.cpp

Index: clang/unittests/AST/ASTTraverserTest.cpp
===
--- clang/unittests/AST/ASTTraverserTest.cpp
+++ clang/unittests/AST/ASTTraverserTest.cpp
@@ -280,7 +280,7 @@
 
 TEST(Traverse, IgnoreUnlessSpelledInSourceVars) {
 
-  auto AST = buildASTFromCode(R"cpp(
+  auto AST = buildASTFromCodeWithArgs(R"cpp(
 
 struct String
 {
@@ -346,7 +346,8 @@
   }
 }
 
-)cpp");
+)cpp",
+  {"-std=c++14"});
 
   {
 auto FN =
@@ -715,7 +716,7 @@
 
 TEST(Traverse, IgnoreUnlessSpelledInSourceReturns) {
 
-  auto AST = buildASTFromCode(R"cpp(
+  auto AST = buildASTFromCodeWithArgs(R"cpp(
 
 struct A
 {
@@ -784,7 +785,8 @@
   return c;
 }
 
-)cpp");
+)cpp",
+  {"-std=c++14"});
 
   auto getFunctionNode = [&AST](const std::string &name) {
 auto BN = ast_matchers::match(functionDecl(hasName(name)).bind("fn"),
Index: clang/test/SemaTemplate/typename-specifier-3.cpp
===
--- cl

[PATCH] D124432: Fix issues with using clangd with C++ modules

[Kugan Vivekanandarajah via Phabricator via cfe-commits]

kuganv created this revision.
Herald added subscribers: dexonsmith, usaxena95, kadircet, arphaman.
Herald added a project: All.
kuganv requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added projects: clang, clang-tools-extra.

Fixes following incompatibility issues with c++ modules
(clangd with c++ modules results in assertion failure and pch_langopt_mismatch 
#1105)

1. Preamble generated by clangd is generated with WriteCommentListToPCH = false;

However, if we are using precompiled modules that have comments in the
serialised AST, following sanity check in the clangd fails.

// Sanity check that the comment does not come from the PCH. We choose to not
// write them into PCH, because they are racy and slow to load.
assert(!Ctx.getSourceManager().isLoadedSourceLocation(RC→getBeginLoc()));

In this patch when we are generating Preamble with
WriteCommentListToPCH, we do not load the comments from AST.

2. If we have modules that are built with RetainCommentsFromSystemHeaders

difference, that would prevent modules from getting loaded. Since this
difference is not critical that should be stopping modules from being loaded,
this patch changes it to be a COMPATIBLE_LANGOPT.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D124432

Files:
  clang-tools-extra/clangd/test/modules-options-compatablity-test/A.h
  clang-tools-extra/clangd/test/modules-options-compatablity-test/B.h
  
clang-tools-extra/clangd/test/modules-options-compatablity-test/compile_commands.json
  
clang-tools-extra/clangd/test/modules-options-compatablity-test/definition.jsonrpc
  
clang-tools-extra/clangd/test/modules-options-compatablity-test/module.modulemap
  clang-tools-extra/clangd/test/modules-options-compatablity-test/use.c
  clang-tools-extra/clangd/test/modules-options-compatablity.test
  clang/include/clang/Basic/LangOptions.def
  clang/lib/Serialization/ASTReader.cpp

Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -3077,6 +3077,10 @@
   return Err;
 if (llvm::Error Err = ReadBlockAbbrevs(C, COMMENTS_BLOCK_ID))
   return Err;
+if (PP.getPreprocessorOpts().GeneratePreamble &&
+!PP.getPreprocessorOpts().WriteCommentListToPCH) {
+  break;
+}
 CommentsCursors.push_back(std::make_pair(C, &F));
 break;
   }
Index: clang/include/clang/Basic/LangOptions.def
===
--- clang/include/clang/Basic/LangOptions.def
+++ clang/include/clang/Basic/LangOptions.def
@@ -387,7 +387,7 @@
 
 LANGOPT(XLPragmaPack, 1, 0, "IBM XL #pragma pack handling")
 
-LANGOPT(RetainCommentsFromSystemHeaders, 1, 0, "retain documentation comments from system headers in the AST")
+COMPATIBLE_LANGOPT(RetainCommentsFromSystemHeaders, 1, 0, "retain documentation comments from system headers in the AST")
 
 LANGOPT(SanitizeAddressFieldPadding, 2, 0, "controls how aggressive is ASan "
"field padding (0: none, 1:least "
Index: clang-tools-extra/clangd/test/modules-options-compatablity.test
===
--- /dev/null
+++ clang-tools-extra/clangd/test/modules-options-compatablity.test
@@ -0,0 +1,10 @@
+
+# RUN: rm -rf %t && mkdir -p %t
+# RUN: cp -r %S/modules-options-compatablity-test/* %t
+# RUN: mkdir -p %t/prebuilt
+# RUN: sed -i -e "s|DIRECTORY|%t|g" %t/definition.jsonrpc
+# RUN: sed -i -e "s|DIRECTORY|%t|g" %t/compile_commands.json
+# RUN: %clang -cc1 -emit-module -o %t/prebuilt/A.pcm -fmodules %t/module.modulemap -fmodule-name=A
+# RUN: %clang -cc1 -fretain-comments-from-system-headers -emit-module -o %t/prebuilt/B.pcm -fmodules %t/module.modulemap -fmodule-name=B -fprebuilt-module-path=%t/prebuilt
+# RUN: rm %t/*.h
+# RUN: clangd -background-index -lit-test < %t/definition.jsonrpc
Index: clang-tools-extra/clangd/test/modules-options-compatablity-test/use.c
===
--- /dev/null
+++ clang-tools-extra/clangd/test/modules-options-compatablity-test/use.c
@@ -0,0 +1,5 @@
+/* use */
+#include 
+#include 
+
+void use() { a(); }
Index: clang-tools-extra/clangd/test/modules-options-compatablity-test/module.modulemap
===
--- /dev/null
+++ clang-tools-extra/clangd/test/modules-options-compatablity-test/module.modulemap
@@ -0,0 +1,8 @@
+/* module.modulemap */
+module A {
+  header "A.h"
+}
+module B {
+  header "B.h"
+  export *
+}
Index: clang-tools-extra/clangd/test/modules-options-compatablity-test/definition.jsonrpc
===
--- /dev/null
+++ clang-tools-extra/clangd/test/modules-options-compatablity-test/definition.jsonrpc
@@ -0,0 +1,28 @@
+{

[PATCH] D118409: [OpenMPIRBuilder] Remove ContinuationBB argument from Body callback.

[Michael Kruse via Phabricator via cfe-commits]

Meinersbur added inline comments.



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:5571-5579
+  {
+OMPBuilderCBHelpers::InlinedRegionBodyRAII IRB(*this, AllocaIP,
+   *FiniBB);
+EmitStmt(CS->getCapturedStmt());
+  }
+
+  if (Builder.saveIP().isSet())

kiranchandramohan wrote:
> Why is it not possible to use `OMPBuilderCBHelpers::EmitOMPInlinedRegionBody` 
> here?
`EmitOMPInlinedRegionBody`  calls `splitBBWithSuffix`, which has already been 
done in this lambda.



Comment at: llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h:26-58
+/// Move the instruction after an InsertPoint to the beginning of another
+/// BasicBlock.
+///
+/// The instructions after \p IP are moved to the beginning of \p New which 
must
+/// not have any PHINodes. If \p CreateBranch is true, a branch instruction to
+/// \p New will be added such that there is no semantic change. Otherwise, the
+/// \p IP insert block remains degenerate and it is up to the caller to insert 
a

kiranchandramohan wrote:
> I guess these are already in from your other patch 
> (https://reviews.llvm.org/D114413).
Yes, now public because also used in CodegenOpenMP.

These utility functions avoid all the workarounds that 
`splitBasicBlock`/`SplitBlock` do not all degenerate blocks, such as inserting 
temporary terminators or ContinuationBB (There may be insertion points 
referencing those temporary terminators!!).



Comment at: 
mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp:103
+  llvm::BasicBlock *continuationBlock =
+  splitBB(builder, true, "omp.region.cont");
+  llvm::BasicBlock *sourceBlock = builder.GetInsertBlock();

kiranchandramohan wrote:
> Would this "omp.region.cont" be a mostly empty block in most cases? I guess 
> it is not a problem since llvm will remove these blocks.
> 
> The IR generated for 
> ```
>   omp.parallel {
> omp.barrier
> omp.terminator
>   }
> ```
> is the following. Notice the empty (only a branch) `omp.region.cont` block. 
> Previously we had this only at the source side `omp.par.region`.
> 
> ```
> omp.par.entry:
>   %tid.addr.local = alloca i32, align 4
>   %0 = load i32, i32* %tid.addr, align 4
>   store i32 %0, i32* %tid.addr.local, align 4
>   %tid = load i32, i32* %tid.addr.local, align 4
>   br label %omp.par.region
> 
> omp.par.region:   ; preds = %omp.par.entry
>   br label %omp.par.region1
> 
> omp.par.region1:  ; preds = %omp.par.region
>   %omp_global_thread_num2 = call i32 
> @__kmpc_global_thread_num(%struct.ident_t* @4)
>   call void @__kmpc_barrier(%struct.ident_t* @3, i32 %omp_global_thread_num2)
>   br label %omp.region.cont, !dbg !12
> 
> omp.region.cont:  ; preds = %omp.par.region1
>   br label %omp.par.pre_finalize
> 
> omp.par.pre_finalize: ; preds = %omp.region.cont
>   br label %omp.par.outlined.exit.exitStub
> ```
Empty BBs should not be considered an issue since they are removed by 
SimplifyCFG anyway. Why would it be? Correctness should be the priority. 

What makes the current code so fragile are the conditions that depend on the 
current insert point. Invoking it in a different manner causes an untested code 
path to be taken. For instance, an insert point becomes invalided that did not 
under any previous test because nobody yet inserted new BBs in a callback. One 
if condition inside the callback and everything breaks.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118409

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

[PATCH] D123319: Change how we handle auto return types for lambda operator() to be consistent with gcc

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added a comment.

In D123319#3473283 , @dblaikie wrote:

> ('scuse the delay)
>
> Baseline: I'm still not really sure this is the right direction. Is there a 
> sound argument for why this change is suitable for lambdas, but not for other 
> types? I believe all the situations that can happen with other types can 
> happen with lambdas (& the other way around) with sufficiently interestingly 
> crafted inputs.

I had a couple of approaches but once I saw how gcc was handling it, I just 
went with consistency with gcc. I might have been missing some cases but I did 
not have other test case that I ran into issues with.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123319

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

[PATCH] D121177: [modules] Merge equivalent extensions and diagnose ivar redeclarations for extensions loaded from different modules.

[Volodymyr Sapsai via Phabricator via cfe-commits]

vsapsai added inline comments.



Comment at: clang/lib/Serialization/ASTReaderDecl.cpp:1261-1263
+  Reader.Diag(IVD->getLocation(), diag::err_duplicate_ivar_declaration)
+  << II;
+  Reader.Diag(PrevIvar->getLocation(), diag::note_previous_definition);

We emit diagnostic for
```lang=objective-c
@implementation TestClass {
@public
  struct { int z; } implementationIvar;
}
@end
```

from merge-anon-record-definition-in-objc.m because we handle only 
`ObjCCategoryDecl` and not `ObjCImplementationDecl`. It is very uncommon to put 
implementation in a header file but I still need to check we don't emit 
duplicate ivar metadata in this case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121177

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

[PATCH] D123924: [clang-apply-replacements] Added an option to ignore insert conflict.

[liushuai wang via Phabricator via cfe-commits]

MTC added inline comments.



Comment at: clang/include/clang/Tooling/Refactoring/AtomicChange.h:119
 
+  Replacements &getRefReplacements() { return Replaces; }
+

IMHO, there is no need to rename the method to get the non-const version.  The 
following code is ok enough

`Replacements &getReplacements() { return Replaces; }`


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

https://reviews.llvm.org/D123924

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

[PATCH] D112921: [clang] Enable sized deallocation by default in C++14 onwards

[Wang Pengcheng via Phabricator via cfe-commits]

pcwang-thead added a comment.

In D112921#3473022 , @ldionne wrote:

> (BTW I strongly support this patch, I just think we should do it properly on 
> all platforms from the start :-)

I couldn't agree with you more, but I have no idea how to implement it. :-(

In D112921#3473080 , @rjmccall wrote:

> Ideally, I think, we would set this up to work something like `ObjCRuntime`, 
> where we're making queries to a common place that contains all the 
> information necessary to decide what runtime features are available.  In 
> particular, we shouldn't treat Apple platforms as forever unique in providing 
> a stable runtime interface with availability gating.
>
> Now, we don't necessarily need the same complexity that `ObjCRuntime` 
> supports, where the user can tell us to use a different runtime and runtime 
> version from the default for the platform.  On the other hand, maybe we want 
> that, because it's a good way to deal with the compatibility problem that we 
> have on non-Apple platforms.  Users could tell us that they're targeting e.g. 
> libsupc++ v4.8, and we could tell them in response that sized allocation 
> isn't supported.  And if we get them to tell us that, rather than "I have 
> sized allocation support" specifically, it sets us up well to solve similar 
> problems in the future.

You mean that we may provide a option `-fc++-runtime` likes `-fobjc-runtime`, 
or extend `-stdlib` to specify version number in the form of  
`-stdlib=libsupc++-v4.8`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112921

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

[PATCH] D123319: Change how we handle auto return types for lambda operator() to be consistent with gcc

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added inline comments.



Comment at: clang/test/CodeGenCXX/no_auto_return_lambda.cpp:1
+// RUN: %clang_cc1 -emit-llvm -debug-info-kind=limited %s -o - | FileCheck %s
+

erichkeane wrote:
> erichkeane wrote:
> > So this CodeGen test without a triple is a bit troublesome.  The one we've 
> > noticed that this fails on the 32 bit windows build:
> > 
> > ```
> > FAIL: Clang :: CodeGenCXX/no_auto_return_lambda.cpp (41841 of 57667)
> >  TEST 'Clang :: CodeGenCXX/no_auto_return_lambda.cpp' 
> > FAILED 
> > Script:
> > --
> > : 'RUN: at line 1';   
> > d:\netbatch\build_comp02320_00\ics_top\builds\xmainoclx86win_prod\llvm\bin\clang.exe
> >  -cc1 -internal-isystem 
> > d:\netbatch\build_comp02320_00\ics_top\builds\xmainoclx86win_prod\llvm\lib\clang\15.0.0\include
> >  -nostdsysteminc -emit-llvm -debug-info-kind=limited 
> > D:\netbatch\build_comp02320_00\ics_top\llvm\clang\test\CodeGenCXX\no_auto_return_lambda.cpp
> >  -o - | 
> > d:\netbatch\build_comp02320_00\ics_top\builds\xmainoclx86win_prod\llvm\bin\filecheck.exe
> >  
> > D:\netbatch\build_comp02320_00\ics_top\llvm\clang\test\CodeGenCXX\no_auto_return_lambda.cpp
> > --
> > Exit Code: 1Command Output (stdout):
> > --
> > $ ":" "RUN: at line 1"
> > $ 
> > "d:\netbatch\build_comp02320_00\ics_top\builds\xmainoclx86win_prod\llvm\bin\clang.exe"
> >  "-cc1" "-internal-isystem" 
> > "d:\netbatch\build_comp02320_00\ics_top\builds\xmainoclx86win_prod\llvm\lib\clang\15.0.0\include"
> >  "-nostdsysteminc" "-emit-llvm" "-debug-info-kind=limited" 
> > "D:\netbatch\build_comp02320_00\ics_top\llvm\clang\test\CodeGenCXX\no_auto_return_lambda.cpp"
> >  "-o" "-"
> > $ 
> > "d:\netbatch\build_comp02320_00\ics_top\builds\xmainoclx86win_prod\llvm\bin\filecheck.exe"
> >  
> > "D:\netbatch\build_comp02320_00\ics_top\llvm\clang\test\CodeGenCXX\no_auto_return_lambda.cpp"
> > # command stderr:
> > D:\netbatch\build_comp02320_00\ics_top\llvm\clang\test\CodeGenCXX\no_auto_return_lambda.cpp:24:11:
> >  error: CHECK: expected string not found in input
> > // CHECK: ![[FUN_TYPE_LAMBDA]] = !DISubroutineType(types: 
> > ![[TYPE_NODE_LAMBDA:[0-9]+]])
> >   ^
> > :56:289: note: scanning from here
> > !17 = distinct !DISubprogram(name: "operator()", linkageName: 
> > "??R@?0??g@@YAHXZ@QBE?A?@@XZ", scope: !13, file: !7, line: 
> > 9, type: !18, scopeLine: 9, flags: DIFlagPrototyped, spFlags: 
> > DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, declaration: !22, 
> > retainedNodes: !11) 
> >   ^
> > :56:289: note: with "FUN_TYPE_LAMBDA" equal to "18"
> > !17 = distinct !DISubprogram(name: "operator()", linkageName: 
> > "??R@?0??g@@YAHXZ@QBE?A?@@XZ", scope: !13, file: !7, line: 
> > 9, type: !18, scopeLine: 9, flags: DIFlagPrototyped, spFlags: 
> > DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, declaration: !22, 
> > retainedNodes: !11) 
> >   ^
> > :57:1: note: possible intended match here
> > !18 = !DISubroutineType(cc: DW_CC_BORLAND_thiscall, types: !19)
> > ^Input file: 
> > Check file: 
> > D:\netbatch\build_comp02320_00\ics_top\llvm\clang\test\CodeGenCXX\no_auto_return_lambda.cpp
> > -dump-input=help explains the following input dump.Input was:
> > <<
> > .
> > .
> > .
> >51: !12 = !DILocalVariable(name: "f", scope: !6, file: !7, line: 
> > 9, type: !13)
> >52: !13 = distinct !DICompositeType(tag: DW_TAG_class_type, 
> > scope: !6, file: !7, line: 9, size: 8, flags: DIFlagTypePassByValue | 
> > DIFlagNonTrivial, elements: !11)
> >53: !14 = !DILocation(line: 9, column: 8, scope: !6)
> >54: !15 = !DILocation(line: 10, column: 10, scope: !6)
> >55: !16 = !DILocation(line: 10, column: 3, scope: !6)
> >56: !17 = distinct !DISubprogram(name: "operator()", 
> > linkageName: "??R@?0??g@@YAHXZ@QBE?A?@@XZ", scope: !13, 
> > file: !7, line: 9, type: !18, scopeLine: 9, flags: DIFlagPrototyped, 
> > spFlags: DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, declaration: 
> > !22, retainedNodes: !11)
> > check:24'0  
> > 
> > 
> >
> > X error: no match found
> > check:24'1  
> > 
> > 
> > 
> >  with "FUN_TYPE_LAMBDA" equal to "18"
> >   

[PATCH] D124427: [Serialization] Pack Expr ObjectKind and ValueKind into one VBR.

[Sam McCall via Phabricator via cfe-commits]

sammccall created this revision.
sammccall added a reviewer: kadircet.
Herald added a subscriber: usaxena95.
Herald added a project: All.
sammccall requested review of this revision.
Herald added subscribers: cfe-commits, ilya-biryukov.
Herald added a project: clang.

Most Exprs are serialized unabbreviated, so this saves 6 bits per expr.
This is worth 0.3% on clangd --check=clangd/AST.cpp: 42276772 -> 42187128
Not terribly much but a trivial change...


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D124427

Files:
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp


Index: clang/lib/Serialization/ASTWriterStmt.cpp
===
--- clang/lib/Serialization/ASTWriterStmt.cpp
+++ clang/lib/Serialization/ASTWriterStmt.cpp
@@ -544,8 +544,9 @@
   VisitStmt(E);
   Record.AddTypeRef(E->getType());
   Record.push_back(E->getDependence());
-  Record.push_back(E->getValueKind());
-  Record.push_back(E->getObjectKind());
+  // Stmt is often written unabbreviated.
+  // VK(2) + OK(3) fit together into a single VBR6 chunk.
+  Record.push_back(E->getValueKind() | E->getObjectKind() << 2);
 }
 
 void ASTStmtWriter::VisitConstantExpr(ConstantExpr *E) {
Index: clang/lib/Serialization/ASTWriterDecl.cpp
===
--- clang/lib/Serialization/ASTWriterDecl.cpp
+++ clang/lib/Serialization/ASTWriterDecl.cpp
@@ -2296,9 +2296,8 @@
   // Expr
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // Type
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, ExprDependenceBits));
-  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetValueKind
-  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetObjectKind
-  //DeclRefExpr
+  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 5)); // ValueKind, 
ObjectKind
+  // DeclRefExpr
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //HasQualifier
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //GetDeclFound
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); //ExplicitTemplateArgs
@@ -2316,9 +2315,8 @@
   // Expr
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // Type
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, ExprDependenceBits));
-  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetValueKind
-  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetObjectKind
-  //Integer Literal
+  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 5)); // ValueKind, 
ObjectKind
+  // Integer Literal
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // Location
   Abv->Add(BitCodeAbbrevOp(32));  // Bit Width
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // Value
@@ -2331,9 +2329,8 @@
   // Expr
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // Type
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, ExprDependenceBits));
-  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetValueKind
-  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetObjectKind
-  //Character Literal
+  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 5)); // ValueKind, 
ObjectKind
+  // Character Literal
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // getValue
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // Location
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); // getKind
@@ -2346,8 +2343,7 @@
   // Expr
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // Type
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, ExprDependenceBits));
-  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetValueKind
-  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 3)); //GetObjectKind
+  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 5)); // ValueKind, 
ObjectKind
   // CastExpr
   Abv->Add(BitCodeAbbrevOp(0)); // PathSize
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // HasFPFeatures
Index: clang/lib/Serialization/ASTReaderStmt.cpp
===
--- clang/lib/Serialization/ASTReaderStmt.cpp
+++ clang/lib/Serialization/ASTReaderStmt.cpp
@@ -107,7 +107,7 @@
 
 /// The number of record fields required for the Expr class
 /// itself.
-static const unsigned NumExprFields = NumStmtFields + 4;
+static const unsigned NumExprFields = NumStmtFields + 3;
 
 /// Read and initialize a ExplicitTemplateArgumentList structure.
 void ReadTemplateKWAndArgsInfo(ASTTemplateKWAndArgsInfo &Args,
@@ -521,8 +521,9 @@
   VisitStmt(E);
   E->setType(Record.readType());
   E->setDependence(static_cast(Record.readInt()));
-  E->setValueKind(static_cast(Record.readInt()));
-  E->setObjectKind(static_cast(Record.readInt()));
+  unsigned OKVK = Record.readInt();
+  E->setValueKind(static_cast(OKVK & 0x3));
+  E->setObjectKind(static_cast(OKVK >> 2));
   assert(Record.getIdx() == NumExprFields &&
  "Incorrect expressi

[PATCH] D121177: [modules] Merge equivalent extensions and diagnose ivar redeclarations for extensions loaded from different modules.

[Volodymyr Sapsai via Phabricator via cfe-commits]

vsapsai updated this revision to Diff 425093.
vsapsai added a comment.

Rebase and update test to use `ptr` instead of `i64*`. Also now the added test 
is failing for `implementationIvar`, investigating that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121177

Files:
  clang/include/clang/AST/DeclObjC.h
  clang/include/clang/Serialization/ASTReader.h
  clang/lib/AST/DeclObjC.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/test/Modules/merge-extension-ivars.m
  clang/test/Modules/redecl-ivars.m

Index: clang/test/Modules/redecl-ivars.m
===
--- /dev/null
+++ clang/test/Modules/redecl-ivars.m
@@ -0,0 +1,166 @@
+// UNSUPPORTED: -zos, -aix
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: %clang_cc1 -fsyntax-only -fobjc-runtime=macosx-10.9 -verify -I%t/include %t/test-mismatch-in-extension.m
+// RUN: %clang_cc1 -fsyntax-only -fobjc-runtime=macosx-10.9 -verify -I%t/include %t/test-mismatch-in-extension.m \
+// RUN:-fmodules -fimplicit-module-maps -fmodules-cache-path=%t/modules.cache
+
+// RUN: %clang_cc1 -fsyntax-only -fobjc-runtime=macosx-10.9 -verify -I%t/include %t/test-mismatch-in-ivars-number.m
+// RUN: %clang_cc1 -fsyntax-only -fobjc-runtime=macosx-10.9 -verify -I%t/include %t/test-mismatch-in-ivars-number.m \
+// RUN:-fmodules -fimplicit-module-maps -fmodules-cache-path=%t/modules.cache
+
+// RUN: %clang_cc1 -fsyntax-only -fobjc-runtime=macosx-10.9 -verify -I%t/include %t/test-mismatch-in-methods-protocols.m
+// RUN: %clang_cc1 -fsyntax-only -fobjc-runtime=macosx-10.9 -verify -I%t/include %t/test-mismatch-in-methods-protocols.m \
+// RUN:-fmodules -fimplicit-module-maps -fmodules-cache-path=%t/modules.cache
+
+// RUN: %clang_cc1 -fsyntax-only -fobjc-runtime=macosx-10.9 -verify -I%t/include %t/test-redecl-in-subclass.m
+// RUN: %clang_cc1 -fsyntax-only -fobjc-runtime=macosx-10.9 -verify -I%t/include %t/test-redecl-in-subclass.m \
+// RUN:-fmodules -fimplicit-module-maps -fmodules-cache-path=%t/modules.cache
+
+// RUN: %clang_cc1 -fsyntax-only -fobjc-runtime=macosx-10.9 -verify -I%t/include %t/test-redecl-in-implementation.m
+// RUN: %clang_cc1 -fsyntax-only -fobjc-runtime=macosx-10.9 -verify -I%t/include %t/test-redecl-in-implementation.m \
+// RUN:-fmodules -fimplicit-module-maps -fmodules-cache-path=%t/modules.cache
+
+// Same class extensions with the same ivars but from different modules aren't considered
+// an error and they are merged together. Test that differences in extensions and/or ivars
+// are still reported as errors.
+
+//--- include/Interfaces.h
+@interface NSObject @end
+@interface ObjCInterface : NSObject
+@end
+@interface ObjCInterfaceLevel2 : ObjCInterface
+@end
+
+@protocol Protocol1 @end
+@protocol Protocol2 @end
+
+//--- include/IvarsInExtensions.h
+#import 
+@interface ObjCInterface() {
+  int ivarName;
+}
+@end
+@interface ObjCInterfaceLevel2() {
+  int bitfieldIvarName: 3;
+}
+@end
+
+//--- include/IvarsInExtensionsWithMethodsProtocols.h
+#import 
+@interface ObjCInterface() {
+  int methodRelatedIvar;
+}
+- (void)test;
+@end
+@interface ObjCInterfaceLevel2()  {
+  int protocolRelatedIvar;
+}
+@end
+
+//--- include/IvarInImplementation.h
+#import 
+@implementation ObjCInterface {
+  int ivarName;
+}
+@end
+
+//--- include/module.modulemap
+module Interfaces {
+  header "Interfaces.h"
+  export *
+}
+module IvarsInExtensions {
+  header "IvarsInExtensions.h"
+  export *
+}
+module IvarsInExtensionsWithMethodsProtocols {
+  header "IvarsInExtensionsWithMethodsProtocols.h"
+  export *
+}
+module IvarInImplementation {
+  header "IvarInImplementation.h"
+  export *
+}
+
+
+//--- test-mismatch-in-extension.m
+// Different ivars with the same name aren't mergeable and constitute an error.
+#import 
+@interface ObjCInterface() {
+  float ivarName; // expected-note {{previous definition is here}}
+}
+@end
+@interface ObjCInterfaceLevel2() {
+  int bitfieldIvarName: 5; // expected-note {{previous definition is here}}
+}
+@end
+#import 
+// expected-error@IvarsInExtensions.h:* {{instance variable is already declared}}
+// expected-error@IvarsInExtensions.h:* {{instance variable is already declared}}
+@implementation ObjCInterfaceLevel2
+@end
+
+
+//--- test-mismatch-in-ivars-number.m
+// Extensions with different amount of ivars aren't considered to be the same.
+#import 
+@interface ObjCInterface() {
+  int ivarName; // expected-note {{previous definition is here}}
+  float anotherIvar;
+}
+@end
+#import 
+// expected-error@IvarsInExtensions.h:* {{instance variable is already declared}}
+@implementation ObjCInterface
+@end
+
+
+//--- test-mismatch-in-methods-protocols.m
+// Extensions with different methods or protocols aren't considered to be the same.
+#import 
+@interface ObjCInterface() {
+  int methodRelatedIvar; // expec

[PATCH] D124422: [Serialization] Improve encoding of small SourceRanges.

[Sam McCall via Phabricator via cfe-commits]

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

Switch reader/writer to use sourcerange encoding for all "obvious" ranges.

Gain is now 1.75% in my test PCH.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124422

Files:
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp

Index: clang/lib/Serialization/ASTWriterStmt.cpp
===
--- clang/lib/Serialization/ASTWriterStmt.cpp
+++ clang/lib/Serialization/ASTWriterStmt.cpp
@@ -62,8 +62,7 @@
 void ASTStmtWriter::AddTemplateKWAndArgsInfo(
 const ASTTemplateKWAndArgsInfo &ArgInfo, const TemplateArgumentLoc *Args) {
   Record.AddSourceLocation(ArgInfo.TemplateKWLoc);
-  Record.AddSourceLocation(ArgInfo.LAngleLoc);
-  Record.AddSourceLocation(ArgInfo.RAngleLoc);
+  Record.AddSourceRange({ArgInfo.LAngleLoc, ArgInfo.RAngleLoc});
   for (unsigned i = 0; i != ArgInfo.NumTemplateArgs; ++i)
 Record.AddTemplateArgumentLoc(Args[i]);
 }
@@ -83,8 +82,7 @@
   Record.push_back(S->size());
   for (auto *CS : S->body())
 Record.AddStmt(CS);
-  Record.AddSourceLocation(S->getLBracLoc());
-  Record.AddSourceLocation(S->getRBracLoc());
+  Record.AddSourceRange({S->getLBracLoc(), S->getRBracLoc()});
   Code = serialization::STMT_COMPOUND;
 }
 
@@ -152,8 +150,7 @@
 Record.AddStmt(S->getInit());
 
   Record.AddSourceLocation(S->getIfLoc());
-  Record.AddSourceLocation(S->getLParenLoc());
-  Record.AddSourceLocation(S->getRParenLoc());
+  Record.AddSourceRange({S->getLParenLoc(), S->getRParenLoc()});
   if (HasElse)
 Record.AddSourceLocation(S->getElseLoc());
 
@@ -177,8 +174,7 @@
 Record.AddDeclRef(S->getConditionVariable());
 
   Record.AddSourceLocation(S->getSwitchLoc());
-  Record.AddSourceLocation(S->getLParenLoc());
-  Record.AddSourceLocation(S->getRParenLoc());
+  Record.AddSourceRange({S->getLParenLoc(), S->getRParenLoc()});
 
   for (SwitchCase *SC = S->getSwitchCaseList(); SC;
SC = SC->getNextSwitchCase())
@@ -198,8 +194,7 @@
 Record.AddDeclRef(S->getConditionVariable());
 
   Record.AddSourceLocation(S->getWhileLoc());
-  Record.AddSourceLocation(S->getLParenLoc());
-  Record.AddSourceLocation(S->getRParenLoc());
+  Record.AddSourceRange({S->getLParenLoc(), S->getRParenLoc()});
   Code = serialization::STMT_WHILE;
 }
 
@@ -221,8 +216,7 @@
   Record.AddStmt(S->getInc());
   Record.AddStmt(S->getBody());
   Record.AddSourceLocation(S->getForLoc());
-  Record.AddSourceLocation(S->getLParenLoc());
-  Record.AddSourceLocation(S->getRParenLoc());
+  Record.AddSourceRange({S->getLParenLoc(), S->getRParenLoc()});
   Code = serialization::STMT_FOR;
 }
 
@@ -270,8 +264,7 @@
 
 void ASTStmtWriter::VisitDeclStmt(DeclStmt *S) {
   VisitStmt(S);
-  Record.AddSourceLocation(S->getBeginLoc());
-  Record.AddSourceLocation(S->getEndLoc());
+  Record.AddSourceRange({S->getBeginLoc(), S->getEndLoc()});
   DeclGroupRef DG = S->getDeclGroup();
   for (DeclGroupRef::iterator D = DG.begin(), DEnd = DG.end(); D != DEnd; ++D)
 Record.AddDeclRef(*D);
@@ -579,8 +572,7 @@
   VisitExpr(E);
 
   Record.AddSourceLocation(E->getLocation());
-  Record.AddSourceLocation(E->getLParenLocation());
-  Record.AddSourceLocation(E->getRParenLocation());
+  Record.AddSourceRange({E->getLParenLocation(), E->getRParenLocation()});
   Record.AddTypeSourceInfo(E->getTypeSourceInfo());
 
   Code = serialization::EXPR_SYCL_UNIQUE_STABLE_NAME;
@@ -708,8 +700,7 @@
 
 void ASTStmtWriter::VisitParenExpr(ParenExpr *E) {
   VisitExpr(E);
-  Record.AddSourceLocation(E->getLParen());
-  Record.AddSourceLocation(E->getRParen());
+  Record.AddSourceRange({E->getLParen(), E->getRParen()});
   Record.AddStmt(E->getSubExpr());
   Code = serialization::EXPR_PAREN;
 }
@@ -719,8 +710,7 @@
   Record.push_back(E->getNumExprs());
   for (auto *SubStmt : E->exprs())
 Record.AddStmt(SubStmt);
-  Record.AddSourceLocation(E->getLParenLoc());
-  Record.AddSourceLocation(E->getRParenLoc());
+  Record.AddSourceRange({E->getLParenLoc(), E->getRParenLoc()});
   Code = serialization::EXPR_PAREN_LIST;
 }
 
@@ -749,8 +739,7 @@
   for (unsigned I = 0, N = E->getNumComponents(); I != N; ++I) {
 const OffsetOfNode &ON = E->getComponent(I);
 Record.push_back(ON.getKind()); // FIXME: Stable encoding
-Record.AddSourceLocation(ON.getSourceRange().getBegin());
-Record.AddSourceLocation(ON.getSourceRange().getEnd());
+Record.AddSourceRange(ON.getSourceRange());
 switch (ON.getKind()) {
 case OffsetOfNode::Array:
   Record.push_back(ON.getArrayExprIndex());
@@ -825,8 +814,7 @@
 Record.AddStmt(Dim);
   for (SourceRange SR : E->getBracketsRanges())
 Record.AddSourceRange(SR);
-  Record.AddSourceLocation(E->get

[PATCH] D124093: [PowerPC] Fixing implicit castings in altivec for -fno-lax-vector-conversions

[Maryam Moghadas via Phabricator via cfe-commits]

maryammo updated this revision to Diff 425086.
maryammo added a comment.

[PowerPC] Address the review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124093

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Headers/altivec.h

Index: clang/lib/Headers/altivec.h
===
--- clang/lib/Headers/altivec.h
+++ clang/lib/Headers/altivec.h
@@ -311,7 +311,7 @@
 
 static __inline__ vector unsigned char __attribute__((__always_inline__))
 vec_add_u128(vector unsigned char __a, vector unsigned char __b) {
-  return __builtin_altivec_vadduqm(__a, __b);
+  return (vector unsigned char)__builtin_altivec_vadduqm(__a, __b);
 }
 #elif defined(__VSX__)
 static __inline__ vector signed long long __ATTRS_o_ai
@@ -325,9 +325,9 @@
   (vector unsigned int)__a + (vector unsigned int)__b;
   vector unsigned int __carry = __builtin_altivec_vaddcuw(
   (vector unsigned int)__a, (vector unsigned int)__b);
-  __carry = __builtin_shufflevector((vector unsigned char)__carry,
-(vector unsigned char)__carry, 0, 0, 0, 7,
-0, 0, 0, 0, 0, 0, 0, 15, 0, 0, 0, 0);
+  __carry = (vector unsigned int)__builtin_shufflevector(
+  (vector unsigned char)__carry, (vector unsigned char)__carry, 0, 0, 0, 7,
+  0, 0, 0, 0, 0, 0, 0, 15, 0, 0, 0, 0);
   return (vector signed long long)(__res + __carry);
 #endif
 }
@@ -358,7 +358,9 @@
 static __inline__ vector signed __int128 __ATTRS_o_ai
 vec_adde(vector signed __int128 __a, vector signed __int128 __b,
  vector signed __int128 __c) {
-  return __builtin_altivec_vaddeuqm(__a, __b, __c);
+  return (vector signed __int128)__builtin_altivec_vaddeuqm(
+  (vector unsigned __int128)__a, (vector unsigned __int128)__b,
+  (vector unsigned __int128)__c);
 }
 
 static __inline__ vector unsigned __int128 __ATTRS_o_ai
@@ -371,7 +373,9 @@
 static __inline__ vector unsigned char __attribute__((__always_inline__))
 vec_adde_u128(vector unsigned char __a, vector unsigned char __b,
   vector unsigned char __c) {
-  return (vector unsigned char)__builtin_altivec_vaddeuqm(__a, __b, __c);
+  return (vector unsigned char)__builtin_altivec_vaddeuqm_c(
+  (vector unsigned char)__a, (vector unsigned char)__b,
+  (vector unsigned char)__c);
 }
 #endif
 
@@ -398,7 +402,9 @@
 static __inline__ vector signed __int128 __ATTRS_o_ai
 vec_addec(vector signed __int128 __a, vector signed __int128 __b,
   vector signed __int128 __c) {
-  return __builtin_altivec_vaddecuq(__a, __b, __c);
+  return (vector signed __int128)__builtin_altivec_vaddecuq(
+  (vector unsigned __int128)__a, (vector unsigned __int128)__b,
+  (vector unsigned __int128)__c);
 }
 
 static __inline__ vector unsigned __int128 __ATTRS_o_ai
@@ -411,7 +417,9 @@
 static __inline__ vector unsigned char __attribute__((__always_inline__))
 vec_addec_u128(vector unsigned char __a, vector unsigned char __b,
vector unsigned char __c) {
-  return (vector unsigned char)__builtin_altivec_vaddecuq(__a, __b, __c);
+  return (vector unsigned char)__builtin_altivec_vaddecuq_c(
+  (vector unsigned char)__a, (vector unsigned char)__b,
+  (vector unsigned char)__c);
 }
 
 #ifdef __powerpc64__
@@ -600,7 +608,8 @@
 
 static __inline__ vector unsigned char __attribute__((__always_inline__))
 vec_addc_u128(vector unsigned char __a, vector unsigned char __b) {
-  return (vector unsigned char)__builtin_altivec_vaddcuq(__a, __b);
+  return (vector unsigned char)__builtin_altivec_vaddcuq_c(
+  (vector unsigned char)__a, (vector unsigned char)__b);
 }
 #endif // defined(__POWER8_VECTOR__) && defined(__powerpc64__)
 
@@ -824,7 +833,9 @@
 static __inline__ vector signed __int128 __ATTRS_o_ai
 vec_vaddeuqm(vector signed __int128 __a, vector signed __int128 __b,
  vector signed __int128 __c) {
-  return __builtin_altivec_vaddeuqm(__a, __b, __c);
+  return (vector signed __int128)__builtin_altivec_vaddeuqm(
+  (vector unsigned __int128)__a, (vector unsigned __int128)__b,
+  (vector unsigned __int128)__c);
 }
 
 static __inline__ vector unsigned __int128 __ATTRS_o_ai
@@ -837,7 +848,8 @@
 
 static __inline__ vector signed __int128 __ATTRS_o_ai
 vec_vaddcuq(vector signed __int128 __a, vector signed __int128 __b) {
-  return __builtin_altivec_vaddcuq(__a, __b);
+  return (vector signed __int128)__builtin_altivec_vaddcuq(
+  (vector unsigned __int128)__a, (vector unsigned __int128)__b);
 }
 
 static __inline__ vector unsigned __int128 __ATTRS_o_ai
@@ -850,7 +862,9 @@
 static __inline__ vector signed __int128 __ATTRS_o_ai
 vec_vaddecuq(vector signed __int128 __a, vector signed __int128 __b,
  vector signed __int128 __c) {
-  return __builtin_altivec_vaddecuq(__a, __b, __c);
+  return (vector signed __int128)__builti

[clang] 8e4cd72 - [CMake] Update cache file for Win to ARM Linux cross toolchain builders. NFC.

[Vladimir Vereschaka via cfe-commits]

Author: Vladimir Vereschaka
Date: 2022-04-25T17:44:35-07:00
New Revision: 8e4cd7295cb56c2baa6fbed1b739ed974738c307

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

LOG: [CMake] Update cache file for Win to ARM Linux cross toolchain builders. 
NFC.

Use default test configuration file for the libunwind tests.

Added: 


Modified: 
clang/cmake/caches/CrossWinToARMLinux.cmake

Removed: 




diff  --git a/clang/cmake/caches/CrossWinToARMLinux.cmake 
b/clang/cmake/caches/CrossWinToARMLinux.cmake
index 525432f9c861a..90af9d964345e 100644
--- a/clang/cmake/caches/CrossWinToARMLinux.cmake
+++ b/clang/cmake/caches/CrossWinToARMLinux.cmake
@@ -176,10 +176,6 @@ if(DEFINED REMOTE_TEST_HOST)
   set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBUNWIND_TARGET_INFO
   "${DEFAULT_TEST_TARGET_INFO}" CACHE STRING "")
   set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBUNWIND_EXECUTOR   
   "${DEFAULT_TEST_EXECUTOR}" CACHE STRING "")
 
-  #NOTE: temporary workaround to fix the remote execution for libunwind tests.
-  # https://reviews.llvm.org/D112082
-  set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBUNWIND_TEST_CONFIG
   "${LLVM_PROJECT_DIR}/libunwind/test/lit.site.cfg.in" CACHE PATH "")
-
   set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBCXXABI_TARGET_INFO
   "${DEFAULT_TEST_TARGET_INFO}" CACHE STRING "")
   set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBCXXABI_EXECUTOR   
   "${DEFAULT_TEST_EXECUTOR}" CACHE STRING "")
   set(RUNTIMES_${TOOLCHAIN_TARGET_TRIPLE}_LIBCXX_TARGET_INFO   
   "${DEFAULT_TEST_TARGET_INFO}" CACHE STRING "")



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

[libunwind] db92019 - [libunwind] Update the test configuration files to support the remote execution.

[Vladimir Vereschaka via cfe-commits]

Author: Vladimir Vereschaka
Date: 2022-04-25T17:33:03-07:00
New Revision: db92019ab97b9bb13a3287438c4a2fa3ba375756

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

LOG: [libunwind] Update the test configuration files to support the remote 
execution.

These changes allow remote execution for the libunwind library tests.

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

Added: 


Modified: 
libunwind/test/configs/llvm-libunwind-shared.cfg.in
libunwind/test/configs/llvm-libunwind-static.cfg.in

Removed: 




diff  --git a/libunwind/test/configs/llvm-libunwind-shared.cfg.in 
b/libunwind/test/configs/llvm-libunwind-shared.cfg.in
index 9de82e9d20fbc..c0a3e4d922be7 100644
--- a/libunwind/test/configs/llvm-libunwind-shared.cfg.in
+++ b/libunwind/test/configs/llvm-libunwind-shared.cfg.in
@@ -20,6 +20,7 @@ config.test_source_root = 
os.path.join('@LIBUNWIND_SOURCE_DIR@', 'test')
 config.test_format = libcxx.test.format.CxxStandardLibraryTest()
 config.recursiveExpansionLimit = 10
 config.test_exec_root = '@CMAKE_BINARY_DIR@'
+config.target_info = "@LIBUNWIND_TARGET_INFO@"
 
 compile_flags = []
 link_flags = []
@@ -39,9 +40,12 @@ if '@CMAKE_SYSTEM_NAME@' == 'Linux':
 # Stack unwinding tests need unwinding tables and these are not generated by 
default on all targets.
 compile_flags.append('-funwind-tables')
 
+config.substitutions.append(('%{executor}', '@LIBUNWIND_EXECUTOR@'))
+
 config.substitutions.append(('%{cxx}', '@CMAKE_CXX_COMPILER@'))
+local_sysroot = '@CMAKE_OSX_SYSROOT@' or '@CMAKE_SYSROOT@'
 config.substitutions.append(('%{flags}',
-'-isysroot {}'.format('@CMAKE_OSX_SYSROOT@') if '@CMAKE_OSX_SYSROOT@' else 
''
+'-isysroot {}'.format(local_sysroot) if local_sysroot else ''
 ))
 config.substitutions.append(('%{compile_flags}',
 '-nostdinc++ -I {}/include {}'.format('@LIBUNWIND_SOURCE_DIR@', ' 
'.join(compile_flags))
@@ -49,7 +53,9 @@ config.substitutions.append(('%{compile_flags}',
 config.substitutions.append(('%{link_flags}',
 '-L {0} -Wl,-rpath,{0} -lunwind -ldl 
{1}'.format('@LIBUNWIND_LIBRARY_DIR@', ' '.join(link_flags))
 ))
-config.substitutions.append(('%{exec}', ''))
+config.substitutions.append(('%{exec}',
+'%{executor} --execdir %T -- ' if '@LIBUNWIND_EXECUTOR@' else ''
+))
 
 import os, site
 site.addsitedir(os.path.join('@LIBUNWIND_LIBCXX_PATH@', 'utils'))

diff  --git a/libunwind/test/configs/llvm-libunwind-static.cfg.in 
b/libunwind/test/configs/llvm-libunwind-static.cfg.in
index 9382ad3f92a36..0bb4207307177 100644
--- a/libunwind/test/configs/llvm-libunwind-static.cfg.in
+++ b/libunwind/test/configs/llvm-libunwind-static.cfg.in
@@ -20,9 +20,11 @@ config.test_source_root = 
os.path.join('@LIBUNWIND_SOURCE_DIR@', 'test')
 config.test_format = libcxx.test.format.CxxStandardLibraryTest()
 config.recursiveExpansionLimit = 10
 config.test_exec_root = '@CMAKE_BINARY_DIR@'
+config.target_info = "@LIBUNWIND_TARGET_INFO@"
 
 compile_flags = []
 link_flags = []
+
 if @LIBUNWIND_USES_ARM_EHABI@:
 config.available_features.add('libunwind-arm-ehabi')
 
@@ -38,12 +40,17 @@ if @LIBUNWIND_ENABLE_CET@:
 if '@CMAKE_SYSTEM_NAME@' == 'Linux':
 link_flags.append('-Wl,--export-dynamic')
 
+
 # Stack unwinding tests need unwinding tables and these are not generated by 
default on all targets.
 compile_flags.append('-funwind-tables')
 
+config.substitutions.append(('%{executor}', '@LIBUNWIND_EXECUTOR@'))
+
 config.substitutions.append(('%{cxx}', '@CMAKE_CXX_COMPILER@'))
+
+local_sysroot = '@CMAKE_OSX_SYSROOT@' or '@CMAKE_SYSROOT@'
 config.substitutions.append(('%{flags}',
-'-isysroot {}'.format('@CMAKE_OSX_SYSROOT@') if '@CMAKE_OSX_SYSROOT@' else 
''
+'-isysroot {}'.format(local_sysroot) if local_sysroot else ''
 ))
 config.substitutions.append(('%{compile_flags}',
 '-nostdinc++ -I {}/include {}'.format('@LIBUNWIND_SOURCE_DIR@', ' 
'.join(compile_flags))
@@ -51,7 +58,9 @@ config.substitutions.append(('%{compile_flags}',
 config.substitutions.append(('%{link_flags}',
 '{}/libunwind.a -ldl {}'.format('@LIBUNWIND_LIBRARY_DIR@', ' 
'.join(link_flags))
 ))
-config.substitutions.append(('%{exec}', ''))
+config.substitutions.append(('%{exec}',
+'%{executor} --execdir %T -- ' if '@LIBUNWIND_EXECUTOR@' else ''
+))
 
 import os, site
 site.addsitedir(os.path.join('@LIBUNWIND_LIBCXX_PATH@', 'utils'))



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

[PATCH] D123831: [POC][WIP] Use relative include in extract-api

[Zixu Wang via Phabricator via cfe-commits]

zixuw updated this revision to Diff 425083.
zixuw added a comment.

- Rewrite commit message for preparation
- Remove shortening paths based on the current working directory: it does not 
work with angled includes, and unnecessary for our use
- XFAIL test known_files_only_hmap.c, as it is not a valid setup with a 
questionable headermap. Need to determine how to fix that test case or just 
discard it, as the new relative_include.m test also checks that symbols from 
external files are dropped


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123831

Files:
  clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
  clang/test/ExtractAPI/known_files_only_hmap.c
  clang/test/ExtractAPI/relative_include.m

Index: clang/test/ExtractAPI/relative_include.m
===
--- /dev/null
+++ clang/test/ExtractAPI/relative_include.m
@@ -0,0 +1,130 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+
+// Setup framework root
+// RUN: mkdir -p %t/Frameworks/MyFramework.framework/Headers
+// RUN: cp %t/MyFramework.h %t/Frameworks/MyFramework.framework/Headers/
+// RUN: cp %t/MyHeader.h %t/Frameworks/MyFramework.framework/Headers/
+
+// RUN: sed -e "s@SRCROOT@%{/t:regex_replacement}@g" \
+// RUN: %t/reference.output.json.in >> %t/reference.output.json
+
+// Headermap maps headers to the source root SRCROOT
+// RUN: sed -e "s@SRCROOT@%{/t:regex_replacement}@g" \
+// RUN: %t/headermap.hmap.json.in >> %t/headermap.hmap.json
+// RUN: %hmaptool write %t/headermap.hmap.json %t/headermap.hmap
+
+// Input headers use paths to the framework root/DSTROOT
+// RUN: %clang -extract-api --product-name=MyFramework -target arm64-apple-macosx \
+// RUN: -I%t/headermap.hmap -F%t/Frameworks \
+// RUN: %t/Frameworks/MyFramework.framework/Headers/MyFramework.h \
+// RUN: %t/Frameworks/MyFramework.framework/Headers/MyHeader.h \
+// RUN: -o %t/output.json | FileCheck -allow-empty %s
+
+// Generator version is not consistent across test runs, normalize it.
+// RUN: sed -e "s@\"generator\": \".*\"@\"generator\": \"?\"@g" \
+// RUN: %t/output.json >> %t/output-normalized.json
+// RUN: diff %t/reference.output.json %t/output-normalized.json
+
+// CHECK-NOT: error:
+// CHECK-NOT: warning:
+
+//--- headermap.hmap.json.in
+{
+  "mappings" :
+{
+ "MyFramework/MyHeader.h" : "SRCROOT/MyHeader.h"
+}
+}
+
+//--- MyFramework.h
+// Umbrella for MyFramework
+#import 
+
+//--- MyHeader.h
+#import 
+int MyInt;
+
+//--- Frameworks/OtherFramework.framework/Headers/OtherHeader.h
+int OtherInt;
+
+//--- reference.output.json.in
+{
+  "metadata": {
+"formatVersion": {
+  "major": 0,
+  "minor": 5,
+  "patch": 3
+},
+"generator": "?"
+  },
+  "module": {
+"name": "MyFramework",
+"platform": {
+  "architecture": "arm64",
+  "operatingSystem": {
+"minimumVersion": {
+  "major": 11,
+  "minor": 0,
+  "patch": 0
+},
+"name": "macosx"
+  },
+  "vendor": "apple"
+}
+  },
+  "relationships": [],
+  "symbols": [
+{
+  "accessLevel": "public",
+  "declarationFragments": [
+{
+  "kind": "typeIdentifier",
+  "preciseIdentifier": "c:I",
+  "spelling": "int"
+},
+{
+  "kind": "text",
+  "spelling": " "
+},
+{
+  "kind": "identifier",
+  "spelling": "MyInt"
+}
+  ],
+  "identifier": {
+"interfaceLanguage": "c",
+"precise": "c:@MyInt"
+  },
+  "kind": {
+"displayName": "Global Variable",
+"identifier": "c.var"
+  },
+  "location": {
+"position": {
+  "character": 5,
+  "line": 2
+},
+"uri": "file://SRCROOT/MyHeader.h"
+  },
+  "names": {
+"navigator": [
+  {
+"kind": "identifier",
+"spelling": "MyInt"
+  }
+],
+"subHeading": [
+  {
+"kind": "identifier",
+"spelling": "MyInt"
+  }
+],
+"title": "MyInt"
+  },
+  "pathComponents": [
+"MyInt"
+  ]
+}
+  ]
+}
Index: clang/test/ExtractAPI/known_files_only_hmap.c
===
--- clang/test/ExtractAPI/known_files_only_hmap.c
+++ clang/test/ExtractAPI/known_files_only_hmap.c
@@ -1,3 +1,4 @@
+// XFAIL: *
 // RUN: rm -rf %t
 // RUN: split-file %s %t
 // RUN: sed -e "s@INPUT_DIR@%{/t:regex_replacement}@g" \
Index: clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
===
--- clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
+++ clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
@@ -38,7 +38,10 @@
 #include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallVector.h"
+#include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Memo

[PATCH] D123831: [POC][WIP] Use relative include in extract-api

[Zixu Wang via Phabricator via cfe-commits]

zixuw added inline comments.



Comment at: clang/lib/ExtractAPI/ExtractAPIConsumer.cpp:134
+if (!SpelledFilename.empty())
+  return SpelledFilename.str();
+

zixuw wrote:
> zixuw wrote:
> > One problem I can see in this right now is that there might be multiple 
> > headermaps that together construct a chain of mapping, for example
> > ```
> > // A.hmap
> > Header.h -> Product/Header.h
> > 
> > // B.hmap
> > Product/Header.h -> /Absolute/path/to/Header.h
> > ```
> > Then this iteration would conclude on using `Product/Header.h` and missed 
> > the first mapping (if the command line goes `clang -extract-api -I A.hmap 
> > -I B.hmap ...`).
> > 
> > It's also possible that a headermap and a search path together resolve the 
> > header. For example:
> > ```
> > //A.hmap
> > Header.h -> Product/Header.h
> > 
> > // Invocation:
> > clang -extract-api /Some/Path/to/Product/Header.h -I A.hmap -I 
> > /Some/path/to/
> > ```
> > 
> > I think we need to keep records and iterate backwards on the search paths 
> > again to get the full reverse lookup
> Or, iterate once in reverse and find the last match? 🤔 
Another thing just came to me: with multiple headermaps chaining remaps, which 
is the "correct" way to include a header?
```
// A.hmap
Header.h -> Product/Header.h

// B.hmap
Product/Header.h -> /Absolute/path/to/Header.h
```
In the context of Darwin frameworks, we'd use `` so we 
don't want to follow the chain all the way backwards.
But without any context or build system rationales of why multiple headermaps 
with remap chains are generated in the first place, I'm feeling that we don't 
nearly have enough information for this if we're only talking about headermap 
as it is and refraining from adopting heuristics.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123831

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

[PATCH] D124422: [Serialization] Improve encoding of small SourceRanges.

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

Bad news: this isn't ready, there are places where ASTWriter calls 
AddSourceLocation() twice and ASTReader calls ReadSourceRange().
After this change, those are no longer compatible so we have to make them 
match, and have to audit them all.

Good news, there's a bunch of potential places where we can replace 
AddSourceLocation() pairs with AddSourceRange for further savings.
Maybe even replacing other "chains" of source locations with delta-encoding, 
though I might be getting carried away...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124422

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

[PATCH] D116203: [clang] adds unary type transformations as compiler built-ins

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added inline comments.



Comment at: clang/include/clang/AST/TransformTypeTraits.def:27
+TRANSFORM_TYPE_TRAIT_DEF(RemoveVolatile, remove_volatile)
+TRANSFORM_TYPE_TRAIT_DEF(EnumUnderlyingType, underlying_type)

This file should undef the `TRANSFORM_TYPE_TRAIT_DEF` macro at the end, like 
our other `.def` files do. Then you can remove all of the `#undef`s elsewhere 
in this patch.



Comment at: clang/include/clang/AST/Type.h:4567-4582
+EnumUnderlyingType,
+AddLvalueReference,
+AddPointer,
+AddRvalueReference,
+Decay,
+MakeSigned,
+MakeUnsigned,

Consider using the `.def` file here.



Comment at: clang/include/clang/AST/Type.h:6528
+  (void)IsCPlusPlus;
+  assert(IsCPlusPlus && "Referenceable types only make sense in C++");
+  const Type &Self = **this;

I think the existence of the `IsCPlusPlus` flag may have the opposite effect of 
the one that's intended:

* Without this flag, looking only at the declaration of this function, I would 
assume you're not supposed to call this function except in C++ mode.
* With this flag, looking only at the declaration of this function, I would 
assume that passing in `IsCPlusPlus = false` would cause the function to always 
return `false` (because there are no reference types).

It might be better to define "referenceable" as "function type with no 
ref-qualifier nor cv-qualifier, object type, or reference type", and just 
accept calls to `isReferenceable` across all language modes.



Comment at: clang/include/clang/AST/Type.h:6532-6537
+  if (!Self.isFunctionType())
+return false;
+
+  const auto *F = Self.getAs();
+  assert(F != nullptr);
+  return F->getMethodQuals().empty() && F->getRefQualifier() == RQ_None;

It's better not to test whether the type is a function type (walking past sugar 
etc) more than once.



Comment at: clang/include/clang/Sema/DeclSpec.h:340
   /*TSS*/unsigned TypeSpecSign : 2;
-  /*TST*/unsigned TypeSpecType : 6;
+  /*TST*/ unsigned TypeSpecType : 7;
   unsigned TypeAltiVecVector : 1;

Please keep the formatting consistent here, even if you need to override 
clang-format.



Comment at: clang/include/clang/Sema/DeclSpec.h:407
   static bool isTypeRep(TST T) {
-return (T == TST_typename || T == TST_typeofType ||
-T == TST_underlyingType || T == TST_atomic);
+static const llvm::SmallVector validTSTs = {
+TST_atomic,

aaron.ballman wrote:
> Should we find a way we can drop the `19` here so that this doesn't become 
> incorrect when someone adds anything to `TransformTypeTraits.def`?
It'd be nice to just compare `T` against the least and greatest trait value -- 
this linear scan seems more expensive than we might want. (And sure, we don't 
care about efficiency given that this function is only used by asserts, but I 
don't think we should assume it'll remain that way.)

Eg, something like:

```
constexpr TST Traits[] = {
#define TRANSFORM_TYPE_TRAIT_DEF(_, Trait) TST_##Trait,
#include "clang/AST/TransformTypeTraits.def"
#undef TRANSFORM_TYPE_TRAIT_DEF
};
static_assert(std::is_sorted(std::begin(Traits), std::end(Traits)));
return T == TST_atomic || T == TST_typename || T == TST_typeofType || (T >= 
Traits[0] && T <= std::end(Traits)[-1]);
```



Comment at: clang/lib/AST/ItaniumMangle.cpp:3962
   if (T->isDependentType()) {
-Out << 'U';
+Out << "Uu";
 

This should just be `u`, not `Uu`.



Comment at: clang/lib/AST/ItaniumMangle.cpp:3976
 
   mangleType(T->getBaseType());
 }

You're missing the `I`...`E` around this argument.



Comment at: clang/lib/Parse/ParseDecl.cpp:3419-3422
 case tok::kw___super:
 case tok::kw_decltype:
 case tok::identifier: {
+ParseIdentifier:

Our normal convention is to put the `{` after the last label in a sequence of 
labels.



Comment at: clang/lib/Parse/ParseDecl.cpp:4155
+#undef TRANSFORM_TYPE_TRAIT_DEF
+  if (!ParseTypeTransformTypeSpecifier(DS))
+goto ParseIdentifier;

The name signature you're using for this function is inconsistent with the 
conventions in the rest of the parser: when a `Parser::Parse...` function with 
a `bool` return type returns `true`, it means "I have failed and issued a 
diagnostic". For "parse this if possible and return whether you did", we 
usually use `Parser::MaybeParse...` (eg, `MaybeParseAttributes`).

Alternatively you could do the one-token lookahead here. If the `setKind` call 
is here, it'll be a lot clearer why it makes sense to `goto ParseIdentifier;`.

Also, for workarounds for a standard library issue, we normally include a `// 
HACK:` comment explaining what we're doing and why.



Comment at: clang/lib/Parse/ParseExpr.cpp:1041-1044
   cas

[PATCH] D123319: Change how we handle auto return types for lambda operator() to be consistent with gcc

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

('scuse the delay)

Baseline: I'm still not really sure this is the right direction. Is there a 
sound argument for why this change is suitable for lambdas, but not for other 
types? I believe all the situations that can happen with other types can happen 
with lambdas (& the other way around) with sufficiently interestingly crafted 
inputs.

In D123319#3439146 , @probinson wrote:

> In D123319#3437250 , @dblaikie 
> wrote:
>
>> (@probinson as someone I've disagreed with about this before)
>>
>> Personally I think there's limited value in expressing 'auto' in DWARF at 
>> all - we could omit function declarations if the return type is not known 
>> (undeduced auto) and wouldn't lose much - basically treating them the same 
>> as templates that aren't instantiated yet.
>
> The problem there is that then the CU where the function is defined is the 
> only one where the type description would include that function; and if we 
> are doing e.g. ctor homing, and that CU doesn't happen to construct any 
> instances, then the function will still exist but not be described anywhere.

Type homing in the non-homed CUs works more like how your private Sony 
minimizing feature works - the member functions are included in those 
translation units where they're defined (eg: if you have a type homed in one 
CU, but a member function template instantiated in another - you get a 
declaration of the type with a member function declared over in that second CU) 
- so it is described.

> If you're not doing ctor homing, then only one CU's description will mention 
> the auto function; so, whether the debugger knows about the auto function 
> will randomly depend on which CU's description the debugger decided to keep.

True - though in CUs without the definition of the function instantiated - it's 
of limited value to know the function exists. Unlike an uninstantiated member 
function template (which we just can't adequately describe in DWARF), at least 
knowing the auto-returning function exists, what it's name is, and what its 
parameters are - would allow a consumer to include it when performing overload 
resolution. But once resolved, the consumer couldn't produce a call to the 
function - without knowing the return type you couldn't implement the necessary 
calling convention (eg: it could depend on whether the type is non-trivially 
copyable, which you couldn't know).

> I do understand the analogy to templates.  The difference I see is that DWARF 
> actually has a way to describe auto function declarations, where it does not 
> have a way to describe template declarations.

Describing a function without its return type limits the value - not zero 
value, but not hugely valuable either.

(whereas a function where you know the return type (and the parameters) you 
might be able to determine the mangled name of the function and produce a valid 
call to the function - even if the function's definition has no DWARF)

>> (& I believe Sony does this for all functions anyway - only including them 
>> when they're defined, not including an exhaustive list of member functions 
>> in class definitions)
>
> We have a private feature that (if you're not doing something like ctor 
> homing, or using type units) will suppress mention of _unused_ functions, 
> which works for us because our debugger will merge type descriptions from 
> different units.  Most debuggers don't do that, generally keeping just 
> whichever one they found first, and assuming the rest are duplicates.  
> Including auto functions only when defined means the various descriptions 
> aren't actually duplicates, and so the debugger will randomly know or not 
> know about the function depending on which description it picks.
>
> It's true that omitting auto function declarations wouldn't affect Sony 
> because we know how to merge descriptions anyway, but OTOH we never 
> upstreamed the suppress-unused-declarations feature because AFAIK no other 
> debugger understands how to handle the situation.  Deliberately introducing 
> omitted declarations seems kinda wrong.  With templates we don't have a 
> choice, but with auto functions we do.
>
> I mean, if you're willing to omit auto functions, why wouldn't you be willing 
> to omit other unused functions?  The argument that "we don't know the whole 
> type" seems a bit weak, given that DWARF gives you a way to describe what's 
> missing.

I think the major difference is a consumer can call a function if it knows the 
whole signature, it can't if it doesn't know the return value. (at least on any 
ABI I can think of - maybe there are some ABIs where not knowing the return 
type would still be viable to call)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123319

___
cfe-commits maili

[clang-tools-extra] 2d014b7 - [test][clangd] Use StringRef instead of std::string

[Vitaly Buka via cfe-commits]

Author: Vitaly Buka
Date: 2022-04-25T16:38:18-07:00
New Revision: 2d014b72ccb51de9a9627c31667a3edf8cca7616

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

LOG: [test][clangd] Use StringRef instead of std::string

runWithAST stores the first parameters as StringRef, so we can't
use temporarily std::string from parameter ID.

Added: 


Modified: 
clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp 
b/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
index 1aaac829d6285..919f69c378403 100644
--- a/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
+++ b/clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
@@ -281,22 +281,22 @@ TEST_F(TUSchedulerTests, Cancellation) {
   //R2B
   //   U3(WantDiags=Yes)
   //R3   <-- cancelled
-  std::vector DiagsSeen, ReadsSeen, ReadsCanceled;
+  std::vector DiagsSeen, ReadsSeen, ReadsCanceled;
   {
 Notification Proceed; // Ensure we schedule everything.
 TUScheduler S(CDB, optsForTest(), captureDiags());
 auto Path = testPath("foo.cpp");
 // Helper to schedule a named update and return a function to cancel it.
-auto Update = [&](std::string ID) -> Canceler {
+auto Update = [&](StringRef ID) -> Canceler {
   auto T = cancelableTask();
   WithContext C(std::move(T.first));
   updateWithDiags(
-  S, Path, "//" + ID, WantDiagnostics::Yes,
+  S, Path, ("//" + ID).str(), WantDiagnostics::Yes,
   [&, ID](std::vector Diags) { DiagsSeen.push_back(ID); });
   return std::move(T.second);
 };
 // Helper to schedule a named read and return a function to cancel it.
-auto Read = [&](std::string ID) -> Canceler {
+auto Read = [&](StringRef ID) -> Canceler {
   auto T = cancelableTask();
   WithContext C(std::move(T.first));
   S.runWithAST(ID, Path, [&, ID](llvm::Expected E) {



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

[PATCH] D124422: [Serialization] Improve encoding of small SourceRanges.

[Sam McCall via Phabricator via cfe-commits]

sammccall created this revision.
sammccall added a reviewer: ilya-biryukov.
Herald added subscribers: usaxena95, kadircet.
Herald added a project: All.
sammccall requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Instead of encoding as (start, end), encode as (start, end-start).
This is smaller in the common case when:

- we store the values as VBR
- start and end are in the same file ID and nearby

This reduces clangd/AST.cpp PCH size by ~0.75%.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D124422

Files:
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp


Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -5202,14 +5202,19 @@
   Record.push_back(Raw);
 }
 
-void ASTWriter::AddSourceLocation(SourceLocation Loc, RecordDataImpl &Record) {
+static SourceLocation::UIntTy encodeForWrite(SourceLocation Loc) {
   SourceLocation::UIntTy Raw = Loc.getRawEncoding();
-  Record.push_back((Raw << 1) | (Raw >> (8 * sizeof(Raw) - 1)));
+  return SourceLocation::UIntTy{(Raw << 1) | (Raw >> (8 * sizeof(Raw) - 1))};
+}
+
+void ASTWriter::AddSourceLocation(SourceLocation Loc, RecordDataImpl &Record) {
+  Record.push_back(encodeForWrite(Loc));
 }
 
 void ASTWriter::AddSourceRange(SourceRange Range, RecordDataImpl &Record) {
   AddSourceLocation(Range.getBegin(), Record);
-  AddSourceLocation(Range.getEnd(), Record);
+  Record.push_back(encodeForWrite(Range.getEnd()) -
+   encodeForWrite(Range.getBegin()));
 }
 
 void ASTRecordWriter::AddAPFloat(const llvm::APFloat &Value) {
Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -8992,9 +8992,12 @@
 SourceRange
 ASTReader::ReadSourceRange(ModuleFile &F, const RecordData &Record,
unsigned &Idx) {
-  SourceLocation beg = ReadSourceLocation(F, Record, Idx);
-  SourceLocation end = ReadSourceLocation(F, Record, Idx);
-  return SourceRange(beg, end);
+  SourceLocation::UIntTy Begin = Record[Idx++];
+  SourceLocation::UIntTy Delta = Record[Idx++];
+  return SourceRange(
+  TranslateSourceLocation(F, ReadUntranslatedSourceLocation(Begin)),
+  TranslateSourceLocation(F,
+  ReadUntranslatedSourceLocation(Begin + Delta)));
 }
 
 /// Read a floating-point value


Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -5202,14 +5202,19 @@
   Record.push_back(Raw);
 }
 
-void ASTWriter::AddSourceLocation(SourceLocation Loc, RecordDataImpl &Record) {
+static SourceLocation::UIntTy encodeForWrite(SourceLocation Loc) {
   SourceLocation::UIntTy Raw = Loc.getRawEncoding();
-  Record.push_back((Raw << 1) | (Raw >> (8 * sizeof(Raw) - 1)));
+  return SourceLocation::UIntTy{(Raw << 1) | (Raw >> (8 * sizeof(Raw) - 1))};
+}
+
+void ASTWriter::AddSourceLocation(SourceLocation Loc, RecordDataImpl &Record) {
+  Record.push_back(encodeForWrite(Loc));
 }
 
 void ASTWriter::AddSourceRange(SourceRange Range, RecordDataImpl &Record) {
   AddSourceLocation(Range.getBegin(), Record);
-  AddSourceLocation(Range.getEnd(), Record);
+  Record.push_back(encodeForWrite(Range.getEnd()) -
+   encodeForWrite(Range.getBegin()));
 }
 
 void ASTRecordWriter::AddAPFloat(const llvm::APFloat &Value) {
Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -8992,9 +8992,12 @@
 SourceRange
 ASTReader::ReadSourceRange(ModuleFile &F, const RecordData &Record,
unsigned &Idx) {
-  SourceLocation beg = ReadSourceLocation(F, Record, Idx);
-  SourceLocation end = ReadSourceLocation(F, Record, Idx);
-  return SourceRange(beg, end);
+  SourceLocation::UIntTy Begin = Record[Idx++];
+  SourceLocation::UIntTy Delta = Record[Idx++];
+  return SourceRange(
+  TranslateSourceLocation(F, ReadUntranslatedSourceLocation(Begin)),
+  TranslateSourceLocation(F,
+  ReadUntranslatedSourceLocation(Begin + Delta)));
 }
 
 /// Read a floating-point value
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124420: [Serialization] Compress serialized macro expansion SLocEntries

[Sam McCall via Phabricator via cfe-commits]

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

Macro expansion SLocEntries are significant to PCH size (7-10% in my tests).
These store the expansion end location as vbr8. However it's highly predictable:

- for macro arg expansion it's zero
- for object macros it equals the expansion start
- for function macros it's usually shortly after the expansion start

Instead, this change stores (bool relative, unsigned value).
If relative is true, ExpEnd is ExpBegin+value, otherwise it's just value.
We define abbreviations to cover the common cases above.

This saves ~15% of SM_SLOC_EXPANSION, which is 1-1.5% of overall PCH size.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D124420

Files:
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp

Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -1689,19 +1689,47 @@
   return Stream.EmitAbbrev(std::move(Abbrev));
 }
 
-/// Create an abbreviation for the SLocEntry that refers to a macro
-/// expansion.
-static unsigned CreateSLocExpansionAbbrev(llvm::BitstreamWriter &Stream) {
+/// We use a family of abbreviations for common cases of expansion SLocEntrys.
+static std::shared_ptr SLocExpansionAbbrevCommon() {
   using namespace llvm;
-
   auto Abbrev = std::make_shared();
   Abbrev->Add(BitCodeAbbrevOp(SM_SLOC_EXPANSION_ENTRY));
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // Offset
-  Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // Spelling location
-  Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // Start location
-  Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // End location
-  Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // Is token range
-  Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // Token length
+  Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // Spelling start
+  Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6)); // Spelling length
+  Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // Expansion start
+  Abbrev->Add(BitCodeAbbrevOp(1));   // ExpEnd is token
+  return Abbrev;
+}
+
+/// Create an abbreviation for the SLocEntry that refers to a macro
+/// argument expansion.
+static unsigned CreateSLocArgExpansionAbbrev(llvm::BitstreamWriter &Stream) {
+  using namespace llvm;
+  auto Abbrev = SLocExpansionAbbrevCommon();
+  Abbrev->Add(BitCodeAbbrevOp(0)); // ExpEnd is relative
+  Abbrev->Add(BitCodeAbbrevOp(0)); // ExpEnd
+  return Stream.EmitAbbrev(std::move(Abbrev));
+}
+
+/// Create an abbreviation for the SLocEntry that refers to a macro
+/// expansion.
+static unsigned CreateSLocObjectExpansionAbbrev(llvm::BitstreamWriter &Stream) {
+  using namespace llvm;
+  auto Abbrev = SLocExpansionAbbrevCommon();
+  Abbrev->Add(BitCodeAbbrevOp(1)); // ExpEnd is relative
+  Abbrev->Add(BitCodeAbbrevOp(0)); // ExpEnd
+  return Stream.EmitAbbrev(std::move(Abbrev));
+}
+
+/// Create an abbreviation for the SLocEntry that refers to a function-like
+/// macro expansion.
+static unsigned
+CreateSLocFunctionExpansionAbbrev(llvm::BitstreamWriter &Stream) {
+  using namespace llvm;
+  auto Abbrev = SLocExpansionAbbrevCommon();
+  Abbrev->Add(BitCodeAbbrevOp(1));   // ExpEnd is relative
+  Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 8)); // End
   return Stream.EmitAbbrev(std::move(Abbrev));
 }
 
@@ -2018,7 +2046,10 @@
   unsigned SLocBufferBlobAbbrv = CreateSLocBufferBlobAbbrev(Stream, false);
   unsigned SLocBufferBlobCompressedAbbrv =
   CreateSLocBufferBlobAbbrev(Stream, true);
-  unsigned SLocExpansionAbbrv = CreateSLocExpansionAbbrev(Stream);
+  unsigned SLocArgExpansionAbbrv = CreateSLocArgExpansionAbbrev(Stream);
+  unsigned SLocObjectExpansionAbbrv = CreateSLocObjectExpansionAbbrev(Stream);
+  unsigned SLocFunctionExpansionAbbrv =
+  CreateSLocFunctionExpansionAbbrev(Stream);
 
   // Write out the source location entry table. We skip the first
   // entry, which is always the same dummy entry.
@@ -2123,19 +2154,47 @@
   // The source location entry is a macro expansion.
   const SrcMgr::ExpansionInfo &Expansion = SLoc->getExpansion();
   AddSourceLocation(Expansion.getSpellingLoc(), Record);
-  AddSourceLocation(Expansion.getExpansionLocStart(), Record);
-  AddSourceLocation(Expansion.isMacroArgExpansion()
-? SourceLocation()
-: Expansion.getExpansionLocEnd(),
-Record);
-  Record.push_back(Expansion.isExpansionTokenRange());
-
-  // Compute the token length for this macro expansion.
+  // Compute the length for this macro expansion.
   SourceLocation::U

[PATCH] D123831: [POC][WIP] Use relative include in extract-api

[Zixu Wang via Phabricator via cfe-commits]

zixuw added inline comments.



Comment at: clang/lib/ExtractAPI/ExtractAPIConsumer.cpp:134
+if (!SpelledFilename.empty())
+  return SpelledFilename.str();
+

zixuw wrote:
> One problem I can see in this right now is that there might be multiple 
> headermaps that together construct a chain of mapping, for example
> ```
> // A.hmap
> Header.h -> Product/Header.h
> 
> // B.hmap
> Product/Header.h -> /Absolute/path/to/Header.h
> ```
> Then this iteration would conclude on using `Product/Header.h` and missed the 
> first mapping (if the command line goes `clang -extract-api -I A.hmap -I 
> B.hmap ...`).
> 
> It's also possible that a headermap and a search path together resolve the 
> header. For example:
> ```
> //A.hmap
> Header.h -> Product/Header.h
> 
> // Invocation:
> clang -extract-api /Some/Path/to/Product/Header.h -I A.hmap -I /Some/path/to/
> ```
> 
> I think we need to keep records and iterate backwards on the search paths 
> again to get the full reverse lookup
Or, iterate once in reverse and find the last match? 🤔 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123831

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

[PATCH] D123831: [POC][WIP] Use relative include in extract-api

[Zixu Wang via Phabricator via cfe-commits]

zixuw added inline comments.



Comment at: clang/lib/ExtractAPI/ExtractAPIConsumer.cpp:134
+if (!SpelledFilename.empty())
+  return SpelledFilename.str();
+

One problem I can see in this right now is that there might be multiple 
headermaps that together construct a chain of mapping, for example
```
// A.hmap
Header.h -> Product/Header.h

// B.hmap
Product/Header.h -> /Absolute/path/to/Header.h
```
Then this iteration would conclude on using `Product/Header.h` and missed the 
first mapping (if the command line goes `clang -extract-api -I A.hmap -I B.hmap 
...`).

It's also possible that a headermap and a search path together resolve the 
header. For example:
```
//A.hmap
Header.h -> Product/Header.h

// Invocation:
clang -extract-api /Some/Path/to/Product/Header.h -I A.hmap -I /Some/path/to/
```

I think we need to keep records and iterate backwards on the search paths again 
to get the full reverse lookup


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123831

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

[PATCH] D112921: [clang] Enable sized deallocation by default in C++14 onwards

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Ideally, I think, we would set this up to work something like `ObjCRuntime`, 
where we're making queries to a common place that contains all the information 
necessary to decide what runtime features are available.  In particular, we 
shouldn't treat Apple platforms as forever unique in providing a stable runtime 
interface with availability gating.

Now, we don't necessarily need the same complexity that `ObjCRuntime` supports, 
where the user can tell us to use a different runtime and runtime version from 
the default for the platform.  On the other hand, maybe we want that, because 
it's a good way to deal with the compatibility problem that we have on 
non-Apple platforms.  Users could tell us that they're targeting e.g. libsupc++ 
v4.8, and we could tell them in response that sized allocation isn't supported. 
 And if we get them to tell us that, rather than "I have sized allocation 
support" specifically, it sets us up well to solve similar problems in the 
future.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112921

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

[PATCH] D112921: [clang] Enable sized deallocation by default in C++14 onwards

[Louis Dionne via Phabricator via cfe-commits]

ldionne added a comment.

(BTW I strongly support this patch, I just think we should do it properly on 
all platforms from the start :-)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112921

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

[PATCH] D112921: [clang] Enable sized deallocation by default in C++14 onwards

[Louis Dionne via Phabricator via cfe-commits]

ldionne added a subscriber: ahatanak.
ldionne added inline comments.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:4078-4082
+  if (!Args.getLastArg(options::OPT_fsized_deallocation,
+   options::OPT_fno_sized_deallocation))
+Opts.SizedDeallocation = Opts.SizedDeallocation &&
+ T.getVendor() != llvm::Triple::VendorType::Apple;
+

Why not implement it correctly from the start? @arphaman @ahatanak What would 
be the right incantation to enable sized deallocation starting in macOS 10.12, 
iOS 10.0, watchOS 3.0, and tvOS 10.0?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112921

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

[PATCH] D124395: [clang][dataflow] Optimize flow condition representation

[Gábor Horváth via Phabricator via cfe-commits]

xazax.hun added a comment.

Nice! Did you do some measurements? Does this improve the performance or 
decrease the memory consumption?




Comment at: 
clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h:160
+  void addFlowConditionConstraint(AtomicBoolValue &Token,
+  BoolValue &Constraint);
+

Could this be const?



Comment at: 
clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h:213
+  //
+  // Flow conditions can depend on other flow conditions (constraints can refer
+  // to flow condition tokens). The graph of flow condition dependencies is

I think an example would be nice what "depending on" a flow condition means. A 
simplistic example with a nested if would probably be the easiest to understand.




Comment at: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp:184-185
+  FlowConditionToken = &DACtx->makeFlowConditionToken();
+  DACtx->addFlowConditionDependency(*FlowConditionToken,
+*Other.FlowConditionToken);
+  DACtx->addFlowConditionConstraint(*FlowConditionToken,

Do we ever expect to call these functions independently of each other? If no, 
maybe `addFlowConditionDependency` should add the constraint as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124395

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

[PATCH] D124316: [clang-tidy] Modernize-macro-to-enum should skip macros used in other macros

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood added a comment.

Gentle ping.

I have another change based on this that fixes #55055
Enhance modernize-macro-to-enum to recognize constant literal expressions 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124316

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

[PATCH] D124382: [Clang] Recognize target address space in superset calculation

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

You should be able to provide an address space of the pointer using the number, 
see details in:
https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/Builtins.def#L65

However if language address spaces are needed I wonder if the best approach is 
just to extend
the Builtin definitions with language address spaces similar to other 
qualifiers?

> This patch attempts to find a happy medium between not recognising target
>  address spaces at all (current state) and allowing all uses of it, based on
>  the assumption that users must know better. What it does not to is to
>  provide a bidirectional translation mechanism, which I'm not sure could ever
>  be done, with the current address space implementation (use of 0, the value
>  of default, etc).

Can you provide an example of where it could be useful? Note that I feel that
such functionality could be implemented on top of full implementation of
target specific address space proposed in https://reviews.llvm.org/D62574.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124382

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

[PATCH] D123831: [POC][WIP] Use relative include in extract-api

[Zixu Wang via Phabricator via cfe-commits]

zixuw updated this revision to Diff 425017.
zixuw added a comment.

- Create FileManager in PrepareToExecuteAction
- Use FileManager to load headermaps and reverse lookup mappings
- Use FileSystem to correctly get working directory and make absolute paths


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123831

Files:
  clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
  clang/test/ExtractAPI/relative_include.m

Index: clang/test/ExtractAPI/relative_include.m
===
--- /dev/null
+++ clang/test/ExtractAPI/relative_include.m
@@ -0,0 +1,130 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+
+// Setup framework root
+// RUN: mkdir -p %t/Frameworks/MyFramework.framework/Headers
+// RUN: cp %t/MyFramework.h %t/Frameworks/MyFramework.framework/Headers/
+// RUN: cp %t/MyHeader.h %t/Frameworks/MyFramework.framework/Headers/
+
+// RUN: sed -e "s@SRCROOT@%{/t:regex_replacement}@g" \
+// RUN: %t/reference.output.json.in >> %t/reference.output.json
+
+// Headermap maps headers to the source root SRCROOT
+// RUN: sed -e "s@SRCROOT@%{/t:regex_replacement}@g" \
+// RUN: %t/headermap.hmap.json.in >> %t/headermap.hmap.json
+// RUN: %hmaptool write %t/headermap.hmap.json %t/headermap.hmap
+
+// Input headers use paths to the framework root/DSTROOT
+// RUN: %clang -extract-api --product-name=MyFramework -target arm64-apple-macosx \
+// RUN: -I%t/headermap.hmap -F%t/Frameworks \
+// RUN: %t/Frameworks/MyFramework.framework/Headers/MyFramework.h \
+// RUN: %t/Frameworks/MyFramework.framework/Headers/MyHeader.h \
+// RUN: -o %t/output.json | FileCheck -allow-empty %s
+
+// Generator version is not consistent across test runs, normalize it.
+// RUN: sed -e "s@\"generator\": \".*\"@\"generator\": \"?\"@g" \
+// RUN: %t/output.json >> %t/output-normalized.json
+// RUN: diff %t/reference.output.json %t/output-normalized.json
+
+// CHECK-NOT: error:
+// CHECK-NOT: warning:
+
+//--- headermap.hmap.json.in
+{
+  "mappings" :
+{
+ "MyFramework/MyHeader.h" : "SRCROOT/MyHeader.h"
+}
+}
+
+//--- MyFramework.h
+// Umbrella for MyFramework
+#import 
+
+//--- MyHeader.h
+#import 
+int MyInt;
+
+//--- Frameworks/OtherFramework.framework/Headers/OtherHeader.h
+int OtherInt;
+
+//--- reference.output.json.in
+{
+  "metadata": {
+"formatVersion": {
+  "major": 0,
+  "minor": 5,
+  "patch": 3
+},
+"generator": "?"
+  },
+  "module": {
+"name": "MyFramework",
+"platform": {
+  "architecture": "arm64",
+  "operatingSystem": {
+"minimumVersion": {
+  "major": 11,
+  "minor": 0,
+  "patch": 0
+},
+"name": "macosx"
+  },
+  "vendor": "apple"
+}
+  },
+  "relationships": [],
+  "symbols": [
+{
+  "accessLevel": "public",
+  "declarationFragments": [
+{
+  "kind": "typeIdentifier",
+  "preciseIdentifier": "c:I",
+  "spelling": "int"
+},
+{
+  "kind": "text",
+  "spelling": " "
+},
+{
+  "kind": "identifier",
+  "spelling": "MyInt"
+}
+  ],
+  "identifier": {
+"interfaceLanguage": "c",
+"precise": "c:@MyInt"
+  },
+  "kind": {
+"displayName": "Global Variable",
+"identifier": "c.var"
+  },
+  "location": {
+"position": {
+  "character": 5,
+  "line": 2
+},
+"uri": "file://SRCROOT/MyHeader.h"
+  },
+  "names": {
+"navigator": [
+  {
+"kind": "identifier",
+"spelling": "MyInt"
+  }
+],
+"subHeading": [
+  {
+"kind": "identifier",
+"spelling": "MyInt"
+  }
+],
+"title": "MyInt"
+  },
+  "pathComponents": [
+"MyInt"
+  ]
+}
+  ]
+}
Index: clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
===
--- clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
+++ clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
@@ -38,7 +38,10 @@
 #include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallVector.h"
+#include "llvm/Support/FileSystem.h"
 #include "llvm/Support/MemoryBuffer.h"
+#include "llvm/Support/Path.h"
+#include "llvm/Support/Regex.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
 #include 
@@ -55,10 +58,128 @@
   return {};
 }
 
+Optional getRelativeIncludeName(const CompilerInstance &CI,
+ StringRef File) {
+  assert(CI.hasFileManager() &&
+ "CompilerInstance does not have a FileNamager!");
+
+  using namespace llvm::sys;
+  // Matches framework include patterns
+  const llvm::Regex Rule("/(.+)\\.framework/(.+)?Headers/(.+)");
+
+  const auto &FS = CI.getVirtualFileSystem();
+
+  SmallString<128> FilePath(File.begin(), File.end());
+

[PATCH] D124389: [clang][NFC] Inclusive language: remove use of Whitelist in clang/lib/Analysis/

[Quinn Pham via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG0386213352ec: [clang][NFC] Inclusive language: remove use of 
Whitelist in clang/lib/Analysis/ (authored by quinnp).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124389

Files:
  clang/lib/Analysis/RetainSummaryManager.cpp


Index: clang/lib/Analysis/RetainSummaryManager.cpp
===
--- clang/lib/Analysis/RetainSummaryManager.cpp
+++ clang/lib/Analysis/RetainSummaryManager.cpp
@@ -398,7 +398,7 @@
   } else if (FName.startswith("NSLog")) {
 return getDoNothingSummary();
   } else if (FName.startswith("NS") && FName.contains("Insert")) {
-// Whitelist NSXXInsertXX, for example NSMapInsertIfAbsent, since they can
+// Allowlist NSXXInsertXX, for example NSMapInsertIfAbsent, since they can
 // be deallocated by NSMapRemove. (radar://11152419)
 ScratchArgs = AF.add(ScratchArgs, 1, ArgEffect(StopTracking));
 ScratchArgs = AF.add(ScratchArgs, 2, ArgEffect(StopTracking));


Index: clang/lib/Analysis/RetainSummaryManager.cpp
===
--- clang/lib/Analysis/RetainSummaryManager.cpp
+++ clang/lib/Analysis/RetainSummaryManager.cpp
@@ -398,7 +398,7 @@
   } else if (FName.startswith("NSLog")) {
 return getDoNothingSummary();
   } else if (FName.startswith("NS") && FName.contains("Insert")) {
-// Whitelist NSXXInsertXX, for example NSMapInsertIfAbsent, since they can
+// Allowlist NSXXInsertXX, for example NSMapInsertIfAbsent, since they can
 // be deallocated by NSMapRemove. (radar://11152419)
 ScratchArgs = AF.add(ScratchArgs, 1, ArgEffect(StopTracking));
 ScratchArgs = AF.add(ScratchArgs, 2, ArgEffect(StopTracking));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 0386213 - [clang][NFC] Inclusive language: remove use of Whitelist in clang/lib/Analysis/

[Quinn Pham via cfe-commits]

Author: Quinn Pham
Date: 2022-04-25T15:26:36-05:00
New Revision: 0386213352ec42342c756099fcfc6c1165d99e08

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

LOG: [clang][NFC] Inclusive language: remove use of Whitelist in 
clang/lib/Analysis/

[NFC] As part of using inclusive language within the llvm project, this patch
rewords a comment to replace Whitelist with Allowlist in
`RetainSummaryManager.cpp`.

Reviewed By: aaron.ballman

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

Added: 


Modified: 
clang/lib/Analysis/RetainSummaryManager.cpp

Removed: 




diff  --git a/clang/lib/Analysis/RetainSummaryManager.cpp 
b/clang/lib/Analysis/RetainSummaryManager.cpp
index 836e369758d38..9098cf370d4f5 100644
--- a/clang/lib/Analysis/RetainSummaryManager.cpp
+++ b/clang/lib/Analysis/RetainSummaryManager.cpp
@@ -398,7 +398,7 @@ const RetainSummary 
*RetainSummaryManager::getSummaryForObjCOrCFObject(
   } else if (FName.startswith("NSLog")) {
 return getDoNothingSummary();
   } else if (FName.startswith("NS") && FName.contains("Insert")) {
-// Whitelist NSXXInsertXX, for example NSMapInsertIfAbsent, since they can
+// Allowlist NSXXInsertXX, for example NSMapInsertIfAbsent, since they can
 // be deallocated by NSMapRemove. (radar://11152419)
 ScratchArgs = AF.add(ScratchArgs, 1, ArgEffect(StopTracking));
 ScratchArgs = AF.add(ScratchArgs, 2, ArgEffect(StopTracking));



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

[PATCH] D124221: Add new builtin __builtin_reflect_struct.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:420
+auto *FD = IFD ? IFD->getAnonField() : dyn_cast(D);
+if (!FD || (FD->isUnnamedBitfield() || FD->isAnonymousStructOrUnion()))
+  continue;

yihanaa wrote:
> erichkeane wrote:
> > rsmith wrote:
> > > erichkeane wrote:
> > > > rsmith wrote:
> > > > > erichkeane wrote:
> > > > > > rsmith wrote:
> > > > > > > erichkeane wrote:
> > > > > > > > Losing the unnamed bitfield is unfortunate, and I the 'dump 
> > > > > > > > struct' handles.  As is losing the anonymous struct/union.
> > > > > > > > 
> > > > > > > > Also, how does this handle 'record type' members?  Does the 
> > > > > > > > user have to know the inner type already?  If they already know 
> > > > > > > > that much information about the type, they wouldn't really need 
> > > > > > > > this, right?
> > > > > > > If `__builtin_dump_struct` includes unnamed bitfields, that's a 
> > > > > > > bug in that builtin.
> > > > > > > 
> > > > > > > In general, the user function gets given the bases and members 
> > > > > > > with the right types, so they can use an overload set or a 
> > > > > > > template to dispatch based on that type. See the SemaCXX test for 
> > > > > > > a basic example of that.
> > > > > > I thought it did?  For the use case I see `__builtin_dump_struct` 
> > > > > > having, I would think printing the existence of unnamed bitfields 
> > > > > > to be quite useful.
> > > > > > 
> > > > > > 
> > > > > Why? They're not part of the value, they're just padding.
> > > > They are lexically part of the type and are part of what makes up the 
> > > > 'size' of the thing. I would expect something dumping the type to be as 
> > > > consistent lexically as possible.
> > > Looks like `__builtin_dump_struct` currently includes them *and* prints a 
> > > value (whatever garbage happens to be in those padding bits). That's 
> > > obviously a bug.
> > O.o! Yeah, printing the value is nonsense.
> I think the user should be informed somehow that there is an unnamed bitfield 
> here
It seems to me that `__builtin_dump_struct` is displaying the value of a struct 
object, not the representation of the object, and unnamed bitfields are not a 
part of the value, so should not be included. And I think it makes sense for 
that builtin to be value-oriented: someone using it presumably already knows 
whatever they want to know about the representation, to the extent that it 
matters, or can look it up; what they don't know is the information that varies 
from one instance to another. If we want a builtin that's more oriented around 
showing the struct's memory representation, I think we'd want quite a different 
output format, including offsets for fields -- and even then I don't think it 
makes sense to include unnamed bit-fields because they're not different from 
any other kind of padding in the object. If we still want to print unnamed 
bit-fields for some reason, presumably we should also print alignment and 
packing attributes and pragmas, because they too can change the padding within 
a struct.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124221

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

[PATCH] D124221: Add new builtin __builtin_reflect_struct.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D124221#3471645 , @erichkeane 
wrote:

> In D124221#3470550 , @aaron.ballman 
> wrote:
>
>> In D124221#3469251 , @rsmith wrote:
>>
>>> - Take any callable as the printing function and pass it the fields with 
>>> their correct types, so that a C++ implementation can dispatch based on the 
>>> type and print the values of types that we don't hard-code (eg, we'd 
>>> generate calls like `user_dump_function("%s = %p", "field_name", 
>>> &p->field_name);`, and a smart C++ formatting function can preserve the 
>>> field type and do something suitable when formatting a corresponding `%p`).
>>
>> +1, though I'm curious what we want to do about things like bit-fields (do 
>> we want to alert the caller that it's a bit-field and what the width is?), 
>> anonymous bit-fields, base classes vs fields of class type, etc.
>
> I suspect we'd want some sort of 'depth' parameter to that as well so we can 
> handle the 'tabbing' correctly,

I was thinking that we'd pass hard-coded `""` strings to the 
`user_dump_function` for indentation (like we do now), rather than trying to 
make it customizable, so that, in particular, you can still pass in `printf` as 
the `user_dump_function` and have it "just work".

> and am also concerned with the things Aaron brought up (particularly the 
> anonymous bit-fields/zero length bitfields), as they seem to be things that 
> make current users persnickety.

Yeah. User concerns about the output format not being what they wanted really 
reinforce for me the fundamental problems with this builtin. But we can still 
make reasonable and principled choices here (eg, show the same information that 
would be in a corresponding compound literal).

>>> - Take additional arguments to be passed onto the provided function, so 
>>> that C users can easily format to a different file or to a  string or 
>>> whatever else
>>
>> +1, that seems pretty sensible for what is effectively a callback function.
>
> I am somewhat concerned with these as they get confusing/obtuse to use 
> sometimes (particularly with variadic functions as the callback, where they 
> cause strange non-compile-time errors with minor, seemingly innocuous 
> changes), but am reasonably sure we could come up with some level of design 
> that would make it not-awful.  If this was JUST C++, I'd say "we should not, 
> and the user should use a functor/lambda for state", but, of course, this is 
> C :/

I definitely understand that concern. I think it's important to allow at least 
one parameter -- I'd be OK with saying that you can pass either the signature 
of `printf` or that signature with a leading `void*`, but I think it's nicer to 
say we'll take whatever extra arguments are given and blindly pass them onto 
the given function, so that we can directly support `fprintf` and `dprintf`. 
(You'd still need a wrapper in order to be able to call `snprintf`, though, in 
order to move the pointer forward and correspondingly decrease the remaining 
buffer length.) But as long as we provide *some* way to pass arbitrary 
information to the callback, I think that satisfies the use case.

> The BOFH-compiler-guy part of me (B-Compiler-Dev-FH ?) thinks we should start 
> randomizing the output to discourage this behavior, but I suspect that would 
> be an arms-race we would ultimately lose.

:-) I think the best thing we can do to discourage people from using this 
dumping facility for reflection is to provide builtins to implement the C++ 
reflection functionality as soon as we can after we think it's ready -- and 
ideally to make sure that those builtins support at least basic use cases in C. 
(The latter might require that we wait until C's constant evaluation 
functionality improves, but at least some in WG14 are pushing hard for that.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124221

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

[libunwind] 7164c5f - [libunwind] [CMake] Remove leftover no-op cmake variable setting. NFC.

[Martin Storsjö via cfe-commits]

Author: Martin Storsjö
Date: 2022-04-25T23:01:22+03:00
New Revision: 7164c5f051a980442f2376af4bae3740710bf347

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

LOG: [libunwind] [CMake] Remove leftover no-op cmake variable setting. NFC.

The setting and restoring of this variable became unused in
3ee0cec88effc88285732c8bec2a8f0e4e37c0b1 / D112155.

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

Added: 


Modified: 
libunwind/CMakeLists.txt

Removed: 




diff  --git a/libunwind/CMakeLists.txt b/libunwind/CMakeLists.txt
index ca6999f7d147a..6a76917ae91b9 100644
--- a/libunwind/CMakeLists.txt
+++ b/libunwind/CMakeLists.txt
@@ -180,15 +180,6 @@ include(HandleLibunwindFlags)
 # Setup Compiler Flags
 
#===
 
-# Compiler tests may be failing if the compiler implicitly links in libunwind,
-# which doesn't exist yet. This gets waived by --unwindlib=none
-# later in config-ix below, but the tests for --target etc before that may
-# be failing due to it. Only test compilation, not linking, for these
-# tests here now.
-set(CMAKE_TRY_COMPILE_TARGET_TYPE_ORIG ${CMAKE_TRY_COMPILE_TARGET_TYPE})
-set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
-set(CMAKE_TRY_COMPILE_TARGET_TYPE ${CMAKE_TRY_COMPILE_TARGET_TYPE_ORIG})
-
 # Configure compiler.
 include(config-ix)
 



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

[libunwind] c98d950 - [libunwind] Fix build warnings in Unwind-EHABI.cpp. NFC.

[Martin Storsjö via cfe-commits]

Author: Martin Storsjö
Date: 2022-04-25T23:00:52+03:00
New Revision: c98d9502fc6b10caea3cc3db94d85887c38e5892

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

LOG: [libunwind] Fix build warnings in Unwind-EHABI.cpp. NFC.

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

Added: 


Modified: 
libunwind/src/Unwind-EHABI.cpp

Removed: 




diff  --git a/libunwind/src/Unwind-EHABI.cpp b/libunwind/src/Unwind-EHABI.cpp
index 257db724c2679..6ac09adfb8fe3 100644
--- a/libunwind/src/Unwind-EHABI.cpp
+++ b/libunwind/src/Unwind-EHABI.cpp
@@ -436,6 +436,8 @@ _Unwind_VRS_Interpret(_Unwind_Context *context, const 
uint32_t *data,
   _UVRSD_UINT32, &pac);
   __asm__ __volatile__("autg %0, %1, %2" : : "r"(pac), "r"(lr), "r"(sp) :);
 }
+#else
+(void)hasReturnAddrAuthCode;
 #endif
 _Unwind_VRS_Set(context, _UVRSC_CORE, UNW_ARM_IP, _UVRSD_UINT32, &lr);
   }
@@ -1193,6 +1195,7 @@ _Unwind_DeleteException(_Unwind_Exception 
*exception_object) {
 extern "C" _LIBUNWIND_EXPORT _Unwind_Reason_Code
 __gnu_unwind_frame(_Unwind_Exception *exception_object,
struct _Unwind_Context *context) {
+  (void)exception_object;
   unw_cursor_t *cursor = (unw_cursor_t *)context;
   switch (__unw_step(cursor)) {
   case UNW_STEP_SUCCESS:



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

[PATCH] D124063: [LegacyPM] Rename and deprecate populateModulePassManager

[Nikita Popov via Phabricator via cfe-commits]

nikic added a comment.

@jberdine See 
https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm-c/Transforms/PassBuilder.h
 for C bindings for the new pass manager.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124063

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

[PATCH] D123319: Change how we handle auto return types for lambda operator() to be consistent with gcc

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/test/CodeGenCXX/no_auto_return_lambda.cpp:1
+// RUN: %clang_cc1 -emit-llvm -debug-info-kind=limited %s -o - | FileCheck %s
+

erichkeane wrote:
> So this CodeGen test without a triple is a bit troublesome.  The one we've 
> noticed that this fails on the 32 bit windows build:
> 
> ```
> FAIL: Clang :: CodeGenCXX/no_auto_return_lambda.cpp (41841 of 57667)
>  TEST 'Clang :: CodeGenCXX/no_auto_return_lambda.cpp' 
> FAILED 
> Script:
> --
> : 'RUN: at line 1';   
> d:\netbatch\build_comp02320_00\ics_top\builds\xmainoclx86win_prod\llvm\bin\clang.exe
>  -cc1 -internal-isystem 
> d:\netbatch\build_comp02320_00\ics_top\builds\xmainoclx86win_prod\llvm\lib\clang\15.0.0\include
>  -nostdsysteminc -emit-llvm -debug-info-kind=limited 
> D:\netbatch\build_comp02320_00\ics_top\llvm\clang\test\CodeGenCXX\no_auto_return_lambda.cpp
>  -o - | 
> d:\netbatch\build_comp02320_00\ics_top\builds\xmainoclx86win_prod\llvm\bin\filecheck.exe
>  
> D:\netbatch\build_comp02320_00\ics_top\llvm\clang\test\CodeGenCXX\no_auto_return_lambda.cpp
> --
> Exit Code: 1Command Output (stdout):
> --
> $ ":" "RUN: at line 1"
> $ 
> "d:\netbatch\build_comp02320_00\ics_top\builds\xmainoclx86win_prod\llvm\bin\clang.exe"
>  "-cc1" "-internal-isystem" 
> "d:\netbatch\build_comp02320_00\ics_top\builds\xmainoclx86win_prod\llvm\lib\clang\15.0.0\include"
>  "-nostdsysteminc" "-emit-llvm" "-debug-info-kind=limited" 
> "D:\netbatch\build_comp02320_00\ics_top\llvm\clang\test\CodeGenCXX\no_auto_return_lambda.cpp"
>  "-o" "-"
> $ 
> "d:\netbatch\build_comp02320_00\ics_top\builds\xmainoclx86win_prod\llvm\bin\filecheck.exe"
>  
> "D:\netbatch\build_comp02320_00\ics_top\llvm\clang\test\CodeGenCXX\no_auto_return_lambda.cpp"
> # command stderr:
> D:\netbatch\build_comp02320_00\ics_top\llvm\clang\test\CodeGenCXX\no_auto_return_lambda.cpp:24:11:
>  error: CHECK: expected string not found in input
> // CHECK: ![[FUN_TYPE_LAMBDA]] = !DISubroutineType(types: 
> ![[TYPE_NODE_LAMBDA:[0-9]+]])
>   ^
> :56:289: note: scanning from here
> !17 = distinct !DISubprogram(name: "operator()", linkageName: 
> "??R@?0??g@@YAHXZ@QBE?A?@@XZ", scope: !13, file: !7, line: 9, 
> type: !18, scopeLine: 9, flags: DIFlagPrototyped, spFlags: 
> DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, declaration: !22, 
> retainedNodes: !11)   
> ^
> :56:289: note: with "FUN_TYPE_LAMBDA" equal to "18"
> !17 = distinct !DISubprogram(name: "operator()", linkageName: 
> "??R@?0??g@@YAHXZ@QBE?A?@@XZ", scope: !13, file: !7, line: 9, 
> type: !18, scopeLine: 9, flags: DIFlagPrototyped, spFlags: 
> DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, declaration: !22, 
> retainedNodes: !11)   
> ^
> :57:1: note: possible intended match here
> !18 = !DISubroutineType(cc: DW_CC_BORLAND_thiscall, types: !19)
> ^Input file: 
> Check file: 
> D:\netbatch\build_comp02320_00\ics_top\llvm\clang\test\CodeGenCXX\no_auto_return_lambda.cpp
> -dump-input=help explains the following input dump.Input was:
> <<
> .
> .
> .
>51: !12 = !DILocalVariable(name: "f", scope: !6, file: !7, line: 
> 9, type: !13)
>52: !13 = distinct !DICompositeType(tag: DW_TAG_class_type, scope: 
> !6, file: !7, line: 9, size: 8, flags: DIFlagTypePassByValue | 
> DIFlagNonTrivial, elements: !11)
>53: !14 = !DILocation(line: 9, column: 8, scope: !6)
>54: !15 = !DILocation(line: 10, column: 10, scope: !6)
>55: !16 = !DILocation(line: 10, column: 3, scope: !6)
>56: !17 = distinct !DISubprogram(name: "operator()", linkageName: 
> "??R@?0??g@@YAHXZ@QBE?A?@@XZ", scope: !13, file: !7, line: 9, 
> type: !18, scopeLine: 9, flags: DIFlagPrototyped, spFlags: 
> DISPFlagLocalToUnit | DISPFlagDefinition, unit: !0, declaration: !22, 
> retainedNodes: !11)
> check:24'0
>   
>   
>  X error: 
> no match found
> check:24'1
>   
>   
>with 
> "FUN_TYPE_LAMBDA" equal to "18"
>57: !18 = !DISubroutineType(cc: DW_CC_BORLAND_thiscall, types: !19)
> check:24'0 
> 
> check:24'2 ?

[clang] 5c90eca - [PS5] Driver test for analyzer defaults

[Paul Robinson via cfe-commits]

Author: Paul Robinson
Date: 2022-04-25T12:42:00-07:00
New Revision: 5c90ecae2db104a816aeb33b6f773aaf782850e7

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

LOG: [PS5] Driver test for analyzer defaults

Added: 
clang/test/Driver/ps4-ps5-analyzer-defaults.cpp

Modified: 


Removed: 
clang/test/Driver/ps4-analyzer-defaults.cpp



diff  --git a/clang/test/Driver/ps4-analyzer-defaults.cpp 
b/clang/test/Driver/ps4-analyzer-defaults.cpp
deleted file mode 100644
index e1649a38b6287..0
--- a/clang/test/Driver/ps4-analyzer-defaults.cpp
+++ /dev/null
@@ -1,33 +0,0 @@
-// Check that the default analyzer checkers for PS4 are:
-//   core
-//   cplusplus
-//   deadcode
-//   nullability
-//   unix
-// Excluding:
-//   unix.API
-//   unix.Vfork
-
-// Check for expected checkers
-// RUN: %clang -target x86_64-scei-ps4 --analyze %s -### 2>&1 \
-// RUN:   | FileCheck %s --check-prefix=CHECK-PS4-POS-CHECKERS
-//
-// Negative check for unexpected checkers
-// RUN: %clang -target x86_64-scei-ps4 --analyze %s -### 2>&1 \
-// RUN:   | FileCheck %s --check-prefix=CHECK-PS4-NEG-CHECKERS
-//
-// Check for all unix checkers except API and Vfork
-// RUN: %clang -target x86_64-scei-ps4 --analyze %s -### 2>&1 \
-// RUN:   | FileCheck %s --check-prefix=CHECK-PS4-UNIX-CHECKERS
-
-// CHECK-PS4-POS-CHECKERS-DAG: analyzer-checker=core
-// CHECK-PS4-POS-CHECKERS-DAG: analyzer-checker=cplusplus
-// CHECK-PS4-POS-CHECKERS-DAG: analyzer-checker=deadcode
-// CHECK-PS4-POS-CHECKERS-DAG: analyzer-checker=nullability
-//
-// CHECK-PS4-NEG-CHECKERS-NOT: analyzer-checker={{osx|security}}
-//
-// CHECK-PS4-UNIX-CHECKERS: analyzer-checker=unix
-// CHECK-PS4-UNIX-CHECKERS-DAG: analyzer-disable-checker=unix.API
-// CHECK-PS4-UNIX-CHECKERS-DAG: analyzer-disable-checker=unix.Vfork
-// CHECK-PS4-UNIX-CHECKERS-NOT: analyzer-checker=unix.{{API|Vfork}}

diff  --git a/clang/test/Driver/ps4-ps5-analyzer-defaults.cpp 
b/clang/test/Driver/ps4-ps5-analyzer-defaults.cpp
new file mode 100644
index 0..6e76f2c90ac84
--- /dev/null
+++ b/clang/test/Driver/ps4-ps5-analyzer-defaults.cpp
@@ -0,0 +1,39 @@
+// Check that the default analyzer checkers for PS4/PS5 are:
+//   core
+//   cplusplus
+//   deadcode
+//   nullability
+//   unix
+// Excluding:
+//   unix.API
+//   unix.Vfork
+
+// Check for expected checkers
+// RUN: %clang -target x86_64-scei-ps4 --analyze %s -### 2>&1 \
+// RUN:   | FileCheck %s --check-prefix=CHECK-POS-CHECKERS
+// RUN: %clang -target x86_64-sie-ps5 --analyze %s -### 2>&1 \
+// RUN:   | FileCheck %s --check-prefix=CHECK-POS-CHECKERS
+//
+// Negative check for unexpected checkers
+// RUN: %clang -target x86_64-scei-ps4 --analyze %s -### 2>&1 \
+// RUN:   | FileCheck %s --check-prefix=CHECK-NEG-CHECKERS
+// RUN: %clang -target x86_64-scei-ps4 --analyze %s -### 2>&1 \
+// RUN:   | FileCheck %s --check-prefix=CHECK-NEG-CHECKERS
+//
+// Check for all unix checkers except API and Vfork
+// RUN: %clang -target x86_64-scei-ps4 --analyze %s -### 2>&1 \
+// RUN:   | FileCheck %s --check-prefix=CHECK-UNIX-CHECKERS
+// RUN: %clang -target x86_64-scei-ps4 --analyze %s -### 2>&1 \
+// RUN:   | FileCheck %s --check-prefix=CHECK-UNIX-CHECKERS
+
+// CHECK-POS-CHECKERS-DAG: analyzer-checker=core
+// CHECK-POS-CHECKERS-DAG: analyzer-checker=cplusplus
+// CHECK-POS-CHECKERS-DAG: analyzer-checker=deadcode
+// CHECK-POS-CHECKERS-DAG: analyzer-checker=nullability
+//
+// CHECK-NEG-CHECKERS-NOT: analyzer-checker={{osx|security}}
+//
+// CHECK-UNIX-CHECKERS: analyzer-checker=unix
+// CHECK-UNIX-CHECKERS-DAG: analyzer-disable-checker=unix.API
+// CHECK-UNIX-CHECKERS-DAG: analyzer-disable-checker=unix.Vfork
+// CHECK-UNIX-CHECKERS-NOT: analyzer-checker=unix.{{API|Vfork}}



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

[PATCH] D124063: [LegacyPM] Rename and deprecate populateModulePassManager

[Josh Berdine via Phabricator via cfe-commits]

jberdine added a comment.

Apologies if this isn't directly related to this patch in particular, but is 
there a more informative message that could be given than "Migrate to new pass 
manager"? In particular, for non-C language bindings that currently call 
`LLVMPassManagerBuilderPopulateModulePassManager`, any pointers to what 
functions in the C API should be used instead would be very helpful.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124063

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

[clang] 6035649 - [Serialization] Remove dead TYPE_FUNCTION_PROTO abbreviation. NFC

[Sam McCall via cfe-commits]

Author: Sam McCall
Date: 2022-04-25T21:16:54+02:00
New Revision: 6035649d4c763dab83376484c5fe515c2469a1bb

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

LOG: [Serialization] Remove dead TYPE_FUNCTION_PROTO abbreviation. NFC

It was added in 01b2cb47 but never used.

Added: 


Modified: 
clang/include/clang/Serialization/ASTWriter.h
clang/lib/Serialization/ASTWriter.cpp

Removed: 




diff  --git a/clang/include/clang/Serialization/ASTWriter.h 
b/clang/include/clang/Serialization/ASTWriter.h
index 6cbf3dd20017a..57d001e571efc 100644
--- a/clang/include/clang/Serialization/ASTWriter.h
+++ b/clang/include/clang/Serialization/ASTWriter.h
@@ -477,7 +477,6 @@ class ASTWriter : public ASTDeserializationListener,
  bool isModule);
 
   unsigned TypeExtQualAbbrev = 0;
-  unsigned TypeFunctionProtoAbbrev = 0;
   void WriteTypeAbbrevs();
   void WriteType(QualType T);
 
@@ -682,10 +681,6 @@ class ASTWriter : public ASTDeserializationListener,
 return TypeExtQualAbbrev;
   }
 
-  unsigned getTypeFunctionProtoAbbrev() const {
-return TypeFunctionProtoAbbrev;
-  }
-
   unsigned getDeclParmVarAbbrev() const { return DeclParmVarAbbrev; }
   unsigned getDeclRecordAbbrev() const { return DeclRecordAbbrev; }
   unsigned getDeclTypedefAbbrev() const { return DeclTypedefAbbrev; }

diff  --git a/clang/lib/Serialization/ASTWriter.cpp 
b/clang/lib/Serialization/ASTWriter.cpp
index 4e8542e13ff70..189d1a914ec31 100644
--- a/clang/lib/Serialization/ASTWriter.cpp
+++ b/clang/lib/Serialization/ASTWriter.cpp
@@ -598,30 +598,6 @@ void ASTWriter::WriteTypeAbbrevs() {
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6));   // Type
   Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 3));   // Quals
   TypeExtQualAbbrev = Stream.EmitAbbrev(std::move(Abv));
-
-  // Abbreviation for TYPE_FUNCTION_PROTO
-  Abv = std::make_shared();
-  Abv->Add(BitCodeAbbrevOp(serialization::TYPE_FUNCTION_PROTO));
-  // FunctionType
-  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6));   // ReturnType
-  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // NoReturn
-  Abv->Add(BitCodeAbbrevOp(0)); // HasRegParm
-  Abv->Add(BitCodeAbbrevOp(0)); // RegParm
-  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 4)); // CC
-  Abv->Add(BitCodeAbbrevOp(0)); // ProducesResult
-  Abv->Add(BitCodeAbbrevOp(0)); // NoCallerSavedRegs
-  Abv->Add(BitCodeAbbrevOp(0)); // NoCfCheck
-  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Fixed, 1)); // CmseNSCall
-  // FunctionProtoType
-  Abv->Add(BitCodeAbbrevOp(0)); // IsVariadic
-  Abv->Add(BitCodeAbbrevOp(0)); // HasTrailingReturn
-  Abv->Add(BitCodeAbbrevOp(0)); // TypeQuals
-  Abv->Add(BitCodeAbbrevOp(0)); // RefQualifier
-  Abv->Add(BitCodeAbbrevOp(EST_None));  // ExceptionSpec
-  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6));   // NumParams
-  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Array));
-  Abv->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 6));   // Params
-  TypeFunctionProtoAbbrev = Stream.EmitAbbrev(std::move(Abv));
 }
 
 
//===--===//



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

[PATCH] D121589: [C++20][Modules][Driver][HU 2/N] Add fmodule-header, fmodule-header=

[Tom Honermann via Phabricator via cfe-commits]

tahonermann added inline comments.



Comment at: clang/docs/ClangCommandLineReference.rst:1183-1185
+.. option:: -fmodule-header=\[user,system\]
+
+Build a C++20 header unit, but search for the header in the user or system 
header search paths respectively.

iains wrote:
> iains wrote:
> > tahonermann wrote:
> > > Are "user" and "system" the right terms to use here? Existing options 
> > > aren't all that consistent. Some examples from `Options.td`:
> > >   def MD : Flag<["-"], "MD">, Group,
> > >   HelpText<"Write a depfile containing user and system headers">;
> > >   def MMD : Flag<["-"], "MMD">, Group,
> > >   HelpText<"Write a depfile containing user headers">;
> > >   ...
> > >   def iquote : JoinedOrSeparate<["-"], "iquote">, Group, 
> > > Flags<[CC1Option]>,
> > > HelpText<"Add directory to QUOTE include search path">, 
> > > MetaVarName<"">;
> > >   def isystem : JoinedOrSeparate<["-"], "isystem">, Group,
> > > Flags<[CC1Option]>,
> > > HelpText<"Add directory to SYSTEM include search path">, 
> > > MetaVarName<"">;
> > > 
> > > For comparison, the related MSVC options (also present in `Options.td`) 
> > > are:
> > >   def _SLASH_headerUnitAngle : CLJoinedOrSeparate<"headerUnit:angle">;
> > >   def _SLASH_headerUnitQuote : CLJoinedOrSeparate<"headerUnit:quote">;
> > > 
> > > Should there be a "both" or "any" option so that the search considers all 
> > > include paths as opposed to just user OR system?
> > > Are "user" and "system" the right terms to use here? Existing options 
> > > aren't all that consistent. Some examples from `Options.td`:
> > >   def MD : Flag<["-"], "MD">, Group,
> > >   HelpText<"Write a depfile containing user and system headers">;
> > >   def MMD : Flag<["-"], "MMD">, Group,
> > >   HelpText<"Write a depfile containing user headers">;
> > >   ...
> > >   def iquote : JoinedOrSeparate<["-"], "iquote">, Group, 
> > > Flags<[CC1Option]>,
> > > HelpText<"Add directory to QUOTE include search path">, 
> > > MetaVarName<"">;
> > >   def isystem : JoinedOrSeparate<["-"], "isystem">, Group,
> > > Flags<[CC1Option]>,
> > > HelpText<"Add directory to SYSTEM include search path">, 
> > > MetaVarName<"">;
> > > 
> > > For comparison, the related MSVC options (also present in `Options.td`) 
> > > are:
> > >   def _SLASH_headerUnitAngle : CLJoinedOrSeparate<"headerUnit:angle">;
> > >   def _SLASH_headerUnitQuote : CLJoinedOrSeparate<"headerUnit:quote">;
> > > 
> > > Should there be a "both" or "any" option so that the search considers all 
> > > include paths as opposed to just user OR system?
> > 
> > 
> At this time, the objective was to be command-line-option compatible with the 
> existing GCC implementation.  There is a goal to minimise difference in 
> interfaces presented to the user (and build systems).
> 
> Given that the latter [GCC] is already "in the wild", if we wanted 
> terminology-compatibility with MSVC, we could add aliases (to both), I 
> suppose.  I have no axe to grind here - if folks form a consensus that we 
> could have better terminology, I'm happy to add the aliases etc. 
> 
> There is also -fmodule-header ... which means "find the header at the path 
> specified" which can either be 'absolute' (i.e. / on unix-y systems) or 
> relative to CWD,
> 
> I'm not sure about 'both' or 'any' in the sense of how that would relate to 
> the existing behaviour of header searches (the mechanisms for substituting 
> HUs for textual headers assume that the searches are done with the same 
> process as for the textual).  
> 
> Hopefully, that expresses the intent of the current landed work - that is not 
> to say that the story ends here, but that probably there are other features 
> we want to complete before fine-tuning this.
Ah, I didn't realize gcc already implemented these options. I agree 
compatibility with it is the more important goal. Looks good to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121589

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

[PATCH] D124382: [Clang] Recognize target address space in superset calculation

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/include/clang/AST/Type.h:486
+   bool IsSYCLOrOpenCL = false) {
+if (ASMap) {
+  bool IsATargetAS = false;

If A and B are both target AS, we fall through to the code which is dealing 
with language AS, which would not do us any good. If that's not expected to 
happen, we should have an assert to ensure it.

Next, I'm not particularly fond of `IsSYCLOrOpenCL`. Do we need it at all. If 
we do know that AS maps to OpenCL `Constant` or `Generic`, I would assume that 
those AS would follow the same semantics. Besides, will we ever see OpenCL 
language AS in non-OpenCL code?

Next, the function *is* OpenCL specific and would not work for CUDA or HIP. I 
think it needs to be generalized to provide language-specific AS mapping rules.



Comment at: clang/include/clang/AST/Type.h:489
+  bool IsBTargetAS = false;
+  if (A > LangAS::FirstTargetAddressSpace)
+IsATargetAS = true;

Is the check intended to tell if A is a target AS? If so, we do have 
`isTargetAddressSpace()` for that (and it uses '>= 
LangAS::FirstTargetAddressSpace', which suggests that `>` may be incorrect, 
too).



Comment at: clang/include/clang/AST/Type.h:498-499
+LangAS Constant = static_cast(
+(*ASMap)[static_cast(LangAS::opencl_constant)] +
+static_cast(LangAS::FirstTargetAddressSpace));
+if (IsATargetAS)

`getLangASFromTargetAS((*ASMap)[static_cast(LangAS::opencl_constant)])`
 



Comment at: clang/include/clang/AST/Type.h:500
+static_cast(LangAS::FirstTargetAddressSpace));
+if (IsATargetAS)
+  B = static_cast(

`if (!IsBTargetAS)` would be more directly related to what we're doing here.



Comment at: clang/include/clang/AST/Type.h:508
+  static_cast(LangAS::FirstTargetAddressSpace));
+// When dealing with target AS return true if:
+// * A is equal to B, or

Is the code above intended to ensure that both A and B are target AS at this 
point?
If so, then it could be simplified to something like this:
```
if (ASMap) {
  if (!isTargetAddressSpace(A))
A = getLangASFromTargetAS((*ASMap)[static_cast(A)]);
  if (!isTargetAddressSpace(B))
B = getLangASFromTargetAS((*ASMap)[static_cast(B)]);

  Generic = 
getLangASFromTargetAS((*ASMap)[static_cast(LangAS::opencl_generic)])
  Constant = 
getLangASFromTargetAS((*ASMap)[static_cast(LangAS::opencl_constant)]);

  // ... proceed inferring whether A is superset of B in target AS.
  return;
}
assert (isTargetAddressSpace(A) && isTargetAddressSpace(B));
```



Comment at: clang/lib/Sema/SemaExpr.cpp:9204
+  const LangASMap &ASMap = S.Context.getTargetInfo().getAddressSpaceMap();
+  if (!lhq.compatiblyIncludes(rhq, &ASMap)) {
+const bool AddressSpaceSuperset = Qualifiers::isAddressSpaceSupersetOf(

Should you pass `IsSYCLOrOpenCL` to it too? The way `isAddressSpaceSupersetOf` 
is implemented now it may give you a different result without it. 

Also, it may make sense to plumb ASMap into `lhq.isAddressSpaceSupersetOf`, 
too, and just use the old code + couple of new arguments.



Comment at: clang/lib/Sema/SemaExpr.cpp:9219
 // and from void*.
-else if (lhq.withoutObjCGCAttr().withoutObjCLifetime()
-.compatiblyIncludes(
-rhq.withoutObjCGCAttr().withoutObjCLifetime())
- && (lhptee->isVoidType() || rhptee->isVoidType()))
+else if (lhq.withoutObjCGCAttr().withoutObjCLifetime().compatiblyIncludes(
+ rhq.withoutObjCGCAttr().withoutObjCLifetime()) &&

Do we need to pass `ASMap` and `IsSYCLOrOpenCL` here, too?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124382

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

[PATCH] D123319: Change how we handle auto return types for lambda operator() to be consistent with gcc

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/test/CodeGenCXX/no_auto_return_lambda.cpp:1
+// RUN: %clang_cc1 -emit-llvm -debug-info-kind=limited %s -o - | FileCheck %s
+

So this CodeGen test without a triple is a bit troublesome.  The one we've 
noticed that this fails on the 32 bit windows build:

```
FAIL: Clang :: CodeGenCXX/no_auto_return_lambda.cpp (41841 of 57667)
 TEST 'Clang :: CodeGenCXX/no_auto_return_lambda.cpp' 
FAILED 
Script:
--
: 'RUN: at line 1';   
d:\netbatch\build_comp02320_00\ics_top\builds\xmainoclx86win_prod\llvm\bin\clang.exe
 -cc1 -internal-isystem 
d:\netbatch\build_comp02320_00\ics_top\builds\xmainoclx86win_prod\llvm\lib\clang\15.0.0\include
 -nostdsysteminc -emit-llvm -debug-info-kind=limited 
D:\netbatch\build_comp02320_00\ics_top\llvm\clang\test\CodeGenCXX\no_auto_return_lambda.cpp
 -o - | 
d:\netbatch\build_comp02320_00\ics_top\builds\xmainoclx86win_prod\llvm\bin\filecheck.exe
 
D:\netbatch\build_comp02320_00\ics_top\llvm\clang\test\CodeGenCXX\no_auto_return_lambda.cpp
--
Exit Code: 1Command Output (stdout):
--
$ ":" "RUN: at line 1"
$ 
"d:\netbatch\build_comp02320_00\ics_top\builds\xmainoclx86win_prod\llvm\bin\clang.exe"
 "-cc1" "-internal-isystem" 
"d:\netbatch\build_comp02320_00\ics_top\builds\xmainoclx86win_prod\llvm\lib\clang\15.0.0\include"
 "-nostdsysteminc" "-emit-llvm" "-debug-info-kind=limited" 
"D:\netbatch\build_comp02320_00\ics_top\llvm\clang\test\CodeGenCXX\no_auto_return_lambda.cpp"
 "-o" "-"
$ 
"d:\netbatch\build_comp02320_00\ics_top\builds\xmainoclx86win_prod\llvm\bin\filecheck.exe"
 
"D:\netbatch\build_comp02320_00\ics_top\llvm\clang\test\CodeGenCXX\no_auto_return_lambda.cpp"
# command stderr:
D:\netbatch\build_comp02320_00\ics_top\llvm\clang\test\CodeGenCXX\no_auto_return_lambda.cpp:24:11:
 error: CHECK: expected string not found in input
// CHECK: ![[FUN_TYPE_LAMBDA]] = !DISubroutineType(types: 
![[TYPE_NODE_LAMBDA:[0-9]+]])
  ^
:56:289: note: scanning from here
!17 = distinct !DISubprogram(name: "operator()", linkageName: 
"??R@?0??g@@YAHXZ@QBE?A?@@XZ", scope: !13, file: !7, line: 9, 
type: !18, scopeLine: 9, flags: DIFlagPrototyped, spFlags: DISPFlagLocalToUnit 
| DISPFlagDefinition, unit: !0, declaration: !22, retainedNodes: !11)   

^
:56:289: note: with "FUN_TYPE_LAMBDA" equal to "18"
!17 = distinct !DISubprogram(name: "operator()", linkageName: 
"??R@?0??g@@YAHXZ@QBE?A?@@XZ", scope: !13, file: !7, line: 9, 
type: !18, scopeLine: 9, flags: DIFlagPrototyped, spFlags: DISPFlagLocalToUnit 
| DISPFlagDefinition, unit: !0, declaration: !22, retainedNodes: !11)   

^
:57:1: note: possible intended match here
!18 = !DISubroutineType(cc: DW_CC_BORLAND_thiscall, types: !19)
^Input file: 
Check file: 
D:\netbatch\build_comp02320_00\ics_top\llvm\clang\test\CodeGenCXX\no_auto_return_lambda.cpp
-dump-input=help explains the following input dump.Input was:
<<
.
.
.
   51: !12 = !DILocalVariable(name: "f", scope: !6, file: !7, line: 9, 
type: !13)
   52: !13 = distinct !DICompositeType(tag: DW_TAG_class_type, scope: 
!6, file: !7, line: 9, size: 8, flags: DIFlagTypePassByValue | 
DIFlagNonTrivial, elements: !11)
   53: !14 = !DILocation(line: 9, column: 8, scope: !6)
   54: !15 = !DILocation(line: 10, column: 10, scope: !6)
   55: !16 = !DILocation(line: 10, column: 3, scope: !6)
   56: !17 = distinct !DISubprogram(name: "operator()", linkageName: 
"??R@?0??g@@YAHXZ@QBE?A?@@XZ", scope: !13, file: !7, line: 9, 
type: !18, scopeLine: 9, flags: DIFlagPrototyped, spFlags: DISPFlagLocalToUnit 
| DISPFlagDefinition, unit: !0, declaration: !22, retainedNodes: !11)
check:24'0  


   X error: no 
match found
check:24'1  


 with 
"FUN_TYPE_LAMBDA" equal to "18"
   57: !18 = !DISubroutineType(cc: DW_CC_BORLAND_thiscall, types: !19)
check:24'0 
check:24'2 ?
possible intended match
   58: !19 = !{!10, !20}
check:24'0 ~~
   59: !20 = !DIDerivedType(tag: DW_TAG_pointer_ty

[PATCH] D123831: [POC][WIP] Use relative include in extract-api

[Zixu Wang via Phabricator via cfe-commits]

zixuw added a comment.

The problem is that we are trying to shorten the input file paths in 
`PrepareToExecuteAction`, where the `CompilerInstance` is still primal and 
doesn't even have a `FileManager` that we could use. That makes it hard (if 
possible at all) to reverse lookup headermaps and use the spelled names if we 
failed to find a search path prefix.
The impact is that we won't be able to get an angled include name for cases 
where an input doesn't reside in any of the normal search paths, but a 
headermap entry maps some name to that path. Or we might get the wrong include 
name where there are both headermap entries and search paths that match the 
input path and the ordering matters.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123831

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

[PATCH] D121589: [C++20][Modules][Driver][HU 2/N] Add fmodule-header, fmodule-header=

[Iain Sandoe via Phabricator via cfe-commits]

iains added inline comments.



Comment at: clang/docs/ClangCommandLineReference.rst:1183-1185
+.. option:: -fmodule-header=\[user,system\]
+
+Build a C++20 header unit, but search for the header in the user or system 
header search paths respectively.

tahonermann wrote:
> Are "user" and "system" the right terms to use here? Existing options aren't 
> all that consistent. Some examples from `Options.td`:
>   def MD : Flag<["-"], "MD">, Group,
>   HelpText<"Write a depfile containing user and system headers">;
>   def MMD : Flag<["-"], "MMD">, Group,
>   HelpText<"Write a depfile containing user headers">;
>   ...
>   def iquote : JoinedOrSeparate<["-"], "iquote">, Group, 
> Flags<[CC1Option]>,
> HelpText<"Add directory to QUOTE include search path">, 
> MetaVarName<"">;
>   def isystem : JoinedOrSeparate<["-"], "isystem">, Group,
> Flags<[CC1Option]>,
> HelpText<"Add directory to SYSTEM include search path">, 
> MetaVarName<"">;
> 
> For comparison, the related MSVC options (also present in `Options.td`) are:
>   def _SLASH_headerUnitAngle : CLJoinedOrSeparate<"headerUnit:angle">;
>   def _SLASH_headerUnitQuote : CLJoinedOrSeparate<"headerUnit:quote">;
> 
> Should there be a "both" or "any" option so that the search considers all 
> include paths as opposed to just user OR system?
> Are "user" and "system" the right terms to use here? Existing options aren't 
> all that consistent. Some examples from `Options.td`:
>   def MD : Flag<["-"], "MD">, Group,
>   HelpText<"Write a depfile containing user and system headers">;
>   def MMD : Flag<["-"], "MMD">, Group,
>   HelpText<"Write a depfile containing user headers">;
>   ...
>   def iquote : JoinedOrSeparate<["-"], "iquote">, Group, 
> Flags<[CC1Option]>,
> HelpText<"Add directory to QUOTE include search path">, 
> MetaVarName<"">;
>   def isystem : JoinedOrSeparate<["-"], "isystem">, Group,
> Flags<[CC1Option]>,
> HelpText<"Add directory to SYSTEM include search path">, 
> MetaVarName<"">;
> 
> For comparison, the related MSVC options (also present in `Options.td`) are:
>   def _SLASH_headerUnitAngle : CLJoinedOrSeparate<"headerUnit:angle">;
>   def _SLASH_headerUnitQuote : CLJoinedOrSeparate<"headerUnit:quote">;
> 
> Should there be a "both" or "any" option so that the search considers all 
> include paths as opposed to just user OR system?





Comment at: clang/docs/ClangCommandLineReference.rst:1183-1185
+.. option:: -fmodule-header=\[user,system\]
+
+Build a C++20 header unit, but search for the header in the user or system 
header search paths respectively.

iains wrote:
> tahonermann wrote:
> > Are "user" and "system" the right terms to use here? Existing options 
> > aren't all that consistent. Some examples from `Options.td`:
> >   def MD : Flag<["-"], "MD">, Group,
> >   HelpText<"Write a depfile containing user and system headers">;
> >   def MMD : Flag<["-"], "MMD">, Group,
> >   HelpText<"Write a depfile containing user headers">;
> >   ...
> >   def iquote : JoinedOrSeparate<["-"], "iquote">, Group, 
> > Flags<[CC1Option]>,
> > HelpText<"Add directory to QUOTE include search path">, 
> > MetaVarName<"">;
> >   def isystem : JoinedOrSeparate<["-"], "isystem">, Group,
> > Flags<[CC1Option]>,
> > HelpText<"Add directory to SYSTEM include search path">, 
> > MetaVarName<"">;
> > 
> > For comparison, the related MSVC options (also present in `Options.td`) are:
> >   def _SLASH_headerUnitAngle : CLJoinedOrSeparate<"headerUnit:angle">;
> >   def _SLASH_headerUnitQuote : CLJoinedOrSeparate<"headerUnit:quote">;
> > 
> > Should there be a "both" or "any" option so that the search considers all 
> > include paths as opposed to just user OR system?
> > Are "user" and "system" the right terms to use here? Existing options 
> > aren't all that consistent. Some examples from `Options.td`:
> >   def MD : Flag<["-"], "MD">, Group,
> >   HelpText<"Write a depfile containing user and system headers">;
> >   def MMD : Flag<["-"], "MMD">, Group,
> >   HelpText<"Write a depfile containing user headers">;
> >   ...
> >   def iquote : JoinedOrSeparate<["-"], "iquote">, Group, 
> > Flags<[CC1Option]>,
> > HelpText<"Add directory to QUOTE include search path">, 
> > MetaVarName<"">;
> >   def isystem : JoinedOrSeparate<["-"], "isystem">, Group,
> > Flags<[CC1Option]>,
> > HelpText<"Add directory to SYSTEM include search path">, 
> > MetaVarName<"">;
> > 
> > For comparison, the related MSVC options (also present in `Options.td`) are:
> >   def _SLASH_headerUnitAngle : CLJoinedOrSeparate<"headerUnit:angle">;
> >   def _SLASH_headerUnitQuote : CLJoinedOrSeparate<"headerUnit:quote">;
> > 
> > Should there be a "both" or "any" option so that the search considers all 
> > include paths as opposed to just user OR system?
> 
> 
At this time, the objective was to be command-line-option compatible with the 
existing GCC implementation.

[PATCH] D122258: [MC] Omit DWARF unwind info if compact unwind is present for all archs

[Jez Ng via Phabricator via cfe-commits]

int3 added a comment.

bump @lhames @JDevlieghere would either of y'all be able to review this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122258

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

[PATCH] D121589: [C++20][Modules][Driver][HU 2/N] Add fmodule-header, fmodule-header=

[Tom Honermann via Phabricator via cfe-commits]

tahonermann added inline comments.



Comment at: clang/docs/ClangCommandLineReference.rst:1183-1185
+.. option:: -fmodule-header=\[user,system\]
+
+Build a C++20 header unit, but search for the header in the user or system 
header search paths respectively.

Are "user" and "system" the right terms to use here? Existing options aren't 
all that consistent. Some examples from `Options.td`:
  def MD : Flag<["-"], "MD">, Group,
  HelpText<"Write a depfile containing user and system headers">;
  def MMD : Flag<["-"], "MMD">, Group,
  HelpText<"Write a depfile containing user headers">;
  ...
  def iquote : JoinedOrSeparate<["-"], "iquote">, Group, 
Flags<[CC1Option]>,
HelpText<"Add directory to QUOTE include search path">, 
MetaVarName<"">;
  def isystem : JoinedOrSeparate<["-"], "isystem">, Group,
Flags<[CC1Option]>,
HelpText<"Add directory to SYSTEM include search path">, 
MetaVarName<"">;

For comparison, the related MSVC options (also present in `Options.td`) are:
  def _SLASH_headerUnitAngle : CLJoinedOrSeparate<"headerUnit:angle">;
  def _SLASH_headerUnitQuote : CLJoinedOrSeparate<"headerUnit:quote">;

Should there be a "both" or "any" option so that the search considers all 
include paths as opposed to just user OR system?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121589

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

[PATCH] D124262: compile commands header to source heuristic lower-cases filenames before inferring file types

[Sam McCall via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG87468e85fcdc: compile commands header to source heuristic 
lower-cases filenames before… (authored by ishaangandhi, committed by 
sammccall).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124262

Files:
  clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
  clang/unittests/Tooling/CompilationDatabaseTest.cpp


Index: clang/unittests/Tooling/CompilationDatabaseTest.cpp
===
--- clang/unittests/Tooling/CompilationDatabaseTest.cpp
+++ clang/unittests/Tooling/CompilationDatabaseTest.cpp
@@ -836,6 +836,14 @@
   EXPECT_EQ(getProxy("foo/bar/baz/shout.C"), "FOO/BAR/BAZ/SHOUT.cc");
 }
 
+TEST_F(InterpolateTest, LanguagePreference) {
+  add("foo/bar/baz/exact.C");
+  add("foo/bar/baz/exact.c");
+  add("other/random/path.cpp");
+  // Proxies for ".H" files are ".C" files, and not ".c files".
+  EXPECT_EQ(getProxy("foo/bar/baz/exact.H"), "foo/bar/baz/exact.C");
+}
+
 TEST_F(InterpolateTest, Aliasing) {
   add("foo.cpp", "-faligned-new");
 
Index: clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
===
--- clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
+++ clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
@@ -328,7 +328,7 @@
   StringRef Path = Strings.save(StringRef(OriginalPaths[I]).lower());
 
   Paths.emplace_back(Path, I);
-  Types.push_back(foldType(guessType(Path)));
+  Types.push_back(foldType(guessType(OriginalPaths[I])));
   Stems.emplace_back(sys::path::stem(Path), I);
   auto Dir = ++sys::path::rbegin(Path), DirEnd = sys::path::rend(Path);
   for (int J = 0; J < DirectorySegmentsIndexed && Dir != DirEnd; ++J, 
++Dir)


Index: clang/unittests/Tooling/CompilationDatabaseTest.cpp
===
--- clang/unittests/Tooling/CompilationDatabaseTest.cpp
+++ clang/unittests/Tooling/CompilationDatabaseTest.cpp
@@ -836,6 +836,14 @@
   EXPECT_EQ(getProxy("foo/bar/baz/shout.C"), "FOO/BAR/BAZ/SHOUT.cc");
 }
 
+TEST_F(InterpolateTest, LanguagePreference) {
+  add("foo/bar/baz/exact.C");
+  add("foo/bar/baz/exact.c");
+  add("other/random/path.cpp");
+  // Proxies for ".H" files are ".C" files, and not ".c files".
+  EXPECT_EQ(getProxy("foo/bar/baz/exact.H"), "foo/bar/baz/exact.C");
+}
+
 TEST_F(InterpolateTest, Aliasing) {
   add("foo.cpp", "-faligned-new");
 
Index: clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
===
--- clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
+++ clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
@@ -328,7 +328,7 @@
   StringRef Path = Strings.save(StringRef(OriginalPaths[I]).lower());
 
   Paths.emplace_back(Path, I);
-  Types.push_back(foldType(guessType(Path)));
+  Types.push_back(foldType(guessType(OriginalPaths[I])));
   Stems.emplace_back(sys::path::stem(Path), I);
   auto Dir = ++sys::path::rbegin(Path), DirEnd = sys::path::rend(Path);
   for (int J = 0; J < DirectorySegmentsIndexed && Dir != DirEnd; ++J, ++Dir)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 87468e8 - compile commands header to source heuristic lower-cases filenames before inferring file types

[Sam McCall via cfe-commits]

Author: Ishaan Gandhi
Date: 2022-04-25T20:40:56+02:00
New Revision: 87468e85fcdcf1bd5055466e34d17436a79017a2

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

LOG: compile commands header to source heuristic lower-cases filenames before 
inferring file types

This leads to ".C" files being rewritten as ".c" files and being inferred to be 
"c" files as opposed to "c++" files.

Fixes https://github.com/clangd/clangd/issues/1108

Reviewed By: sammccall

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

Added: 


Modified: 
clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
clang/unittests/Tooling/CompilationDatabaseTest.cpp

Removed: 




diff  --git a/clang/lib/Tooling/InterpolatingCompilationDatabase.cpp 
b/clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
index 51e8439b6b79b..0143b5f8df6b6 100644
--- a/clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
+++ b/clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
@@ -328,7 +328,7 @@ class FileIndex {
   StringRef Path = Strings.save(StringRef(OriginalPaths[I]).lower());
 
   Paths.emplace_back(Path, I);
-  Types.push_back(foldType(guessType(Path)));
+  Types.push_back(foldType(guessType(OriginalPaths[I])));
   Stems.emplace_back(sys::path::stem(Path), I);
   auto Dir = ++sys::path::rbegin(Path), DirEnd = sys::path::rend(Path);
   for (int J = 0; J < DirectorySegmentsIndexed && Dir != DirEnd; ++J, 
++Dir)

diff  --git a/clang/unittests/Tooling/CompilationDatabaseTest.cpp 
b/clang/unittests/Tooling/CompilationDatabaseTest.cpp
index adb9de0c1cbaa..8194dd3953c20 100644
--- a/clang/unittests/Tooling/CompilationDatabaseTest.cpp
+++ b/clang/unittests/Tooling/CompilationDatabaseTest.cpp
@@ -836,6 +836,14 @@ TEST_F(InterpolateTest, Case) {
   EXPECT_EQ(getProxy("foo/bar/baz/shout.C"), "FOO/BAR/BAZ/SHOUT.cc");
 }
 
+TEST_F(InterpolateTest, LanguagePreference) {
+  add("foo/bar/baz/exact.C");
+  add("foo/bar/baz/exact.c");
+  add("other/random/path.cpp");
+  // Proxies for ".H" files are ".C" files, and not ".c files".
+  EXPECT_EQ(getProxy("foo/bar/baz/exact.H"), "foo/bar/baz/exact.C");
+}
+
 TEST_F(InterpolateTest, Aliasing) {
   add("foo.cpp", "-faligned-new");
 



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

[PATCH] D124396: [HIP] Fix diag msg about sanitizer

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl marked an inline comment as done.
yaxunl added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticDriverKinds.td:113-114
 def warn_drv_unsupported_option_for_offload_arch_req_feature : Warning<
-  "ignoring '%0' option as it is not currently supported for "
-  "offload arch '%1'. Use it with an offload arch containing '%2' instead">,
+  "ignoring '%0' option for offload arch '%1' as it is not currently supported 
for "
+  "that offload arch. Use it with an offload arch containing '%2' instead">,
   InGroup;

tra wrote:
> 'there' would be more concise and less repetitive.
will do when committing


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

https://reviews.llvm.org/D124396

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

[PATCH] D119544: Deferred Concept Instantiation Implementation

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

Alright, a touch more:  It looks like the looping through the `CurContext` at 
line 6084 finds the wrong thing in evaluating this `CXXMethodDecl`!  The 
"broken" version has its CurContext as `bar` in the example above, the 
"working" versions have `foo` or `foo2`.  Therefore the 2nd time through 
the loop, those both end up on the `ClassTemplateSpecializationDecl`, but the 
broken one finds the `isFileContext` version.

So I don't know HOW to fix it, but it seems that the `CheckFunctionConstraints` 
probably has to change the `CurContext`.  I suspect the instantiation of the 
`WorkingRequires` does something like this correctly.

I'm poking on/off on it today, but if @ChuanqiXu has an idea/help, it would be 
greatly appreciated.


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

https://reviews.llvm.org/D119544

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

[PATCH] D119544: Deferred Concept Instantiation Implementation

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

Here is the example I'm playing with:

  template
  constexpr bool constraint = true;
  
  #define BROKE_REQUIRES 1
  #define WORKING_REQUIRES 2
  #define WORKING_BODY 3
   
  #define TEST BROKE_REQUIRES
  //#define TEST WORKING_REQUIRES
  //#define TEST WORKING_BODY
   
  template
  struct S {
T t;
void foo()
  #if TEST == BROKE_REQUIRES
  requires (constraint)
  #endif
  {
  #if TEST == WORKING_BODY
  using G = decltype(t);
  #endif
}
  #if TEST == WORKING_REQUIRES
template
void foo2() requires (constraint){}
  #endif
  };
   
  void bar() {
S s;
  #if TEST == BROKE_REQUIRES || TEST == WORKING_BODY
s.foo();
  #endif
  #if TEST == WORKING_REQUIRES
s.foo2();
  #endif
  }

For all 3 versions (see the definitions of TEST), they get to 6083 on the 1st 
breakpoint.


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

https://reviews.llvm.org/D119544

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

[PATCH] D124396: [HIP] Fix diag msg about sanitizer

[Artem Belevich via Phabricator via cfe-commits]

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

Wording nit. LGTM otherwise.




Comment at: clang/include/clang/Basic/DiagnosticDriverKinds.td:113-114
 def warn_drv_unsupported_option_for_offload_arch_req_feature : Warning<
-  "ignoring '%0' option as it is not currently supported for "
-  "offload arch '%1'. Use it with an offload arch containing '%2' instead">,
+  "ignoring '%0' option for offload arch '%1' as it is not currently supported 
for "
+  "that offload arch. Use it with an offload arch containing '%2' instead">,
   InGroup;

'there' would be more concise and less repetitive.


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

https://reviews.llvm.org/D124396

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

[PATCH] D119544: Deferred Concept Instantiation Implementation

[Erich Keane via Phabricator via cfe-commits]

erichkeane updated this revision to Diff 424963.
erichkeane added a comment.
This revision is now accepted and ready to land.

Here is my current 'WIP' patch, with only `ChecksMemberVar::foo` failing.  I 
noticed that the problem so far starts in `TransformMemberExpr`, which calls 
`TransformDecl` (TreeTransform.h: ~11018). THAT ends up being a 'pass through' 
and just calls `SemaRef.FindInstantiatedDecl`, which attempts to get the 
instantiated version of `S` in its call to `FindInstantiatedContext` (see 
SemaTemplateInstantiateDecl.cpp:6160).

THAT calls `FindInstantiatedDecl` again on the `ParentDC` (which is the 
uninstantiated `CXXRecordDecl` of `S`), and ends up going down past the 
`ClassTemplate` calculation (~6083, which is DeclContext *DC = CurContext), and 
everything is the same up to there.

That is the point that I have ended looking into it at the moment, but I think 
the problem/or at least something that should suggest the fix is there, since 
it manages to instead return the primary template  instead of the 
instantiation-of-int.


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

https://reviews.llvm.org/D119544

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/Decl.h
  clang/include/clang/AST/DeclBase.h
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Sema/Template.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/Decl.cpp
  clang/lib/AST/DeclBase.cpp
  clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
  clang/lib/Sema/SemaConcept.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/CXX/temp/temp.constr/temp.constr.constr/non-function-templates.cpp
  clang/test/SemaTemplate/concepts.cpp
  clang/test/SemaTemplate/deferred-concept-inst.cpp
  clang/test/SemaTemplate/instantiate-requires-clause.cpp
  clang/test/SemaTemplate/trailing-return-short-circuit.cpp

Index: clang/test/SemaTemplate/trailing-return-short-circuit.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/trailing-return-short-circuit.cpp
@@ -0,0 +1,62 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+
+template 
+  requires(sizeof(T) > 2) || T::value // #FOO_REQ
+void Foo(T){};// #FOO
+
+template 
+void TrailingReturn(T)   // #TRAILING
+  requires(sizeof(T) > 2) || // #TRAILING_REQ
+  T::value   // #TRAILING_REQ_VAL
+{};
+template 
+struct HasValue {
+  static constexpr bool value = B;
+};
+static_assert(sizeof(HasValue) <= 2);
+
+template 
+struct HasValueLarge {
+  static constexpr bool value = B;
+  int I;
+};
+static_assert(sizeof(HasValueLarge) > 2);
+
+void usage() {
+  // Passes the 1st check, short-circuit so the 2nd ::value is not evaluated.
+  Foo(1.0);
+  TrailingReturn(1.0);
+
+  // Fails the 1st check, but has a ::value, so the check happens correctly.
+  Foo(HasValue{});
+  TrailingReturn(HasValue{});
+
+  // Passes the 1st check, but would have passed the 2nd one.
+  Foo(HasValueLarge{});
+  TrailingReturn(HasValueLarge{});
+
+  // Fails the 1st check, fails 2nd because there is no ::value.
+  Foo(true);
+  // expected-error@-1{{no matching function for call to 'Foo'}}
+  // expected-note@#FOO{{candidate template ignored: constraints not satisfied [with T = bool]}}
+  // expected-note@#FOO_REQ{{because 'sizeof(_Bool) > 2' (1 > 2) evaluated to false}}
+  // expected-note@#FOO_REQ{{because substituted constraint expression is ill-formed: type 'bool' cannot be used prior to '::' because it has no members}}
+
+  TrailingReturn(true);
+  // expected-error@-1{{no matching function for call to 'TrailingReturn'}}
+  // expected-note@#TRAILING{{candidate template ignored: constraints not satisfied [with T = bool]}}
+  // expected-note@#TRAILING_REQ{{because 'sizeof(_Bool) > 2' (1 > 2) evaluated to false}}
+  // expected-note@#TRAILING_REQ_VAL{{because substituted constraint expression is ill-formed: type 'bool' cannot be used prior to '::' because it has no members}}
+
+  // Fails the 1st check, fails 2nd because ::value is false.
+  Foo(HasValue{});
+  // expected-error@-1 {{no matching function for call to 'Foo'}}
+  // expected-note@#FOO{{candidate template ignored: constraints not satisfied [with T = HasValue]}}
+  // expected-note@#FOO_REQ{{because 'sizeof(HasValue) > 2' (1 > 2) evaluated to false}}
+  // expected-note@#FOO_REQ{{and 'HasValue::value' evaluated to false}}
+  TrailingReturn(HasValue{});
+  // expected-error@-1 {{no matching function for call to 'TrailingReturn'}}
+  // expected-note@#TRAILING{{candidate template ignored: constraints not satisfied [with T = HasValue]}}
+  // expected-note@#TRAILING_REQ{{because 'sizeof(HasValue) > 2' (1 > 2) evaluated to false}}
+  // expected-note@#TRAILING_REQ_VAL{{and 'HasValue::val

[clang] ef7439b - [Basic] SourceManager docs: macro expansion SLocs aren't a single token. NFC

[Sam McCall via cfe-commits]

Author: Sam McCall
Date: 2022-04-25T19:57:47+02:00
New Revision: ef7439bdf923e59095449c3bc8cfe72d8101eea5

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

LOG: [Basic] SourceManager docs: macro expansion SLocs aren't a single token. 
NFC

And haven't been since 2011: 
https://github.com/llvm/llvm-project/commit/eeca36fe9ad767380b2eab76a6fe5ba410a47393

Added: 


Modified: 
clang/include/clang/Basic/SourceManager.h
clang/lib/AST/ASTImporter.cpp
clang/lib/Basic/SourceManager.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/SourceManager.h 
b/clang/include/clang/Basic/SourceManager.h
index 3f3f1bb65c2c1..73e6353109d92 100644
--- a/clang/include/clang/Basic/SourceManager.h
+++ b/clang/include/clang/Basic/SourceManager.h
@@ -900,22 +900,26 @@ class SourceManager : public 
RefCountedBase {
   FileID getOrCreateFileID(const FileEntry *SourceFile,
SrcMgr::CharacteristicKind FileCharacter);
 
-  /// Return a new SourceLocation that encodes the
-  /// fact that a token from SpellingLoc should actually be referenced from
-  /// ExpansionLoc, and that it represents the expansion of a macro argument
-  /// into the function-like macro body.
-  SourceLocation createMacroArgExpansionLoc(SourceLocation Loc,
+  /// Creates an expansion SLocEntry for the substitution of an argument into a
+  /// function-like macro's body. Returns the start of the expansion.
+  ///
+  /// The macro argument was written at \p SpellingLoc with length \p Length.
+  /// \p ExpansionLoc is the parameter name in the (expanded) macro body.
+  SourceLocation createMacroArgExpansionLoc(SourceLocation SpellingLoc,
 SourceLocation ExpansionLoc,
-unsigned TokLength);
+unsigned Length);
 
-  /// Return a new SourceLocation that encodes the fact
-  /// that a token from SpellingLoc should actually be referenced from
-  /// ExpansionLoc.
-  SourceLocation
-  createExpansionLoc(SourceLocation Loc, SourceLocation ExpansionLocStart,
- SourceLocation ExpansionLocEnd, unsigned TokLength,
- bool ExpansionIsTokenRange = true, int LoadedID = 0,
- SourceLocation::UIntTy LoadedOffset = 0);
+  /// Creates an expansion SLocEntry for a macro use. Returns its start.
+  ///
+  /// The macro body begins at \p SpellingLoc with length \p Length.
+  /// The macro use spans [ExpansionLocStart, ExpansionLocEnd].
+  SourceLocation createExpansionLoc(SourceLocation SpellingLoc,
+SourceLocation ExpansionLocStart,
+SourceLocation ExpansionLocEnd,
+unsigned Length,
+bool ExpansionIsTokenRange = true,
+int LoadedID = 0,
+SourceLocation::UIntTy LoadedOffset = 0);
 
   /// Return a new SourceLocation that encodes that the token starting
   /// at \p TokenStart ends prematurely at \p TokenEnd.
@@ -1803,7 +1807,7 @@ class SourceManager : public 
RefCountedBase {
   /// the SLocEntry table and producing a source location that refers to it.
   SourceLocation
   createExpansionLocImpl(const SrcMgr::ExpansionInfo &Expansion,
- unsigned TokLength, int LoadedID = 0,
+ unsigned Length, int LoadedID = 0,
  SourceLocation::UIntTy LoadedOffset = 0);
 
   /// Return true if the specified FileID contains the

diff  --git a/clang/lib/AST/ASTImporter.cpp b/clang/lib/AST/ASTImporter.cpp
index 537ccc22ed050..e2294088908c5 100644
--- a/clang/lib/AST/ASTImporter.cpp
+++ b/clang/lib/AST/ASTImporter.cpp
@@ -9293,13 +9293,13 @@ Expected ASTImporter::Import(FileID FromID, 
bool IsBuiltin) {
 ExpectedSLoc ToExLocS = Import(FromEx.getExpansionLocStart());
 if (!ToExLocS)
   return ToExLocS.takeError();
-unsigned TokenLen = FromSM.getFileIDSize(FromID);
+unsigned ExLength = FromSM.getFileIDSize(FromID);
 SourceLocation MLoc;
 if (FromEx.isMacroArgExpansion()) {
-  MLoc = ToSM.createMacroArgExpansionLoc(*ToSpLoc, *ToExLocS, TokenLen);
+  MLoc = ToSM.createMacroArgExpansionLoc(*ToSpLoc, *ToExLocS, ExLength);
 } else {
   if (ExpectedSLoc ToExLocE = Import(FromEx.getExpansionLocEnd()))
-MLoc = ToSM.createExpansionLoc(*ToSpLoc, *ToExLocS, *ToExLocE, 
TokenLen,
+MLoc = ToSM.createExpansionLoc(*ToSpLoc, *ToExLocS, *ToExLocE, 
ExLength,
FromEx.isExpansionTokenRange());
   else
 return ToExLocE.takeError();

diff  --git a/clang/lib/Basic/SourceManager.cpp 
b/clan

[PATCH] D123831: [POC][WIP] Use relative include in extract-api

[Zixu Wang via Phabricator via cfe-commits]

zixuw updated this revision to Diff 424959.
zixuw added a comment.

- Use first match in `getRelativeIncludeName`
- Try to get Preprocessor and reverse lookup headermaps in 
`getRelativeIncludeName`
- Use `getRelativeIncludeName` to check for known files in `LocationFileChecker`
- Misc fixes & adjustments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123831

Files:
  clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
  clang/test/ExtractAPI/relative_include.m

Index: clang/test/ExtractAPI/relative_include.m
===
--- /dev/null
+++ clang/test/ExtractAPI/relative_include.m
@@ -0,0 +1,130 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+
+// Setup framework root
+// RUN: mkdir -p %t/Frameworks/MyFramework.framework/Headers
+// RUN: cp %t/MyFramework.h %t/Frameworks/MyFramework.framework/Headers/
+// RUN: cp %t/MyHeader.h %t/Frameworks/MyFramework.framework/Headers/
+
+// RUN: sed -e "s@SRCROOT@%{/t:regex_replacement}@g" \
+// RUN: %t/reference.output.json.in >> %t/reference.output.json
+
+// Headermap maps headers to the source root SRCROOT
+// RUN: sed -e "s@SRCROOT@%{/t:regex_replacement}@g" \
+// RUN: %t/headermap.hmap.json.in >> %t/headermap.hmap.json
+// RUN: %hmaptool write %t/headermap.hmap.json %t/headermap.hmap
+
+// Input headers use paths to the framework root/DSTROOT
+// RUN: %clang -extract-api --product-name=MyFramework -target arm64-apple-macosx \
+// RUN: -I%t/headermap.hmap -F%t/Frameworks \
+// RUN: %t/Frameworks/MyFramework.framework/Headers/MyFramework.h \
+// RUN: %t/Frameworks/MyFramework.framework/Headers/MyHeader.h \
+// RUN: -o %t/output.json | FileCheck -allow-empty %s
+
+// Generator version is not consistent across test runs, normalize it.
+// RUN: sed -e "s@\"generator\": \".*\"@\"generator\": \"?\"@g" \
+// RUN: %t/output.json >> %t/output-normalized.json
+// RUN: diff %t/reference.output.json %t/output-normalized.json
+
+// CHECK-NOT: error:
+// CHECK-NOT: warning:
+
+//--- headermap.hmap.json.in
+{
+  "mappings" :
+{
+ "MyFramework/MyHeader.h" : "SRCROOT/MyHeader.h"
+}
+}
+
+//--- MyFramework.h
+// Umbrella for MyFramework
+#import 
+
+//--- MyHeader.h
+#import 
+int MyInt;
+
+//--- Frameworks/OtherFramework.framework/Headers/OtherHeader.h
+int OtherInt;
+
+//--- reference.output.json.in
+{
+  "metadata": {
+"formatVersion": {
+  "major": 0,
+  "minor": 5,
+  "patch": 3
+},
+"generator": "?"
+  },
+  "module": {
+"name": "MyFramework",
+"platform": {
+  "architecture": "arm64",
+  "operatingSystem": {
+"minimumVersion": {
+  "major": 11,
+  "minor": 0,
+  "patch": 0
+},
+"name": "macosx"
+  },
+  "vendor": "apple"
+}
+  },
+  "relationships": [],
+  "symbols": [
+{
+  "accessLevel": "public",
+  "declarationFragments": [
+{
+  "kind": "typeIdentifier",
+  "preciseIdentifier": "c:I",
+  "spelling": "int"
+},
+{
+  "kind": "text",
+  "spelling": " "
+},
+{
+  "kind": "identifier",
+  "spelling": "MyInt"
+}
+  ],
+  "identifier": {
+"interfaceLanguage": "c",
+"precise": "c:@MyInt"
+  },
+  "kind": {
+"displayName": "Global Variable",
+"identifier": "c.var"
+  },
+  "location": {
+"position": {
+  "character": 5,
+  "line": 2
+},
+"uri": "file://SRCROOT/MyHeader.h"
+  },
+  "names": {
+"navigator": [
+  {
+"kind": "identifier",
+"spelling": "MyInt"
+  }
+],
+"subHeading": [
+  {
+"kind": "identifier",
+"spelling": "MyInt"
+  }
+],
+"title": "MyInt"
+  },
+  "pathComponents": [
+"MyInt"
+  ]
+}
+  ]
+}
Index: clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
===
--- clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
+++ clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
@@ -38,7 +38,10 @@
 #include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallVector.h"
+#include "llvm/Support/FileSystem.h"
 #include "llvm/Support/MemoryBuffer.h"
+#include "llvm/Support/Path.h"
+#include "llvm/Support/Regex.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
 #include 
@@ -55,10 +58,128 @@
   return {};
 }
 
+Optional getRelativeIncludeName(const CompilerInstance &CI,
+ StringRef File) {
+  using namespace llvm::sys;
+  // Matches framework include patterns
+  const llvm::Regex Rule("/(.+)\\.framework/(.+)?Headers/(.+)");
+
+  // FIXME: WorkingDir might not be set at this point.
+  StringRef WorkingDir = CI.getFileSystemOpts().WorkingDir;
+
+  SmallString<128> FilePath(Fi

[PATCH] D122920: [Clang][CodeGen]Fix __builtin_dump_struct missing record type field name

[Andy Soffer via Phabricator via cfe-commits]

asoffer added a comment.

In D122920#3471865 , @yihanaa wrote:

> In D122920#3471654 , @erichkeane 
> wrote:
>
>> @yihanaa : I'd suggest seeing the conversation that @rsmith @aaron.ballman 
>> and I are having about this builtin here: https://reviews.llvm.org/D124221
>>
>> In general it looks like the three of us think that this builtin needs an 
>> overhaul in implementation/functionality in order to be further useful. 
>> While we very much appreciate your attempts to try to improve it, we believe 
>> there needs to be larger-scale changes.
>
> Thanks for your reply, I would like to get involved and help if needed

While I eagerly await `__builtin_reflect_struct`, this change still provides 
significant value in fixing a regression with `__builtin_dump_struct`. Should 
we proceed with this change and that proposal independently?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122920

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

[clang] 9727c77 - [NFC] Rename Instrinsic to Intrinsic

[David Green via cfe-commits]

Author: David Green
Date: 2022-04-25T18:13:23+01:00
New Revision: 9727c77d58ac920a4158d08c15659470e52ddda4

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

LOG: [NFC] Rename Instrinsic to Intrinsic

Added: 


Modified: 
clang/lib/CodeGen/CGBuiltin.cpp
clang/test/CodeGen/builtins-nvptx-mma.py
clang/test/CodeGenCUDA/fp-contract.cu
clang/test/Profile/c-avoid-direct-call.c
clang/test/Profile/c-indirect-call.c
clang/test/Profile/cxx-indirect-call.cpp
llvm/include/llvm/Analysis/VectorUtils.h
llvm/include/llvm/CodeGen/MachineInstr.h
llvm/include/llvm/CodeGen/ReplaceWithVeclib.h
llvm/include/llvm/IR/InstVisitor.h
llvm/include/llvm/IR/IntrinsicsARM.td
llvm/include/llvm/IR/Metadata.h
llvm/include/llvm/Transforms/Scalar/ScalarizeMaskedMemIntrin.h
llvm/include/llvm/Transforms/Utils/Local.h
llvm/lib/Analysis/CallGraphSCCPass.cpp
llvm/lib/Analysis/ConstantFolding.cpp
llvm/lib/Analysis/IVDescriptors.cpp
llvm/lib/Analysis/VectorUtils.cpp
llvm/lib/CodeGen/ReplaceWithVeclib.cpp
llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
llvm/lib/CodeGen/SjLjEHPrepare.cpp
llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
llvm/lib/Target/AArch64/AArch64InstrInfo.td
llvm/lib/Target/AArch64/AArch64StackTagging.cpp
llvm/lib/Target/BPF/BPFAbstractMemberAccess.cpp
llvm/lib/Target/Mips/MipsISelLowering.h
llvm/lib/Target/NVPTX/NVPTXIntrinsics.td
llvm/lib/Target/NVPTX/NVPTXTargetTransformInfo.cpp
llvm/lib/Target/PowerPC/README_P9.txt
llvm/lib/Target/X86/X86LowerAMXType.cpp
llvm/lib/Transforms/IPO/GlobalOpt.cpp
llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp
llvm/lib/Transforms/Scalar/LoopIdiomRecognize.cpp
llvm/lib/Transforms/Scalar/ScalarizeMaskedMemIntrin.cpp
llvm/lib/Transforms/Scalar/Scalarizer.cpp
llvm/lib/Transforms/Scalar/SpeculativeExecution.cpp
llvm/lib/Transforms/Utils/Local.cpp
llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp
llvm/lib/Transforms/Utils/RelLookupTableConverter.cpp
llvm/lib/Transforms/Utils/SimplifyCFG.cpp
llvm/lib/Transforms/Utils/StripGCRelocates.cpp
llvm/lib/Transforms/Vectorize/LoopVectorizationLegality.cpp
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
llvm/test/CodeGen/Hexagon/hvx-byte-store-double.ll
llvm/test/DebugInfo/WebAssembly/dbg-declare.ll
llvm/test/Instrumentation/DataFlowSanitizer/unordered_atomic_mem_intrins.ll
llvm/test/Instrumentation/MemorySanitizer/msan_basic.ll

llvm/test/Transforms/FunctionSpecialization/function-specialization-nodup2.ll
llvm/test/Transforms/Inline/inline_constprop.ll
llvm/test/Transforms/InstCombine/stacksave-debuginfo.ll
llvm/test/Transforms/SROA/basictest-opaque-ptrs.ll
llvm/test/Transforms/SROA/basictest.ll
llvm/unittests/Analysis/IRSimilarityIdentifierTest.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index fc2d32f3e26fe..f9966c1fd777c 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -18200,7 +18200,7 @@ RValue CodeGenFunction::EmitBuiltinIsAligned(const 
CallExpr *E) {
 
 /// Generate (x & ~(y-1)) to align down or ((x+(y-1)) & ~(y-1)) to align up.
 /// Note: For pointer types we can avoid ptrtoint/inttoptr pairs by using the
-/// llvm.ptrmask instrinsic (with a GEP before in the align_up case).
+/// llvm.ptrmask intrinsic (with a GEP before in the align_up case).
 /// TODO: actually use ptrmask once most optimization passes know about it.
 RValue CodeGenFunction::EmitBuiltinAlignTo(const CallExpr *E, bool AlignUp) {
   BuiltinAlignArgs Args(E, *this);

diff  --git a/clang/test/CodeGen/builtins-nvptx-mma.py 
b/clang/test/CodeGen/builtins-nvptx-mma.py
index dc40f04c11ce6..6c09910020278 100644
--- a/clang/test/CodeGen/builtins-nvptx-mma.py
+++ b/clang/test/CodeGen/builtins-nvptx-mma.py
@@ -1,5 +1,5 @@
 # This script generates all variants of wmma builtins, verifies that clang 
calls
-# correct LLVM instrinsics, and checks that availability of specific builtins 
is
+# correct LLVM intrinsics, and checks that availability of specific builtins is
 # constrained by the correct PTX version and the target GPU variant.
 
 # Dummy test run to avoid lit warnings.

diff  --git a/clang/test/CodeGenCUDA/fp-contract.cu 
b/clang/test/CodeGenCUDA/fp-contract.cu
index d466affded132..60824ba59ddfb 100644
--- a/clang/test/CodeGenCUDA/fp-contract.cu
+++ b/clang/test/CodeGenCUDA/fp-contract.cu
@@ -105,7 +105,7 @@
 
 // Explicit -ffp-contract=on -- fusing by front-end.
 // In IR,
-//mult/add in the same statement - llvm.fmuladd instrinsic emitted
+//mult/add in the same statement - llvm.fmuladd intrinsic emitt

[PATCH] D124026: [Headers][MSVC] Define wchar_t in stddef.h like MSVC if not using the builtin type

[Eli Friedman via Phabricator via cfe-commits]

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124026

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

[PATCH] D124250: [Serialization] write expr dependence bits as a single integer

[Jake Egan via Phabricator via cfe-commits]

Jake-Egan added a comment.

Thanks @sammccall, the test is passing now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124250

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

[PATCH] D124262: compile commands header to source heuristic lower-cases filenames before inferring file types

[Ishaan Gandhi via Phabricator via cfe-commits]

ishaangandhi added a comment.

In D124262#3472079 , @sammccall wrote:

> Thanks!
> I can land this for you if you don't have commit access - can you provide the 
> name/email to use for the commit?

Thank you!

Ishaan Gandhi
ishaangan...@gmail.com


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

https://reviews.llvm.org/D124262

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

[PATCH] D124063: [LegacyPM] Rename and deprecate populateModulePassManager

[Arthur Eubanks via Phabricator via cfe-commits]

aeubanks added a comment.

I'd first fix up as many in-tree users as nikic pointed out

(I'll work on bugpoint soonish since that requires a bit more work)




Comment at: llvm/include/llvm-c/Transforms/PassManagerBuilder.h:72
+#ifdef __GNUC__
+__attribute__((deprecated("Migrate to new pass manager for optimization 
pipeline. This header will be removed soon.")))
+#endif

can we use `llvm/include/llvm-c/Deprecated.h` for the C API here? looks like we 
only have on in-tree user in 
`llvm/unittests/ExecutionEngine/MCJIT/MCJITCAPITest.cpp` that we should be able 
to clean up


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124063

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

[PATCH] D124186: [RISCV] Fix incorrect policy implement for unmasked vslidedown and vslideup.

[Zakk Chen 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 rGffe03ff75c26: [RISCV] Fix incorrect policy implement for 
unmasked vslidedown and vslideup. (authored by khchen).

Changed prior to commit:
  https://reviews.llvm.org/D124186?vs=424517&id=424934#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124186

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vslidedown.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vslideup.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vslidedown.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vslideup.c
  llvm/include/llvm/IR/IntrinsicsRISCV.td
  llvm/lib/Target/RISCV/RISCVInstrInfoVPseudos.td
  llvm/lib/Target/RISCV/RISCVInstrInfoVVLPatterns.td
  llvm/test/CodeGen/RISCV/rvv/emergency-slot.mir
  llvm/test/CodeGen/RISCV/rvv/extract-subvector.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-calling-conv.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-extload-truncstore.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-extract-subvector.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp-buildvec.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp-conv.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp-setcc.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp-shuffles.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp2i.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-i2fp.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-insert-i1.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-insert-subvector.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-insert.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-int-buildvec.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-int-exttrunc.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-int-shuffles.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-int.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-mask-buildvec.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-mask-load-store.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-mask-splat.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-masked-gather.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-unaligned.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-vpgather.ll
  llvm/test/CodeGen/RISCV/rvv/insert-subvector.ll
  llvm/test/CodeGen/RISCV/rvv/insertelt-fp-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/insertelt-fp-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/insertelt-i1.ll
  llvm/test/CodeGen/RISCV/rvv/insertelt-int-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/insertelt-int-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/masked-tama.ll
  llvm/test/CodeGen/RISCV/rvv/setcc-fp.ll
  llvm/test/CodeGen/RISCV/rvv/setcc-integer.ll
  llvm/test/CodeGen/RISCV/rvv/unmasked-ta.ll
  llvm/test/CodeGen/RISCV/rvv/vector-splice.ll
  llvm/test/CodeGen/RISCV/rvv/vslidedown-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vslidedown-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vslideup-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vslideup-rv64.ll

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

[PATCH] D121299: [NVPTX] Disable DWARF .file directory for PTX

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

I'm okay with doing it this way.  My impression over the years (as a debug-info 
guy, not as a ptxas user) is that ptxas evolves slowly and this is not really 
"busy work."


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121299

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

[PATCH] D124395: [clang][dataflow] Optimize flow condition representation

[Stanislav Gatev via Phabricator via cfe-commits]

sgatev updated this revision to Diff 424930.
sgatev added a comment.

Mark methods as const.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124395

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h
  clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
  clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp

Index: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
===
--- clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -76,33 +76,14 @@
   Environment &MergedEnv,
   Environment::ValueModel &Model) {
   // Join distinct boolean values preserving information about the constraints
-  // in the respective path conditions. Note: this construction can, in
-  // principle, result in exponential growth in the size of boolean values.
-  // Potential optimizations may be worth considering. For example, represent
-  // the flow condition of each environment using a bool atom and store, in
-  // `DataflowAnalysisContext`, a mapping of bi-conditionals between flow
-  // condition atoms and flow condition constraints. Something like:
-  // \code
-  //   FC1 <=> C1 ^ C2
-  //   FC2 <=> C2 ^ C3 ^ C4
-  //   FC3 <=> (FC1 v FC2) ^ C5
-  // \code
-  // Then, we can track dependencies between flow conditions (e.g. above `FC3`
-  // depends on `FC1` and `FC2`) and modify `flowConditionImplies` to construct
-  // a formula that includes the bi-conditionals for all flow condition atoms in
-  // the transitive set, before invoking the solver.
+  // in the respective path conditions.
   //
   // FIXME: Does not work for backedges, since the two (or more) paths will not
   // have mutually exclusive conditions.
   if (auto *Expr1 = dyn_cast(Val1)) {
-for (BoolValue *Constraint : Env1.getFlowConditionConstraints()) {
-  Expr1 = &MergedEnv.makeAnd(*Expr1, *Constraint);
-}
 auto *Expr2 = cast(Val2);
-for (BoolValue *Constraint : Env2.getFlowConditionConstraints()) {
-  Expr2 = &MergedEnv.makeAnd(*Expr2, *Constraint);
-}
-return &MergedEnv.makeOr(*Expr1, *Expr2);
+return &Env1.makeOr(Env1.makeAnd(Env1.getFlowConditionToken(), *Expr1),
+Env1.makeAnd(Env2.getFlowConditionToken(), *Expr2));
   }
 
   // FIXME: Consider destroying `MergedValue` immediately if `ValueModel::merge`
@@ -156,63 +137,6 @@
   }
 }
 
-/// Returns constraints that represent the disjunction of `Constraints1` and
-/// `Constraints2`.
-///
-/// Requirements:
-///
-///  The elements of `Constraints1` and `Constraints2` must not be null.
-llvm::DenseSet
-joinConstraints(DataflowAnalysisContext *Context,
-const llvm::DenseSet &Constraints1,
-const llvm::DenseSet &Constraints2) {
-  // `(X ^ Y) v (X ^ Z)` is logically equivalent to `X ^ (Y v Z)`. Therefore, to
-  // avoid unnecessarily expanding the resulting set of constraints, we will add
-  // all common constraints of `Constraints1` and `Constraints2` directly and
-  // add a disjunction of the constraints that are not common.
-
-  llvm::DenseSet JoinedConstraints;
-
-  if (Constraints1.empty() || Constraints2.empty()) {
-// Disjunction of empty set and non-empty set is represented as empty set.
-return JoinedConstraints;
-  }
-
-  BoolValue *Val1 = nullptr;
-  for (BoolValue *Constraint : Constraints1) {
-if (Constraints2.contains(Constraint)) {
-  // Add common constraints directly to `JoinedConstraints`.
-  JoinedConstraints.insert(Constraint);
-} else if (Val1 == nullptr) {
-  Val1 = Constraint;
-} else {
-  Val1 = &Context->getOrCreateConjunctionValue(*Val1, *Constraint);
-}
-  }
-
-  BoolValue *Val2 = nullptr;
-  for (BoolValue *Constraint : Constraints2) {
-// Common constraints are added to `JoinedConstraints` above.
-if (Constraints1.contains(Constraint)) {
-  continue;
-}
-if (Val2 == nullptr) {
-  Val2 = Constraint;
-} else {
-  Val2 = &Context->getOrCreateConjunctionValue(*Val2, *Constraint);
-}
-  }
-
-  // An empty set of constraints (represented as a null value) is interpreted as
-  // `true` and `true v X` is logically equivalent to `true` so we need to add a
-  // constraint only if both `Val1` and `Val2` are not null.
-  if (Val1 != nullptr && Val2 != nullptr)
-JoinedConstraints.insert(
-&Context->getOrCreateDisjunctionValue(*Val1, *Val2));
-
-  return JoinedConstraints;
-}
-
 static void
 getFieldsFromClassHierarchy(QualType Type, bool IgnorePrivateFields,
 llvm::DenseSet &Fields) {
@@ -249,6 +173,26 @@
   return Fields;
 }
 
+Environment::Environment(DataflowAnalysisContext &DACtx)
+: DACtx(&DACtx)

[PATCH] D124262: compile commands header to source heuristic lower-cases filenames before inferring file types

[Sam McCall via Phabricator via cfe-commits]

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

Thanks!
I can land this for you if you don't have commit access - can you provide the 
name/email to use for the commit?


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

https://reviews.llvm.org/D124262

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

[PATCH] D124221: Add new builtin __builtin_reflect_struct.

[Wang Yihan via Phabricator via cfe-commits]

yihanaa added a comment.

Thank you for inviting me to a discussion on this topic. I have something very 
confusing as follows:

- If the developer already knows all fields info in some struct, wyh doesn't he 
write a simple function to do the printing(like: print_struct_foo(const struct 
foo *); )? It might be easier to write a printing  function.
- If the struct has many levels of nesting, and the developers just want to 
output the details of the struct for debugging purposes, then I think they 
might just need something like the 'p' command in LLDB.
- If we want to support these printing functions, and make this builtin 
flexible and general, I think reflection is a good idea. But we may want to 
make this builtin support C/C++ or other languages supported by Clang at the 
same time. I have a not-so-sophisticated (perhaps silly-sounding) idea: this 
builtin might be one or more C-style functions in order to be usable in many 
different languages. This family of functions supports getting the number of 
struct fields, as well as their details (and possibly getting the value of the 
field by getting the subscript). like:

  int __builtin_reflect_struct_member_count(const void *struct_addr, unsigned 
*count);
  int __builtin_reflect_struct_member_detail(const void *struct_addr, unsigned 
index, char *name, unsigned *bitfield, int *is_unnamed);
  int __builtin_reflect_struct_member_ptr(const void *struct_addr, unsigned 
index, void **ptr);

Maybe it also can support nested struct?

em, my idea looks really stupid, don't laugh at me, hahahaha~~~


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124221

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

[PATCH] D124396: [HIP] Fix diag msg about sanitizer

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added a reviewer: tra.
Herald added subscribers: kerbowa, jvesely.
Herald added a project: All.
yaxunl requested review of this revision.

Fix the misleading diag msg as the option is ignored for a particular offload 
arch only.


https://reviews.llvm.org/D124396

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/test/Driver/hip-sanitize-options.hip
  clang/test/Driver/openmp-amdgpu-sanitize-options.c


Index: clang/test/Driver/openmp-amdgpu-sanitize-options.c
===
--- clang/test/Driver/openmp-amdgpu-sanitize-options.c
+++ clang/test/Driver/openmp-amdgpu-sanitize-options.c
@@ -32,8 +32,8 @@
 // RUN:   %clang -### -fopenmp --offload-arch=gfx908:xnack- -fsanitize=address 
-fno-gpu-sanitize  %s 2>&1 \
 // RUN:   | FileCheck -check-prefixes=NOGPUSAN,XNACKNEG %s
 
-// XNACK-DAG: warning: ignoring '-fsanitize=address' option as it is not 
currently supported for offload arch 'gfx908:xnack-'. Use it with an offload 
arch containing 'xnack+' instead
-// XNACKNONE-DAG: warning: ignoring '-fsanitize=address' option as it is not 
currently supported for offload arch 'gfx908'. Use it with an offload arch 
containing 'xnack+' instead
+// XNACK-DAG: warning: ignoring '-fsanitize=address' option for offload arch 
'gfx908:xnack-' as it is not currently supported for that offload arch. Use it 
with an offload arch containing 'xnack+' instead
+// XNACKNONE-DAG: warning: ignoring '-fsanitize=address' option for offload 
arch 'gfx908' as it is not currently supported for that offload arch. Use it 
with an offload arch containing 'xnack+' instead
 
 // GPUSAN: clang{{.*}}"-cc1" "-triple" 
"x86_64-unknown-linux-gnu"{{.*}}"-fopenmp"{{.*}}"-fsanitize=address"{{.*}}"-fopenmp-targets=amdgcn-amd-amdhsa"{{.*}}"-x"
 "c"{{.*}}
 // GPUSAN: clang{{.*}}"-cc1" "-triple" 
"x86_64-unknown-linux-gnu"{{.*}}"-fopenmp"{{.*}}"-fsanitize=address"{{.*}}"-fopenmp-targets=amdgcn-amd-amdhsa"{{.*}}"-x"
 "ir"{{.*}}
Index: clang/test/Driver/hip-sanitize-options.hip
===
--- clang/test/Driver/hip-sanitize-options.hip
+++ clang/test/Driver/hip-sanitize-options.hip
@@ -65,8 +65,8 @@
 // FAIL: error: AMDGPU address sanitizer runtime library (asanrtl) not found. 
Please install ROCm device library which supports address sanitizer
 
 // XNACK-DAG: warning: ignoring '-fsanitize=leak' option as it is not 
currently supported for target 'amdgcn-amd-amdhsa'
-// XNACK-DAG: warning: ignoring '-fsanitize=address' option as it is not 
currently supported for offload arch 'gfx900:xnack-'. Use it with an offload 
arch containing 'xnack+' instead
-// XNACK-DAG: warning: ignoring '-fsanitize=address' option as it is not 
currently supported for offload arch 'gfx906'. Use it with an offload arch 
containing 'xnack+' instead
+// XNACK-DAG: warning: ignoring '-fsanitize=address' option for offload arch 
'gfx900:xnack-' as it is not currently supported for that offload arch. Use it 
with an offload arch containing 'xnack+' instead
+// XNACK-DAG: warning: ignoring '-fsanitize=address' option for offload arch 
'gfx906' as it is not currently supported for that offload arch. Use it with an 
offload arch containing 'xnack+' instead
 // XNACK-DAG: {{"[^"]*clang[^"]*".* "-mlink-bitcode-file" ".*asanrtl.bc".* 
"-target-cpu" "gfx900".* "-target-feature" "\+xnack".* "-fsanitize=address"}}
 // XNACK-DAG: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* "-target-feature" 
"-xnack"}}
 // XNACK-DAG: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx906"}}
@@ -85,8 +85,8 @@
 // NOGPU-DAG: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx906"}}
 // NOGPU-DAG: {{"[^"]*clang[^"]*".* "-triple" "x86_64-unknown-linux-gnu".* 
"-fsanitize=address,leak"}}
 // NOGPUNEG-NOT: warning: ignoring '-fsanitize=leak' option as it is not 
currently supported for target 'amdgcn-amd-amdhsa'
-// NOGPUNEG-NOT: warning: ignoring '-fsanitize=address' option as it is not 
currently supported for offload arch 'gfx900:xnack-'. Use it with an offload 
arch containing 'xnack+' instead
-// NOGPUNEG-NOT: warning: ignoring '-fsanitize=address' option as it is not 
currently supported for offload arch 'gfx906'. Use it with an offload arch 
containing 'xnack+' instead
+// NOGPUNEG-NOT: warning: ignoring '-fsanitize=address' option for offload 
arch 'gfx900:xnack-' as it is not currently supported for that offload arch. 
Use it with an offload arch containing 'xnack+' instead
+// NOGPUNEG-NOT: warning: ignoring '-fsanitize=address' option for offload 
arch 'gfx906' as it is not currently supported for that offload arch. Use it 
with an offload arch containing 'xnack+' instead
 // NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-mlink-bitcode-file" ".*asanrtl.bc".* 
"-target-cpu" "gfx900".* "-target-feature" "\+xnack".* "-fsanitize=address"}}
 // NOGPUNEG-NOT: {{"[^"]*clang[^"]*".* "-target-cpu" "gfx900".* 
"-target-feature" "\+xnack".* "-fsanitize=address,leak"}}
 // NOGPUNEG-NO

[PATCH] D121299: [NVPTX] Disable DWARF .file directory for PTX

[Andrew Savonichev via Phabricator via cfe-commits]

asavonic added a comment.

I'm going to merge the patch in a couple of days, unless anyone has a strong 
opinion against it.
Alternative options:

- revert this default back to false (not great for other targets)
- add a check for `Triple == NVPTX` directly to llc (tools other than llc will 
have to replicate the same logic)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121299

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

[PATCH] D124395: [clang][dataflow] Optimize flow condition representation

[Stanislav Gatev via Phabricator via cfe-commits]

sgatev created this revision.
sgatev added reviewers: ymandel, xazax.hun, gribozavr2.
Herald added subscribers: tschuett, steakhal, rnkovacs.
Herald added a project: All.
sgatev requested review of this revision.
Herald added a project: clang.

Represent flow conditions as Token <=> Constraints biconditional clauses
in order to make joining of distinct values more efficient. For example,
joining distinct values while preserving flow condition information can
be implemented by adding the tokens of the flow conditions to the formula:
`makeOr(makeAnd(FC1, Val1), makeAnd(FC2, Val2))`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D124395

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h
  clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
  clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp

Index: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
===
--- clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -76,33 +76,14 @@
   Environment &MergedEnv,
   Environment::ValueModel &Model) {
   // Join distinct boolean values preserving information about the constraints
-  // in the respective path conditions. Note: this construction can, in
-  // principle, result in exponential growth in the size of boolean values.
-  // Potential optimizations may be worth considering. For example, represent
-  // the flow condition of each environment using a bool atom and store, in
-  // `DataflowAnalysisContext`, a mapping of bi-conditionals between flow
-  // condition atoms and flow condition constraints. Something like:
-  // \code
-  //   FC1 <=> C1 ^ C2
-  //   FC2 <=> C2 ^ C3 ^ C4
-  //   FC3 <=> (FC1 v FC2) ^ C5
-  // \code
-  // Then, we can track dependencies between flow conditions (e.g. above `FC3`
-  // depends on `FC1` and `FC2`) and modify `flowConditionImplies` to construct
-  // a formula that includes the bi-conditionals for all flow condition atoms in
-  // the transitive set, before invoking the solver.
+  // in the respective path conditions.
   //
   // FIXME: Does not work for backedges, since the two (or more) paths will not
   // have mutually exclusive conditions.
   if (auto *Expr1 = dyn_cast(Val1)) {
-for (BoolValue *Constraint : Env1.getFlowConditionConstraints()) {
-  Expr1 = &MergedEnv.makeAnd(*Expr1, *Constraint);
-}
 auto *Expr2 = cast(Val2);
-for (BoolValue *Constraint : Env2.getFlowConditionConstraints()) {
-  Expr2 = &MergedEnv.makeAnd(*Expr2, *Constraint);
-}
-return &MergedEnv.makeOr(*Expr1, *Expr2);
+return &Env1.makeOr(Env1.makeAnd(Env1.getFlowConditionToken(), *Expr1),
+Env1.makeAnd(Env2.getFlowConditionToken(), *Expr2));
   }
 
   // FIXME: Consider destroying `MergedValue` immediately if `ValueModel::merge`
@@ -156,63 +137,6 @@
   }
 }
 
-/// Returns constraints that represent the disjunction of `Constraints1` and
-/// `Constraints2`.
-///
-/// Requirements:
-///
-///  The elements of `Constraints1` and `Constraints2` must not be null.
-llvm::DenseSet
-joinConstraints(DataflowAnalysisContext *Context,
-const llvm::DenseSet &Constraints1,
-const llvm::DenseSet &Constraints2) {
-  // `(X ^ Y) v (X ^ Z)` is logically equivalent to `X ^ (Y v Z)`. Therefore, to
-  // avoid unnecessarily expanding the resulting set of constraints, we will add
-  // all common constraints of `Constraints1` and `Constraints2` directly and
-  // add a disjunction of the constraints that are not common.
-
-  llvm::DenseSet JoinedConstraints;
-
-  if (Constraints1.empty() || Constraints2.empty()) {
-// Disjunction of empty set and non-empty set is represented as empty set.
-return JoinedConstraints;
-  }
-
-  BoolValue *Val1 = nullptr;
-  for (BoolValue *Constraint : Constraints1) {
-if (Constraints2.contains(Constraint)) {
-  // Add common constraints directly to `JoinedConstraints`.
-  JoinedConstraints.insert(Constraint);
-} else if (Val1 == nullptr) {
-  Val1 = Constraint;
-} else {
-  Val1 = &Context->getOrCreateConjunctionValue(*Val1, *Constraint);
-}
-  }
-
-  BoolValue *Val2 = nullptr;
-  for (BoolValue *Constraint : Constraints2) {
-// Common constraints are added to `JoinedConstraints` above.
-if (Constraints1.contains(Constraint)) {
-  continue;
-}
-if (Val2 == nullptr) {
-  Val2 = Constraint;
-} else {
-  Val2 = &Context->getOrCreateConjunctionValue(*Val2, *Constraint);
-}
-  }
-
-  // An empty set of constraints (represented as a null value) is interpreted as
-  // `true` and `true v X` is logically equivalent to `true` so we need to add a
-  // constraint only if both `Val1` and `Val2` are not null.
-  if

[PATCH] D124250: [Serialization] write expr dependence bits as a single integer

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

1c65c734c93f8c4d39947e596d7fe89289ce283d 
 will 
clear the PCH file. If this
doesn't fix the problem I'll revert.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124250

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

[clang] 1c65c73 - Clear temporary file in test, buildbot appears to be reusing an old one.

[Sam McCall via cfe-commits]

Author: Sam McCall
Date: 2022-04-25T17:26:39+02:00
New Revision: 1c65c734c93f8c4d39947e596d7fe89289ce283d

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

LOG: Clear temporary file in test, buildbot appears to be reusing an old one.

https://lab.llvm.org/buildbot/#/builders/214/builds/903/steps/6/logs/FAIL__Clang__pch-with-module_m

Added: 


Modified: 
clang/test/Index/pch-with-module.m

Removed: 




diff  --git a/clang/test/Index/pch-with-module.m 
b/clang/test/Index/pch-with-module.m
index 77262d5eb6d1f..9acd9694830bd 100644
--- a/clang/test/Index/pch-with-module.m
+++ b/clang/test/Index/pch-with-module.m
@@ -1,5 +1,6 @@
 // REQUIRES: x86-registered-target
 // RUN: rm -rf %t.cache
+// RUN: rm -rf %t.h.pch
 // RUN: c-index-test -write-pch %t.h.pch %s -target x86_64-apple-macosx10.7 
-fobjc-arc -fmodules-cache-path=%t.cache -fmodules -F %S/../Modules/Inputs 
-Xclang -fdisable-module-hash
 // RUN: %clang -fsyntax-only %s -target x86_64-apple-macosx10.7 -include %t.h 
-fobjc-arc -fmodules-cache-path=%t.cache -fmodules -F %S/../Modules/Inputs \
 // RUN:  -Xclang -fdisable-module-hash -Xclang 
-detailed-preprocessing-record -Xclang -verify



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

Re: [PATCH] D124250: [Serialization] write expr dependence bits as a single integer

[Sam McCall via cfe-commits]

Hi Jake,

I suspect something about the test/runner is nonhermetic, I'm going to try
to fix it in the test.

This commit changes the serialized PCH format.
It looks like this test is not properly hermetic, and is trying to load the
PCH from a previous run of the test. It clears the module dir, but not the
PCH itself.
This would normally trigger a version mismatch error, but the test disables
it with -fdisable-module-hash for some reason.

Only mystery is why the c-index-test line doesn't fail if it doesn't manage
to overwrite the PCH file.

On Mon, Apr 25, 2022 at 4:59 PM Jake Egan via Phabricator <
revi...@reviews.llvm.org> wrote:

> Jake-Egan added a comment.
>
> Hi, this broke a test on AIX
> https://lab.llvm.org/buildbot/#/builders/214/builds/903/steps/6/logs/FAIL__Clang__pch-with-module_m
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D124250/new/
>
> https://reviews.llvm.org/D124250
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D122663: Mark identifier prefixes as substitutable

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D122663#3471960 , @hvdijk wrote:

> In D122663#3471866 , @erichkeane 
> wrote:
>
>> This actually wouldn't be necessary in this case: cxxfilt is already 
>> 'right', this is just for humans to be able to see "we changed this from 
>> mangling as  to ".
>
> That's a good point. We do have tests in clang that use llvm-cxxfilt already 
> (the PPC intrinsic tests) so there should be no problem with it as a 
> dependency; I think once this is in I might submit that as a follow-up change 
> for review unless someone else beats me to it.

Any amount of test cleanup in that direction would be greatly appreciated!  
Even as NFC.

The test I did it for was CodeGenCXX/mangle-nttp-anon-union.cpp as an example 
of what I'm talking about.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122663

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

[PATCH] D122663: Mark identifier prefixes as substitutable

[Harald van Dijk via Phabricator via cfe-commits]

hvdijk added a comment.

In D122663#3471866 , @erichkeane 
wrote:

> This actually wouldn't be necessary in this case: cxxfilt is already 'right', 
> this is just for humans to be able to see "we changed this from mangling as 
>  to ".

That's a good point. We do have tests in clang that use llvm-cxxfilt already 
(the PPC intrinsic tests) so there should be no problem with it as a 
dependency; I think once this is in I might submit that as a follow-up change 
for review unless someone else beats me to it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122663

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

[PATCH] D124104: [clang][dataflow] Fix `Environment::join`'s handling of flow condition merging

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
ymandel marked an inline comment as done.
Closed by commit rG37b4782e3e53: [clang][dataflow] Fix 
`Environment::join`'s handling of flow-condition merging. (authored by 
ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124104

Files:
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
  clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
@@ -10,6 +10,7 @@
 #include "TestingSupport.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/ExprCXX.h"
+#include "clang/AST/Type.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Analysis/CFG.h"
@@ -295,6 +296,164 @@
   // FIXME: Called functions at point `p` should contain only "foo".
 }
 
+// Models an analysis that uses flow conditions.
+class SpecialBoolAnalysis
+: public DataflowAnalysis {
+public:
+  explicit SpecialBoolAnalysis(ASTContext &Context)
+  : DataflowAnalysis(Context) {}
+
+  static NoopLattice initialElement() { return {}; }
+
+  void transfer(const Stmt *S, NoopLattice &, Environment &Env) {
+auto SpecialBoolRecordDecl = recordDecl(hasName("SpecialBool"));
+auto HasSpecialBoolType = hasType(SpecialBoolRecordDecl);
+
+if (const auto *E = selectFirst(
+"call", match(cxxConstructExpr(HasSpecialBoolType).bind("call"), *S,
+  getASTContext( {
+  auto &ConstructorVal = *cast(Env.createValue(E->getType()));
+  ConstructorVal.setProperty("is_set", Env.getBoolLiteralValue(false));
+  Env.setValue(*Env.getStorageLocation(*E, SkipPast::None), ConstructorVal);
+} else if (const auto *E = selectFirst(
+   "call", match(cxxMemberCallExpr(callee(cxxMethodDecl(ofClass(
+   SpecialBoolRecordDecl
+ .bind("call"),
+ *S, getASTContext( {
+  auto *Object = E->getImplicitObjectArgument();
+  assert(Object != nullptr);
+
+  auto *ObjectLoc =
+  Env.getStorageLocation(*Object, SkipPast::ReferenceThenPointer);
+  assert(ObjectLoc != nullptr);
+
+  auto &ConstructorVal =
+  *cast(Env.createValue(Object->getType()));
+  ConstructorVal.setProperty("is_set", Env.getBoolLiteralValue(true));
+  Env.setValue(*ObjectLoc, ConstructorVal);
+}
+  }
+
+  bool compareEquivalent(QualType Type, const Value &Val1,
+ const Environment &Env1, const Value &Val2,
+ const Environment &Env2) final {
+const auto *Decl = Type->getAsCXXRecordDecl();
+if (Decl == nullptr || Decl->getIdentifier() == nullptr ||
+Decl->getName() != "SpecialBool")
+  return false;
+
+auto *IsSet1 = cast_or_null(
+cast(&Val1)->getProperty("is_set"));
+if (IsSet1 == nullptr)
+  return true;
+
+auto *IsSet2 = cast_or_null(
+cast(&Val2)->getProperty("is_set"));
+if (IsSet2 == nullptr)
+  return false;
+
+return Env1.flowConditionImplies(*IsSet1) ==
+   Env2.flowConditionImplies(*IsSet2);
+  }
+
+  // Always returns `true` to accept the `MergedVal`.
+  bool merge(QualType Type, const Value &Val1, const Environment &Env1,
+ const Value &Val2, const Environment &Env2, Value &MergedVal,
+ Environment &MergedEnv) final {
+const auto *Decl = Type->getAsCXXRecordDecl();
+if (Decl == nullptr || Decl->getIdentifier() == nullptr ||
+Decl->getName() != "SpecialBool")
+  return true;
+
+auto *IsSet1 = cast_or_null(
+cast(&Val1)->getProperty("is_set"));
+if (IsSet1 == nullptr)
+  return true;
+
+auto *IsSet2 = cast_or_null(
+cast(&Val2)->getProperty("is_set"));
+if (IsSet2 == nullptr)
+  return true;
+
+auto &IsSet = MergedEnv.makeAtomicBoolValue();
+cast(&MergedVal)->setProperty("is_set", IsSet);
+if (Env1.flowConditionImplies(*IsSet1) &&
+Env2.flowConditionImplies(*IsSet2))
+  MergedEnv.addToFlowCondition(IsSet);
+
+return true;
+  }
+};
+
+class JoinFlowConditionsTest : public Test {
+protected:
+  template 
+  void runDataflow(llvm::StringRef Code, Matcher Match) {
+ASSERT_THAT_ERROR(
+test::checkDataflow(
+Code, "target",
+[](ASTContext &Context, Environment &Env) {
+  return SpecialBoolAnalysis(Context);
+},
+[&Match](
+llvm::ArrayRef<
+

[clang] 37b4782 - [clang][dataflow] Fix `Environment::join`'s handling of flow-condition merging.

[Yitzhak Mandelbaum via cfe-commits]

Author: Yitzhak Mandelbaum
Date: 2022-04-25T15:05:50Z
New Revision: 37b4782e3e53cba265d26843f222134ed21e1974

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

LOG: [clang][dataflow] Fix `Environment::join`'s handling of flow-condition 
merging.

The current implementation mutates the environment as it performs the
join. However, that interferes with the call to the model's `merge` operation,
which can modify `MergedEnv`. Since any modifications are assumed to apply to
the post-join environment, providing the same environment for both is
incorrect. This mismatch is a particular concern for joining the flow
conditions, where modifications in the old environment may not be propagated to
the new one.

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

Added: 


Modified: 
clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

Removed: 




diff  --git a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp 
b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
index 04bf41605d9d3..91e07bdb88ce0 100644
--- a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -66,12 +66,14 @@ static bool equivalentValues(QualType Type, Value *Val1,
   return Model.compareEquivalent(Type, *Val1, Env1, *Val2, Env2);
 }
 
-/// Attempts to merge distinct values `Val1` and `Val1` in `Env1` and `Env2`,
+/// Attempts to merge distinct values `Val1` and `Val2` in `Env1` and `Env2`,
 /// respectively, of the same type `Type`. Merging generally produces a single
 /// value that (soundly) approximates the two inputs, although the actual
 /// meaning depends on `Model`.
-static Value *mergeDistinctValues(QualType Type, Value *Val1, Environment 
&Env1,
-  Value *Val2, const Environment &Env2,
+static Value *mergeDistinctValues(QualType Type, Value *Val1,
+  const Environment &Env1, Value *Val2,
+  const Environment &Env2,
+  Environment &MergedEnv,
   Environment::ValueModel &Model) {
   // Join distinct boolean values preserving information about the constraints
   // in the respective path conditions. Note: this construction can, in
@@ -94,19 +96,19 @@ static Value *mergeDistinctValues(QualType Type, Value 
*Val1, Environment &Env1,
   // have mutually exclusive conditions.
   if (auto *Expr1 = dyn_cast(Val1)) {
 for (BoolValue *Constraint : Env1.getFlowConditionConstraints()) {
-  Expr1 = &Env1.makeAnd(*Expr1, *Constraint);
+  Expr1 = &MergedEnv.makeAnd(*Expr1, *Constraint);
 }
 auto *Expr2 = cast(Val2);
 for (BoolValue *Constraint : Env2.getFlowConditionConstraints()) {
-  Expr2 = &Env1.makeAnd(*Expr2, *Constraint);
+  Expr2 = &MergedEnv.makeAnd(*Expr2, *Constraint);
 }
-return &Env1.makeOr(*Expr1, *Expr2);
+return &MergedEnv.makeOr(*Expr1, *Expr2);
   }
 
   // FIXME: Consider destroying `MergedValue` immediately if 
`ValueModel::merge`
   // returns false to avoid storing unneeded values in `DACtx`.
-  if (Value *MergedVal = Env1.createValue(Type))
-if (Model.merge(Type, *Val1, Env1, *Val2, Env2, *MergedVal, Env1))
+  if (Value *MergedVal = MergedEnv.createValue(Type))
+if (Model.merge(Type, *Val1, Env1, *Val2, Env2, *MergedVal, MergedEnv))
   return MergedVal;
 
   return nullptr;
@@ -315,28 +317,26 @@ LatticeJoinEffect Environment::join(const Environment 
&Other,
 
   auto Effect = LatticeJoinEffect::Unchanged;
 
-  const unsigned DeclToLocSizeBefore = DeclToLoc.size();
-  DeclToLoc = intersectDenseMaps(DeclToLoc, Other.DeclToLoc);
-  if (DeclToLocSizeBefore != DeclToLoc.size())
+  Environment JoinedEnv(*DACtx);
+
+  JoinedEnv.DeclToLoc = intersectDenseMaps(DeclToLoc, Other.DeclToLoc);
+  if (DeclToLoc.size() != JoinedEnv.DeclToLoc.size())
 Effect = LatticeJoinEffect::Changed;
 
-  const unsigned ExprToLocSizeBefore = ExprToLoc.size();
-  ExprToLoc = intersectDenseMaps(ExprToLoc, Other.ExprToLoc);
-  if (ExprToLocSizeBefore != ExprToLoc.size())
+  JoinedEnv.ExprToLoc = intersectDenseMaps(ExprToLoc, Other.ExprToLoc);
+  if (ExprToLoc.size() != JoinedEnv.ExprToLoc.size())
 Effect = LatticeJoinEffect::Changed;
 
-  const unsigned MemberLocToStructSizeBefore = MemberLocToStruct.size();
-  MemberLocToStruct =
+  JoinedEnv.MemberLocToStruct =
   intersectDenseMaps(MemberLocToStruct, Other.MemberLocToStruct);
-  if (MemberLocToStructSizeBefore != MemberLocToStruct.size())
+  if (MemberLocToStruct.size() != JoinedEnv.MemberLocToStruct.size())
 Effect = LatticeJoinEffect::Changed;
 
-  // Move `LocToVal` so that `Environme

[PATCH] D124104: [clang][dataflow] Fix `Environment::join`'s handling of flow condition merging

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel marked an inline comment as done.
ymandel added inline comments.



Comment at: 
clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp:356
+
+return V1 == V2 ||
+   Env1.flowConditionImplies(*V1) == Env2.flowConditionImplies(*V2);

sgatev wrote:
> ymandel wrote:
> > sgatev wrote:
> > > That's guaranteed to be false in `compareEquivalent`.
> > I thought just `Val1 == Val2` was guaranteed false? Also, I see that the 
> > variable naming could be confusing, so I've renamed.
> Right. I think I misread it. Having `IsSet1 == IsSet2` here makes sense to 
> me. Though, if the test only needs the second part, I suggest removing this 
> to simplify the setup.
agreed. done


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124104

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

[PATCH] D124389: [clang][NFC] Inclusive language: remove use of Whitelist in clang/lib/Analysis/

[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, thanks for the cleanup!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124389

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

[PATCH] D124104: [clang][dataflow] Fix `Environment::join`'s handling of flow condition merging

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel updated this revision to Diff 424916.
ymandel marked an inline comment as done.
ymandel added a comment.

address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124104

Files:
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
  clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
@@ -10,6 +10,7 @@
 #include "TestingSupport.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/ExprCXX.h"
+#include "clang/AST/Type.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Analysis/CFG.h"
@@ -295,6 +296,164 @@
   // FIXME: Called functions at point `p` should contain only "foo".
 }
 
+// Models an analysis that uses flow conditions.
+class SpecialBoolAnalysis
+: public DataflowAnalysis {
+public:
+  explicit SpecialBoolAnalysis(ASTContext &Context)
+  : DataflowAnalysis(Context) {}
+
+  static NoopLattice initialElement() { return {}; }
+
+  void transfer(const Stmt *S, NoopLattice &, Environment &Env) {
+auto SpecialBoolRecordDecl = recordDecl(hasName("SpecialBool"));
+auto HasSpecialBoolType = hasType(SpecialBoolRecordDecl);
+
+if (const auto *E = selectFirst(
+"call", match(cxxConstructExpr(HasSpecialBoolType).bind("call"), *S,
+  getASTContext( {
+  auto &ConstructorVal = *cast(Env.createValue(E->getType()));
+  ConstructorVal.setProperty("is_set", Env.getBoolLiteralValue(false));
+  Env.setValue(*Env.getStorageLocation(*E, SkipPast::None), ConstructorVal);
+} else if (const auto *E = selectFirst(
+   "call", match(cxxMemberCallExpr(callee(cxxMethodDecl(ofClass(
+   SpecialBoolRecordDecl
+ .bind("call"),
+ *S, getASTContext( {
+  auto *Object = E->getImplicitObjectArgument();
+  assert(Object != nullptr);
+
+  auto *ObjectLoc =
+  Env.getStorageLocation(*Object, SkipPast::ReferenceThenPointer);
+  assert(ObjectLoc != nullptr);
+
+  auto &ConstructorVal =
+  *cast(Env.createValue(Object->getType()));
+  ConstructorVal.setProperty("is_set", Env.getBoolLiteralValue(true));
+  Env.setValue(*ObjectLoc, ConstructorVal);
+}
+  }
+
+  bool compareEquivalent(QualType Type, const Value &Val1,
+ const Environment &Env1, const Value &Val2,
+ const Environment &Env2) final {
+const auto *Decl = Type->getAsCXXRecordDecl();
+if (Decl == nullptr || Decl->getIdentifier() == nullptr ||
+Decl->getName() != "SpecialBool")
+  return false;
+
+auto *IsSet1 = cast_or_null(
+cast(&Val1)->getProperty("is_set"));
+if (IsSet1 == nullptr)
+  return true;
+
+auto *IsSet2 = cast_or_null(
+cast(&Val2)->getProperty("is_set"));
+if (IsSet2 == nullptr)
+  return false;
+
+return Env1.flowConditionImplies(*IsSet1) ==
+   Env2.flowConditionImplies(*IsSet2);
+  }
+
+  // Always returns `true` to accept the `MergedVal`.
+  bool merge(QualType Type, const Value &Val1, const Environment &Env1,
+ const Value &Val2, const Environment &Env2, Value &MergedVal,
+ Environment &MergedEnv) final {
+const auto *Decl = Type->getAsCXXRecordDecl();
+if (Decl == nullptr || Decl->getIdentifier() == nullptr ||
+Decl->getName() != "SpecialBool")
+  return true;
+
+auto *IsSet1 = cast_or_null(
+cast(&Val1)->getProperty("is_set"));
+if (IsSet1 == nullptr)
+  return true;
+
+auto *IsSet2 = cast_or_null(
+cast(&Val2)->getProperty("is_set"));
+if (IsSet2 == nullptr)
+  return true;
+
+auto &IsSet = MergedEnv.makeAtomicBoolValue();
+cast(&MergedVal)->setProperty("is_set", IsSet);
+if (Env1.flowConditionImplies(*IsSet1) &&
+Env2.flowConditionImplies(*IsSet2))
+  MergedEnv.addToFlowCondition(IsSet);
+
+return true;
+  }
+};
+
+class JoinFlowConditionsTest : public Test {
+protected:
+  template 
+  void runDataflow(llvm::StringRef Code, Matcher Match) {
+ASSERT_THAT_ERROR(
+test::checkDataflow(
+Code, "target",
+[](ASTContext &Context, Environment &Env) {
+  return SpecialBoolAnalysis(Context);
+},
+[&Match](
+llvm::ArrayRef<
+std::pair>>
+Results,
+ASTContext &ASTCtx) { Match(Results, ASTCtx); },
+{"-fsyntax-only", "-std=c++17"}),
+ll

[PATCH] D124104: [clang][dataflow] Fix `Environment::join`'s handling of flow condition merging

[Stanislav Gatev via Phabricator via cfe-commits]

sgatev accepted this revision.
sgatev added inline comments.



Comment at: 
clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp:356
+
+return V1 == V2 ||
+   Env1.flowConditionImplies(*V1) == Env2.flowConditionImplies(*V2);

ymandel wrote:
> sgatev wrote:
> > That's guaranteed to be false in `compareEquivalent`.
> I thought just `Val1 == Val2` was guaranteed false? Also, I see that the 
> variable naming could be confusing, so I've renamed.
Right. I think I misread it. Having `IsSet1 == IsSet2` here makes sense to me. 
Though, if the test only needs the second part, I suggest removing this to 
simplify the setup.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124104

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

[PATCH] D124262: compile commands header to source heuristic lower-cases filenames before inferring file types

[Ishaan Gandhi via Phabricator via cfe-commits]

ishaangandhi updated this revision to Diff 424914.
ishaangandhi added a comment.

Made test case reflect that proxies for ".H" files are ".C" files, and not ".c 
files".


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

https://reviews.llvm.org/D124262

Files:
  clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
  clang/unittests/Tooling/CompilationDatabaseTest.cpp


Index: clang/unittests/Tooling/CompilationDatabaseTest.cpp
===
--- clang/unittests/Tooling/CompilationDatabaseTest.cpp
+++ clang/unittests/Tooling/CompilationDatabaseTest.cpp
@@ -845,6 +845,14 @@
   EXPECT_EQ(getProxy("foo/bar/baz/shout.C"), "FOO/BAR/BAZ/SHOUT.cc");
 }
 
+TEST_F(InterpolateTest, LanguagePreference) {
+  add("foo/bar/baz/exact.C");
+  add("foo/bar/baz/exact.c");
+  add("other/random/path.cpp");
+  // Proxies for ".H" files are ".C" files, and not ".c files".
+  EXPECT_EQ(getProxy("foo/bar/baz/exact.H"), "foo/bar/baz/exact.C");
+}
+
 TEST_F(InterpolateTest, Aliasing) {
   add("foo.cpp", "-faligned-new");
 
Index: clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
===
--- clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
+++ clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
@@ -329,7 +329,7 @@
   StringRef Path = Strings.save(StringRef(OriginalPaths[I]).lower());
 
   Paths.emplace_back(Path, I);
-  Types.push_back(foldType(guessType(Path)));
+  Types.push_back(foldType(guessType(OriginalPaths[I])));
   Stems.emplace_back(sys::path::stem(Path), I);
   auto Dir = ++sys::path::rbegin(Path), DirEnd = sys::path::rend(Path);
   for (int J = 0; J < DirectorySegmentsIndexed && Dir != DirEnd; ++J, 
++Dir)


Index: clang/unittests/Tooling/CompilationDatabaseTest.cpp
===
--- clang/unittests/Tooling/CompilationDatabaseTest.cpp
+++ clang/unittests/Tooling/CompilationDatabaseTest.cpp
@@ -845,6 +845,14 @@
   EXPECT_EQ(getProxy("foo/bar/baz/shout.C"), "FOO/BAR/BAZ/SHOUT.cc");
 }
 
+TEST_F(InterpolateTest, LanguagePreference) {
+  add("foo/bar/baz/exact.C");
+  add("foo/bar/baz/exact.c");
+  add("other/random/path.cpp");
+  // Proxies for ".H" files are ".C" files, and not ".c files".
+  EXPECT_EQ(getProxy("foo/bar/baz/exact.H"), "foo/bar/baz/exact.C");
+}
+
 TEST_F(InterpolateTest, Aliasing) {
   add("foo.cpp", "-faligned-new");
 
Index: clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
===
--- clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
+++ clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
@@ -329,7 +329,7 @@
   StringRef Path = Strings.save(StringRef(OriginalPaths[I]).lower());
 
   Paths.emplace_back(Path, I);
-  Types.push_back(foldType(guessType(Path)));
+  Types.push_back(foldType(guessType(OriginalPaths[I])));
   Stems.emplace_back(sys::path::stem(Path), I);
   auto Dir = ++sys::path::rbegin(Path), DirEnd = sys::path::rend(Path);
   for (int J = 0; J < DirectorySegmentsIndexed && Dir != DirEnd; ++J, ++Dir)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124384: [clang] Fix a constant evaluator crash on a NULL-type expr.

[Sam McCall via Phabricator via cfe-commits]

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

This is a reasonable immediate fix, but creating null-typed expressions that 
live *outside* the recoveryexpr seems scary, and likely to violate expected 
invariants elsewhere too...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124384

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

[PATCH] D107668: [OpenMP]Fix PR50336: Remove temporary files in the offload bundler tool

[Victor Lomuller via Phabricator via cfe-commits]

Naghasan added a comment.

Thanks for your answer, make sense.

If we are moving away I won't bother looking fixing my issue upstream as it is 
very niche (I don't think you can trigger this with the upstream clang driver).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107668

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

[PATCH] D124262: compile commands header to source heuristic lower-cases filenames before inferring file types

[Ishaan Gandhi via Phabricator via cfe-commits]

ishaangandhi added inline comments.



Comment at: clang/unittests/Tooling/CompilationDatabaseTest.cpp:852
+  add("other/random/path.cpp");
+  // Proxies for ".H" files are ".C" files, and not ".cpp files"
+  EXPECT_EQ(getProxy("foo/bar/baz/exact.H"), "foo/bar/baz/exact.C");

sammccall wrote:
> Is this really what you intend to test?
> 
> I think our goal here is to treat `.H` and `.C` as C++ rather than C, not to 
> link them together in some way. If the current file is `foo.H`, then 
> `foo.cpp` and `foo.C` should be equally compelling candidates, but both beat 
> `foo.c`.
Bleh brain fart. You're right. "exact.C" should win over "exact.c", not 
necessarily "exact.cpp".


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

https://reviews.llvm.org/D124262

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

[PATCH] D124250: [Serialization] write expr dependence bits as a single integer

[Jake Egan via Phabricator via cfe-commits]

Jake-Egan added a comment.

Hi, this broke a test on AIX 
https://lab.llvm.org/buildbot/#/builders/214/builds/903/steps/6/logs/FAIL__Clang__pch-with-module_m


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124250

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

[PATCH] D124262: compile commands header to source heuristic lower-cases filenames before inferring file types

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D124262#3471841 , @ishaangandhi 
wrote:

> Test case added, re-diffed with `-U`, and removed redundant constructor. 
> Thanks for the quick feedback, @sammccall!
>
> (I didn't wait for the tests to run locally, I am hoping to use your CI 
> systems to do that. It seems like a simple enough of a test that I hope I can 
> get it right on the first try.)

Unfortunately it looks like you've created a patch that phabricator can render, 
but the precommit CI can't apply (it's using `git apply`).
The usual way to upload is with `arc`, but the output of `git diff -U` 
should also work.




Comment at: clang/unittests/Tooling/CompilationDatabaseTest.cpp:852
+  add("other/random/path.cpp");
+  // Proxies for ".H" files are ".C" files, and not ".cpp files"
+  EXPECT_EQ(getProxy("foo/bar/baz/exact.H"), "foo/bar/baz/exact.C");

Is this really what you intend to test?

I think our goal here is to treat `.H` and `.C` as C++ rather than C, not to 
link them together in some way. If the current file is `foo.H`, then `foo.cpp` 
and `foo.C` should be equally compelling candidates, but both beat `foo.c`.


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

https://reviews.llvm.org/D124262

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

[PATCH] D124104: [clang][dataflow] Fix `Environment::join`'s handling of flow condition merging

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel marked 7 inline comments as done.
ymandel added inline comments.



Comment at: 
clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp:356
+
+return V1 == V2 ||
+   Env1.flowConditionImplies(*V1) == Env2.flowConditionImplies(*V2);

sgatev wrote:
> That's guaranteed to be false in `compareEquivalent`.
I thought just `Val1 == Val2` was guaranteed false? Also, I see that the 
variable naming could be confusing, so I've renamed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124104

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

[PATCH] D124104: [clang][dataflow] Fix `Environment::join`'s handling of flow condition merging

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel updated this revision to Diff 424909.
ymandel added a comment.

address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124104

Files:
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
  clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
@@ -10,6 +10,7 @@
 #include "TestingSupport.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/ExprCXX.h"
+#include "clang/AST/Type.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Analysis/CFG.h"
@@ -295,6 +296,164 @@
   // FIXME: Called functions at point `p` should contain only "foo".
 }
 
+// Models an analysis that uses flow conditions.
+class SpecialBoolAnalysis
+: public DataflowAnalysis {
+public:
+  explicit SpecialBoolAnalysis(ASTContext &Context)
+  : DataflowAnalysis(Context) {}
+
+  static NoopLattice initialElement() { return {}; }
+
+  void transfer(const Stmt *S, NoopLattice &, Environment &Env) {
+auto SpecialBoolRecordDecl = recordDecl(hasName("SpecialBool"));
+auto HasSpecialBoolType = hasType(SpecialBoolRecordDecl);
+
+if (const auto *E = selectFirst(
+"call", match(cxxConstructExpr(HasSpecialBoolType).bind("call"), *S,
+  getASTContext( {
+  auto &ConstructorVal = *cast(Env.createValue(E->getType()));
+  ConstructorVal.setProperty("is_set", Env.getBoolLiteralValue(false));
+  Env.setValue(*Env.getStorageLocation(*E, SkipPast::None), ConstructorVal);
+} else if (const auto *E = selectFirst(
+   "call", match(cxxMemberCallExpr(callee(cxxMethodDecl(ofClass(
+   SpecialBoolRecordDecl
+ .bind("call"),
+ *S, getASTContext( {
+  auto *Object = E->getImplicitObjectArgument();
+  assert(Object != nullptr);
+
+  auto *ObjectLoc =
+  Env.getStorageLocation(*Object, SkipPast::ReferenceThenPointer);
+  assert(ObjectLoc != nullptr);
+
+  auto &ConstructorVal =
+  *cast(Env.createValue(Object->getType()));
+  ConstructorVal.setProperty("is_set", Env.getBoolLiteralValue(true));
+  Env.setValue(*ObjectLoc, ConstructorVal);
+}
+  }
+
+  bool compareEquivalent(QualType Type, const Value &Val1,
+ const Environment &Env1, const Value &Val2,
+ const Environment &Env2) final {
+const auto *Decl = Type->getAsCXXRecordDecl();
+if (Decl == nullptr || Decl->getIdentifier() == nullptr ||
+Decl->getName() != "SpecialBool")
+  return false;
+
+auto *IsSet1 = cast_or_null(
+cast(&Val1)->getProperty("is_set"));
+if (IsSet1 == nullptr)
+  return true;
+
+auto *IsSet2 = cast_or_null(
+cast(&Val2)->getProperty("is_set"));
+if (IsSet2 == nullptr)
+  return false;
+
+return IsSet1 == IsSet2 || Env1.flowConditionImplies(*IsSet1) ==
+   Env2.flowConditionImplies(*IsSet2);
+  }
+
+  // Always returns `true` to accept the `MergedVal`.
+  bool merge(QualType Type, const Value &Val1, const Environment &Env1,
+ const Value &Val2, const Environment &Env2, Value &MergedVal,
+ Environment &MergedEnv) final {
+const auto *Decl = Type->getAsCXXRecordDecl();
+if (Decl == nullptr || Decl->getIdentifier() == nullptr ||
+Decl->getName() != "SpecialBool")
+  return true;
+
+auto *IsSet1 = cast_or_null(
+cast(&Val1)->getProperty("is_set"));
+if (IsSet1 == nullptr)
+  return true;
+
+auto *IsSet2 = cast_or_null(
+cast(&Val2)->getProperty("is_set"));
+if (IsSet2 == nullptr)
+  return true;
+
+auto &IsSet = MergedEnv.makeAtomicBoolValue();
+cast(&MergedVal)->setProperty("is_set", IsSet);
+if (Env1.flowConditionImplies(*IsSet1) &&
+Env2.flowConditionImplies(*IsSet2))
+  MergedEnv.addToFlowCondition(IsSet);
+
+return true;
+  }
+};
+
+class JoinFlowConditionsTest : public Test {
+protected:
+  template 
+  void runDataflow(llvm::StringRef Code, Matcher Match) {
+ASSERT_THAT_ERROR(
+test::checkDataflow(
+Code, "target",
+[](ASTContext &Context, Environment &Env) {
+  return SpecialBoolAnalysis(Context);
+},
+[&Match](
+llvm::ArrayRef<
+std::pair>>
+Results,
+ASTContext &ASTCtx) { Match(Results, ASTCtx); },
+{"-fsyntax-only", "-std=c++17"}),
+

[PATCH] D122663: Mark identifier prefixes as substitutable

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

> llvm-cxxfilt has no option to be compatible with earlier incorrect mangling 
> though, so it would not help with this particular test. But it could help 
> with other tests, agreed.

This actually wouldn't be necessary in this case: cxxfilt is already 'right', 
this is just for humans to be able to see "we changed this from mangling as 
 to ".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122663

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

[PATCH] D122920: [Clang][CodeGen]Fix __builtin_dump_struct missing record type field name

[Wang Yihan via Phabricator via cfe-commits]

yihanaa added a comment.

In D122920#3471654 , @erichkeane 
wrote:

> @yihanaa : I'd suggest seeing the conversation that @rsmith @aaron.ballman 
> and I are having about this builtin here: https://reviews.llvm.org/D124221
>
> In general it looks like the three of us think that this builtin needs an 
> overhaul in implementation/functionality in order to be further useful. While 
> we very much appreciate your attempts to try to improve it, we believe there 
> needs to be larger-scale changes.

Thanks for your reply, I would like to get involved and help if needed


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122920

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

[PATCH] D124262: compile commands header to source heuristic lower-cases filenames before inferring file types

[Ishaan Gandhi via Phabricator via cfe-commits]

ishaangandhi updated this revision to Diff 424906.

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

https://reviews.llvm.org/D124262

Files:
  clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
  clang/unittests/Tooling/CompilationDatabaseTest.cpp


Index: clang/unittests/Tooling/CompilationDatabaseTest.cpp
===
--- clang/unittests/Tooling/CompilationDatabaseTest.cpp
+++ clang/unittests/Tooling/CompilationDatabaseTest.cpp
@@ -845,6 +845,14 @@
   EXPECT_EQ(getProxy("foo/bar/baz/shout.C"), "FOO/BAR/BAZ/SHOUT.cc");
 }
 
+TEST_F(InterpolateTest, LanguagePreference) {
+  add("foo/bar/baz/exact.C");
+  add("foo/bar/baz/exact.cpp");
+  add("other/random/path.cpp");
+  // Proxies for ".H" files are ".C" files, and not ".cpp files"
+  EXPECT_EQ(getProxy("foo/bar/baz/exact.H"), "foo/bar/baz/exact.C");
+}
+
 TEST_F(InterpolateTest, Aliasing) {
   add("foo.cpp", "-faligned-new");
 
Index: clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
===
--- clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
+++ clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
@@ -329,7 +329,7 @@
   StringRef Path = Strings.save(StringRef(OriginalPaths[I]).lower());
 
   Paths.emplace_back(Path, I);
-  Types.push_back(foldType(guessType(Path)));
+  Types.push_back(foldType(guessType(OriginalPaths[I])));
   Stems.emplace_back(sys::path::stem(Path), I);
   auto Dir = ++sys::path::rbegin(Path), DirEnd = sys::path::rend(Path);
   for (int J = 0; J < DirectorySegmentsIndexed && Dir != DirEnd; ++J, 
++Dir)


Index: clang/unittests/Tooling/CompilationDatabaseTest.cpp
===
--- clang/unittests/Tooling/CompilationDatabaseTest.cpp
+++ clang/unittests/Tooling/CompilationDatabaseTest.cpp
@@ -845,6 +845,14 @@
   EXPECT_EQ(getProxy("foo/bar/baz/shout.C"), "FOO/BAR/BAZ/SHOUT.cc");
 }
 
+TEST_F(InterpolateTest, LanguagePreference) {
+  add("foo/bar/baz/exact.C");
+  add("foo/bar/baz/exact.cpp");
+  add("other/random/path.cpp");
+  // Proxies for ".H" files are ".C" files, and not ".cpp files"
+  EXPECT_EQ(getProxy("foo/bar/baz/exact.H"), "foo/bar/baz/exact.C");
+}
+
 TEST_F(InterpolateTest, Aliasing) {
   add("foo.cpp", "-faligned-new");
 
Index: clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
===
--- clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
+++ clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
@@ -329,7 +329,7 @@
   StringRef Path = Strings.save(StringRef(OriginalPaths[I]).lower());
 
   Paths.emplace_back(Path, I);
-  Types.push_back(foldType(guessType(Path)));
+  Types.push_back(foldType(guessType(OriginalPaths[I])));
   Stems.emplace_back(sys::path::stem(Path), I);
   auto Dir = ++sys::path::rbegin(Path), DirEnd = sys::path::rend(Path);
   for (int J = 0; J < DirectorySegmentsIndexed && Dir != DirEnd; ++J, ++Dir)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124262: compile commands header to source heuristic lower-cases filenames before inferring file types

[Ishaan Gandhi via Phabricator via cfe-commits]

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

Test case added, re-diffed with `-U`, and removed redundant constructor. 
Thanks for the quick feedback, @sammccall!

(I didn't wait for the tests to run locally, I am hoping to use your CI systems 
to do that. It seems like a simple enough of a test that I hope I can get it 
right on the first try.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124262

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

[PATCH] D124262: compile commands header to source heuristic lower-cases filenames before inferring file types

[Ishaan Gandhi via Phabricator via cfe-commits]

ishaangandhi updated this revision to Diff 424904.
ishaangandhi added a comment.

- Added a test case
- Removed redundant "StringRef" constructor


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124262

Files:
  clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
  clang/unittests/Tooling/CompilationDatabaseTest.cpp


Index: clang/unittests/Tooling/CompilationDatabaseTest.cpp
===
--- clang/unittests/Tooling/CompilationDatabaseTest.cpp
+++ clang/unittests/Tooling/CompilationDatabaseTest.cpp
@@ -845,6 +845,14 @@
   EXPECT_EQ(getProxy("foo/bar/baz/shout.C"), "FOO/BAR/BAZ/SHOUT.cc");
 }
 
+TEST_F(InterpolateTest, LanguagePreference) {
+  add("foo/bar/baz/exact.C");
+  add("foo/bar/baz/exact.cpp");
+  add("other/random/path.cpp");
+  // Proxies for ".H" files are ".C" files, and not ".cpp files"
+  EXPECT_EQ(getProxy("foo/bar/baz/exact.H"), "foo/bar/baz/exact.C");
+}
+
 TEST_F(InterpolateTest, Aliasing) {
   add("foo.cpp", "-faligned-new");
 
Index: clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
===
--- clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
+++ clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
@@ -329,7 +329,7 @@
   StringRef Path = Strings.save(StringRef(OriginalPaths[I]).lower());
 
   Paths.emplace_back(Path, I);
-  Types.push_back(foldType(guessType(StringRef(OriginalPaths[I];
+  Types.push_back(foldType(guessType(OriginalPaths[I])));
   Stems.emplace_back(sys::path::stem(Path), I);
   auto Dir = ++sys::path::rbegin(Path), DirEnd = sys::path::rend(Path);
   for (int J = 0; J < DirectorySegmentsIndexed && Dir != DirEnd; ++J, 
++Dir)


Index: clang/unittests/Tooling/CompilationDatabaseTest.cpp
===
--- clang/unittests/Tooling/CompilationDatabaseTest.cpp
+++ clang/unittests/Tooling/CompilationDatabaseTest.cpp
@@ -845,6 +845,14 @@
   EXPECT_EQ(getProxy("foo/bar/baz/shout.C"), "FOO/BAR/BAZ/SHOUT.cc");
 }
 
+TEST_F(InterpolateTest, LanguagePreference) {
+  add("foo/bar/baz/exact.C");
+  add("foo/bar/baz/exact.cpp");
+  add("other/random/path.cpp");
+  // Proxies for ".H" files are ".C" files, and not ".cpp files"
+  EXPECT_EQ(getProxy("foo/bar/baz/exact.H"), "foo/bar/baz/exact.C");
+}
+
 TEST_F(InterpolateTest, Aliasing) {
   add("foo.cpp", "-faligned-new");
 
Index: clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
===
--- clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
+++ clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
@@ -329,7 +329,7 @@
   StringRef Path = Strings.save(StringRef(OriginalPaths[I]).lower());
 
   Paths.emplace_back(Path, I);
-  Types.push_back(foldType(guessType(StringRef(OriginalPaths[I];
+  Types.push_back(foldType(guessType(OriginalPaths[I])));
   Stems.emplace_back(sys::path::stem(Path), I);
   auto Dir = ++sys::path::rbegin(Path), DirEnd = sys::path::rend(Path);
   for (int J = 0; J < DirectorySegmentsIndexed && Dir != DirEnd; ++J, ++Dir)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124389: [clang][NFC] Inclusive language: remove use of Whitelist in clang/lib/Analysis/

[Quinn Pham via Phabricator via cfe-commits]

quinnp created this revision.
Herald added a project: All.
quinnp requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

[NFC] As part of using inclusive language within the llvm project, this patch
rewords a comment to replace Whitelist with Allowlist in
`RetainSummaryManager.cpp`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D124389

Files:
  clang/lib/Analysis/RetainSummaryManager.cpp


Index: clang/lib/Analysis/RetainSummaryManager.cpp
===
--- clang/lib/Analysis/RetainSummaryManager.cpp
+++ clang/lib/Analysis/RetainSummaryManager.cpp
@@ -398,7 +398,7 @@
   } else if (FName.startswith("NSLog")) {
 return getDoNothingSummary();
   } else if (FName.startswith("NS") && FName.contains("Insert")) {
-// Whitelist NSXXInsertXX, for example NSMapInsertIfAbsent, since they can
+// Allowlist NSXXInsertXX, for example NSMapInsertIfAbsent, since they can
 // be deallocated by NSMapRemove. (radar://11152419)
 ScratchArgs = AF.add(ScratchArgs, 1, ArgEffect(StopTracking));
 ScratchArgs = AF.add(ScratchArgs, 2, ArgEffect(StopTracking));


Index: clang/lib/Analysis/RetainSummaryManager.cpp
===
--- clang/lib/Analysis/RetainSummaryManager.cpp
+++ clang/lib/Analysis/RetainSummaryManager.cpp
@@ -398,7 +398,7 @@
   } else if (FName.startswith("NSLog")) {
 return getDoNothingSummary();
   } else if (FName.startswith("NS") && FName.contains("Insert")) {
-// Whitelist NSXXInsertXX, for example NSMapInsertIfAbsent, since they can
+// Allowlist NSXXInsertXX, for example NSMapInsertIfAbsent, since they can
 // be deallocated by NSMapRemove. (radar://11152419)
 ScratchArgs = AF.add(ScratchArgs, 1, ArgEffect(StopTracking));
 ScratchArgs = AF.add(ScratchArgs, 2, ArgEffect(StopTracking));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits