[PATCH] D53238: [Driver] Add -static= to unify -static-{libgcc,libstdc++}

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D53238#1660259 , @pirama wrote:

> Does this regress from existing behavior for unused argument warnings?  
> Currently, `-static-libstdc++ -nostdlib` issues an unused argument warning 
> for `-static-libstdc++`, while AFAICT `-static=c++stdlib -nostdlib` doesn't.
>
> I'm not exactly sure how/where to issue this warning, though.


This change will suppress some unused argument warnings but I'll not call that 
"regression":)

Various toolchains already do things like:

  Args.ClaimAllArgs(options::OPT_g_Group);
  Args.ClaimAllArgs(options::OPT_emit_llvm);
  Args.ClaimAllArgs(options::OPT_w);

Hexagon and Myriad even do `Args.ClaimAllArgs(options::OPT_static_libgcc);` 
This diagnostic IMO has very low value.


Repository:
  rC Clang

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

https://reviews.llvm.org/D53238



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

[PATCH] D58094: Fix -Wnonportable-include-path suppression for header maps with absolute paths.

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added inline comments.



Comment at: clang/lib/Lex/HeaderSearch.cpp:888
 bool InUserSpecifiedSystemFramework = false;
-bool HasBeenMapped = false;
+bool CurrentInHeaderMap = false;
 bool IsFrameworkFoundInDir = false;

Why not name this the same way as the parameter?  (`IsInHeaderMap`)



Comment at: clang/lib/Lex/HeaderSearch.cpp:896-897
+  assert(CurrentInHeaderMap && "MappedName should come from a header map");
   CacheLookup.MappedName =
-  copyString(Filename, LookupFileCache.getAllocator());
-  if (IsMapped)
-*IsMapped = true;
+  copyString(MappedName, LookupFileCache.getAllocator());
+  HasBeenMapped = true;

It's not obvious to me why this changed from `Filename` to `MappedName`.  Can 
you explain it?



Comment at: clang/lib/Lex/HeaderSearch.cpp:898
+  copyString(MappedName, LookupFileCache.getAllocator());
+  HasBeenMapped = true;
 }

Do we need `HasBeenMapped` outside of the loop, or can you just use the 
loop-local variable?



Comment at: clang/lib/Lex/HeaderSearch.cpp:908-909
 
+if (IsMapped)
+  *IsMapped = CurrentInHeaderMap || HasBeenMapped;
+

Are you intentionally delaying this until after the `if (!File)` check?  If so, 
why?


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

https://reviews.llvm.org/D58094



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

[PATCH] D53238: [Driver] Add -static= to unify -static-{libgcc,libstdc++}

[Pirama Arumuga Nainar via Phabricator via cfe-commits]

pirama added a comment.

Does this regress from existing behavior for unused arguments?  Currently, 
`-static-libstdc++ -nostdlib` issues an unused argument warning for 
`-static-libstdc++`, while AFAICT `-static=c++stdlib -nostdlib` doesn't.

I'm not exactly sure how/where to issue this warning, though.


Repository:
  rC Clang

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

https://reviews.llvm.org/D53238



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

[PATCH] D53238: [Driver] Add -static= to unify -static-{libgcc,libstdc++}

[Fangrui Song via Phabricator via cfe-commits]

MaskRay updated this revision to Diff 219025.
MaskRay retitled this revision from "[Driver] Add -static-{rtlib,stdlib} and 
make -static-{libgcc,libstdc++} their aliases" to "[Driver] Add -static= to 
unify -static-{libgcc,libstdc++}".
MaskRay edited the summary of this revision.
MaskRay added reviewers: phosek, pirama, rnk, srhines.
MaskRay removed a subscriber: rnk.
MaskRay added a comment.

Repurpose the patch.  Add -static= instead


Repository:
  rC Clang

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

https://reviews.llvm.org/D53238

Files:
  include/clang/Driver/Options.td
  include/clang/Driver/ToolChain.h
  lib/Driver/ToolChain.cpp
  lib/Driver/ToolChains/CommonArgs.cpp
  lib/Driver/ToolChains/CrossWindows.cpp
  lib/Driver/ToolChains/DragonFly.cpp
  lib/Driver/ToolChains/Fuchsia.cpp
  lib/Driver/ToolChains/Gnu.cpp
  lib/Driver/ToolChains/Hexagon.cpp
  lib/Driver/ToolChains/MinGW.cpp
  lib/Driver/ToolChains/Myriad.cpp
  lib/Driver/ToolChains/NaCl.cpp
  test/Driver/fuchsia.cpp
  test/Driver/linux-ld.c
  test/Driver/linux-musl.cpp
  test/Driver/static.c

Index: test/Driver/static.c
===
--- /dev/null
+++ test/Driver/static.c
@@ -0,0 +1,5 @@
+// RUN: %clang -target %itanium_abi_triple %s -static=c++stdlib,rtlib -### 2>&1 | \
+// RUN:   FileCheck /dev/null --implicit-check-not=error:
+
+// RUN: %clang -target %itanium_abi_triple %s -static=unknown -### 2>&1 | FileCheck --check-prefix=STATIC-UNKNOWN %s
+// STATIC-UNKNOWN: error: unsupported argument 'unknown' to option 'static='
Index: test/Driver/linux-musl.cpp
===
--- /dev/null
+++ test/Driver/linux-musl.cpp
@@ -0,0 +1,13 @@
+// RUN: %clangxx -no-canonical-prefixes %s -### -target x86_64-linux-musl 2>&1 \
+// RUN:   -static=c++stdlib -stdlib=libc++ \
+// RUN:   -ccc-install-dir %S/Inputs/basic_linux_tree/usr/bin \
+// RUN:   --sysroot=%S/Inputs/basic_linux_libcxx_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-STATIC-LIBCXX %s
+// CHECK-STATIC-LIBCXX: "-Bstatic" "-lc++" "-Bdynamic" "-lm" "-lgcc_s" "-lgcc" "-lc" "-lgcc_s" "-lgcc"
+
+// RUN: %clangxx -no-canonical-prefixes %s -### -target x86_64-linux-musl 2>&1 \
+// RUN:   -static=c++stdlib,rtlib -stdlib=libc++ \
+// RUN:   -ccc-install-dir %S/Inputs/basic_linux_tree/usr/bin \
+// RUN:   --sysroot=%S/Inputs/basic_linux_libcxx_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-STATIC-LIBCXX-RTLIB %s
+// CHECK-STATIC-LIBCXX-RTLIB: "-Bstatic" "-lc++" "-Bdynamic" "-lm" "-lgcc" "-lgcc_eh" "-lc" "-lgcc" "-lgcc_eh"
Index: test/Driver/linux-ld.c
===
--- test/Driver/linux-ld.c
+++ test/Driver/linux-ld.c
@@ -131,11 +131,17 @@
 // CHECK-LD-GCC: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
 // CHECK-LD-GCC: "-lc"
 // CHECK-LD-GCC: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
-//
+
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: --target=x86_64-unknown-linux -rtlib=platform \
-// RUN: -static-libgcc \
-// RUN: --gcc-toolchain="" \
+// RUN: -static=rtlib --gcc-toolchain="" \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD-64-STATIC-LIBGCC %s
+
+// -static-libgcc is an alias of -static=rtlib
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-unknown-linux -rtlib=platform \
+// RUN: -static-libgcc --gcc-toolchain="" \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-LD-64-STATIC-LIBGCC %s
 // CHECK-LD-64-STATIC-LIBGCC-NOT: warning:
@@ -243,7 +249,7 @@
 // CHECK-CLANG-NO-LIBGCC-DYNAMIC: "-lc"
 // CHECK-CLANG-NO-LIBGCC-DYNAMIC: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
 //
-// RUN: %clang -static-libgcc -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: %clang -static=rtlib -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: --target=x86_64-unknown-linux -rtlib=platform \
 // RUN: --gcc-toolchain="" \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
@@ -253,7 +259,7 @@
 // CHECK-CLANG-STATIC-LIBGCC: "-lc"
 // CHECK-CLANG-STATIC-LIBGCC: "-lgcc" "-lgcc_eh"
 //
-// RUN: %clang -static-libgcc -dynamic -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: %clang -static=rtlib -dynamic -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: --target=x86_64-unknown-linux -rtlib=platform \
 // RUN: --gcc-toolchain="" \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
@@ -329,7 +335,7 @@
 // Check that flags can be combined. The -static dominates.
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: --target=x86_64-unknown-linux -rtlib=platform \
-// RUN: -static-libgcc -static \
+// RUN: -static=rtlib -static \
 // RUN: --gcc-toolchain="" \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-LD-64-STATIC %s
Index: 

[PATCH] D67058: [clang][CodeGen] Add alias for cpu_dispatch function with IFunc & Fix resolver linkage type

[Sr.Zhang via Phabricator via cfe-commits]

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



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:3005
 /*ForVTable=*/false);
+auto Linkage = (FD->isCPUDispatchMultiVersion() || 
FD->isCPUSpecificMultiVersion())
+? llvm::Function::LinkOnceODRLinkage

erichkeane wrote:
> I think this can always just be LinkOnceODR.
Changing this also changes linkage for attribute(target()), should I also 
change test cases for them? (including test/CodeGen{,CXX}/attr-*.ll)


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

https://reviews.llvm.org/D67058



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

[PATCH] D67253: clang-misexpect: a standalone tool for verifying the use of __builtin_expect with PGO data

[Paul Kirth via Phabricator via cfe-commits]

paulkirth created this revision.
paulkirth added reviewers: phosek, leonardchan, nickdesaulniers.
Herald added subscribers: llvm-commits, cfe-commits, hiraditya, mgorny.
Herald added projects: clang, LLVM.

This is a continuation of the work in D66324  
that creates a standalone tool that can simply be run over an entire codebase 
through the use of a compile commands database. This simplifies the need to 
support custom build targets to check a project's use of `__builtin_expect()`.

The design is fairly straightforward: use a libTooling executor to walk the 
compilation database, and run the compiler over each target after curating some 
compiler flags.  Mainly, we remove any incompatible flags, and then configure 
the codegen options to support using the selected type of profile data. We also 
process the LLVMArgs, as libTooling executors seem to bypass the normal 
mechanisms for passing flags to the LLVM backend. Other than these few changes 
we rely on the existing compiler infrastructure to generate our diagnostics.

Currently the use of the `CodeGenAction` with the libTooling Executor seems to 
be surfacing some race conditions within the compiler infrastructure. For now I 
plan to limit the concurrency of the executor to run single threaded, but 
eventually, I would like to have this run with full parallelism. If a 
`CodeGenAction` can never be safely run in parallel, then it may become 
necessary to use an external driver script, similar to  `run_clang_tidy.py` to 
take advantage of parallelism.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D67253

Files:
  clang-tools-extra/CMakeLists.txt
  clang-tools-extra/clang-misexpect/CMakeLists.txt
  clang-tools-extra/clang-misexpect/ClangMisExpect.cpp
  clang-tools-extra/clang-misexpect/ClangMisExpect.h
  clang-tools-extra/clang-misexpect/tool/CMakeLists.txt
  clang-tools-extra/clang-misexpect/tool/ClangMisExpectMain.cpp
  clang/cmake/caches/Fuchsia-stage2.cmake
  llvm/lib/Transforms/Utils/MisExpect.cpp

Index: llvm/lib/Transforms/Utils/MisExpect.cpp
===
--- llvm/lib/Transforms/Utils/MisExpect.cpp
+++ llvm/lib/Transforms/Utils/MisExpect.cpp
@@ -43,7 +43,8 @@
 static cl::opt PGOWarnMisExpect(
 "pgo-warn-misexpect", cl::init(false), cl::Hidden,
 cl::desc("Use this option to turn on/off "
- "warnings about incorrect usage of llvm.expect intrinsics."));
+ "warnings about incorrect usage of llvm.expect intrinsics."),
+cl::ZeroOrMore);
 
 } // namespace llvm
 
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -207,6 +207,7 @@
   LTO
   clang-apply-replacements
   clang-doc
+  clang-misexpect
   clang-format
   clang-resource-headers
   clang-include-fixer
Index: clang-tools-extra/clang-misexpect/tool/ClangMisExpectMain.cpp
===
--- /dev/null
+++ clang-tools-extra/clang-misexpect/tool/ClangMisExpectMain.cpp
@@ -0,0 +1,124 @@
+//===-- ClangMisExpectMain.cpp - ClangMisexpect -*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file implements the main function for clang misexpect. It uses a
+// libTooling exectutor to check each file in the compiler_commands.json against
+// a provided PGO profile. When profile counters disagree with the compiler's
+// threshold values for likely and unlike branches clang-misexpect will issue a
+// diagnostic message.
+//
+//===--===//
+
+#include "../ClangMisExpect.h"
+#include "clang/Basic/CodeGenOptions.h"
+#include "clang/Basic/LLVM.h"
+#include "clang/Tooling/AllTUsExecution.h"
+#include "clang/Tooling/ArgumentsAdjusters.h"
+#include "clang/Tooling/CommonOptionsParser.h"
+#include "clang/Tooling/Execution.h"
+#include "clang/Tooling/Tooling.h"
+#include "llvm/ADT/Optional.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/Support/Path.h"
+#include "llvm/Support/Signals.h"
+#include 
+
+using namespace clang;
+using namespace clang::tooling;
+using namespace clang::misexpect;
+using Path = std::string;
+
+static llvm::cl::extrahelp CommonHelp(CommonOptionsParser::HelpMessage);
+static llvm::cl::OptionCategory
+ClangMisExpectCategory("clang-misexpect options");
+
+static llvm::cl::opt ProfileDir(
+"profile-dir",
+llvm::cl::desc(
+"Specify a path to the profile data to use during validation"),
+llvm::cl::cat(ClangMisExpectCategory));
+
+static llvm::cl::opt ProfFormat(
+

[PATCH] D67058: [clang][CodeGen] Add alias for cpu_dispatch function with IFunc & Fix resolver linkage type

[Sr.Zhang via Phabricator via cfe-commits]

zsrkmyn added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:3002
 false);
 llvm::Constant *Resolver = GetOrCreateLLVMFunction(
 MangledName + ".resolver", ResolverType, GlobalDecl{},

erichkeane wrote:
> This Resolver should have the same linkage as below.
Actually, I wanted to set linkage here at the first time, but failed. When 
compiling code with cpu_specific but no cpu_dispatch, we cannot set it as 
LinkOnceODR or WeakODR. E.g.:

```
$ cat specific_only.c
__declspec(cpu_specific(pentium_iii))
int foo(void) { return 0; }
int usage() { return foo(); }

$ clang -fdeclspec specific_only.c  
   
Global is external, but doesn't have external or weak linkage!  
  
i32 ()* ()* @foo.resolver   
  
fatal error: error in backend: Broken module found, compilation aborted!   
```

This is found by lit test test/CodeGen/attr-cpuspecific.c, in which 
'SingleVersion()' doesn't have a cpu_dispatch declaration.


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

https://reviews.llvm.org/D67058



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

[PATCH] D67208: [WebAssembly] Add -fwasm-exceptions for wasm EH

[Heejin Ahn via Phabricator via cfe-commits]

aheejin added a comment.

In D67208#1660041 , @sbc100 wrote:

>   `-pthreads`  enabling `-matomics` and `-mbulk-memory`make some sense 
> because each of those low level flags might make sense on its own.   But if 
> `-fwasm-exceptions` only going to enable `-mexception-handling` then I'm not 
> sure I see the point in adding it.  Or is there something else it will enable?


I think I didn't provide enough motives; let me explain this over again.
**tl;dr: I think `-fwasm-exceptions`is necessary. Something we should decide is 
whether we should make `-mexception-handling` turn it on automatically.**

1. Why we need `LangOptions::WasmExceptions`

What we need to additionally set besides `-mattr=+exception-handling` in the 
backend is `-exception-model=wasm`, which sets the exception model 
.
 (We need to set this programmatically. I used `llc` options just for 
illustration) This part corresponds to this code in 
`clang/lib/CodeGen/BackendUtil.cpp` above.

  if (LangOpts.WasmExceptions)
Options.ExceptionModel = llvm::ExceptionHandling::Wasm;

If we don't have `LangOption::WasmExceptions`, we would need to invoke target 
features to set this option, which is not very clean and inconsistent with 
other exception models.

Also, because we didn't have `LangOptions::WasmExceptions`, the current code 
for selecting personality function 

 is not very clear. This CL fixes this too.

2. Why we need `-fwasm-exceptions`

`-fwasm-exceptions` is the means to set `LangOptions::WasmExceptions`. Please 
see the code for `clang/lib/Frontend/CompilerInvocation.cpp` in this CL.

  Arg *A = Args.getLastArg(
  options::OPT_fsjlj_exceptions, options::OPT_fseh_exceptions,
  options::OPT_fdwarf_exceptions, options::OPT_fwasm_exceptions);
  if (A) {
...
Opts.SjLjExceptions = Opt.matches(options::OPT_fsjlj_exceptions);
Opts.SEHExceptions = Opt.matches(options::OPT_fseh_exceptions);
Opts.DWARFExceptions = Opt.matches(options::OPT_fdwarf_exceptions);
Opts.WasmExceptions = Opt.matches(options::OPT_fwasm_exceptions);
  }

If we don't have `options::OPT_fwasm_exceptions` there, the code to determine 
whether we have to set `Opts.WasmExceptions` will be not very clean and 
inconsistent with other model options.
(Here this `Opts.WasmExceptions` will be the same as `LangOpts.WasmExceptions` 
in `clang/lib/CodeGen/BackendUtil.cpp` above.)

3. Why I think choosing `-fwasm-exceptions`, not `-mexception-handling`, as the 
controlling option, is better

Given that we need `-fwasm-exceptions` anyway (according to 1 and 2 above), I 
think `-fwasm-exceptions` sets `-mexception-handling` makes more sense than the 
other way around. Also, as I said above, I'm not sure if using architectural 
flags to control features is a good idea. They are pretty low-level, and they 
only exist because wasm features are developed one by one; if we were able to 
put everything into MVP they wouldn't exist. Wouldn't we someday turn on all 
these architectural flags on by default? And it's possible that we want to use 
the current emscripten-based exception even if we have all architectural 
features turned on.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67208



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

[PATCH] D67249: [Modules][PCH] Hash input files content

[Adrian Prantl via Phabricator via cfe-commits]

aprantl added a comment.

Nice! Are you planning to address the FIXME's in a later update of this patch?




Comment at: clang/lib/Serialization/ASTWriter.cpp:1767
   bool IsTopLevelModuleMap;
+  uint32_t ContentHash[2];
 };

Why is this not a uint64_t?



Comment at: clang/test/Modules/validate-file-content.m:14
+// RUN: %clang_cc1 -emit-pch -fmodules-cache-path=%t/cache -fmodules 
-fimplicit-module-maps -o %t/a.pch -I %t -x objective-c-header %t/a.h 
-fvalidate-ast-input-files-content
+// RUN: touch -m -a -A 01 %t/m.h
+// RUN: %clang_cc1 -fsyntax-only -fmodules-cache-path=%t/cache -fmodules 
-fimplicit-module-maps -I %t -include-pch %t/a.pch %s -verify 
-fvalidate-ast-input-files-content

Are there other tests that use touch and file timestamps in general? I wonder 
if this could cause random issues when building on NFS or filesystems with a 
really low timestamp granularity. I don't have a better suggestion either since 
the mtime is part of the code being tested here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67249



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

[PATCH] D67200: Add -static-openmp driver option

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

Instead of more `-static-foobar`, maybe we need `-static=foobar,stdlib,rtlib` 
instead?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67200



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

[PATCH] D67208: [WebAssembly] Add -fwasm-exceptions for wasm EH

[Heejin Ahn via Phabricator via cfe-commits]

aheejin added a comment.

In D67208#1660041 , @sbc100 wrote:

>   `-pthreads`  enabling `-matomics` and `-mbulk-memory`make some sense 
> because each of those low level flags might make sense on its own.   But if 
> `-fwasm-exceptions` only going to enable `-mexception-handling` then I'm not 
> sure I see the point in adding it.  Or is there something else it will enable?


We also needs to enable `-exception-model=wasm` in the backend... but we want 
to enable that if `-mexception-handling` is given, as you said.

The more important reason is I'm not sure if using architectural flags to 
control features is a good idea. They are pretty low-level, and they only exist 
because we develop wasm features are developed one by one; if we were able to 
put everything into MVP they wouldn't exist. Wouldn't we someday turn on all 
these architectural flags on by default? And it's possible that we want to use 
the current emscripten-based exception even if we have all architectural 
features turned on.

The other reason is for consistency with other exception model flags: All 
exception handling options here 

 except ARM has its own `-f***-exceptions` option.

Anyway, that's my reasoning, but people might disagree. What do you think? 
@dschuff @tlively


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67208



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

[PATCH] D67200: Add -static-openmp driver option

[Stephen Hines via Phabricator via cfe-commits]

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

Looks really nice. I am sure the NDK developers will be happy to see support 
for static OpenMP. Do you want to add the public NDK github issue link in the 
commit message?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67200



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

[PATCH] D67249: [Modules][PCH] Hash input files content

[Bruno Cardoso Lopes via Phabricator via cfe-commits]

bruno created this revision.
bruno added reviewers: dexonsmith, arphaman, rsmith, aprantl.
Herald added subscribers: cfe-commits, jkorous.
Herald added a project: clang.

When files often get touched during builds, the mtime based validation
leads to different problems in implicit modules builds, even when the
content doesn't actually change:

- Modules only: module invalidation due to out of date files. Usually

causing rebuild traffic.

- Modules + PCH: build failures because clang cannot rebuild a module if

it comes from building a PCH.

- PCH: build failures because clang cannot rebuild a PCH in case one of

the input headers has different mtime.

This patch proposes hashing the content of input files (headers and
module maps), which is performed during serialization time. When looking
at input files for validation, clang only computes the hash in case
there's a mtime mismatch.

I've tested a couple of different hash algorithms availble in LLVM in
face of building modules+pch for `#import `:

- `hash_code`: performace diff within the noise, total module cache

increased by 0.07%.

- `SHA1`: 5% slowdown. Haven't done real size measurements, but it'd be

BLOCK_ID+20 bytes per input file, instead of BLOCK_ID+8 bytes from
`hash_code`.

- `MD5`: 3% slowdown. Like above, but BLOCK_ID+16 bytes per input file.

Given the numbers above, the patch uses `hash_code`. The patch also
improves invalidation error msgs to point out which type of problem the
user is facing: "mtime", "size" or "content".

rdar://problem/29320105


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D67249

Files:
  clang/include/clang/Basic/DiagnosticSerializationKinds.td
  clang/include/clang/Driver/Options.td
  clang/include/clang/Lex/HeaderSearchOptions.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/Serialization/ASTReader.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/Modules/validate-file-content.m
  clang/test/PCH/validate-file-content.m

Index: clang/test/PCH/validate-file-content.m
===
--- /dev/null
+++ clang/test/PCH/validate-file-content.m
@@ -0,0 +1,29 @@
+// REQUIRES: shell
+//
+// Check driver works
+// RUN: %clang -x objective-c-header -fsyntax-only -fpch-validate-input-files-content %t/a.h -### 2>&1 | FileCheck --check-prefix=CHECK-CC1 %s
+// CHECK-CC1: -fvalidate-ast-input-files-content
+//
+// PCH only: Test that a mtime mismatch without content change is fine
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: echo '// m.h' > %t/m.h
+// RUN: echo '#include "m.h"' > %t/a.h
+// RUN: %clang_cc1 -emit-pch -o %t/a.pch -I %t -x objective-c-header %t/a.h -fvalidate-ast-input-files-content
+// RUN: touch -m -a -A 01 %t/m.h
+// RUN: %clang_cc1 -fsyntax-only -I %t -include-pch %t/a.pch %s -verify -fvalidate-ast-input-files-content
+//
+// PCH only: Test that a mtime mismatch with content change
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: echo '// m.h' > %t/m.h
+// RUN: echo '#include "m.h"' > %t/a.h
+// RUN: %clang_cc1 -emit-pch -o %t/a.pch -I %t -x objective-c-header %t/a.h -fvalidate-ast-input-files-content
+// RUN: echo '// m.x' > %t/m.h
+// RUN: touch -m -a -A 01 %t/m.h
+// RUN: not %clang_cc1 -fsyntax-only -I %t -include-pch %t/a.pch %s -fvalidate-ast-input-files-content 2> %t/stderr
+// RUN: FileCheck %s < %t/stderr
+//
+// CHECK: file '[[M_H:.*[/\\]m\.h]]' has been modified since the precompiled header '[[A_PCH:.*/a\.pch]]' was built: content changed
+// CHECK: please rebuild precompiled header '[[A_PCH]]'
+// expected-no-diagnostics
Index: clang/test/Modules/validate-file-content.m
===
--- /dev/null
+++ clang/test/Modules/validate-file-content.m
@@ -0,0 +1,33 @@
+// REQUIRES: shell
+//
+// Check driver works
+// RUN: %clang -fmodules -fsyntax-only -fmodules-validate-input-files-content %s -### 2>&1 | FileCheck --check-prefix=CHECK-CC1 %s
+// CHECK-CC1: -fvalidate-ast-input-files-content
+//
+// PCH+Modules: Test that a mtime mismatch without content change is fine
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: echo '// m.h' > %t/m.h
+// RUN: echo '#include "m.h"' > %t/a.h
+// RUN: echo 'module m { header "m.h" }' > %t/module.modulemap
+// RUN: %clang_cc1 -emit-pch -fmodules-cache-path=%t/cache -fmodules -fimplicit-module-maps -o %t/a.pch -I %t -x objective-c-header %t/a.h -fvalidate-ast-input-files-content
+// RUN: touch -m -a -A 01 %t/m.h
+// RUN: %clang_cc1 -fsyntax-only -fmodules-cache-path=%t/cache -fmodules -fimplicit-module-maps -I %t -include-pch %t/a.pch %s -verify -fvalidate-ast-input-files-content
+//
+// PCH+Modules: Test that a mtime mismatch with content change
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: echo '// m.h' > %t/m.h
+// RUN: echo '#include "m.h"' > %t/a.h
+// RUN: 

[PATCH] D65761: Add Windows Control Flow Guard checks (/guard:cf).

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a subscriber: hans.
rnk added a comment.

Here is some feedback, I apologize for dragging my feet.

Also, I would really like to get feedback from @pcc. He's OOO currently, though.




Comment at: clang/include/clang/Driver/Options.td:500
 def b : JoinedOrSeparate<["-"], "b">, Flags<[Unsupported]>;
+def cfguard_no_checks : Flag<["-"], "cfguard-no-checks">, Flags<[CC1Option]>,
+  HelpText<"Emit Windows Control Flow Guard tables only (no checks).">;

@hans, WDYT about the -cc1 interface? I think this is fine.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5972
+if (Instrument && !NoChecks)
+  //Emit CFG instrumentation and the table of address-taken functions.
   CmdArgs.push_back("-cfguard");

Comment formatting needs to be fixed, you can use clang-format for this.



Comment at: llvm/include/llvm/CodeGen/MachineBasicBlock.h:179
+assert((!CachedMCSymbol || LabelIsPublic == true) && "Cannot set label to 
public after it has been accessed.");
+LabelIsPublic = true; 
+  }

I hesitate to make MBB labels public, I think it might be better to build your 
own MCSymbol label with a public name.



Comment at: llvm/lib/CodeGen/CFGuardLongjmp.cpp:101
+  // targets.
+  for (MachineInstr *Setjmp : SetjmpCalls) {
+MachineBasicBlock *OldMBB = Setjmp->getParent();

Rather than changing the machine CFG, I would suggest using 
MachineInstr::setPostInstrSymbol, which I've been planning to use for exactly 
this purpose. :) You can make labels with MCContext::createSymbol, and you'll 
want to come up with symbols that won't clash with C or C++ symbols. I see MSVC 
makes labels like `$LN4`, so maybe `$cfgsjN` or something like that. I think 
MCContext will add numbers for you.



Comment at: llvm/lib/Target/X86/X86FixupCFGuard.cpp:11
+/// This file contains the machine instruction transform to fixup the Control
+/// Flow Guard checks inserted by /X86CFGuard.cpp. This pass searches
+/// for such cases and replaces the pair of instructions with a single

I guess it's not X86CFGuard.cpp now that you've generalized it as a 
cross-platform IR pass.



Comment at: llvm/lib/Target/X86/X86FixupCFGuard.cpp:57-58
+
+/// MachineFunction pass to fix x86 Control Flow Guard checks that have been
+/// generated as separate load and call/invoke instructions.
+class X86FixupCFGuard : public MachineFunctionPass {

Can you elaborate on what the correctness requirement is? The correctness 
requirement is just that the loaded value is not saved in a CSR which is then 
spilled and reloaded from memory across a call site. If possible, I think it 
would be worth teaching both FastISel and SDISel to build the correct 
MachineInstrs during instruction selection, and turn this into a validation 
pass that fails if it sees indirect calls through registers in functions where 
CFG is enabled.



Comment at: llvm/lib/Target/X86/X86FixupCFGuard.cpp:114
+OldCallOpcode = X86::CALL64r;
+NewCallOpcode = X86::CALL64m;
+  } else {

I think you probably also want to look for tail calls. I think the best way to 
do this would be to use `MI.isCall()` in the loop, and then switch on the 
opcode to handle all call variants.



Comment at: llvm/lib/Target/X86/X86FixupCFGuard.cpp:134
+  // load instruction
+  for (auto I = LoadMI.getIterator(), E = MBB->instr_end(); I != E; ++I) {
+MachineInstr  = cast(*I);

Is it possible to use MachineRegisterInfo to iterate over all the uses of the 
load, instead of scanning the BB? It seems like this could be O(n^2) if a 
single BB contains a long sequence of indirect calls. I think it would look 
like this:
  MachineRegisterInfo *MRI = MF.getRegInfo();
  for (MachineInstr  : MRI->use_instructions(Reg))
// do something with MI
There's also use_operands.



Comment at: llvm/lib/Target/X86/X86FixupCFGuard.cpp:168-170
+  // Erase all marked call/invoke instructions
+  for (MachineInstr *MI : MIsToErase) {
+MI->eraseFromParent();

Erasing at the end is always the safest way to do it. :)



Comment at: llvm/lib/Target/X86/X86FixupCFGuard.cpp:209
+  for (MachineInstr *LoadMI : GuardLoads) {
+fixupGuardLoad(*LoadMI, TII);
+

This doesn't do anything with the return value, should it?



Comment at: llvm/lib/Transforms/CFGuard/CFGuard.cpp:38
+/// architectures (e.g. X86_32 uses cf_check, X86_64 uses cf_dispatch).
+class CFGuard : public ModulePass {
+public:

Does this need to be a ModulePass? It's preferable to avoid module passes if 
possible. When the pass manager has a sequence of function passes to run, it 
runs all passes on function f, then g, then h, and so on, rather than running 
the function pass over the entire module and 

Re: r371004 - [c++20] Fix some ambiguities in our mangling of lambdas with explicit

[Nico Weber via cfe-commits]

On Wed, Sep 4, 2019 at 9:22 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Wed Sep  4 18:23:47 2019
> New Revision: 371004
>
> URL: http://llvm.org/viewvc/llvm-project?rev=371004=rev
> Log:
> [c++20] Fix some ambiguities in our mangling of lambdas with explicit
> template parameters.
>
> This finishes the implementation of the proposal described in
> https://github.com/itanium-cxx-abi/cxx-abi/issues/31. (We already
> implemented the  extensions, but didn't take them into
> account when computing mangling numbers, and didn't deal properly with
> expanded parameter packs, and didn't disambiguate between different
> levels of template parameters in manglings.)
>
> Modified:
> cfe/trunk/include/clang/AST/Mangle.h
> cfe/trunk/lib/AST/DeclBase.cpp
> cfe/trunk/lib/AST/ItaniumCXXABI.cpp
> cfe/trunk/lib/AST/ItaniumMangle.cpp
> cfe/trunk/lib/Sema/SemaLambda.cpp
> cfe/trunk/test/CodeGenCXX/mangle-lambda-explicit-template-params.cpp
>
> Modified: cfe/trunk/include/clang/AST/Mangle.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Mangle.h?rev=371004=371003=371004=diff
>
> ==
> --- cfe/trunk/include/clang/AST/Mangle.h (original)
> +++ cfe/trunk/include/clang/AST/Mangle.h Wed Sep  4 18:23:47 2019
> @@ -170,6 +170,8 @@ public:
>virtual void mangleCXXDtorComdat(const CXXDestructorDecl *D,
> raw_ostream &) = 0;
>
> +  virtual void mangleLambdaSig(const CXXRecordDecl *Lambda, raw_ostream
> &) = 0;
> +
>static bool classof(const MangleContext *C) {
>  return C->getKind() == MK_Itanium;
>}
>
> Modified: cfe/trunk/lib/AST/DeclBase.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclBase.cpp?rev=371004=371003=371004=diff
>
> ==
> --- cfe/trunk/lib/AST/DeclBase.cpp (original)
> +++ cfe/trunk/lib/AST/DeclBase.cpp Wed Sep  4 18:23:47 2019
> @@ -12,6 +12,7 @@
>
>  #include "clang/AST/DeclBase.h"
>  #include "clang/AST/ASTContext.h"
> +#include "clang/AST/ASTLambda.h"
>  #include "clang/AST/ASTMutationListener.h"
>  #include "clang/AST/Attr.h"
>  #include "clang/AST/AttrIterator.h"
> @@ -1043,6 +1044,12 @@ DeclContext *DeclContext::getLookupParen
>  getLexicalParent()->getRedeclContext()->isRecord())
>return getLexicalParent();
>
> +  // A lookup within the call operator of a lambda never looks in the
> lambda
> +  // class; instead, skip to the context in which that closure type is
> +  // declared.
> +  if (isLambdaCallOperator(this))
> +return getParent()->getParent();
> +
>return getParent();
>  }
>
>
> Modified: cfe/trunk/lib/AST/ItaniumCXXABI.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ItaniumCXXABI.cpp?rev=371004=371003=371004=diff
>
> ==
> --- cfe/trunk/lib/AST/ItaniumCXXABI.cpp (original)
> +++ cfe/trunk/lib/AST/ItaniumCXXABI.cpp Wed Sep  4 18:23:47 2019
> @@ -19,10 +19,12 @@
>  #include "CXXABI.h"
>  #include "clang/AST/ASTContext.h"
>  #include "clang/AST/DeclCXX.h"
> +#include "clang/AST/Mangle.h"
>  #include "clang/AST/MangleNumberingContext.h"
>  #include "clang/AST/RecordLayout.h"
>  #include "clang/AST/Type.h"
>  #include "clang/Basic/TargetInfo.h"
> +#include "llvm/ADT/FoldingSet.h"
>  #include "llvm/ADT/iterator.h"
>
>  using namespace clang;
> @@ -73,10 +75,33 @@ struct DecompositionDeclName {
>  }
>
>  namespace llvm {
> +template bool isDenseMapKeyEmpty(T V) {
> +  return llvm::DenseMapInfo::isEqual(
> +  V, llvm::DenseMapInfo::getEmptyKey());
> +}
> +template bool isDenseMapKeyTombstone(T V) {
> +  return llvm::DenseMapInfo::isEqual(
> +  V, llvm::DenseMapInfo::getTombstoneKey());
> +}
> +
> +template
> +Optional areDenseMapKeysEqualSpecialValues(T LHS, T RHS) {
> +  bool LHSEmpty = isDenseMapKeyEmpty(LHS);
> +  bool RHSEmpty = isDenseMapKeyEmpty(RHS);
> +  if (LHSEmpty || RHSEmpty)
> +return LHSEmpty && RHSEmpty;
> +
> +  bool LHSTombstone = isDenseMapKeyTombstone(LHS);
> +  bool RHSTombstone = isDenseMapKeyTombstone(RHS);
> +  if (LHSTombstone || RHSTombstone)
> +return LHSTombstone && RHSTombstone;
> +
> +  return None;
> +}
> +
>  template<>
>  struct DenseMapInfo {
>using ArrayInfo = llvm::DenseMapInfo>;
> -  using IdentInfo = llvm::DenseMapInfo;
>static DecompositionDeclName getEmptyKey() {
>  return {ArrayInfo::getEmptyKey()};
>}
> @@ -88,10 +113,10 @@ struct DenseMapInfo  return llvm::hash_combine_range(Key.begin(), Key.end());
>}
>static bool isEqual(DecompositionDeclName LHS, DecompositionDeclName
> RHS) {
> -if (ArrayInfo::isEqual(LHS.Bindings, ArrayInfo::getEmptyKey()))
> -  return ArrayInfo::isEqual(RHS.Bindings, ArrayInfo::getEmptyKey());
> -if (ArrayInfo::isEqual(LHS.Bindings, 

[PATCH] D67024: [analyzer] NFC: Replace intrusive list of bug reports with a vector of pointers.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ updated this revision to Diff 219011.
NoQ added a comment.

Fxd, thanks!


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

https://reviews.llvm.org/D67024

Files:
  clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
  clang/lib/StaticAnalyzer/Core/BugReporter.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp

Index: clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -3004,8 +3004,8 @@
 llvm::make_range(BR.EQClasses_begin(), BR.EQClasses_end());
 
 for (const auto  : EQClasses) {
-  for (const BugReport  : EQ) {
-const auto *PR = dyn_cast();
+  for (const auto  : EQ.getReports()) {
+const auto *PR = dyn_cast(I.get());
 if (!PR)
   continue;
 const ExplodedNode *EN = PR->getErrorNode();
@@ -3135,7 +3135,8 @@
 // Iterate through the reports and get their nodes.
 for (BugReporter::EQClasses_iterator
EI = BR.EQClasses_begin(), EE = BR.EQClasses_end(); EI != EE; ++EI) {
-  const auto *R = dyn_cast(&*EI->begin());
+  const auto *R =
+  dyn_cast(EI->getReports().begin()->get());
   if (!R)
 continue;
   const auto *N = const_cast(R->getErrorNode());
Index: clang/lib/StaticAnalyzer/Core/BugReporter.cpp
===
--- clang/lib/StaticAnalyzer/Core/BugReporter.cpp
+++ clang/lib/StaticAnalyzer/Core/BugReporter.cpp
@@ -2798,17 +2798,17 @@
 
 BugReport *PathSensitiveBugReporter::findReportInEquivalenceClass(
 BugReportEquivClass , SmallVectorImpl ) {
-  BugReportEquivClass::iterator I = EQ.begin(), E = EQ.end();
+  auto I = EQ.getReports().begin(), E = EQ.getReports().end();
   assert(I != E);
-  const BugType& BT = I->getBugType();
+  const BugType& BT = (*I)->getBugType();
 
   // If we don't need to suppress any of the nodes because they are
   // post-dominated by a sink, simply add all the nodes in the equivalence class
   // to 'Nodes'.  Any of the reports will serve as a "representative" report.
   if (!BT.isSuppressOnSink()) {
-BugReport *R = &*I;
-for (auto  : EQ) {
-  if (auto *PR = dyn_cast()) {
+BugReport *R = I->get();
+for (auto  : EQ.getReports()) {
+  if (auto *PR = dyn_cast(J.get())) {
 R = PR;
 bugReports.push_back(PR);
   }
@@ -2825,7 +2825,7 @@
   BugReport *exampleReport = nullptr;
 
   for (; I != E; ++I) {
-auto *R = dyn_cast(&*I);
+auto *R = dyn_cast(I->get());
 if (!R)
   continue;
 
Index: clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
===
--- clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
+++ clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
@@ -72,7 +72,7 @@
 
 /// This class provides an interface through which checkers can create
 /// individual bug reports.
-class BugReport : public llvm::ilist_node {
+class BugReport {
 public:
   enum class Kind { Basic, PathSensitive };
 
@@ -465,28 +465,21 @@
   friend class BugReporter;
 
   /// List of *owned* BugReport objects.
-  llvm::ilist Reports;
+  llvm::SmallVector, 4> Reports;
 
-  void AddReport(std::unique_ptr R) {
-Reports.push_back(R.release());
+  void AddReport(std::unique_ptr &) {
+Reports.push_back(std::move(R));
   }
 
 public:
   BugReportEquivClass(std::unique_ptr R) { AddReport(std::move(R)); }
 
+  ArrayRef> getReports() const { return Reports; }
+
   void Profile(llvm::FoldingSetNodeID& ID) const {
 assert(!Reports.empty());
-Reports.front().Profile(ID);
+Reports.front()->Profile(ID);
   }
-
-  using iterator = llvm::ilist::iterator;
-  using const_iterator = llvm::ilist::const_iterator;
-
-  iterator begin() { return Reports.begin(); }
-  iterator end() { return Reports.end(); }
-
-  const_iterator begin() const { return Reports.begin(); }
-  const_iterator end() const { return Reports.end(); }
 };
 
 //===--===//
@@ -573,7 +566,7 @@
   virtual BugReport *
   findReportInEquivalenceClass(BugReportEquivClass ,
SmallVectorImpl ) {
-return &*eqClass.begin();
+return eqClass.getReports().begin()->get();
   }
 
 protected:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67247: Added missing unqualified name lookup of operator overloads for fold expressions

[Jonathan Meier via Phabricator via cfe-commits]

jonathanmeier created this revision.
jonathanmeier added reviewers: clang, rsmith.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Valid operator overloads for fold expressions are not found in the current 
scope, since unqualified name lookup is not performed.

This is a proposal to fix Bug 30590 
 (and its duplicates Bug 30738 
 and Bug 42518 
). The core issue is that fold 
expressions get expanded during template instantiation (second phase of name 
lookup) when the current scope is not available anymore (current scope is 
available in the first phase of name lookup, i.e. while parsing the template 
definition).

My approach is to attach to the fold expression the operator overload 
candidates found by the unqualified name lookup while parsing. During template 
instantiation these candidates are then considered when the fold expressions 
are expanded and the actual binary operations are built.

Please comment on whether you deem this a reasonable approach or if you know of 
a better way of solving the issue.


Repository:
  rC Clang

https://reviews.llvm.org/D67247

Files:
  clang/include/clang/AST/ExprCXX.h
  clang/include/clang/AST/UnresolvedSet.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/lib/Sema/SemaTemplateVariadic.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/test/SemaTemplate/cxx1z-fold-expressions.cpp

Index: clang/test/SemaTemplate/cxx1z-fold-expressions.cpp
===
--- clang/test/SemaTemplate/cxx1z-fold-expressions.cpp
+++ clang/test/SemaTemplate/cxx1z-fold-expressions.cpp
@@ -102,3 +102,49 @@
 
   Sum<1>::type<1, 2> x; // expected-note {{instantiation of}}
 }
+
+namespace N {
+  
+  struct A { int i; };
+  struct B { int i; };
+  
+  constexpr B operator+(const B& a, const B& b) { return { a.i + b.i }; }
+  
+}
+
+struct C { int i; };
+
+constexpr C operator+(const C& a, const C& b) { return { a.i + b.i }; }
+constexpr N::A operator+(const N::A& a, const N::A& b) { return { a.i + b.i }; }
+
+template constexpr auto custom_fold(T1 t1, T2 ...t2) {
+  return (t2 + ...) + (... + t2) + (t2 + ... + t1) + (t1 + ... + t2);
+}
+
+static_assert(custom_fold(N::A{1}, N::A{2}, N::A{3}, N::A{4}, N::A{5}).i == 58);
+static_assert(custom_fold(N::B{1}, N::B{2}, N::B{3}, N::B{4}, N::B{5}).i == 58);
+static_assert(custom_fold(C{1}, C{2}, C{3}, C{4}, C{5}).i == 58);
+
+template constexpr auto func_fold(
+decltype((T{ I2 } + ...) + (... + T{ I2 }) + (T{ I2 } + ... + T{ I1 }) + (T{ I1 } + ... + T{ I2 })) t) {
+  return t.i;
+}
+
+static_assert(func_fold(N::A{ 42 }) == 42);
+static_assert(func_fold(N::B{ 42 }) == 42);
+static_assert(func_fold(C{ 42 }) == 42);
+
+struct D { int i; };
+
+namespace N {
+  
+  constexpr D operator+(const D& a, const D& b) { return { a.i + b.i }; }
+  
+}
+
+template constexpr auto custom_fold_using(T1 t1, T2 ...t2) {
+  using N::operator+;
+  return (t2 + ...) + (... + t2) + (t2 + ... + t1) + (t1 + ... + t2);
+}
+
+static_assert(custom_fold_using(D{1}, D{2}, D{3}, D{4}, D{5}).i == 58);
Index: clang/lib/Serialization/ASTWriterStmt.cpp
===
--- clang/lib/Serialization/ASTWriterStmt.cpp
+++ clang/lib/Serialization/ASTWriterStmt.cpp
@@ -1817,6 +1817,7 @@
 
 void ASTStmtWriter::VisitCXXFoldExpr(CXXFoldExpr *E) {
   VisitExpr(E);
+  Record.push_back(E->getNumOverloadCands());
   Record.AddSourceLocation(E->LParenLoc);
   Record.AddSourceLocation(E->EllipsisLoc);
   Record.AddSourceLocation(E->RParenLoc);
@@ -1824,6 +1825,12 @@
   Record.AddStmt(E->SubExprs[0]);
   Record.AddStmt(E->SubExprs[1]);
   Record.push_back(E->Opcode);
+  for (UnresolvedSetIterator I = E->overloadCandsBegin(),
+ End = E->overloadCandsEnd();
+   I != End; ++I) {
+Record.AddDeclRef(I.getDecl());
+Record.push_back(I.getAccess());
+  }
   Code = serialization::EXPR_CXX_FOLD;
 }
 
Index: clang/lib/Serialization/ASTReaderStmt.cpp
===
--- clang/lib/Serialization/ASTReaderStmt.cpp
+++ clang/lib/Serialization/ASTReaderStmt.cpp
@@ -1883,6 +1883,7 @@
 
 void ASTStmtReader::VisitCXXFoldExpr(CXXFoldExpr *E) {
   VisitExpr(E);
+  unsigned NumOverloadCands = Record.readInt();
   E->LParenLoc = ReadSourceLocation();
   E->EllipsisLoc = ReadSourceLocation();
   E->RParenLoc = ReadSourceLocation();
@@ -1890,6 +1891,13 @@
   E->SubExprs[0] = Record.readSubExpr();
   E->SubExprs[1] = Record.readSubExpr();
   E->Opcode = (BinaryOperatorKind)Record.readInt();
+
+  DeclAccessPair *OverloadCands = E->getTrailingObjects();
+  for (unsigned I = 0; I != NumOverloadCands; ++I) {
+   

[PATCH] D66572: [analyzer] NFC: BugReporter Separation Ep.I.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added inline comments.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h:122
+  /// Get the location on which the report should be uniqued.
+  virtual PathDiagnosticLocation getUniqueingLocation() const {
+return Location;

gribozavr wrote:
> NoQ wrote:
> > gribozavr wrote:
> > > Where can I read about the uniqueing logic? Does it mean that out of two 
> > > bug reports with the same location only one gets displayed, regardless of 
> > > other properties?
> > Added some comments ^^
> Thanks for the comments, but sorry, this one is still unclear.
> 
> (1)
> 
> ```
> // Imagine a ClangTidy checker that finds calls to math functions where it is 
> 
> double foo() {
>   return sqrt(-1); // warning: 'sqrt' will always return NaN
> }
> ```
> 
> What should be the "decl with issue" here? 'foo' or 'sqrt'?
> 
> (2)
> 
> ```
> #include 
> using std::vector; // warning: using names from 'std' is error-prone
> ```
> 
> (3)
> 
> ```
> void foo(Foo f) {
>   bar(std::move(f)); // warning: passing result of 'std::move' as a const 
> reference argument, no move will actually happen
> }
> ```
> 
> Is it 'foo', 'bar', 'std::move', or the copy constructor of 'Foo'?
Made another attempt at the decl with issue comment :)



Comment at: 
clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h:126-135
+  /// Get the declaration containing the uniqueing location.
+  virtual const Decl *getUniqueingDecl() const {
+return DeclWithIssue;
+  }
+
+  /// Return the canonical declaration, be it a method or class, where
+  /// this issue semantically occurred.

gribozavr wrote:
> NoQ wrote:
> > gribozavr wrote:
> > > I don't think `getUniqueingDecl()` and `getDeclWithIssue()` make sense 
> > > for most ClangTidy checkers.
> > `getDeclWithIssue()` corresponds to the "Function/Method" column we have in 
> > our scan-build index page:
> > 
> > {F9881207}
> > 
> > This column is not super important but probably kinda nice to have. I don't 
> > mind leaving it empty for clang-tidy checks, or possibly auto-detect it 
> > post factum when possible (e.g., find the smallest decl in which the 
> > warning location is contained).
> > 
> > `getUniqueingDecl()` is, as far as i understand, only currently used by the 
> > issue hash mechanism which governs deduplication across translation units 
> > (e.g., we emit a warning against the same header in multiple translation 
> > units - it's vital for the static analyzer because it's not uncommon for an 
> > execution path that starts in the main file to end in a header). And even 
> > then, it's only present in plist output. I'm not convinced it's useful at 
> > all. It's likely that we can remove it.
> > 
> > Also clang-tidy checks wouldn't need to specify their `UniqueingDecl` 
> > manually as it silently defaults to their `DeclWithIssue`.
> > 
> > So basically we have these two methods on the base class for bureaucratic 
> > reasons: our existing algorithms handle all kinds of warnings uniformly 
> > based on these computed properties of bug reports. I think we should be 
> > perfectly fine if some kinds of bug reports return null from them, 
> > indicating that "this property doesn't make sense for them". We could 
> > instead reinvent protocols on top of our custom RTTI ("does this warning 
> > conform to `Uniqueable`? if so, i'll try to unique it"), but i don't think 
> > it's worth the complexity.
> > `getDeclWithIssue()` corresponds to the "Function/Method" column we have in 
> > our scan-build index page:
> 
> Judging from the screenshot, that column seems to play a function of a 
> human-readable summary of the warning location. Is that correct?
> 
> Should we determine it automatically from `getLocation()`? Is there a use 
> case for `getDeclWithIssue()` be different from the function/class that 
> `getLocation()` is pointing into?
> 
> > (e.g., find the smallest decl in which the warning location is contained).
> 
> Oh you are saying the same thing. Why not have it always be auto-detected? Is 
> there a use case for manual curation?
> 
> > `getUniqueingDecl()` [...] I'm not convinced it's useful at all. It's 
> > likely that we can remove it.
> 
> I agree about eliminating it -- actually, replacing it with comparing source 
> locations. In our experience running ClangTidy, uniquing bug reports based on 
> source locations works quite well. Can you give it a go in a separate patch 
> that we can land ahead of time? I see there are only 4 callers of the 
> BugReport constructor that accepts the location.
> 
> Also the doc comment is somewhat contradictory. "declarations that ... 
> contains ... the uniqueing location. This is not actively used for 
> uniqueing..."
> Oh you are saying the same thing. Why not have it always be auto-detected? Is 
> there a use case for manual curation?

I don't think anybody needs manual curation. We just literally always had a 
good decl to put in 

[PATCH] D65256: [Sema][ObjC] Mark C union fields that have non-trivial ObjC ownership qualifications as unavailable if the union is declared in a system header

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak updated this revision to Diff 219008.
ahatanak added a comment.

Rename function to `ignoreForTrivialityComputation`.


Repository:
  rC Clang

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

https://reviews.llvm.org/D65256

Files:
  include/clang/AST/ASTContext.h
  lib/AST/ASTContext.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaType.cpp
  test/SemaObjC/Inputs/non-trivial-c-union.h
  test/SemaObjC/non-trivial-c-union.m

Index: test/SemaObjC/non-trivial-c-union.m
===
--- test/SemaObjC/non-trivial-c-union.m
+++ test/SemaObjC/non-trivial-c-union.m
@@ -1,4 +1,6 @@
-// RUN: %clang_cc1 -fsyntax-only -fblocks -fobjc-arc -fobjc-runtime-has-weak -verify %s
+// RUN: %clang_cc1 -fsyntax-only -fblocks -fobjc-arc -fobjc-runtime-has-weak -I %S/Inputs -verify %s
+
+#include "non-trivial-c-union.h"
 
 typedef union { // expected-note 12 {{'U0' has subobjects that are non-trivial to default-initialize}} expected-note 36 {{'U0' has subobjects that are non-trivial to destruct}} expected-note 28 {{'U0' has subobjects that are non-trivial to copy}}
   id f0; // expected-note 12 {{f0 has type '__strong id' that is non-trivial to default-initialize}} expected-note 36 {{f0 has type '__strong id' that is non-trivial to destruct}} expected-note 28 {{f0 has type '__strong id' that is non-trivial to copy}}
@@ -80,3 +82,7 @@
 void testVolatileLValueToRValue(volatile U0 *a) {
   (void)*a; // expected-error {{cannot use volatile type 'volatile U0' where it causes an lvalue-to-rvalue conversion since it is a union that is non-trivial to destruct}} // expected-error {{cannot use volatile type 'volatile U0' where it causes an lvalue-to-rvalue conversion since it is a union that is non-trivial to copy}}
 }
+
+void unionInSystemHeader0(U0_SystemHeader);
+
+void unionInSystemHeader1(U1_SystemHeader); // expected-error {{cannot use type 'U1_SystemHeader' for a function/method parameter since it is a union that is non-trivial to destruct}} expected-error {{cannot use type 'U1_SystemHeader' for a function/method parameter since it is a union that is non-trivial to copy}}
Index: test/SemaObjC/Inputs/non-trivial-c-union.h
===
--- /dev/null
+++ test/SemaObjC/Inputs/non-trivial-c-union.h
@@ -0,0 +1,19 @@
+// For backward compatibility, fields of C unions declared in system headers
+// that have non-trivial ObjC ownership qualifications are marked as unavailable
+// unless the qualifier is explicit and __strong.
+
+#pragma clang system_header
+
+typedef __strong id StrongID;
+
+typedef union {
+  id f0;
+  _Nonnull id f1;
+  __weak id f2;
+  StrongID f3;
+} U0_SystemHeader;
+
+typedef union { // expected-note {{'U1_SystemHeader' has subobjects that are non-trivial to destruct}} expected-note {{'U1_SystemHeader' has subobjects that are non-trivial to copy}}
+  __strong id f0; // expected-note {{f0 has type '__strong id' that is non-trivial to destruct}} expected-note {{f0 has type '__strong id' that is non-trivial to copy}}
+  _Nonnull id f1;
+} U1_SystemHeader;
Index: lib/Sema/SemaType.cpp
===
--- lib/Sema/SemaType.cpp
+++ lib/Sema/SemaType.cpp
@@ -6027,36 +6027,6 @@
   }
 }
 
-/// Does this type have a "direct" ownership qualifier?  That is,
-/// is it written like "__strong id", as opposed to something like
-/// "typeof(foo)", where that happens to be strong?
-static bool hasDirectOwnershipQualifier(QualType type) {
-  // Fast path: no qualifier at all.
-  assert(type.getQualifiers().hasObjCLifetime());
-
-  while (true) {
-// __strong id
-if (const AttributedType *attr = dyn_cast(type)) {
-  if (attr->getAttrKind() == attr::ObjCOwnership)
-return true;
-
-  type = attr->getModifiedType();
-
-// X *__strong (...)
-} else if (const ParenType *paren = dyn_cast(type)) {
-  type = paren->getInnerType();
-
-// That's it for things we want to complain about.  In particular,
-// we do not want to look through typedefs, typeof(expr),
-// typeof(type), or any other way that the type is somehow
-// abstracted.
-} else {
-
-  return false;
-}
-  }
-}
-
 /// handleObjCOwnershipTypeAttr - Process an objc_ownership
 /// attribute on the specified type.
 ///
@@ -6132,7 +6102,7 @@
   if (Qualifiers::ObjCLifetime previousLifetime
 = type.getQualifiers().getObjCLifetime()) {
 // If it's written directly, that's an error.
-if (hasDirectOwnershipQualifier(type)) {
+if (S.Context.hasDirectOwnershipQualifier(type)) {
   S.Diag(AttrLoc, diag::err_attr_objc_ownership_redundant)
 << type;
   return true;
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -15700,27 +15700,11 @@
 
   // Warn about implicitly autoreleasing indirect 

[PATCH] D67246: clang-format: Add support for formatting lambdas with explicit template parameters.

[Nico Weber via Phabricator via cfe-commits]

thakis created this revision.
thakis added a reviewer: krasimir.

Ports r359967 to clang-format.


https://reviews.llvm.org/D67246

Files:
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -12888,6 +12888,10 @@
"  return 1; //\n"
"};");
 
+  // Lambdas with explicit template argument lists.
+  verifyFormat(
+  "auto L = [] class T, class U>(T &) {};\n");
+
   // Multiple lambdas in the same parentheses change indentation rules. These
   // lambdas are forced to start on new lines.
   verifyFormat("SomeFunction(\n"
@@ -12905,8 +12909,8 @@
"},\n"
"1);\n");
 
-  // A multi-line lambda passed as arg1 forces arg0 to be pushed out, just 
like the arg0
-  // case above.
+  // A multi-line lambda passed as arg1 forces arg0 to be pushed out, just like
+  // the arg0 case above.
   auto Style = getGoogleStyle();
   Style.BinPackArguments = false;
   verifyFormat("SomeFunction(\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1440,8 +1440,11 @@
 case tok::identifier:
 case tok::numeric_constant:
 case tok::coloncolon:
+case tok::kw_class:
 case tok::kw_mutable:
 case tok::kw_noexcept:
+case tok::kw_template:
+case tok::kw_typename:
   nextToken();
   break;
 // Specialization of a template with an integer parameter can contain
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -40,6 +40,24 @@
   return Tok.Tok.getIdentifierInfo() != nullptr;
 }
 
+/// With `Left` being '(', check if we're at either `[...](` or
+/// `...]<...>(`.
+static bool isLambdaParameterList(const FormatToken *Left) {
+  if (!Left->Previous)
+return false;
+
+  // Skip <...> if present.
+  if (Left->Previous && Left->Previous->is(tok::greater) &&
+  Left->Previous->MatchingParen &&
+  Left->Previous->MatchingParen->is(TT_TemplateOpener))
+Left = Left->Previous->MatchingParen;
+
+  // Check for `[...](`.
+  return Left->Previous && Left->Previous->is(tok::r_square) &&
+ Left->Previous->MatchingParen &&
+ Left->Previous->MatchingParen->is(TT_LambdaLSquare);
+}
+
 /// A parser that gathers additional information about tokens.
 ///
 /// The \c TokenAnnotator tries to match parenthesis and square brakets and
@@ -191,9 +209,7 @@
Left->Previous->is(TT_JsTypeColon)) {
   // let x: (SomeType);
   Contexts.back().IsExpression = false;
-} else if (Left->Previous && Left->Previous->is(tok::r_square) &&
-   Left->Previous->MatchingParen &&
-   Left->Previous->MatchingParen->is(TT_LambdaLSquare)) {
+} else if (isLambdaParameterList(Left)) {
   // This is a parameter list of a lambda expression.
   Contexts.back().IsExpression = false;
 } else if (Line.InPPDirective &&


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -12888,6 +12888,10 @@
"  return 1; //\n"
"};");
 
+  // Lambdas with explicit template argument lists.
+  verifyFormat(
+  "auto L = [] class T, class U>(T &) {};\n");
+
   // Multiple lambdas in the same parentheses change indentation rules. These
   // lambdas are forced to start on new lines.
   verifyFormat("SomeFunction(\n"
@@ -12905,8 +12909,8 @@
"},\n"
"1);\n");
 
-  // A multi-line lambda passed as arg1 forces arg0 to be pushed out, just like the arg0
-  // case above.
+  // A multi-line lambda passed as arg1 forces arg0 to be pushed out, just like
+  // the arg0 case above.
   auto Style = getGoogleStyle();
   Style.BinPackArguments = false;
   verifyFormat("SomeFunction(\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1440,8 +1440,11 @@
 case tok::identifier:
 case tok::numeric_constant:
 case tok::coloncolon:
+case tok::kw_class:
 case tok::kw_mutable:
 case tok::kw_noexcept:
+case tok::kw_template:
+case tok::kw_typename:
   nextToken();
   break;
 // Specialization of a template with an integer parameter can contain
Index: clang/lib/Format/TokenAnnotator.cpp

[PATCH] D67208: [WebAssembly] Add -fwasm-exceptions for wasm EH

[Derek Schuff via Phabricator via cfe-commits]

dschuff added a comment.

Oh, you're right, I'm conflating `-mexception-handling` with `-fexceptions`. 
And also `-fno-exceptions` with `noexcept`. So... just forget I was here 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67208



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

[PATCH] D67208: [WebAssembly] Add -fwasm-exceptions for wasm EH

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

Derek, are you saying that `-mexception-handling` is somehow related to 
`-fno-exceptions`.   What is the relationship?I wasn't aware this change 
was related to  `-fno-exceptions`.

`-pthreads`  enabling `-matomics` and `-mbulk-memory`make some sense because 
each of those low level flags might make sense on its own.   But if 
`-fwasm-exceptions` only going to enable `-mexception-handling` then I'm not 
sure I see the point in adding it.  Or is there something else it will enable?  
 Also, we didn't add `-pthread`, it was pre-existing we we didn't need to 
justify adding it but rather make it work.

Sorry, I'm not necessarily against this change but I want to avoid adding flags 
unless there is a clear need.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67208



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

[PATCH] D67200: Add -static-openmp driver option

[Pirama Arumuga Nainar via Phabricator via cfe-commits]

pirama updated this revision to Diff 219004.
pirama added a comment.

Change parameter name.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67200

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/CommonArgs.h
  clang/lib/Driver/ToolChains/FreeBSD.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/NetBSD.cpp
  clang/test/Driver/fopenmp.c

Index: clang/test/Driver/fopenmp.c
===
--- clang/test/Driver/fopenmp.c
+++ clang/test/Driver/fopenmp.c
@@ -31,6 +31,10 @@
 // RUN: %clang -target x86_64-linux-gnu -fopenmp=libgomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-GOMP --check-prefix=CHECK-LD-GOMP-RT
 // RUN: %clang -target x86_64-linux-gnu -fopenmp=libiomp5 %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-IOMP5
 //
+// RUN: %clang -target x86_64-linux-gnu -fopenmp=libomp -static-openmp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-STATIC-OMP
+// RUN: %clang -target x86_64-linux-gnu -fopenmp=libgomp -static-openmp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-STATIC-GOMP --check-prefix=CHECK-LD-STATIC-GOMP-RT
+// RUN: %clang -target x86_64-linux-gnu -fopenmp=libiomp5 -static-openmp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-STATIC-IOMP5
+//
 // RUN: %clang -nostdlib -target x86_64-linux-gnu -fopenmp=libomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-OMP
 // RUN: %clang -nostdlib -target x86_64-linux-gnu -fopenmp=libgomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-GOMP
 // RUN: %clang -nostdlib -target x86_64-linux-gnu -fopenmp=libiomp5 %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-IOMP5
@@ -47,6 +51,10 @@
 // RUN: %clang -target x86_64-freebsd -fopenmp=libgomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-GOMP --check-prefix=CHECK-LD-GOMP-NO-RT
 // RUN: %clang -target x86_64-freebsd -fopenmp=libiomp5 %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-IOMP5
 //
+// RUN: %clang -target x86_64-freebsd -fopenmp=libomp -static-openmp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-STATIC-OMP
+// RUN: %clang -target x86_64-freebsd -fopenmp=libgomp -static-openmp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-STATIC-GOMP --check-prefix=CHECK-LD-STATIC-GOMP-NO-RT
+// RUN: %clang -target x86_64-freebsd -fopenmp=libiomp5 -static-openmp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-STATIC-IOMP5
+//
 // RUN: %clang -nostdlib -target x86_64-freebsd -fopenmp=libomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-OMP
 // RUN: %clang -nostdlib -target x86_64-freebsd -fopenmp=libgomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-GOMP
 // RUN: %clang -nostdlib -target x86_64-freebsd -fopenmp=libiomp5 %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-IOMP5
@@ -55,6 +63,10 @@
 // RUN: %clang -target x86_64-netbsd -fopenmp=libgomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-GOMP --check-prefix=CHECK-LD-GOMP-NO-RT
 // RUN: %clang -target x86_64-netbsd -fopenmp=libiomp5 %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-IOMP5
 //
+// RUN: %clang -target x86_64-netbsd -fopenmp=libomp -static-openmp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-STATIC-OMP
+// RUN: %clang -target x86_64-netbsd -fopenmp=libgomp -static-openmp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-STATIC-GOMP --check-prefix=CHECK-LD-STATIC-GOMP-NO-RT
+// RUN: %clang -target x86_64-netbsd -fopenmp=libiomp5 -static-openmp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-STATIC-IOMP5
+//
 // RUN: %clang -nostdlib -target x86_64-netbsd -fopenmp=libomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-OMP
 // RUN: %clang -nostdlib -target x86_64-netbsd -fopenmp=libgomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-GOMP
 // RUN: %clang -nostdlib -target x86_64-netbsd -fopenmp=libiomp5 %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-IOMP5
@@ -93,6 +105,17 @@
 // CHECK-NO-IOMP5MD: "{{.*}}ld{{(.exe)?}}"
 // CHECK-NO-IOMP5MD-NOT: "-liomp5md"
 //
+// CHECK-LD-STATIC-OMP: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LD-STATIC-OMP: "-Bstatic" "-lomp" "-Bdynamic"
+//
+// CHECK-LD-STATIC-GOMP: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LD-STATIC-GOMP: "-Bstatic" "-lgomp" "-Bdynamic"
+// CHECK-LD-STATIC-GOMP-RT: "-lrt"
+// CHECK-LD-STATIC-NO-GOMP-RT-NOT: "-lrt"
+//
+// CHECK-LD-STATIC-IOMP5: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LD-STATIC-IOMP5: "-Bstatic" "-liomp5" "-Bdynamic"
+//
 // We'd like to check that the default is sane, but until we have the ability
 // to *always* semantically analyze OpenMP without always generating runtime
 // calls (in the event of an unsupported runtime), we don't have a good way to
Index: clang/lib/Driver/ToolChains/NetBSD.cpp

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

[Parker Schuh via Phabricator via cfe-commits]

pschuh added a comment.

Hi John, maybe take a look?


Repository:
  rC Clang

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

https://reviews.llvm.org/D66360



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

[PATCH] D67208: [WebAssembly] Add -fwasm-exceptions for wasm EH

[Heejin Ahn via Phabricator via cfe-commits]

aheejin added a comment.

In D67208#1659972 , @dschuff wrote:

> If this is to be like `-fdwarf-exceptions` I assume the idea is that 
> eventually it will default on when targeting wasm, and become one of those 
> flags that most users never set. In that case it really just selects the 
> default exception model, and thus it should be compatible with 
> `-fno-exceptions` just as `-fdwarf-exceptions` is.\


`-fwasm-exceptions` works fine with `-fno-exceptions`. That has the same effect 
as when you specify both `-fdwarf-exceptions` and `-fno-exceptions` together; 
it just lowers invokes to calls. Is that not what you mean?

> Also `-fno-exceptions` doesn't really mean "no exceptions whatsoever" because 
> IIRC if you call something that the compiler isn't sure never throws, it 
> generates an implicit catch-all that calls `std::terminate`. So how it does 
> that would still be affected by the exception model. (and whatever downstream 
> invoke-removing pass or postprocessing tool might care).

`-fno-exceptions` does not generate try-catch with calls to `std::terminate`. 
The native x86 compiler does not do that either. It just assumes exceptions 
don't exist. (And you can't use keywords like `try`, `catch`, or `throw` with 
`-fno-exceptions`.) What you described is when we use `noexcept` on the 
function declaration but the function calls another function that can throw, I 
think.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67208



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

[PATCH] D67208: [WebAssembly] Add -fwasm-exceptions for wasm EH

[Heejin Ahn via Phabricator via cfe-commits]

aheejin added a comment.

In D67208#1659941 , @sbc100 wrote:

> But why not make -mexception-handling  be the option that enabled everything? 
>  I mean -mexception-handling is a flag we have today..  if you add 
> -fwasm-exceptions what does -mexception-handling meaning?  Is it still useful?


As I said above, I'm not sure making architecture flags control everything is a 
good idea. I view those flags as very low-level flags whose only job is exactly 
turn on those architecture features (Others may view them differently though). 
Likewise, currently setting `--pthreads` controls other features, but setting 
`-matomics` or `-mbulk-memory` does not control other features.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67208



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

[PATCH] D67140: [analyzer][NFC] Fix inconsistent references to checkers as "checks"

[Dmitri Gribenko via Phabricator via cfe-commits]

gribozavr added a comment.

We should take a page from desktop software here. If the messages were in a 
separate file, there would be a lot of people capable of mass-editing them. 
When messages are hardcoded in the tool code, navigating and editing them 
requires more skill, and definitely a lot more jumping around.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67140



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

[PATCH] D67140: [analyzer][NFC] Fix inconsistent references to checkers as "checks"

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

Szelethus added a comment.

In D67140#1659907 , @NoQ wrote:

> In D67140#1659872 , @aaron.ballman 
> wrote:
>
> > If we're okay with the inconsistency but still feel like giving ourselves 
> > more work, adding proper punctuation to Static Analyzer diagnostics would 
> > at least make them grammatically correct. :-D
>
>
> I'd love us some punctuation! Unfortunately the last time a person who 
> actually speaks English committed actively to the Static Analyzer was, like, 
> a couple of years ago at least (:


I guess there's a joke waiting to be made about a couple Hungarians and 
Russians discussing how to write proper English :^) With that said, we could 
ask @whisperity to chip in more, he has an ever-growing academic background, 
and a keen eye for grammatical errors.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67140



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

[PATCH] D67208: [WebAssembly] Add -fwasm-exceptions for wasm EH

[Derek Schuff via Phabricator via cfe-commits]

dschuff added a comment.

If this is to be like `-fdwarf-exceptions` I assume the idea is that eventually 
it will default on when targeting wasm, and become one of those flags that most 
users never set. In that case it really just selects the default exception 
model, and thus it should be compatible with `-fno-exceptions` just as 
`-fdwarf-exceptions`.
Also `-fno-exceptions` doesn't really mean "no exceptions whatsoever" because 
if you call something that the compiler isn't sure never throws, it generates 
an implicit catch-all that calls `std::terminate`. So how it does that would 
still be affected by the exception model. (and whatever downstream 
invoke-removing pass or postprocessing tool might care).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67208



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

[PATCH] D67208: [WebAssembly] Add -fwasm-exceptions for wasm EH

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

But why not make -mexception-handling  be the option that enabled everything?  
I mean -mexception-handling is a flag we have today..  if you add 
-fwasm-exceptions what does -mexception-handling meaning?  Is it still useful?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67208



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

[PATCH] D67028: Use musttail for variadic method thunks when possible

[Reid Kleckner via Phabricator via cfe-commits]

rnk updated this revision to Diff 218995.
rnk added a comment.

- emit an error if we try to clone without a definition


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67028

Files:
  clang/lib/CodeGen/CGVTables.cpp
  clang/test/CodeGenCXX/linetable-virtual-variadic.cpp
  clang/test/CodeGenCXX/ms-thunks-variadic-return.cpp
  clang/test/CodeGenCXX/thunks.cpp

Index: clang/test/CodeGenCXX/thunks.cpp
===
--- clang/test/CodeGenCXX/thunks.cpp
+++ clang/test/CodeGenCXX/thunks.cpp
@@ -1,6 +1,20 @@
-// RUN: %clang_cc1 %s -triple=x86_64-pc-linux-gnu -munwind-tables -emit-llvm -o - | FileCheck --check-prefix=CHECK --check-prefix=CHECK-NONOPT %s
-// RUN: %clang_cc1 %s -triple=x86_64-pc-linux-gnu -debug-info-kind=standalone -dwarf-version=5 -munwind-tables -emit-llvm -o - | FileCheck --check-prefix=CHECK --check-prefix=CHECK-NONOPT --check-prefix=CHECK-DBG %s
-// RUN: %clang_cc1 %s -triple=x86_64-pc-linux-gnu -munwind-tables -emit-llvm -o - -O1 -disable-llvm-passes | FileCheck --check-prefix=CHECK --check-prefix=CHECK-OPT %s
+// Sparc64 doesn't support musttail (yet), so it uses method cloning for
+// variadic thunks. Use it for testing.
+// RUN: %clang_cc1 %s -triple=sparc64-pc-linux-gnu -munwind-tables -emit-llvm -o - \
+// RUN: | FileCheck --check-prefixes=CHECK,CHECK-CLONE,CHECK-NONOPT %s
+// RUN: %clang_cc1 %s -triple=sparc64-pc-linux-gnu -debug-info-kind=standalone -dwarf-version=5 -munwind-tables -emit-llvm -o - \
+// RUN: | FileCheck --check-prefixes=CHECK,CHECK-CLONE,CHECK-NONOPT,CHECK-DBG %s
+// RUN: %clang_cc1 %s -triple=sparc64-pc-linux-gnu -munwind-tables -emit-llvm -o - -O1 -disable-llvm-passes \
+// RUN: | FileCheck --check-prefixes=CHECK,CHECK-CLONE,CHECK-OPT %s
+
+// Test x86_64, which uses musttail for variadic thunks.
+// RUN: %clang_cc1 %s -triple=x86_64-pc-linux-gnu -munwind-tables -emit-llvm -o - -O1 -disable-llvm-passes \
+// RUN: | FileCheck --check-prefixes=CHECK,CHECK-TAIL,CHECK-OPT %s
+
+// Finally, reuse these tests for the MS ABI.
+// RUN: %clang_cc1 %s -triple=x86_64-windows-msvc -munwind-tables -emit-llvm -o - -O1 -disable-llvm-passes \
+// RUN: | FileCheck --check-prefixes=WIN64 %s
+
 
 namespace Test1 {
 
@@ -23,6 +37,11 @@
 // CHECK-LABEL: define void @_ZThn8_N5Test11C1fEv(
 // CHECK-DBG-NOT: dbg.declare
 // CHECK: ret void
+//
+// WIN64-LABEL: define dso_local void @"?f@C@Test1@@UEAAXXZ"(
+// WIN64-LABEL: define linkonce_odr dso_local void @"?f@C@Test1@@W7EAAXXZ"(
+// WIN64: getelementptr i8, i8* {{.*}}, i32 -8
+// WIN64: ret void
 void C::f() { }
 
 }
@@ -45,6 +64,10 @@
 // CHECK: ret void
 void B::f() { }
 
+// No thunk is used for this case in the MS ABI.
+// WIN64-LABEL: define dso_local void @"?f@B@Test2@@UEAAXXZ"(
+// WIN64-NOT: define {{.*}} void @"?f@B@Test2
+
 }
 
 namespace Test3 {
@@ -65,6 +88,7 @@
 };
 
 // CHECK: define %{{.*}}* @_ZTch0_v0_n24_N5Test31B1fEv(
+// WIN64: define weak_odr dso_local %{{.*}} @"?f@B@Test3@@QEAAPEAUV1@2@XZ"(
 V2 *B::f() { return 0; }
 
 }
@@ -92,6 +116,10 @@
 // CHECK: ret void
 void C::f() { }
 
+// Visibility doesn't matter on COFF, but whatever. We could add an ELF test
+// mode later.
+// WIN64-LABEL: define protected void @"?f@C@Test4@@UEAAXXZ"(
+// WIN64-LABEL: define linkonce_odr protected void @"?f@C@Test4@@W7EAAXXZ"(
 }
 
 // Check that the thunk gets internal linkage.
@@ -119,6 +147,8 @@
 c.f();
   }
 }
+// Not sure why this isn't delayed like in Itanium.
+// WIN64-LABEL: define internal void @"?f@C@?A0xAEF74CE7@Test4B@@UEAAXXZ"(
 
 namespace Test5 {
 
@@ -134,6 +164,7 @@
 void f(B b) {
   b.f();
 }
+// No thunk in MS ABI in this case.
 }
 
 namespace Test6 {
@@ -178,6 +209,10 @@
   // CHECK: {{call void @_ZN5Test66Thunks1fEv.*sret}}
   // CHECK: ret void
   X Thunks::f() { return X(); }
+
+  // WIN64-LABEL: define linkonce_odr dso_local void @"?f@Thunks@Test6@@WBA@EAA?AUX@2@XZ"({{.*}} sret %{{.*}})
+  // WIN64-NOT: memcpy
+  // WIN64: tail call void @"?f@Thunks@Test6@@UEAA?AUX@2@XZ"({{.*}} sret %{{.*}})
 }
 
 namespace Test7 {
@@ -224,6 +259,8 @@
   // CHECK-NOT: memcpy
   // CHECK: ret void
   void testD() { D d; }
+
+  // MS C++ ABI doesn't use a thunk, so this case isn't interesting.
 }
 
 namespace Test8 {
@@ -241,6 +278,8 @@
   // CHECK-NOT: memcpy
   // CHECK: ret void
   void C::bar(NonPOD var) {}
+
+  // MS C++ ABI doesn't use a thunk, so this case isn't interesting.
 }
 
 // PR7241: Emitting thunks for a method shouldn't require the vtable for
@@ -287,6 +326,16 @@
   // CHECK: define {{.*}} @_ZTch0_v0_n32_N6Test111C1fEv(
   // CHECK-DBG-NOT: dbg.declare
   // CHECK: ret
+
+  // WIN64-LABEL: define dso_local %{{.*}}* @"?f@C@Test11@@UEAAPEAU12@XZ"(i8*
+
+  // WIN64-LABEL: define weak_odr dso_local %{{.*}}* @"?f@C@Test11@@QEAAPEAUA@2@XZ"(i8*
+  // WIN64: call %{{.*}}* @"?f@C@Test11@@UEAAPEAU12@XZ"(i8* %{{.*}})
+  //
+  // Match the vbtable return adjustment.

[PATCH] D67028: Use musttail for variadic method thunks when possible

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

In D67028#1659881 , @efriedma wrote:

> > In your test case, we hit the early return that I linked to, so we don't 
> > try to clone, and we don't need to emit an error.
>
> Yes, that's what happens with the Itanium ABI; what happens with the MS ABI?


I see, it doesn't work. There's also the case of the MS ABI for ISAs that don't 
support musttail, although that's less interesting.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67028



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

[PATCH] D65371: do not emit -Wunused-macros warnings in -frewrite-includes mode (PR15614)

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

A test case would be good (in the clang/test directory - probably near/in the 
other tests for -frewrite-includes)

And does the same bug occur for other preprocessor-related warnings? Maybe it's 
not practical to disable them all this way & there should be a different 
solution? (or maybe we shouldn't fix these and users can pass -w to disable 
warnings when using -frewrite-includes?)


Repository:
  rC Clang

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

https://reviews.llvm.org/D65371



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

[PATCH] D67208: [WebAssembly] Add -fwasm-exceptions for wasm EH

[Heejin Ahn via Phabricator via cfe-commits]

aheejin added a comment.

@tlively @sbc100 What I wanted was to make `-fwasm-exceptions` as something 
like `-pthreads`, which serves as the only flag that needs to be turned on and 
turns on all other necessary flags, such as `+matomics`, `+mbulk-memory`, and 
`--shared-memory`. I think all those architectural flags starting with `-m` can 
be someday all turned on, when all our existing proposals become the new MVP, 
and I still want to give users an option to opt out of threads of exception 
handling at that point. And it also makes sense to have a `LangOption` of 
`WasmExceptions` given that there are `LangOption`s for all other exception 
models. I think this covers most of the questions above.

@tlively

> Is there a plan to turn this on by default at some point, or will users 
> always have to opt-in to using exceptions?

I'm planning to create an emscripten option, something like `-s 
EXCEPTION_HANDLING=1`, to turn this option on. Maybe at some point, when we 
don't use emscripten exception anymore and all wasm platforms (wasi and 
emscripten and what not) use the new exception proposal, we can consider 
turning this on by default. Until then I incline not to.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67208



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

[PATCH] D67140: [analyzer][NFC] Fix inconsistent references to checkers as "checks"

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

In D67140#1659872 , @aaron.ballman 
wrote:

> If we're okay with the inconsistency but still feel like giving ourselves 
> more work, adding proper punctuation to Static Analyzer diagnostics would at 
> least make them grammatically correct. :-D


I'd love us some punctuation! Unfortunately the last time a person who actually 
speaks English committed actively to the Static Analyzer was, like, a couple of 
years ago at least (:


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67140



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

[PATCH] D67122: [UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined behaviour

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D67122#1659882 , @rupprecht wrote:

> > Still think this looks good. Have you tried running this on the llvm test 
> > suite, or some other interesting corpus? Would be curious to see any 
> > pre/post patch numbers.
>
> I finally had time this morning to patch this in and give it a shot. (Sorry 
> for the delay... it's been a real busy week :( )




> First, starting off with the good news: I reverted all the fixes I made, and 
> now all the tests fail when running w/ ubsan. Yay!
>  The error we see in each case is `UndefinedBehaviorSanitizer: 
> nullptr-with-nonzero-offset` with the logs containing `runtime error: 
> applying non-zero offset  to null pointer`. Which catches the two 
> places where we were adding some non-zero offset to nullptr,

That is good :)

> but doesn't seem to catch the nullptr-after-nonzero-offset case in 
> https://github.com/google/filament/pull/1566 -- instead, it fails later, when 
> the pointer with a value of nullptr is incremented. (Or... maybe this is 
> actually a separate bug. Hmm. Needs some more testing...)

Well yeah, there are quite a few cases in clang codegen where we create `gep 
inbounds` without sanitization, so it may or may not be one of those cases.

> At any rate, I have some more tests to run to get some idea of what % of code 
> this would flag as being bad.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67122



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

[PATCH] D67028: Use musttail for variadic method thunks when possible

[Reid Kleckner via Phabricator via cfe-commits]

rnk updated this revision to Diff 218992.
rnk added a comment.

- merge into thunks.cpp


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67028

Files:
  clang/lib/CodeGen/CGVTables.cpp
  clang/test/CodeGenCXX/linetable-virtual-variadic.cpp
  clang/test/CodeGenCXX/thunks.cpp

Index: clang/test/CodeGenCXX/thunks.cpp
===
--- clang/test/CodeGenCXX/thunks.cpp
+++ clang/test/CodeGenCXX/thunks.cpp
@@ -1,6 +1,20 @@
-// RUN: %clang_cc1 %s -triple=x86_64-pc-linux-gnu -munwind-tables -emit-llvm -o - | FileCheck --check-prefix=CHECK --check-prefix=CHECK-NONOPT %s
-// RUN: %clang_cc1 %s -triple=x86_64-pc-linux-gnu -debug-info-kind=standalone -dwarf-version=5 -munwind-tables -emit-llvm -o - | FileCheck --check-prefix=CHECK --check-prefix=CHECK-NONOPT --check-prefix=CHECK-DBG %s
-// RUN: %clang_cc1 %s -triple=x86_64-pc-linux-gnu -munwind-tables -emit-llvm -o - -O1 -disable-llvm-passes | FileCheck --check-prefix=CHECK --check-prefix=CHECK-OPT %s
+// Sparc64 doesn't support musttail (yet), so it uses method cloning for
+// variadic thunks. Use it for testing.
+// RUN: %clang_cc1 %s -triple=sparc64-pc-linux-gnu -munwind-tables -emit-llvm -o - \
+// RUN: | FileCheck --check-prefixes=CHECK,CHECK-CLONE,CHECK-NONOPT %s
+// RUN: %clang_cc1 %s -triple=sparc64-pc-linux-gnu -debug-info-kind=standalone -dwarf-version=5 -munwind-tables -emit-llvm -o - \
+// RUN: | FileCheck --check-prefixes=CHECK,CHECK-CLONE,CHECK-NONOPT,CHECK-DBG %s
+// RUN: %clang_cc1 %s -triple=sparc64-pc-linux-gnu -munwind-tables -emit-llvm -o - -O1 -disable-llvm-passes \
+// RUN: | FileCheck --check-prefixes=CHECK,CHECK-CLONE,CHECK-OPT %s
+
+// Test x86_64, which uses musttail for variadic thunks.
+// RUN: %clang_cc1 %s -triple=x86_64-pc-linux-gnu -munwind-tables -emit-llvm -o - -O1 -disable-llvm-passes \
+// RUN: | FileCheck --check-prefixes=CHECK,CHECK-TAIL,CHECK-OPT %s
+
+// Finally, reuse these tests for the MS ABI.
+// RUN: %clang_cc1 %s -triple=x86_64-windows-msvc -munwind-tables -emit-llvm -o - -O1 -disable-llvm-passes \
+// RUN: | FileCheck --check-prefixes=WIN64 %s
+
 
 namespace Test1 {
 
@@ -23,6 +37,11 @@
 // CHECK-LABEL: define void @_ZThn8_N5Test11C1fEv(
 // CHECK-DBG-NOT: dbg.declare
 // CHECK: ret void
+//
+// WIN64-LABEL: define dso_local void @"?f@C@Test1@@UEAAXXZ"(
+// WIN64-LABEL: define linkonce_odr dso_local void @"?f@C@Test1@@W7EAAXXZ"(
+// WIN64: getelementptr i8, i8* {{.*}}, i32 -8
+// WIN64: ret void
 void C::f() { }
 
 }
@@ -45,6 +64,10 @@
 // CHECK: ret void
 void B::f() { }
 
+// No thunk is used for this case in the MS ABI.
+// WIN64-LABEL: define dso_local void @"?f@B@Test2@@UEAAXXZ"(
+// WIN64-NOT: define {{.*}} void @"?f@B@Test2
+
 }
 
 namespace Test3 {
@@ -65,6 +88,7 @@
 };
 
 // CHECK: define %{{.*}}* @_ZTch0_v0_n24_N5Test31B1fEv(
+// WIN64: define weak_odr dso_local %{{.*}} @"?f@B@Test3@@QEAAPEAUV1@2@XZ"(
 V2 *B::f() { return 0; }
 
 }
@@ -92,6 +116,10 @@
 // CHECK: ret void
 void C::f() { }
 
+// Visibility doesn't matter on COFF, but whatever. We could add an ELF test
+// mode later.
+// WIN64-LABEL: define protected void @"?f@C@Test4@@UEAAXXZ"(
+// WIN64-LABEL: define linkonce_odr protected void @"?f@C@Test4@@W7EAAXXZ"(
 }
 
 // Check that the thunk gets internal linkage.
@@ -119,6 +147,8 @@
 c.f();
   }
 }
+// Not sure why this isn't delayed like in Itanium.
+// WIN64-LABEL: define internal void @"?f@C@?A0xAEF74CE7@Test4B@@UEAAXXZ"(
 
 namespace Test5 {
 
@@ -134,6 +164,7 @@
 void f(B b) {
   b.f();
 }
+// No thunk in MS ABI in this case.
 }
 
 namespace Test6 {
@@ -178,6 +209,10 @@
   // CHECK: {{call void @_ZN5Test66Thunks1fEv.*sret}}
   // CHECK: ret void
   X Thunks::f() { return X(); }
+
+  // WIN64-LABEL: define linkonce_odr dso_local void @"?f@Thunks@Test6@@WBA@EAA?AUX@2@XZ"({{.*}} sret %{{.*}})
+  // WIN64-NOT: memcpy
+  // WIN64: tail call void @"?f@Thunks@Test6@@UEAA?AUX@2@XZ"({{.*}} sret %{{.*}})
 }
 
 namespace Test7 {
@@ -224,6 +259,8 @@
   // CHECK-NOT: memcpy
   // CHECK: ret void
   void testD() { D d; }
+
+  // MS C++ ABI doesn't use a thunk, so this case isn't interesting.
 }
 
 namespace Test8 {
@@ -241,6 +278,8 @@
   // CHECK-NOT: memcpy
   // CHECK: ret void
   void C::bar(NonPOD var) {}
+
+  // MS C++ ABI doesn't use a thunk, so this case isn't interesting.
 }
 
 // PR7241: Emitting thunks for a method shouldn't require the vtable for
@@ -287,6 +326,16 @@
   // CHECK: define {{.*}} @_ZTch0_v0_n32_N6Test111C1fEv(
   // CHECK-DBG-NOT: dbg.declare
   // CHECK: ret
+
+  // WIN64-LABEL: define dso_local %{{.*}}* @"?f@C@Test11@@UEAAPEAU12@XZ"(i8*
+
+  // WIN64-LABEL: define weak_odr dso_local %{{.*}}* @"?f@C@Test11@@QEAAPEAUA@2@XZ"(i8*
+  // WIN64: call %{{.*}}* @"?f@C@Test11@@UEAAPEAU12@XZ"(i8* %{{.*}})
+  //
+  // Match the vbtable return adjustment.
+  // WIN64: load i32*, i32** %{{[^,]*}}, align 8
+  // WIN64: getelementptr inbounds 

[PATCH] D67122: [UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined behaviour

[Jordan Rupprecht via Phabricator via cfe-commits]

rupprecht added a comment.

> Still think this looks good. Have you tried running this on the llvm test 
> suite, or some other interesting corpus? Would be curious to see any pre/post 
> patch numbers.

I finally had time this morning to patch this in and give it a shot. (Sorry for 
the delay... it's been a real busy week :( )

First, starting off with the good news: I reverted all the fixes I made, and 
now all the tests fail when running w/ ubsan. Yay!

The error we see in each case is `UndefinedBehaviorSanitizer: 
nullptr-with-nonzero-offset` with the logs containing `runtime error: applying 
non-zero offset  to null pointer`. Which catches the two places where 
we were adding some non-zero offset to nullptr, but doesn't seem to catch the 
nullptr-after-nonzero-offset case in 
https://github.com/google/filament/pull/1566 -- instead, it fails later, when 
the pointer with a value of nullptr is incremented. (Or... maybe this is 
actually a separate bug. Hmm. Needs some more testing...)

At any rate, I have some more tests to run to get some idea of what % of code 
this would flag as being bad.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67122



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

[PATCH] D67028: Use musttail for variadic method thunks when possible

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

> In your test case, we hit the early return that I linked to, so we don't try 
> to clone, and we don't need to emit an error.

Yes, that's what happens with the Itanium ABI; what happens with the MS ABI?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67028



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

[PATCH] D67140: [analyzer][NFC] Fix inconsistent references to checkers as "checks"

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

Szelethus added a comment.

I don't have strong feelings on capitalization itself either, but the idea of 
longer, multi-sentence bug report messages (maybe this could finally be used? 
D66572#inline-602143 ) sound 
pretty cool.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67140



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

[PATCH] D67140: [analyzer][NFC] Fix inconsistent references to checkers as "checks"

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D67140#1659831 , @NoQ wrote:

> In D67140#1659774 , @aaron.ballman 
> wrote:
>
> > I don't think it's a requirement (so long as the diagnostics are clear 
> > about the issue being diagnosed, I'm happy enough), but I think it's good 
> > for a tool to be self-consistent in its messaging. It's jarring that one 
> > part of the compiler emits diagnostics one way and another emits them a 
> > totally different way. It may be less of an impact for people who don't see 
> > the output from both at the same time, but that happens to be the use case 
> > I have.
>
>
> Unfortunately i think at this point many clients who tried to integrate 
> multiple tools resorted to "Automatic Message Recapitalization" (c). For that 
> reason we probably can harmlessly decapitalize Static Analyzer messages. I 
> suspect that it won't really change anything either, because most tools will 
> still be afraid of accidental inconsistencies in the compiler.


If we're okay with the inconsistency but still feel like giving ourselves more 
work, adding proper punctuation to Static Analyzer diagnostics would at least 
make them grammatically correct. :-D


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67140



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

[PATCH] D67208: [WebAssembly] Add -fwasm-exceptions for wasm EH

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

Is there some reason why clang can't pass the  -exception-model=wasm flag 
programatically to llc when -mmexception-handling is set?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67208



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

[PATCH] D67208: [WebAssembly] Add -fwasm-exceptions for wasm EH

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added a comment.

I don't really see why we can't just have the existing `-mexception-handling` 
take on this new meaning?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67208



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

[PATCH] D67028: Use musttail for variadic method thunks when possible

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

I think what I said applies to your test case. Basically, in the Itanium C++ 
ABI, virtual method definitions provide all their thunks as `weak_odr`. We only 
emit thunks referenced by vtables as an optimization, and they are marked 
`available_externally`. In your test case, we hit the early return that I 
linked to, so we don't try to clone, and we don't need to emit an error.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67028



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

[PATCH] D67208: [WebAssembly] Add -fwasm-exceptions for wasm EH

[Thomas Lively via Phabricator via cfe-commits]

tlively added a comment.

Is there a plan to turn this on by default at some point, or will users always 
have to opt-in to using exceptions? Also, would it make sense to automatically 
turn this feature on if the user instead supplies `-mexception-handling` to 
turn on the target feature?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67208



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

[PATCH] D67140: [analyzer][NFC] Fix inconsistent references to checkers as "checks"

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

In D67140#1659774 , @aaron.ballman 
wrote:

> I don't think it's a requirement (so long as the diagnostics are clear about 
> the issue being diagnosed, I'm happy enough), but I think it's good for a 
> tool to be self-consistent in its messaging. It's jarring that one part of 
> the compiler emits diagnostics one way and another emits them a totally 
> different way. It may be less of an impact for people who don't see the 
> output from both at the same time, but that happens to be the use case I have.


Unfortunately i think at this point many clients who tried to integrate 
multiple tools resorted to "Automatic Message Recapitalization" (c). For that 
reason we probably can harmlessly decapitalize Static Analyzer messages. I 
suspect that it won't really change anything either, because most tools will 
still be afraid of accidental inconsistencies in the compiler.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67140



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

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

[Matthias Gehre via Phabricator via cfe-commits]

mgehre abandoned this revision.
mgehre added a comment.

The discussions on the bug did not provide further insight (until now).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66365



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

[PATCH] D67028: Use musttail for variadic method thunks when possible

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

> In the MS ABI, deriving a new class may require the creation of new thunks 
> for methods that were not overridden, so we can't use the same trick.

Yes.  MSVC emits an error message "covariant returns with multiple or virtual 
inheritance not supported for varargs functions" in cases like the following.   
It looks like the equivalent isn't implemented in clang?  (Is that the 
llvm_unreachable in this patch?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67028



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

[PATCH] D67028: Use musttail for variadic method thunks when possible

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

Oops, meant to actually include the testcase in my last comment:

struct V1 { };
struct V2 : virtual V1 { };
struct A {

  virtual V1 *f(int,...);

};
struct B : A {

  virtual void b();
  virtual V2 *f(int,...);

};
B b;


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67028



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

[PATCH] D67202: Implement Microsoft-compatible mangling for decomposition declarations.

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL371124: Implement Microsoft-compatible mangling for 
decomposition declarations. (authored by nico, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67202?vs=218934=218978#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67202

Files:
  cfe/trunk/include/clang/AST/Mangle.h
  cfe/trunk/lib/AST/MicrosoftMangle.cpp
  cfe/trunk/test/CodeGenCXX/mangle-ms-cxx17.cpp


Index: cfe/trunk/lib/AST/MicrosoftMangle.cpp
===
--- cfe/trunk/lib/AST/MicrosoftMangle.cpp
+++ cfe/trunk/lib/AST/MicrosoftMangle.cpp
@@ -868,16 +868,11 @@
   }
 
   if (const DecompositionDecl *DD = dyn_cast(ND)) {
-// FIXME: Invented mangling for decomposition declarations:
-//   [X,Y,Z]
-// where X,Y,Z are the names of the bindings.
-llvm::SmallString<128> Name("[");
-for (auto *BD : DD->bindings()) {
-  if (Name.size() > 1)
-Name += ',';
-  Name += BD->getDeclName().getAsIdentifierInfo()->getName();
-}
-Name += ']';
+// Decomposition declarations are considered anonymous, and get
+// numbered with a $S prefix.
+llvm::SmallString<64> Name("$S");
+// Get a unique id for the anonymous struct.
+Name += llvm::utostr(Context.getAnonymousStructId(DD) + 1);
 mangleSourceName(Name);
 break;
   }
Index: cfe/trunk/include/clang/AST/Mangle.h
===
--- cfe/trunk/include/clang/AST/Mangle.h
+++ cfe/trunk/include/clang/AST/Mangle.h
@@ -56,7 +56,7 @@
 
   llvm::DenseMap GlobalBlockIds;
   llvm::DenseMap LocalBlockIds;
-  llvm::DenseMap AnonStructIds;
+  llvm::DenseMap AnonStructIds;
 
 public:
   ManglerKind getKind() const { return Kind; }
@@ -82,9 +82,9 @@
 return Result.first->second;
   }
 
-  uint64_t getAnonymousStructId(const TagDecl *TD) {
-std::pair::iterator, bool>
-Result = AnonStructIds.insert(std::make_pair(TD, 
AnonStructIds.size()));
+  uint64_t getAnonymousStructId(const NamedDecl *D) {
+std::pair::iterator, bool>
+Result = AnonStructIds.insert(std::make_pair(D, AnonStructIds.size()));
 return Result.first->second;
   }
 
Index: cfe/trunk/test/CodeGenCXX/mangle-ms-cxx17.cpp
===
--- cfe/trunk/test/CodeGenCXX/mangle-ms-cxx17.cpp
+++ cfe/trunk/test/CodeGenCXX/mangle-ms-cxx17.cpp
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -std=c++1z -fms-extensions -emit-llvm %s -o - 
-triple=i386-pc-win32 -fms-compatibility-version=19.10 | FileCheck 
-allow-deprecated-dag-overlap %s --check-prefix=CHECK --check-prefix=MSVC2017
+// RUN: %clang_cc1 -std=c++1z -fms-extensions -emit-llvm %s -o - 
-triple=i386-pc-win32 -fms-compatibility-version=19.00 | FileCheck 
-allow-deprecated-dag-overlap %s --check-prefix=CHECK --check-prefix=MSVC2015
+
+struct S {
+int x;
+double y;
+};
+S f();
+
+// CHECK-DAG: "?$S1@@3US@@B"
+const auto [x0, y0] = f();
+// CHECK-DAG: "?$S2@@3US@@B"
+const auto [x1, y1] = f();
+
+static union {
+int a;
+double b;
+};
+
+// CHECK-DAG: "?$S4@@3US@@B"
+const auto [x2, y2] = f();


Index: cfe/trunk/lib/AST/MicrosoftMangle.cpp
===
--- cfe/trunk/lib/AST/MicrosoftMangle.cpp
+++ cfe/trunk/lib/AST/MicrosoftMangle.cpp
@@ -868,16 +868,11 @@
   }
 
   if (const DecompositionDecl *DD = dyn_cast(ND)) {
-// FIXME: Invented mangling for decomposition declarations:
-//   [X,Y,Z]
-// where X,Y,Z are the names of the bindings.
-llvm::SmallString<128> Name("[");
-for (auto *BD : DD->bindings()) {
-  if (Name.size() > 1)
-Name += ',';
-  Name += BD->getDeclName().getAsIdentifierInfo()->getName();
-}
-Name += ']';
+// Decomposition declarations are considered anonymous, and get
+// numbered with a $S prefix.
+llvm::SmallString<64> Name("$S");
+// Get a unique id for the anonymous struct.
+Name += llvm::utostr(Context.getAnonymousStructId(DD) + 1);
 mangleSourceName(Name);
 break;
   }
Index: cfe/trunk/include/clang/AST/Mangle.h
===
--- cfe/trunk/include/clang/AST/Mangle.h
+++ cfe/trunk/include/clang/AST/Mangle.h
@@ -56,7 +56,7 @@
 
   llvm::DenseMap GlobalBlockIds;
   llvm::DenseMap LocalBlockIds;
-  llvm::DenseMap AnonStructIds;
+  llvm::DenseMap AnonStructIds;
 
 public:
   ManglerKind getKind() const { return Kind; }
@@ -82,9 +82,9 @@
 return Result.first->second;
   }
 
-  uint64_t getAnonymousStructId(const TagDecl *TD) {
-std::pair::iterator, bool>
-

[PATCH] D67140: [analyzer][NFC] Fix inconsistent references to checkers as "checks"

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D67140#1659749 , @gribozavr wrote:

> In D67140#1659356 , @aaron.ballman 
> wrote:
>
> > In D67140#1658969 , @gribozavr 
> > wrote:
> >
> > > In D67140#1658365 , 
> > > @aaron.ballman wrote:
> > >
> > > > Ah, good to know! That reduces my concern, but doesn't negate it. 
> > > > AFAIK, we haven't changed the interface such that it requires code 
> > > > changes rather than just a recompile in recent history, so this is a 
> > > > bit novel.
> > >
> > >
> > > I think API changes happen all the time. At Google, we are integrating 
> > > upstream LLVM and Clang changes into our internal codebase daily. We have 
> > > a lot of internal ClangTidy checkers. Fixing up all our internal code to 
> > > keep with upstream changes is a full time job for one engineer (but it is 
> > > a rotation).
> >
> >
> > I think this sort of backs up the point I was making.
>
>
> Sorry, but in the previous comment you were saying that "we haven't changed 
> the interface such that it requires code changes". So which is it, for you?


Both. :-) It's been my experience that there are relatively few breaking 
changes to clang-tidy checks (but they certainly do happen). Your experience is 
that you need an entire FTE to deal with the amount of breaks. Both of our 
experiences can be valid simultaneously.

> 
> 
>> It requires an FTE to keep up with the breaks already.
> 
> Exactly. So one more or one less API change that requires a trivial code 
> change *does not matter*. People working on the Clang upgrade still have a 
> ton of other, complex, changes to deal with. Is it more work to upgrade for 
> this sort of API rename? Yes. Is meaningfully more work, if you look at 
> everything that needs to be done as a whole? No. It will not be a thing that 
> makes or breaks someone's Clang upgrade.

That's one perspective on it, yes. As I said, my experience is different than 
yours, which is probably why I'm more hesitant to make sweeping breaking 
changes like this when they have so little tangible benefit. You claim it won't 
make or break someone's Clang upgrade, but it certainly *can*. I've worked for 
places that, when we didn't have the resources to deal with breakage from a 
compiler upgrade, we delayed upgrading to that compiler until after we handled 
the issues raised, and I don't think this was all that unusual of a practice.

I'm not saying *no* to this change, despite my push-back.  We don't have source 
compatibility or API stability guarantees, so it would be unreasonable to think 
we'll never make a breaking change. I just don't think it's a good software 
engineering practice to be cavalier about breaking 100% of downstream users 
without a very good reason to do so. My opinion is that check vs checker is not 
a very good reason to break the world, but I'm not willing to hold up the patch 
over it if that opinion isn't shared by the community.

> Why do static analysis tools have to be consistent with Clang in its message 
> style?

I don't think it's a requirement (so long as the diagnostics are clear about 
the issue being diagnosed, I'm happy enough), but I think it's good for a tool 
to be self-consistent in its messaging. It's jarring that one part of the 
compiler emits diagnostics one way and another emits them a totally different 
way. It may be less of an impact for people who don't see the output from both 
at the same time, but that happens to be the use case I have. As a somewhat 
related example of inconsistencies, the Clang static analyzer does not report 
compiler diagnostics through it's bug reporter interface, which means that 
exporting analysis results to SARIF only exports the static analyzer bugs. This 
has caught quite a few people by surprise at GrammaTech and they've asked when 
Clang can start reporting all of the diagnostics instead of just some of them 
(aka, they thought this behavior was a bug), but then the inconsistencies in 
messaging would be more obvious.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67140



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

r371124 - Implement Microsoft-compatible mangling for decomposition declarations.

[Nico Weber via cfe-commits]

Author: nico
Date: Thu Sep  5 14:08:50 2019
New Revision: 371124

URL: http://llvm.org/viewvc/llvm-project?rev=371124=rev
Log:
Implement Microsoft-compatible mangling for decomposition declarations.

Match cl.exe's mangling for decomposition declarations.

Decomposition declarations are considered to be anonymous structs,
and use the same convention as for anonymous struct/union declarations.

Naming confirmed to match https://godbolt.org/z/K2osJa

Patch from Eric Astor !

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

Added:
cfe/trunk/test/CodeGenCXX/mangle-ms-cxx17.cpp
Modified:
cfe/trunk/include/clang/AST/Mangle.h
cfe/trunk/lib/AST/MicrosoftMangle.cpp

Modified: cfe/trunk/include/clang/AST/Mangle.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Mangle.h?rev=371124=371123=371124=diff
==
--- cfe/trunk/include/clang/AST/Mangle.h (original)
+++ cfe/trunk/include/clang/AST/Mangle.h Thu Sep  5 14:08:50 2019
@@ -56,7 +56,7 @@ private:
 
   llvm::DenseMap GlobalBlockIds;
   llvm::DenseMap LocalBlockIds;
-  llvm::DenseMap AnonStructIds;
+  llvm::DenseMap AnonStructIds;
 
 public:
   ManglerKind getKind() const { return Kind; }
@@ -82,9 +82,9 @@ public:
 return Result.first->second;
   }
 
-  uint64_t getAnonymousStructId(const TagDecl *TD) {
-std::pair::iterator, bool>
-Result = AnonStructIds.insert(std::make_pair(TD, 
AnonStructIds.size()));
+  uint64_t getAnonymousStructId(const NamedDecl *D) {
+std::pair::iterator, bool>
+Result = AnonStructIds.insert(std::make_pair(D, AnonStructIds.size()));
 return Result.first->second;
   }
 

Modified: cfe/trunk/lib/AST/MicrosoftMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/MicrosoftMangle.cpp?rev=371124=371123=371124=diff
==
--- cfe/trunk/lib/AST/MicrosoftMangle.cpp (original)
+++ cfe/trunk/lib/AST/MicrosoftMangle.cpp Thu Sep  5 14:08:50 2019
@@ -868,16 +868,11 @@ void MicrosoftCXXNameMangler::mangleUnqu
   }
 
   if (const DecompositionDecl *DD = dyn_cast(ND)) {
-// FIXME: Invented mangling for decomposition declarations:
-//   [X,Y,Z]
-// where X,Y,Z are the names of the bindings.
-llvm::SmallString<128> Name("[");
-for (auto *BD : DD->bindings()) {
-  if (Name.size() > 1)
-Name += ',';
-  Name += BD->getDeclName().getAsIdentifierInfo()->getName();
-}
-Name += ']';
+// Decomposition declarations are considered anonymous, and get
+// numbered with a $S prefix.
+llvm::SmallString<64> Name("$S");
+// Get a unique id for the anonymous struct.
+Name += llvm::utostr(Context.getAnonymousStructId(DD) + 1);
 mangleSourceName(Name);
 break;
   }

Added: cfe/trunk/test/CodeGenCXX/mangle-ms-cxx17.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/mangle-ms-cxx17.cpp?rev=371124=auto
==
--- cfe/trunk/test/CodeGenCXX/mangle-ms-cxx17.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/mangle-ms-cxx17.cpp Thu Sep  5 14:08:50 2019
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -std=c++1z -fms-extensions -emit-llvm %s -o - 
-triple=i386-pc-win32 -fms-compatibility-version=19.10 | FileCheck 
-allow-deprecated-dag-overlap %s --check-prefix=CHECK --check-prefix=MSVC2017
+// RUN: %clang_cc1 -std=c++1z -fms-extensions -emit-llvm %s -o - 
-triple=i386-pc-win32 -fms-compatibility-version=19.00 | FileCheck 
-allow-deprecated-dag-overlap %s --check-prefix=CHECK --check-prefix=MSVC2015
+
+struct S {
+int x;
+double y;
+};
+S f();
+
+// CHECK-DAG: "?$S1@@3US@@B"
+const auto [x0, y0] = f();
+// CHECK-DAG: "?$S2@@3US@@B"
+const auto [x1, y1] = f();
+
+static union {
+int a;
+double b;
+};
+
+// CHECK-DAG: "?$S4@@3US@@B"
+const auto [x2, y2] = f();


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

r371122 - [Diagnostics] Minor improvements for -Wxor-used-as-pow

[David Bolvansky via cfe-commits]

Author: xbolva00
Date: Thu Sep  5 13:50:48 2019
New Revision: 371122

URL: http://llvm.org/viewvc/llvm-project?rev=371122=rev
Log:
[Diagnostics] Minor improvements for -Wxor-used-as-pow

Extracted from D66397; implemented suggestion for 2^64; tests revisited.


Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/test/SemaCXX/warn-xor-as-pow.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=371122=371121=371122=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu Sep  5 13:50:48 
2019
@@ -3354,6 +3354,9 @@ def warn_address_of_reference_bool_conve
   "code; pointer may be assumed to always convert to true">,
   InGroup;
 
+def warn_xor_used_as_pow : Warning<
+  "result of '%0' is %1; did you mean an exponentiation?">,
+  InGroup;
 def warn_xor_used_as_pow_base_extra : Warning<
   "result of '%0' is %1; did you mean '%2' (%3)?">,
   InGroup;
@@ -3361,7 +3364,7 @@ def warn_xor_used_as_pow_base : Warning<
   "result of '%0' is %1; did you mean '%2'?">,
   InGroup;
 def note_xor_used_as_pow_silence : Note<
-  "replace expression with '%0' to silence this warning">;
+  "replace expression with '%0' %select{|or use 'xor' instead of '^' }1to 
silence this warning">;
 
 def warn_null_pointer_compare : Warning<
 "comparison of %select{address of|function|array}0 '%1' %select{not |}2"

Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=371122=371121=371122=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Thu Sep  5 13:50:48 2019
@@ -11081,33 +11081,42 @@ QualType Sema::CheckVectorCompareOperand
   return GetSignedVectorType(vType);
 }
 
-static void diagnoseXorMisusedAsPow(Sema , ExprResult , ExprResult ,
-SourceLocation Loc) {
+static void diagnoseXorMisusedAsPow(Sema , const ExprResult ,
+const ExprResult ,
+const SourceLocation Loc) {
   // Do not diagnose macros.
   if (Loc.isMacroID())
 return;
 
   bool Negative = false;
-  const auto *LHSInt = dyn_cast(LHS.get());
-  const auto *RHSInt = dyn_cast(RHS.get());
+  bool ExplicitPlus = false;
+  const auto *LHSInt = dyn_cast(XorLHS.get());
+  const auto *RHSInt = dyn_cast(XorRHS.get());
 
   if (!LHSInt)
 return;
   if (!RHSInt) {
 // Check negative literals.
-if (const auto *UO = dyn_cast(RHS.get())) {
-  if (UO->getOpcode() != UO_Minus)
+if (const auto *UO = dyn_cast(XorRHS.get())) {
+  UnaryOperatorKind Opc = UO->getOpcode();
+  if (Opc != UO_Minus && Opc != UO_Plus)
 return;
   RHSInt = dyn_cast(UO->getSubExpr());
   if (!RHSInt)
 return;
-  Negative = true;
+  Negative = (Opc == UO_Minus);
+  ExplicitPlus = !Negative;
 } else {
   return;
 }
   }
 
-  if (LHSInt->getValue().getBitWidth() != RHSInt->getValue().getBitWidth())
+  const llvm::APInt  = LHSInt->getValue();
+  llvm::APInt RightSideValue = RHSInt->getValue();
+  if (LeftSideValue != 2 && LeftSideValue != 10)
+return;
+
+  if (LeftSideValue.getBitWidth() != RightSideValue.getBitWidth())
 return;
 
   CharSourceRange ExprRange = CharSourceRange::getCharRange(
@@ -11123,10 +11132,6 @@ static void diagnoseXorMisusedAsPow(Sema
   if (XorStr == "xor")
 return;
 
-  const llvm::APInt  = LHSInt->getValue();
-  const llvm::APInt  = RHSInt->getValue();
-  const llvm::APInt XorValue = LeftSideValue ^ RightSideValue;
-
   std::string LHSStr = Lexer::getSourceText(
   CharSourceRange::getTokenRange(LHSInt->getSourceRange()),
   S.getSourceManager(), S.getLangOpts());
@@ -11134,23 +11139,30 @@ static void diagnoseXorMisusedAsPow(Sema
   CharSourceRange::getTokenRange(RHSInt->getSourceRange()),
   S.getSourceManager(), S.getLangOpts());
 
-  int64_t RightSideIntValue = RightSideValue.getSExtValue();
   if (Negative) {
-RightSideIntValue = -RightSideIntValue;
+RightSideValue = -RightSideValue;
 RHSStr = "-" + RHSStr;
+  } else if (ExplicitPlus) {
+RHSStr = "+" + RHSStr;
   }
 
   StringRef LHSStrRef = LHSStr;
   StringRef RHSStrRef = RHSStr;
-  // Do not diagnose binary, hexadecimal, octal literals.
+  // Do not diagnose literals with digit separators, binary, hexadecimal, octal
+  // literals.
   if (LHSStrRef.startswith("0b") || LHSStrRef.startswith("0B") ||
   RHSStrRef.startswith("0b") || RHSStrRef.startswith("0B") ||
   LHSStrRef.startswith("0x") || LHSStrRef.startswith("0X") ||
   RHSStrRef.startswith("0x") || RHSStrRef.startswith("0X") ||
   

[PATCH] D67028: Use musttail for variadic method thunks when possible

[Reid Kleckner via Phabricator via cfe-commits]

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

In D67028#1653439 , @efriedma wrote:

> Do we have test coverage for a variadic, covariant thunk for a function 
> without a definition?  I don't think there's any way for us to actually emit 
> that, but we should make sure the error message is right.


That appears to have been PR18098, so we have a test for it in thunks.cpp. The 
way the Itanium C++ ABI works, thunks are always emitted as `weak_odr` in TUs 
that provide the implementation, so emitting them with the vtable is just an 
optimization. Basically, clang never *has* to emit a thunk when the definition 
isn't present, it can always choose to simply declare it, and that's what we do 
here: 
https://github.com/llvm/llvm-project/blob/7c8952197b86790b31731d34d559281840916e1f/clang/lib/CodeGen/CGVTables.cpp#L558

In the MS ABI, deriving a new class may require the creation of new thunks for 
methods that were not overridden, so we can't use the same trick.

I think my two new tests are redundant with tests in thunks.cpp, so perhaps I 
should just add some new RUN lines there.

> I'm a little concerned that using musttail thunks with the Itanium ABI will 
> flush out bugs that have been hiding because we have less test coverage on 
> Windows. But it's probably the right thing to do.

True, it's a risk. One other thing worth mentioning is that the IR cloning 
doesn't actually work in the presence of labels-as-values, so we are improving 
conformance in that extra, extra corner case.




Comment at: clang/lib/CodeGen/CGVTables.cpp:206
+  AdjustedThisPtr = Builder.CreateBitCast(AdjustedThisPtr,
+  ThisStore->getOperand(0)->getType());
   ThisStore->setOperand(0, AdjustedThisPtr);

efriedma wrote:
> This is fine, I guess, but how is it related?
The MS ABI implementation of `performThisAdjustment` returns a pointer that 
needs to be cast. The covariant test exercises this codepath in the MS ABI, and 
we didn't do that before. I guess the Itanium one does the cast internally, but 
the MS ABI impl has this comment:
  // Don't need to bitcast back, the call CodeGen will handle this.
  return V;

I probably removed the cast when trying to clean up our generated IR.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67028



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

r371117 - [clang][Index] Replace CodegenNameGenerator with ASTNameGenerator

[Jan Korous via cfe-commits]

Author: jkorous
Date: Thu Sep  5 13:33:52 2019
New Revision: 371117

URL: http://llvm.org/viewvc/llvm-project?rev=371117=rev
Log:
[clang][Index] Replace CodegenNameGenerator with ASTNameGenerator

Follow-up to: 3ff8c3b73f6, d5d15b4c1fd

Should be NFC since the original patch just moved the code.

Removed:
cfe/trunk/include/clang/Index/CodegenNameGenerator.h
cfe/trunk/lib/Index/CodegenNameGenerator.cpp
Modified:
cfe/trunk/lib/Index/CMakeLists.txt
cfe/trunk/tools/c-index-test/core_main.cpp
cfe/trunk/tools/libclang/CIndex.cpp

Removed: cfe/trunk/include/clang/Index/CodegenNameGenerator.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Index/CodegenNameGenerator.h?rev=371116=auto
==
--- cfe/trunk/include/clang/Index/CodegenNameGenerator.h (original)
+++ cfe/trunk/include/clang/Index/CodegenNameGenerator.h (removed)
@@ -1,52 +0,0 @@
-//===- CodegenNameGenerator.h - Codegen name generation 
---===//
-//
-// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
-// See https://llvm.org/LICENSE.txt for license information.
-// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-//
-//===--===//
-//
-// Determines the name that the symbol will get for code generation.
-//
-//===--===//
-
-#ifndef LLVM_CLANG_INDEX_CODEGENNAMEGENERATOR_H
-#define LLVM_CLANG_INDEX_CODEGENNAMEGENERATOR_H
-
-#include "clang/AST/Mangle.h"
-#include "clang/Basic/LLVM.h"
-#include 
-#include 
-#include 
-
-namespace clang {
-  class ASTContext;
-  class Decl;
-
-namespace index {
-
-class CodegenNameGenerator {
-public:
-  explicit CodegenNameGenerator(ASTContext );
-  ~CodegenNameGenerator();
-
-  /// \returns true on failure to produce a name for the given decl, false on
-  /// success.
-  bool writeName(const Decl *D, raw_ostream );
-
-  /// Version of \c writeName function that returns a string.
-  std::string getName(const Decl *D);
-
-  /// This can return multiple mangled names when applicable, e.g. for C++
-  /// constructors/destructors.
-  std::vector getAllManglings(const Decl *D);
-
-private:
-  struct Implementation;
-  std::unique_ptr Impl;
-};
-
-} // namespace index
-} // namespace clang
-
-#endif // LLVM_CLANG_INDEX_CODEGENNAMEGENERATOR_H

Modified: cfe/trunk/lib/Index/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Index/CMakeLists.txt?rev=371117=371116=371117=diff
==
--- cfe/trunk/lib/Index/CMakeLists.txt (original)
+++ cfe/trunk/lib/Index/CMakeLists.txt Thu Sep  5 13:33:52 2019
@@ -4,7 +4,6 @@ set(LLVM_LINK_COMPONENTS
   )
 
 add_clang_library(clangIndex
-  CodegenNameGenerator.cpp
   CommentToXML.cpp
   FileIndexRecord.cpp
   IndexBody.cpp

Removed: cfe/trunk/lib/Index/CodegenNameGenerator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Index/CodegenNameGenerator.cpp?rev=371116=auto
==
--- cfe/trunk/lib/Index/CodegenNameGenerator.cpp (original)
+++ cfe/trunk/lib/Index/CodegenNameGenerator.cpp (removed)
@@ -1,36 +0,0 @@
-//===- CodegenNameGenerator.cpp - Codegen name generation 
-===//
-//
-// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
-// See https://llvm.org/LICENSE.txt for license information.
-// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-//
-//===--===//
-//
-// Determines the name that the symbol will get for code generation.
-//
-//===--===//
-
-#include "clang/Index/CodegenNameGenerator.h"
-#include "clang/AST/ASTContext.h"
-
-using namespace clang;
-using namespace clang::index;
-
-CodegenNameGenerator::CodegenNameGenerator(ASTContext )
-  : Impl(new ASTNameGenerator(Ctx)) {
-}
-
-CodegenNameGenerator::~CodegenNameGenerator() {
-}
-
-bool CodegenNameGenerator::writeName(const Decl *D, raw_ostream ) {
-  return Impl->writeName(D, OS);
-}
-
-std::string CodegenNameGenerator::getName(const Decl *D) {
-  return Impl->getName(D);
-}
-
-std::vector CodegenNameGenerator::getAllManglings(const Decl *D) {
-  return Impl->getAllManglings(D);
-}

Modified: cfe/trunk/tools/c-index-test/core_main.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/c-index-test/core_main.cpp?rev=371117=371116=371117=diff
==
--- cfe/trunk/tools/c-index-test/core_main.cpp (original)
+++ cfe/trunk/tools/c-index-test/core_main.cpp Thu Sep  5 13:33:52 2019
@@ -6,6 +6,7 @@
 //
 
//===--===//
 
+#include "clang/AST/Mangle.h"

[PATCH] D67140: [analyzer][NFC] Fix inconsistent references to checkers as "checks"

[Dmitri Gribenko via Phabricator via cfe-commits]

gribozavr added a comment.

In D67140#1658365 , @aaron.ballman 
wrote:

> In D67140#1658353 , @gribozavr wrote:
>
> > In D67140#1658315 , @aaron.ballman 
> > wrote:
> >
> > > In D67140#1656831 , @NoQ wrote:
> > >
> > > > Honestly, i'm much more worried about message capitalization :)
> > >
> > >
> > > Likewise. I wish the static analyzer would follow the usual conventions 
> > > followed by clang and clang-tidy. ;-)
> >
> >
> > I have the opposite opinion -- I wish that ClangTidy used complete 
> > sentences, and multiple sentences if it makes sense. The sentence fragments 
> > are too brief to explain complex and nuanced topics that ClangTidy 
> > communicates about. ClangTidy often plays the role of a developer education 
> > tool. It is not a guard like a compiler; developers can totally ignore 
> > ClangTidy if they disagree with the message. The better we can explain the 
> > problem, the more likely it is the developer will act on the message. I 
> > believe static analysis tools would be better off if we could write 
> > multiple sentences in the diagnostic.
> >
> > Even for compiler messages, a sentence fragment is sometimes too concise.
>
>
> I agree with you in principle, but practicality still matters. I don't 
> imagine we're going to go back and change the thousands of diagnostics in 
> Clang to be complete sentences, and I prefer my diagnostics to be consistent. 
> It's jarring when one part of the compiler uses one style of diagnostics and 
> another part of the compiler uses a different style. So while I'd love it if 
> we had more descriptive diagnostics, I would be happy to settle for 
> consistent styles of diagnostics.


Why do static analysis tools have to be consistent with Clang in its message 
style?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67140



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

[PATCH] D67140: [analyzer][NFC] Fix inconsistent references to checkers as "checks"

[Dmitri Gribenko via Phabricator via cfe-commits]

gribozavr added a comment.

In D67140#1659356 , @aaron.ballman 
wrote:

> In D67140#1658969 , @gribozavr wrote:
>
> > In D67140#1658365 , @aaron.ballman 
> > wrote:
> >
> > > Ah, good to know! That reduces my concern, but doesn't negate it. AFAIK, 
> > > we haven't changed the interface such that it requires code changes 
> > > rather than just a recompile in recent history, so this is a bit novel.
> >
> >
> > I think API changes happen all the time. At Google, we are integrating 
> > upstream LLVM and Clang changes into our internal codebase daily. We have a 
> > lot of internal ClangTidy checkers. Fixing up all our internal code to keep 
> > with upstream changes is a full time job for one engineer (but it is a 
> > rotation).
>
>
> I think this sort of backs up the point I was making.


Sorry, but in the previous comment you were saying that "we haven't changed the 
interface such that it requires code changes". So which is it, for you?

> It requires an FTE to keep up with the breaks already.

Exactly. So one more or one less API change that requires a trivial code change 
*does not matter*. People working on the Clang upgrade still have a ton of 
other, complex, changes to deal with. Is it more work to upgrade for this sort 
of API rename? Yes. Is meaningfully more work, if you look at everything that 
needs to be done as a whole? No. It will not be a thing that makes or breaks 
someone's Clang upgrade.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67140



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

[PATCH] D64671: [clang-tidy] New check: misc-init-local-variables

[Jussi Pakkanen via Phabricator via cfe-commits]

jpakkane updated this revision to Diff 218970.
jpakkane marked 2 inline comments as done.
jpakkane added a comment.

Fixed issues raised in review.


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

https://reviews.llvm.org/D64671

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/InitVariablesCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/InitVariablesCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-init-variables.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/cppcoreguidelines-init-variables.cpp

Index: clang-tools-extra/test/clang-tidy/cppcoreguidelines-init-variables.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/cppcoreguidelines-init-variables.cpp
@@ -0,0 +1,80 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-init-variables %t
+
+// Ensure that function declarations are not changed.
+void some_func(int x, double d, bool b, const char *p);
+
+// Ensure that function arguments are not changed
+int identity_function(int x) {
+  return x;
+}
+
+int do_not_modify_me;
+
+static int should_not_be_initialized;
+extern int should_not_be_initialized2;
+
+typedef struct {
+  int unaltered1;
+  int unaltered2;
+} UnusedStruct;
+
+typedef int my_int_type;
+#define MACRO_INT int
+#define FULL_DECLARATION() int macrodecl;
+
+template 
+void template_test_function() {
+  T t;
+  int uninitialized;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: variable 'uninitialized' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  int uninitialized = 0;{{$}}
+}
+
+void init_unit_tests() {
+  int x;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: variable 'x' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  int x = 0;{{$}}
+  my_int_type myint;
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: variable 'myint' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  my_int_type myint = 0;{{$}}
+
+  MACRO_INT macroint;
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: variable 'macroint' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  MACRO_INT macroint = 0;{{$}}
+  FULL_DECLARATION();
+
+  int x0 = 1, x1, x2 = 2;
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: variable 'x1' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  int x0 = 1, x1 = 0, x2 = 2;{{$}}
+  int y0, y1 = 1, y2;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: variable 'y0' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-MESSAGES: :[[@LINE-2]]:19: warning: variable 'y2' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  int y0 = 0, y1 = 1, y2 = 0;{{$}}
+  int hasval = 42;
+
+  float f;
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: variable 'f' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  float f = NAN;{{$}}
+  float fval = 85.0;
+  double d;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: variable 'd' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  double d = NAN;{{$}}
+  double dval = 99.0;
+
+  bool b;
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: variable 'b' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  bool b = 0;{{$}}
+  bool bval = true;
+
+  const char *ptr;
+  // CHECK-MESSAGES: :[[@LINE-1]]:15: warning: variable 'ptr' is not initialized [cppcoreguidelines-init-variables]
+  // CHECK-FIXES: {{^}}  const char *ptr = nullptr;{{$}}
+  const char *ptrval = "a string";
+
+  UnusedStruct u;
+
+  static int does_not_need_an_initializer;
+  extern int does_not_need_an_initializer2;
+  int parens(42);
+  int braces{42};
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -193,6 +193,7 @@
cppcoreguidelines-avoid-magic-numbers (redirects to readability-magic-numbers) 
cppcoreguidelines-c-copy-assignment-signature (redirects to misc-unconventional-assign-operator) 
cppcoreguidelines-explicit-virtual-functions (redirects to modernize-use-override) 
+   cppcoreguidelines-init-variables
cppcoreguidelines-interfaces-global-init
cppcoreguidelines-macro-usage
cppcoreguidelines-narrowing-conversions
Index: clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-init-variables.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-init-variables.rst
@@ -0,0 +1,39 @@
+.. title:: clang-tidy - cppcoreguidelines-init-variables
+

r371113 - Revert: [DebugInfo] Add debug location to stubs generated by CGDeclCXX and mark them as artificial

[Alexandre Ganea via cfe-commits]

Author: aganea
Date: Thu Sep  5 13:12:20 2019
New Revision: 371113

URL: http://llvm.org/viewvc/llvm-project?rev=371113=rev
Log:
Revert: [DebugInfo] Add debug location to stubs generated by CGDeclCXX and mark 
them as artificial

Removed:
cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp
cfe/trunk/test/CodeGenCXX/debug-info-destroy-helper.cpp
Modified:
cfe/trunk/include/clang/AST/GlobalDecl.h
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
cfe/trunk/test/CodeGenCXX/debug-info-global-ctor-dtor.cpp
cfe/trunk/test/CodeGenCXX/debug-info-line.cpp

Modified: cfe/trunk/include/clang/AST/GlobalDecl.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/GlobalDecl.h?rev=371113=371112=371113=diff
==
--- cfe/trunk/include/clang/AST/GlobalDecl.h (original)
+++ cfe/trunk/include/clang/AST/GlobalDecl.h Thu Sep  5 13:12:20 2019
@@ -31,7 +31,6 @@ enum class DynamicInitKind : unsigned {
   NoStub = 0,
   Initializer,
   AtExit,
-  GlobalArrayDestructor
 };
 
 /// GlobalDecl - represents a global declaration. This can either be a

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=371113=371112=371113=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Sep  5 13:12:20 2019
@@ -1910,8 +1910,7 @@ StringRef CGDebugInfo::getDynamicInitial
  llvm::Function *InitFn) {
   // If we're not emitting codeview, use the mangled name. For Itanium, this is
   // arbitrary.
-  if (!CGM.getCodeGenOpts().EmitCodeView ||
-  StubKind == DynamicInitKind::GlobalArrayDestructor)
+  if (!CGM.getCodeGenOpts().EmitCodeView)
 return InitFn->getName();
 
   // Print the normal qualified name for the variable, then break off the last
@@ -1936,7 +1935,6 @@ StringRef CGDebugInfo::getDynamicInitial
 
   switch (StubKind) {
   case DynamicInitKind::NoStub:
-  case DynamicInitKind::GlobalArrayDestructor:
 llvm_unreachable("not an initializer");
   case DynamicInitKind::Initializer:
 OS << "`dynamic initializer for '";
@@ -3571,8 +3569,7 @@ void CGDebugInfo::EmitFunctionStart(Glob
   if (Name.startswith("\01"))
 Name = Name.substr(1);
 
-  if (!HasDecl || D->isImplicit() || D->hasAttr() ||
-  (isa(D) && GD.getDynamicInitKind() != DynamicInitKind::NoStub)) 
{
+  if (!HasDecl || D->isImplicit() || D->hasAttr()) {
 Flags |= llvm::DINode::FlagArtificial;
 // Artificial functions should not silently reuse CurLoc.
 CurLoc = SourceLocation();

Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDeclCXX.cpp?rev=371113=371112=371113=diff
==
--- cfe/trunk/lib/CodeGen/CGDeclCXX.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDeclCXX.cpp Thu Sep  5 13:12:20 2019
@@ -247,8 +247,6 @@ llvm::Function *CodeGenFunction::createA
 
   CGF.StartFunction(GlobalDecl(, DynamicInitKind::AtExit),
 CGM.getContext().VoidTy, fn, FI, FunctionArgList());
-  // Emit an artificial location for this function.
-  auto AL = ApplyDebugLocation::CreateArtificial(CGF);
 
   llvm::CallInst *call = CGF.Builder.CreateCall(dtor, addr);
 
@@ -644,9 +642,8 @@ void CodeGenFunction::GenerateCXXGlobalV
 
   StartFunction(GlobalDecl(D, DynamicInitKind::Initializer),
 getContext().VoidTy, Fn, getTypes().arrangeNullaryFunction(),
-FunctionArgList());
-  // Emit an artificial location for this function.
-  auto AL = ApplyDebugLocation::CreateArtificial(*this);
+FunctionArgList(), D->getLocation(),
+D->getInit()->getExprLoc());
 
   // Use guarded initialization if the global variable is weak. This
   // occurs for, e.g., instantiated static data members and
@@ -771,10 +768,7 @@ llvm::Function *CodeGenFunction::generat
 
   CurEHLocation = VD->getBeginLoc();
 
-  StartFunction(GlobalDecl(VD, DynamicInitKind::GlobalArrayDestructor),
-getContext().VoidTy, fn, FI, args);
-  // Emit an artificial location for this function.
-  auto AL = ApplyDebugLocation::CreateArtificial(*this);
+  StartFunction(VD, getContext().VoidTy, fn, FI, args);
 
   emitDestroy(addr, type, destroyer, useEHCleanupForArray);
 

Removed: cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp?rev=371112=auto
==
--- cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp (removed)
@@ -1,20 +0,0 @@
-// RUN: %clang_cc1 -emit-llvm %s -triple 

[PATCH] D67122: [UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined behaviour

[Vedant Kumar via Phabricator via cfe-commits]

vsk added a comment.

Still think this looks good. Have you tried running this on the llvm test 
suite, or some other interesting corpus? Would be curious to see any pre/post 
patch numbers.




Comment at: clang/lib/CodeGen/CGExprScalar.cpp:4703-4720
+// 2) The sign of the difference between the computed address and the base
+// pointer matches the sign of the total offset.
+llvm::Value *ValidGEP;
+auto *NoOffsetOverflow = Builder.CreateNot(OffsetOverflows);
+if (SignedIndices) {
+  auto *PosOrZeroValid = Builder.CreateICmpUGE(ComputedGEP, IntPtr);
+  auto *PosOrZeroOffset = Builder.CreateICmpSGE(TotalOffset, Zero);

lebedev.ri wrote:
> lebedev.ri wrote:
> > This makes me ick every time i look at it.
> > I wonder if this can be sanely rewritten via `.with.overflow` intrinsic..
> Hm, 
> ```
> Name: add unsigned
>   %computed = add i8 %base, %offset
>   %PosOrZeroValid = icmp uge i8 %computed, %base
> =>
>   %agg = uadd_overflow i8 %base, %offset
>   %computed = extractvalue i8 %agg, 0
>   %ov = extractvalue i1 %agg, 1
>   %PosOrZeroValid = xor i1 %ov, -1
> 
> Name: sub unsigned
>   %computed = add i8 %base, %offset
>   %PosOrZeroValid = icmp ule i8 %computed, %base
> =>
>   %negated_offset = sub i8 0, %offset
>   %agg = usub_overflow i8 %base, %negated_offset
>   %computed = extractvalue i8 %agg, 0
>   %ov = extractvalue i1 %agg, 1
>   %PosOrZeroValid = xor i1 %ov, -1
> 
> Name: add signed
>   %computed = add i8 %base, %offset
>   %PosOrZeroValid = icmp uge i8 %computed, %base
>   %PosOrZeroOffset = icmp sge i8 %offset, 0
>   %NegValid = icmp ult i8 %computed, %base
>   %OKay = select i1 %PosOrZeroOffset, i1 %PosOrZeroValid, i1 %NegValid
> =>
>   %uadd.agg = uadd_overflow i8 %base, %offset
>   %uadd.ov = extractvalue i1 %uadd.agg, 1
>   %negated_offset = sub i8 0, %offset
>   %usub.agg = usub_overflow i8 %base, %negated_offset
>   %usub.ov = extractvalue i1 %usub.agg, 1
>   %computed = add i8 %base, %offset
>   %PosOrZeroOffset = icmp sge i8 %offset, 0
>   %NotOKay = select i1 %PosOrZeroOffset, i1 %uadd.ov, i1 %usub.ov
>   %OKay = xor i1 %NotOKay, -1
> ```
> 
> That's not great, but i wonder what is more friendly to middle-end.
> https://godbolt.org/z/ORSU_L
I suggest splitting out changes to the existing pointer wraparound check in a 
follow-up patch. This may well be an improvement, but there are enough moving 
parts to this patch as-is.



Comment at: clang/test/CodeGen/catch-nullptr-and-nonzero-offset-blacklist.c:1
+// RUN: %clang_cc1 -fsanitize=pointer-overflow 
-fsanitize-recover=pointer-overflow -emit-llvm %s -o - -triple x86_64-linux-gnu 
| FileCheck %s -implicit-check-not="call void @__ubsan_handle_pointer_overflow" 
--check-prefixes=CHECK,CHECK-NULL-IS-INVALID-PTR
+// RUN: %clang_cc1 -fno-delete-null-pointer-checks -fsanitize=pointer-overflow 
-fsanitize-recover=pointer-overflow -emit-llvm %s -o - -triple x86_64-linux-gnu 
| FileCheck %s -implicit-check-not="call void @__ubsan_handle_pointer_overflow" 
--check-prefixes=CHECK,CHECK-NULL-IS-VALID-PTR

lebedev.ri wrote:
> vsk wrote:
> > Should the test filename be "ignore-nullptr-and-nonzero-..."?
> `-blacklist.c` is the filename i have i used for all similar testfiles in all 
> previous sanitizers.
> "black list" means here "list of cases where no sanitization will be emitted".
This is minor. I only raised the nit as I felt that this test was about 
ignoring "foo", not about catching "foo", and that "blacklist" already means 
something else in the context of sanitizers. Happy to defer to your preference 
here.



Comment at: clang/test/CodeGen/catch-nullptr-and-nonzero-offset.c:66
+  // CHECK: define i8* @var_zero_OK(i8* %[[BASE:.*]])
+  // CHECK-NEXT: [[ENTRY:.*]]:
+  // CHECK-NEXT: %[[BASE_ADDR:.*]] = alloca i8*, align 8

lebedev.ri wrote:
> vsk wrote:
> > Does this simplify to:
> > 
> > ```
> > CHECK-LABEL: define i8* @var_zero_ok(
> > CHECK-NOT: !nosanitize
> > ```
> I find it easier to reason about readable check lines.
Ah, sure, having the IR written out explicitly can help. The downside is that 
it's more to read/maintain, and arguably the key idea here is that "no 
sanitizer stuff happens" since presumably IRGen for generic pointer arithmetic 
is tested elsewhere, but again this is minor & I'm happy to defer on this.



Comment at: clang/test/CodeGen/ubsan-pointer-overflow.m:48
 void pointer_array_unsigned_indices(int **arr, unsigned k) {
   // CHECK: icmp uge
   // CHECK-NOT: select

lebedev.ri wrote:
> vsk wrote:
> > I'm curious about what happens here with the new null-status-change check. 
> > If array indices are unsigned, there is no need for a separate 
> > null-status-change check: if the result of the GEP is indeed null, that 
> > will be detected by the pointer wraparound check. We just need to check 
> > that the base pointer itself isn't null.
> > 
> > That generalizes to 

r371112 - [AST][NFC] Doc comments for ASTNameGenerator

[Jan Korous via cfe-commits]

Author: jkorous
Date: Thu Sep  5 13:04:11 2019
New Revision: 371112

URL: http://llvm.org/viewvc/llvm-project?rev=371112=rev
Log:
[AST][NFC] Doc comments for ASTNameGenerator

Modified:
cfe/trunk/include/clang/AST/Mangle.h

Modified: cfe/trunk/include/clang/AST/Mangle.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Mangle.h?rev=371112=37=371112=diff
==
--- cfe/trunk/include/clang/AST/Mangle.h (original)
+++ cfe/trunk/include/clang/AST/Mangle.h Thu Sep  5 13:04:11 2019
@@ -250,8 +250,16 @@ class ASTNameGenerator {
 public:
   explicit ASTNameGenerator(ASTContext );
   ~ASTNameGenerator();
+
+  /// Writes name for \p D to \p OS.
+  /// \returns true on failure, false on success.
   bool writeName(const Decl *D, raw_ostream );
+
+  /// \returns name for \p D
   std::string getName(const Decl *D);
+
+  /// \returns all applicable mangled names.
+  /// For example C++ constructors/destructors can have multiple.
   std::vector getAllManglings(const Decl *D);
 
 private:


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

Re: r371080 - [DebugInfo] Add debug location to stubs generated by CGDeclCXX and mark them as artificial

[Erik Pilkington via cfe-commits]

Hi Alexandre,

Looks like this commit is causing crashes on darwin, can you take a look
please? Here is a failing bot:
http://lab.llvm.org:8080/green/job/clang-stage1-RA/1671/

Thanks!
Erik

On Thu, Sep 5, 2019 at 11:23 AM Alexandre Ganea via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: aganea
> Date: Thu Sep  5 08:24:49 2019
> New Revision: 371080
>
> URL: http://llvm.org/viewvc/llvm-project?rev=371080=rev
> Log:
> [DebugInfo] Add debug location to stubs generated by CGDeclCXX and mark
> them as artificial
>
> Differential Revision: https://reviews.llvm.org/D66328
>
> Added:
> cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp
> cfe/trunk/test/CodeGenCXX/debug-info-destroy-helper.cpp
> Modified:
> cfe/trunk/include/clang/AST/GlobalDecl.h
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> cfe/trunk/test/CodeGenCXX/debug-info-global-ctor-dtor.cpp
> cfe/trunk/test/CodeGenCXX/debug-info-line.cpp
>
> Modified: cfe/trunk/include/clang/AST/GlobalDecl.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/GlobalDecl.h?rev=371080=371079=371080=diff
>
> ==
> --- cfe/trunk/include/clang/AST/GlobalDecl.h (original)
> +++ cfe/trunk/include/clang/AST/GlobalDecl.h Thu Sep  5 08:24:49 2019
> @@ -31,6 +31,7 @@ enum class DynamicInitKind : unsigned {
>NoStub = 0,
>Initializer,
>AtExit,
> +  GlobalArrayDestructor
>  };
>
>  /// GlobalDecl - represents a global declaration. This can either be a
>
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=371080=371079=371080=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Sep  5 08:24:49 2019
> @@ -1910,7 +1910,8 @@ StringRef CGDebugInfo::getDynamicInitial
>   llvm::Function *InitFn) {
>// If we're not emitting codeview, use the mangled name. For Itanium,
> this is
>// arbitrary.
> -  if (!CGM.getCodeGenOpts().EmitCodeView)
> +  if (!CGM.getCodeGenOpts().EmitCodeView ||
> +  StubKind == DynamicInitKind::GlobalArrayDestructor)
>  return InitFn->getName();
>
>// Print the normal qualified name for the variable, then break off the
> last
> @@ -1935,6 +1936,7 @@ StringRef CGDebugInfo::getDynamicInitial
>
>switch (StubKind) {
>case DynamicInitKind::NoStub:
> +  case DynamicInitKind::GlobalArrayDestructor:
>  llvm_unreachable("not an initializer");
>case DynamicInitKind::Initializer:
>  OS << "`dynamic initializer for '";
> @@ -3569,7 +3571,8 @@ void CGDebugInfo::EmitFunctionStart(Glob
>if (Name.startswith("\01"))
>  Name = Name.substr(1);
>
> -  if (!HasDecl || D->isImplicit() || D->hasAttr()) {
> +  if (!HasDecl || D->isImplicit() || D->hasAttr() ||
> +  (isa(D) && GD.getDynamicInitKind() !=
> DynamicInitKind::NoStub)) {
>  Flags |= llvm::DINode::FlagArtificial;
>  // Artificial functions should not silently reuse CurLoc.
>  CurLoc = SourceLocation();
>
> Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDeclCXX.cpp?rev=371080=371079=371080=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGDeclCXX.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDeclCXX.cpp Thu Sep  5 08:24:49 2019
> @@ -247,6 +247,8 @@ llvm::Function *CodeGenFunction::createA
>
>CGF.StartFunction(GlobalDecl(, DynamicInitKind::AtExit),
>  CGM.getContext().VoidTy, fn, FI, FunctionArgList());
> +  // Emit an artificial location for this function.
> +  auto AL = ApplyDebugLocation::CreateArtificial(CGF);
>
>llvm::CallInst *call = CGF.Builder.CreateCall(dtor, addr);
>
> @@ -642,8 +644,9 @@ void CodeGenFunction::GenerateCXXGlobalV
>
>StartFunction(GlobalDecl(D, DynamicInitKind::Initializer),
>  getContext().VoidTy, Fn,
> getTypes().arrangeNullaryFunction(),
> -FunctionArgList(), D->getLocation(),
> -D->getInit()->getExprLoc());
> +FunctionArgList());
> +  // Emit an artificial location for this function.
> +  auto AL = ApplyDebugLocation::CreateArtificial(*this);
>
>// Use guarded initialization if the global variable is weak. This
>// occurs for, e.g., instantiated static data members and
> @@ -768,7 +771,10 @@ llvm::Function *CodeGenFunction::generat
>
>CurEHLocation = VD->getBeginLoc();
>
> -  StartFunction(VD, getContext().VoidTy, fn, FI, args);
> +  StartFunction(GlobalDecl(VD, DynamicInitKind::GlobalArrayDestructor),
> +getContext().VoidTy, fn, FI, args);
> +  // Emit an artificial location for this function.
> +  auto AL = 

[PATCH] D64644: [Sema] Fixes an assertion failure while instantiation a template with an incomplete typo corrected type

[Mark de Wever via Phabricator via cfe-commits]

Mordante updated this revision to Diff 218965.
Mordante marked an inline comment as done.
Mordante added a comment.

Removes the unnecessary std::move as suggested by @aaron.ballman.


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

https://reviews.llvm.org/D64644

Files:
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/SemaTemplate/instantiate-incomplete-typo-suggested-error-limit.cpp


Index: 
clang/test/SemaTemplate/instantiate-incomplete-typo-suggested-error-limit.cpp
===
--- /dev/null
+++ 
clang/test/SemaTemplate/instantiate-incomplete-typo-suggested-error-limit.cpp
@@ -0,0 +1,60 @@
+// RUN: not %clang -fsyntax-only -std=c++11 -ferror-limit=1 %s 2>&1 | 
FileCheck %s
+
+// Test case for PR35682.
+// The issue be caused by the typo correction that changes String to the
+// incomplete type string. The example is based on the std::pair code and
+// reduced to a minimal test case. When using std::pair the issue can only be
+// reproduced when using the -stdlib=libc++ compiler option.
+
+template  class allocator;
+
+template  struct char_traits;
+
+template ,
+  class Allocator = allocator>
+class basic_string;
+typedef basic_string, allocator> string;
+
+template  struct enable_if {};
+template  struct enable_if { typedef Tp type; };
+
+template  struct integral_constant {
+  static constexpr const Tp value = v;
+  typedef Tp value_type;
+  typedef integral_constant type;
+
+  constexpr operator value_type() const noexcept { return value; }
+  constexpr value_type operator()() const noexcept { return value; }
+};
+
+template  constexpr const Tp integral_constant::value;
+
+using true_type = integral_constant;
+using false_type = integral_constant;
+
+template  struct is_same : public false_type {};
+template  struct is_same : public true_type {};
+
+template  struct single {
+  typedef T first_type;
+
+  T first;
+
+  struct CheckArgs {
+template  static constexpr bool enable_implicit() {
+  return is_same::value;
+}
+  };
+
+  template (),
+   bool>::type = false>
+  single(U1 &);
+};
+
+using SetKeyType = String;
+single v;
+
+// CHECK: error: unknown type name 'String'; did you mean 'string'?
+// CHECK: fatal error: too many errors emitted, stopping now [-ferror-limit=]
+// CHECK-NOT: Assertion{{.*}}failed
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -718,9 +718,13 @@
 SourceLocation TemplateKWLoc,
 const DeclarationNameInfo ,
 const TemplateArgumentListInfo *TemplateArgs) {
+  // DependentScopeDeclRefExpr::Create requires a valid QualifierLoc
+  NestedNameSpecifierLoc QualifierLoc = SS.getWithLocInContext(Context);
+  if (!QualifierLoc)
+return ExprError();
+
   return DependentScopeDeclRefExpr::Create(
-  Context, SS.getWithLocInContext(Context), TemplateKWLoc, NameInfo,
-  TemplateArgs);
+  Context, QualifierLoc, TemplateKWLoc, NameInfo, TemplateArgs);
 }
 
 


Index: clang/test/SemaTemplate/instantiate-incomplete-typo-suggested-error-limit.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/instantiate-incomplete-typo-suggested-error-limit.cpp
@@ -0,0 +1,60 @@
+// RUN: not %clang -fsyntax-only -std=c++11 -ferror-limit=1 %s 2>&1 | FileCheck %s
+
+// Test case for PR35682.
+// The issue be caused by the typo correction that changes String to the
+// incomplete type string. The example is based on the std::pair code and
+// reduced to a minimal test case. When using std::pair the issue can only be
+// reproduced when using the -stdlib=libc++ compiler option.
+
+template  class allocator;
+
+template  struct char_traits;
+
+template ,
+  class Allocator = allocator>
+class basic_string;
+typedef basic_string, allocator> string;
+
+template  struct enable_if {};
+template  struct enable_if { typedef Tp type; };
+
+template  struct integral_constant {
+  static constexpr const Tp value = v;
+  typedef Tp value_type;
+  typedef integral_constant type;
+
+  constexpr operator value_type() const noexcept { return value; }
+  constexpr value_type operator()() const noexcept { return value; }
+};
+
+template  constexpr const Tp integral_constant::value;
+
+using true_type = integral_constant;
+using false_type = integral_constant;
+
+template  struct is_same : public false_type {};
+template  struct is_same : public true_type {};
+
+template  struct single {
+  typedef T first_type;
+
+  T first;
+
+  struct CheckArgs {
+template  static constexpr bool enable_implicit() {
+  return is_same::value;
+}
+  };
+
+  template (),
+   bool>::type = false>
+  single(U1 &);
+};
+
+using SetKeyType = String;
+single v;
+
+// CHECK: error: 

[PATCH] D64644: [Sema] Fixes an assertion failure while instantiation a template with an incomplete typo corrected type

[Mark de Wever via Phabricator via cfe-commits]

Mordante marked 3 inline comments as done.
Mordante added inline comments.



Comment at: 
clang/test/SemaTemplate/instantiate-incomplete-typo-suggested-error-limit.cpp:1
+// RUN: not %clang -fsyntax-only -std=c++11 -ferror-limit=1 %s 2>&1 | 
FileCheck %s
+

aaron.ballman wrote:
> Do you intend to test `%clang_cc1` instead? Can the test be rewritten to use 
> `-verify` rather than `FileCheck`? If the test crashes or asserts, that will 
> cause the test to fail anyway, so it doesn't seem like it needs to 
> `FileCheck`.
As discussed on IRC this is not possible due to the fact there is an error 
without line number.
`  (frontend): too many errors emitted, stopping now`


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

https://reviews.llvm.org/D64644



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

Re: r369943 - FileManager: Use llvm::Expected in new getFileRef API

[David Blaikie via cfe-commits]

On Thu, Sep 5, 2019 at 9:57 AM Duncan P. N. Exon Smith 
wrote:

>
>
> On Sep 4, 2019, at 17:39, David Blaikie  wrote:
>
>
>
> On Mon, Aug 26, 2019 at 11:28 AM Duncan P. N. Exon Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: dexonsmith
>> Date: Mon Aug 26 11:29:51 2019
>> New Revision: 369943
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=369943=rev
>> Log:
>> FileManager: Use llvm::Expected in new getFileRef API
>>
>> `FileManager::getFileRef` is a modern API which we expect to convert to
>> over time.  We should modernize the error handling as well, using
>> `llvm::Expected` instead of `llvm::ErrorOr`, to help clients that care
>> about errors to ensure nothing is missed.
>>
>> However, not all clients care.  I've also added another path for those
>> that don't:
>>
>> - `FileEntryRef` is now copy- and move-assignable (using a pointer
>>   instead of a reference).
>> - `FileManager::getOptionalFileRef` returns an `llvm::Optional` instead
>>   of `llvm::Expected`.
>> - Added an `llvm::expectedToOptional` utility in case this is useful
>>   elsewhere.
>>
>
> I'd hesitate to add new general constructs that swallow errors like this -
> keeping them manually written might help avoid their use becoming too
> common.
>
> On that note/direction - are there enough callers of getFileRef that don't
> care about errors that it's really impractical for them to each explicitly
> swallow the errors?
>
>
> `getFileRef` is intended to eventually supplant `getFile` which has many
> users.  Most of them don't care about the error, they just want to know
> whether or not they have a file entry.  If it makes sense to change them at
> some point that's great, but I think having them use `getOptionalFileRef`
> makes it easy to track down (and potentially change) the ones that are
> ignoring the specific error, without requiring a ton of boilerplate at each
> call site in the meantime.  An un-posted version of the patch changed all
> the current call sites of getFileRef to handle/ignore the error explicitly
> and it looked like I was making the code worse.
>

Fair enough - thanks for the context :)


> That said, as long as we have the getOptionalFileRef API, I don't feel
> strongly about the llvm::expectedToOptional utility.  The points in favour
> are that it aligns well with llvm::errorToBool, it reduces boilerplate, and
> it seems both explicit and grep'able.  Maybe that's not compelling enough
> though.
>

I'd have objected to errorToBool on the same grounds if I'd seen the review
- and at least like Lang to take a look at llvm::Error API changes like
this to evaluate how they fit into the desire for strong error handling. I
think escape hatches from that should be implemented pretty cautiously. The
original consumeError was meant to be used very sparingly (& I see you've
provided a similar caveat on expectedToOptional (though there is none on
errorToBool) - thanks for that!

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

[PATCH] D67202: Implement Microsoft-compatible mangling for decomposition declarations.

[Nico Weber via Phabricator via cfe-commits]

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

Thanks!

Re llvm-undname: That seems to match behavior of MSVC's undname, so I'd say 
that's all good :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67202



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

[PATCH] D67200: Add -static-openmp driver option

[Dan Albert via Phabricator via cfe-commits]

danalbert added a comment.

Otherwise LGTM




Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:503
 bool tools::addOpenMPRuntime(ArgStringList , const ToolChain ,
- const ArgList , bool IsOffloadingHost,
- bool GompNeedsRT) {
+ const ArgList , bool StaticHostRuntime,
+ bool IsOffloadingHost, bool GompNeedsRT) {

Maybe `ForceStaticHostRuntime`? For configurations where there is only a static 
runtime available, `StaticHostRuntime = false` won't actually link the dynamic 
runtime.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67200



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

[PATCH] D67200: Add -static-openmp driver option

[Pirama Arumuga Nainar via Phabricator via cfe-commits]

pirama updated this revision to Diff 218959.
pirama added a comment.
Herald added a subscriber: emaste.

Supported this flag for NetBSD and FreeBSD as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67200

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/CommonArgs.h
  clang/lib/Driver/ToolChains/FreeBSD.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/NetBSD.cpp
  clang/test/Driver/fopenmp.c

Index: clang/test/Driver/fopenmp.c
===
--- clang/test/Driver/fopenmp.c
+++ clang/test/Driver/fopenmp.c
@@ -31,6 +31,10 @@
 // RUN: %clang -target x86_64-linux-gnu -fopenmp=libgomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-GOMP --check-prefix=CHECK-LD-GOMP-RT
 // RUN: %clang -target x86_64-linux-gnu -fopenmp=libiomp5 %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-IOMP5
 //
+// RUN: %clang -target x86_64-linux-gnu -fopenmp=libomp -static-openmp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-STATIC-OMP
+// RUN: %clang -target x86_64-linux-gnu -fopenmp=libgomp -static-openmp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-STATIC-GOMP --check-prefix=CHECK-LD-STATIC-GOMP-RT
+// RUN: %clang -target x86_64-linux-gnu -fopenmp=libiomp5 -static-openmp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-STATIC-IOMP5
+//
 // RUN: %clang -nostdlib -target x86_64-linux-gnu -fopenmp=libomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-OMP
 // RUN: %clang -nostdlib -target x86_64-linux-gnu -fopenmp=libgomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-GOMP
 // RUN: %clang -nostdlib -target x86_64-linux-gnu -fopenmp=libiomp5 %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-IOMP5
@@ -47,6 +51,10 @@
 // RUN: %clang -target x86_64-freebsd -fopenmp=libgomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-GOMP --check-prefix=CHECK-LD-GOMP-NO-RT
 // RUN: %clang -target x86_64-freebsd -fopenmp=libiomp5 %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-IOMP5
 //
+// RUN: %clang -target x86_64-freebsd -fopenmp=libomp -static-openmp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-STATIC-OMP
+// RUN: %clang -target x86_64-freebsd -fopenmp=libgomp -static-openmp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-STATIC-GOMP --check-prefix=CHECK-LD-STATIC-GOMP-NO-RT
+// RUN: %clang -target x86_64-freebsd -fopenmp=libiomp5 -static-openmp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-STATIC-IOMP5
+//
 // RUN: %clang -nostdlib -target x86_64-freebsd -fopenmp=libomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-OMP
 // RUN: %clang -nostdlib -target x86_64-freebsd -fopenmp=libgomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-GOMP
 // RUN: %clang -nostdlib -target x86_64-freebsd -fopenmp=libiomp5 %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-IOMP5
@@ -55,6 +63,10 @@
 // RUN: %clang -target x86_64-netbsd -fopenmp=libgomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-GOMP --check-prefix=CHECK-LD-GOMP-NO-RT
 // RUN: %clang -target x86_64-netbsd -fopenmp=libiomp5 %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-IOMP5
 //
+// RUN: %clang -target x86_64-netbsd -fopenmp=libomp -static-openmp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-STATIC-OMP
+// RUN: %clang -target x86_64-netbsd -fopenmp=libgomp -static-openmp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-STATIC-GOMP --check-prefix=CHECK-LD-STATIC-GOMP-NO-RT
+// RUN: %clang -target x86_64-netbsd -fopenmp=libiomp5 -static-openmp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-LD-STATIC-IOMP5
+//
 // RUN: %clang -nostdlib -target x86_64-netbsd -fopenmp=libomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-OMP
 // RUN: %clang -nostdlib -target x86_64-netbsd -fopenmp=libgomp %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-GOMP
 // RUN: %clang -nostdlib -target x86_64-netbsd -fopenmp=libiomp5 %s -o %t -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-IOMP5
@@ -93,6 +105,17 @@
 // CHECK-NO-IOMP5MD: "{{.*}}ld{{(.exe)?}}"
 // CHECK-NO-IOMP5MD-NOT: "-liomp5md"
 //
+// CHECK-LD-STATIC-OMP: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LD-STATIC-OMP: "-Bstatic" "-lomp" "-Bdynamic"
+//
+// CHECK-LD-STATIC-GOMP: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LD-STATIC-GOMP: "-Bstatic" "-lgomp" "-Bdynamic"
+// CHECK-LD-STATIC-GOMP-RT: "-lrt"
+// CHECK-LD-STATIC-NO-GOMP-RT-NOT: "-lrt"
+//
+// CHECK-LD-STATIC-IOMP5: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LD-STATIC-IOMP5: "-Bstatic" "-liomp5" "-Bdynamic"
+//
 // We'd like to check that the default is sane, but until we have the ability
 // to *always* semantically analyze OpenMP without always generating runtime
 // calls (in the event of an unsupported runtime), we don't have a good way to
Index: 

[PATCH] D67031: [Clang][Bundler] Error reporting improvements

[Sergey Dmitriev via Phabricator via cfe-commits]

sdmitriev added a comment.

I think I have addressed all comments posted so far. Do you have more 
notes/comments/suggestions?


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

https://reviews.llvm.org/D67031



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

[PATCH] D65917: [clang-tidy] Added check for the Google style guide's category method naming rule.

[David Gatwood via Phabricator via cfe-commits]

dgatwood added a comment.

Ah.  I expected my comments to be submitted as part of uploading a new 
revision.  Still learning this UI.  :-/




Comment at: 
clang-tools-extra/clang-tidy/google/RequireCategoryMethodPrefixesCheck.cpp:57
+  }
+  std::string method_name = method_declaration->getNameAsString();
+  auto owning_objc_class_interface = method_declaration->getClassInterface();

aaron.ballman wrote:
> dgatwood wrote:
> > aaron.ballman wrote:
> > > This should use `getName()` to get a `StringRef` to avoid the copy.
> > That's actually what I originally tried, but that method won't work here, 
> > unless I'm missing something.  The getName() method crashes with a message 
> > saying that "Name is not a simple identifier".
> You can call `getIdentifier()` instead, and if you get a non-null object 
> back, you can call `getName()` on that. If it is null, there's nothing to 
> check.
I just tried it, and getIdentifier() returns NULL consistently for every 
category method, so I changed it back to getNameAsString(), which works.



Comment at: 
clang-tools-extra/clang-tidy/google/RequireCategoryMethodPrefixesCheck.cpp:57
+  }
+  std::string method_name = method_declaration->getNameAsString();
+  auto owning_objc_class_interface = method_declaration->getClassInterface();

aaron.ballman wrote:
> dgatwood wrote:
> > aaron.ballman wrote:
> > > dgatwood wrote:
> > > > aaron.ballman wrote:
> > > > > This should use `getName()` to get a `StringRef` to avoid the copy.
> > > > That's actually what I originally tried, but that method won't work 
> > > > here, unless I'm missing something.  The getName() method crashes with 
> > > > a message saying that "Name is not a simple identifier".
> > > You can call `getIdentifier()` instead, and if you get a non-null object 
> > > back, you can call `getName()` on that. If it is null, there's nothing to 
> > > check.
> > I just tried it, and getIdentifier() returns NULL consistently for every 
> > category method, so I changed it back to getNameAsString(), which works.
> The comment to use `getIdentifier()` was marked as done but the changes were 
> not applied; was that a mistake? I'm pushing back on `getNameAsString()` 
> because the function is commented as having its use discouraged, so we should 
> not be adding new uses of it.
I marked that as done because I tried it and it didn't work.  The 
getIdentifier() method returned NULL for every category method.

BTW, this isn't my first attempt at writing this code in a way that doesn't 
require that method.  I literally fought with getting the name of category 
methods for a day or more when I first started writing this, because I kept 
getting NULLs or crashes.  At one point, I think I even tried looking for the 
owning class and querying its interface.  Nothing worked until I discovered 
getNameAsString().

I'm assuming that this is simply a bug somewhere in the LLVM core that nobody 
has noticed or bothered to fix, because it really should not be difficult to 
get the name of a method.  :-/



Comment at: 
clang-tools-extra/clang-tidy/google/RequireCategoryMethodPrefixesCheck.cpp:30
+ClangTidyOptions::OptionMap ) {
+  Options.store(Opts, "WhitelistedPrefixes", WhitelistedPrefixes);
+}

aaron.ballman wrote:
> `ExpectedPrefixes` here as well.
> 
> Should there be a default list of these?
Done.  And no, there should be no default, unless somehow Xcode's project 
prefix makes it down as far as LLVM, in which case //maybe// that could be the 
default.

The idea is that you can whitelist your own Xcode project's prefix, along with 
the prefixes of your own in-house libraries, so that each individual 
team/workgroup can add categories on their own classes, but will get warned 
when they try to add unprefixed category methods on classes that they don't own 
(e.g. classes in system frameworks, third-party frameworks, etc.).



Comment at: 
clang-tools-extra/clang-tidy/google/RequireCategoryMethodPrefixesCheck.cpp:30
+ClangTidyOptions::OptionMap ) {
+  Options.store(Opts, "WhitelistedPrefixes", WhitelistedPrefixes);
+}

aaron.ballman wrote:
> dgatwood wrote:
> > aaron.ballman wrote:
> > > `ExpectedPrefixes` here as well.
> > > 
> > > Should there be a default list of these?
> > Done.  And no, there should be no default, unless somehow Xcode's project 
> > prefix makes it down as far as LLVM, in which case //maybe// that could be 
> > the default.
> > 
> > The idea is that you can whitelist your own Xcode project's prefix, along 
> > with the prefixes of your own in-house libraries, so that each individual 
> > team/workgroup can add categories on their own classes, but will get warned 
> > when they try to add unprefixed category methods on classes that they don't 
> > own (e.g. classes in system frameworks, third-party frameworks, etc.).
> Still wondering whether we should have a default list of 

[PATCH] D65917: [clang-tidy] Added check for the Google style guide's category method naming rule.

[David Gatwood via Phabricator via cfe-commits]

dgatwood updated this revision to Diff 218953.
dgatwood marked 7 inline comments as done.
dgatwood added a comment.

Fixed a couple of variable names in the .h file, renamed 
kCustomCategoryMethodIdentifier to CustomCategoryMethodIdentifier, and switched 
to llvm::any_of.


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

https://reviews.llvm.org/D65917

Files:
  clang-tools-extra/clang-tidy/google/CMakeLists.txt
  clang-tools-extra/clang-tidy/google/GoogleTidyModule.cpp
  clang-tools-extra/clang-tidy/google/RequireCategoryMethodPrefixesCheck.cpp
  clang-tools-extra/clang-tidy/google/RequireCategoryMethodPrefixesCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/google-objc-require-category-method-prefixes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/google-objc-require-category-method-prefixes.m

Index: clang-tools-extra/test/clang-tidy/google-objc-require-category-method-prefixes.m
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/google-objc-require-category-method-prefixes.m
@@ -0,0 +1,35 @@
+// RUN: %check_clang_tidy %s google-objc-require-category-method-prefixes %t -config="{CheckOptions: [{key: google-objc-require-category-method-prefixes.ExpectedPrefixes, value: GMO}]}"
+
+@class NSString;
+
+@interface NSURL
++ (nullable instancetype)URLWithString:(NSString *)URLString;
++ (instancetype)alloc;
+- (instancetype)init;
+@end
+
+@interface NSURL (CustomExtension)
+
+- (void)unprefixedMethod;
+- (void)unprefixed;
+- (void)justprefixed_;
+
+@end
+
+// CHECK-MESSAGES: :[[@LINE-6]]:1: warning: the category method 'unprefixedMethod' is not properly prefixed [google-objc-require-category-method-prefixes]
+// CHECK-MESSAGES: :[[@LINE-6]]:1: warning: the category method 'unprefixed' is not properly prefixed [google-objc-require-category-method-prefixes]
+// CHECK-MESSAGES: :[[@LINE-6]]:1: warning: the category method 'justprefixed_' is not properly prefixed [google-objc-require-category-method-prefixes]
+
+@interface NSURL (CustomExtension2)
+- (void)gmo_prefixedMethod;
+@end
+
+@interface GMOURL
++ (nullable instancetype)URLWithString:(NSString *)URLString;
++ (instancetype)alloc;
+- (instancetype)init;
+@end
+
+@interface GMOURL (CustomExtension3)
+- (void)unprefixedMethodInClassWithExpectedPrefix;
+@end
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -230,6 +230,7 @@
google-objc-avoid-throwing-exception
google-objc-function-naming
google-objc-global-variable-declaration
+   google-objc-require-category-method-prefixes
google-readability-avoid-underscore-in-googletest-name
google-readability-braces-around-statements (redirects to readability-braces-around-statements) 
google-readability-casting
Index: clang-tools-extra/docs/clang-tidy/checks/google-objc-require-category-method-prefixes.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/google-objc-require-category-method-prefixes.rst
@@ -0,0 +1,44 @@
+.. title:: clang-tidy - google-objc-require-category-method-prefixes
+
+google-objc-require-category-method-prefixes
+
+
+Warns when Objective-C category method names are not properly prefixed (e.g.
+``gmo_methodName``) unless the category is extending a class with an
+expected prefix (configurable).
+
+The Google Objective-C style guide requires
+`prefixes for methods http://go/objc-style#Category_Names`_ in categories on
+classes that you don't control (for example, categories on Apple or third-party
+framework classes or classes created by other teams) to prevent name collisions
+when those frameworks are updated.
+
+This checker ensures that all methods in categories have some sort of prefix
+(e.g. ``gmo_``). It excludes categories on classes whose names have a
+whitelisted three-letter prefix.
+
+For example, the following code sample is a properly prefixed method on a
+non-owned class (``NSObject``):
+
+.. code-block:: objc
+  @interface NSObject (QEDMyCategory)
+  - (BOOL)qed_myCustomMethod;
+  @end
+
+If you whitelist the ``QED`` three-letter prefix, the following code sample
+is also allowed:
+
+.. code-block:: objc
+
+  @interface QEDMyClass (MyCategory)
+  - (BOOL)myCustomMethod;
+  @end
+
+Options
+---
+
+.. option:: ExpectedPrefixes
+
+   A semicolon-delimited list of class name prefixes.  Methods in categories
+   that extend classes whose names begin with any of these prefixes are exempt
+   from the method name prefixing requirement.
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- 

[PATCH] D65256: [Sema][ObjC] Mark C union fields that have non-trivial ObjC ownership qualifications as unavailable if the union is declared in a system header

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Could you give it a slightly more general name and then use it in the main 
semantic check in ActOnFields?


Repository:
  rC Clang

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

https://reviews.llvm.org/D65256



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

Re: r369943 - FileManager: Use llvm::Expected in new getFileRef API

[Duncan P. N. Exon Smith via cfe-commits]

> On Sep 4, 2019, at 17:39, David Blaikie  wrote:
> 
> 
> 
> On Mon, Aug 26, 2019 at 11:28 AM Duncan P. N. Exon Smith via cfe-commits 
> mailto:cfe-commits@lists.llvm.org>> wrote:
> Author: dexonsmith
> Date: Mon Aug 26 11:29:51 2019
> New Revision: 369943
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=369943=rev 
> 
> Log:
> FileManager: Use llvm::Expected in new getFileRef API
> 
> `FileManager::getFileRef` is a modern API which we expect to convert to
> over time.  We should modernize the error handling as well, using
> `llvm::Expected` instead of `llvm::ErrorOr`, to help clients that care
> about errors to ensure nothing is missed.
> 
> However, not all clients care.  I've also added another path for those
> that don't:
> 
> - `FileEntryRef` is now copy- and move-assignable (using a pointer
>   instead of a reference).
> - `FileManager::getOptionalFileRef` returns an `llvm::Optional` instead
>   of `llvm::Expected`.
> - Added an `llvm::expectedToOptional` utility in case this is useful
>   elsewhere.
> 
> I'd hesitate to add new general constructs that swallow errors like this - 
> keeping them manually written might help avoid their use becoming too common.
> 
> On that note/direction - are there enough callers of getFileRef that don't 
> care about errors that it's really impractical for them to each explicitly 
> swallow the errors?

`getFileRef` is intended to eventually supplant `getFile` which has many users. 
 Most of them don't care about the error, they just want to know whether or not 
they have a file entry.  If it makes sense to change them at some point that's 
great, but I think having them use `getOptionalFileRef` makes it easy to track 
down (and potentially change) the ones that are ignoring the specific error, 
without requiring a ton of boilerplate at each call site in the meantime.  An 
un-posted version of the patch changed all the current call sites of getFileRef 
to handle/ignore the error explicitly and it looked like I was making the code 
worse.

That said, as long as we have the getOptionalFileRef API, I don't feel strongly 
about the llvm::expectedToOptional utility.  The points in favour are that it 
aligns well with llvm::errorToBool, it reduces boilerplate, and it seems both 
explicit and grep'able.  Maybe that's not compelling enough though.___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D65433: [clangd] DefineInline action availability checks

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet updated this revision to Diff 218936.
kadircet marked 4 inline comments as done.
kadircet added a comment.

- Rebase and address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65433

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

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -22,8 +22,10 @@
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Rewrite/Core/Rewriter.h"
+#include "clang/StaticAnalyzer/Core/AnalyzerOptions.h"
 #include "clang/Tooling/Core/Replacement.h"
 #include "llvm/ADT/IntrusiveRefCntPtr.h"
+#include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Support/MemoryBuffer.h"
@@ -33,6 +35,8 @@
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 #include 
+#include 
+#include 
 
 using ::testing::AllOf;
 using ::testing::HasSubstr;
@@ -554,7 +558,6 @@
   EXPECT_THAT(apply(" [[int a = 5;]] a++; "), StartsWith("fail"));
   // Don't extract return
   EXPECT_THAT(apply(" if(true) [[return;]] "), StartsWith("fail"));
-  
 }
 
 TEST_F(ExtractFunctionTest, FileTest) {
@@ -648,6 +651,108 @@
   EXPECT_THAT(apply(" for(;;) { [[while(1) break; break;]] }"),
   StartsWith("fail"));
 }
+
+TWEAK_TEST(DefineInline);
+TEST_F(DefineInlineTest, TriggersOnFunctionDecl) {
+  // Basic check for function body and signature.
+  EXPECT_AVAILABLE(R"cpp(
+  class Bar {
+void baz();
+  };
+
+  [[void [[Bar::[[b^a^z() [[{
+return;
+  }
+
+  void foo();
+  [[void [[f^o^o]]() [[{
+return;
+  }
+  )cpp");
+
+  EXPECT_UNAVAILABLE(R"cpp(
+  // Not a definition
+  vo^i[[d^ ^f]]^oo();
+
+  [[vo^id ]]foo[[()]] {[[
+[[(void)(5+3);
+return;]]
+  }]]
+  )cpp");
+}
+
+TEST_F(DefineInlineTest, NoForwardDecl) {
+  Header = "void bar();";
+  EXPECT_UNAVAILABLE(R"cpp(
+  void bar() {
+return;
+  }
+  // FIXME: Generate a decl in the header.
+  void fo^o() {
+return;
+  })cpp");
+}
+
+TEST_F(DefineInlineTest, ReferencedDecls) {
+  EXPECT_AVAILABLE(R"cpp(
+void bar();
+void foo(int test);
+
+void fo^o(int baz) {
+  int x = 10;
+  bar();
+})cpp");
+
+  // Internal symbol usage.
+  Header = "void foo(int test);";
+  EXPECT_UNAVAILABLE(R"cpp(
+#include "a.h"
+void bar();
+void fo^o(int baz) {
+  int x = 10;
+  bar();
+})cpp");
+
+  // Becomes available after making symbol visible.
+  Header = "void bar();" + Header;
+  EXPECT_AVAILABLE(R"cpp(
+#include "a.h"
+void fo^o(int baz) {
+  int x = 10;
+  bar();
+})cpp");
+
+  // FIXME: Move declaration below bar to make it visible.
+  EXPECT_UNAVAILABLE(R"cpp(
+void foo();
+void bar();
+
+void fo^o() {
+  bar();
+})cpp");
+
+  // Order doesn't matter within a class.
+  EXPECT_AVAILABLE(R"cpp(
+class Bar {
+  void foo();
+  void bar();
+};
+
+void Bar::fo^o() {
+  bar();
+})cpp");
+
+  // FIXME: Perform include insertion to make symbol visible.
+  ExtraFiles["a.h"] = "void bar();";
+  Header = "void foo(int test);";
+  EXPECT_UNAVAILABLE(R"cpp(
+#include "a.h"
+void fo^o(int baz) {
+  int x = 10;
+  bar();
+})cpp");
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/unittests/TweakTesting.h
===
--- clang-tools-extra/clangd/unittests/TweakTesting.h
+++ clang-tools-extra/clangd/unittests/TweakTesting.h
@@ -10,8 +10,10 @@
 #define LLVM_CLANG_TOOLS_EXTRA_UNITTESTS_CLANGD_TWEAKTESTING_H
 
 #include "TestTU.h"
-#include "gtest/gtest.h"
+#include "llvm/ADT/StringMap.h"
 #include "gmock/gmock.h"
+#include "gtest/gtest.h"
+#include 
 
 namespace clang {
 namespace clangd {
@@ -33,8 +35,6 @@
 //   EXPECT_UNAVAILABLE("auto ^X^ = ^foo();");
 // }
 class TweakTest : public ::testing::Test {
-  const char *TweakID;
-
 public:
   // Inputs are wrapped in file boilerplate before attempting to apply a tweak.
   // Context describes the type of boilerplate.
@@ -47,6 +47,8 @@
 Expression,
   };
 
+  llvm::StringMap ExtraFiles;
+
 protected:
   TweakTest(const char *TweakID) : TweakID(TweakID) {}
 
@@ -76,6 +78,8 @@
   // Returns a matcher that accepts marked code snippets where the tweak is
   // available at the marked range.
   ::testing::Matcher isAvailable() const;
+
+  const char *TweakID;
 };
 
 #define TWEAK_TEST(TweakID)\
Index: 

[PATCH] D58497: Clear the KnownModules cache if the preprocessor is going away

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

I don't think you need prior frontend expertise, just some time and patience 
since the modules code has some technical debt.  If you are still willing to 
look at it, I agree with Richard's suggestion that we could merge this with the 
map in the Module Manager.  One approach would be to start caching (and 
invalidating?) module load failures in the ModuleManager somehow, redirect APIs 
using KnownModules to point there, and then delete this cache entirely.  
Another approach would be to re-evaluate if we need to cache module load 
failures; hypothetically, it's possible we don't need that feature (anymore).


Repository:
  rC Clang

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

https://reviews.llvm.org/D58497



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

[PATCH] D67202: Implement Microsoft-compatible mangling for decomposition declarations.

[Eric Astor via Phabricator via cfe-commits]

epastor added a comment.

The change passes ninja check-clang - and I've added a test per your 
suggestions. Thanks!

As for llvm-undname: it works reasonably well, but these are anonymous names. 
It successfully recognizes $S1, etc. as the "name", though!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67202



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

[PATCH] D67202: Implement Microsoft-compatible mangling for decomposition declarations.

[Eric Astor via Phabricator via cfe-commits]

epastor updated this revision to Diff 218934.
epastor added a comment.

- Add testing for the new deprecation declarations mangling


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67202

Files:
  clang/include/clang/AST/Mangle.h
  clang/lib/AST/MicrosoftMangle.cpp
  clang/test/CodeGenCXX/mangle-ms-cxx17.cpp


Index: clang/test/CodeGenCXX/mangle-ms-cxx17.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/mangle-ms-cxx17.cpp
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -std=c++1z -fms-extensions -emit-llvm %s -o - 
-triple=i386-pc-win32 -fms-compatibility-version=19.10 | FileCheck 
-allow-deprecated-dag-overlap %s --check-prefix=CHECK --check-prefix=MSVC2017
+// RUN: %clang_cc1 -std=c++1z -fms-extensions -emit-llvm %s -o - 
-triple=i386-pc-win32 -fms-compatibility-version=19.00 | FileCheck 
-allow-deprecated-dag-overlap %s --check-prefix=CHECK --check-prefix=MSVC2015
+
+struct S {
+int x;
+double y;
+};
+S f();
+
+// CHECK-DAG: "?$S1@@3US@@B"
+const auto [x0, y0] = f();
+// CHECK-DAG: "?$S2@@3US@@B"
+const auto [x1, y1] = f();
+
+static union {
+int a;
+double b;
+};
+
+// CHECK-DAG: "?$S4@@3US@@B"
+const auto [x2, y2] = f();
Index: clang/lib/AST/MicrosoftMangle.cpp
===
--- clang/lib/AST/MicrosoftMangle.cpp
+++ clang/lib/AST/MicrosoftMangle.cpp
@@ -868,16 +868,11 @@
   }
 
   if (const DecompositionDecl *DD = dyn_cast(ND)) {
-// FIXME: Invented mangling for decomposition declarations:
-//   [X,Y,Z]
-// where X,Y,Z are the names of the bindings.
-llvm::SmallString<128> Name("[");
-for (auto *BD : DD->bindings()) {
-  if (Name.size() > 1)
-Name += ',';
-  Name += BD->getDeclName().getAsIdentifierInfo()->getName();
-}
-Name += ']';
+// Decomposition declarations are considered anonymous, and get
+// numbered with a $S prefix.
+llvm::SmallString<64> Name("$S");
+// Get a unique id for the anonymous struct.
+Name += llvm::utostr(Context.getAnonymousStructId(DD) + 1);
 mangleSourceName(Name);
 break;
   }
Index: clang/include/clang/AST/Mangle.h
===
--- clang/include/clang/AST/Mangle.h
+++ clang/include/clang/AST/Mangle.h
@@ -56,7 +56,7 @@
 
   llvm::DenseMap GlobalBlockIds;
   llvm::DenseMap LocalBlockIds;
-  llvm::DenseMap AnonStructIds;
+  llvm::DenseMap AnonStructIds;
 
 public:
   ManglerKind getKind() const { return Kind; }
@@ -82,9 +82,9 @@
 return Result.first->second;
   }
 
-  uint64_t getAnonymousStructId(const TagDecl *TD) {
-std::pair::iterator, bool>
-Result = AnonStructIds.insert(std::make_pair(TD, 
AnonStructIds.size()));
+  uint64_t getAnonymousStructId(const NamedDecl *D) {
+std::pair::iterator, bool>
+Result = AnonStructIds.insert(std::make_pair(D, AnonStructIds.size()));
 return Result.first->second;
   }
 


Index: clang/test/CodeGenCXX/mangle-ms-cxx17.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/mangle-ms-cxx17.cpp
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -std=c++1z -fms-extensions -emit-llvm %s -o - -triple=i386-pc-win32 -fms-compatibility-version=19.10 | FileCheck -allow-deprecated-dag-overlap %s --check-prefix=CHECK --check-prefix=MSVC2017
+// RUN: %clang_cc1 -std=c++1z -fms-extensions -emit-llvm %s -o - -triple=i386-pc-win32 -fms-compatibility-version=19.00 | FileCheck -allow-deprecated-dag-overlap %s --check-prefix=CHECK --check-prefix=MSVC2015
+
+struct S {
+int x;
+double y;
+};
+S f();
+
+// CHECK-DAG: "?$S1@@3US@@B"
+const auto [x0, y0] = f();
+// CHECK-DAG: "?$S2@@3US@@B"
+const auto [x1, y1] = f();
+
+static union {
+int a;
+double b;
+};
+
+// CHECK-DAG: "?$S4@@3US@@B"
+const auto [x2, y2] = f();
Index: clang/lib/AST/MicrosoftMangle.cpp
===
--- clang/lib/AST/MicrosoftMangle.cpp
+++ clang/lib/AST/MicrosoftMangle.cpp
@@ -868,16 +868,11 @@
   }
 
   if (const DecompositionDecl *DD = dyn_cast(ND)) {
-// FIXME: Invented mangling for decomposition declarations:
-//   [X,Y,Z]
-// where X,Y,Z are the names of the bindings.
-llvm::SmallString<128> Name("[");
-for (auto *BD : DD->bindings()) {
-  if (Name.size() > 1)
-Name += ',';
-  Name += BD->getDeclName().getAsIdentifierInfo()->getName();
-}
-Name += ']';
+// Decomposition declarations are considered anonymous, and get
+// numbered with a $S prefix.
+llvm::SmallString<64> Name("$S");
+// Get a unique id for the anonymous struct.
+Name += llvm::utostr(Context.getAnonymousStructId(DD) + 1);
 mangleSourceName(Name);
 

[PATCH] D66791: [lldb][ELF] Read symbols from .gnu_debugdata sect.

[Konrad Wilhelm Kleine via Phabricator via cfe-commits]

kwk updated this revision to Diff 218931.
kwk added a comment.

- Better names for minidebuginfo files


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66791

Files:
  lldb/CMakeLists.txt
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/include/lldb/Host/Config.h.cmake
  lldb/include/lldb/Host/LZMA.h
  lldb/lit/Breakpoint/Inputs/minidebuginfo-lib.c
  lldb/lit/Breakpoint/Inputs/minidebuginfo-lib.h
  lldb/lit/Breakpoint/Inputs/minidebuginfo-main.c
  lldb/lit/Breakpoint/Inputs/minidebuginfo.keep_symbols
  lldb/lit/Breakpoint/minidebuginfo-corrupt-xz.yaml
  lldb/lit/Breakpoint/minidebuginfo-find-symbols.yaml
  lldb/lit/Breakpoint/minidebuginfo-no-lzma.yaml
  lldb/lit/Breakpoint/minidebuginfo.test
  lldb/lit/CMakeLists.txt
  lldb/lit/lit.cfg.py
  lldb/lit/lit.site.cfg.py.in
  lldb/source/Host/CMakeLists.txt
  lldb/source/Host/common/LZMA.cpp
  lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
  lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h

Index: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h
===
--- lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h
+++ lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h
@@ -208,6 +208,10 @@
   /// Collection of symbols from the dynamic table.
   DynamicSymbolColl m_dynamic_symbols;
 
+  /// Object file parsed from .gnu_debugdata section (\sa
+  /// GetGnuDebugDataObjectFile())
+  std::shared_ptr m_gnu_debug_data_object_file;
+
   /// List of file specifications corresponding to the modules (shared
   /// libraries) on which this object file depends.
   mutable std::unique_ptr m_filespec_up;
@@ -383,6 +387,14 @@
   lldb_private::UUID );
 
   bool AnySegmentHasPhysicalAddress();
+  
+  /// Takes the .gnu_debugdata and returns the decompressed object file that is
+  /// stored within that section.
+  ///
+  /// \returns either the decompressed object file stored within the
+  /// .gnu_debugdata section or \c nullptr if an error occured or if there's no
+  /// section with that name.
+  std::shared_ptr GetGnuDebugDataObjectFile();
 };
 
 #endif // liblldb_ObjectFileELF_h_
Index: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -18,6 +18,7 @@
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Core/Section.h"
 #include "lldb/Host/FileSystem.h"
+#include "lldb/Host/LZMA.h"
 #include "lldb/Symbol/DWARFCallFrameInfo.h"
 #include "lldb/Symbol/SymbolContext.h"
 #include "lldb/Target/SectionLoadList.h"
@@ -1842,6 +1843,72 @@
   // unified section list.
   if (GetType() != eTypeDebugInfo)
 unified_section_list = *m_sections_up;
+  
+  // If there's a .gnu_debugdata section, we'll try to read the .symtab that's
+  // embedded in there and replace the one in the original object file (if any).
+  // If there's none in the orignal object file, we add it to it.
+  SectionList *module_section_list = GetModule()->GetSectionList();
+  if (auto gdd_obj_file = GetGnuDebugDataObjectFile()) {
+if (auto gdd_objfile_section_list = gdd_obj_file->GetSectionList()) {
+  if (SectionSP symtab_section_sp =
+  gdd_objfile_section_list->FindSectionByType(
+  eSectionTypeELFSymbolTable, true)) {
+SectionSP module_section_sp = module_section_list->FindSectionByType(
+eSectionTypeELFSymbolTable, true);
+if (module_section_sp)
+  module_section_list->ReplaceSection(module_section_sp->GetID(),
+  symtab_section_sp);
+else
+  module_section_list->AddSection(symtab_section_sp);
+  }
+}
+  }  
+}
+
+std::shared_ptr ObjectFileELF::GetGnuDebugDataObjectFile() {
+  if (m_gnu_debug_data_object_file != nullptr)
+return m_gnu_debug_data_object_file;
+
+  SectionSP section =
+  GetSectionList()->FindSectionByName(ConstString(".gnu_debugdata"));
+  if (!section)
+return nullptr;
+
+  if (!lldb_private::lzma::isAvailable()) {
+GetModule()->ReportWarning(
+"No LZMA support found for reading .gnu_debugdata section");
+return nullptr;
+  }
+
+  // Uncompress the data
+  DataExtractor data;
+  section->GetSectionData(data);
+  llvm::ArrayRef compressedData(data.GetDataStart(), data.GetByteSize());
+  llvm::SmallVector uncompressedData;
+  auto err = lldb_private::lzma::uncompress(compressedData, uncompressedData);
+  if (err) {
+GetModule()->ReportWarning(
+"An error occured while decompression the section %s: %s",
+section->GetName().AsCString(), llvm::toString(std::move(err)).c_str());
+return nullptr;
+  }
+
+  // Construct ObjectFileELF object from decompressed buffer
+  DataBufferSP gdd_data_buf(
+  new DataBufferHeap(uncompressedData.data(), 

[PATCH] D66791: [lldb][ELF] Read symbols from .gnu_debugdata sect.

[Konrad Wilhelm Kleine via Phabricator via cfe-commits]

kwk updated this revision to Diff 218932.
kwk added a comment.

- Better names for minidebuginfo files


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66791

Files:
  lldb/CMakeLists.txt
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/include/lldb/Host/Config.h.cmake
  lldb/include/lldb/Host/LZMA.h
  lldb/lit/Breakpoint/Inputs/minidebuginfo-lib.c
  lldb/lit/Breakpoint/Inputs/minidebuginfo-lib.h
  lldb/lit/Breakpoint/Inputs/minidebuginfo-main.c
  lldb/lit/Breakpoint/Inputs/minidebuginfo.keep_symbols
  lldb/lit/Breakpoint/minidebuginfo-corrupt-xz.yaml
  lldb/lit/Breakpoint/minidebuginfo-find-symbols.yaml
  lldb/lit/Breakpoint/minidebuginfo-no-lzma.yaml
  lldb/lit/Breakpoint/minidebuginfo-set-and-hit-breakpoint.test
  lldb/lit/CMakeLists.txt
  lldb/lit/lit.cfg.py
  lldb/lit/lit.site.cfg.py.in
  lldb/source/Host/CMakeLists.txt
  lldb/source/Host/common/LZMA.cpp
  lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
  lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h

Index: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h
===
--- lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h
+++ lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h
@@ -208,6 +208,10 @@
   /// Collection of symbols from the dynamic table.
   DynamicSymbolColl m_dynamic_symbols;
 
+  /// Object file parsed from .gnu_debugdata section (\sa
+  /// GetGnuDebugDataObjectFile())
+  std::shared_ptr m_gnu_debug_data_object_file;
+
   /// List of file specifications corresponding to the modules (shared
   /// libraries) on which this object file depends.
   mutable std::unique_ptr m_filespec_up;
@@ -383,6 +387,14 @@
   lldb_private::UUID );
 
   bool AnySegmentHasPhysicalAddress();
+  
+  /// Takes the .gnu_debugdata and returns the decompressed object file that is
+  /// stored within that section.
+  ///
+  /// \returns either the decompressed object file stored within the
+  /// .gnu_debugdata section or \c nullptr if an error occured or if there's no
+  /// section with that name.
+  std::shared_ptr GetGnuDebugDataObjectFile();
 };
 
 #endif // liblldb_ObjectFileELF_h_
Index: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -18,6 +18,7 @@
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Core/Section.h"
 #include "lldb/Host/FileSystem.h"
+#include "lldb/Host/LZMA.h"
 #include "lldb/Symbol/DWARFCallFrameInfo.h"
 #include "lldb/Symbol/SymbolContext.h"
 #include "lldb/Target/SectionLoadList.h"
@@ -1842,6 +1843,72 @@
   // unified section list.
   if (GetType() != eTypeDebugInfo)
 unified_section_list = *m_sections_up;
+  
+  // If there's a .gnu_debugdata section, we'll try to read the .symtab that's
+  // embedded in there and replace the one in the original object file (if any).
+  // If there's none in the orignal object file, we add it to it.
+  SectionList *module_section_list = GetModule()->GetSectionList();
+  if (auto gdd_obj_file = GetGnuDebugDataObjectFile()) {
+if (auto gdd_objfile_section_list = gdd_obj_file->GetSectionList()) {
+  if (SectionSP symtab_section_sp =
+  gdd_objfile_section_list->FindSectionByType(
+  eSectionTypeELFSymbolTable, true)) {
+SectionSP module_section_sp = module_section_list->FindSectionByType(
+eSectionTypeELFSymbolTable, true);
+if (module_section_sp)
+  module_section_list->ReplaceSection(module_section_sp->GetID(),
+  symtab_section_sp);
+else
+  module_section_list->AddSection(symtab_section_sp);
+  }
+}
+  }  
+}
+
+std::shared_ptr ObjectFileELF::GetGnuDebugDataObjectFile() {
+  if (m_gnu_debug_data_object_file != nullptr)
+return m_gnu_debug_data_object_file;
+
+  SectionSP section =
+  GetSectionList()->FindSectionByName(ConstString(".gnu_debugdata"));
+  if (!section)
+return nullptr;
+
+  if (!lldb_private::lzma::isAvailable()) {
+GetModule()->ReportWarning(
+"No LZMA support found for reading .gnu_debugdata section");
+return nullptr;
+  }
+
+  // Uncompress the data
+  DataExtractor data;
+  section->GetSectionData(data);
+  llvm::ArrayRef compressedData(data.GetDataStart(), data.GetByteSize());
+  llvm::SmallVector uncompressedData;
+  auto err = lldb_private::lzma::uncompress(compressedData, uncompressedData);
+  if (err) {
+GetModule()->ReportWarning(
+"An error occured while decompression the section %s: %s",
+section->GetName().AsCString(), llvm::toString(std::move(err)).c_str());
+return nullptr;
+  }
+
+  // Construct ObjectFileELF object from decompressed buffer
+  DataBufferSP gdd_data_buf(
+  new 

[PATCH] D66791: [lldb][ELF] Read symbols from .gnu_debugdata sect.

[Konrad Wilhelm Kleine via Phabricator via cfe-commits]

kwk updated this revision to Diff 218930.
kwk added a comment.
Herald added subscribers: wuzish, rnkovacs.

- Fixup
- Test for minidebuginfo image dump symtab
- Fixed test for corrupted xz blob
- Fix test
- Added test that runs when no LZMA is configured


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66791

Files:
  lldb/CMakeLists.txt
  lldb/cmake/modules/LLDBConfig.cmake
  lldb/include/lldb/Host/Config.h.cmake
  lldb/include/lldb/Host/LZMA.h
  lldb/lit/Breakpoint/Inputs/minidebuginfo-lib.c
  lldb/lit/Breakpoint/Inputs/minidebuginfo-lib.h
  lldb/lit/Breakpoint/Inputs/minidebuginfo-main.c
  lldb/lit/Breakpoint/Inputs/minidebuginfo.keep_symbols
  lldb/lit/Breakpoint/minidebuginfo-only-gnu_debugdata.corrupt.yaml
  lldb/lit/Breakpoint/minidebuginfo-only-gnu_debugdata.nolzma.yaml
  lldb/lit/Breakpoint/minidebuginfo-only-gnu_debugdata.yaml
  lldb/lit/Breakpoint/minidebuginfo.test
  lldb/lit/CMakeLists.txt
  lldb/lit/lit.cfg.py
  lldb/lit/lit.site.cfg.py.in
  lldb/source/Host/CMakeLists.txt
  lldb/source/Host/common/LZMA.cpp
  lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
  lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h

Index: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h
===
--- lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h
+++ lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.h
@@ -208,6 +208,10 @@
   /// Collection of symbols from the dynamic table.
   DynamicSymbolColl m_dynamic_symbols;
 
+  /// Object file parsed from .gnu_debugdata section (\sa
+  /// GetGnuDebugDataObjectFile())
+  std::shared_ptr m_gnu_debug_data_object_file;
+
   /// List of file specifications corresponding to the modules (shared
   /// libraries) on which this object file depends.
   mutable std::unique_ptr m_filespec_up;
@@ -383,6 +387,14 @@
   lldb_private::UUID );
 
   bool AnySegmentHasPhysicalAddress();
+  
+  /// Takes the .gnu_debugdata and returns the decompressed object file that is
+  /// stored within that section.
+  ///
+  /// \returns either the decompressed object file stored within the
+  /// .gnu_debugdata section or \c nullptr if an error occured or if there's no
+  /// section with that name.
+  std::shared_ptr GetGnuDebugDataObjectFile();
 };
 
 #endif // liblldb_ObjectFileELF_h_
Index: lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -18,6 +18,7 @@
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Core/Section.h"
 #include "lldb/Host/FileSystem.h"
+#include "lldb/Host/LZMA.h"
 #include "lldb/Symbol/DWARFCallFrameInfo.h"
 #include "lldb/Symbol/SymbolContext.h"
 #include "lldb/Target/SectionLoadList.h"
@@ -1842,6 +1843,72 @@
   // unified section list.
   if (GetType() != eTypeDebugInfo)
 unified_section_list = *m_sections_up;
+  
+  // If there's a .gnu_debugdata section, we'll try to read the .symtab that's
+  // embedded in there and replace the one in the original object file (if any).
+  // If there's none in the orignal object file, we add it to it.
+  SectionList *module_section_list = GetModule()->GetSectionList();
+  if (auto gdd_obj_file = GetGnuDebugDataObjectFile()) {
+if (auto gdd_objfile_section_list = gdd_obj_file->GetSectionList()) {
+  if (SectionSP symtab_section_sp =
+  gdd_objfile_section_list->FindSectionByType(
+  eSectionTypeELFSymbolTable, true)) {
+SectionSP module_section_sp = module_section_list->FindSectionByType(
+eSectionTypeELFSymbolTable, true);
+if (module_section_sp)
+  module_section_list->ReplaceSection(module_section_sp->GetID(),
+  symtab_section_sp);
+else
+  module_section_list->AddSection(symtab_section_sp);
+  }
+}
+  }  
+}
+
+std::shared_ptr ObjectFileELF::GetGnuDebugDataObjectFile() {
+  if (m_gnu_debug_data_object_file != nullptr)
+return m_gnu_debug_data_object_file;
+
+  SectionSP section =
+  GetSectionList()->FindSectionByName(ConstString(".gnu_debugdata"));
+  if (!section)
+return nullptr;
+
+  if (!lldb_private::lzma::isAvailable()) {
+GetModule()->ReportWarning(
+"No LZMA support found for reading .gnu_debugdata section");
+return nullptr;
+  }
+
+  // Uncompress the data
+  DataExtractor data;
+  section->GetSectionData(data);
+  llvm::ArrayRef compressedData(data.GetDataStart(), data.GetByteSize());
+  llvm::SmallVector uncompressedData;
+  auto err = lldb_private::lzma::uncompress(compressedData, uncompressedData);
+  if (err) {
+GetModule()->ReportWarning(
+"An error occured while decompression the section %s: %s",
+section->GetName().AsCString(), 

[PATCH] D66791: [lldb][ELF] Read symbols from .gnu_debugdata sect.

[Konrad Wilhelm Kleine via Phabricator via cfe-commits]

kwk updated this revision to Diff 218929.
kwk added a comment.
Herald added subscribers: openmp-commits, libcxx-commits, Sanitizers, 
cfe-commits, seiya, erik.pilkington, asbirlea, ormris, Petar.Avramovic, jsji, 
mstorsjo, jfb, kadircet, arphaman, jkorous, george.burgess.iv, christof, 
jakehehrlich, javed.absar, kbarton, aheejin, sbc100, nhaehnle, jvesely, 
nemanjai, arsenm.
Herald added a reviewer: martong.
Herald added a reviewer: shafik.
Herald added a reviewer: rupprecht.
Herald added a reviewer: jdoerfert.
Herald added a reviewer: jhenderson.
Herald added a reviewer: jdoerfert.
Herald added projects: clang, Sanitizers, libc++, OpenMP.

- Fixup
- Test for minidebuginfo image dump symtab
- Fixed test for corrupted xz blob
- Fix test
- Added test that runs when no LZMA is configured


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66791

Files:
  .git-blame-ignore-revs
  clang-tools-extra/clang-tidy/bugprone/ArgumentCommentCheck.cpp
  clang-tools-extra/clang-tidy/misc/DefinitionsInHeadersCheck.cpp
  clang-tools-extra/clangd/CMakeLists.txt
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdUnit.cpp
  clang-tools-extra/clangd/ClangdUnit.h
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/FindSymbols.cpp
  clang-tools-extra/clangd/ParsedAST.cpp
  clang-tools-extra/clangd/ParsedAST.h
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/Selection.cpp
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/SourceCode.cpp
  clang-tools-extra/clangd/SourceCode.h
  clang-tools-extra/clangd/TUScheduler.cpp
  clang-tools-extra/clangd/TUScheduler.h
  clang-tools-extra/clangd/Threading.h
  clang-tools-extra/clangd/Trace.cpp
  clang-tools-extra/clangd/Trace.h
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/XRefs.h
  clang-tools-extra/clangd/index/Background.cpp
  clang-tools-extra/clangd/index/BackgroundRebuild.cpp
  clang-tools-extra/clangd/index/FileIndex.cpp
  clang-tools-extra/clangd/refactor/Rename.cpp
  clang-tools-extra/clangd/refactor/Tweak.h
  clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
  clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp
  clang-tools-extra/clangd/refactor/tweaks/RawStringLiteral.cpp
  clang-tools-extra/clangd/refactor/tweaks/SwapIfBranches.cpp
  clang-tools-extra/clangd/unittests/CMakeLists.txt
  clang-tools-extra/clangd/unittests/ClangdUnitTests.cpp
  clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
  clang-tools-extra/clangd/unittests/ExpectedTypeTest.cpp
  clang-tools-extra/clangd/unittests/FileIndexTests.cpp
  clang-tools-extra/clangd/unittests/ParsedASTTests.cpp
  clang-tools-extra/clangd/unittests/SelectionTests.cpp
  clang-tools-extra/clangd/unittests/SourceCodeTests.cpp
  clang-tools-extra/clangd/unittests/SymbolInfoTests.cpp
  clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp
  clang-tools-extra/clangd/unittests/TestTU.h
  clang-tools-extra/clangd/unittests/TypeHierarchyTests.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp
  clang-tools-extra/modularize/Modularize.cpp
  clang-tools-extra/test/clang-tidy/bugprone-argument-comment-literals.cpp
  clang-tools-extra/test/clang-tidy/misc-definitions-in-headers.hpp
  clang/docs/ConstantInterpreter.rst
  clang/docs/OpenMPSupport.rst
  clang/docs/index.rst
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Decl.h
  clang/include/clang/AST/Mangle.h
  clang/include/clang/AST/OptionalDiagnostic.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/BuiltinsAMDGPU.def
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/include/clang/Basic/DiagnosticASTKinds.td
  clang/include/clang/Basic/DiagnosticCommonKinds.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/Options.h
  clang/include/clang/Driver/Options.td
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/CMakeLists.txt
  clang/lib/AST/Decl.cpp
  clang/lib/AST/DeclBase.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/Interp/Block.cpp
  clang/lib/AST/Interp/Block.h
  clang/lib/AST/Interp/Boolean.h
  clang/lib/AST/Interp/ByteCodeEmitter.cpp
  clang/lib/AST/Interp/ByteCodeEmitter.h
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/lib/AST/Interp/ByteCodeExprGen.h
  clang/lib/AST/Interp/ByteCodeGenError.cpp
  clang/lib/AST/Interp/ByteCodeGenError.h
  clang/lib/AST/Interp/ByteCodeStmtGen.cpp
  clang/lib/AST/Interp/ByteCodeStmtGen.h
  clang/lib/AST/Interp/CMakeLists.txt
  clang/lib/AST/Interp/Context.cpp
  clang/lib/AST/Interp/Context.h
  clang/lib/AST/Interp/Descriptor.cpp
  

[clang-tools-extra] r371081 - [clangd] Initialize int field to zero. NFC

[Ilya Biryukov via cfe-commits]

Author: ibiryukov
Date: Thu Sep  5 08:30:05 2019
New Revision: 371081

URL: http://llvm.org/viewvc/llvm-project?rev=371081=rev
Log:
[clangd] Initialize int field to zero. NFC

To make sure we do not have uninitialized values and undefined behavior.

Modified:
clang-tools-extra/trunk/clangd/Protocol.h

Modified: clang-tools-extra/trunk/clangd/Protocol.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Protocol.h?rev=371081=371080=371081=diff
==
--- clang-tools-extra/trunk/clangd/Protocol.h (original)
+++ clang-tools-extra/trunk/clangd/Protocol.h Thu Sep  5 08:30:05 2019
@@ -1205,7 +1205,7 @@ llvm::json::Value toJSON(const FileStatu
 /// specific line of the text document.
 struct SemanticHighlightingInformation {
   /// The line these highlightings belong to.
-  int Line;
+  int Line = 0;
   /// The base64 encoded string of highlighting tokens.
   std::string Tokens;
 };


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

[PATCH] D66328: [DebugInfo] Add debug location to stubs generated by CGDeclCXX and mark them as artificial

[Alexandre Ganea via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL371080: [DebugInfo] Add debug location to stubs generated by 
CGDeclCXX and mark them as… (authored by aganea, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D66328?vs=218515=218928#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D66328

Files:
  cfe/trunk/include/clang/AST/GlobalDecl.h
  cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
  cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
  cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp
  cfe/trunk/test/CodeGenCXX/debug-info-destroy-helper.cpp
  cfe/trunk/test/CodeGenCXX/debug-info-global-ctor-dtor.cpp
  cfe/trunk/test/CodeGenCXX/debug-info-line.cpp

Index: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
===
--- cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
+++ cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
@@ -247,6 +247,8 @@
 
   CGF.StartFunction(GlobalDecl(, DynamicInitKind::AtExit),
 CGM.getContext().VoidTy, fn, FI, FunctionArgList());
+  // Emit an artificial location for this function.
+  auto AL = ApplyDebugLocation::CreateArtificial(CGF);
 
   llvm::CallInst *call = CGF.Builder.CreateCall(dtor, addr);
 
@@ -642,8 +644,9 @@
 
   StartFunction(GlobalDecl(D, DynamicInitKind::Initializer),
 getContext().VoidTy, Fn, getTypes().arrangeNullaryFunction(),
-FunctionArgList(), D->getLocation(),
-D->getInit()->getExprLoc());
+FunctionArgList());
+  // Emit an artificial location for this function.
+  auto AL = ApplyDebugLocation::CreateArtificial(*this);
 
   // Use guarded initialization if the global variable is weak. This
   // occurs for, e.g., instantiated static data members and
@@ -768,7 +771,10 @@
 
   CurEHLocation = VD->getBeginLoc();
 
-  StartFunction(VD, getContext().VoidTy, fn, FI, args);
+  StartFunction(GlobalDecl(VD, DynamicInitKind::GlobalArrayDestructor),
+getContext().VoidTy, fn, FI, args);
+  // Emit an artificial location for this function.
+  auto AL = ApplyDebugLocation::CreateArtificial(*this);
 
   emitDestroy(addr, type, destroyer, useEHCleanupForArray);
 
Index: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
===
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
@@ -1910,7 +1910,8 @@
  llvm::Function *InitFn) {
   // If we're not emitting codeview, use the mangled name. For Itanium, this is
   // arbitrary.
-  if (!CGM.getCodeGenOpts().EmitCodeView)
+  if (!CGM.getCodeGenOpts().EmitCodeView ||
+  StubKind == DynamicInitKind::GlobalArrayDestructor)
 return InitFn->getName();
 
   // Print the normal qualified name for the variable, then break off the last
@@ -1935,6 +1936,7 @@
 
   switch (StubKind) {
   case DynamicInitKind::NoStub:
+  case DynamicInitKind::GlobalArrayDestructor:
 llvm_unreachable("not an initializer");
   case DynamicInitKind::Initializer:
 OS << "`dynamic initializer for '";
@@ -3569,7 +3571,8 @@
   if (Name.startswith("\01"))
 Name = Name.substr(1);
 
-  if (!HasDecl || D->isImplicit() || D->hasAttr()) {
+  if (!HasDecl || D->isImplicit() || D->hasAttr() ||
+  (isa(D) && GD.getDynamicInitKind() != DynamicInitKind::NoStub)) {
 Flags |= llvm::DINode::FlagArtificial;
 // Artificial functions should not silently reuse CurLoc.
 CurLoc = SourceLocation();
Index: cfe/trunk/include/clang/AST/GlobalDecl.h
===
--- cfe/trunk/include/clang/AST/GlobalDecl.h
+++ cfe/trunk/include/clang/AST/GlobalDecl.h
@@ -31,6 +31,7 @@
   NoStub = 0,
   Initializer,
   AtExit,
+  GlobalArrayDestructor
 };
 
 /// GlobalDecl - represents a global declaration. This can either be a
Index: cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp
===
--- cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp
+++ cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 -emit-llvm %s -triple x86_64-windows-msvc -gcodeview -debug-info-kind=limited -o - | FileCheck %s
+
+struct a {
+  ~a();
+};
+template  struct c : a {
+  c(void (b::*)());
+};
+struct B {
+  virtual void e();
+};
+c *d() { static c f(::e); return  }
+
+// CHECK: define internal void @"??__Ff@?1??d@@YAPEAU?$c@UBXZ@YAXXZ"()
+// CHECK-SAME: !dbg ![[SUBPROGRAM:[0-9]+]] {
+// CHECK: call void @"??1?$c@UBQEAA@XZ"(%struct.c* @"?f@?1??d@@YAPEAU?$c@UBXZ@4U2@A"), !dbg ![[LOCATION:[0-9]+]]
+// CHECK-NEXT: ret void, !dbg ![[LOCATION]]
+// CHECK: ![[SUBPROGRAM]] = distinct !DISubprogram(name: "`dynamic atexit destructor for 'f'"
+// CHECK-SAME: flags: DIFlagArtificial
+// CHECK: ![[LOCATION]] = !DILocation(line: 0, scope: ![[SUBPROGRAM]])
\ No newline at end of file

r371080 - [DebugInfo] Add debug location to stubs generated by CGDeclCXX and mark them as artificial

[Alexandre Ganea via cfe-commits]

Author: aganea
Date: Thu Sep  5 08:24:49 2019
New Revision: 371080

URL: http://llvm.org/viewvc/llvm-project?rev=371080=rev
Log:
[DebugInfo] Add debug location to stubs generated by CGDeclCXX and mark them as 
artificial

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

Added:
cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp
cfe/trunk/test/CodeGenCXX/debug-info-destroy-helper.cpp
Modified:
cfe/trunk/include/clang/AST/GlobalDecl.h
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
cfe/trunk/test/CodeGenCXX/debug-info-global-ctor-dtor.cpp
cfe/trunk/test/CodeGenCXX/debug-info-line.cpp

Modified: cfe/trunk/include/clang/AST/GlobalDecl.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/GlobalDecl.h?rev=371080=371079=371080=diff
==
--- cfe/trunk/include/clang/AST/GlobalDecl.h (original)
+++ cfe/trunk/include/clang/AST/GlobalDecl.h Thu Sep  5 08:24:49 2019
@@ -31,6 +31,7 @@ enum class DynamicInitKind : unsigned {
   NoStub = 0,
   Initializer,
   AtExit,
+  GlobalArrayDestructor
 };
 
 /// GlobalDecl - represents a global declaration. This can either be a

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=371080=371079=371080=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Thu Sep  5 08:24:49 2019
@@ -1910,7 +1910,8 @@ StringRef CGDebugInfo::getDynamicInitial
  llvm::Function *InitFn) {
   // If we're not emitting codeview, use the mangled name. For Itanium, this is
   // arbitrary.
-  if (!CGM.getCodeGenOpts().EmitCodeView)
+  if (!CGM.getCodeGenOpts().EmitCodeView ||
+  StubKind == DynamicInitKind::GlobalArrayDestructor)
 return InitFn->getName();
 
   // Print the normal qualified name for the variable, then break off the last
@@ -1935,6 +1936,7 @@ StringRef CGDebugInfo::getDynamicInitial
 
   switch (StubKind) {
   case DynamicInitKind::NoStub:
+  case DynamicInitKind::GlobalArrayDestructor:
 llvm_unreachable("not an initializer");
   case DynamicInitKind::Initializer:
 OS << "`dynamic initializer for '";
@@ -3569,7 +3571,8 @@ void CGDebugInfo::EmitFunctionStart(Glob
   if (Name.startswith("\01"))
 Name = Name.substr(1);
 
-  if (!HasDecl || D->isImplicit() || D->hasAttr()) {
+  if (!HasDecl || D->isImplicit() || D->hasAttr() ||
+  (isa(D) && GD.getDynamicInitKind() != DynamicInitKind::NoStub)) 
{
 Flags |= llvm::DINode::FlagArtificial;
 // Artificial functions should not silently reuse CurLoc.
 CurLoc = SourceLocation();

Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDeclCXX.cpp?rev=371080=371079=371080=diff
==
--- cfe/trunk/lib/CodeGen/CGDeclCXX.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDeclCXX.cpp Thu Sep  5 08:24:49 2019
@@ -247,6 +247,8 @@ llvm::Function *CodeGenFunction::createA
 
   CGF.StartFunction(GlobalDecl(, DynamicInitKind::AtExit),
 CGM.getContext().VoidTy, fn, FI, FunctionArgList());
+  // Emit an artificial location for this function.
+  auto AL = ApplyDebugLocation::CreateArtificial(CGF);
 
   llvm::CallInst *call = CGF.Builder.CreateCall(dtor, addr);
 
@@ -642,8 +644,9 @@ void CodeGenFunction::GenerateCXXGlobalV
 
   StartFunction(GlobalDecl(D, DynamicInitKind::Initializer),
 getContext().VoidTy, Fn, getTypes().arrangeNullaryFunction(),
-FunctionArgList(), D->getLocation(),
-D->getInit()->getExprLoc());
+FunctionArgList());
+  // Emit an artificial location for this function.
+  auto AL = ApplyDebugLocation::CreateArtificial(*this);
 
   // Use guarded initialization if the global variable is weak. This
   // occurs for, e.g., instantiated static data members and
@@ -768,7 +771,10 @@ llvm::Function *CodeGenFunction::generat
 
   CurEHLocation = VD->getBeginLoc();
 
-  StartFunction(VD, getContext().VoidTy, fn, FI, args);
+  StartFunction(GlobalDecl(VD, DynamicInitKind::GlobalArrayDestructor),
+getContext().VoidTy, fn, FI, args);
+  // Emit an artificial location for this function.
+  auto AL = ApplyDebugLocation::CreateArtificial(*this);
 
   emitDestroy(addr, type, destroyer, useEHCleanupForArray);
 

Added: cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp?rev=371080=auto
==
--- cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/debug-info-atexit-stub.cpp Thu Sep  5 08:24:49 
2019
@@ -0,0 

[PATCH] D65863: [ARM] Add support for the s,j,x,N,O inline asm constraints

[David Candler via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL371079: [ARM] Add support for the s,j,x,N,O inline asm 
constraints (authored by dcandler, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D65863?vs=214205=218927#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65863

Files:
  cfe/trunk/lib/Basic/Targets/ARM.cpp
  cfe/trunk/test/Sema/arm_inline_asm_constraints.c
  llvm/trunk/lib/Target/ARM/ARMISelLowering.cpp

Index: llvm/trunk/lib/Target/ARM/ARMISelLowering.cpp
===
--- llvm/trunk/lib/Target/ARM/ARMISelLowering.cpp
+++ llvm/trunk/lib/Target/ARM/ARMISelLowering.cpp
@@ -15323,7 +15323,7 @@
   case 'j':
 // Constant suitable for movw, must be between 0 and
 // 65535.
-if (Subtarget->hasV6T2Ops())
+if (Subtarget->hasV6T2Ops() || (Subtarget->hasV8MBaselineOps()))
   if (CVal >= 0 && CVal <= 65535)
 break;
 return;
@@ -15431,7 +15431,7 @@
 return;
 
   case 'N':
-if (Subtarget->isThumb()) {  // FIXME thumb2
+if (Subtarget->isThumb1Only()) {
   // This must be a constant between 0 and 31, for shift amounts.
   if (CVal >= 0 && CVal <= 31)
 break;
@@ -15439,7 +15439,7 @@
 return;
 
   case 'O':
-if (Subtarget->isThumb()) {  // FIXME thumb2
+if (Subtarget->isThumb1Only()) {
   // This must be a multiple of 4 between -508 and 508, for
   // ADD/SUB sp = sp + immediate.
   if ((CVal >= -508 && CVal <= 508) && ((CVal & 3) == 0))
Index: cfe/trunk/test/Sema/arm_inline_asm_constraints.c
===
--- cfe/trunk/test/Sema/arm_inline_asm_constraints.c
+++ cfe/trunk/test/Sema/arm_inline_asm_constraints.c
@@ -0,0 +1,305 @@
+// REQUIRES: arm-registered-target
+
+// RUN: %clang_cc1 -triple armv6 -verify=arm6 %s
+// RUN: %clang_cc1 -triple armv7 -verify=arm7 %s
+// RUN: %clang_cc1 -triple thumbv6 -verify=thumb1 %s
+// RUN: %clang_cc1 -triple thumbv7 -verify=thumb2 %s
+
+// j: An immediate integer between 0 and 65535 (valid for MOVW) (ARM/Thumb2)
+int test_j(int i) {
+  int res;
+  __asm("movw %0, %1;"
+: [ result ] "=r"(res)
+: [ constant ] "j"(-1), [ input ] "r"(i)
+:);
+  // arm6-error@13 {{invalid input constraint 'j' in asm}}
+  // arm7-error@13 {{value '-1' out of range for constraint 'j'}}
+  // thumb1-error@13 {{invalid input constraint 'j' in asm}}
+  // thumb2-error@13 {{value '-1' out of range for constraint 'j'}}
+  __asm("movw %0, %1;"
+: [ result ] "=r"(res)
+: [ constant ] "j"(0), [ input ] "r"(i)
+:);
+  // arm6-error@21 {{invalid input constraint 'j' in asm}}
+  // arm7-no-error
+  // thumb1-error@21 {{invalid input constraint 'j' in asm}}
+  // thumb2-no-error
+  __asm("movw %0, %1;"
+: [ result ] "=r"(res)
+: [ constant ] "j"(65535), [ input ] "r"(i)
+:);
+  // arm6-error@29 {{invalid input constraint 'j' in asm}}
+  // arm7-no-error
+  // thumb1-error@29 {{invalid input constraint 'j' in asm}}
+  // thumb2-no-error
+  __asm("movw %0, %1;"
+: [ result ] "=r"(res)
+: [ constant ] "j"(65536), [ input ] "r"(i)
+:);
+  // arm6-error@37 {{invalid input constraint 'j' in asm}}
+  // arm7-error@37 {{value '65536' out of range for constraint 'j'}}
+  // thumb1-error@37 {{invalid input constraint 'j' in asm}}
+  // thumb2-error@37 {{value '65536' out of range for constraint 'j'}}
+  return res;
+}
+
+// I: An immediate integer valid for a data-processing instruction. (ARM/Thumb2)
+//An immediate integer between 0 and 255. (Thumb1)
+int test_I(int i) {
+  int res;
+  __asm(
+  "add %0, %1;"
+  : [ result ] "=r"(res)
+  : [ constant ] "I"(-1), [ input ] "r"(i)
+  :); // thumb1-error@53 {{value '-1' out of range for constraint 'I'}}
+  __asm(
+  "add %0, %1;"
+  : [ result ] "=r"(res)
+  : [ constant ] "I"(0), [ input ] "r"(i)
+  :); // No errors expected.
+  __asm(
+  "add %0, %1;"
+  : [ result ] "=r"(res)
+  : [ constant ] "I"(255), [ input ] "r"(i)
+  :); // No errors expected.
+  __asm(
+  "add %0, %1;"
+  : [ result ] "=r"(res)
+  : [ constant ] "I"(256), [ input ] "r"(i)
+  :); // thumb1-error@68 {{value '256' out of range for constraint 'I'}}
+  return res;
+}
+
+// J: An immediate integer between -4095 and 4095. (ARM/Thumb2)
+//An immediate integer between -255 and -1. (Thumb1)
+int test_J(int i) {
+  int res;
+  __asm(
+  "movw %0, %1;"
+  : [ result ] "=r"(res)
+  : [ constant ] "J"(-4096), [ input ] "r"(i)
+  :);
+  // arm6-error@80 {{value '-4096' out of range for constraint 'J'}}
+  // arm7-error@80 {{value '-4096' out of range for constraint 'J'}}
+  // thumb1-error@80 {{value '-4096' out of range for 

r371079 - [ARM] Add support for the s,j,x,N,O inline asm constraints

[David Candler via cfe-commits]

Author: dcandler
Date: Thu Sep  5 08:17:25 2019
New Revision: 371079

URL: http://llvm.org/viewvc/llvm-project?rev=371079=rev
Log:
[ARM] Add support for the s,j,x,N,O inline asm constraints

A number of inline assembly constraints are currently supported by LLVM, but 
rejected as invalid by Clang:

Target independent constraints:

s: An integer constant, but allowing only relocatable values

ARM specific constraints:

j: An immediate integer between 0 and 65535 (valid for MOVW)
x: A 32, 64, or 128-bit floating-point/SIMD register: s0-s15, d0-d7, or q0-q3
N: An immediate integer between 0 and 31 (Thumb1 only)
O: An immediate integer which is a multiple of 4 between -508 and 508. (Thumb1 
only)

This patch adds support to Clang for the missing constraints along with some 
checks to ensure that the constraints are used with the correct target and 
Thumb mode, and that immediates are within valid ranges (at least where 
possible). The constraints are already implemented in LLVM, but just a couple 
of minor corrections to checks (V8M Baseline includes MOVW so should work with 
'j', 'N' and 'O' shouldn't be valid in Thumb2) so that Clang and LLVM are in 
line with each other and the documentation.

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

Change-Id: I18076619e319bac35fbb60f590c069145c9d9a0a

Added:
cfe/trunk/test/Sema/arm_inline_asm_constraints.c
Modified:
cfe/trunk/lib/Basic/Targets/ARM.cpp

Modified: cfe/trunk/lib/Basic/Targets/ARM.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/ARM.cpp?rev=371079=371078=371079=diff
==
--- cfe/trunk/lib/Basic/Targets/ARM.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/ARM.cpp Thu Sep  5 08:17:25 2019
@@ -885,19 +885,102 @@ bool ARMTargetInfo::validateAsmConstrain
   switch (*Name) {
   default:
 break;
-  case 'l': // r0-r7
-  case 'h': // r8-r15
-  case 't': // VFP Floating point register single precision
-  case 'w': // VFP Floating point register double precision
+  case 'l': // r0-r7 if thumb, r0-r15 if ARM
 Info.setAllowsRegister();
 return true;
+  case 'h': // r8-r15, thumb only
+if (isThumb()) {
+  Info.setAllowsRegister();
+  return true;
+}
+break;
+  case 's': // An integer constant, but allowing only relocatable values.
+return true;
+  case 't': // s0-s31, d0-d31, or q0-q15
+  case 'w': // s0-s15, d0-d7, or q0-q3
+  case 'x': // s0-s31, d0-d15, or q0-q7
+Info.setAllowsRegister();
+return true;
+  case 'j': // An immediate integer between 0 and 65535 (valid for MOVW)
+// only available in ARMv6T2 and above
+if (CPUAttr.equals("6T2") || ArchVersion >= 7) {
+  Info.setRequiresImmediate(0, 65535);
+  return true;
+}
+break;
   case 'I':
+if (isThumb()) {
+  if (!supportsThumb2())
+Info.setRequiresImmediate(0, 255);
+  else
+// FIXME: should check if immediate value would be valid for a Thumb2
+// data-processing instruction
+Info.setRequiresImmediate();
+} else
+  // FIXME: should check if immediate value would be valid for an ARM
+  // data-processing instruction
+  Info.setRequiresImmediate();
+return true;
   case 'J':
+if (isThumb() && !supportsThumb2())
+  Info.setRequiresImmediate(-255, -1);
+else
+  Info.setRequiresImmediate(-4095, 4095);
+return true;
   case 'K':
+if (isThumb()) {
+  if (!supportsThumb2())
+// FIXME: should check if immediate value can be obtained from shifting
+// a value between 0 and 255 left by any amount
+Info.setRequiresImmediate();
+  else
+// FIXME: should check if immediate value would be valid for a Thumb2
+// data-processing instruction when inverted
+Info.setRequiresImmediate();
+} else
+  // FIXME: should check if immediate value would be valid for an ARM
+  // data-processing instruction when inverted
+  Info.setRequiresImmediate();
+return true;
   case 'L':
+if (isThumb()) {
+  if (!supportsThumb2())
+Info.setRequiresImmediate(-7, 7);
+  else
+// FIXME: should check if immediate value would be valid for a Thumb2
+// data-processing instruction when negated
+Info.setRequiresImmediate();
+} else
+  // FIXME: should check if immediate value  would be valid for an ARM
+  // data-processing instruction when negated
+  Info.setRequiresImmediate();
+return true;
   case 'M':
-// FIXME
+if (isThumb() && !supportsThumb2())
+  // FIXME: should check if immediate value is a multiple of 4 between 0 
and
+  // 1020
+  Info.setRequiresImmediate();
+else
+  // FIXME: should check if immediate value is a power of two or a integer
+  // between 0 and 32
+  Info.setRequiresImmediate();
 return true;
+  case 'N':
+// Thumb1 only
+if (isThumb() && !supportsThumb2()) {
+  

[PATCH] D66716: [analyzer] PR43102: Fix an assertion and an out-of-bounds error for diagnostic location construction

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

Szelethus added a comment.

I'm still working on this, just been kinda busy. I'll try to get it out of the 
way asap.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66716



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

[PATCH] D67224: [clangd] Enable completions with fixes in VSCode

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov planned changes to this revision.
ilya-biryukov added a comment.

Changing behavior of clangd might affect other clients.
It would be nice to find alternative ways to fix this.

Nevertheless, posting this here as an example of a potential workaround for the 
problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67224



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

[PATCH] D67140: [analyzer][NFC] Fix inconsistent references to checkers as "checks"

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

Szelethus added a comment.



In D67140#1658365 , @aaron.ballman 
wrote:

> Then again, with the recent resurfacing of discussions about renaming 
> everything under the sun, maybe we've changed our community opinion here. :-D 
> I guess I don't see Check vs Checker to be worthy of breaking everyone's 
> out-of-tree code over.


This pretty much summarizes my feelings on this: Changing this in ClangTidy 
would be better, but probably wouldn't be worth it.

In D67140#1658365 , @aaron.ballman 
wrote:

> In D67140#1658353 , @gribozavr wrote:
>
> > In D67140#1658315 , @aaron.ballman 
> > wrote:
> >
> > > In D67140#1656831 , @NoQ wrote:
> > >
> > > > Honestly, i'm much more worried about message capitalization :)
> > >
> > >
> > > Likewise. I wish the static analyzer would follow the usual conventions 
> > > followed by clang and clang-tidy. ;-)
> >
> >
> > I have the opposite opinion -- I wish that ClangTidy used complete 
> > sentences, and multiple sentences if it makes sense. The sentence fragments 
> > are too brief to explain complex and nuanced topics that ClangTidy 
> > communicates about. ClangTidy often plays the role of a developer education 
> > tool. It is not a guard like a compiler; developers can totally ignore 
> > ClangTidy if they disagree with the message. The better we can explain the 
> > problem, the more likely it is the developer will act on the message. I 
> > believe static analysis tools would be better off if we could write 
> > multiple sentences in the diagnostic.
> >
> > Even for compiler messages, a sentence fragment is sometimes too concise.
>
>
> I agree with you in principle, but practicality still matters. I don't 
> imagine we're going to go back and change the thousands of diagnostics in 
> Clang to be complete sentences, and I prefer my diagnostics to be consistent. 
> It's jarring when one part of the compiler uses one style of diagnostics and 
> another part of the compiler uses a different style. So while I'd love it if 
> we had more descriptive diagnostics, I would be happy to settle for 
> consistent styles of diagnostics.


I personally disagree with this point. I also think that ClangTidy and the 
Static Analyzer play a drastically different role compared to regular compiler 
diagnostics, and we should regard them as such. That said, I don't integrate 
the Static Analyzer into my editor, and use a different tool to view its 
results.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67140



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

[PATCH] D66872: [clangd] SelectionTree should mark a node as fully-selected if the only claimed tokens were early-claimed.

[Sam McCall via Phabricator via cfe-commits]

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

remove special-case handling of VarDecl in ExtractFunction that is no longer 
needed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66872

Files:
  clang-tools-extra/clangd/Selection.cpp
  clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
  clang-tools-extra/clangd/unittests/SelectionTests.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -508,13 +508,12 @@
   EXPECT_EQ(apply("int x = 0; [[x++;]]"), "unavailable");
   // We don't support extraction from lambdas.
   EXPECT_EQ(apply("auto lam = [](){ [[int x;]] }; "), "unavailable");
+  // Partial statements aren't extracted.
+  EXPECT_THAT(apply("int [[x = 0]];"), "unavailable");
 
   // Ensure that end of Zone and Beginning of PostZone being adjacent doesn't
   // lead to break being included in the extraction zone.
   EXPECT_THAT(apply("for(;;) { [[int x;]]break; }"), HasSubstr("extracted"));
-  // FIXME: This should be unavailable since partially selected but
-  // selectionTree doesn't always work correctly for VarDecls.
-  EXPECT_THAT(apply("int [[x = 0]];"), HasSubstr("extracted"));
   // FIXME: ExtractFunction should be unavailable inside loop construct
   // initalizer/condition.
   EXPECT_THAT(apply(" for([[int i = 0;]];);"), HasSubstr("extracted"));
@@ -522,7 +521,6 @@
   EXPECT_THAT(apply(" [[int a = 5;]] a++; "), StartsWith("fail"));
   // Don't extract return
   EXPECT_THAT(apply(" if(true) [[return;]] "), StartsWith("fail"));
-  
 }
 
 TEST_F(ExtractFunctionTest, FileTest) {
Index: clang-tools-extra/clangd/unittests/SelectionTests.cpp
===
--- clang-tools-extra/clangd/unittests/SelectionTests.cpp
+++ clang-tools-extra/clangd/unittests/SelectionTests.cpp
@@ -354,6 +354,8 @@
 #define ECHO(X) X
 ECHO(EC^HO([[$C[[int]]) EC^HO(a]]));
   ]])cpp",
+  R"cpp( $C[[^$C[[int]] a^]]; )cpp",
+  R"cpp( $C[[^$C[[int]] a = $C[[5]]^]]; )cpp",
   };
   for (const char *C : Cases) {
 Annotations Test(C);
Index: clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
@@ -113,15 +113,12 @@
 return nullptr;
   switch (CommonAnc->Selected) {
   case SelectionTree::Selection::Unselected:
+// Typicaly a block, with the { and } unselected, could also be ForStmt etc
 // Ensure all Children are RootStmts.
 return llvm::all_of(CommonAnc->Children, isRootStmt) ? CommonAnc : nullptr;
   case SelectionTree::Selection::Partial:
-// Treat Partially selected VarDecl as completely selected since
-// SelectionTree doesn't always select VarDecls correctly.
-// FIXME: Remove this after D66872 is upstream)
-if (!CommonAnc->ASTNode.get())
-  return nullptr;
-LLVM_FALLTHROUGH;
+// Only a fully-selected single statement can be selected.
+return nullptr;
   case SelectionTree::Selection::Complete:
 // If the Common Ancestor is completely selected, then it's a root statement
 // and its parent will be unselected.
Index: clang-tools-extra/clangd/Selection.cpp
===
--- clang-tools-extra/clangd/Selection.cpp
+++ clang-tools-extra/clangd/Selection.cpp
@@ -61,13 +61,13 @@
 
   // Associates any tokens overlapping [Begin, End) with an AST node.
   // Tokens that were already claimed by another AST node are not claimed again.
-  // Returns whether the node is selected in the sense of SelectionTree.
-  SelectionTree::Selection claim(unsigned Begin, unsigned End) {
+  // Updates Result if the node is selected in the sense of SelectionTree.
+  void claim(unsigned Begin, unsigned End, SelectionTree::Selection ) {
 assert(Begin <= End);
 
 // Fast-path for missing the selection entirely.
 if (Begin >= SelEnd || End <= SelBegin)
-  return SelectionTree::Unselected;
+  return;
 
 // We will consider the range (at least partially) selected if it hit any
 // selected and previously unclaimed token.
@@ -98,9 +98,13 @@
   }
 }
 
-if (!ClaimedAnyToken)
-  return SelectionTree::Unselected;
-return PartialSelection ? SelectionTree::Partial : SelectionTree::Complete;
+// If some tokens were previously claimed (Result != Unselected), we may
+// upgrade from Partial->Complete, even if no new tokens were claimed.
+// Important for [[int a]].
+if (ClaimedAnyToken || Result) {
+  Result = std::max(Result, PartialSelection ? 

[PATCH] D67056: Add a bugprone-argument-comment option: IgnoreSingleArgument.

[Alexander Kornienko via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL371075: Add a bugprone-argument-comment option: 
IgnoreSingleArgument. (authored by alexfh, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67056?vs=218892=218922#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67056

Files:
  clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp
  clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.h
  clang-tools-extra/trunk/docs/clang-tidy/checks/bugprone-argument-comment.rst
  
clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-ignore-single-argument.cpp

Index: clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-ignore-single-argument.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-ignore-single-argument.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-ignore-single-argument.cpp
@@ -0,0 +1,97 @@
+// RUN: %check_clang_tidy %s bugprone-argument-comment %t -- \
+// RUN:   -config="{CheckOptions: [{key: bugprone-argument-comment.IgnoreSingleArgument, value: 1}, {key: CommentBoolLiterals, value: 1},{key: CommentIntegerLiterals, value: 1}, {key: CommentFloatLiterals, value: 1}, {key: CommentUserDefinedLiterals, value: 1}, {key: CommentStringLiterals, value: 1}, {key: CommentNullPtrs, value: 1}, {key: CommentCharacterLiterals, value: 1}]}" --
+
+struct A {
+  void foo(bool abc);
+  void foo(bool abc, bool cde);
+  void foo(const char *, bool abc);
+  void foo(int iabc);
+  void foo(float fabc);
+  void foo(double dabc);
+  void foo(const char *strabc);
+  void fooW(const wchar_t *wstrabc);
+  void fooPtr(A *ptrabc);
+  void foo(char chabc);
+};
+
+#define FOO 1
+
+void g(int a);
+void h(double b);
+void i(const char *c);
+
+double operator"" _km(long double);
+
+void test() {
+  A a;
+
+  a.foo(true);
+
+  a.foo(false);
+
+  a.foo(true, false);
+  // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for literal argument 'abc' [bugprone-argument-comment]
+  // CHECK-MESSAGES: [[@LINE-2]]:15: warning: argument comment missing for literal argument 'cde' [bugprone-argument-comment]
+  // CHECK-FIXES: a.foo(/*abc=*/true, /*cde=*/false);
+
+  a.foo(false, true);
+  // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for literal argument 'abc' [bugprone-argument-comment]
+  // CHECK-MESSAGES: [[@LINE-2]]:16: warning: argument comment missing for literal argument 'cde' [bugprone-argument-comment]
+  // CHECK-FIXES: a.foo(/*abc=*/false, /*cde=*/true);
+
+  a.foo(/*abc=*/false, true);
+  // CHECK-MESSAGES: [[@LINE-1]]:24: warning: argument comment missing for literal argument 'cde' [bugprone-argument-comment]
+  // CHECK-FIXES: a.foo(/*abc=*/false, /*cde=*/true);
+
+  a.foo(false, /*cde=*/true);
+  // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for literal argument 'abc' [bugprone-argument-comment]
+  // CHECK-FIXES: a.foo(/*abc=*/false, /*cde=*/true);
+
+  bool val1 = true;
+  bool val2 = false;
+  a.foo(val1, val2);
+
+  a.foo("", true);
+  // CHECK-MESSAGES: [[@LINE-1]]:13: warning: argument comment missing for literal argument 'abc' [bugprone-argument-comment]
+  // CHECK-FIXES: a.foo("", /*abc=*/true);
+
+  a.foo(0);
+
+  a.foo(1.0f);
+
+  a.foo(1.0);
+
+  int val3 = 10;
+  a.foo(val3);
+
+  float val4 = 10.0;
+  a.foo(val4);
+
+  double val5 = 10.0;
+  a.foo(val5);
+
+  a.foo("Hello World");
+
+  a.fooW(L"Hello World");
+
+  a.fooPtr(nullptr);
+
+  a.foo(402.0_km);
+
+  a.foo('A');
+
+  g(FOO);
+
+  h(1.0f);
+
+  i(__FILE__);
+
+  g((1));
+}
+
+void f(bool _with_underscores_);
+void ignores_underscores() {
+  f(false);
+
+  f(true);
+}
Index: clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.h
===
--- clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.h
+++ clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.h
@@ -41,6 +41,7 @@
 
 private:
   const unsigned StrictMode : 1;
+  const unsigned IgnoreSingleArgument : 1;
   const unsigned CommentBoolLiterals : 1;
   const unsigned CommentIntegerLiterals : 1;
   const unsigned CommentFloatLiterals : 1;
Index: clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp
@@ -24,6 +24,7 @@
ClangTidyContext *Context)
 : ClangTidyCheck(Name, Context),
   StrictMode(Options.getLocalOrGlobal("StrictMode", 0) != 0),
+  IgnoreSingleArgument(Options.get("IgnoreSingleArgument", 0) != 0),

[clang-tools-extra] r371075 - Add a bugprone-argument-comment option: IgnoreSingleArgument.

[Alexander Kornienko via cfe-commits]

Author: alexfh
Date: Thu Sep  5 07:48:23 2019
New Revision: 371075

URL: http://llvm.org/viewvc/llvm-project?rev=371075=rev
Log:
Add a bugprone-argument-comment option: IgnoreSingleArgument.

Summary:
Add bugprone-argument-comment option: IgnoreSingleArgument.
When true, the check will ignore the single argument.

Sometimes, it's not necessary to add comment to single argument.
For example:

> std::string name("Yubo Xie");
> pScreen->SetWidth(1920);
> pScreen->SetHeight(1080);

This option can ignore such single argument in bugprone-argument-comment check.

Reviewers: alexfh

Reviewed By: alexfh

Subscribers: cfe-commits

Tags: #clang

Patch by Yubo Xie.

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

Added:

clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-ignore-single-argument.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp
clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.h
clang-tools-extra/trunk/docs/clang-tidy/checks/bugprone-argument-comment.rst

Modified: clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp?rev=371075=371074=371075=diff
==
--- clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp Thu 
Sep  5 07:48:23 2019
@@ -24,6 +24,7 @@ ArgumentCommentCheck::ArgumentCommentChe
ClangTidyContext *Context)
 : ClangTidyCheck(Name, Context),
   StrictMode(Options.getLocalOrGlobal("StrictMode", 0) != 0),
+  IgnoreSingleArgument(Options.get("IgnoreSingleArgument", 0) != 0),
   CommentBoolLiterals(Options.getLocalOrGlobal("CommentBoolLiterals", 0) !=
   0),
   CommentIntegerLiterals(
@@ -41,6 +42,7 @@ ArgumentCommentCheck::ArgumentCommentChe
 
 void ArgumentCommentCheck::storeOptions(ClangTidyOptions::OptionMap ) {
   Options.store(Opts, "StrictMode", StrictMode);
+  Options.store(Opts, "IgnoreSingleArgument", IgnoreSingleArgument);
   Options.store(Opts, "CommentBoolLiterals", CommentBoolLiterals);
   Options.store(Opts, "CommentIntegerLiterals", CommentIntegerLiterals);
   Options.store(Opts, "CommentFloatLiterals", CommentFloatLiterals);
@@ -254,7 +256,7 @@ void ArgumentCommentCheck::checkCallArgs
 
   Callee = Callee->getFirstDecl();
   unsigned NumArgs = std::min(Args.size(), Callee->getNumParams());
-  if (NumArgs == 0)
+  if ((NumArgs == 0) || (IgnoreSingleArgument && NumArgs == 1))
 return;
 
   auto MakeFileCharRange = [Ctx](SourceLocation Begin, SourceLocation End) {

Modified: clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.h?rev=371075=371074=371075=diff
==
--- clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.h 
(original)
+++ clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.h Thu Sep  
5 07:48:23 2019
@@ -41,6 +41,7 @@ public:
 
 private:
   const unsigned StrictMode : 1;
+  const unsigned IgnoreSingleArgument : 1;
   const unsigned CommentBoolLiterals : 1;
   const unsigned CommentIntegerLiterals : 1;
   const unsigned CommentFloatLiterals : 1;

Modified: 
clang-tools-extra/trunk/docs/clang-tidy/checks/bugprone-argument-comment.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/clang-tidy/checks/bugprone-argument-comment.rst?rev=371075=371074=371075=diff
==
--- 
clang-tools-extra/trunk/docs/clang-tidy/checks/bugprone-argument-comment.rst 
(original)
+++ 
clang-tools-extra/trunk/docs/clang-tidy/checks/bugprone-argument-comment.rst 
Thu Sep  5 07:48:23 2019
@@ -28,6 +28,9 @@ Options
underscores and case when comparing names -- otherwise they are taken into
account.
 
+.. option:: IgnoreSingleArgument
+   When true, the check will ignore the single argument.
+
 .. option:: CommentBoolLiterals
 
When true, the check will add argument comments in the format

Added: 
clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-ignore-single-argument.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-ignore-single-argument.cpp?rev=371075=auto
==
--- 
clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-ignore-single-argument.cpp
 (added)
+++ 
clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-ignore-single-argument.cpp
 Thu Sep  5 07:48:23 2019
@@ -0,0 +1,97 @@
+// RUN: %check_clang_tidy %s 

[clang-tools-extra] r371076 - [clang-tidy] Make most ArgumentCommentCheck options local, as they should be

[Alexander Kornienko via cfe-commits]

Author: alexfh
Date: Thu Sep  5 07:48:31 2019
New Revision: 371076

URL: http://llvm.org/viewvc/llvm-project?rev=371076=rev
Log:
[clang-tidy] Make most ArgumentCommentCheck options local, as they should be

Modified:
clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp

clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-ignore-single-argument.cpp

clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-literals.cpp

Modified: clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp?rev=371076=371075=371076=diff
==
--- clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp Thu 
Sep  5 07:48:31 2019
@@ -25,19 +25,14 @@ ArgumentCommentCheck::ArgumentCommentChe
 : ClangTidyCheck(Name, Context),
   StrictMode(Options.getLocalOrGlobal("StrictMode", 0) != 0),
   IgnoreSingleArgument(Options.get("IgnoreSingleArgument", 0) != 0),
-  CommentBoolLiterals(Options.getLocalOrGlobal("CommentBoolLiterals", 0) !=
-  0),
-  CommentIntegerLiterals(
-  Options.getLocalOrGlobal("CommentIntegerLiterals", 0) != 0),
-  CommentFloatLiterals(
-  Options.getLocalOrGlobal("CommentFloatLiterals", 0) != 0),
-  CommentStringLiterals(
-  Options.getLocalOrGlobal("CommentStringLiterals", 0) != 0),
-  CommentUserDefinedLiterals(
-  Options.getLocalOrGlobal("CommentUserDefinedLiterals", 0) != 0),
-  CommentCharacterLiterals(
-  Options.getLocalOrGlobal("CommentCharacterLiterals", 0) != 0),
-  CommentNullPtrs(Options.getLocalOrGlobal("CommentNullPtrs", 0) != 0),
+  CommentBoolLiterals(Options.get("CommentBoolLiterals", 0) != 0),
+  CommentIntegerLiterals(Options.get("CommentIntegerLiterals", 0) != 0),
+  CommentFloatLiterals(Options.get("CommentFloatLiterals", 0) != 0),
+  CommentStringLiterals(Options.get("CommentStringLiterals", 0) != 0),
+  CommentUserDefinedLiterals(Options.get("CommentUserDefinedLiterals", 0) 
!=
+ 0),
+  CommentCharacterLiterals(Options.get("CommentCharacterLiterals", 0) != 
0),
+  CommentNullPtrs(Options.get("CommentNullPtrs", 0) != 0),
   IdentRE("^(/\\* *)([_A-Za-z][_A-Za-z0-9]*)( *= *\\*/)$") {}
 
 void ArgumentCommentCheck::storeOptions(ClangTidyOptions::OptionMap ) {

Modified: 
clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-ignore-single-argument.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-ignore-single-argument.cpp?rev=371076=371075=371076=diff
==
--- 
clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-ignore-single-argument.cpp
 (original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-ignore-single-argument.cpp
 Thu Sep  5 07:48:31 2019
@@ -1,5 +1,13 @@
 // RUN: %check_clang_tidy %s bugprone-argument-comment %t -- \
-// RUN:   -config="{CheckOptions: [{key: 
bugprone-argument-comment.IgnoreSingleArgument, value: 1}, {key: 
CommentBoolLiterals, value: 1},{key: CommentIntegerLiterals, value: 1}, {key: 
CommentFloatLiterals, value: 1}, {key: CommentUserDefinedLiterals, value: 1}, 
{key: CommentStringLiterals, value: 1}, {key: CommentNullPtrs, value: 1}, {key: 
CommentCharacterLiterals, value: 1}]}" --
+// RUN:   -config="{CheckOptions: [ \
+// RUN: {key: bugprone-argument-comment.IgnoreSingleArgument, value: 1}, \
+// RUN: {key: bugprone-argument-comment.CommentBoolLiterals, value: 1}, \
+// RUN: {key: bugprone-argument-comment.CommentIntegerLiterals, value: 1}, 
\
+// RUN: {key: bugprone-argument-comment.CommentFloatLiterals, value: 1}, \
+// RUN: {key: bugprone-argument-comment.CommentUserDefinedLiterals, value: 
1}, \
+// RUN: {key: bugprone-argument-comment.CommentStringLiterals, value: 1}, \
+// RUN: {key: bugprone-argument-comment.CommentNullPtrs, value: 1}, \
+// RUN: {key: bugprone-argument-comment.CommentCharacterLiterals, value: 
1}]}" --
 
 struct A {
   void foo(bool abc);

Modified: 
clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-literals.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-literals.cpp?rev=371076=371075=371076=diff
==
--- 
clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-literals.cpp 
(original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-literals.cpp 
Thu Sep  5 07:48:31 2019
@@ -1,5 +1,12 @@
 // RUN: %check_clang_tidy %s bugprone-argument-comment 

[PATCH] D54408: [ASTMatchers] Add matchers available through casting to derived

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D54408#1659301 , @Abpostelnicu 
wrote:

> @aaron.ballman 
>  I think the auto usage improves and simplifies the code, however, as I would 
> really like to see this code landed, I would be ok to help Stephen to finish 
> this work and replace auto by the "old" way. Do you think we can have this 
> approved if we make the changes mentioned earlier?


Nothing jumps out at me as blocking this, aside from completing the usual 
review activities. Have at it!


Repository:
  rC Clang

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

https://reviews.llvm.org/D54408



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

[PATCH] D67140: [analyzer][NFC] Fix inconsistent references to checkers as "checks"

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D67140#1658969 , @gribozavr wrote:

> In D67140#1658365 , @aaron.ballman 
> wrote:
>
> > Ah, good to know! That reduces my concern, but doesn't negate it. AFAIK, we 
> > haven't changed the interface such that it requires code changes rather 
> > than just a recompile in recent history, so this is a bit novel.
>
>
> I think API changes happen all the time. At Google, we are integrating 
> upstream LLVM and Clang changes into our internal codebase daily. We have a 
> lot of internal ClangTidy checkers. Fixing up all our internal code to keep 
> with upstream changes is a full time job for one engineer (but it is a 
> rotation).


I think this sort of backs up the point I was making. It requires an FTE to 
keep up with the breaks already. I'm worried about the folks who don't have the 
same resources that Google has. Where you get a new version of Clang every N 
months (rather than tracking ToT) and it's a scramble to make everything work 
again with the newest version, which delays adopting the newest Clang version 
until one lucky developer fixes all the checks.

API changes happen all the time, but rarely do they break *everything* for so 
little gain. I'm not asking for API stability guarantees, but we should still 
recognize that not everyone has Google's resources for keeping things working.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67140



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

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[Justin Hibbits via Phabricator via cfe-commits]

jhibbits added a comment.

Not in 9.0, but I will try to push for it in 9.0.1.

To others, for posterity, I pushed *only* the SPE subset, not the 8548 CPU 
component.  That will be a separate commit.  I wanted it to be more than just a 
dummy stub, so that part will be a separate commit.  The part committed was 
already reviewed by @nemanjai and approved.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D49754



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

[PATCH] D66919: Warn about zero-parameter K definitions in -Wstrict-prototypes

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D66919#1658483 , @aaronpuchert 
wrote:

> In D66919#1658355 , @aaron.ballman 
> wrote:
>
> > We do have numerous warnings that are default errors, you can look for 
> > `DefaultError` in the diagnostic .td files to see the uses.
>
>
> Thanks, I hadn't seen that before. It seems that most of these warnings are 
> for extensions, but one comes pretty close to what @dexonsmith has suggested:
>
>   def warn_cannot_pass_non_pod_arg_to_vararg : Warning<
> "cannot pass object of %select{non-POD|non-trivial}0 type %1 through 
> variadic"
> " %select{function|block|method|constructor}2; call will abort at 
> runtime">,
> InGroup, DefaultError;
>
>
> The standard explicitly says in C11 6.5.2.2p8: “the number and types of 
> arguments are not compared with those of the parameters in a function 
> definition that does not include a function prototype declarator”, but 
> perhaps this just means a programmer can't rely on such a check?


I read that as stating that such a check does not happen. However, the standard 
places very little requirements on diagnostics; it's always permissible to take 
undefined behavior and define it to do something, such as diagnosing as a 
warning or an error, as a matter of QoI.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66919



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

[PATCH] D67084: [clang-tidy] Fix bugprone-argument-comment bug: negative literal number is not checked.

[Alexander Kornienko via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL371072: [clang-tidy] Fix bugprone-argument-comment bug: 
negative literal number is not… (authored by alexfh, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67084?vs=218893=218914#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67084

Files:
  clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp
  clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-literals.cpp


Index: 
clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-literals.cpp
===
--- 
clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-literals.cpp
+++ 
clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-literals.cpp
@@ -69,18 +69,29 @@
   // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for 
literal argument 'fabc' [bugprone-argument-comment]
   // CHECK-FIXES: a.foo(/*fabc=*/1.0f);
 
+  a.foo(-1.0f);
+  // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for 
literal argument 'fabc' [bugprone-argument-comment]
+  // CHECK-FIXES: a.foo(/*fabc=*/-1.0f);
+
   a.foo(1.0);
   // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for 
literal argument 'dabc' [bugprone-argument-comment]
   // CHECK-FIXES: a.foo(/*dabc=*/1.0);
 
+  a.foo(-1.0);
+  // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for 
literal argument 'dabc' [bugprone-argument-comment]
+  // CHECK-FIXES: a.foo(/*dabc=*/-1.0);
+
   int val3 = 10;
   a.foo(val3);
+  a.foo(-val3);
 
   float val4 = 10.0;
   a.foo(val4);
+  a.foo(-val4);
 
   double val5 = 10.0;
   a.foo(val5);
+  a.foo(-val5);
 
   a.foo("Hello World");
   // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for 
literal argument 'strabc' [bugprone-argument-comment]
@@ -98,14 +109,22 @@
   // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for 
literal argument 'dabc' [bugprone-argument-comment]
   // CHECK-FIXES: a.foo(/*dabc=*/402.0_km);
 
+  a.foo(-402.0_km);
+  // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for 
literal argument 'dabc' [bugprone-argument-comment]
+  // CHECK-FIXES: a.foo(/*dabc=*/-402.0_km);
+
   a.foo('A');
   // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for 
literal argument 'chabc' [bugprone-argument-comment]
   // CHECK-FIXES: a.foo(/*chabc=*/'A');
 
   g(FOO);
+  g(-FOO);
   h(1.0f);
   // CHECK-MESSAGES: [[@LINE-1]]:5: warning: argument comment missing for 
literal argument 'b' [bugprone-argument-comment]
   // CHECK-FIXES: h(/*b=*/1.0f);
+  h(-1.0f);
+  // CHECK-MESSAGES: [[@LINE-1]]:5: warning: argument comment missing for 
literal argument 'b' [bugprone-argument-comment]
+  // CHECK-FIXES: h(/*b=*/-1.0f);
   i(__FILE__);
 
   j(1, X(1), X(1));
Index: clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp
@@ -230,9 +230,11 @@
 // Given the argument type and the options determine if we should
 // be adding an argument comment.
 bool ArgumentCommentCheck::shouldAddComment(const Expr *Arg) const {
+  Arg = Arg->IgnoreImpCasts();
+  if (isa(Arg))
+Arg = cast(Arg)->getSubExpr();
   if (Arg->getExprLoc().isMacroID())
 return false;
-  Arg = Arg->IgnoreImpCasts();
   return (CommentBoolLiterals && isa(Arg)) ||
  (CommentIntegerLiterals && isa(Arg)) ||
  (CommentFloatLiterals && isa(Arg)) ||


Index: clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-literals.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-literals.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-literals.cpp
@@ -69,18 +69,29 @@
   // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for literal argument 'fabc' [bugprone-argument-comment]
   // CHECK-FIXES: a.foo(/*fabc=*/1.0f);
 
+  a.foo(-1.0f);
+  // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for literal argument 'fabc' [bugprone-argument-comment]
+  // CHECK-FIXES: a.foo(/*fabc=*/-1.0f);
+
   a.foo(1.0);
   // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for literal argument 'dabc' [bugprone-argument-comment]
   // CHECK-FIXES: a.foo(/*dabc=*/1.0);
 
+  a.foo(-1.0);
+  // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for literal argument 'dabc' [bugprone-argument-comment]
+  // CHECK-FIXES: a.foo(/*dabc=*/-1.0);
+
   int val3 = 10;
   a.foo(val3);
+  a.foo(-val3);
 
   float val4 = 10.0;
   

[clang-tools-extra] r371072 - [clang-tidy] Fix bugprone-argument-comment bug: negative literal number is not checked.

[Alexander Kornienko via cfe-commits]

Author: alexfh
Date: Thu Sep  5 07:13:57 2019
New Revision: 371072

URL: http://llvm.org/viewvc/llvm-project?rev=371072=rev
Log:
[clang-tidy] Fix bugprone-argument-comment bug: negative literal number is not 
checked.

Summary:
For example:
```
void foo(int a);
foo(-2);
```
should be fixed as:
```
foo(/*a=*/-2);
```
This change tries to fix this issue.

Reviewers: alexfh, hokein, aaron.ballman

Reviewed By: alexfh, aaron.ballman

Subscribers: xazax.hun, cfe-commits

Tags: #clang, #clang-tools-extra

Patch by Yubo Xie.

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

Modified:
clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp

clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-literals.cpp

Modified: clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp?rev=371072=371071=371072=diff
==
--- clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/bugprone/ArgumentCommentCheck.cpp Thu 
Sep  5 07:13:57 2019
@@ -230,9 +230,11 @@ static const FunctionDecl *resolveMocks(
 // Given the argument type and the options determine if we should
 // be adding an argument comment.
 bool ArgumentCommentCheck::shouldAddComment(const Expr *Arg) const {
+  Arg = Arg->IgnoreImpCasts();
+  if (isa(Arg))
+Arg = cast(Arg)->getSubExpr();
   if (Arg->getExprLoc().isMacroID())
 return false;
-  Arg = Arg->IgnoreImpCasts();
   return (CommentBoolLiterals && isa(Arg)) ||
  (CommentIntegerLiterals && isa(Arg)) ||
  (CommentFloatLiterals && isa(Arg)) ||

Modified: 
clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-literals.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-literals.cpp?rev=371072=371071=371072=diff
==
--- 
clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-literals.cpp 
(original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/bugprone-argument-comment-literals.cpp 
Thu Sep  5 07:13:57 2019
@@ -69,18 +69,29 @@ void test() {
   // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for 
literal argument 'fabc' [bugprone-argument-comment]
   // CHECK-FIXES: a.foo(/*fabc=*/1.0f);
 
+  a.foo(-1.0f);
+  // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for 
literal argument 'fabc' [bugprone-argument-comment]
+  // CHECK-FIXES: a.foo(/*fabc=*/-1.0f);
+
   a.foo(1.0);
   // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for 
literal argument 'dabc' [bugprone-argument-comment]
   // CHECK-FIXES: a.foo(/*dabc=*/1.0);
 
+  a.foo(-1.0);
+  // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for 
literal argument 'dabc' [bugprone-argument-comment]
+  // CHECK-FIXES: a.foo(/*dabc=*/-1.0);
+
   int val3 = 10;
   a.foo(val3);
+  a.foo(-val3);
 
   float val4 = 10.0;
   a.foo(val4);
+  a.foo(-val4);
 
   double val5 = 10.0;
   a.foo(val5);
+  a.foo(-val5);
 
   a.foo("Hello World");
   // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for 
literal argument 'strabc' [bugprone-argument-comment]
@@ -98,14 +109,22 @@ void test() {
   // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for 
literal argument 'dabc' [bugprone-argument-comment]
   // CHECK-FIXES: a.foo(/*dabc=*/402.0_km);
 
+  a.foo(-402.0_km);
+  // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for 
literal argument 'dabc' [bugprone-argument-comment]
+  // CHECK-FIXES: a.foo(/*dabc=*/-402.0_km);
+
   a.foo('A');
   // CHECK-MESSAGES: [[@LINE-1]]:9: warning: argument comment missing for 
literal argument 'chabc' [bugprone-argument-comment]
   // CHECK-FIXES: a.foo(/*chabc=*/'A');
 
   g(FOO);
+  g(-FOO);
   h(1.0f);
   // CHECK-MESSAGES: [[@LINE-1]]:5: warning: argument comment missing for 
literal argument 'b' [bugprone-argument-comment]
   // CHECK-FIXES: h(/*b=*/1.0f);
+  h(-1.0f);
+  // CHECK-MESSAGES: [[@LINE-1]]:5: warning: argument comment missing for 
literal argument 'b' [bugprone-argument-comment]
+  // CHECK-FIXES: h(/*b=*/-1.0f);
   i(__FILE__);
 
   j(1, X(1), X(1));


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

[PATCH] D67224: [clangd] Enable completions with fixes in VSCode

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov created this revision.
Herald added subscribers: cfe-commits, kadircet, arphaman, mgrang, jkorous, 
MaskRay.
Herald added a project: clang.

Currently, the completions are not shown to the user as VSCode tries to match
'filterText' against the text in the edit range. Since the text contains '.'
or '->', we end up trying to match 'field' against '->field' and fail.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D67224

Files:
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/CodeComplete.h
  clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts


Index: clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
===
--- clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
+++ clang-tools-extra/clangd/clients/clangd-vscode/src/extension.ts
@@ -65,6 +65,14 @@
   }
 }
 
+class EnableEditsNearCursorFeature implements vscodelc.StaticFeature {
+  fillClientCapabilities(capabilities: vscodelc.ClientCapabilities): void {
+const extendedCompletionCapabilities: any = 
capabilities.textDocument.completion;
+extendedCompletionCapabilities.editsNearCursor = true;
+  }
+  initialize(capabilities: vscodelc.ServerCapabilities, documentSelector: 
(string | { language: string; scheme?: string; pattern?: string; } | { 
language?: string; scheme: string; pattern?: string; } | { language?: string; 
scheme?: string; pattern: string; })[]): void {
+  }
+}
 /**
  *  this method is called when your extension is activate
  *  your extension is activated the very first time the command is executed
@@ -114,6 +122,7 @@
   context.subscriptions.push(
   vscode.Disposable.from(semanticHighlightingFeature));
   clangdClient.registerFeature(semanticHighlightingFeature);
+  clangdClient.registerFeature(new EnableEditsNearCursorFeature);
   console.log('Clang Language Server is now active!');
   context.subscriptions.push(clangdClient.start());
   context.subscriptions.push(vscode.commands.registerCommand(
Index: clang-tools-extra/clangd/CodeComplete.h
===
--- clang-tools-extra/clangd/CodeComplete.h
+++ clang-tools-extra/clangd/CodeComplete.h
@@ -175,9 +175,13 @@
   // thse includes may not be accurate for all of them.
   llvm::SmallVector Includes;
 
+  struct FixIt {
+std::string Before;
+TextEdit Edit;
+  };
   /// Holds information about small corrections that needs to be done. Like
   /// converting '->' to '.' on member access.
-  std::vector FixIts;
+  std::vector FixIts;
 
   /// Holds the range of the token we are going to replace with this 
completion.
   Range CompletionTokenRange;
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -277,12 +277,25 @@
   Completion.Name.back() == '/')
 Completion.Kind = CompletionItemKind::Folder;
   for (const auto  : C.SemaResult->FixIts) {
-Completion.FixIts.push_back(toTextEdit(
-FixIt, ASTCtx->getSourceManager(), ASTCtx->getLangOpts()));
+// FIXME: this should live in SourceCode.h
+auto  = ASTCtx->getSourceManager();
+CharSourceRange Range = Lexer::makeFileCharRange(FixIt.RemoveRange, SM,
+ 
ASTCtx->getLangOpts());
+FileID FID;
+unsigned StartOffset;
+std::tie(FID, StartOffset) = SM.getDecomposedLoc(Range.getBegin());
+
+std::string Code = SM.getBufferData(FID).substr(
+StartOffset, SM.getFileOffset(Range.getEnd()) - StartOffset);
+
+Completion.FixIts.push_back(CodeCompletion::FixIt{
+std::move(Code), toTextEdit(FixIt, ASTCtx->getSourceManager(),
+ASTCtx->getLangOpts())});
   }
-  llvm::sort(Completion.FixIts, [](const TextEdit , const TextEdit ) {
-return std::tie(X.range.start.line, X.range.start.character) <
-   std::tie(Y.range.start.line, Y.range.start.character);
+  llvm::sort(Completion.FixIts, [](const CodeCompletion::FixIt ,
+   const CodeCompletion::FixIt ) {
+return std::tie(X.Edit.range.start.line, X.Edit.range.start.character) 
<
+   std::tie(Y.Edit.range.start.line, Y.Edit.range.start.character);
   });
   Completion.Deprecated |=
   (C.SemaResult->Availability == CXAvailability_Deprecated);
@@ -1817,11 +1830,12 @@
   // is mainly to help LSP clients again, so that changes do not effect each
   // other.
   for (const auto  : FixIts) {
-if (isRangeConsecutive(FixIt.range, LSP.textEdit->range)) {
-  LSP.textEdit->newText = FixIt.newText + LSP.textEdit->newText;
-  LSP.textEdit->range.start = FixIt.range.start;
+if (isRangeConsecutive(FixIt.Edit.range,