[PATCH] D121098: [C++20][Modules][HU 4/5] Handle pre-processed header units.

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

OK, I feel good if this one contains tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121098

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

[PATCH] D121678: [pseudo] Split greatergreater token.

[Zequan Wu via Phabricator via cfe-commits]

zequanwu added a comment.

This fails on windows bot at 
https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket/8819402935494502225/+/u/package_clang/stdout?format=raw.

  
C:\b\s\w\ir\cache\builder\src\third_party\llvm\clang-tools-extra\pseudo\unittests\TokenTest.cpp(190):
 error: Value of: Split.tokens()
  
  
   Expected: has 5 elements where
  
  
   element #0 token (">", 51),
  
  
   element #1 token (">", 51),
  
  
   element #2 token (">", 51),
  
  
   element #3 token (">", 51),
  
  
   element #4 token (">>=", 54)
  
  
 Actual: { greater 1:0 ">" flags=1, greater 1:0 ">" flags=1, greater 3:0 
"\80" flags=1, greater 3:0 "\10" flags=1, greatergreaterequal 5:0 ">>=" flags=1 
}, whose element #2 doesn't match
  
  
   [  FAILED  ] TokenTest.SplitGreaterGreater (1 ms)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121678

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

[PATCH] D121951: [AMDGPU] Only warn when mixing printf and hostcall

[Sameer Sahasrabuddhe via Phabricator via cfe-commits]

sameerds added a comment.

The check for "__ockl_hostcall_internal" is not longer relevant with the new 
hostcall attribute. Can we simply remove this check? What is the situation 
where the warning is still useful?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121951

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

[PATCH] D121749: [clang-format][docs] Regenerate ClangFormatStyleOptions.rst

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

I’m not blocking it just using the observation to highlight that the rst 
generated isn’t conformant with best practices. The solution being that a 
volunteer offers to fix the dump_format_style.py or enduring Format.h isn’t 
making those mistakes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121749

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

[PATCH] D121916: [clang-format] [doc] Add script to automatically update help output in ClangFormat.rst.

[MyDeveloperDay via Phabricator via cfe-commits]

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

Wow! Now that’s what I’m talking about!! Awesome! Thank you so much!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121916

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

[PATCH] D121983: Driver: Don't warn on -mbranch-protection when linking

[Tom Stellard via Phabricator via cfe-commits]

tstellar created this revision.
tstellar added reviewers: chill, vhscampos, stuij, amilendra.
Herald added a project: All.
tstellar requested review of this revision.
Herald added a project: clang.

The -mbranch-protection definition in Options.td was not given a Group,
so this was causing clang to emit a -Wunused-command-line-argument
warning when this flag was passed to the linker driver.  This was a
problem, because some build systems, like cmake, automatically pass the
C flags to the linker.  Therefore, any program that was compiled with
-Werror and -mbranch-protection would fail to link with the error:

argument unused during compilation: '-mbranch-protection=standard' 
[-Werror,-Wunused-command-line-argument]


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121983

Files:
  clang/include/clang/Driver/Options.td
  clang/test/Driver/Inputs/main.c
  clang/test/Driver/aarch64-security-options.c


Index: clang/test/Driver/aarch64-security-options.c
===
--- clang/test/Driver/aarch64-security-options.c
+++ clang/test/Driver/aarch64-security-options.c
@@ -27,6 +27,10 @@
 // RUN: %clang -target aarch64--none-eabi -c %s -### -mbranch-protection=bar   
  2>&1 | \
 // RUN: FileCheck %s --check-prefix=BAD-BP-PROTECTION --check-prefix=WARN
 
+// RUN: %clang -target aarch64--none-eabi -o %t-main.o 
-mbranch-protection=standard -c %S/Inputs/main.c
+// RUN: %clang -target aarch64--none-eabi -o %t-main 
-mbranch-protection=standard %t-main.o 2>&1 | \
+// RUN: FileCheck --allow-empty %s --check-prefix=LINKER-DRIVER
+
 // WARN-NOT: warning: ignoring '-mbranch-protection=' option because the 
'aarch64' architecture does not support it [-Wbranch-protection]
 
 // RA-OFF: "-msign-return-address=none"
@@ -46,3 +50,7 @@
 
 // BAD-B-KEY-COMBINATION: invalid branch protection option 'b-key' in 
'-mbranch-protection={{.*}}'
 // BAD-LEAF-COMBINATION: invalid branch protection option 'leaf' in 
'-mbranch-protection={{.*}}'
+
+// Check that the linker driver doesn't warn about -mbranch-protection=standard
+// as an unused option.
+// LINKER-DRIVER-NOT: warning:
Index: clang/test/Driver/Inputs/main.c
===
--- /dev/null
+++ clang/test/Driver/Inputs/main.c
@@ -0,0 +1,3 @@
+int main(int argc, char **argv) {
+  return 0;
+}
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -3442,6 +3442,7 @@
   Flags<[CC1Option]>, Group, Values<"none,all,non-leaf">,
   HelpText<"Select return address signing scope">;
 def mbranch_protection_EQ : Joined<["-"], "mbranch-protection=">,
+  Group,
   HelpText<"Enforce targets of indirect branches and function returns">;
 
 def mharden_sls_EQ : Joined<["-"], "mharden-sls=">,


Index: clang/test/Driver/aarch64-security-options.c
===
--- clang/test/Driver/aarch64-security-options.c
+++ clang/test/Driver/aarch64-security-options.c
@@ -27,6 +27,10 @@
 // RUN: %clang -target aarch64--none-eabi -c %s -### -mbranch-protection=bar 2>&1 | \
 // RUN: FileCheck %s --check-prefix=BAD-BP-PROTECTION --check-prefix=WARN
 
+// RUN: %clang -target aarch64--none-eabi -o %t-main.o -mbranch-protection=standard -c %S/Inputs/main.c
+// RUN: %clang -target aarch64--none-eabi -o %t-main -mbranch-protection=standard %t-main.o 2>&1 | \
+// RUN: FileCheck --allow-empty %s --check-prefix=LINKER-DRIVER
+
 // WARN-NOT: warning: ignoring '-mbranch-protection=' option because the 'aarch64' architecture does not support it [-Wbranch-protection]
 
 // RA-OFF: "-msign-return-address=none"
@@ -46,3 +50,7 @@
 
 // BAD-B-KEY-COMBINATION: invalid branch protection option 'b-key' in '-mbranch-protection={{.*}}'
 // BAD-LEAF-COMBINATION: invalid branch protection option 'leaf' in '-mbranch-protection={{.*}}'
+
+// Check that the linker driver doesn't warn about -mbranch-protection=standard
+// as an unused option.
+// LINKER-DRIVER-NOT: warning:
Index: clang/test/Driver/Inputs/main.c
===
--- /dev/null
+++ clang/test/Driver/Inputs/main.c
@@ -0,0 +1,3 @@
+int main(int argc, char **argv) {
+  return 0;
+}
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -3442,6 +3442,7 @@
   Flags<[CC1Option]>, Group, Values<"none,all,non-leaf">,
   HelpText<"Select return address signing scope">;
 def mbranch_protection_EQ : Joined<["-"], "mbranch-protection=">,
+  Group,
   HelpText<"Enforce targets of indirect branches and function returns">;
 
 def mharden_sls_EQ : Joined<["-"], "mharden-sls=">,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
htt

[PATCH] D121984: [RISCV][NFC] Moving RVV intrinsic type related util to llvm/Support

[Kito Cheng via Phabricator via cfe-commits]

kito-cheng created this revision.
Herald added subscribers: s, VincentWu, luke957, vkmr, frasercrmck, evandro, 
luismarques, apazos, sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, 
PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, jrtc27, 
niosHD, sabuasal, simoncook, johnrusso, rbar, asb, hiraditya, arichardson, 
mgorny.
Herald added a project: All.
kito-cheng requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, pcwang-thead, eopXD, 
MaskRay.
Herald added projects: clang, LLVM.

This patch is split from https://reviews.llvm.org/D111617, we need those
stuffs on clang, so must moving those stuff to llvm/Support.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121984

Files:
  clang/utils/TableGen/RISCVVEmitter.cpp
  llvm/include/llvm/Support/RISCVVIntrinsicUtils.h
  llvm/lib/Support/CMakeLists.txt
  llvm/lib/Support/RISCVVIntrinsicUtils.cpp

Index: llvm/lib/Support/RISCVVIntrinsicUtils.cpp
===
--- /dev/null
+++ llvm/lib/Support/RISCVVIntrinsicUtils.cpp
@@ -0,0 +1,668 @@
+//===- RISCVVIntrinsicUtils.cpp - RISC-V Vector Intrinsic Utils -*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "llvm/Support/RISCVVIntrinsicUtils.h"
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/SmallSet.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/ADT/StringMap.h"
+#include "llvm/ADT/StringSet.h"
+#include "llvm/ADT/Twine.h"
+#include "llvm/TableGen/Error.h"
+#include "llvm/TableGen/Record.h"
+#include 
+
+namespace llvm {
+namespace RISCV {
+
+//===--===//
+// Type implementation
+//===--===//
+
+LMULType::LMULType(int NewLog2LMUL) {
+  // Check Log2LMUL is -3, -2, -1, 0, 1, 2, 3
+  assert(NewLog2LMUL <= 3 && NewLog2LMUL >= -3 && "Bad LMUL number!");
+  Log2LMUL = NewLog2LMUL;
+}
+
+std::string LMULType::str() const {
+  if (Log2LMUL < 0)
+return "mf" + utostr(1ULL << (-Log2LMUL));
+  return "m" + utostr(1ULL << Log2LMUL);
+}
+
+VScaleVal LMULType::getScale(unsigned ElementBitwidth) const {
+  int Log2ScaleResult = 0;
+  switch (ElementBitwidth) {
+  default:
+break;
+  case 8:
+Log2ScaleResult = Log2LMUL + 3;
+break;
+  case 16:
+Log2ScaleResult = Log2LMUL + 2;
+break;
+  case 32:
+Log2ScaleResult = Log2LMUL + 1;
+break;
+  case 64:
+Log2ScaleResult = Log2LMUL;
+break;
+  }
+  // Illegal vscale result would be less than 1
+  if (Log2ScaleResult < 0)
+return llvm::None;
+  return 1 << Log2ScaleResult;
+}
+
+void LMULType::MulLog2LMUL(int log2LMUL) { Log2LMUL += log2LMUL; }
+
+LMULType &LMULType::operator*=(uint32_t RHS) {
+  assert(isPowerOf2_32(RHS));
+  this->Log2LMUL = this->Log2LMUL + Log2_32(RHS);
+  return *this;
+}
+
+RVVType::RVVType(BasicType BT, int Log2LMUL, StringRef prototype)
+: BT(BT), LMUL(LMULType(Log2LMUL)) {
+  applyBasicType();
+  applyModifier(prototype);
+  Valid = verifyType();
+  if (Valid) {
+initBuiltinStr();
+initTypeStr();
+if (isVector()) {
+  initClangBuiltinStr();
+}
+  }
+}
+
+// clang-format off
+// boolean type are encoded the ratio of n (SEW/LMUL)
+// SEW/LMUL | 1 | 2 | 4 | 8| 16| 32| 64
+// c type   | vbool64_t | vbool32_t | vbool16_t | vbool8_t | vbool4_t  | vbool2_t  | vbool1_t
+// IR type  | nxv1i1| nxv2i1| nxv4i1| nxv8i1   | nxv16i1   | nxv32i1   | nxv64i1
+
+// type\lmul | 1/8| 1/4  | 1/2 | 1   | 2| 4| 8
+//   |--  |  | --- | --- |  |  | 
+// i64   | N/A| N/A  | N/A | nxv1i64 | nxv2i64  | nxv4i64  | nxv8i64
+// i32   | N/A| N/A  | nxv1i32 | nxv2i32 | nxv4i32  | nxv8i32  | nxv16i32
+// i16   | N/A| nxv1i16  | nxv2i16 | nxv4i16 | nxv8i16  | nxv16i16 | nxv32i16
+// i8| nxv1i8 | nxv2i8   | nxv4i8  | nxv8i8  | nxv16i8  | nxv32i8  | nxv64i8
+// double| N/A| N/A  | N/A | nxv1f64 | nxv2f64  | nxv4f64  | nxv8f64
+// float | N/A| N/A  | nxv1f32 | nxv2f32 | nxv4f32  | nxv8f32  | nxv16f32
+// half  | N/A| nxv1f16  | nxv2f16 | nxv4f16 | nxv8f16  | nxv16f16 | nxv32f16
+// clang-format on
+
+bool RVVType::verifyType() const {
+  if (ScalarType == Invalid)
+return false;
+  if (isScalar())
+return true;
+  if (!Scale.hasValue())
+return false;
+  if (isFloat() && ElementBitwidth == 8)
+return false;
+  unsigned V = Scale.getValue();
+  switch (ElementBitwidth) {
+  case 1:
+  case 8:
+// Check Scale is 1,2,4,8,16,32,64
+return (V <= 64 &&

[PATCH] D70401: [RISCV] Complete RV32E/ilp32e implementation

[Zakk Chen via Phabricator via cfe-commits]

khchen added a comment.
Herald added a subscriber: s.

In D70401#3384758 , @pcwang-thead 
wrote:

> In D70401#3250049 , @khchen wrote:
>
>> 1. please add a check here 
>> 
>>  and a clang cc1 test for it.
>> 2. Have you try to run llvm-test-suite with rv32e config on qemu?
>
>
>
> 1. Thanks, I may do it later. And here is a question: the comment 
> 
>  says `It is illegal to specify 'e' extensions with 'f' and 'd'`.
>
> While ilp32e 
> 
>  says:
>
>> The ILP32E calling convention is not compatible with ISAs that have 
>> registers that require load and store alignments of more than 32 bits. In 
>> particular, this calling convention must not be used with the D ISA 
>> extension.
>
> And, the RV32E 
>  chapter 
> in RISCV ISA manual says:
>
>> RV32E can be combined with all current standard extensions.
>
> If I understand correctly, E can't be combined with D in current 
> specification since E must use ILP32E calling convention.

IMO, at least clang need to follows the gcc's implementation.
I guess gcc implementation follow riscv-elf-psabi-doc, @kito-cheng could you 
please confirm that?

> 2. I have run llvm-test-suite with rv32e on qemu, and found no major fault 
> for current implementation. Some tests are disabled because they can't run on 
> bare mental (sees Disabled llvm-test-suite cases 
> ).
>
> There are some failed tests due to floating-point precision, but I saw the 
> same result when run with  rv32imc on bare mental. I haven't taken the time 
> to find out the reason, but I guess it may be soft-float issues.

Thanks for testing!! I also tested your patch locally, 
Could you please make sure all gcc and clang results are the same in your 
failed tests?

I found 
https://github.com/llvm/llvm-test-suite/blob/main/SingleSource/UnitTests/2003-05-26-Shorts.c
 result is mismatched with gcc's (-march=rv32e -mabi=ilp32e).
Did you have same issue?

my build option:

  $/path/to/rv32e-gcc/bin/riscv32-unknown-elf-gcc -march=rv32e -mabi=ilp32e 
2003-05-26-Shorts.c
  $./bin/clang --target=riscv32 -march=rv32e -mabi=ilp32e 
--gcc-toolchain=/path/to/rv32e-gcc/ 2003-05-26-Shorts.c 

clang output:

 ui = 3318069411 (0xc5c5b8a3) UL-ui = 0 (0xafafafaf)

  ui*ui = 2382936009 (0x8e08b7c9)   UL/ui = -2060025877491592863 
(0xe3695161)   


  i = -976897885 (0xc5c5b8a3) L-i = 0 (0xafafafb0)  

   i* i = -1912031287 (0x8e08b7c9)L/ i = 6996953267980741613 
(0x611a2bed0001)   


  us= 47267 (0xb8a3)  UL-us = -4195947477825748992 
(0xc5c5afafafaf) 
  us*us = 2234169289 (0x852ab7c9)   UL/us = 1452874783539635691 
(0x1429a5ebf397)


   s= -18269 (0xb8a3) L-s = -4195666002849038335 
(0xc5c6afafafaf)   
   s* s = 333756361 (0x13e4b7c9)  L/ s = -7718140893307295808 
(0x94e3a7c1201b)  


  ub= 163 (0xa3)  UL-ub = -4195745167686238208 
(0xc5c5b800afafafaf) 
  ub*ub = 26569 (0x67c9)  UL/ub = 2350833624863004346 
(0x209fd6ba0113eca9)  


   b= -93 (0xffa3)L-b = -4195744068174610431 
(0xc5c5b900afafafaf)   
   b* b = 8649 (0x21c9)   L/b = -1938405340110362979 
(0xe519669d00dd1421)   

gcc output:

 ui = 3318069411 (0xc5c5b8a3) UL-ui = -5787213829993660416 
(0xafafafaf)
  ui*ui = 2382936009 (0x8e08b7c9)   UL/ui = 3815330145 (0xe3695161)
  
  i = -976897885 (0xc5c5b8a3) L-i = -5787213825698693120 
(0xafafafb0)
   i* i = -1912031287 (0x8e08b7c9)L/ i = 5924072429 (0x1611a2bed)
  
  us= 47267 (0xb8a3)  UL-us = -5787213826675638272 
(0xafafafafc5c5)
  us*us = 2234169289 (0x852ab7c9)   UL/us = 267830203885035 (0xf3971429a5eb)
  
   s= -18269 (0xb8a3) L-s = -5787213826675572736 
(0xafafafafc5c6)
   s* s = 333756361 (0x13e4b7c9)  L/ s = 316777810864064 (0x1201b94e3a7c0)
  
  ub= 163 (0xa3)  UL-ub = -5787213826675591168 
(0xafaf

[PATCH] D121916: [clang-format] [doc] Add script to automatically update help output in ClangFormat.rst.

[Marek Kurdej via Phabricator via cfe-commits]

curdeius added inline comments.



Comment at: clang/tools/clang-format/ClangFormat.cpp:105
+SortIncludes("sort-includes",
+ cl::desc("If set, overrides the include sorting behavior\n"
+  "determined by the SortIncludes style flag"),

HazardyKnusperkeks wrote:
> Couldn't one split the string in python? I think an arbitrary position to 
> split the help isn't nice. I for one have often the terminal over half the 
> monitor spread, sometimes even the complete monitor.
Well, these strings are used to generate the output of `clang-format --help`, 
which is, IIUC, supposed to produce a 80-column output.
I fully agree that it would be better to have it splitted automatically 
depending on the output screen width, but we're not there yet unfortunately.
And .rst file is just the reflection of what `--help` outputs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121916

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

[PATCH] D121906: [clang-format] Indent import statements in JavaScript.

[MyDeveloperDay via Phabricator via cfe-commits]

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

Can you please supply full context diff "Context not available."




Comment at: clang/lib/Format/ContinuationIndenter.cpp:629
   int PPColumnCorrection = 0;
-  if (Style.IndentPPDirectives == FormatStyle::PPDIS_AfterHash &&
+  if (Style.Language != FormatStyle::LK_JavaScript &&
+  Style.IndentPPDirectives == FormatStyle::PPDIS_AfterHash &&

!Style.isJavaScript()



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:1436
+  // Javascript import statements are indented like normal statements.
+  if (Style.Language != FormatStyle::LK_JavaScript &&
+  Style.IndentPPDirectives != FormatStyle::PPDIS_BeforeHash &&

!Style.isJavaScript()


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121906

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

[PATCH] D121753: [clang-format] Use a macro for non-C keywords

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay requested changes to this revision.
MyDeveloperDay added inline comments.
This revision now requires changes to proceed.



Comment at: clang/lib/Format/FormatToken.h:884
 struct AdditionalKeywords {
+#define LIST_ADDITIONAL_KEYWORDS   
\
+  /* Context-sensitive ones that appear in C++ or ObjC.  The lexer lexes them  
\

I didn't see this before... for me this is a hard no, I think macro code is 
ugly, it causes clang-format itself a whole host of issues, and I don't want to 
proliferate it. plus it begins a path of you using flags and I think that is 
unstructure C way of coding.

I know you want to add other keywords for Verilog but this to me isn't nice I 
don't understand why you couldn't have added the Verilog keywords like we did 
for JavaScript and C# 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121753

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

[PATCH] D121755: [clang-format] Join spaceRequiredBefore and spaceRequiredBetween

[MyDeveloperDay via Phabricator via cfe-commits]

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

This just made a 300 lines function and a 500 line function with minimal 
comments into a 800 line function.. For no real benefit?

Because from what I can tell you haven't worked on small clang-format issues 
you won't know that I often put a breakpoint in the spaceRequiredBetween, if it 
calls out into that function I now know where its covered.

I think if you had fixed a miriade of issues like   "I want a space between `@` 
and `{`" then you would have understood why breaking the 800 lines at least in 
2 can be helpful even a little.

I know its not idea, but I'm not sure that the first step I'd make is to join 2 
functions to make one massive function, for me my greatest frustration is the 
lack of comments and the if statements that have about 8 different clauses..

A better developer than me once said "Deal with the case you want and get 
out"...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121755

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

[PATCH] D121756: [clang-format] Clean up code looking for if statements

[MyDeveloperDay via Phabricator via cfe-commits]

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

Sorry I don't believe we've covered the changes with unit tests.




Comment at: clang/lib/Format/FormatToken.h:528
+  /// to be handled separately.
+  bool isConditionLParen(bool IncludeSpecial) const {
+if (!is(tok::l_paren))

IncludeSpecial  seems confusing at best if not obtuse.



Comment at: clang/lib/Format/FormatToken.h:538
+ tok::kw_for, tok::kw_catch)) ||
+Prev->isOneOf(tok::kw_if, tok::kw_while, tok::kw_switch,
+  tok::kw_case, tok::kw_constexpr));

What about MacroIf



Comment at: clang/lib/Format/TokenAnnotator.cpp:2988
 return 100;
-  if (Left.is(tok::l_paren) && Left.Previous &&
-  (Left.Previous->is(tok::kw_for) || Left.Previous->isIf()))
+  if (Left.isConditionLParen(/*IncludeSpecial=*/true))
 return 1000;

There has to be a missed unit test here..this condition before only handled if 
and for

Did you run the regression suite as well as the unit tests?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121756

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

[PATCH] D121983: Driver: Don't warn on -mbranch-protection when linking

[Victor Campos via Phabricator via cfe-commits]

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

LGTM, thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121983

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

[PATCH] D121754: [clang-format] Refactor determineStarAmpUsage

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay requested changes to this revision.
MyDeveloperDay added inline comments.
This revision now requires changes to proceed.



Comment at: clang/lib/Format/TokenAnnotator.cpp:2146-2147
+//   know how they can be followed by a star or amp.
+// co_await, delete - It doesn't make sense to have them followed by a 
unary
+//   `+` or `-`.
+if (PrevToken->isOneOf(TT_ConditionalExpr, tok::l_paren, tok::comma,

HazardyKnusperkeks wrote:
> Especially here, why should a `+` after `delete` be a binary operator?
> How much sense it makes doesn't matter, it is valid c++: 
> https://gcc.godbolt.org/z/c1x1nn3Ej
I'm also trying to understand did you mean you couldn't have

case -1:
case +1:
case +0:
case  -0:

https://gcc.godbolt.org/z/qvE44d5xz


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121754

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

[PATCH] D118370: [clang-tidy] bugprone-signal-handler: Message improvement and code refactoring.

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

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

Applied the review proposals.
Changed "system call" to "standard function".
Put the string lists into constant std::initializer_list.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118370

Files:
  clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h
  clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler-minimal.c
  clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler-posix.c
  clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c
@@ -5,7 +5,7 @@
 #include "stdio.h"
 #include "system-other.h"
 
-// The function should be classified as system call even if there is
+// The function should be classified as standard function even if there is
 // declaration the in source file.
 // FIXME: The detection works only if the first declaration is in system
 // header.
@@ -17,7 +17,7 @@
 
 void handler_printf(int) {
   printf("1234");
-  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: standard function 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
   // CHECK-NOTES: :[[@LINE-2]]:3: note: function 'printf' called here from 'handler_printf'
   // CHECK-NOTES: :[[@LINE+4]]:18: note: function 'handler_printf' registered here as signal handler
 }
@@ -28,7 +28,7 @@
 
 void handler_extern(int) {
   f_extern();
-  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'f_extern' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: cannot verify that external function 'f_extern' is asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
   // CHECK-NOTES: :[[@LINE-2]]:3: note: function 'f_extern' called here from 'handler_extern'
   // CHECK-NOTES: :[[@LINE+4]]:18: note: function 'handler_extern' registered here as signal handler
 }
@@ -51,7 +51,7 @@
 
 void f_bad() {
   printf("1234");
-  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: standard function 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
   // CHECK-NOTES: :[[@LINE-2]]:3: note: function 'printf' called here from 'f_bad'
   // CHECK-NOTES: :[[@LINE+5]]:3: note: function 'f_bad' called here from 'handler_bad'
   // CHECK-NOTES: :[[@LINE+8]]:18: note: function 'handler_bad' registered here as signal handler
@@ -67,7 +67,7 @@
 
 void f_bad1() {
   printf("1234");
-  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: standard function 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
   // CHECK-NOTES: :[[@LINE-2]]:3: note: function 'printf' called here from 'f_bad1'
   // CHECK-NOTES: :[[@LINE+6]]:3: note: function 'f_bad1' called here from 'f_bad2'
   // CHECK-NOTES: :[[@LINE+9]]:3: note: function 'f_bad2' called here from 'handler_bad1'
@@ -99,7 +99,7 @@
 void handler_false_condition(int) {
   if (0)
 printf("1234");
-  // CHECK-NOTES: :[[@LINE-1]]:5: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:5: warning: standard function 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
   // CHECK-NOTES: :[[@LINE-2]]:5: note: function 'printf' called here from 'handler_false_condition'
   // CHECK-NOTES: :[[@LINE+4]]:18: note: function 'handler_false_condition' registered here as signal handler
 }
@@ -110,11 +110,11 @@
 
 void handler_multiple_calls(int) {
   f_extern();
-  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'f_extern' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: cannot verify that external function 'f_extern' is asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
   // CHECK-NOTES: :[[@LINE-2]]:3: note: function 'f_extern' called here

[PATCH] D121758: [clang-format] Add support for formatting Verilog code

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

In D121758#3389181 , @sstwcw wrote:

> Yes.  I am surprised that you asked since everyone asked me to break it apart.

Well I was thinking you move the unrelated parts out and then reduce the side 
of this patch, (but you'll have patch dependencies but then the review will be 
more manageable for us.)

No one is saying that adding Verilog isn't a good idea. (it is actually as long 
as its not too invasive), I like @HazardyKnusperkeks  suggestion of bringing it 
in in smaller pieces, I could even see us landing pieces before
it was fully complete. (Like we did with C#, which probably isn't 100% complete 
either, but we incrementally add it)

If people don't try and format Verilog (which they shouldn't be expecting to 
then it won't hurt if its not 100% complete.) And from my perspective is seems 
it NOT possible for you to land Verilog without completely rewriting large
swaths of the seemingly unrelated other code first? is the structure of 
clang-format so bad that you can't possible work with what is there without 
having to come in a refactor it all from underneath us?

Bottom line, here is the impression  I get... You likely have a downstream fork 
of clang-format that supports Verilog, and you are trying to upstream 
it..problem is as you developed it you refactored a lot of things (to some 
extent for the better in your view), But you didn't add unit tests for those 
refactoring because frankly you didn't need to it was your local copy.

Now landing those refactoring seems like a good idea to you, but we have to 
take them on sight unseen that those refactoring are ok, With no unit tests to 
back up your justification even if that just means bolstering the existing 
tests with new tests that cover more cases. (your isIf() change is one, I'd be 
HIGHLY surprised if that didn't cause some sort of regressions for someone 
somewhere, when I say regression I mean changes, both positive and negative but 
people call them regression! either way even if we fix stuff..)

I feel like we are trying to be super responsive to your reviews (no seriously 
I used to have to wait weeks for someone to even have a look!, we have a great 
team of reviewers and contributors they are highly skilled), You've been an 
LLVM member in Phabricator for not a month. Some people have multiple years 
experience here, What are we to do? accept everything on face value without 
unit tests?

But I'm sorry I feel bad, because at every turn I'm like "Really, are we doing 
that now?  (MACRO is FormatToken)",  I hate doing it but I feel like I'm 
pushing back on every review. But we can't just let stuff in without trying to 
do a full and through review and that means unit tests, you understand that 
right?

Don't expect to drive by with this review, some of my reviews took 1-2 years to 
land, my dedication to stay and fix bugs in the meantime proved to the 
reviewers that I was serious. It could take this level of time and commitment 
to gain peoples trust to land such a large patch.

You are clearly highly capable and understand the clang-format code base. We 
want you as a contributor because you understand it already. But this is a most 
unusual onboarding, but I feel I personally we have to treat the reviews as I 
would any other review coming in...which I'm afraid is with scrutiny.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121758

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

[PATCH] D121097: [C++20][Modules][HU 3/5] Emit module macros for header units.

[Iain Sandoe via Phabricator via cfe-commits]

iains added a comment.

In D121097#3391236 , @ChuanqiXu wrote:

> I feel good if we could add  the test from: 
> http://eel.is/c++draft/cpp.import#8.

I agree we should have tests based on all the relevant examples in the standard.

However, that specific example is not connected with **building** header units, 
but instead is connected with consuming various preprocessor directives etc. 
when building a regular module.  We actually already have some of the tests in 
diagnosing bad imports.

So I think that (after this series is in) we should be in a position to add 
some more of the examples in the standard - as a follow-on patch, does that 
make sense?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121097

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

[PATCH] D121965: Add validation for number of arguments of __builtin_memcpy_inline

[Guillaume Chatelet via Phabricator via cfe-commits]

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

Thx!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121965

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

[PATCH] D70401: [RISCV] Complete RV32E/ilp32e implementation

[Kito Cheng via Phabricator via cfe-commits]

kito-cheng added a comment.

> If I understand correctly, E can't be combined with D in current 
> specification since E must use ILP32E calling convention.

Calling convention and extensions are separated, calling convention are specify 
the how argument passing and the register convention, so ILP32E *can* use with 
`-march=rv32efd`, but it can't pass or return floating point type in FPR.

Just like we can `ILP32` for `-march=rv32ifd` and `LP64` with `-march=rv64ifd`, 
you may confused about the opposite combination like `ILP32D` with 
`-march=rv32i` and `LP64D` with `-march=rv64i` is not work, that's because it 
require pass or return floating point type in FPR, but FPR isn't existing in 
such ISA config.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70401

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

[clang] 33d020d - [CodeGen] Remove some uses of deprecated Address constructor

[Nikita Popov via cfe-commits]

Author: Nikita Popov
Date: 2022-03-18T11:01:25+01:00
New Revision: 33d020d010478e59e2cdc57300d4aae3fbac0611

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

LOG: [CodeGen] Remove some uses of deprecated Address constructor

Added: 


Modified: 
clang/lib/CodeGen/CGCall.cpp
clang/lib/CodeGen/CGException.cpp
clang/lib/CodeGen/CGExprScalar.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index f80aa630e4aba..6cfc3c56c165b 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -1011,11 +1011,12 @@ static void forConstantArrayExpansion(CodeGenFunction 
&CGF,
   CharUnits EltSize = CGF.getContext().getTypeSizeInChars(CAE->EltTy);
   CharUnits EltAlign =
 BaseAddr.getAlignment().alignmentOfArrayElement(EltSize);
+  llvm::Type *EltTy = CGF.ConvertTypeForMem(CAE->EltTy);
 
   for (int i = 0, n = CAE->NumElts; i < n; i++) {
 llvm::Value *EltAddr = CGF.Builder.CreateConstGEP2_32(
 BaseAddr.getElementType(), BaseAddr.getPointer(), 0, i);
-Fn(Address::deprecated(EltAddr, EltAlign));
+Fn(Address(EltAddr, EltTy, EltAlign));
   }
 }
 
@@ -2684,9 +2685,8 @@ void CodeGenFunction::EmitFunctionProlog(const 
CGFunctionInfo &FI,
   // parameter, which is a pointer to the complete memory area.
   Address ArgStruct = Address::invalid();
   if (IRFunctionArgs.hasInallocaArg()) {
-ArgStruct = Address::deprecated(
-Fn->getArg(IRFunctionArgs.getInallocaArgNo()),
-FI.getArgStructAlignment());
+ArgStruct = Address(Fn->getArg(IRFunctionArgs.getInallocaArgNo()),
+FI.getArgStruct(), FI.getArgStructAlignment());
 
 assert(ArgStruct.getType() == FI.getArgStruct()->getPointerTo());
   }
@@ -2736,8 +2736,8 @@ void CodeGenFunction::EmitFunctionProlog(const 
CGFunctionInfo &FI,
   Address V =
   Builder.CreateStructGEP(ArgStruct, FieldIndex, Arg->getName());
   if (ArgI.getInAllocaIndirect())
-V = Address::deprecated(Builder.CreateLoad(V),
-getContext().getTypeAlignInChars(Ty));
+V = Address(Builder.CreateLoad(V), ConvertTypeForMem(Ty),
+getContext().getTypeAlignInChars(Ty));
   ArgVals.push_back(ParamValue::forIndirect(V));
   break;
 }
@@ -2885,8 +2885,8 @@ void CodeGenFunction::EmitFunctionProlog(const 
CGFunctionInfo &FI,
   assert(pointeeTy->isPointerType());
   Address temp =
 CreateMemTemp(pointeeTy, getPointerAlign(), "swifterror.temp");
-  Address arg = Address::deprecated(
-  V, getContext().getTypeAlignInChars(pointeeTy));
+  Address arg(V, ConvertTypeForMem(pointeeTy),
+  getContext().getTypeAlignInChars(pointeeTy));
   llvm::Value *incomingErrorValue = Builder.CreateLoad(arg);
   Builder.CreateStore(incomingErrorValue, temp);
   V = temp.getPointer();
@@ -4966,8 +4966,8 @@ RValue CodeGenFunction::EmitCall(const CGFunctionInfo 
&CallInfo,
   assert(!swiftErrorTemp.isValid() && "multiple swifterror args");
 
   QualType pointeeTy = I->Ty->getPointeeType();
-  swiftErrorArg =
-Address::deprecated(V, 
getContext().getTypeAlignInChars(pointeeTy));
+  swiftErrorArg = Address(V, ConvertTypeForMem(pointeeTy),
+  getContext().getTypeAlignInChars(pointeeTy));
 
   swiftErrorTemp =
 CreateMemTemp(pointeeTy, getPointerAlign(), "swifterror.temp");

diff  --git a/clang/lib/CodeGen/CGException.cpp 
b/clang/lib/CodeGen/CGException.cpp
index 98be1e2ff338f..76c6beb090a96 100644
--- a/clang/lib/CodeGen/CGException.cpp
+++ b/clang/lib/CodeGen/CGException.cpp
@@ -1845,7 +1845,7 @@ Address 
CodeGenFunction::recoverAddrOfEscapedLocal(CodeGenFunction &ParentCGF,
   llvm::Value *ChildVar =
   Builder.CreateBitCast(RecoverCall, ParentVar.getType());
   ChildVar->setName(ParentVar.getName());
-  return Address::deprecated(ChildVar, ParentVar.getAlignment());
+  return ParentVar.withPointer(ChildVar);
 }
 
 void CodeGenFunction::EmitCapturedLocals(CodeGenFunction &ParentCGF,

diff  --git a/clang/lib/CodeGen/CGExprScalar.cpp 
b/clang/lib/CodeGen/CGExprScalar.cpp
index 18a22b50f63e4..cdd4302dc9711 100644
--- a/clang/lib/CodeGen/CGExprScalar.cpp
+++ b/clang/lib/CodeGen/CGExprScalar.cpp
@@ -420,8 +420,9 @@ class ScalarExprEmitter
 
 if (Value *Result = ConstantEmitter(CGF).tryEmitConstantExpr(E)) {
   if (E->isGLValue())
-return CGF.Builder.CreateLoad(Address::deprecated(
-Result, CGF.getContext().getTypeAlignInChars(E->getType(;
+return CGF.Builder.CreateLoad(Address(
+Result, CGF.ConvertTypeForMem(E->getType()),
+CGF.getContext(

[PATCH] D118370: [clang-tidy] bugprone-signal-handler: Message improvement and code refactoring.

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

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

Additional documentation related fixes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118370

Files:
  clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h
  clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler-minimal.c
  clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler-posix.c
  clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c
@@ -5,7 +5,7 @@
 #include "stdio.h"
 #include "system-other.h"
 
-// The function should be classified as system call even if there is
+// The function should be classified as standard function even if there is
 // declaration the in source file.
 // FIXME: The detection works only if the first declaration is in system
 // header.
@@ -17,7 +17,7 @@
 
 void handler_printf(int) {
   printf("1234");
-  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: standard function 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
   // CHECK-NOTES: :[[@LINE-2]]:3: note: function 'printf' called here from 'handler_printf'
   // CHECK-NOTES: :[[@LINE+4]]:18: note: function 'handler_printf' registered here as signal handler
 }
@@ -28,7 +28,7 @@
 
 void handler_extern(int) {
   f_extern();
-  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'f_extern' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: cannot verify that external function 'f_extern' is asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
   // CHECK-NOTES: :[[@LINE-2]]:3: note: function 'f_extern' called here from 'handler_extern'
   // CHECK-NOTES: :[[@LINE+4]]:18: note: function 'handler_extern' registered here as signal handler
 }
@@ -51,7 +51,7 @@
 
 void f_bad() {
   printf("1234");
-  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: standard function 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
   // CHECK-NOTES: :[[@LINE-2]]:3: note: function 'printf' called here from 'f_bad'
   // CHECK-NOTES: :[[@LINE+5]]:3: note: function 'f_bad' called here from 'handler_bad'
   // CHECK-NOTES: :[[@LINE+8]]:18: note: function 'handler_bad' registered here as signal handler
@@ -67,7 +67,7 @@
 
 void f_bad1() {
   printf("1234");
-  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: standard function 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
   // CHECK-NOTES: :[[@LINE-2]]:3: note: function 'printf' called here from 'f_bad1'
   // CHECK-NOTES: :[[@LINE+6]]:3: note: function 'f_bad1' called here from 'f_bad2'
   // CHECK-NOTES: :[[@LINE+9]]:3: note: function 'f_bad2' called here from 'handler_bad1'
@@ -99,7 +99,7 @@
 void handler_false_condition(int) {
   if (0)
 printf("1234");
-  // CHECK-NOTES: :[[@LINE-1]]:5: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:5: warning: standard function 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
   // CHECK-NOTES: :[[@LINE-2]]:5: note: function 'printf' called here from 'handler_false_condition'
   // CHECK-NOTES: :[[@LINE+4]]:18: note: function 'handler_false_condition' registered here as signal handler
 }
@@ -110,11 +110,11 @@
 
 void handler_multiple_calls(int) {
   f_extern();
-  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'f_extern' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: cannot verify that external function 'f_extern' is asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
   // CHECK-NOTES: :[[@LINE-2]]:3: note: function 'f_extern' called here from 'handler_multiple_calls'
   // CHECK-NOTES: :[[@LINE+10]]:18: note: function 'handler_mu

[PATCH] D121755: [clang-format] Join spaceRequiredBefore and spaceRequiredBetween

[Owen Pan via Phabricator via cfe-commits]

owenpan added a comment.

In D121755#3391606 , @MyDeveloperDay 
wrote:

> This just made a 300 lines function and a 500 line function with minimal 
> comments into a 800 line function.. For no real benefit?
>
> Because from what I can tell you haven't worked on small clang-format issues 
> you won't know that I often put a breakpoint in the spaceRequiredBetween, if 
> it calls out into that function I now know where its covered.
>
> I think if you had fixed a miriade of issues like   "I want a space between 
> `@` and `{`" then you would have understood why breaking the 800 lines at 
> least in 2 can be helpful even a little.
>
> I know its not idea, but I'm not sure that the first step I'd make is to join 
> 2 functions to make one massive function, for me my greatest frustration is 
> the lack of comments and the if statements that have about 8 different 
> clauses..
>
> A better developer than me once said "Deal with the case you want and get 
> out"...

+1.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121755

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

[clang] 74992f4 - [CodeGen] Store element type in DominatingValue

[Nikita Popov via cfe-commits]

Author: Nikita Popov
Date: 2022-03-18T11:13:25+01:00
New Revision: 74992f4a5bb79e2084abdef406ef2e5aa2024368

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

LOG: [CodeGen] Store element type in DominatingValue

For aggregate rvalues, we need to store the element type in the
dominating value, so we can recover the element type for the
address.

Added: 


Modified: 
clang/lib/CodeGen/CGCleanup.cpp
clang/lib/CodeGen/CodeGenFunction.h

Removed: 




diff  --git a/clang/lib/CodeGen/CGCleanup.cpp b/clang/lib/CodeGen/CGCleanup.cpp
index d84bddb8b22f3..a10851edfb82c 100644
--- a/clang/lib/CodeGen/CGCleanup.cpp
+++ b/clang/lib/CodeGen/CGCleanup.cpp
@@ -38,13 +38,13 @@ DominatingValue::saved_type::save(CodeGenFunction 
&CGF, RValue rv) {
 
 // These automatically dominate and don't need to be saved.
 if (!DominatingLLVMValue::needsSaving(V))
-  return saved_type(V, ScalarLiteral);
+  return saved_type(V, nullptr, ScalarLiteral);
 
 // Everything else needs an alloca.
 Address addr =
   CGF.CreateDefaultAlignTempAlloca(V->getType(), "saved-rvalue");
 CGF.Builder.CreateStore(V, addr);
-return saved_type(addr.getPointer(), ScalarAddress);
+return saved_type(addr.getPointer(), nullptr, ScalarAddress);
   }
 
   if (rv.isComplex()) {
@@ -54,19 +54,19 @@ DominatingValue::saved_type::save(CodeGenFunction 
&CGF, RValue rv) {
 Address addr = CGF.CreateDefaultAlignTempAlloca(ComplexTy, 
"saved-complex");
 CGF.Builder.CreateStore(V.first, CGF.Builder.CreateStructGEP(addr, 0));
 CGF.Builder.CreateStore(V.second, CGF.Builder.CreateStructGEP(addr, 1));
-return saved_type(addr.getPointer(), ComplexAddress);
+return saved_type(addr.getPointer(), nullptr, ComplexAddress);
   }
 
   assert(rv.isAggregate());
   Address V = rv.getAggregateAddress(); // TODO: volatile?
   if (!DominatingLLVMValue::needsSaving(V.getPointer()))
-return saved_type(V.getPointer(), AggregateLiteral,
+return saved_type(V.getPointer(), V.getElementType(), AggregateLiteral,
   V.getAlignment().getQuantity());
 
   Address addr =
 CGF.CreateTempAlloca(V.getType(), CGF.getPointerAlign(), "saved-rvalue");
   CGF.Builder.CreateStore(V.getPointer(), addr);
-  return saved_type(addr.getPointer(), AggregateAddress,
+  return saved_type(addr.getPointer(), V.getElementType(), AggregateAddress,
 V.getAlignment().getQuantity());
 }
 
@@ -86,11 +86,11 @@ RValue 
DominatingValue::saved_type::restore(CodeGenFunction &CGF) {
 return RValue::get(CGF.Builder.CreateLoad(getSavingAddress(Value)));
   case AggregateLiteral:
 return RValue::getAggregate(
-Address::deprecated(Value, CharUnits::fromQuantity(Align)));
+Address(Value, ElementType, CharUnits::fromQuantity(Align)));
   case AggregateAddress: {
 auto addr = CGF.Builder.CreateLoad(getSavingAddress(Value));
 return RValue::getAggregate(
-Address::deprecated(addr, CharUnits::fromQuantity(Align)));
+Address(addr, ElementType, CharUnits::fromQuantity(Align)));
   }
   case ComplexAddress: {
 Address address = getSavingAddress(Value);

diff  --git a/clang/lib/CodeGen/CodeGenFunction.h 
b/clang/lib/CodeGen/CodeGenFunction.h
index 7c6dbf814553a..24000b99608f7 100644
--- a/clang/lib/CodeGen/CodeGenFunction.h
+++ b/clang/lib/CodeGen/CodeGenFunction.h
@@ -201,10 +201,11 @@ template <> struct DominatingValue {
 AggregateAddress, ComplexAddress };
 
 llvm::Value *Value;
+llvm::Type *ElementType;
 unsigned K : 3;
 unsigned Align : 29;
-saved_type(llvm::Value *v, Kind k, unsigned a = 0)
-  : Value(v), K(k), Align(a) {}
+saved_type(llvm::Value *v, llvm::Type *e, Kind k, unsigned a = 0)
+  : Value(v), ElementType(e), K(k), Align(a) {}
 
   public:
 static bool needsSaving(RValue value);



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

[PATCH] D115907: [misexpect] Re-implement MisExpect Diagnostics

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.

The test also failed in the Phabricator pre-commit CI, please keep an eye on it 
before re-submitting (failure link for latest diff was 
https://buildkite.com/llvm-project/premerge-checks/builds/83983#39c06525-7452-412d-af83-ae2cc2d30cdc)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115907

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

[PATCH] D115622: [Debugify] Optimize debugify original mode

[Djordje Todorovic via Phabricator via cfe-commits]

djtodoro updated this revision to Diff 416438.
djtodoro added a comment.
Herald added a project: All.

- Move the skipping into the for-loop since we want to collect metadata for the 
functions that are not observed in the previous Pass (for example the function 
wasn't of interest due to having an attribute attached that wasn't relevant for 
the previous Pass) -- the improvement is still ~2x

Again, Sorry for delay here and, @Orlando @StephenTozer thank you a lot for 
your comments!


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

https://reviews.llvm.org/D115622

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  llvm/include/llvm/Transforms/Utils/Debugify.h
  llvm/lib/Transforms/Utils/Debugify.cpp
  llvm/tools/opt/opt.cpp
  llvm/unittests/Transforms/Utils/DebugifyTest.cpp

Index: llvm/unittests/Transforms/Utils/DebugifyTest.cpp
===
--- llvm/unittests/Transforms/Utils/DebugifyTest.cpp
+++ llvm/unittests/Transforms/Utils/DebugifyTest.cpp
@@ -121,15 +121,15 @@
 
   DebugInfoDrop *P = new DebugInfoDrop();
 
-  DebugInfoPerPassMap DIPreservationMap;
+  DebugInfoPerPass DIBeforePass;
   DebugifyCustomPassManager Passes;
-  Passes.setDIPreservationMap(DIPreservationMap);
+  Passes.setDebugInfoBeforePass(DIBeforePass);
   Passes.add(createDebugifyModulePass(DebugifyMode::OriginalDebugInfo, "",
-  &(Passes.getDebugInfoPerPassMap(;
+  &(Passes.getDebugInfoPerPass(;
   Passes.add(P);
   Passes.add(createCheckDebugifyModulePass(false, "", nullptr,
DebugifyMode::OriginalDebugInfo,
-   &(Passes.getDebugInfoPerPassMap(;
+   &(Passes.getDebugInfoPerPass(;
 
   testing::internal::CaptureStderr();
   Passes.run(*M);
@@ -172,15 +172,15 @@
 
   DebugValueDrop *P = new DebugValueDrop();
 
-  DebugInfoPerPassMap DIPreservationMap;
+  DebugInfoPerPass DIBeforePass;
   DebugifyCustomPassManager Passes;
-  Passes.setDIPreservationMap(DIPreservationMap);
+  Passes.setDebugInfoBeforePass(DIBeforePass);
   Passes.add(createDebugifyModulePass(DebugifyMode::OriginalDebugInfo, "",
-  &(Passes.getDebugInfoPerPassMap(;
+  &(Passes.getDebugInfoPerPass(;
   Passes.add(P);
   Passes.add(createCheckDebugifyModulePass(false, "", nullptr,
DebugifyMode::OriginalDebugInfo,
-   &(Passes.getDebugInfoPerPassMap(;
+   &(Passes.getDebugInfoPerPass(;
 
   testing::internal::CaptureStderr();
   Passes.run(*M);
@@ -225,15 +225,15 @@
 
   DebugInfoDummyAnalysis *P = new DebugInfoDummyAnalysis();
 
-  DebugInfoPerPassMap DIPreservationMap;
+  DebugInfoPerPass DIBeforePass;
   DebugifyCustomPassManager Passes;
-  Passes.setDIPreservationMap(DIPreservationMap);
+  Passes.setDebugInfoBeforePass(DIBeforePass);
   Passes.add(createDebugifyModulePass(DebugifyMode::OriginalDebugInfo, "",
-  &(Passes.getDebugInfoPerPassMap(;
+  &(Passes.getDebugInfoPerPass(;
   Passes.add(P);
   Passes.add(createCheckDebugifyModulePass(false, "", nullptr,
DebugifyMode::OriginalDebugInfo,
-   &(Passes.getDebugInfoPerPassMap(;
+   &(Passes.getDebugInfoPerPass(;
 
   testing::internal::CaptureStderr();
   Passes.run(*M);
Index: llvm/tools/opt/opt.cpp
===
--- llvm/tools/opt/opt.cpp
+++ llvm/tools/opt/opt.cpp
@@ -829,13 +829,13 @@
   // the (-check)-debugify passes.
   DebugifyCustomPassManager Passes;
   DebugifyStatsMap DIStatsMap;
-  DebugInfoPerPassMap DIPreservationMap;
+  DebugInfoPerPass DebugInfoBeforePass;
   if (DebugifyEach) {
 Passes.setDebugifyMode(DebugifyMode::SyntheticDebugInfo);
 Passes.setDIStatsMap(DIStatsMap);
   } else if (VerifyEachDebugInfoPreserve) {
 Passes.setDebugifyMode(DebugifyMode::OriginalDebugInfo);
-Passes.setDIPreservationMap(DIPreservationMap);
+Passes.setDebugInfoBeforePass(DebugInfoBeforePass);
 if (!VerifyDIPreserveExport.empty())
   Passes.setOrigDIVerifyBugsReportFilePath(VerifyDIPreserveExport);
   }
@@ -855,10 +855,10 @@
   Passes.setDIStatsMap(DIStatsMap);
   Passes.add(createDebugifyModulePass());
 } else if (VerifyDebugInfoPreserve) {
-  Passes.setDIPreservationMap(DIPreservationMap);
+  Passes.setDebugInfoBeforePass(DebugInfoBeforePass);
   Passes.add(createDebugifyModulePass(
   DebugifyMode::OriginalDebugInfo, "",
-  &(Passes.getDebugInfoPerPassMap(;
+  &(Passes.getDebugInfoPerPass(;
 }

[PATCH] D118935: [SYCL] Disallow explicit casts between mismatching address spaces

[Ronan Keryell via Phabricator via cfe-commits]

keryell added a comment.

In D118935#3389452 , @hvdijk wrote:

> It does make sense, then. A slightly more verbose commit message might have 
> helped though :)

Even better, some comments in the code explaining the "why" would have helped. 
The commit messages disappear while the comments are right there when the code 
is read/reviewed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118935

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

[PATCH] D121873: [clang][extract-api] Add enum support

[Daniel Grumberg via Phabricator via cfe-commits]

dang added inline comments.



Comment at: clang/lib/SymbolGraph/Serialization.cpp:343
+  if (!Enum)
+return;
+

zixuw wrote:
> dang wrote:
> > Quick design question: Do we want to be silently failing in these 
> > situations (especially since this shouldn't be happening)? Let me know what 
> > you think.
> I'm using this check to intentionally skip symbols that we do not want to 
> spit out, for example unconditionally unavailable symbols, or after we have 
> support for typedef records, anonymous enum decls that's declared with a 
> `typedef` so that we don't have duplicate information, etc.
> `Optional serializeAPIRecord` does this check now, and if we 
> `Serializer::shouldSkip` it, `None` will be returned. So it is expected, not 
> really silently failing.
Yeah that makes sense. If we are doing the check in `serializeAPIRecord` it 
might be worth not calling `serializeEnumRecord` at all for the sake of keeping 
the code handling these kinds of situation in a single place.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121873

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

[PATCH] D121965: Add validation for number of arguments of __builtin_memcpy_inline

[Roy Jacobson via Phabricator via cfe-commits]

royjacobson added a comment.

@gchatelet

In D121965#3391714 , @gchatelet wrote:

> Thx!

Thanks, will you be able to commit this for me as "Roy Jacobson 
"? I don't have write access :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121965

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

[PATCH] D121754: [clang-format] Refactor determineStarAmpUsage

[sstwcw via Phabricator via cfe-commits]

sstwcw updated this revision to Diff 416450.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121754

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

Index: clang/unittests/Format/TokenAnnotatorTest.cpp
===
--- clang/unittests/Format/TokenAnnotatorTest.cpp
+++ clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -80,6 +80,88 @@
   EXPECT_TOKEN(Tokens[11], tok::star, TT_UnaryOperator);
 }
 
+TEST_F(TokenAnnotatorTest, UnderstandsUsesOfPlusAndMinus) {
+  auto Tokens = annotate("x - 0");
+  EXPECT_EQ(Tokens.size(), 4u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::minus, TT_BinaryOperator);
+  Tokens = annotate("0 + 0");
+  EXPECT_EQ(Tokens.size(), 4u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::plus, TT_BinaryOperator);
+  Tokens = annotate("x + +0");
+  EXPECT_EQ(Tokens.size(), 5u) << Tokens;
+  EXPECT_TOKEN(Tokens[2], tok::plus, TT_UnaryOperator);
+  Tokens = annotate("x ? -0 : +0");
+  EXPECT_EQ(Tokens.size(), 8u) << Tokens;
+  EXPECT_TOKEN(Tokens[2], tok::minus, TT_UnaryOperator);
+  EXPECT_TOKEN(Tokens[5], tok::plus, TT_UnaryOperator);
+  Tokens = annotate("(-0)");
+  EXPECT_EQ(Tokens.size(), 5u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::minus, TT_UnaryOperator);
+  Tokens = annotate("0, -0");
+  EXPECT_EQ(Tokens.size(), 5u) << Tokens;
+  EXPECT_TOKEN(Tokens[2], tok::minus, TT_UnaryOperator);
+  Tokens = annotate("for (; -1;) {\n}");
+  EXPECT_EQ(Tokens.size(), 10u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::minus, TT_UnaryOperator);
+  Tokens = annotate("x = -1;");
+  EXPECT_EQ(Tokens.size(), 6u) << Tokens;
+  EXPECT_TOKEN(Tokens[2], tok::minus, TT_UnaryOperator);
+  Tokens = annotate("x[-1]");
+  EXPECT_EQ(Tokens.size(), 6u) << Tokens;
+  EXPECT_TOKEN(Tokens[2], tok::minus, TT_UnaryOperator);
+  Tokens = annotate("x = {-1};");
+  EXPECT_EQ(Tokens.size(), 8u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::minus, TT_UnaryOperator);
+  Tokens = annotate("co_await -x;");
+  EXPECT_EQ(Tokens.size(), 5u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::minus, TT_UnaryOperator);
+  Tokens = annotate("co_return -x;");
+  EXPECT_EQ(Tokens.size(), 5u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::minus, TT_UnaryOperator);
+  Tokens = annotate("co_yield -x;");
+  EXPECT_EQ(Tokens.size(), 5u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::minus, TT_UnaryOperator);
+  Tokens = annotate("delete -x;");
+  EXPECT_EQ(Tokens.size(), 5u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::minus, TT_UnaryOperator);
+  Tokens = annotate("return -x;");
+  EXPECT_EQ(Tokens.size(), 5u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::minus, TT_UnaryOperator);
+  Tokens = annotate("throw -x;");
+  EXPECT_EQ(Tokens.size(), 5u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::minus, TT_UnaryOperator);
+  Tokens = annotate("sizeof -x");
+  EXPECT_EQ(Tokens.size(), 4u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::minus, TT_UnaryOperator);
+  Tokens = annotate("co_await +x;");
+  EXPECT_EQ(Tokens.size(), 5u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::plus, TT_UnaryOperator);
+  Tokens = annotate("co_return +x;");
+  EXPECT_EQ(Tokens.size(), 5u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::plus, TT_UnaryOperator);
+  Tokens = annotate("co_yield +x;");
+  EXPECT_EQ(Tokens.size(), 5u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::plus, TT_UnaryOperator);
+  Tokens = annotate("delete +x;");
+  EXPECT_EQ(Tokens.size(), 5u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::plus, TT_UnaryOperator);
+  Tokens = annotate("return +x;");
+  EXPECT_EQ(Tokens.size(), 5u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::plus, TT_UnaryOperator);
+  Tokens = annotate("throw +x;");
+  EXPECT_EQ(Tokens.size(), 5u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::plus, TT_UnaryOperator);
+  Tokens = annotate("sizeof +x");
+  EXPECT_EQ(Tokens.size(), 4u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::plus, TT_UnaryOperator);
+  Tokens = annotate("(int)-x");
+  EXPECT_EQ(Tokens.size(), 6u) << Tokens;
+  EXPECT_TOKEN(Tokens[3], tok::minus, TT_UnaryOperator);
+  Tokens = annotate("!+x");
+  EXPECT_EQ(Tokens.size(), 4u) << Tokens;
+  EXPECT_TOKEN(Tokens[1], tok::plus, TT_UnaryOperator);
+}
+
 TEST_F(TokenAnnotatorTest, UnderstandsClasses) {
   auto Tokens = annotate("class C {};");
   EXPECT_EQ(Tokens.size(), 6u) << Tokens;
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -9753,6 +9753,11 @@
   verifyFormat("if (!(a->f())) {\n}");
   verifyFormat("if (!+i) {\n}");
   verifyFormat("~&a;");
+  verifyFormat("for (x = 0; -10 < x; --x) {\n}");
+  verifyFormat("sizeof -x");
+  verifyFormat("sizeof +x");
+  verifyFormat("delete +x;");
+  verifyFormat("co_await +x;");
 
   verifyFormat("a-- > b;");
   verifyFormat("b ? -a : c;");
Index: clang/lib/Format/Toke

[PATCH] D121890: [clang-format] Copy help options to the doc directory.

[sstwcw via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGfee94803f59d: [clang-format] Copy help options to the doc 
directory. (authored by sstwcw).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121890

Files:
  clang/docs/ClangFormat.rst

Index: clang/docs/ClangFormat.rst
===
--- clang/docs/ClangFormat.rst
+++ clang/docs/ClangFormat.rst
@@ -30,72 +30,69 @@
 
   Clang-format options:
 
---Werror   - If set, changes formatting warnings to errors
---Wno-error=- If set don't error out on the specified warning type.
-  =unknown -   If set, unknown format options are only warned about.
-   This can be used to enable formatting, even if the
-   configuration contains unknown (newer) options.
-   Use with caution, as this might lead to dramatically
-   differing format depending on an option being
-   supported or not.
---assume-filename= - Override filename used to determine the language.
- When reading from stdin, clang-format assumes this
- filename to determine the language.
---cursor=- The position of the cursor when invoking
- clang-format from an editor integration
---dry-run  - If set, do not actually make the formatting changes
---dump-config  - Dump configuration options to stdout and exit.
- Can be used with -style option.
---fallback-style=  - The name of the predefined style used as a
- fallback in case clang-format is invoked with
- -style=file, but can not find the .clang-format
- file to use.
- Use -fallback-style=none to skip formatting.
---ferror-limit=  - Set the maximum number of clang-format errors to
- emit before stopping (0 = no limit). Used only
- with --dry-run or -n
--i - Inplace edit s, if specified.
---length=- Format a range of this length (in bytes).
- Multiple ranges can be formatted by specifying
- several -offset and -length pairs.
- When only a single -offset is specified without
- -length, clang-format will format up to the end
- of the file.
- Can only be used with one input file.
---lines=   - : - format a range of
- lines (both 1-based).
- Multiple ranges can be formatted by specifying
- several -lines arguments.
- Can't be used with -offset and -length.
- Can only be used with one input file.
--n - Alias for --dry-run
---offset=- Format a range starting at this byte offset.
- Multiple ranges can be formatted by specifying
- several -offset and -length pairs.
- Can only be used with one input file.
---output-replacements-xml  - Output replacements as XML.
---sort-includes- If set, overrides the include sorting behavior
- determined by the SortIncludes style flag
---style=   - Coding style, currently supports:
-   LLVM, Google, Chromium, Mozilla, WebKit.
- Use -style=file to load style configuration from
- .clang-format file located in one of the parent
- directories of the source file (or current
- directory for stdin).
- Use -style=file: to load style
- configuration from a format file located at
- . This path can be absolute or
- relative to the working directory.
- Use -style="{key: value, ...}" to set specific
- parameters, e.g.:
-   -style="{BasedOnStyle: llvm, IndentWidth: 8}"
---verbose  - If set, shows the list of processed files
+--Werror   - If set, changes formatting warni

[clang] fee9480 - [clang-format] Copy help options to the doc directory.

[via cfe-commits]

Author: sstwcw
Date: 2022-03-18T10:51:36Z
New Revision: fee94803f59dbd1a5b39c51036f181246d7d2fe6

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

LOG: [clang-format] Copy help options to the doc directory.

The options listed in ClangFormat.rst lag behind those output by the
-help command line option.  Specifically, these are missing.

--files
--qualifier-alignment

Fixes #54418

Reviewed By: MyDeveloperDay, HazardyKnusperkeks

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

Added: 


Modified: 
clang/docs/ClangFormat.rst

Removed: 




diff  --git a/clang/docs/ClangFormat.rst b/clang/docs/ClangFormat.rst
index 8c0273c8eb3c3..5fc9656a4756a 100644
--- a/clang/docs/ClangFormat.rst
+++ b/clang/docs/ClangFormat.rst
@@ -30,72 +30,69 @@ to format 
C/C++/Java/JavaScript/JSON/Objective-C/Protobuf/C# code.
 
   Clang-format options:
 
---Werror   - If set, changes formatting warnings to errors
---Wno-error=- If set don't error out on the specified 
warning type.
-  =unknown -   If set, unknown format options are only 
warned about.
-   This can be used to enable formatting, even 
if the
-   configuration contains unknown (newer) 
options.
-   Use with caution, as this might lead to 
dramatically
-   
diff ering format depending on an option being
-   supported or not.
---assume-filename= - Override filename used to determine the 
language.
- When reading from stdin, clang-format assumes 
this
- filename to determine the language.
---cursor=- The position of the cursor when invoking
- clang-format from an editor integration
---dry-run  - If set, do not actually make the formatting 
changes
---dump-config  - Dump configuration options to stdout and exit.
- Can be used with -style option.
---fallback-style=  - The name of the predefined style used as a
- fallback in case clang-format is invoked with
- -style=file, but can not find the 
.clang-format
- file to use.
- Use -fallback-style=none to skip formatting.
---ferror-limit=  - Set the maximum number of clang-format errors 
to
- emit before stopping (0 = no limit). Used only
- with --dry-run or -n
--i - Inplace edit s, if specified.
---length=- Format a range of this length (in bytes).
- Multiple ranges can be formatted by specifying
- several -offset and -length pairs.
- When only a single -offset is specified 
without
- -length, clang-format will format up to the 
end
- of the file.
- Can only be used with one input file.
---lines=   - : - format a range of
- lines (both 1-based).
- Multiple ranges can be formatted by specifying
- several -lines arguments.
- Can't be used with -offset and -length.
- Can only be used with one input file.
--n - Alias for --dry-run
---offset=- Format a range starting at this byte offset.
- Multiple ranges can be formatted by specifying
- several -offset and -length pairs.
- Can only be used with one input file.
---output-replacements-xml  - Output replacements as XML.
---sort-includes- If set, overrides the include sorting behavior
- determined by the SortIncludes style flag
---style=   - Coding style, currently supports:
-   LLVM, Google, Chromium, Mozilla, WebKit.
- Use -style=file to load style configuration 
from
- .clang-format file located in one of the 
parent
- directories of the source file (or current
- directory for stdin).
- Use -style=file: to load 
style
- configuration fro

[PATCH] D121797: [clang][dataflow] Add modeling of Chromium's CHECK functionality

[Stanislav Gatev via Phabricator via cfe-commits]

sgatev accepted this revision.
sgatev added inline comments.



Comment at: 
clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h:15
+
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/DeclCXX.h"

This is unnecessary.



Comment at: clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp:49-55
+  if (const auto *Call = dyn_cast(Stmt))
+if (const auto *M = dyn_cast(Call->getDirectCallee()))
+  if (M->isStatic() && isCheckLikeMethod(CheckDecls, *M)) {
+// Logically, mark this branch as unreachable.
+Env.addToFlowCondition(Env.getBoolLiteralValue(false));
+return true;
+  }





Comment at: clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp:51
+if (const auto *M = dyn_cast(Call->getDirectCallee()))
+  if (M->isStatic() && isCheckLikeMethod(CheckDecls, *M)) {
+// Logically, mark this branch as unreachable.

Shouldn't this be part of `isCheckLikeMethod`?



Comment at: clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp:52
+  if (M->isStatic() && isCheckLikeMethod(CheckDecls, *M)) {
+// Logically, mark this branch as unreachable.
+Env.addToFlowCondition(Env.getBoolLiteralValue(false));





Comment at: clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp:57
+  return false;
+}
+} // namespace dataflow





Comment at: clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp:90
+
+static constexpr char BadChromiumCheckHeader[] = R"(
+namespace other {

Perhaps "Incorrect" instead of "Bad" and comment on what makes it incorrect?



Comment at: 
clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp:133
+  void runDataflow(llvm::StringRef Code, Matcher Match,
+   LangStandard::Kind Std = LangStandard::lang_cxx17) {
+const tooling::FileContentMappings FileContents = {

We're not testing with other standards so remove this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121797

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

[PATCH] D121754: [clang-format] Refactor determineStarAmpUsage

[sstwcw via Phabricator via cfe-commits]

sstwcw marked 5 inline comments as done.
sstwcw added inline comments.



Comment at: clang/lib/Format/TokenAnnotator.cpp:2146-2147
+//   know how they can be followed by a star or amp.
+// co_await, delete - It doesn't make sense to have them followed by a 
unary
+//   `+` or `-`.
+if (PrevToken->isOneOf(TT_ConditionalExpr, tok::l_paren, tok::comma,

MyDeveloperDay wrote:
> HazardyKnusperkeks wrote:
> > Especially here, why should a `+` after `delete` be a binary operator?
> > How much sense it makes doesn't matter, it is valid c++: 
> > https://gcc.godbolt.org/z/c1x1nn3Ej
> I'm also trying to understand did you mean you couldn't have
> 
> case -1:
> case +1:
> case +0:
> case  -0:
> 
> https://gcc.godbolt.org/z/qvE44d5xz
In the new version `+` following `delete` is a unary operator.  Previously I 
was under the impression that we only formatted code that is sensible.



Comment at: clang/lib/Format/TokenAnnotator.cpp:2146-2147
+//   know how they can be followed by a star or amp.
+// co_await, delete - It doesn't make sense to have them followed by a 
unary
+//   `+` or `-`.
+if (PrevToken->isOneOf(TT_ConditionalExpr, tok::l_paren, tok::comma,

sstwcw wrote:
> MyDeveloperDay wrote:
> > HazardyKnusperkeks wrote:
> > > Especially here, why should a `+` after `delete` be a binary operator?
> > > How much sense it makes doesn't matter, it is valid c++: 
> > > https://gcc.godbolt.org/z/c1x1nn3Ej
> > I'm also trying to understand did you mean you couldn't have
> > 
> > case -1:
> > case +1:
> > case +0:
> > case  -0:
> > 
> > https://gcc.godbolt.org/z/qvE44d5xz
> In the new version `+` following `delete` is a unary operator.  Previously I 
> was under the impression that we only formatted code that is sensible.
> case -1:
> case +1:

I meant we couldn't have things like `case *x` or `case &x`.  Is the comment 
not clear enough?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121754

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

[PATCH] D121992: [Clang] [Driver] Add option to set alternative toolchain path

[Qiu Chaofan via Phabricator via cfe-commits]

qiucf created this revision.
qiucf added reviewers: hubert.reinterpretcast, jsji, nemanjai, collinbaker, 
rpenacob.
Herald added a project: All.
qiucf requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

In some cases, we need to set alternative toolchain path other than the default 
with system (headers, libraries, dynamic linker prefix, `ld` path, etc.), but 
keep `sysroot` at the same time.

This patch introduces a new option `--overlay-platform-toolchain` to set up 
such alternative toolchain path.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121992

Files:
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/test/Driver/Inputs/powerpc64le-linux-gnu-tree/gcc-11.2.0/include/.keep
  clang/test/Driver/Inputs/powerpc64le-linux-gnu-tree/gcc-11.2.0/lib64/.keep
  clang/test/Driver/gcc-toolchain.cpp

Index: clang/test/Driver/gcc-toolchain.cpp
===
--- clang/test/Driver/gcc-toolchain.cpp
+++ clang/test/Driver/gcc-toolchain.cpp
@@ -37,3 +37,15 @@
 
 // AARCH64:Inputs{{[^"]+}}aarch64-suse-linux/{{[^"]+}}crt1.o"
 // NO_AARCH64-NOT: Inputs{{[^"]+}}aarch64-suse-linux/{{[^"]+}}crt1.o"
+
+/// Test option to add 'overlay platform toolchain'
+// RUN: %clangxx %s -### --target=powerpc64le-linux-gnu \
+// RUN:   --overlay-platform-toolchain=%S/Inputs/powerpc64le-linux-gnu-tree/gcc-11.2.0 \
+// RUN:   2>&1 | FileCheck %s --check-prefix=OVERLAY
+
+// OVERLAY: "-internal-externc-isystem"
+// OVERLAY: "[[TOOLCHAIN:[^"]+]]/powerpc64le-linux-gnu-tree/gcc-11.2.0/include"
+// OVERLAY: "-dynamic-linker"
+// OVERLAY: "[[TOOLCHAIN]]/powerpc64le-linux-gnu-tree/gcc-11.2.0/lib64/ld64.so.2"
+// OVERLAY: "-L[[TOOLCHAIN]]/powerpc64le-linux-gnu-tree/gcc-11.2.0/lib/../lib64"
+// OVERLAY: "-L[[TOOLCHAIN]]/powerpc64le-linux-gnu-tree/gcc-11.2.0/lib"
Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -261,6 +261,16 @@
   const std::string OSLibDir = std::string(getOSLibDir(Triple, Args));
   const std::string MultiarchTriple = getMultiarchTriple(D, Triple, SysRoot);
 
+  if (!D.OverlayToolChainPath.empty()) {
+const std::string &ExtraPath = D.OverlayToolChainPath;
+addPathIfExists(D, ExtraPath + "/lib/" + MultiarchTriple, Paths);
+addPathIfExists(D, ExtraPath + "/lib/../" + OSLibDir, Paths);
+addPathIfExists(D, ExtraPath + "/usr/lib/" + MultiarchTriple, Paths);
+addPathIfExists(D, ExtraPath + "/usr/lib/../" + OSLibDir, Paths);
+addPathIfExists(D, ExtraPath + "/lib", Paths);
+addPathIfExists(D, ExtraPath + "/usr/lib", Paths);
+  }
+
   // mips32: Debian multilib, we use /libo32, while in other case, /lib is
   // used. We need add both libo32 and /lib.
   if (Arch == llvm::Triple::mips || Arch == llvm::Triple::mipsel) {
@@ -567,6 +577,10 @@
   if (DriverArgs.hasArg(options::OPT_nostdlibinc))
 return;
 
+  if (!D.OverlayToolChainPath.empty())
+addExternCSystemInclude(DriverArgs, CC1Args,
+D.OverlayToolChainPath + "/include");
+
   // LOCAL_INCLUDE_DIR
   addSystemInclude(DriverArgs, CC1Args, SysRoot + "/usr/local/include");
   // TOOL_INCLUDE_DIR
Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -1867,6 +1867,10 @@
   if (A)
 return A->getValue();
 
+  if (const Arg *X = Args.getLastArg(
+  clang::driver::options::OPT__overlay_platform_toolchain_EQ))
+return X->getValue();
+
   // If we have a SysRoot, ignore GCC_INSTALL_PREFIX.
   // GCC_INSTALL_PREFIX specifies the gcc installation for the default
   // sysroot and is likely not valid with a different sysroot.
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -1208,6 +1208,11 @@
   CompilerPath = Split.second;
 }
   }
+  if (const Arg *A =
+  Args.getLastArg(options::OPT__overlay_platform_toolchain_EQ)) {
+OverlayToolChainPath = A->getValue();
+DyldPrefix = A->getValue();
+  }
   if (const Arg *A = Args.getLastArg(options::OPT__sysroot_EQ))
 SysRoot = A->getValue();
   if (const Arg *A = Args.getLastArg(options::OPT__dyld_prefix_EQ))
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -4178,6 +4178,8 @@
 def _output_class_directory : Separate<["--"], "output-class-directory">, Alias;
 def _output_EQ : Joined<["--"], "output=">, Alias;
 def _output : Separa

[PATCH] D121906: [clang-format] Indent import statements in JavaScript.

[sstwcw via Phabricator via cfe-commits]

sstwcw updated this revision to Diff 416456.
sstwcw added a comment.

use `isJavascript`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121906

Files:
  clang/lib/Format/ContinuationIndenter.cpp
  clang/lib/Format/UnwrappedLineFormatter.cpp
  clang/unittests/Format/FormatTestJS.cpp


Index: clang/unittests/Format/FormatTestJS.cpp
===
--- clang/unittests/Format/FormatTestJS.cpp
+++ clang/unittests/Format/FormatTestJS.cpp
@@ -1868,6 +1868,11 @@
   " myX} from 'm';");
   verifyFormat("import * as lib from 'some/module.js';");
   verifyFormat("var x = {import: 1};\nx.import = 2;");
+  // Ensure an import statement inside a block is at the correct level.
+  verifyFormat("function() {\n"
+   "  var x;\n"
+   "  import 'some/module.js';\n"
+   "}");
 
   verifyFormat("export function fn() {\n"
"  return 'fn';\n"
Index: clang/lib/Format/UnwrappedLineFormatter.cpp
===
--- clang/lib/Format/UnwrappedLineFormatter.cpp
+++ clang/lib/Format/UnwrappedLineFormatter.cpp
@@ -1431,8 +1431,10 @@
   if (Newlines)
 Indent = NewlineIndent;
 
-  // Preprocessor directives get indented before the hash only if specified
-  if (Style.IndentPPDirectives != FormatStyle::PPDIS_BeforeHash &&
+  // Preprocessor directives get indented before the hash only if specified. In
+  // Javascript import statements are indented like normal statements.
+  if (!Style.isJavaScript() &&
+  Style.IndentPPDirectives != FormatStyle::PPDIS_BeforeHash &&
   (Line.Type == LT_PreprocessorDirective ||
Line.Type == LT_ImportStatement))
 Indent = 0;
Index: clang/lib/Format/ContinuationIndenter.cpp
===
--- clang/lib/Format/ContinuationIndenter.cpp
+++ clang/lib/Format/ContinuationIndenter.cpp
@@ -623,9 +623,11 @@
 
   unsigned Spaces = Current.SpacesRequiredBefore + ExtraSpaces;
 
-  // Indent preprocessor directives after the hash if required.
+  // Indent preprocessor directives after the hash if required. In Javascript
+  // import statements are indented like normal statements.
   int PPColumnCorrection = 0;
-  if (Style.IndentPPDirectives == FormatStyle::PPDIS_AfterHash &&
+  if (!Style.isJavaScript() &&
+  Style.IndentPPDirectives == FormatStyle::PPDIS_AfterHash &&
   Previous.is(tok::hash) && State.FirstIndent > 0 &&
   (State.Line->Type == LT_PreprocessorDirective ||
State.Line->Type == LT_ImportStatement)) {


Index: clang/unittests/Format/FormatTestJS.cpp
===
--- clang/unittests/Format/FormatTestJS.cpp
+++ clang/unittests/Format/FormatTestJS.cpp
@@ -1868,6 +1868,11 @@
   " myX} from 'm';");
   verifyFormat("import * as lib from 'some/module.js';");
   verifyFormat("var x = {import: 1};\nx.import = 2;");
+  // Ensure an import statement inside a block is at the correct level.
+  verifyFormat("function() {\n"
+   "  var x;\n"
+   "  import 'some/module.js';\n"
+   "}");
 
   verifyFormat("export function fn() {\n"
"  return 'fn';\n"
Index: clang/lib/Format/UnwrappedLineFormatter.cpp
===
--- clang/lib/Format/UnwrappedLineFormatter.cpp
+++ clang/lib/Format/UnwrappedLineFormatter.cpp
@@ -1431,8 +1431,10 @@
   if (Newlines)
 Indent = NewlineIndent;
 
-  // Preprocessor directives get indented before the hash only if specified
-  if (Style.IndentPPDirectives != FormatStyle::PPDIS_BeforeHash &&
+  // Preprocessor directives get indented before the hash only if specified. In
+  // Javascript import statements are indented like normal statements.
+  if (!Style.isJavaScript() &&
+  Style.IndentPPDirectives != FormatStyle::PPDIS_BeforeHash &&
   (Line.Type == LT_PreprocessorDirective ||
Line.Type == LT_ImportStatement))
 Indent = 0;
Index: clang/lib/Format/ContinuationIndenter.cpp
===
--- clang/lib/Format/ContinuationIndenter.cpp
+++ clang/lib/Format/ContinuationIndenter.cpp
@@ -623,9 +623,11 @@
 
   unsigned Spaces = Current.SpacesRequiredBefore + ExtraSpaces;
 
-  // Indent preprocessor directives after the hash if required.
+  // Indent preprocessor directives after the hash if required. In Javascript
+  // import statements are indented like normal statements.
   int PPColumnCorrection = 0;
-  if (Style.IndentPPDirectives == FormatStyle::PPDIS_AfterHash &&
+  if (!Style.isJavaScript() &&
+  Style.IndentPPDirectives == FormatStyle::PPDIS_AfterHash &&
   Previous.is(tok::hash) && State.FirstIndent > 0 &&
   (State.Line->Type == LT_P

[PATCH] D121906: [clang-format] Indent import statements in JavaScript.

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added inline comments.



Comment at: clang/lib/Format/ContinuationIndenter.cpp:631
+  Style.IndentPPDirectives == FormatStyle::PPDIS_AfterHash &&
   Previous.is(tok::hash) && State.FirstIndent > 0 &&
   (State.Line->Type == LT_PreprocessorDirective ||

can I check? is this case really firing? i mean isn't it

`# import`

why would javascript be seeing that?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121906

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

[PATCH] D121907: [clang-format] Use an enum for context types.

[sstwcw via Phabricator via cfe-commits]

sstwcw updated this revision to Diff 416458.
sstwcw added a comment.

Remove comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121907

Files:
  clang/lib/Format/TokenAnnotator.cpp

Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -113,8 +113,8 @@
 Contexts.back().IsExpression = false;
 // If there's a template keyword before the opening angle bracket, this is a
 // template parameter, not an argument.
-Contexts.back().InTemplateArgument =
-Left->Previous && Left->Previous->isNot(tok::kw_template);
+if (Left->Previous && Left->Previous->isNot(tok::kw_template))
+  Contexts.back().ContextType = Context::TemplateArgument;
 
 if (Style.Language == FormatStyle::LK_Java &&
 CurrentToken->is(tok::question))
@@ -288,7 +288,7 @@
 } else if (OpeningParen.Previous &&
OpeningParen.Previous->is(TT_ForEachMacro)) {
   // The first argument to a foreach macro is a declaration.
-  Contexts.back().IsForEachMacro = true;
+  Contexts.back().ContextType = Context::ForEachMacro;
   Contexts.back().IsExpression = false;
 } else if (OpeningParen.Previous && OpeningParen.Previous->MatchingParen &&
OpeningParen.Previous->MatchingParen->is(TT_ObjCBlockLParen)) {
@@ -558,7 +558,7 @@
 bool CppArrayTemplates =
 Style.isCpp() && Parent && Parent->is(TT_TemplateCloser) &&
 (Contexts.back().CanBeExpression || Contexts.back().IsExpression ||
- Contexts.back().InTemplateArgument);
+ Contexts.back().ContextType == Context::TemplateArgument);
 
 bool IsCpp11AttributeSpecifier = isCpp11AttributeSpecifier(*Left) ||
  Contexts.back().InCpp11AttributeSpecifier;
@@ -803,7 +803,7 @@
 if (Style.AlignArrayOfStructures != FormatStyle::AIAS_None) {
   if (OpeningBrace.ParentBracket == tok::l_brace &&
   couldBeInStructArrayInitializer() && CommaCount > 0)
-Contexts.back().InStructArrayInitializer = true;
+Contexts.back().ContextType = Context::StructArrayInitializer;
 }
 next();
 return true;
@@ -1157,16 +1157,22 @@
   parseTemplateDeclaration();
   break;
 case tok::comma:
-  if (Contexts.back().InCtorInitializer)
+  switch (Contexts.back().ContextType) {
+  case Context::CtorInitializer:
 Tok->setType(TT_CtorInitializerComma);
-  else if (Contexts.back().InInheritanceList)
+break;
+  case Context::InheritanceList:
 Tok->setType(TT_InheritanceComma);
-  else if (Contexts.back().FirstStartOfName &&
-   (Contexts.size() == 1 || startsWithInitStatement(Line))) {
-Contexts.back().FirstStartOfName->PartOfMultiVariableDeclStmt = true;
-Line.IsMultiVariableDeclStmt = true;
+break;
+  default:
+if (Contexts.back().FirstStartOfName &&
+(Contexts.size() == 1 || startsWithInitStatement(Line))) {
+  Contexts.back().FirstStartOfName->PartOfMultiVariableDeclStmt = true;
+  Line.IsMultiVariableDeclStmt = true;
+}
+break;
   }
-  if (Contexts.back().IsForEachMacro)
+  if (Contexts.back().ContextType == Context::ForEachMacro)
 Contexts.back().IsExpression = true;
   break;
 case tok::identifier:
@@ -1411,7 +1417,7 @@
 }
 
 for (const auto &ctx : Contexts)
-  if (ctx.InStructArrayInitializer)
+  if (ctx.ContextType == Context::StructArrayInitializer)
 return LT_ArrayOfStructInitializer;
 
 return LT_Other;
@@ -1488,14 +1494,25 @@
 FormatToken *FirstObjCSelectorName = nullptr;
 FormatToken *FirstStartOfName = nullptr;
 bool CanBeExpression = true;
-bool InTemplateArgument = false;
-bool InCtorInitializer = false;
-bool InInheritanceList = false;
 bool CaretFound = false;
-bool IsForEachMacro = false;
 bool InCpp11AttributeSpecifier = false;
 bool InCSharpAttributeSpecifier = false;
-bool InStructArrayInitializer = false;
+enum {
+  Unknown,
+  // Like the part after `:` in a constructor.
+  //   Context(...) : IsExpression(IsExpression)
+  CtorInitializer,
+  // Like in the parentheses in a foreach.
+  ForEachMacro,
+  // Like the inheritance list in a class declaration.
+  //   class Input : public IO
+  InheritanceList,
+  // Like in the braced list.
+  //   int x[] = {};
+  StructArrayInitializer,
+  // Like in `static_cast`.
+  TemplateArgument,
+} ContextType = Unknown;
   };
 
   /// Puts a new \c Context onto the stack \c Contexts for the lifetime
@@ -1513,9 +1530,9 @@
 
 ~ScopedContextCreator() {
   if (P.Style.AlignArrayOfStructures != FormatStyle::AIAS_None) {

[PATCH] D121907: [clang-format] Use an enum for context types. NFC

[MyDeveloperDay via Phabricator via cfe-commits]

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

I think fundamentally this look ok? @curdeius and @owenpan I feel I want to bow 
to your better judgement.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121907

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

[PATCH] D121907: [clang-format] Use an enum for context types. NFC

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

Please wait for the other reviewers if you have commit access.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121907

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

[PATCH] D121955: [clang] NFC: Dead code removal in SemaDecl.cpp, CheckMultiVersionFunction().

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121955

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

[PATCH] D121957: [clang] NFC: Redundant code removal in SemaDecl.cpp, CheckTargetCausesMultiVersioning().

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121957

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

[PATCH] D121958: [clang] NFC: Remove forced type merging in multiversion function checks.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

You should fix the clang-format issues (I leave @erichkeane to sign off on this 
one, but it looks reasonable to me).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121958

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

[PATCH] D121960: [clang] NFC: Rename 'MVType' variables to 'MVKind' for consistency with their type.

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121960

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

[PATCH] D121497: Lex: add support for `{,u}i128` Microsoft extension

[Iain Sandoe via Phabricator via cfe-commits]

iains added a comment.

In D121497#3388870 , @aaron.ballman 
wrote:

> In D121497#3388024 , @compnerd 
> wrote:
>
>> I don't have an example module sadly.  It was something that I ran into with 
>> Swift code import the WinSDK module defined in 
>> https://github.com/apple/swift/blob/main/stdlib/public/Platform/winsdk.modulemap.
>
> Could this be the reproducer? https://godbolt.org/z/YbbMse9a4

For C++20 modules, the basic rejection of this code is correct; we told the 
compiler it was a module but the source is not a valid module file  (the first 
non-comment token needs to be  a module/expoert decl).
The diagnostic is not especially friendly - but it does not seem to me that the 
example involves any attempt to expand the macro - it is perhaps poor recovery 
from the initial error.

So, I m not sure if we've explained the original problem yet - or whether other 
modules "flavours" would permit a non-module directive to precede any valid one 
(I suspect that modules-ts has a more flexible allowance, where there is an 
implicit global module fragment)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121497

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

[PATCH] D121907: [clang-format] Use an enum for context types. NFC

[sstwcw via Phabricator via cfe-commits]

sstwcw marked 2 inline comments as done.
sstwcw added a comment.

In D121907#3390226 , @MyDeveloperDay 
wrote:

> So out of interest, what is the reason? my assumption is that you wanted to 
> add more for Verilog and you felt adding the extra bools was the wrong design 
> and its better an an enum

You are right.

>   bool InCpp11AttributeSpecifier = false;
>   bool InCSharpAttributeSpecifier = false;
>
> Does the fact that some aren't exclusive make you think its ok to split it 
> into enums and bools is ok?  (no real opinion just wondered what you and 
> others think?)

Does it make me think it's ok? Yes. Good? No. I am lazy and I chose this way 
which doesn't require examining those two options.




Comment at: clang/lib/Format/TokenAnnotator.cpp:116
 // template parameter, not an argument.
-Contexts.back().InTemplateArgument =
-Left->Previous && Left->Previous->isNot(tok::kw_template);
+if (Left->Previous && Left->Previous->isNot(tok::kw_template))
+  Contexts.back().ContextType = Context::TemplateArgument;

owenpan wrote:
> If this was bug, it should be in a separate patch with test cases added.
Sorry that the previous patch did not include more context.  Pun intended.  Now 
you can scroll up and see that the context was just initialized, so 
`InTemplateArgument` starts being false, so it didn't matter whether the 
original code was `InTemplateArgument = ...;` or `if (...) InTemplateArgument = 
true;`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121907

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

[PATCH] D121961: [clang] Produce a "multiversion" annotation in textual AST output.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Is there a need for this functionality? The text node dumper already dumps 
attributes associated with the function: https://godbolt.org/z/EbW8E74TT

If the change is necessary, it needs some test coverage (I'd recommend adding 
the test to the `clang/test/AST` directory).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121961

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

[PATCH] D121755: [clang-format] Join spaceRequiredBefore and spaceRequiredBetween

[sstwcw via Phabricator via cfe-commits]

sstwcw added a comment.

By the way, last time I used a breakpoint on `spaceRequiredBefore` and stepped 
until return.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121755

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

[PATCH] D121997: [clang][driver] Fix compilation database dump with multiple architectures

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 created this revision.
jansvoboda11 added reviewers: Bigcheese, dexonsmith, arphaman, jkorous.
Herald added a project: All.
jansvoboda11 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Command lines with multiple `-arch` arguments expand into multiple entries in 
the compilation database. However, the file writes are not appending, meaning 
subsequent writes end up overwriting the previous ones, resulting in garbled 
output.

This patch fixes that by always appending to the file.

rdar://90165004


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121997

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/compilation_database_multiarch.c


Index: clang/test/Driver/compilation_database_multiarch.c
===
--- /dev/null
+++ clang/test/Driver/compilation_database_multiarch.c
@@ -0,0 +1,6 @@
+// RUN: rm -rf %t && mkdir -p %t
+// RUN: %clang -c %s -o %t/out -arch x86_64 -arch arm64 -MJ 
%t/compilation_database.json
+// RUN: FileCheck --input-file=%t/compilation_database.json %s
+
+// CHECK:  { "directory": "{{.*}}", "file": "{{.*}}", "output": "{{.*}}", 
"arguments": [{{.*}} "--target=x86_64-apple-macosx12.0.0"]},
+// CHECK-NEXT: { "directory": "{{.*}}", "file": "{{.*}}", "output": "{{.*}}", 
"arguments": [{{.*}} "--target=arm64-apple-ios5.0.0"]},
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -2382,7 +2382,8 @@
   if (!CompilationDatabase) {
 std::error_code EC;
 auto File = std::make_unique(
-Filename, EC, llvm::sys::fs::OF_TextWithCRLF);
+Filename, EC,
+llvm::sys::fs::OF_TextWithCRLF | llvm::sys::fs::OF_Append);
 if (EC) {
   D.Diag(clang::diag::err_drv_compilationdatabase) << Filename
<< EC.message();


Index: clang/test/Driver/compilation_database_multiarch.c
===
--- /dev/null
+++ clang/test/Driver/compilation_database_multiarch.c
@@ -0,0 +1,6 @@
+// RUN: rm -rf %t && mkdir -p %t
+// RUN: %clang -c %s -o %t/out -arch x86_64 -arch arm64 -MJ %t/compilation_database.json
+// RUN: FileCheck --input-file=%t/compilation_database.json %s
+
+// CHECK:  { "directory": "{{.*}}", "file": "{{.*}}", "output": "{{.*}}", "arguments": [{{.*}} "--target=x86_64-apple-macosx12.0.0"]},
+// CHECK-NEXT: { "directory": "{{.*}}", "file": "{{.*}}", "output": "{{.*}}", "arguments": [{{.*}} "--target=arm64-apple-ios5.0.0"]},
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -2382,7 +2382,8 @@
   if (!CompilationDatabase) {
 std::error_code EC;
 auto File = std::make_unique(
-Filename, EC, llvm::sys::fs::OF_TextWithCRLF);
+Filename, EC,
+llvm::sys::fs::OF_TextWithCRLF | llvm::sys::fs::OF_Append);
 if (EC) {
   D.Diag(clang::diag::err_drv_compilationdatabase) << Filename
<< EC.message();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D121906: [clang-format] Indent import statements in JavaScript.

[sstwcw via Phabricator via cfe-commits]

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



Comment at: clang/lib/Format/ContinuationIndenter.cpp:631
+  Style.IndentPPDirectives == FormatStyle::PPDIS_AfterHash &&
   Previous.is(tok::hash) && State.FirstIndent > 0 &&
   (State.Line->Type == LT_PreprocessorDirective ||

MyDeveloperDay wrote:
> can I check? is this case really firing? i mean isn't it
> 
> `# import`
> 
> why would javascript be seeing that?
In Javascript import statements also need some special handling. So the line is 
intentionally labeled as LT_ImportStatement. In `AnnotatingParser::parseLine` 
there is this.
```
if (Style.isJavaScript() && CurrentToken->is(Keywords.kw_import))
  ImportStatement = true;
```
I don't know why the line type isn't printed in 
`TokenAnnotator::printDebugInfo`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121906

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

[PATCH] D121907: [clang-format] Use an enum for context types. NFC

[Owen Pan via Phabricator via cfe-commits]

owenpan accepted this revision.
owenpan added a comment.

LGTM. Any comments, @curdeius?




Comment at: clang/lib/Format/TokenAnnotator.cpp:116
 // template parameter, not an argument.
-Contexts.back().InTemplateArgument =
-Left->Previous && Left->Previous->isNot(tok::kw_template);
+if (Left->Previous && Left->Previous->isNot(tok::kw_template))
+  Contexts.back().ContextType = Context::TemplateArgument;

sstwcw wrote:
> owenpan wrote:
> > If this was bug, it should be in a separate patch with test cases added.
> Sorry that the previous patch did not include more context.  Pun intended.  
> Now you can scroll up and see that the context was just initialized, so 
> `InTemplateArgument` starts being false, so it didn't matter whether the 
> original code was `InTemplateArgument = ...;` or `if (...) InTemplateArgument 
> = true;`.
Got it. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121907

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

[clang] 33a9eac - [Clang] Support multiple attributes in a single pragma

[Egor Zhdan via cfe-commits]

Author: Egor Zhdan
Date: 2022-03-18T12:20:41Z
New Revision: 33a9eac6aaa495fce6fd9b17cd48aa57a95461e6

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

LOG: [Clang] Support multiple attributes in a single pragma

This adds support for multiple attributes in `#pragma clang attribute push`, 
for example:

```
```
or
```
```

Related attributes can now be applied with a single pragma, which makes it 
harder for developers to make an accidental error later when editing the code.

rdar://78269653

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

Added: 
clang/test/AST/pragma-multiple-attributes-declspec.cpp
clang/test/AST/pragma-multiple-attributes.cpp

Modified: 
clang/docs/LanguageExtensions.rst
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/AttrSubjectMatchRules.h
clang/include/clang/Basic/DiagnosticParseKinds.td
clang/lib/Parse/ParseDecl.cpp
clang/lib/Parse/ParsePragma.cpp
clang/test/FixIt/fixit-pragma-attribute.c
clang/test/FixIt/fixit-pragma-attribute.cpp
clang/test/Parser/pragma-attribute-declspec.cpp
clang/test/Parser/pragma-attribute.cpp

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index d670bf55eec98..685f834a8495a 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -4121,8 +4121,22 @@ The ``__declspec`` style syntax is also supported:
 
   #pragma clang attribute pop
 
-A single push directive accepts only one attribute regardless of the syntax
-used.
+A single push directive can contain multiple attributes, however, 
+only one syntax style can be used within a single directive:
+
+.. code-block:: c++
+
+  #pragma clang attribute push ([[noreturn, noinline]], apply_to = function)
+
+  void function1(); // The function now has the [[noreturn]] and [[noinline]] 
attributes
+
+  #pragma clang attribute pop
+  
+  #pragma clang attribute push (__attribute((noreturn, noinline)), apply_to = 
function)
+
+  void function2(); // The function now has the __attribute((noreturn)) and 
__attribute((noinline)) attributes
+
+  #pragma clang attribute pop
 
 Because multiple push directives can be nested, if you're writing a macro that
 expands to ``_Pragma("clang attribute")`` it's good hygiene (though not

diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 21531bf72cd5b..5ddec067bc22f 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -106,6 +106,8 @@ Attribute Changes in Clang
 - Statement attributes ``[[clang::noinline]]`` and  
``[[clang::always_inline]]``
   can be used to control inlining decisions at callsites.
 
+- ``#pragma clang attribute push`` now supports multiple attributes within a 
single directive.
+
 Windows Support
 ---
 

diff  --git a/clang/include/clang/Basic/AttrSubjectMatchRules.h 
b/clang/include/clang/Basic/AttrSubjectMatchRules.h
index 4a4c1a883cf42..e3dcb943e59d4 100644
--- a/clang/include/clang/Basic/AttrSubjectMatchRules.h
+++ b/clang/include/clang/Basic/AttrSubjectMatchRules.h
@@ -18,6 +18,9 @@ namespace attr {
 /// A list of all the recognized kinds of attributes.
 enum SubjectMatchRule {
 #define ATTR_MATCH_RULE(X, Spelling, IsAbstract) X,
+#include "clang/Basic/AttrSubMatchRulesList.inc"
+  SubjectMatchRule_Last = -1
+#define ATTR_MATCH_RULE(X, Spelling, IsAbstract) +1
 #include "clang/Basic/AttrSubMatchRulesList.inc"
 };
 

diff  --git a/clang/include/clang/Basic/DiagnosticParseKinds.td 
b/clang/include/clang/Basic/DiagnosticParseKinds.td
index 7af15f5504ff9..1640a75391831 100644
--- a/clang/include/clang/Basic/DiagnosticParseKinds.td
+++ b/clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -1237,8 +1237,6 @@ def err_pragma_attribute_extra_tokens_after_attribute : 
Error<
   "extra tokens after attribute in a '#pragma clang attribute push'">;
 def err_pragma_attribute_unsupported_attribute : Error<
   "attribute %0 is not supported by '#pragma clang attribute'">;
-def err_pragma_attribute_multiple_attributes : Error<
-  "more than one attribute specified in '#pragma clang attribute push'">;
 def err_pragma_attribute_expected_attribute_syntax : Error<
   "expected an attribute that is specified using the GNU, C++11 or 
'__declspec'"
   " syntax">;

diff  --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index 44a05eec4e350..135b2dfe54167 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -600,6 +600,8 @@ unsigned Parser::ParseClangAttributeArgs(
 bool Parser::ParseMicrosoftDeclSpecArgs(IdentifierInfo *AttrName,
 SourceLocation AttrNameLoc,
 ParsedAttributes &Attrs) {
+  unsigned ExistingAttrs = Attrs.size();
+
  

[PATCH] D121283: [Clang] Support multiple attributes in a single pragma

[Egor Zhdan via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG33a9eac6aaa4: [Clang] Support multiple attributes in a 
single pragma (authored by egorzhdan).

Changed prior to commit:
  https://reviews.llvm.org/D121283?vs=416279&id=416469#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121283

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/AttrSubjectMatchRules.h
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParsePragma.cpp
  clang/test/AST/pragma-multiple-attributes-declspec.cpp
  clang/test/AST/pragma-multiple-attributes.cpp
  clang/test/FixIt/fixit-pragma-attribute.c
  clang/test/FixIt/fixit-pragma-attribute.cpp
  clang/test/Parser/pragma-attribute-declspec.cpp
  clang/test/Parser/pragma-attribute.cpp

Index: clang/test/Parser/pragma-attribute.cpp
===
--- clang/test/Parser/pragma-attribute.cpp
+++ clang/test/Parser/pragma-attribute.cpp
@@ -154,9 +154,6 @@
 #pragma clang attribute push ([[gnu::abi_tag]], apply_to=any(function))
 #pragma clang attribute pop
 
-#pragma clang attribute push ([[clang::disable_tail_calls, noreturn]], apply_to = function) // expected-error {{more than one attribute specified in '#pragma clang attribute push'}}
-#pragma clang attribute push ([[clang::disable_tail_calls, noreturn]]) // expected-error {{more than one attribute specified in '#pragma clang attribute push'}}
-
 #pragma clang attribute push ([[gnu::abi_tag]], apply_to=namespace)
 #pragma clang attribute pop
 
@@ -210,3 +207,13 @@
 #pragma clang attribute push([[clang::uninitialized]], apply_to=any) // expected-error {{expected '('}}
 #pragma clang attribute push([[clang::uninitialized]], apply_to = any()) // expected-error {{expected an identifier that corresponds to an attribute subject rule}}
 // NB: neither of these need to be popped; they were never successfully pushed.
+
+#pragma clang attribute push ([[clang::disable_tail_calls, noreturn]], apply_to = function)
+#pragma clang attribute pop
+
+#pragma clang attribute push (__attribute__((disable_tail_calls, annotate("test"))), apply_to = function)
+#pragma clang attribute pop
+
+#pragma clang attribute push (__attribute__((disable_tail_calls,)), apply_to = function) // expected-error {{expected identifier that represents an attribute name}}
+
+#pragma clang attribute push ([[clang::disable_tail_calls, noreturn]]) // expected-error {{expected ','}}
Index: clang/test/Parser/pragma-attribute-declspec.cpp
===
--- clang/test/Parser/pragma-attribute-declspec.cpp
+++ clang/test/Parser/pragma-attribute-declspec.cpp
@@ -6,7 +6,8 @@
 
 #pragma clang attribute pop
 
-#pragma clang attribute push(__declspec(dllexport, dllimport), apply_to = function) // expected-error {{more than one attribute specified in '#pragma clang attribute push'}}
+#pragma clang attribute push(__declspec(dllexport, dllimport), apply_to = function)
+#pragma clang attribute pop
 
 #pragma clang attribute push(__declspec(align), apply_to = variable) // expected-error {{attribute 'align' is not supported by '#pragma clang attribute'}}
 
Index: clang/test/FixIt/fixit-pragma-attribute.cpp
===
--- clang/test/FixIt/fixit-pragma-attribute.cpp
+++ clang/test/FixIt/fixit-pragma-attribute.cpp
@@ -39,7 +39,7 @@
 #pragma clang attribute pop
 
 #pragma clang attribute push (__attribute__((abi_tag("a"
-// CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:60}:", apply_to = any(record(unless(is_union)), variable, function, namespace)"
+// CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:60}:", apply_to = any(function, namespace, record(unless(is_union)), variable)"
 #pragma clang attribute push (__attribute__((abi_tag("a"))) apply_to=function)
 // CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:60}:", "
 #pragma clang attribute push (__attribute__((abi_tag("a"))) = function)
@@ -48,36 +48,39 @@
 // CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:60}:", apply_to = "
 
 #pragma clang attribute push (__attribute__((abi_tag("a"))) 22)
-// CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:63}:", apply_to = any(record(unless(is_union)), variable, function, namespace)"
+// CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:63}:", apply_to = any(function, namespace, record(unless(is_union)), variable)"
 #pragma clang attribute push (__attribute__((abi_tag("a"))) function)
-// CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:69}:", apply_to = any(record(unless(is_union)), variable, function, namespace)"
+// CHECK: fix-it:{{.*}}:{[[@LINE-1]]:60-[[@LINE-1]]:69}:", apply_to = any(function, namespace, record(unless(is_union)), variable)"
 #pragma clang attribu

[PATCH] D117522: [clang-tidy] Add modernize-macro-to-enum check

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D117522#3390136 , 
@LegalizeAdulthood wrote:

> I think I've got all the changes incorporated, but I'm getting a test failure 
> so I haven't uploaded a new diff.
>
> Honestly, I don't understand the test failure output.  On Windows, the test 
> failure output is all mangled and
> difficult to interpret correctly as to what exactly is the problem, so I'm 
> still trying to figure it out.

If you're able to post the output you're getting, I can try to help psychically 
debug it.

> Improving the readability of the test failures is one of the things I would 
> like to address in a future change.
> I suspect it's only a problem on Windows as it seems most of the clang-tidy 
> devs are using unix?

FWIW, I use Windows almost exclusively. Also, clang-tidy is frequently 
integrated into people's CI pipelines so even folks on *nix can be impacted by 
the behavior on Windows in those cases. That said, I have no idea what the test 
failures look like or how likely they are to be hit, so it may be reasonable to 
improve in a follow-up.


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

https://reviews.llvm.org/D117522

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

[PATCH] D121283: [Clang] Support multiple attributes in a single pragma

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

The commit message got a bit mutilated: 
33a9eac6aaa495fce6fd9b17cd48aa57a95461e6 


Just FYI in case you didn't notice. In that case, update your commit workflow 
to make sure this doesn't happen next time :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121283

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

[PATCH] D121907: [clang-format] Use an enum for context types. NFC

[Marek Kurdej via Phabricator via cfe-commits]

curdeius accepted this revision.
curdeius added a comment.

I really like this change. Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121907

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

[PATCH] D121283: [Clang] Support multiple attributes in a single pragma

[Egor Zhdan via Phabricator via cfe-commits]

egorzhdan added a comment.

In D121283#3392137 , @thakis wrote:

> The commit message got a bit mutilated: 
> 33a9eac6aaa495fce6fd9b17cd48aa57a95461e6 
> 
>
> Just FYI in case you didn't notice. In that case, update your commit workflow 
> to make sure this doesn't happen next time :)

That's strange, I didn't notice this, thanks for the heads up.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121283

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

[PATCH] D121556: [randstruct] Add randomize structure layout support

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/AST/Randstruct.h:34
+
+extern std::string SEED;
+

void wrote:
> aaron.ballman wrote:
> > Doing this with a global variable is unfortunate; it could make things 
> > harder when we multithread the frontend. Can we solve this without a 
> > global? (And if not, does this global need to be a `ManagedStatic`?)
> Maybe this could be moved to `LangOpts`?
That's a really good idea, let's go with that approach.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:11543
+// Layout randomization warning.
+def cast_from_randomized_struct : Error<
+  "casting from randomized structure pointer type %0 to %1">;





Comment at: clang/lib/AST/Randstruct.cpp:99
+
+if (FD->isBitField() && !FD->isZeroLengthBitField(Context)) {
+  // Start a bitfield run if this is the first bitfield we have found.

void wrote:
> aaron.ballman wrote:
> > Oh cool, we do bit-field runs!
> > 
> > How should we handle anonymous bit-fields (if anything special should be 
> > done for them at all)? People usually use them for padding between 
> > bit-fields, so it's not clear to me how to treat them when randomizing.
> Good question! I'm not sure either. On one hand, I'm rather concerned about 
> changing bitfield order in general, but it appears to be something that GCC's 
> plugin does, so...
> 
Yeah, I was really surprised about bit-fields as well. I'm especially concerned 
that bit-fields which were [un]carefully straddling allocation unit boundaries 
might be rearranged such that subtle atomic bugs and whatnot will be exposed.

If we find these sort of concerns are valid in real world code, we may want to 
add a second command line option (off-by-default, perhaps) for enabling 
rearranging bit-fields. But for now, I think it's fine to follow GCC's lead 
here.



Comment at: clang/lib/AST/Randstruct.cpp:179
+
+  SmallVector RandomizedFields;
+

void wrote:
> aaron.ballman wrote:
> > This one seems a bit large to me; any reason not to use `16` again?
> The code above looks to apply mostly to bitfield runs. This is for all fields 
> in a structure. I assumed (without proof) that this will always be larger 
> than the bitfield runs. :-)
I think that's a safe assumption and it's probably not worth worrying about 
overly much. It's more that 16 bit-fields seemed like it would be large enough 
to cover most bit-fields in a class while still being "small", but 64 fields 
seems likely to be way larger than most structures will need and isn't very 
small.

That said, I don't have a strong feeling here and I think the numbers are 
defensible unless we measure something that says otherwise.



Comment at: clang/lib/Sema/AnalysisBasedWarnings.cpp:2503
+
+  // FIXME: Any way to get a handle to a RecordDecl struct here?
+  clang::randstruct::checkForBadCasts(S, AC);

void wrote:
> aaron.ballman wrote:
> > No, this function is only called when popping a function scope, and so the 
> > only declaration it has access to is the `FunctionDecl`. Or do I 
> > misunderstand the question?
> Sounds good to me. Is this the best place for this check then?
I'm not convinced it is the best place for it -- analysis-based warnings are 
typically ones that require a CFG to be analyzed and so they are only run once 
we know the function body itself is valid (they also typically require the user 
to manually enable the checks -- your check runs always, even if the user 
hasn't enabled struct randomization, so it walks a lot of ASTs it doesn't need 
to). Your check doesn't require a CFG at all and it seems like it can be done 
purely when building the AST. I think a better place for this checking is in 
SemaCast.cpp in the `CastOperation` class.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121556

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

[clang] 52cc65d - [OpenMPRuntime] Specify correct pointer type

[Nikita Popov via cfe-commits]

Author: Nikita Popov
Date: 2022-03-18T14:25:51+01:00
New Revision: 52cc65d4740992a29ae8375498c3b470f003de26

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

LOG: [OpenMPRuntime] Specify correct pointer type

Rather than specifying a dummy type in EmitLoadOfPointer() and
then casting it to the correct one, we should instead specify the
correct type and cast beforehand. Otherwise the computed alignment
will be incorrect.

Added: 


Modified: 
clang/lib/CodeGen/CGOpenMPRuntime.cpp
clang/test/OpenMP/distribute_parallel_for_reduction_task_codegen.cpp
clang/test/OpenMP/for_reduction_task_codegen.cpp
clang/test/OpenMP/master_taskloop_in_reduction_codegen.cpp
clang/test/OpenMP/master_taskloop_simd_in_reduction_codegen.cpp
clang/test/OpenMP/parallel_for_reduction_task_codegen.cpp
clang/test/OpenMP/parallel_master_reduction_task_codegen.cpp
clang/test/OpenMP/parallel_reduction_task_codegen.cpp
clang/test/OpenMP/parallel_sections_reduction_task_codegen.cpp
clang/test/OpenMP/reduction_implicit_map.cpp
clang/test/OpenMP/sections_reduction_task_codegen.cpp
clang/test/OpenMP/target_parallel_for_reduction_task_codegen.cpp
clang/test/OpenMP/target_parallel_reduction_task_codegen.cpp

clang/test/OpenMP/target_teams_distribute_parallel_for_reduction_task_codegen.cpp
clang/test/OpenMP/task_in_reduction_codegen.cpp
clang/test/OpenMP/taskloop_in_reduction_codegen.cpp
clang/test/OpenMP/taskloop_simd_in_reduction_codegen.cpp
clang/test/OpenMP/teams_distribute_parallel_for_reduction_task_codegen.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGOpenMPRuntime.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
index 1192d194f5865..840775308684b 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -5993,19 +5993,19 @@ static llvm::Value 
*emitReduceCombFunction(CodeGenModule &CGM,
   PrivateScope.addPrivate(
   LHSVD,
   // Pull out the pointer to the variable.
-  CGF.Builder.CreateElementBitCast(
-  CGF.EmitLoadOfPointer(
+  CGF.EmitLoadOfPointer(
+  CGF.Builder.CreateElementBitCast(
   CGF.GetAddrOfLocalVar(&ParamInOut),
-  C.getPointerType(C.VoidPtrTy).castAs()),
-  CGF.ConvertTypeForMem(LHSVD->getType(;
+  CGF.ConvertTypeForMem(LHSVD->getType())->getPointerTo()),
+  C.getPointerType(LHSVD->getType())->castAs()));
   PrivateScope.addPrivate(
   RHSVD,
   // Pull out the pointer to the variable.
-  CGF.Builder.CreateElementBitCast(
-  CGF.EmitLoadOfPointer(
-  CGF.GetAddrOfLocalVar(&ParamIn),
-  C.getPointerType(C.VoidPtrTy).castAs()),
-  CGF.ConvertTypeForMem(RHSVD->getType(;
+  CGF.EmitLoadOfPointer(
+  CGF.Builder.CreateElementBitCast(
+CGF.GetAddrOfLocalVar(&ParamIn),
+CGF.ConvertTypeForMem(RHSVD->getType())->getPointerTo()),
+  C.getPointerType(RHSVD->getType())->castAs()));
   PrivateScope.Privatize();
   // Emit the combiner body:
   // %2 = ( *%lhs,  *%rhs)

diff  --git 
a/clang/test/OpenMP/distribute_parallel_for_reduction_task_codegen.cpp 
b/clang/test/OpenMP/distribute_parallel_for_reduction_task_codegen.cpp
index 5b00d194d1be1..b2fbf617069ed 100644
--- a/clang/test/OpenMP/distribute_parallel_for_reduction_task_codegen.cpp
+++ b/clang/test/OpenMP/distribute_parallel_for_reduction_task_codegen.cpp
@@ -444,14 +444,14 @@ int main(int argc, char **argv) {
 // CHECK1-NEXT:[[DOTADDR1:%.*]] = alloca i8*, align 8
 // CHECK1-NEXT:store i8* [[TMP0]], i8** [[DOTADDR]], align 8
 // CHECK1-NEXT:store i8* [[TMP1]], i8** [[DOTADDR1]], align 8
-// CHECK1-NEXT:[[TMP2:%.*]] = load i8*, i8** [[DOTADDR]], align 8
-// CHECK1-NEXT:[[TMP3:%.*]] = bitcast i8* [[TMP2]] to i32*
-// CHECK1-NEXT:[[TMP4:%.*]] = load i8*, i8** [[DOTADDR1]], align 8
-// CHECK1-NEXT:[[TMP5:%.*]] = bitcast i8* [[TMP4]] to i32*
-// CHECK1-NEXT:[[TMP6:%.*]] = load i32, i32* [[TMP3]], align 8
-// CHECK1-NEXT:[[TMP7:%.*]] = load i32, i32* [[TMP5]], align 8
+// CHECK1-NEXT:[[TMP2:%.*]] = bitcast i8** [[DOTADDR]] to i32**
+// CHECK1-NEXT:[[TMP3:%.*]] = load i32*, i32** [[TMP2]], align 8
+// CHECK1-NEXT:[[TMP4:%.*]] = bitcast i8** [[DOTADDR1]] to i32**
+// CHECK1-NEXT:[[TMP5:%.*]] = load i32*, i32** [[TMP4]], align 8
+// CHECK1-NEXT:[[TMP6:%.*]] = load i32, i32* [[TMP3]], align 4
+// CHECK1-NEXT:[[TMP7:%.*]] = load i32, i32* [[TMP5]], align 4
 // CHECK1-NEXT:[[ADD:%.*]] = add nsw i32 [[TMP6]], [[TMP7]]
-// CHECK1-NEXT:store i32 [[ADD]], i32* [[TMP3]], align 8
+// CHECK1-NEXT:store i32 [[ADD]], i32* [[TMP3]], align 4
 // CHECK1-NEXT:ret void
 //
 //
@@ -1063,14 +1063,14 @@ int main

[PATCH] D121961: [clang] Produce a "multiversion" annotation in textual AST output.

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D121961#3391988 , @aaron.ballman 
wrote:

> Is there a need for this functionality? The text node dumper already dumps 
> attributes associated with the function: https://godbolt.org/z/EbW8E74TT
>
> If the change is necessary, it needs some test coverage (I'd recommend adding 
> the test to the `clang/test/AST` directory).

I would have found this helpful while working with MV functions in the past, 
particularly 'target' ones.  So there is perhaps some value and minimal harm to 
this.  That said, we definitely need a test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121961

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

[PATCH] D121797: [clang][dataflow] Add modeling of Chromium's CHECK functionality

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

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

address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121797

Files:
  clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h
  clang/lib/Analysis/FlowSensitive/Models/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp
  clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
  clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
===
--- /dev/null
+++ clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
@@ -0,0 +1,223 @@
+//===- ChromiumCheckModelTest.cpp -===//
+//
+// 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
+//
+//===--===//
+// FIXME: Move this to clang/unittests/Analysis/FlowSensitive/Models.
+
+#include "clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h"
+#include "NoopAnalysis.h"
+#include "TestingSupport.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Tooling/Tooling.h"
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Testing/Support/Error.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+#include 
+
+using namespace clang;
+using namespace dataflow;
+using namespace test;
+
+namespace {
+using ::testing::_;
+using ::testing::ElementsAre;
+using ::testing::NotNull;
+using ::testing::Pair;
+
+static constexpr char ChromiumCheckHeader[] = R"(
+namespace std {
+class ostream;
+} // namespace std
+
+namespace logging {
+class VoidifyStream {
+ public:
+  VoidifyStream() = default;
+  void operator&(std::ostream&) {}
+};
+
+class CheckError {
+ public:
+  static CheckError Check(const char* file, int line, const char* condition);
+  static CheckError DCheck(const char* file, int line, const char* condition);
+  static CheckError PCheck(const char* file, int line, const char* condition);
+  static CheckError PCheck(const char* file, int line);
+  static CheckError DPCheck(const char* file, int line, const char* condition);
+
+  std::ostream& stream();
+
+  ~CheckError();
+
+  CheckError(const CheckError& other) = delete;
+  CheckError& operator=(const CheckError& other) = delete;
+  CheckError(CheckError&& other) = default;
+  CheckError& operator=(CheckError&& other) = default;
+};
+
+} // namespace logging
+
+#define LAZY_CHECK_STREAM(stream, condition) \
+  !(condition) ? (void)0 : ::logging::VoidifyStream() & (stream)
+
+#define CHECK(condition) \
+  LAZY_CHECK_STREAM( \
+  ::logging::CheckError::Check(__FILE__, __LINE__, #condition).stream(), \
+  !(condition))
+
+#define PCHECK(condition) \
+  LAZY_CHECK_STREAM(  \
+  ::logging::CheckError::PCheck(__FILE__, __LINE__, #condition).stream(), \
+  !(condition))
+
+#define DCHECK(condition) \
+  LAZY_CHECK_STREAM(  \
+  ::logging::CheckError::DCheck(__FILE__, __LINE__, #condition).stream(), \
+  !(condition))
+
+#define DPCHECK(condition) \
+  LAZY_CHECK_STREAM(   \
+  ::logging::CheckError::DPCheck(__FILE__, __LINE__, #condition).stream(), \
+  !(condition))
+)";
+
+// A definition of the `CheckError` class that looks like the Chromium one, but
+// is actually something else.
+static constexpr char OtherCheckHeader[] = R"(
+namespace other {
+namespace logging {
+class CheckError {
+ public:
+  static CheckError Check(const char* file, int line, const char* condition);
+};
+} // namespace logging
+} // namespace other
+)";
+
+/// Replaces all occurrences of `Pattern` in `S` with `Replacement`.
+std::string ReplacePattern(std::string S, const std::string &Pattern,
+   const std::string &Replacement) {
+  size_t Pos = 0;
+  Pos = S.find(Pattern, Pos);
+  if (Pos != std::string::npos)
+S.replace(Pos, Pattern.size(), Replacement);
+  return S;
+}
+
+template 
+class ModelAdaptorAnalysis
+: public DataflowAnalysis, NoopLattice> {
+public:
+  explicit ModelAdaptorAnalysis(ASTContext &Context)
+  : DataflowAnalysis(
+Context, /*ApplyBuiltinTransfer=*/true)

[PATCH] D121678: [pseudo] Split greatergreater token.

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

We had the same thing happen downstream.  One of our guys speculates that 
because some allocations are "owned" by the returned TokenStream, but the 
returned TokenStream is a temporary, the lifetimes might not be sufficient and 
some deallocations can happen.
If I change the nested calls `stripComments(cook(lex(Code, Opts), Opts))` to 
separate calls stored to separate locals, the problem goes away.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121678

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

[PATCH] D121960: [clang] NFC: Rename 'MVType' variables to 'MVKind' for consistency with their type.

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

I'm ok with this, but please fix the clang-format before committed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121960

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

[PATCH] D121958: [clang] NFC: Remove forced type merging in multiversion function checks.

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

Hmm... my understanding is "MergeTypeWithPrevious" is important for cases where 
we decide that this is a redeclaration, right?  We need to set it to 'false' 
when we "know" that this is a different declaration, right?  So at least the 
'=false' was correct?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121958

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

[PATCH] D121829: [clang][AArc64][SVE] Implement vector-scalar operators

[David Truby via Phabricator via cfe-commits]

DavidTruby updated this revision to Diff 416487.
DavidTruby added a comment.

Fix non-valid operation diagnostics
Add correct float tests
Add negative tests for invalid types


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121829

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/CodeGen/aarch64-sve-vector-arith-ops.c
  clang/test/CodeGen/aarch64-sve-vector-bitwise-ops.c
  clang/test/Sema/aarch64-sve-vector-arith-ops.c

Index: clang/test/Sema/aarch64-sve-vector-arith-ops.c
===
--- clang/test/Sema/aarch64-sve-vector-arith-ops.c
+++ clang/test/Sema/aarch64-sve-vector-arith-ops.c
@@ -20,6 +20,12 @@
   (void)(i8 + f16); // expected-error{{invalid operands to binary expression}}
   (void)(i8 + f32); // expected-error{{invalid operands to binary expression}}
   (void)(i8 + f64); // expected-error{{invalid operands to binary expression}}
+  (void)(i8 + 0);   // expected-error{{invalid operands to binary expression}}
+  (void)(i8 + 0l);  // expected-error{{invalid operands to binary expression}}
+  (void)(i8 + 0u);  // expected-error{{invalid operands to binary expression}}
+  (void)(i8 + 0ul); // expected-error{{invalid operands to binary expression}}
+  (void)(i8 + 0.f); // expected-error{{invalid operands to binary expression}}
+  (void)(i8 + 0.);  // expected-error{{invalid operands to binary expression}}
 
   (void)(u8 + b);   // expected-error{{invalid operands to binary expression}}
   (void)(u8 + i16); // expected-error{{invalid operands to binary expression}}
@@ -31,6 +37,12 @@
   (void)(u8 + f16); // expected-error{{invalid operands to binary expression}}
   (void)(u8 + f32); // expected-error{{invalid operands to binary expression}}
   (void)(u8 + f64); // expected-error{{invalid operands to binary expression}}
+  (void)(u8 + 0);   // expected-error{{invalid operands to binary expression}}
+  (void)(u8 + 0l);  // expected-error{{invalid operands to binary expression}}
+  (void)(u8 + 0u);  // expected-error{{invalid operands to binary expression}}
+  (void)(u8 + 0ul); // expected-error{{invalid operands to binary expression}}
+  (void)(u8 + 0.f); // expected-error{{invalid operands to binary expression}}
+  (void)(u8 + 0.);  // expected-error{{invalid operands to binary expression}}
 
   (void)(i16 + b);   // expected-error{{invalid operands to binary expression}}
   (void)(i16 + i8);  // expected-error{{invalid operands to binary expression}}
@@ -42,6 +54,12 @@
   (void)(i16 + f16); // expected-error{{invalid operands to binary expression}}
   (void)(i16 + f32); // expected-error{{invalid operands to binary expression}}
   (void)(i16 + f64); // expected-error{{invalid operands to binary expression}}
+  (void)(i16 + 0);   // expected-error{{invalid operands to binary expression}}
+  (void)(i16 + 0l);  // expected-error{{invalid operands to binary expression}}
+  (void)(i16 + 0u);  // expected-error{{invalid operands to binary expression}}
+  (void)(i16 + 0ul); // expected-error{{invalid operands to binary expression}}
+  (void)(i16 + 0.f); // expected-error{{invalid operands to binary expression}}
+  (void)(i16 + 0.);  // expected-error{{invalid operands to binary expression}}
 
   (void)(u16 + b);   // expected-error{{invalid operands to binary expression}}
   (void)(u16 + i8);  // expected-error{{invalid operands to binary expression}}
@@ -53,6 +71,12 @@
   (void)(u16 + f16); // expected-error{{invalid operands to binary expression}}
   (void)(u16 + f32); // expected-error{{invalid operands to binary expression}}
   (void)(u16 + f64); // expected-error{{invalid operands to binary expression}}
+  (void)(u16 + 0);   // expected-error{{invalid operands to binary expression}}
+  (void)(u16 + 0l);  // expected-error{{invalid operands to binary expression}}
+  (void)(u16 + 0u);  // expected-error{{invalid operands to binary expression}}
+  (void)(u16 + 0ul); // expected-error{{invalid operands to binary expression}}
+  (void)(u16 + 0.f); // expected-error{{invalid operands to binary expression}}
+  (void)(u16 + 0.);  // expected-error{{invalid operands to binary expression}}
 
   (void)(i32 + b);   // expected-error{{invalid operands to binary expression}}
   (void)(i32 + i8);  // expected-error{{invalid operands to binary expression}}
@@ -64,6 +88,11 @@
   (void)(i32 + f16); // expected-error{{invalid operands to binary expression}}
   (void)(i32 + f32); // expected-error{{invalid operands to binary expression}}
   (void)(i32 + f64); // expected-error{{invalid operands to binary expression}}
+  (void)(i32 + 0l);  // expected-error{{invalid operands to binary expression}}
+  (void)(i32 + 0u);  // expected-error{{invalid operands to binary expression}}
+  (void)(i32 + 0ul); // expected-error{{invalid operands to binary expression}}
+  (void)(i32 + 0.f); // expected-error{{invalid operands to 

[PATCH] D121954: [clang] Add test cases for multiversion function overload scenarios in C.

[Erich Keane via Phabricator via cfe-commits]

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

These all look like fine tests to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121954

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

[PATCH] D121959: [clang] Add missing diagnostics for invalid overloads of multiversion functions in C.

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D121959#3390658 , @tahonermann 
wrote:

> Intel issue CMPLRLLVM-28177.

These words have no power here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121959

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

[clang] b6baab6 - [clang-format] Refactor BreakableBlockComment constructor. NFC.

[Marek Kurdej via cfe-commits]

Author: Marek Kurdej
Date: 2022-03-18T15:01:40+01:00
New Revision: b6baab673a7c17747c245fa7b33d9b29ad9a107d

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

LOG: [clang-format] Refactor BreakableBlockComment constructor. NFC.

Added: 


Modified: 
clang/lib/Format/BreakableToken.cpp

Removed: 




diff  --git a/clang/lib/Format/BreakableToken.cpp 
b/clang/lib/Format/BreakableToken.cpp
index ae084e9e14544..db7361bf5f2ff 100644
--- a/clang/lib/Format/BreakableToken.cpp
+++ b/clang/lib/Format/BreakableToken.cpp
@@ -410,11 +410,13 @@ BreakableBlockComment::BreakableBlockComment(
   }
   for (size_t i = 1, e = Content.size(); i < e && !Decoration.empty(); ++i) {
 const StringRef &Text = Content[i];
-// If the last line is empty, the closing "*/" will have a star.
-if (i + 1 == e && Text.empty())
-  break;
-if (!Text.empty() && i + 1 != e && Decoration.startswith(Text))
+if (i + 1 == e) {
+  // If the last line is empty, the closing "*/" will have a star.
+  if (Text.empty())
+break;
+} else if (!Text.empty() && Decoration.startswith(Text)) {
   continue;
+}
 while (!Text.startswith(Decoration))
   Decoration = Decoration.drop_back(1);
   }



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

[clang] acc7a7f - [clang-format] Use range-for loop. NFC.

[Marek Kurdej via cfe-commits]

Author: Marek Kurdej
Date: 2022-03-18T15:01:41+01:00
New Revision: acc7a7f9a17f683b1bbf0a4913ebadb926e1f71b

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

LOG: [clang-format] Use range-for loop. NFC.

Added: 


Modified: 
clang/lib/Format/TokenAnnotator.cpp

Removed: 




diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index 9c94590dc0b9a..b0d48c46340a6 100644
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -4601,8 +4601,8 @@ void TokenAnnotator::printDebugInfo(const AnnotatedLine 
&Line) {
  << " BK=" << Tok->getBlockKind() << " P=" << Tok->SplitPenalty
  << " Name=" << Tok->Tok.getName() << " L=" << Tok->TotalLength
  << " PPK=" << Tok->getPackingKind() << " FakeLParens=";
-for (unsigned i = 0, e = Tok->FakeLParens.size(); i != e; ++i)
-  llvm::errs() << Tok->FakeLParens[i] << "/";
+for (prec::Level LParen : Tok->FakeLParens)
+  llvm::errs() << LParen << "/";
 llvm::errs() << " FakeRParens=" << Tok->FakeRParens;
 llvm::errs() << " II=" << Tok->Tok.getIdentifierInfo();
 llvm::errs() << " Text='" << Tok->TokenText << "'\n";



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

[clang] c79e18d - [clang-format] Expect instead of setting the same value in tests. NFC.

[Marek Kurdej via cfe-commits]

Author: Marek Kurdej
Date: 2022-03-18T15:01:41+01:00
New Revision: c79e18da4f65c43bb8d94e95961e87e66d67b65a

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

LOG: [clang-format] Expect instead of setting the same value in tests. NFC.

Added: 


Modified: 
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index 4ef4c9a8612a7..e36a267c01f4b 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -2767,7 +2767,8 @@ TEST_F(FormatTest, CaseRanges) {
 
 TEST_F(FormatTest, ShortEnums) {
   FormatStyle Style = getLLVMStyle();
-  Style.AllowShortEnumsOnASingleLine = true;
+  EXPECT_TRUE(Style.AllowShortEnumsOnASingleLine);
+  EXPECT_FALSE(Style.BraceWrapping.AfterEnum);
   verifyFormat("enum { A, B, C } ShortEnum1, ShortEnum2;", Style);
   verifyFormat("typedef enum { A, B, C } ShortEnum1, ShortEnum2;", Style);
   Style.AllowShortEnumsOnASingleLine = false;



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

[clang] 4b3a27e - Add validation for number of arguments of __builtin_memcpy_inline

[Guillaume Chatelet via cfe-commits]

Author: Roy Jacobson
Date: 2022-03-18T14:03:25Z
New Revision: 4b3a27e2e026f9be703c1bdcb396c10559a87347

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

LOG: Add validation for number of arguments of __builtin_memcpy_inline

__builtin_memcpy_inline doesn't use the usual builtin argument validation code,
so it crashed when receiving wrong number of argument. Add the missing 
validation
check.

Open issue: https://github.com/llvm/llvm-project/issues/52949

Reviewed By: gchatelet

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

Committed by gchatelet on behalf of "Roy Jacobson "

Added: 


Modified: 
clang/lib/Sema/SemaChecking.cpp
clang/test/Sema/builtins-memcpy-inline.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 2d2250771eb6e..e02104b4699e1 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -1679,7 +1679,10 @@ Sema::CheckBuiltinFunctionCall(FunctionDecl *FDecl, 
unsigned BuiltinID,
 if ((ICEArguments & (1 << ArgNo)) == 0) continue;
 
 llvm::APSInt Result;
-if (SemaBuiltinConstantArg(TheCall, ArgNo, Result))
+// If we don't have enough arguments, continue so we can issue better
+// diagnostic in checkArgCount(...)
+if (ArgNo < TheCall->getNumArgs() &&
+SemaBuiltinConstantArg(TheCall, ArgNo, Result))
   return true;
 ICEArguments &= ~(1 << ArgNo);
   }
@@ -1943,6 +1946,8 @@ Sema::CheckBuiltinFunctionCall(FunctionDecl *FDecl, 
unsigned BuiltinID,
   case Builtin::BI__builtin_nontemporal_store:
 return SemaBuiltinNontemporalOverloaded(TheCallResult);
   case Builtin::BI__builtin_memcpy_inline: {
+if (checkArgCount(*this, TheCall, 3))
+  return ExprError();
 auto ArgArrayConversionFailed = [&](unsigned Arg) {
   ExprResult ArgExpr =
   DefaultFunctionArrayLvalueConversion(TheCall->getArg(Arg));

diff  --git a/clang/test/Sema/builtins-memcpy-inline.cpp 
b/clang/test/Sema/builtins-memcpy-inline.cpp
index 30bc636c78393..ab0a8700a6c98 100644
--- a/clang/test/Sema/builtins-memcpy-inline.cpp
+++ b/clang/test/Sema/builtins-memcpy-inline.cpp
@@ -42,3 +42,8 @@ void test_memcpy_inline_implicit_conversion(void *ptr) {
   __builtin_memcpy_inline(ptr, a, 5);
   __builtin_memcpy_inline(a, ptr, 5);
 }
+
+void test_memcpy_inline_num_args(void *dst, void *src) {
+ __builtin_memcpy_inline(); // expected-error {{too few arguments to function 
call}}
+ __builtin_memcpy_inline(dst, src, 4, NULL); // expected-error {{too many 
arguments to function call}}
+}



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

[PATCH] D121965: Add validation for number of arguments of __builtin_memcpy_inline

[Guillaume Chatelet via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4b3a27e2e026: Add validation for number of arguments of 
__builtin_memcpy_inline (authored by royjacobson, committed by gchatelet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121965

Files:
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Sema/builtins-memcpy-inline.cpp


Index: clang/test/Sema/builtins-memcpy-inline.cpp
===
--- clang/test/Sema/builtins-memcpy-inline.cpp
+++ clang/test/Sema/builtins-memcpy-inline.cpp
@@ -42,3 +42,8 @@
   __builtin_memcpy_inline(ptr, a, 5);
   __builtin_memcpy_inline(a, ptr, 5);
 }
+
+void test_memcpy_inline_num_args(void *dst, void *src) {
+ __builtin_memcpy_inline(); // expected-error {{too few arguments to function 
call}}
+ __builtin_memcpy_inline(dst, src, 4, NULL); // expected-error {{too many 
arguments to function call}}
+}
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -1679,7 +1679,10 @@
 if ((ICEArguments & (1 << ArgNo)) == 0) continue;
 
 llvm::APSInt Result;
-if (SemaBuiltinConstantArg(TheCall, ArgNo, Result))
+// If we don't have enough arguments, continue so we can issue better
+// diagnostic in checkArgCount(...)
+if (ArgNo < TheCall->getNumArgs() &&
+SemaBuiltinConstantArg(TheCall, ArgNo, Result))
   return true;
 ICEArguments &= ~(1 << ArgNo);
   }
@@ -1943,6 +1946,8 @@
   case Builtin::BI__builtin_nontemporal_store:
 return SemaBuiltinNontemporalOverloaded(TheCallResult);
   case Builtin::BI__builtin_memcpy_inline: {
+if (checkArgCount(*this, TheCall, 3))
+  return ExprError();
 auto ArgArrayConversionFailed = [&](unsigned Arg) {
   ExprResult ArgExpr =
   DefaultFunctionArrayLvalueConversion(TheCall->getArg(Arg));


Index: clang/test/Sema/builtins-memcpy-inline.cpp
===
--- clang/test/Sema/builtins-memcpy-inline.cpp
+++ clang/test/Sema/builtins-memcpy-inline.cpp
@@ -42,3 +42,8 @@
   __builtin_memcpy_inline(ptr, a, 5);
   __builtin_memcpy_inline(a, ptr, 5);
 }
+
+void test_memcpy_inline_num_args(void *dst, void *src) {
+ __builtin_memcpy_inline(); // expected-error {{too few arguments to function call}}
+ __builtin_memcpy_inline(dst, src, 4, NULL); // expected-error {{too many arguments to function call}}
+}
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -1679,7 +1679,10 @@
 if ((ICEArguments & (1 << ArgNo)) == 0) continue;
 
 llvm::APSInt Result;
-if (SemaBuiltinConstantArg(TheCall, ArgNo, Result))
+// If we don't have enough arguments, continue so we can issue better
+// diagnostic in checkArgCount(...)
+if (ArgNo < TheCall->getNumArgs() &&
+SemaBuiltinConstantArg(TheCall, ArgNo, Result))
   return true;
 ICEArguments &= ~(1 << ArgNo);
   }
@@ -1943,6 +1946,8 @@
   case Builtin::BI__builtin_nontemporal_store:
 return SemaBuiltinNontemporalOverloaded(TheCallResult);
   case Builtin::BI__builtin_memcpy_inline: {
+if (checkArgCount(*this, TheCall, 3))
+  return ExprError();
 auto ArgArrayConversionFailed = [&](unsigned Arg) {
   ExprResult ArgExpr =
   DefaultFunctionArrayLvalueConversion(TheCall->getArg(Arg));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D121959: [clang] Add missing diagnostics for invalid overloads of multiversion functions in C.

[Erich Keane via Phabricator via cfe-commits]

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

Generally looks fine to me.  Just 1 test that looks suspicious.




Comment at: clang/test/Sema/attr-cpuspecific.c:133
 
-// FIXME: Declaration of a non-overloadable function when more than one
-// FIXME: multiversion function declarations are present results in an
-// FIXME: assertion failure.
 int __attribute__((cpu_dispatch(generic))) bad_overload3(void);
 int __attribute__((cpu_specific(ivybridge))) bad_overload3(void);

In what way is this test different than bad_overload1?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121959

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

[PATCH] D121797: [clang][dataflow] Add modeling of Chromium's CHECK functionality

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel updated this revision to Diff 416494.
ymandel marked 6 inline comments as done.
ymandel added a comment.

address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121797

Files:
  clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h
  clang/lib/Analysis/FlowSensitive/Models/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp
  clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
  clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
===
--- /dev/null
+++ clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
@@ -0,0 +1,219 @@
+//===- ChromiumCheckModelTest.cpp -===//
+//
+// 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
+//
+//===--===//
+// FIXME: Move this to clang/unittests/Analysis/FlowSensitive/Models.
+
+#include "clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h"
+#include "NoopAnalysis.h"
+#include "TestingSupport.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Tooling/Tooling.h"
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Testing/Support/Error.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+#include 
+
+using namespace clang;
+using namespace dataflow;
+using namespace test;
+
+namespace {
+using ::testing::_;
+using ::testing::ElementsAre;
+using ::testing::NotNull;
+using ::testing::Pair;
+
+static constexpr char ChromiumCheckHeader[] = R"(
+namespace std {
+class ostream;
+} // namespace std
+
+namespace logging {
+class VoidifyStream {
+ public:
+  VoidifyStream() = default;
+  void operator&(std::ostream&) {}
+};
+
+class CheckError {
+ public:
+  static CheckError Check(const char* file, int line, const char* condition);
+  static CheckError DCheck(const char* file, int line, const char* condition);
+  static CheckError PCheck(const char* file, int line, const char* condition);
+  static CheckError PCheck(const char* file, int line);
+  static CheckError DPCheck(const char* file, int line, const char* condition);
+
+  std::ostream& stream();
+
+  ~CheckError();
+
+  CheckError(const CheckError& other) = delete;
+  CheckError& operator=(const CheckError& other) = delete;
+  CheckError(CheckError&& other) = default;
+  CheckError& operator=(CheckError&& other) = default;
+};
+
+} // namespace logging
+
+#define LAZY_CHECK_STREAM(stream, condition) \
+  !(condition) ? (void)0 : ::logging::VoidifyStream() & (stream)
+
+#define CHECK(condition) \
+  LAZY_CHECK_STREAM( \
+  ::logging::CheckError::Check(__FILE__, __LINE__, #condition).stream(), \
+  !(condition))
+
+#define PCHECK(condition) \
+  LAZY_CHECK_STREAM(  \
+  ::logging::CheckError::PCheck(__FILE__, __LINE__, #condition).stream(), \
+  !(condition))
+
+#define DCHECK(condition) \
+  LAZY_CHECK_STREAM(  \
+  ::logging::CheckError::DCheck(__FILE__, __LINE__, #condition).stream(), \
+  !(condition))
+
+#define DPCHECK(condition) \
+  LAZY_CHECK_STREAM(   \
+  ::logging::CheckError::DPCheck(__FILE__, __LINE__, #condition).stream(), \
+  !(condition))
+)";
+
+// A definition of the `CheckError` class that looks like the Chromium one, but
+// is actually something else.
+static constexpr char OtherCheckHeader[] = R"(
+namespace other {
+namespace logging {
+class CheckError {
+ public:
+  static CheckError Check(const char* file, int line, const char* condition);
+};
+} // namespace logging
+} // namespace other
+)";
+
+/// Replaces all occurrences of `Pattern` in `S` with `Replacement`.
+std::string ReplacePattern(std::string S, const std::string &Pattern,
+   const std::string &Replacement) {
+  size_t Pos = 0;
+  Pos = S.find(Pattern, Pos);
+  if (Pos != std::string::npos)
+S.replace(Pos, Pattern.size(), Replacement);
+  return S;
+}
+
+template 
+class ModelAdaptorAnalysis
+: public DataflowAnalysis, NoopLattice> {
+public:
+  explicit ModelAdaptorAnalysis(ASTContext &Context)
+  : DataflowAnalysis(
+Context, /*ApplyBuiltinTransfer=*/true)

[clang] f47e7e4 - [clang][SVE] Add support for bitwise operators on SVE types

[David Truby via cfe-commits]

Author: David Truby
Date: 2022-03-18T14:06:47Z
New Revision: f47e7e4a3480707f124db9622001d3a05a777d5d

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

LOG: [clang][SVE] Add support for bitwise operators on SVE types

This patch implements support for the &, |, ^, and ~ operators on sizeless SVE
types.

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

Added: 
clang/test/CodeGen/aarch64-sve-vector-arith-ops.c
clang/test/CodeGen/aarch64-sve-vector-bitwise-ops.c
clang/test/Sema/aarch64-sve-vector-arith-ops.c
clang/test/Sema/aarch64-sve-vector-bitwise-ops.c

Modified: 
clang/include/clang/Sema/Sema.h
clang/lib/AST/Type.cpp
clang/lib/Sema/SemaExpr.cpp
clang/test/Sema/attr-arm-sve-vector-bits.c
clang/test/Sema/sizeless-1.c
clang/test/SemaCXX/sizeless-1.cpp

Removed: 
clang/test/CodeGen/aarch64-sve-vector-ops.c
clang/test/Sema/aarch64-sve-vector-ops.c



diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index fe8a1f371fe74..32a8ffdc8df92 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -11948,7 +11948,8 @@ class Sema final {
 
   // type checking for sizeless vector binary operators.
   QualType CheckSizelessVectorOperands(ExprResult &LHS, ExprResult &RHS,
-   SourceLocation Loc);
+   SourceLocation Loc,
+   ArithConvKind OperationKind);
 
   /// Type checking for matrix binary operators.
   QualType CheckMatrixElementwiseOperands(ExprResult &LHS, ExprResult &RHS,

diff  --git a/clang/lib/AST/Type.cpp b/clang/lib/AST/Type.cpp
index 08a95669ac9fd..1803fe12d69c8 100644
--- a/clang/lib/AST/Type.cpp
+++ b/clang/lib/AST/Type.cpp
@@ -1899,8 +1899,14 @@ bool Type::hasAutoForTrailingReturnType() const {
 bool Type::hasIntegerRepresentation() const {
   if (const auto *VT = dyn_cast(CanonicalType))
 return VT->getElementType()->isIntegerType();
-  else
-return isIntegerType();
+  if (CanonicalType->isVLSTBuiltinType()) {
+const auto *VT = cast(CanonicalType);
+return VT->getKind() == BuiltinType::SveBool ||
+   (VT->getKind() >= BuiltinType::SveInt8 &&
+VT->getKind() <= BuiltinType::SveUint64);
+  }
+
+  return isIntegerType();
 }
 
 /// Determine whether this type is an integral type.

diff  --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index 635721b4cc3b3..be90c58e066d8 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -10464,7 +10464,8 @@ QualType Sema::CheckVectorOperands(ExprResult &LHS, 
ExprResult &RHS,
 }
 
 QualType Sema::CheckSizelessVectorOperands(ExprResult &LHS, ExprResult &RHS,
-   SourceLocation Loc) {
+   SourceLocation Loc,
+   ArithConvKind OperationKind) {
   QualType LHSType = LHS.get()->getType().getUnqualifiedType();
   QualType RHSType = RHS.get()->getType().getUnqualifiedType();
 
@@ -10472,7 +10473,8 @@ QualType Sema::CheckSizelessVectorOperands(ExprResult 
&LHS, ExprResult &RHS,
   const BuiltinType *RHSVecType = RHSType->getAs();
 
   unsigned DiagID = diag::err_typecheck_invalid_operands;
-  if (LHSVecType->isSVEBool() || RHSVecType->isSVEBool()) {
+  if ((OperationKind == ACK_Arithmetic) &&
+  (LHSVecType->isSVEBool() || RHSVecType->isSVEBool())) {
 Diag(Loc, DiagID) << LHSType << RHSType << LHS.get()->getSourceRange()
   << RHS.get()->getSourceRange();
 return QualType();
@@ -10600,7 +10602,7 @@ QualType Sema::CheckMultiplyDivideOperands(ExprResult 
&LHS, ExprResult &RHS,
/*AllowBooleanOperation*/ false,
/*ReportInvalid*/ true);
   if (LHSTy->isVLSTBuiltinType() || RHSTy->isVLSTBuiltinType())
-return CheckSizelessVectorOperands(LHS, RHS, Loc);
+return CheckSizelessVectorOperands(LHS, RHS, Loc, ACK_Arithmetic);
   if (!IsDiv &&
   (LHSTy->isConstantMatrixType() || RHSTy->isConstantMatrixType()))
 return CheckMatrixMultiplyOperands(LHS, RHS, Loc, IsCompAssign);
@@ -10650,7 +10652,7 @@ QualType Sema::CheckRemainderOperands(
 ->getType()
 ->getSveEltType(Context)
 ->hasIntegerRepresentation())
-  return CheckSizelessVectorOperands(LHS, RHS, Loc);
+  return CheckSizelessVectorOperands(LHS, RHS, Loc, ACK_Arithmetic);
 
 return InvalidOperands(Loc, LHS, RHS);
   }
@@ -10964,7 +10966,8 @@ QualType Sema::CheckAdditionOperands(ExprResult &LHS, 
ExprResult &RHS,
 
   if (LHS.get()->getType()->isVLSTBuiltinType() ||
   RHS.get()->getType()->isVLSTBuiltinType()) {
-QualType compType = CheckSizeles

[PATCH] D121119: [clang][SVE] Add support for bitwise operators on SVE types

[David Truby via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGf47e7e4a3480: [clang][SVE] Add support for bitwise operators 
on SVE types (authored by DavidTruby).

Changed prior to commit:
  https://reviews.llvm.org/D121119?vs=415858&id=416496#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121119

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Type.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/CodeGen/aarch64-sve-vector-arith-ops.c
  clang/test/CodeGen/aarch64-sve-vector-bitwise-ops.c
  clang/test/CodeGen/aarch64-sve-vector-ops.c
  clang/test/Sema/aarch64-sve-vector-arith-ops.c
  clang/test/Sema/aarch64-sve-vector-bitwise-ops.c
  clang/test/Sema/aarch64-sve-vector-ops.c
  clang/test/Sema/attr-arm-sve-vector-bits.c
  clang/test/Sema/sizeless-1.c
  clang/test/SemaCXX/sizeless-1.cpp

Index: clang/test/SemaCXX/sizeless-1.cpp
===
--- clang/test/SemaCXX/sizeless-1.cpp
+++ clang/test/SemaCXX/sizeless-1.cpp
@@ -205,15 +205,11 @@
   -init_int8;   // expected-error {{invalid argument type 'svint8_t'}}
   --init_int8;  // expected-error {{cannot decrement value of type 'svint8_t'}}
   init_int8--;  // expected-error {{cannot decrement value of type 'svint8_t'}}
-  ~init_int8;   // expected-error {{invalid argument type 'svint8_t'}}
   !init_int8;   // expected-error {{invalid argument type 'svint8_t'}}
   *init_int8;   // expected-error {{indirection requires pointer operand}}
   __real init_int8; // expected-error {{invalid type 'svint8_t'}}
   __imag init_int8; // expected-error {{invalid type 'svint8_t'}}
 
-  local_int8 &init_int8;   // expected-error {{invalid operands to binary expression}}
-  local_int8 | init_int8;  // expected-error {{invalid operands to binary expression}}
-  local_int8 ^ init_int8;  // expected-error {{invalid operands to binary expression}}
   local_int8 << init_int8; // expected-error {{invalid operands to binary expression}}
   local_int8 >> init_int8; // expected-error {{invalid operands to binary expression}}
   local_int8 < init_int8;  // expected-error {{invalid operands to binary expression}}
@@ -225,9 +221,6 @@
   local_int8 &&init_int8;  // expected-error {{invalid operands to binary expression}} expected-error {{not contextually convertible}}
   local_int8 || init_int8; // expected-error {{invalid operands to binary expression}} expected-error {{not contextually convertible}}
 
-  local_int8 &= init_int8;  // expected-error {{invalid operands to binary expression}}
-  local_int8 |= init_int8;  // expected-error {{invalid operands to binary expression}}
-  local_int8 ^= init_int8;  // expected-error {{invalid operands to binary expression}}
   local_int8 <<= init_int8; // expected-error {{invalid operands to binary expression}}
   local_int8 >>= init_int8; // expected-error {{invalid operands to binary expression}}
 
Index: clang/test/Sema/sizeless-1.c
===
--- clang/test/Sema/sizeless-1.c
+++ clang/test/Sema/sizeless-1.c
@@ -193,15 +193,11 @@
   -init_int8;   // expected-error {{invalid argument type 'svint8_t'}}
   --init_int8;  // expected-error {{cannot decrement value of type 'svint8_t'}}
   init_int8--;  // expected-error {{cannot decrement value of type 'svint8_t'}}
-  ~init_int8;   // expected-error {{invalid argument type 'svint8_t'}}
   !init_int8;   // expected-error {{invalid argument type 'svint8_t'}}
   *init_int8;   // expected-error {{indirection requires pointer operand}}
   __real init_int8; // expected-error {{invalid type 'svint8_t'}}
   __imag init_int8; // expected-error {{invalid type 'svint8_t'}}
 
-  local_int8 &init_int8;   // expected-error {{invalid operands to binary expression}}
-  local_int8 | init_int8;  // expected-error {{invalid operands to binary expression}}
-  local_int8 ^ init_int8;  // expected-error {{invalid operands to binary expression}}
   local_int8 << init_int8; // expected-error {{invalid operands to binary expression}}
   local_int8 >> init_int8; // expected-error {{invalid operands to binary expression}}
   local_int8 < init_int8;  // expected-error {{invalid operands to binary expression}}
@@ -213,9 +209,6 @@
   local_int8 &&init_int8;  // expected-error {{invalid operands to binary expression}}
   local_int8 || init_int8; // expected-error {{invalid operands to binary expression}}
 
-  local_int8 &= init_int8;  // expected-error {{invalid operands to binary expression}}
-  local_int8 |= init_int8;  // expected-error {{invalid operands to binary expression}}
-  local_int8 ^= init_int8;  // expected-error {{invalid operands to binary expression}}
   local_int8 <<= init_int8; // expected-error {{invalid operands to binary expression}}
   local_int8 >>= init_int8; // expected-error {{invalid operands to binary expression}}
 
Index:

[PATCH] D121797: [clang][dataflow] Add modeling of Chromium's CHECK functionality

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added inline comments.



Comment at: 
clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp:122
+  void transfer(const Stmt *S, NoopLattice &, Environment &Env) {
+M.transfer(S, Env);
+  }

xazax.hun wrote:
> ymandel wrote:
> > xazax.hun wrote:
> > > I wonder whether the models should actually be called by the framework at 
> > > some point. 
> > > E.g. imagine the following scenario:
> > > ```
> > > void f()
> > > {
> > > std::optional o(5);
> > > if (o)
> > > {
> > > // dead code here;
> > > }
> > > }
> > > ```
> > > 
> > > In an ideal case, an analysis could use the `std::optional` modeling to 
> > > realize that the code in the `if` statement is dead and use this fact to 
> > > improve its precision. Explicitly request the modeling in the transfer 
> > > function works OK when we only have a couple things to model. But it 
> > > might not scale in the future. When we model dozens of standard types and 
> > > functions we would not want all the analysis clients to invoke all the 
> > > transfers for all the models individually. 
> > Agreed. It seems similar the problems that motivated DLLs back in the day. 
> > there's clearly a lot to be worked out here in terms of how best to support 
> > composition. It's probably worth a RFC or somesuch to discuss in more depth.
> Having an RFC and some deeper discussions would be great. I also wonder 
> whether modeling arbitrary `Stmt`s is the right approach. The peculiarities 
> of the language should probably be modelled by the framework itself without 
> any extensions. Maybe we only want the modeling of certain function calls to 
> be customizable?
Good question. It would be really nice if we could draw this line, but I have a 
bad feeling that it won't be so simple. :) Still, worth looking at our existing 
models, and new ones that we're developing, to see if we can find a clear 
"bounding box".

What does CSA do in this regard?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121797

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

[PATCH] D122008: [flang][driver] Add support for generating executables

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski created this revision.
awarzynski added reviewers: kiranchandramohan, clementval.
Herald added a subscriber: mgorny.
Herald added a reviewer: sscalpone.
Herald added projects: Flang, All.
awarzynski requested review of this revision.
Herald added subscribers: cfe-commits, jdoerfert.
Herald added a project: clang.

This patch adds 2 missing items required for `flang-new` to be able to
generate executables:

1. Extra linker flags to include Fortran runtime libraries.

2. The Fortran_main runtime library, which implements the main entry point into 
Fortran's PROGRAM.

With this change, you can generate an executable that will print `hello,
world!` as follows:

  $ cat hello.f90
  program hello
write (*,*), "hello, world!"
  end program hello
  $ flang-new hello.f90
  ./a.out
  hello, world!

Note: Fortran_main was originally written by Peter Klausler, Jean Perier
and Steve Scalpone in the fir-dev` branch in [1].

[1] https://github.com/flang-compiler/f18-llvm-project

Co-authored-by: Peter Klausler 
Co-authored-by: Jean Perier 
Co-authored-by: Steve Scalpone https://reviews.llvm.org/D122008

Files:
  clang/lib/Driver/ToolChains/Gnu.cpp
  flang/include/flang/Runtime/stop.h
  flang/runtime/CMakeLists.txt
  flang/runtime/FortranMain/CMakeLists.txt
  flang/runtime/FortranMain/Fortran_main.c
  flang/test/CMakeLists.txt
  flang/test/Driver/linker-flags.f90

Index: flang/test/Driver/linker-flags.f90
===
--- /dev/null
+++ flang/test/Driver/linker-flags.f90
@@ -0,0 +1,30 @@
+! Verify that the Fortran runtime libraries are present in the linker
+! invocation. These libraries are added on top of other standard runtime
+! libraries that the Clang driver will include.
+
+! NOTE: The additional linker flags tested here are currently specified in
+! clang/lib/Driver/Toolchains/Gnu.cpp. This makes the current implementation GNU
+! (Linux) specific. The following line will make sure that this test is skipped
+! on Windows. Ideally we should find a more robust way of testing this.
+! REQUIRES: shell
+! UNSUPPORTED: darwin, macos
+
+!
+! RUN COMMAND
+!
+! RUN: %flang -### --ld-path=/usr/bin/ld %S/Inputs/hello.f90 2>&1 | FileCheck %s
+
+!
+! EXPECTED OUTPUT
+!
+! Compiler invocation to generate the object file
+! CHECK-LABEL: {{.*}} "-emit-obj"
+! CHECK-SAME:  "-o" "[[object_file:.*]]" {{.*}}Inputs/hello.f90
+
+! Linker invocation to generate the executable
+! CHECK-LABEL:  "/usr/bin/ld"
+! CHECK-SAME: "[[object_file]]"
+! CHECK-SAME: -lFortran_main
+! CHECK-SAME: -lFortranRuntime
+! CHECK-SAME: -lFortranDecimal
+! CHECK-SAME: -lm
Index: flang/test/CMakeLists.txt
===
--- flang/test/CMakeLists.txt
+++ flang/test/CMakeLists.txt
@@ -47,6 +47,7 @@
 
 set(FLANG_TEST_DEPENDS
   flang-new llvm-config FileCheck count not module_files fir-opt tco bbc llvm-objdump
+  FortranRuntime Fortran_main FortranDecimal
 )
 
 if (FLANG_INCLUDE_TESTS)
Index: flang/runtime/FortranMain/Fortran_main.c
===
--- /dev/null
+++ flang/runtime/FortranMain/Fortran_main.c
@@ -0,0 +1,22 @@
+//===-- runtime/FortranMain/Fortran_main.c ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "flang/Runtime/main.h"
+#include "flang/Runtime/stop.h"
+
+/* main entry into PROGRAM */
+void _QQmain();
+
+/* C main stub */
+int main(int argc, const char *argv[], const char *envp[])
+{
+  RTNAME(ProgramStart)(argc, argv, envp);
+  _QQmain();
+  RTNAME(ProgramEndStatement)();
+  return 0;
+}
Index: flang/runtime/FortranMain/CMakeLists.txt
===
--- /dev/null
+++ flang/runtime/FortranMain/CMakeLists.txt
@@ -0,0 +1,3 @@
+add_flang_library(Fortran_main STATIC
+  Fortran_main.c
+)
Index: flang/runtime/CMakeLists.txt
===
--- flang/runtime/CMakeLists.txt
+++ flang/runtime/CMakeLists.txt
@@ -30,6 +30,8 @@
 # with different names
 include_directories(AFTER ${CMAKE_CURRENT_BINARY_DIR})
 
+add_subdirectory(FortranMain)
+
 add_flang_library(FortranRuntime
   ISO_Fortran_binding.cpp
   allocatable.cpp
Index: flang/include/flang/Runtime/stop.h
===
--- flang/include/flang/Runtime/stop.h
+++ flang/include/flang/Runtime/stop.h
@@ -27,7 +27,7 @@
 NORETURN void RTNAME(ProgramEndStatement)(NO_ARGUMENTS);
 
 // Extensions
-NORETURN void RTNAME(Exit)(int status = EXIT_SUCCESS);
+NORETURN void RTNAME(Exit)(int status DEFAULT_VALUE(EXIT_SUCCESS));
 NORETURN void RTNAME(Ab

[clang] c59c2b6 - [clang-format] Refactor ShouldBreakBeforeBrace to use switch. NFC.

[Marek Kurdej via cfe-commits]

Author: Marek Kurdej
Date: 2022-03-18T15:16:01+01:00
New Revision: c59c2b6bd19eb7625f7c234eb68d347d8de17079

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

LOG: [clang-format] Refactor ShouldBreakBeforeBrace to use switch. NFC.

Added: 


Modified: 
clang/lib/Format/UnwrappedLineParser.cpp

Removed: 




diff  --git a/clang/lib/Format/UnwrappedLineParser.cpp 
b/clang/lib/Format/UnwrappedLineParser.cpp
index cadf1960dbf7a..bef8ed54fab8a 100644
--- a/clang/lib/Format/UnwrappedLineParser.cpp
+++ b/clang/lib/Format/UnwrappedLineParser.cpp
@@ -897,17 +897,24 @@ static bool isIIFE(const UnwrappedLine &Line,
 
 static bool ShouldBreakBeforeBrace(const FormatStyle &Style,
const FormatToken &InitialToken) {
-  if (InitialToken.isOneOf(tok::kw_namespace, TT_NamespaceMacro))
+  tok::TokenKind Kind = InitialToken.Tok.getKind();
+  if (InitialToken.is(TT_NamespaceMacro))
+Kind = tok::kw_namespace;
+
+  switch (Kind) {
+  case tok::kw_namespace:
 return Style.BraceWrapping.AfterNamespace;
-  if (InitialToken.is(tok::kw_class))
+  case tok::kw_class:
 return Style.BraceWrapping.AfterClass;
-  if (InitialToken.is(tok::kw_union))
+  case tok::kw_union:
 return Style.BraceWrapping.AfterUnion;
-  if (InitialToken.is(tok::kw_struct))
+  case tok::kw_struct:
 return Style.BraceWrapping.AfterStruct;
-  if (InitialToken.is(tok::kw_enum))
+  case tok::kw_enum:
 return Style.BraceWrapping.AfterEnum;
-  return false;
+  default:
+return false;
+  }
 }
 
 void UnwrappedLineParser::parseChildBlock(



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

[PATCH] D121837: [OpenMP][FIX] Allow device constructors for AMD GPU

[Kamau Bridgeman via Phabricator via cfe-commits]

kamaub added a comment.

The test cases added with this commit failed on clang-ppc64be-linux-lnt # 13809 
 could you please 
revert this change, and recommit with the test case corrected? thank you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121837

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

[PATCH] D119792: [Clang] [P2025] Analyze only potential scopes for NRVO

[Evgeny Shulgin via Phabricator via cfe-commits]

Izaron added inline comments.



Comment at: clang/include/clang/Sema/Scope.h:518
 
   void addNRVOCandidate(VarDecl *VD) {
+// every candidate except VD is "spoiled" now, remove them from the set

ChuanqiXu wrote:
> Firstly I am wondering why here doesn't check `NRVO.getInt()` to shortcut 
> directly. But later I found it would change the logic in 
> `::mergeNRVOIntoParent`:
> ```
> void Scope::mergeNRVOIntoParent() {
>   if (VarDecl *Candidate = NRVO.getPointer()) {
> if (isDeclScope(Candidate))
>   Candidate->setNRVOVariable(true);
>   }
>   ...
> ```
> 
> It would set NRVO for the candidate in NRVO if it is in current scope. With 
> the context of `addNRVOCandidate` here, I could judge that the change would 
> be:
> ```
> X test(bool B) {
>   X x; // before: no nrvo, after: no nrvo (same)
>   if (B)
> return x;
>   X y; // before: no nrvo, after: nrvo (better)
>   return y; // Now NRVO.getInt()==true and NRVO.getPointer() == y;
> }
> ```
> 
> Yeah, the behavior is still 'right'. `y` should be NRVO in this case. But the 
> implementation smell bad, if `NRVO.getInt()` is true, we shouldn't do any 
> thing. I am not sure if I state my points well. I mean the implementation 
> might be correct, but it is hard to understand, read and maintain. It'd 
> better to make the reader avoid doing mathmatics when reading the codes.
> I am not sure if I state my points well. I mean the implementation might be 
> correct, but it is hard to understand, read and maintain. It'd better to make 
> the reader avoid doing mathmatics when reading the codes.
I agree that it is really hard to understand and needs to be polished. It took 
long time for me to construct the code that won't break.

I think that one of the sources of the complexity is the `NRVO` variable itself.
If we could change
```
llvm::PointerIntPair NRVO;
```
to something like
```
VarDecl *NRVOCandidate;
bool InvalidatesParentNRVOCandidates;
```
And maybe rename `setNoNRVO()` to smth like `invalidateNRVOCandidates` and so 
on.

What do you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119792

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

[clang] a36c2dd - [clang][dataflow] Add modeling of Chromium's CHECK functionality

[Yitzhak Mandelbaum via cfe-commits]

Author: Yitzhak Mandelbaum
Date: 2022-03-18T14:39:23Z
New Revision: a36c2dd6d54c6ff854cb4872cd2831ed995e9275

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

LOG: [clang][dataflow] Add modeling of Chromium's CHECK functionality

Chromium's implementation of assertions (`CHECK`, `DCHECK`, etc.) are not
annotated with "noreturn", by default. This patch adds a model of the logical
implications of successfully executing one of these assertions.

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

Added: 
clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h
clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp
clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp

Modified: 
clang/lib/Analysis/FlowSensitive/Models/CMakeLists.txt
clang/unittests/Analysis/FlowSensitive/CMakeLists.txt

Removed: 




diff  --git 
a/clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h 
b/clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h
new file mode 100644
index 0..93c427bd1ddc6
--- /dev/null
+++ b/clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h
@@ -0,0 +1,39 @@
+//===-- ChromiumCheckModel.h *- 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 defines a dataflow model for Chromium's family of CHECK functions.
+//
+//===--===//
+#ifndef CLANG_ANALYSIS_FLOWSENSITIVE_MODELS_CHROMIUMCHECKMODEL_H
+#define CLANG_ANALYSIS_FLOWSENSITIVE_MODELS_CHROMIUMCHECKMODEL_H
+
+#include "clang/AST/DeclCXX.h"
+#include "clang/AST/Stmt.h"
+#include "clang/Analysis/FlowSensitive/DataflowAnalysis.h"
+#include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
+#include "llvm/ADT/DenseSet.h"
+
+namespace clang {
+namespace dataflow {
+
+/// Models the behavior of Chromium's CHECK, DCHECK, etc. macros, so that code
+/// after a call to `*CHECK` can rely on the condition being true.
+class ChromiumCheckModel : public DataflowModel {
+public:
+  ChromiumCheckModel() = default;
+  bool transfer(const Stmt *Stmt, Environment &Env) override;
+
+private:
+  /// Declarations for `::logging::CheckError::.*Check`, lazily initialized.
+  llvm::SmallDenseSet CheckDecls;
+};
+
+} // namespace dataflow
+} // namespace clang
+
+#endif // CLANG_ANALYSIS_FLOWSENSITIVE_MODELS_CHROMIUMCHECKMODEL_H

diff  --git a/clang/lib/Analysis/FlowSensitive/Models/CMakeLists.txt 
b/clang/lib/Analysis/FlowSensitive/Models/CMakeLists.txt
index 5bed00c4bfdc6..89bbe8791eb2c 100644
--- a/clang/lib/Analysis/FlowSensitive/Models/CMakeLists.txt
+++ b/clang/lib/Analysis/FlowSensitive/Models/CMakeLists.txt
@@ -1,4 +1,5 @@
 add_clang_library(clangAnalysisFlowSensitiveModels
+  ChromiumCheckModel.cpp
   UncheckedOptionalAccessModel.cpp
 
   LINK_LIBS

diff  --git a/clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp 
b/clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp
new file mode 100644
index 0..3910847316a59
--- /dev/null
+++ b/clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp
@@ -0,0 +1,67 @@
+//===-- ChromiumCheckModel.cpp --*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
+#include "llvm/ADT/DenseSet.h"
+
+namespace clang {
+namespace dataflow {
+
+/// Determines whether `D` is one of the methods used to implement Chromium's
+/// `CHECK` macros. Populates `CheckDecls`, if empty.
+bool isCheckLikeMethod(llvm::SmallDenseSet &CheckDecls,
+   const CXXMethodDecl &D) {
+  // All of the methods of interest are static, so avoid any lookup for
+  // non-static methods (the common case).
+  if (!D.isStatic())
+return false;
+
+  if (CheckDecls.empty()) {
+// Attempt to initialize `CheckDecls` with the methods in class
+// `CheckError`.
+const CXXRecordDecl *ParentClass = D.getParent();
+if (ParentClass == nullptr || !ParentClass->getDeclName().isIdentifier() ||
+ParentClass->getName() != "CheckError")
+  return false;
+
+// Check whether namespace

[PATCH] D121797: [clang][dataflow] Add modeling of Chromium's CHECK functionality

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa36c2dd6d54c: [clang][dataflow] Add modeling of 
Chromium's CHECK functionality (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121797

Files:
  clang/include/clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h
  clang/lib/Analysis/FlowSensitive/Models/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/Models/ChromiumCheckModel.cpp
  clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
  clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
===
--- /dev/null
+++ clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
@@ -0,0 +1,219 @@
+//===- ChromiumCheckModelTest.cpp -===//
+//
+// 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
+//
+//===--===//
+// FIXME: Move this to clang/unittests/Analysis/FlowSensitive/Models.
+
+#include "clang/Analysis/FlowSensitive/Models/ChromiumCheckModel.h"
+#include "NoopAnalysis.h"
+#include "TestingSupport.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Tooling/Tooling.h"
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/StringExtras.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Testing/Support/Error.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+#include 
+
+using namespace clang;
+using namespace dataflow;
+using namespace test;
+
+namespace {
+using ::testing::_;
+using ::testing::ElementsAre;
+using ::testing::NotNull;
+using ::testing::Pair;
+
+static constexpr char ChromiumCheckHeader[] = R"(
+namespace std {
+class ostream;
+} // namespace std
+
+namespace logging {
+class VoidifyStream {
+ public:
+  VoidifyStream() = default;
+  void operator&(std::ostream&) {}
+};
+
+class CheckError {
+ public:
+  static CheckError Check(const char* file, int line, const char* condition);
+  static CheckError DCheck(const char* file, int line, const char* condition);
+  static CheckError PCheck(const char* file, int line, const char* condition);
+  static CheckError PCheck(const char* file, int line);
+  static CheckError DPCheck(const char* file, int line, const char* condition);
+
+  std::ostream& stream();
+
+  ~CheckError();
+
+  CheckError(const CheckError& other) = delete;
+  CheckError& operator=(const CheckError& other) = delete;
+  CheckError(CheckError&& other) = default;
+  CheckError& operator=(CheckError&& other) = default;
+};
+
+} // namespace logging
+
+#define LAZY_CHECK_STREAM(stream, condition) \
+  !(condition) ? (void)0 : ::logging::VoidifyStream() & (stream)
+
+#define CHECK(condition) \
+  LAZY_CHECK_STREAM( \
+  ::logging::CheckError::Check(__FILE__, __LINE__, #condition).stream(), \
+  !(condition))
+
+#define PCHECK(condition) \
+  LAZY_CHECK_STREAM(  \
+  ::logging::CheckError::PCheck(__FILE__, __LINE__, #condition).stream(), \
+  !(condition))
+
+#define DCHECK(condition) \
+  LAZY_CHECK_STREAM(  \
+  ::logging::CheckError::DCheck(__FILE__, __LINE__, #condition).stream(), \
+  !(condition))
+
+#define DPCHECK(condition) \
+  LAZY_CHECK_STREAM(   \
+  ::logging::CheckError::DPCheck(__FILE__, __LINE__, #condition).stream(), \
+  !(condition))
+)";
+
+// A definition of the `CheckError` class that looks like the Chromium one, but
+// is actually something else.
+static constexpr char OtherCheckHeader[] = R"(
+namespace other {
+namespace logging {
+class CheckError {
+ public:
+  static CheckError Check(const char* file, int line, const char* condition);
+};
+} // namespace logging
+} // namespace other
+)";
+
+/// Replaces all occurrences of `Pattern` in `S` with `Replacement`.
+std::string ReplacePattern(std::string S, const std::string &Pattern,
+   const std::string &Replacement) {
+  size_t Pos = 0;
+  Pos = S.find(Pattern, Pos);
+  if (Pos != std::string::npos)
+S.replace(Pos, Pattern.size(), Replacement);
+  return S;
+}
+
+template 
+class ModelAdaptorAnalysis
+: public DataflowAnalysis, NoopLattice> {
+public:
+  explicit M

[PATCH] D121532: [Clang][WIP] Fix Unevaluated Lambdas

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a reviewer: clang-language-wg.
aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaLambda.cpp:978-979
 
   CXXRecordDecl *Class = createLambdaClosureType(Intro.Range, MethodTyInfo,
  KnownDependent, 
Intro.Default);
   CXXMethodDecl *Method =

I don't think we should pass `KnownDependent` here as a bool, despite it 
working because of the enumerator value for the known dependent case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121532

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

[PATCH] D119476: Generalize and harmonize sub-expression traversal

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman accepted this revision.
aaron.ballman added a reviewer: aaron.ballman.
aaron.ballman added a comment.

Sorry for the delay in reviewing this, but this looks correct to me. I don't 
think the precommit CI failures on Debian relate to your patch, either, so this 
LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119476

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

[PATCH] D121797: [clang][dataflow] Add modeling of Chromium's CHECK functionality

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a comment.

Why this should be maintained and developed by LLVM/Clang developers and not by 
Chromium?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121797

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

[PATCH] D122008: [flang][driver] Add support for generating executables

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski updated this revision to Diff 416513.
awarzynski added a comment.

Fix formatting


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122008

Files:
  clang/lib/Driver/ToolChains/Gnu.cpp
  flang/include/flang/Runtime/stop.h
  flang/runtime/CMakeLists.txt
  flang/runtime/FortranMain/CMakeLists.txt
  flang/runtime/FortranMain/Fortran_main.c
  flang/test/CMakeLists.txt
  flang/test/Driver/linker-flags.f90

Index: flang/test/Driver/linker-flags.f90
===
--- /dev/null
+++ flang/test/Driver/linker-flags.f90
@@ -0,0 +1,30 @@
+! Verify that the Fortran runtime libraries are present in the linker
+! invocation. These libraries are added on top of other standard runtime
+! libraries that the Clang driver will include.
+
+! NOTE: The additional linker flags tested here are currently specified in
+! clang/lib/Driver/Toolchains/Gnu.cpp. This makes the current implementation GNU
+! (Linux) specific. The following line will make sure that this test is skipped
+! on Windows. Ideally we should find a more robust way of testing this.
+! REQUIRES: shell
+! UNSUPPORTED: darwin, macos
+
+!
+! RUN COMMAND
+!
+! RUN: %flang -### --ld-path=/usr/bin/ld %S/Inputs/hello.f90 2>&1 | FileCheck %s
+
+!
+! EXPECTED OUTPUT
+!
+! Compiler invocation to generate the object file
+! CHECK-LABEL: {{.*}} "-emit-obj"
+! CHECK-SAME:  "-o" "[[object_file:.*]]" {{.*}}Inputs/hello.f90
+
+! Linker invocation to generate the executable
+! CHECK-LABEL:  "/usr/bin/ld"
+! CHECK-SAME: "[[object_file]]"
+! CHECK-SAME: -lFortran_main
+! CHECK-SAME: -lFortranRuntime
+! CHECK-SAME: -lFortranDecimal
+! CHECK-SAME: -lm
Index: flang/test/CMakeLists.txt
===
--- flang/test/CMakeLists.txt
+++ flang/test/CMakeLists.txt
@@ -47,6 +47,7 @@
 
 set(FLANG_TEST_DEPENDS
   flang-new llvm-config FileCheck count not module_files fir-opt tco bbc llvm-objdump
+  FortranRuntime Fortran_main FortranDecimal
 )
 
 if (FLANG_INCLUDE_TESTS)
Index: flang/runtime/FortranMain/Fortran_main.c
===
--- /dev/null
+++ flang/runtime/FortranMain/Fortran_main.c
@@ -0,0 +1,21 @@
+//===-- runtime/FortranMain/Fortran_main.c ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "flang/Runtime/main.h"
+#include "flang/Runtime/stop.h"
+
+/* main entry into PROGRAM */
+void _QQmain();
+
+/* C main stub */
+int main(int argc, const char *argv[], const char *envp[]) {
+  RTNAME(ProgramStart)(argc, argv, envp);
+  _QQmain();
+  RTNAME(ProgramEndStatement)();
+  return 0;
+}
Index: flang/runtime/FortranMain/CMakeLists.txt
===
--- /dev/null
+++ flang/runtime/FortranMain/CMakeLists.txt
@@ -0,0 +1,3 @@
+add_flang_library(Fortran_main STATIC
+  Fortran_main.c
+)
Index: flang/runtime/CMakeLists.txt
===
--- flang/runtime/CMakeLists.txt
+++ flang/runtime/CMakeLists.txt
@@ -30,6 +30,8 @@
 # with different names
 include_directories(AFTER ${CMAKE_CURRENT_BINARY_DIR})
 
+add_subdirectory(FortranMain)
+
 add_flang_library(FortranRuntime
   ISO_Fortran_binding.cpp
   allocatable.cpp
Index: flang/include/flang/Runtime/stop.h
===
--- flang/include/flang/Runtime/stop.h
+++ flang/include/flang/Runtime/stop.h
@@ -27,7 +27,7 @@
 NORETURN void RTNAME(ProgramEndStatement)(NO_ARGUMENTS);
 
 // Extensions
-NORETURN void RTNAME(Exit)(int status = EXIT_SUCCESS);
+NORETURN void RTNAME(Exit)(int status DEFAULT_VALUE(EXIT_SUCCESS));
 NORETURN void RTNAME(Abort)(NO_ARGUMENTS);
 
 // Crash with an error message when the program dynamically violates a Fortran
Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -379,6 +379,13 @@
  Exec, CmdArgs, Inputs, Output));
 }
 
+static void addFortranLinkerFlags(ArgStringList &CmdArgs) {
+  CmdArgs.push_back("-lFortran_main");
+  CmdArgs.push_back("-lFortranRuntime");
+  CmdArgs.push_back("-lFortranDecimal");
+  CmdArgs.push_back("-lm");
+}
+
 void tools::gnutools::Linker::ConstructJob(Compilation &C, const JobAction &JA,
const InputInfo &Output,
const InputInfoList &Inputs,
@@ -665,6 +672,10 @@
 }
   }
 
+  // Additional

[PATCH] D119477: Ignore FullExpr when traversing cast sub-expressions

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

The changes here generally look good, and I'm happy to see that more of our 
test cases are diagnosing similar to other compilers with the changes.




Comment at: clang/test/SemaCXX/cxx2a-consteval.cpp:362-364
+  { A k = to_lvalue_ref(A().ret_a()); } // expected-error {{'alloc::A::ret_a' 
is not a constant expression}} expected-error {{'alloc::to_lvalue_ref' is not a 
constant expression}}
+  // expected-note@-1 {{temporary created here}}
+  // expected-note@-2 {{heap-allocated object is not a constant expression}} 
expected-note@-2 {{reference to temporary is not a constant expression}}

I usually prefer line continuation characters because I think it makes the test 
easier to read (it's easy to miss secondary diagnostics on the same line). 
However, I don't insist on these changes either (but if you make them, please 
do similar for the other test lines you're touching).



Comment at: clang/test/SemaCXX/cxx2a-consteval.cpp:365
-  { int k = A().ret_a().ret_i(); }
-  { int k = by_value_a(A()); }
   { int k = const_a_ref(A()); }

Why are we dropping this test coverage?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119477

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

[PATCH] D121951: [AMDGPU] Only warn when mixing printf and hostcall

[Scott Linder via Phabricator via cfe-commits]

scott.linder added a comment.

In D121951#3391472 , @sameerds wrote:

> The check for "__ockl_hostcall_internal" is not longer relevant with the new 
> hostcall attribute. Can we simply remove this check? What is the situation 
> where the warning is still useful?

I wasn't aware of the new attribute, I'm happy to just delete it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121951

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

[PATCH] D121837: [OpenMP][FIX] Allow device constructors for AMD GPU

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

In D121837#3392346 , @kamaub wrote:

> The test cases added with this commit failed on clang-ppc64be-linux-lnt # 
> 13809  could you 
> please revert this change, and recommit with the test case corrected? thank 
> you.

I did in https://reviews.llvm.org/rGb4cc3b1dd8d7200640210513263b28187f810703, I 
don't think the bot picked it up yet.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121837

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

[clang] 1df3a91 - [OpenMP][FIX] Make test check lines less strict

[Johannes Doerfert via cfe-commits]

Author: Johannes Doerfert
Date: 2022-03-18T10:53:32-05:00
New Revision: 1df3a913efc497b2ce63d856b25ba8903378d377

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

LOG: [OpenMP][FIX] Make test check lines less strict

The ppc64be bot emits the dtor metadata first for some reason. We should
investigate this or make the _cc_ update script able to use variables
instead of fixed numbers (e.g., !1). The IR update script does that
already.

Added: 


Modified: 
clang/test/OpenMP/amdgcn_target_global_constructor.cpp

Removed: 




diff  --git a/clang/test/OpenMP/amdgcn_target_global_constructor.cpp 
b/clang/test/OpenMP/amdgcn_target_global_constructor.cpp
index 544406dc7f43f..830497a661850 100644
--- a/clang/test/OpenMP/amdgcn_target_global_constructor.cpp
+++ b/clang/test/OpenMP/amdgcn_target_global_constructor.cpp
@@ -93,13 +93,13 @@ S A;
 // CHECK: attributes #3 = { convergent
 // CHECK: attributes #4 = { convergent
 //.
-// CHECK: !0 = !{i32 0, {{.*}}, !"__omp_offloading_{{.*}}_ctor", i32 19, i32 1}
-// CHECK: !1 = !{i32 0, {{.*}}, !"__omp_offloading_{{.*}}_dtor", i32 19, i32 2}
-// CHECK: !2 = !{i32 1, !"A", i32 0, i32 0}
-// CHECK: !3 = !{void ()* @__omp_offloading_{{.*}}_ctor, !"kernel", i32 1}
-// CHECK: !4 = !{void ()* @__omp_offloading_{{.*}}_dtor, !"kernel", i32 1}
-// CHECK: !5 = !{i32 1, !"wchar_size", i32 4}
-// CHECK: !6 = !{i32 7, !"openmp", i32 50}
-// CHECK: !7 = !{i32 7, !"openmp-device", i32 50}
-// CHECK: !8 = !{!"clang version
+// CHECK-DAG: !{i32 0, {{.*}}, !"__omp_offloading_{{.*}}_ctor", i32 19, i32 1}
+// CHECK-DAG: !{i32 0, {{.*}}, !"__omp_offloading_{{.*}}_dtor", i32 19, i32 2}
+// CHECK-DAG: !{i32 1, !"A", i32 0, i32 0}
+// CHECK-DAG: !{void ()* @__omp_offloading_{{.*}}_ctor, !"kernel", i32 1}
+// CHECK-DAG: !{void ()* @__omp_offloading_{{.*}}_dtor, !"kernel", i32 1}
+// CHECK-DAG: !{i32 1, !"wchar_size", i32 4}
+// CHECK-DAG: !{i32 7, !"openmp", i32 50}
+// CHECK-DAG: !{i32 7, !"openmp-device", i32 50}
+// CHECK-DAG: !{!"clang version
 //.



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

[PATCH] D121906: [clang-format] Indent import statements in JavaScript.

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added inline comments.



Comment at: clang/lib/Format/ContinuationIndenter.cpp:633
   (State.Line->Type == LT_PreprocessorDirective ||
State.Line->Type == LT_ImportStatement)) {
 Spaces += State.FirstIndent;

AfterHash  - Could be true
Previous is hash - Can't be true can it?
FirstIndent > 0 - I guess could be true
State.Line->Type being LT_ImportStatement could be true..

true && false && true && true == false right?

Remove `!Style.isJavaScript()` from this, does your test still pass?

Either add the second test to cover this case or remove the condition, I don't 
mind either way.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121906

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

[PATCH] D121907: [clang-format] Use an enum for context types. NFC

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121907

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

[PATCH] D121797: [clang][dataflow] Add modeling of Chromium's CHECK functionality

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added a comment.

In D121797#3392444 , @xbolva00 wrote:

> Why this should be maintained and developed by LLVM/Clang developers and not 
> by Chromium?

That's a good question. I think the short answer, that skirts around the issue, 
is that this is targeted for use in an upcoming clang-tidy check, and we don't 
have any framework for clients developing their own pluggable models for 
individual checks. Chromium could find some way to patch their clang-tidy 
source, I suppose, but we'd rather not encourage that.  This framework is new 
and under development and the benefit of accomodating Chromium (in this very 
small way) seems worth the feedback from them applying it to their codebase.

That said, we are *also* in discussions with them to change their implement of 
CHECK, etc. so as to obviate the need for this model at all.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121797

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

[PATCH] D119477: Ignore FullExpr when traversing cast sub-expressions

[Kim Gräsman via Phabricator via cfe-commits]

kimgr added inline comments.



Comment at: clang/test/SemaCXX/cxx2a-consteval.cpp:362-364
+  { A k = to_lvalue_ref(A().ret_a()); } // expected-error {{'alloc::A::ret_a' 
is not a constant expression}} expected-error {{'alloc::to_lvalue_ref' is not a 
constant expression}}
+  // expected-note@-1 {{temporary created here}}
+  // expected-note@-2 {{heap-allocated object is not a constant expression}} 
expected-note@-2 {{reference to temporary is not a constant expression}}

aaron.ballman wrote:
> I usually prefer line continuation characters because I think it makes the 
> test easier to read (it's easy to miss secondary diagnostics on the same 
> line). However, I don't insist on these changes either (but if you make them, 
> please do similar for the other test lines you're touching).
Thanks, I wasn't aware there was support for line continuation. I agree it 
would benefit readability here, so I'll look into it. 



Comment at: clang/test/SemaCXX/cxx2a-consteval.cpp:365
-  { int k = A().ret_a().ret_i(); }
-  { int k = by_value_a(A()); }
   { int k = const_a_ref(A()); }

aaron.ballman wrote:
> Why are we dropping this test coverage?
Good question, that must've been a mistake. I'll take another look. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119477

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

[clang] f5fea45 - [RISCV][NFC] Add tests to address invalid arch dependencies.

[Zakk Chen via cfe-commits]

Author: Zakk Chen
Date: 2022-03-18T09:41:04-07:00
New Revision: f5fea45d09e5bae2f141195d05cfcb055914b63f

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

LOG: [RISCV][NFC] Add tests to address invalid arch dependencies.

Improve test converage.

Reviewed By: asb

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

Added: 


Modified: 
clang/test/Driver/riscv-arch.c

Removed: 




diff  --git a/clang/test/Driver/riscv-arch.c b/clang/test/Driver/riscv-arch.c
index 88dd7bb9fe7e5..e407c7f9bf13e 100644
--- a/clang/test/Driver/riscv-arch.c
+++ b/clang/test/Driver/riscv-arch.c
@@ -224,6 +224,31 @@
 // RV32-ORDER: error: invalid arch name 'rv32imcq',
 // RV32-ORDER: standard user-level extension not given in canonical order 'q'
 
+// RUN: %clang -target riscv32-unknown-elf -march=rv64e -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-EER %s
+// RV64-EER: error: invalid arch name 'rv64e',
+// RV64-EER: standard user-level extension 'e' requires 'rv32'
+
+// RUN: %clang -target riscv32-unknown-elf -march=rv32id -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-DER %s
+// RV32-DER: error: invalid arch name 'rv32id',
+// RV32-DER: d requires f extension to also be specified
+
+// RUN: %clang -target riscv32-unknown-elf -march=rv32izve32f -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZVE32F-ER %s
+// RV32-ZVE32F-ER: error: invalid arch name 'rv32izve32f',
+// RV32-ZVE32F-ER: zve32f requires f or zfinx extension to also be specified
+
+// RUN: %clang -target riscv32-unknown-elf -march=rv32ifzve64d -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZVE64D-ER %s
+// RV32-ZVE64D-ER: error: invalid arch name 'rv32ifzve64d',
+// RV32-ZVE64D-ER: zve64d requires d or zdinx extension to also be specified
+
+// RUN: %clang -target riscv32-unknown-elf -march=rv32izvl64b -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZVL64B-ER %s
+// RV32-ZVL64B-ER: error: invalid arch name 'rv32izvl64b',
+// RV32-ZVL64B-ER: zvl*b requires v or zve* extension to also be specified
+
 // RUN: %clang -target riscv32-unknown-elf -march=rv32imw -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-STD-INVAL %s
 // RV32-STD-INVAL: error: invalid arch name 'rv32imw',
@@ -376,6 +401,18 @@
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
 // RV64-TARGET: "-triple" "riscv64-unknown-unknown-elf"
 
+// RUN: %clang -target riscv32-unknown-elf -march=rv32ifzfh01p0 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZFH %s
+// RUN: %clang -target riscv32-unknown-elf -march=rv32ifzfh -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZFH %s
+// RV32-ZFH: "-target-feature" "+zfh"
+
+// RUN: %clang -target riscv32-unknown-elf -march=rv32ifzfhmin01p0 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZFHMIN %s
+// RUN: %clang -target riscv32-unknown-elf -march=rv32ifzfhmin -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZFHMIN %s
+// RV32-ZFHMIN: "-target-feature" "+zfhmin"
+
 // RUN: %clang -target riscv32-unknown-elf -march=rv32izbb1p0 -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZBB %s
 // RUN: %clang -target riscv32-unknown-elf -march=rv32izbb -### %s \



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

[PATCH] D121578: [RISCV][NFC] Add tests to address invalid arch dependencies.

[Zakk Chen via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGf5fea45d09e5: [RISCV][NFC] Add tests to address invalid arch 
dependencies. (authored by khchen).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121578

Files:
  clang/test/Driver/riscv-arch.c


Index: clang/test/Driver/riscv-arch.c
===
--- clang/test/Driver/riscv-arch.c
+++ clang/test/Driver/riscv-arch.c
@@ -224,6 +224,31 @@
 // RV32-ORDER: error: invalid arch name 'rv32imcq',
 // RV32-ORDER: standard user-level extension not given in canonical order 'q'
 
+// RUN: %clang -target riscv32-unknown-elf -march=rv64e -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-EER %s
+// RV64-EER: error: invalid arch name 'rv64e',
+// RV64-EER: standard user-level extension 'e' requires 'rv32'
+
+// RUN: %clang -target riscv32-unknown-elf -march=rv32id -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-DER %s
+// RV32-DER: error: invalid arch name 'rv32id',
+// RV32-DER: d requires f extension to also be specified
+
+// RUN: %clang -target riscv32-unknown-elf -march=rv32izve32f -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZVE32F-ER %s
+// RV32-ZVE32F-ER: error: invalid arch name 'rv32izve32f',
+// RV32-ZVE32F-ER: zve32f requires f or zfinx extension to also be specified
+
+// RUN: %clang -target riscv32-unknown-elf -march=rv32ifzve64d -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZVE64D-ER %s
+// RV32-ZVE64D-ER: error: invalid arch name 'rv32ifzve64d',
+// RV32-ZVE64D-ER: zve64d requires d or zdinx extension to also be specified
+
+// RUN: %clang -target riscv32-unknown-elf -march=rv32izvl64b -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZVL64B-ER %s
+// RV32-ZVL64B-ER: error: invalid arch name 'rv32izvl64b',
+// RV32-ZVL64B-ER: zvl*b requires v or zve* extension to also be specified
+
 // RUN: %clang -target riscv32-unknown-elf -march=rv32imw -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-STD-INVAL %s
 // RV32-STD-INVAL: error: invalid arch name 'rv32imw',
@@ -376,6 +401,18 @@
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
 // RV64-TARGET: "-triple" "riscv64-unknown-unknown-elf"
 
+// RUN: %clang -target riscv32-unknown-elf -march=rv32ifzfh01p0 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZFH %s
+// RUN: %clang -target riscv32-unknown-elf -march=rv32ifzfh -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZFH %s
+// RV32-ZFH: "-target-feature" "+zfh"
+
+// RUN: %clang -target riscv32-unknown-elf -march=rv32ifzfhmin01p0 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZFHMIN %s
+// RUN: %clang -target riscv32-unknown-elf -march=rv32ifzfhmin -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZFHMIN %s
+// RV32-ZFHMIN: "-target-feature" "+zfhmin"
+
 // RUN: %clang -target riscv32-unknown-elf -march=rv32izbb1p0 -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZBB %s
 // RUN: %clang -target riscv32-unknown-elf -march=rv32izbb -### %s \


Index: clang/test/Driver/riscv-arch.c
===
--- clang/test/Driver/riscv-arch.c
+++ clang/test/Driver/riscv-arch.c
@@ -224,6 +224,31 @@
 // RV32-ORDER: error: invalid arch name 'rv32imcq',
 // RV32-ORDER: standard user-level extension not given in canonical order 'q'
 
+// RUN: %clang -target riscv32-unknown-elf -march=rv64e -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-EER %s
+// RV64-EER: error: invalid arch name 'rv64e',
+// RV64-EER: standard user-level extension 'e' requires 'rv32'
+
+// RUN: %clang -target riscv32-unknown-elf -march=rv32id -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-DER %s
+// RV32-DER: error: invalid arch name 'rv32id',
+// RV32-DER: d requires f extension to also be specified
+
+// RUN: %clang -target riscv32-unknown-elf -march=rv32izve32f -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZVE32F-ER %s
+// RV32-ZVE32F-ER: error: invalid arch name 'rv32izve32f',
+// RV32-ZVE32F-ER: zve32f requires f or zfinx extension to also be specified
+
+// RUN: %clang -target riscv32-unknown-elf -march=rv32ifzve64d -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZVE64D-ER %s
+// RV32-ZVE64D-ER: error: invalid arch name 'rv32ifzve64d',
+// RV32-ZVE64D-ER: zve64d requires d or zdinx extension to also be specified
+
+// RUN: %clang -target riscv32-unknown-elf -march=rv32izvl64b -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZVL64B-ER %s
+// RV32-ZVL64B-ER: error: invalid arch name 'rv32izvl64b',
+// RV32-ZVL64B-ER: zvl*b requires v or zve* extension to also be specified
+
 // RUN: %clang -target riscv32-unknown-elf -march=rv32imw -

[PATCH] D121797: [clang][dataflow] Add modeling of Chromium's CHECK functionality

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

xazax.hun added inline comments.



Comment at: 
clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp:122
+  void transfer(const Stmt *S, NoopLattice &, Environment &Env) {
+M.transfer(S, Env);
+  }

ymandel wrote:
> xazax.hun wrote:
> > ymandel wrote:
> > > xazax.hun wrote:
> > > > I wonder whether the models should actually be called by the framework 
> > > > at some point. 
> > > > E.g. imagine the following scenario:
> > > > ```
> > > > void f()
> > > > {
> > > > std::optional o(5);
> > > > if (o)
> > > > {
> > > > // dead code here;
> > > > }
> > > > }
> > > > ```
> > > > 
> > > > In an ideal case, an analysis could use the `std::optional` modeling to 
> > > > realize that the code in the `if` statement is dead and use this fact 
> > > > to improve its precision. Explicitly request the modeling in the 
> > > > transfer function works OK when we only have a couple things to model. 
> > > > But it might not scale in the future. When we model dozens of standard 
> > > > types and functions we would not want all the analysis clients to 
> > > > invoke all the transfers for all the models individually. 
> > > Agreed. It seems similar the problems that motivated DLLs back in the 
> > > day. there's clearly a lot to be worked out here in terms of how best to 
> > > support composition. It's probably worth a RFC or somesuch to discuss in 
> > > more depth.
> > Having an RFC and some deeper discussions would be great. I also wonder 
> > whether modeling arbitrary `Stmt`s is the right approach. The peculiarities 
> > of the language should probably be modelled by the framework itself without 
> > any extensions. Maybe we only want the modeling of certain function calls 
> > to be customizable?
> Good question. It would be really nice if we could draw this line, but I have 
> a bad feeling that it won't be so simple. :) Still, worth looking at our 
> existing models, and new ones that we're developing, to see if we can find a 
> clear "bounding box".
> 
> What does CSA do in this regard?
In the CSA, there is no clear distinction between modeling and diagnostics, 
each check can do both. Historically, this turned out to be a bad idea. When we 
have a check that is doing both modeling and diagnostics, users can end up 
turning the check off due to some false positives and end up getting worse 
results from other checks because some critical piece of modeling is also 
turned off. (E.g., even if there are a couple of false positives from a 
std::optional check, it might still be beneficial to do the modeling in the 
background without the diagnostics because it might help discover infeasible 
paths and that can improve the precision of other checks). 

Nowadays, we try to make the distinction clear, some checks are modeling only 
and others are diagnostic only (they might still have their own modeling but 
they do not affect the global analysis state, i.e., the diagnostic only checks 
should not be able to affect each other). This distinction is currently a best 
effort approach and not enforced by any of the APIs.

In CSA, the checker APIs are very powerful. E.g., if there is a pointer with an 
unknown value and we see a dereference, we can continue the analysis with the 
assumption that the pointer is not-null. These assumptions could be added by 
the framework itself or just a regular check. Over time, we are trying to move 
as much modeling to (non-diagnostic) checks as possible to keep the framework 
lightweight but most of the meat is still in the framework.

To model libraries, we are using the evalCall callback: 
https://github.com/llvm/llvm-project/blob/main/clang/lib/StaticAnalyzer/Checkers/CheckerDocumentation.cpp#L229

Roughly speaking the model looks like this:
* The analyzer encounters a function call, so it asks all the checks in a 
sequence if any of them wants to model it
* A check gets the evalCall callback and can do whatever it wants to do. Most 
of them will return false most of the time as they are only expected to handle 
a small subset of the functions.
* This first check returning true will short-circuit this process.
* If none of the checks returned true, the framework will fall back to a 
default modeling which is a conservative approximation of the call, i.e., 
invalidating the bindings that could be changes by the function (globals, 
output arguments, return values etc.)

The model above assumes that when a check return true it will end up modeling 
all the aspects of a function (like invalidation). A downside might be that it 
will not solve the composition, when multiple checks want to model the same 
function, well, the framework will just pick one of them. Also, modeling types 
is really challenging. E.g., if a modeling check models the constructor of a 
type but does not model the destructor, the framework will end up using the 
default modeling for the dtor. The problem is that, in that case the ctor was 
not 

[PATCH] D117522: [clang-tidy] Add modernize-macro-to-enum check

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood added a comment.

I've worked through this issue before, I just need to spend some time on it.

The basic problem is that the test fails and dumps a bunch of output to "help" 
you
understand the failure, but the way it is formatted and mangled doesn't end up
being useful.


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

https://reviews.llvm.org/D117522

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

[PATCH] D122021: [CMake][Fuchsia] Include llvm-undname

[Petr Hosek via Phabricator via cfe-commits]

phosek created this revision.
phosek added reviewers: abrachet, haowei.
Herald added a subscriber: mgorny.
Herald added a project: All.
phosek requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This is useful when developing on Windows.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D122021

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -70,9 +70,6 @@
   set(LIBCXX_ENABLE_SHARED OFF CACHE BOOL "")
   set(LIBCXX_ENABLE_STATIC_ABI_LIBRARY ON CACHE BOOL "")
   set(LIBCXX_ABI_VERSION 2 CACHE STRING "")
-  set(DARWIN_ios_ARCHS arm64 CACHE STRING "")
-  set(DARWIN_iossim_ARCHS arm64 CACHE STRING "")
-  set(DARWIN_osx_ARCHS arm64;x86_64 CACHE STRING "")
 endif()
 
 if(WIN32)


Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -70,9 +70,6 @@
   set(LIBCXX_ENABLE_SHARED OFF CACHE BOOL "")
   set(LIBCXX_ENABLE_STATIC_ABI_LIBRARY ON CACHE BOOL "")
   set(LIBCXX_ABI_VERSION 2 CACHE STRING "")
-  set(DARWIN_ios_ARCHS arm64 CACHE STRING "")
-  set(DARWIN_iossim_ARCHS arm64 CACHE STRING "")
-  set(DARWIN_osx_ARCHS arm64;x86_64 CACHE STRING "")
 endif()
 
 if(WIN32)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits