[clang] [clang][AArch64] Add validation for Global Register Variable. (PR #94271)

2024-06-16 Thread Daniel Kiss via cfe-commits
https://github.com/DanielKristofKiss closed https://github.com/llvm/llvm-project/pull/94271 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 5fe7f73 - [clang][AArch64] Add validation for Global Register Variable. (#94271)

2024-06-16 Thread via cfe-commits
Author: Daniel Kiss Date: 2024-06-17T08:48:53+02:00 New Revision: 5fe7f7364abcabe34f9bf157e5e6a6fa4fa0248a URL: https://github.com/llvm/llvm-project/commit/5fe7f7364abcabe34f9bf157e5e6a6fa4fa0248a DIFF: https://github.com/llvm/llvm-project/commit/5fe7f7364abcabe34f9bf157e5e6a6fa4fa0248a.diff L

[clang] [clang][ExprConst] allow single element access of vector object to be constant expression (PR #72607)

2024-06-16 Thread Yuanfang Chen via cfe-commits
yuanfang-chen wrote: Hello @vikramRH, please feel free to commandeer this. https://github.com/llvm/llvm-project/pull/72607 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][ExprConst] allow single element access of vector object to be constant expression (PR #72607)

2024-06-16 Thread Vikram Hegde via cfe-commits
vikramRH wrote: @yuanfang-chen , @AaronBallman, @shafik, are we still actively looking into this ? (I would be willing to commandeer this if its not high on your priority list) https://github.com/llvm/llvm-project/pull/72607 ___ cfe-commits mailing

[clang] [Serialization] Use specialized decl hash function for GlobalDeclID (PR #95730)

2024-06-16 Thread Anton Korobeynikov via cfe-commits
@@ -230,7 +230,11 @@ template <> struct DenseMapInfo { } static unsigned getHashValue(const GlobalDeclID &Key) { -return DenseMapInfo::getHashValue(Key.get()); +// Our default hash algorithm for 64 bits integer may not be very good. +// In GlobalDeclID's case,

[clang] [llvm] [AMDGPU] Extend readlane, writelane and readfirstlane intrinsic lowering for generic types (PR #89217)

2024-06-16 Thread Vikram Hegde via cfe-commits
@@ -0,0 +1,65 @@ +; RUN: llc -stop-after=amdgpu-isel -mtriple=amdgcn-- -mcpu=gfx1100 -verify-machineinstrs -o - %s | FileCheck --check-prefixes=CHECK,ISEL %s + +; CHECK-LABEL: name:basic_readfirstlane_i64 +; CHECK:[[TOKEN:%[0-9]+]]{{[^ ]*}} = CONVERGENCECTRL

[clang-tools-extra] [clangd] Add inlay hints for default function arguments and implicit lambda captures (PR #95712)

2024-06-16 Thread Younan Zhang via cfe-commits
@@ -372,6 +382,34 @@ maybeDropCxxExplicitObjectParameters(ArrayRef Params) { return Params; } +llvm::StringRef getLambdaCaptureName(const LambdaCapture &Capture) { + if (Capture.capturesVariable()) +return Capture.getCapturedVar()->getName(); + if (Capture.capturesThis

[clang-tools-extra] [clangd] Add inlay hints for default function arguments and implicit lambda captures (PR #95712)

2024-06-16 Thread Younan Zhang via cfe-commits
@@ -281,7 +281,7 @@ struct TextDocumentEdit { /// The text document to change. VersionedTextDocumentIdentifier textDocument; - /// The edits to be applied. + /// The edits to be applied. zyn0217 wrote: Ditto. Unrelated blank changes. Please revert

[clang-tools-extra] [clangd] Add inlay hints for default function arguments and implicit lambda captures (PR #95712)

2024-06-16 Thread Younan Zhang via cfe-commits
@@ -1458,13 +1463,66 @@ TEST(TypeHints, DefaultTemplateArgs) { struct A {}; A foo(); auto $var[[var]] = foo(); -A bar[1]; +A baz; +A bar[1]{}; zyn0217 wrote: Why there's an empty initializer? Can you revert it? https://github.com/llvm/

[clang-tools-extra] [clangd] Add inlay hints for default function arguments and implicit lambda captures (PR #95712)

2024-06-16 Thread Younan Zhang via cfe-commits
@@ -504,10 +503,10 @@ struct FragmentCompiler { auto Fast = isFastTidyCheck(Str); if (!Fast.has_value()) { diag(Warning, - llvm::formatv( - "Latency of clang-tidy check '{0}' is not known. " - "It will only run if

[clang-tools-extra] [clangd] Add inlay hints for default function arguments and implicit lambda captures (PR #95712)

2024-06-16 Thread Younan Zhang via cfe-commits
@@ -1568,7 +1626,7 @@ TEST(TypeHints, SubstTemplateParameterAliases) { )cpp"; llvm::StringRef VectorIntPtr = R"cpp( -vector array; +vector $init[[array]]; zyn0217 wrote: Will the range ever be used somewhere? https://github.com/llvm/llvm-project/

[clang-tools-extra] [clangd] Add inlay hints for default function arguments and implicit lambda captures (PR #95712)

2024-06-16 Thread Younan Zhang via cfe-commits
@@ -372,6 +382,34 @@ maybeDropCxxExplicitObjectParameters(ArrayRef Params) { return Params; } +llvm::StringRef getLambdaCaptureName(const LambdaCapture &Capture) { + if (Capture.capturesVariable()) +return Capture.getCapturedVar()->getName(); + if (Capture.capturesThis

[clang-tools-extra] [clangd] Add inlay hints for default function arguments and implicit lambda captures (PR #95712)

2024-06-16 Thread Younan Zhang via cfe-commits
@@ -755,12 +807,34 @@ class InlayHintVisitor : public RecursiveASTVisitor { bool NameHint = shouldHintName(Args[I], Name); bool ReferenceHint = shouldHintReference(Params[I], ForwardedParams[I]); + bool IsDefault = isa(Args[I]); + HasNonDefaultArgs |= !I

[clang-tools-extra] [clangd] Add inlay hints for default function arguments and implicit lambda captures (PR #95712)

2024-06-16 Thread Younan Zhang via cfe-commits
https://github.com/zyn0217 commented: My two cents: While I appreciate the value of inspecting more semantic information about lambdas, I still have mixed feelings about user experience. Admittedly, presenting implicitly captured variables provides users with insight into ODR-used variables,

[clang-tools-extra] [clangd] Add inlay hints for default function arguments and implicit lambda captures (PR #95712)

2024-06-16 Thread Younan Zhang via cfe-commits
@@ -15,9 +15,12 @@ #include "support/Context.h" #include "llvm/ADT/StringRef.h" #include "llvm/Support/ScopedPrinter.h" +#include "llvm/Support/raw_ostream.h" #include "gmock/gmock.h" #include "gtest/gtest.h" +#include #include +#include zyn0217 wrote: W

[clang-tools-extra] [clangd] Add inlay hints for default function arguments and implicit lambda captures (PR #95712)

2024-06-16 Thread Younan Zhang via cfe-commits
https://github.com/zyn0217 edited https://github.com/llvm/llvm-project/pull/95712 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][analyzer] use unqualified canonical type during merging equivalence class (PR #95729)

2024-06-16 Thread Balazs Benics via cfe-commits
https://github.com/steakhal commented: Awesome. I have one remark though. It would be nice to see tests that does not depend on the errno, as this eqclass merging is a major vore feature, unlike the errno modeling which is an optional feature. If have something in mind, you could add that test

[clang] [llvm] [Clang][Coroutines] Improve CoroElide with [[clang::coro_structured_concurrency]] attribute for C++ (PR #94693)

2024-06-16 Thread Chuanqi Xu via cfe-commits
ChuanqiXu9 wrote: > Thanks for the feedback. This patch is the first iteration to model this idea > as quickly as I can. In general, I agree with your comments. > > > * I feel the name containing `concurrency` is not proper > > The name is bikesheddable as always. I was also thinking around th

[clang] [llvm] [Clang][Coroutines] Improve CoroElide with [[clang::coro_structured_concurrency]] attribute for C++ (PR #94693)

2024-06-16 Thread Chuanqi Xu via cfe-commits
ChuanqiXu9 wrote: > Thanks for the feedback. This patch is the first iteration to model this idea > as quickly as I can. In general, I agree with your comments. > > > * I feel the name containing `concurrency` is not proper > > The name is bikesheddable as always. I was also thinking around th

[clang] [llvm] [Clang][Coroutines] Improve CoroElide with [[clang::coro_structured_concurrency]] attribute for C++ (PR #94693)

2024-06-16 Thread Yuxuan Chen via cfe-commits
yuxuanchen1997 wrote: > What I prefer is to add a middle end function attribute (must-coro-elide) and > apply this attribute and (always inline attribute) to the calls: Actually this might be problematic. The same coroutine called in different contexts (e.g. one coroutine that is also attribut

[clang] [llvm] [Clang][Coroutines] Improve CoroElide with [[clang::coro_structured_concurrency]] attribute for C++ (PR #94693)

2024-06-16 Thread Yuxuan Chen via cfe-commits
yuxuanchen1997 wrote: Thanks for the feedback. This patch is the first iteration to model this idea as quickly as I can. In general, I agree with your comments. > * I feel the name containing `concurrency` is not proper The name is bikesheddable as always. I was also thinking around the line

[clang] [llvm] [Clang][Coroutines] Improve CoroElide with [[clang::coro_structured_concurrency]] attribute for C++ (PR #94693)

2024-06-16 Thread Yuxuan Chen via cfe-commits
yuxuanchen1997 wrote: Thanks for the feedback. This patch is the first iteration to model this idea as quickly as I can. In general I agree with your comments > * I feel the name containing `concurrency` is not proper The name is bikesheddable as always. I was also thinking around the line of

[clang] [Serialization] Use specialized decl hash function for GlobalDeclID (PR #95730)

2024-06-16 Thread Chuanqi Xu via cfe-commits
https://github.com/ChuanqiXu9 edited https://github.com/llvm/llvm-project/pull/95730 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Serialization] Use specialized decl hash function for GlobalDeclID (PR #95730)

2024-06-16 Thread via cfe-commits
llvmbot wrote: @llvm/pr-subscribers-clang Author: Chuanqi Xu (ChuanqiXu9) Changes See the comment: https://github.com/llvm/llvm-project/pull/92083#issuecomment-2168121729 After the patch, https://github.com/llvm/llvm-project/pull/92083, the lower 32 bits of DeclID can be the same commonl

[clang] [Serialization] Use specialized decl hash function for GlobalDeclID (PR #95730)

2024-06-16 Thread Chuanqi Xu via cfe-commits
https://github.com/ChuanqiXu9 created https://github.com/llvm/llvm-project/pull/95730 See the comment: https://github.com/llvm/llvm-project/pull/92083#issuecomment-2168121729 After the patch, https://github.com/llvm/llvm-project/pull/92083, the lower 32 bits of DeclID can be the same commonly.

[clang] [Clang][AMDGPU] Add a new builtin type for buffer rsrc (PR #94830)

2024-06-16 Thread Shilei Tian via cfe-commits
https://github.com/shiltian updated https://github.com/llvm/llvm-project/pull/94830 >From 15ed0af5f5d23213fd4c10ff704ac26bb1b80030 Mon Sep 17 00:00:00 2001 From: Shilei Tian Date: Sun, 16 Jun 2024 23:07:29 -0400 Subject: [PATCH] [Clang][AMDGPU] Add a new builtin type for buffer rsrc --- clang

[clang] [llvm] [Clang][Coroutines] Improve CoroElide with [[clang::coro_structured_concurrency]] attribute for C++ (PR #94693)

2024-06-16 Thread Chuanqi Xu via cfe-commits
ChuanqiXu9 wrote: Then we can find that the frontend part is much more complex and harder than the middle end part. So maybe we can introduce the middle end part first and introduce a not so powerful attribute but introducing a function and statement level attribute `must_elide` in the beginn

[clang] [llvm] [Clang][Coroutines] Improve CoroElide with [[clang::coro_structured_concurrency]] attribute for C++ (PR #94693)

2024-06-16 Thread Chuanqi Xu via cfe-commits
ChuanqiXu9 wrote: Thanks for the patch. I like it in the very high level. I did a quick scanning over the PR and here is some comments: - I feel the name containing `concurrency` is not proper. I don't feel it relates concurrency in any level. - Every time we add or change IR related to corou

[clang] [clang][analyzer] use unqualified canonical type during merging equivalence class (PR #95729)

2024-06-16 Thread via cfe-commits
llvmbot wrote: @llvm/pr-subscribers-clang-static-analyzer-1 Author: Congcong Cai (HerrCai0907) Changes Fixes: #95658 Unqualified canonical type should be used instead of normal QualType for type equality comparison --- Full diff: https://github.com/llvm/llvm-project/pull/95729.diff 2

[clang] [clang][analyzer] use unqualified canonical type during merging equivalence class (PR #95729)

2024-06-16 Thread via cfe-commits
llvmbot wrote: @llvm/pr-subscribers-clang Author: Congcong Cai (HerrCai0907) Changes Fixes: #95658 Unqualified canonical type should be used instead of normal QualType for type equality comparison --- Full diff: https://github.com/llvm/llvm-project/pull/95729.diff 2 Files Affected: -

[clang] [clang][analyzer] use unqualified canonical type during merging equivalence class (PR #95729)

2024-06-16 Thread Congcong Cai via cfe-commits
https://github.com/HerrCai0907 created https://github.com/llvm/llvm-project/pull/95729 Fixes: #95658 Unqualified canonical type should be used instead of normal QualType for type equality comparison >From 40f18f2be624ed2a5b4922e67e4ed6070d2d2400 Mon Sep 17 00:00:00 2001 From: Congcong Cai Da

[clang] 15bb026 - [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (#75912)

2024-06-16 Thread via cfe-commits
Author: Chuanqi Xu Date: 2024-06-17T10:25:35+08:00 New Revision: 15bb02650e26875c48889053d6a9697444583721 URL: https://github.com/llvm/llvm-project/commit/15bb02650e26875c48889053d6a9697444583721 DIFF: https://github.com/llvm/llvm-project/commit/15bb02650e26875c48889053d6a9697444583721.diff LO

[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)

2024-06-16 Thread Chuanqi Xu via cfe-commits
https://github.com/ChuanqiXu9 closed https://github.com/llvm/llvm-project/pull/75912 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)

2024-06-16 Thread Chuanqi Xu via cfe-commits
@@ -6853,6 +6853,7 @@ void CodeGenModule::EmitTopLevelDecl(Decl *D) { if (ES->hasExternalDefinitions(D) == ExternalASTSource::EK_Never) DI->completeUnusedClass(*CRD); } + ChuanqiXu9 wrote: Done https://github.com/llvm/llvm-project/pull/7

[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)

2024-06-16 Thread Chuanqi Xu via cfe-commits
https://github.com/ChuanqiXu9 updated https://github.com/llvm/llvm-project/pull/75912 >From 4b595ee5b7a5fefb1e9ec0a152bce587ba463b4b Mon Sep 17 00:00:00 2001 From: Chuanqi Xu Date: Tue, 19 Dec 2023 17:00:59 +0800 Subject: [PATCH 1/8] [C++20] [Modules] [Itanium ABI] Generate the vtable in the m

[clang] [C++20] [Modules] [Itanium ABI] Generate the vtable in the module unit of dynamic classes (PR #75912)

2024-06-16 Thread Chuanqi Xu via cfe-commits
@@ -318,6 +318,9 @@ namespace { if (Diags.hasUnrecoverableErrorOccurred()) return; + if (RD->shouldEmitInExternalSource()) ChuanqiXu9 wrote: Thanks. It makes sense. https://github.com/llvm/llvm-project/pull/75912 __

[clang] [serialization] no transitive decl change (PR #92083)

2024-06-16 Thread Chuanqi Xu via cfe-commits
ChuanqiXu9 wrote: > I got to the bottom of it. The problem is that our hash function for 64 bit > ints is [not very > good](https://github.com/llvm/llvm-project/blob/d5297b72aa32ad3a69563a1fcc61294282f0b379/llvm/include/llvm/ADT/DenseMapInfo.h#L140). > > It will have a lot of collision when lo

[clang] [clang-format] Handle Verilog delay control (PR #95703)

2024-06-16 Thread via cfe-commits
https://github.com/sstwcw closed https://github.com/llvm/llvm-project/pull/95703 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] ef18986 - [clang-format] Handle Verilog delay control (#95703)

2024-06-16 Thread via cfe-commits
Author: sstwcw Date: 2024-06-17T01:46:04Z New Revision: ef18986b2033a44e69b7c3553a356e9037ac1413 URL: https://github.com/llvm/llvm-project/commit/ef18986b2033a44e69b7c3553a356e9037ac1413 DIFF: https://github.com/llvm/llvm-project/commit/ef18986b2033a44e69b7c3553a356e9037ac1413.diff LOG: [clang

[clang] [clang-format] Handle Verilog delay control (PR #95703)

2024-06-16 Thread via cfe-commits
https://github.com/sstwcw updated https://github.com/llvm/llvm-project/pull/95703 >From ef18986b2033a44e69b7c3553a356e9037ac1413 Mon Sep 17 00:00:00 2001 From: sstwcw Date: Sun, 16 Jun 2024 13:04:27 + Subject: [PATCH] [clang-format] Handle Verilog delay control (#95703) I made a mistake wh

[clang] [Clang][Sema] Skip checking anonymous enum in using enum declaration (PR #87144)

2024-06-16 Thread Qizhi Hu via cfe-commits
jcsxky wrote: > Hi @jcsxky , I fetched and rebased to origin/main just now (6/16/2024 at > 4:30pm Central US time), and rebuilt - and I see the crash. Did you try > rebasing to latest source and rebuilding? > > `$ clang --analyze -Xclang -analyzer-config -Xclang > experimental-enable-naive-ct

[clang] [clang][CodeGen] Add query for a target's flat address space (PR #95728)

2024-06-16 Thread Alex Voicu via cfe-commits
https://github.com/AlexVlx updated https://github.com/llvm/llvm-project/pull/95728 >From 2b500ad9ef2baf27da29146b5a4123dcb75e Mon Sep 17 00:00:00 2001 From: Alex Voicu Date: Mon, 17 Jun 2024 02:15:00 +0100 Subject: [PATCH] Add interface for exposing a target's flat address space, if it exi

[clang] [clang][CodeGen] Add query for a target's flat address space (PR #95728)

2024-06-16 Thread via cfe-commits
github-actions[bot] wrote: :warning: C/C++ code formatter, clang-format found issues in your code. :warning: You can test this locally with the following command: ``bash git-clang-format --diff 527e7328607ea0a55855e53a59c5030a7d07a554 2b500ad9ef2baf27da29146b5a4123dcb75e --

[clang] [clang][CodeGen] Add query for a target's flat address space (PR #95728)

2024-06-16 Thread Alex Voicu via cfe-commits
https://github.com/AlexVlx edited https://github.com/llvm/llvm-project/pull/95728 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][CodeGen] Add query for a target's flat address space (PR #95728)

2024-06-16 Thread via cfe-commits
llvmbot wrote: @llvm/pr-subscribers-clang Author: Alex Voicu (AlexVlx) Changes Often, targets which are not address space agnostic expose a flat/generic address space, which acts as a shared, legal target for address space casts. Whilst today we accidentally (e.g. by using `PointerType::

[clang] [clang][CodeGen] Add query for a target's flat address space (PR #95728)

2024-06-16 Thread Alex Voicu via cfe-commits
https://github.com/AlexVlx created https://github.com/llvm/llvm-project/pull/95728 Often, targets which are not address space agnostic expose a flat/generic address space, which acts as a shared, legal target for address space casts. Whilst today we accidentally (e.g. by using `PointerType::ge

[clang] [clang-format][NFC] Add FormatToken::isAccessSpecifierKeyword() (PR #95727)

2024-06-16 Thread via cfe-commits
llvmbot wrote: @llvm/pr-subscribers-clang-format Author: Owen Pan (owenca) Changes --- Full diff: https://github.com/llvm/llvm-project/pull/95727.diff 3 Files Affected: - (modified) clang/lib/Format/FormatToken.h (+11-9) - (modified) clang/lib/Format/TokenAnnotator.cpp (+21-23) - (m

[clang] [clang-format][NFC] Add FormatToken::isAccessSpecifierKeyword() (PR #95727)

2024-06-16 Thread Owen Pan via cfe-commits
https://github.com/owenca created https://github.com/llvm/llvm-project/pull/95727 None >From ec9b902518ef09d77e8b32777032a852d33476fd Mon Sep 17 00:00:00 2001 From: Owen Pan Date: Sun, 16 Jun 2024 17:47:56 -0700 Subject: [PATCH] [clang-format][NFC] Add FormatToken::isAccessSpecifierKeyword()

[clang] [clang][Parser] "Better" error messages for invalid template template (PR #95726)

2024-06-16 Thread via cfe-commits
llvmbot wrote: @llvm/pr-subscribers-clang Author: None (Veeloxfire) Changes For the somewhat easy mistake of `template