tru wrote:
@steakhal you can cherry-pick both at the same time with cherry-pick
that works for me.
https://github.com/llvm/llvm-project/pull/151908
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listin
tru wrote:
@zwuis do you need someone to merge the PR for you?
https://github.com/llvm/llvm-project/pull/153593
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tru approved this pull request.
https://github.com/llvm/llvm-project/pull/153593
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
> @tru In that case it might make sense to switch to the libcxx model where all
> the release notes are versioned (see
> https://github.com/llvm/llvm-project/tree/main/libcxx/docs/ReleaseNotes) and
> then just the latest one included on the unversioned page?
Yes this is probably a
tru wrote:
Maybe out of scope for this PR - but I wonder if we should just copy the
release notes to ReleaseNotes-LLVM21.rst instead of just nuking them from main.
That would make it easier to see what recently happened and not much of a
difference for the script.
What do you guys think @tste
tru wrote:
Hi this is great! Thanks for doing this. There are some things that might need
to happen in libc++ as well. Is that something we can automate in this script
@ldionne @philnik777 ?
https://github.com/llvm/llvm-project/pull/153593
___
cfe-co
tru wrote:
The conflict in ReleaseNotes has to be fixed. I am happy to have this
compatibility fixed since we ran into it at some point. I am guessing that
reviews can be slower during summer. Maybe @aganea or @efriedma-quic could have
a look (again).
https://github.com/llvm/llvm-project/pull
https://github.com/tru approved this pull request.
https://github.com/llvm/llvm-project/pull/149988
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Oh never mind @AaronBallman I just noticed that this PR was targeting `main`
and not the release branch, ignore my comments! It just ended up in my review
queue since it's in the milestone and I didn't pay attention!
https://github.com/llvm/llvm-project/pull/150282
_
tru wrote:
> > @AaronBallman can you squash this? (release procedure is a bit different so
> > we prefer to get it pre-squashed).
>
> Sure, but I'm not certain we should have a different merge strategy for main
> vs release branches so I'd like to understand more about what's driving this.
>
tru wrote:
@AaronBallman can you squash this? (release procedure is a bit different so we
prefer to get it pre-squashed).
https://github.com/llvm/llvm-project/pull/150282
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
tru wrote:
> > How much slower is this? Last time I tested fatlto in our toolchain it took
> > a VERY long time to link.
>
>
>
> You're probably thinking about "full" LTO, this is fat thin LTO. Our naming
> is truly amazing. See https://llvm.org/docs/FatLTO.html.
>
>
>
> It should add abo
tru wrote:
How much slower is this? Last time I tested fatlto in our toolchain it took a
VERY long time to link.
https://github.com/llvm/llvm-project/pull/140381
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/m
tru wrote:
> @tru - would you be happy for me to backport this to the LLVM 21 release
> branch to complete the DTLTO feature?
Yes!
https://github.com/llvm/llvm-project/pull/147265
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists
https://github.com/tru closed https://github.com/llvm/llvm-project/pull/139504
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Sorry for the delay. I have addressed both your comments now @benlangmuir -
reworked it to use Lexer::getEscapedNewLineSize() and removed the assertline. I
also expanded the test coverage.
https://github.com/llvm/llvm-project/pull/139504
_
https://github.com/tru updated https://github.com/llvm/llvm-project/pull/139504
>From 859723743a51bc75d855b4ee924ea5cf86e26183 Mon Sep 17 00:00:00 2001
From: Tobias Hieta
Date: Mon, 5 May 2025 11:40:17 +0200
Subject: [PATCH 1/5] [clang][scandeps] Improve handling of rawstrings.
The current pars
https://github.com/tru updated https://github.com/llvm/llvm-project/pull/139504
>From 859723743a51bc75d855b4ee924ea5cf86e26183 Mon Sep 17 00:00:00 2001
From: Tobias Hieta
Date: Mon, 5 May 2025 11:40:17 +0200
Subject: [PATCH 1/4] [clang][scandeps] Improve handling of rawstrings.
The current pars
https://github.com/tru updated https://github.com/llvm/llvm-project/pull/139504
>From 859723743a51bc75d855b4ee924ea5cf86e26183 Mon Sep 17 00:00:00 2001
From: Tobias Hieta
Date: Mon, 5 May 2025 11:40:17 +0200
Subject: [PATCH 1/3] [clang][scandeps] Improve handling of rawstrings.
The current pars
https://github.com/tru approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/142195
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tru created https://github.com/llvm/llvm-project/pull/139504
The current parser just checks one step back for a R before each string to know
that it's a rawstring. But the preprocessor is much more advanced here and can
have constructs like:
R\
"str"
And much more. This pat
https://github.com/tru approved this pull request.
https://github.com/llvm/llvm-project/pull/128090
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -90,9 +88,17 @@ else()
set(CLANG_BOOTSTRAP_TARGETS ${LLVM_RELEASE_FINAL_STAGE_TARGETS} CACHE STRING
"")
endif()
+if (LLVM_RELEASE_ENABLE_LTO)
+ # Enable LTO for the runtimes. We need to configure stage1 clang to default
+ # to using lld as the linker because the stage
https://github.com/tru approved this pull request.
https://github.com/llvm/llvm-project/pull/127268
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tru commented:
Just one question.
https://github.com/llvm/llvm-project/pull/127268
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -90,9 +88,17 @@ else()
set(CLANG_BOOTSTRAP_TARGETS ${LLVM_RELEASE_FINAL_STAGE_TARGETS} CACHE STRING
"")
endif()
+if (LLVM_RELEASE_ENABLE_LTO)
+ # Enable LTO for the runtimes. We need to configure stage1 clang to default
+ # to using lld as the linker because the stage
https://github.com/tru edited https://github.com/llvm/llvm-project/pull/127268
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
> Great. Actually, we wanted to add support for distributing via FASTBuild,
> icecream and distcc with the initial DTLTO PR. However, we investigated found
> that these couldn't be supported without extending the existing codebases.
> More details to follow..
Interesting. Intereste
tru wrote:
> > ⚠️ C/C++ code formatter, clang-format found issues in your code. ⚠️
> > You can test this locally with the following command:
> > View the diff from clang-format here.
>
> I believe this failure is OK as I have followed the (non-standard) formatting
> in the flagged file which th
https://github.com/tru edited https://github.com/llvm/llvm-project/pull/126654
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -969,6 +969,10 @@ def Xlinker : Separate<["-"], "Xlinker">,
Flags<[LinkerInput, RenderAsInput]>,
Visibility<[ClangOption, CLOption, FlangOption]>,
HelpText<"Pass to the linker">, MetaVarName<"">,
Group;
+def Xdist : Separate<["-"], "Xdist">, Flags<[LinkOption]>,
@@ -116,7 +117,18 @@ BitcodeCompiler::BitcodeCompiler(COFFLinkerContext &c) :
ctx(c) {
// Initialize ltoObj.
lto::ThinBackend backend;
- if (ctx.config.thinLTOIndexOnly) {
+ if (!ctx.config.DTLTODistributor.empty()) {
+StringRef version = getenv("LLD_VERSION"); // F
https://github.com/tru commented:
Hello! I had a quick glance at this and while I am no expert in the actual LTO
internal code, I was totally able to understand how we could integrate this
with our build system (fastbuild) so I am really happy you have decided to
upstream this. I am planning o
tru wrote:
Just saw this in LLVM weekly. But this is not supported on Windows right? Only
the UNIX platforms that can mmap? In that case it the limitation needs to be
documented
https://github.com/llvm/llvm-project/pull/124353
___
cfe-commits mail
tru wrote:
Yeah. It's still on my list to update the patch to be recursive - but it's been
a pretty busy period and I haven't gotten around to it yet.
https://github.com/llvm/llvm-project/pull/88857
___
cfe-commits mailing list
cfe-commits@lists.llvm
tru wrote:
I can recommend the hyperfine tool when benchmarking. It runs the same command
multiple times and does all the fancy things to make sure you are measuring
correctly.
https://github.com/llvm/llvm-project/pull/114260
___
cfe-commits mailing
@@ -0,0 +1,13 @@
+// This test checks if Window PE file compiled with -flto option contains a
magic
+// string "LTCG" to indicate LTO compilation.
+
+// REQUIRES: system-windows
+
+// RUN: %clang --target=x86_64-pc-windows-msvc -flto -fuse-ld=lld %s -o %t.exe
tr
tru wrote:
You can consolidate the tests into a single cpp file instead of having three
different ones.
https://github.com/llvm/llvm-project/pull/114260
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:
https://github.com/tru commented:
Thanks for working on this. It's always good to be compatible with MSVC as much
as possible. Some comments and questions. We also need some more people that
know more COFF to weigh in.
https://github.com/llvm/llvm-project/pull/114260
_
@@ -0,0 +1,13 @@
+// This test checks if Window PE file compiled with -flto option contains a
magic
+// string "LTCG" to indicate LTO compilation.
+
+// REQUIRES: system-windows
+
+// RUN: %clang --target=x86_64-pc-windows-msvc -flto -fuse-ld=lld %s -o %t.exe
+// RUN: dumpbin /H
@@ -1165,6 +1188,23 @@ void Writer::createMiscChunks() {
llvm::TimeTraceScope timeScope("Misc chunks");
Configuration *config = &ctx.config;
+ auto searchForPgoMagicSection = [this](char sectionName[]) {
tru wrote:
How expensive is this recursive search
https://github.com/tru edited https://github.com/llvm/llvm-project/pull/114260
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tru approved this pull request.
LGTM! Thanks for doing that!
https://github.com/llvm/llvm-project/pull/112378
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tru approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/108725
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
> @tru No, this is my first llvm pr. I'd appreciate you doing it :)
Thanks for your contribution!
https://github.com/llvm/llvm-project/pull/106369
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailma
https://github.com/tru closed https://github.com/llvm/llvm-project/pull/106369
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Yeah it needs to be towards the 19.x release branch as I described in my
comment here
https://github.com/llvm/llvm-project/pull/107964#issuecomment-2352261158
https://github.com/llvm/llvm-project/pull/108801
___
cfe-commits mailing list
c
tru wrote:
Create a branch from `release/19.x` in your own fork, then cherry-pick over the
changes from `main`, edit them to match the things we talked about above (and
fix any merge problems). Then submit a PR that wants to merge `yourbranch` into
`release/19.x`. And check the checkbox `maint
tru wrote:
@nebulark do you have commit access to merge this? otherwise I can do it for
you.
https://github.com/llvm/llvm-project/pull/106369
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-c
tru wrote:
@ganeshgit or @RKSimon can one of you put up a PR against release/19.x with the
abi compatible changes so that we have chance to look at it and approve it
before the release tomorrow.
https://github.com/llvm/llvm-project/pull/107964
___
cf
tru wrote:
I think it's better it land as it should be in `main` and then you can create a
new PR against the ` release/19.x` branch with the different enum layout.
https://github.com/llvm/llvm-project/pull/107964
___
cfe-commits mailing list
cfe-comm
tru wrote:
> It would be messy, but could we not place the CK_ZNVER5 enum entry at the end
> of the enum list just for 19.x and then fix the sorting in trunk?
I would be fine with that. WDYT @nikic ?
https://github.com/llvm/llvm-project/pull/107964
_
tru wrote:
> The change to X86TargetParser.h looks ABI breaking to me.
This seems unfortunate to me. But I don't think it would be good to insert the
enum at the end of the list and changing the sorting order.
How big of a problem would it be with a ABI break now? I know you have
requested th
https://github.com/tru approved this pull request.
LGTM. Let's remove it.
https://github.com/llvm/llvm-project/pull/108342
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
This was suggested in https://github.com/llvm/llvm-project/pull/91856 and the
suggestion there was that we need to split it up per sub-project which is
something @e-kwsm has been doing:
https://github.com/llvm/llvm-project/pulls/e-kwsm so I don't think this one is
needed.
https://
tru wrote:
Do we still need to fix this for 19.1.0-final?
https://github.com/llvm/llvm-project/pull/100091
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
> Though having said all this, I marked this for LLVM 19 as my reading of
> https://discourse.llvm.org/t/update-on-llvm-19-x-releases/80511 was that new
> features are still ok before RC2, but re-reading it it's a bit ambiguous: it
> says "New features will have to wait until LLVM 2
tru wrote:
This seems to add a new feature, is it really relevant for a backport?
https://github.com/llvm/llvm-project/pull/99335
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tru approved this pull request.
https://github.com/llvm/llvm-project/pull/98431
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Hmm. It's a bit worrying that we can't have the tests running... I wonder what
the workflow would be here since we need to verify before we run the binaries.
What's the problem with the tests currently?
https://github.com/llvm/llvm-project/pull/98431
tru wrote:
I don't have the bandwidth to get a RFC through right now. If this is broken
and no-one wants to take care of getting consensus for something new, I suggest
you revert to the previous state. For my toolchain I can continue to carry a
patch until this is all sorted.
https://github.c
https://github.com/tru approved this pull request.
https://github.com/llvm/llvm-project/pull/90138
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Did you consider the parallel setting as well?
https://github.com/llvm/llvm-project/pull/90138
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Yeah I think this should be brought up as an RFC in discourse. I would like to
see that we move away from two different layouts and just adopt one (my
preference is the new layout, but honestly - I don't feel that strongly about
it).
https://github.com/llvm/llvm-project/pull/89775
tru wrote:
It needs a release note and documentation though.
https://github.com/llvm/llvm-project/pull/89775
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
I think this is fine. I probably have to carry a one line patch in our tree to
make it the default on windows as well. But that's acceptable to me.
https://github.com/llvm/llvm-project/pull/89775
___
cfe-commits mailing list
cfe-commits@li
@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl
GD) const {
static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty,
CodeGenModule &CGM) {
+ // If the record is marked with the trivial_abi attribute, we don'
tru wrote:
ping on this.
https://github.com/llvm/llvm-project/pull/88857
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
If this is for permanent storage I suggest we use TXZ instead, since it has
better compression. You should also set CPACK_ARCHIVE_THREADS to something
higher than the default (1). Since xz really benefits from this.
https://github.com/llvm/llvm-project/pull/90138
___
https://github.com/tru approved this pull request.
https://github.com/llvm/llvm-project/pull/90139
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
I think I suggested that we should make the CMake variable change the driver
behaviour to reflect the setting in order to remove unexpected fallbacks and
that the vendor could select the layout. I still think that's probably the
better solution.
https://github.com/llvm/llvm-projec
tru wrote:
> > LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=on
>
>
>
> I'm unable to find what code this affects. I don't see it mentioned anywhere
> in clang/lib or clang/include.
>
>
>
> It does seem like it should control the behavior of
> `ToolChain::getCompilerRT`; where I had added the Windo
https://github.com/tru approved this pull request.
I find changes to the multi-stage build caches a bit confusing to review
without being able to see the cache that's generated. But I trust that you have
tested this and it works as expected, In that case you can merge this.
https://github.com/
https://github.com/tru approved this pull request.
https://github.com/llvm/llvm-project/pull/89517
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
And I think it's better to revert it all instead of implementing this
half-revert in this PR in that case and then we should discuss how to move
forward.
https://github.com/llvm/llvm-project/pull/89775
___
cfe-commits mailing list
cfe-comm
tru wrote:
Honestly - I think going back to *one* style of runtime path is to be preferred
now. But I don't think it's fair to say that it doesn't solve any problems,
because we switched to it so that we could ship more platforms in one toolchain
package without having to add cfg files and sim
tru wrote:
I agree that if downstream want to change stuff, they need to engage. We can't
guess what microsoft wants to do (or sony) unless we have a discussion about
it. This is also documented in the developer policy. If there are missed
release notes, they need to be added of course.
That
tru wrote:
It's been like that for maybe 2-3 years now and no one has complained about it,
so I think that change is solid. I can suggest a CMake change, but last time it
was discussed I think @maskray was against a new variable, but since we might
need to have some different behaviour it migh
tru wrote:
We have a custom toolchain that uses the new style on windows and if you build
with runtimes on windows (which is the suggested way) it will end up with the
new style without arch suffix. I don't think we can assume this is correct for
windows in all setups. I am fine with this chan
tru wrote:
The final decision is Toms, but I don't think it qualifies since we are so late
in the current process and that 19 will start in just a few months.
https://github.com/llvm/llvm-project/pull/87392
___
cfe-commits mailing list
cfe-commits@li
@@ -1105,6 +1105,11 @@ bool MicrosoftCXXABI::hasMostDerivedReturn(GlobalDecl
GD) const {
static bool isTrivialForMSVC(const CXXRecordDecl *RD, QualType Ty,
CodeGenModule &CGM) {
+ // If the record is marked with the trivial_abi attribute, we don'
tru wrote:
@efriedma-quic are you ok with this change?
https://github.com/llvm/llvm-project/pull/88857
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tru updated https://github.com/llvm/llvm-project/pull/88857
>From 08214d87d1a7c83ea25eef3bf18de1568a20a152 Mon Sep 17 00:00:00 2001
From: Tobias Hieta
Date: Tue, 16 Apr 2024 09:38:53 +0200
Subject: [PATCH] [clang] Handle trivial_abi attribute for Microsoft ABI.
Previously the
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -std=c++11 -fcxx-exceptions
-fexceptions -emit-llvm -o - %s | FileCheck %s
+
+// CHECK: %[[STRUCT_TRIVIAL:.*]] = type { ptr }
+struct __attribute__((trivial_abi)) Trivial {
+ int *p;
+ Trivial() : p(0) {}
+ Tr
https://github.com/tru created https://github.com/llvm/llvm-project/pull/88857
Previously the trivial_abi was ignored for records when targetting the
microsoft abi, the MSVC rules where always enforced to ensure compatibility
with MSVC. This commit changes it to be closer to the itanium abi whe
tru wrote:
> I think .natvis files should be CRLF (those are used with Visual Studio for
> debug visualizers).
Agreed, Visual Studio should handle this correctly, but who knows 🤷🏼
https://github.com/llvm/llvm-project/pull/86318
___
cfe-commits maili
@@ -2410,20 +2410,35 @@ usual build cycle when using sample profilers for
optimization:
1. Build the code with source line table information. You can use all the
usual build flags that you always build your application with. The only
- requirement is that you add ``-glin
@@ -2410,20 +2410,35 @@ usual build cycle when using sample profilers for
optimization:
1. Build the code with source line table information. You can use all the
usual build flags that you always build your application with. The only
- requirement is that you add ``-glin
@@ -2410,20 +2410,35 @@ usual build cycle when using sample profilers for
optimization:
1. Build the code with source line table information. You can use all the
usual build flags that you always build your application with. The only
- requirement is that you add ``-glin
https://github.com/tru commented:
Thanks for working on documentation!
https://github.com/llvm/llvm-project/pull/84864
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tru edited https://github.com/llvm/llvm-project/pull/84864
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tru approved this pull request.
This seems good to me, it worked in my internal test as I expected it!
https://github.com/llvm/llvm-project/pull/81037
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi
tru wrote:
cc @sylvain-audi
https://github.com/llvm/llvm-project/pull/81677
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
I haven't checked closely yet, but it seems like you need to add tests.
https://github.com/llvm/llvm-project/pull/79390
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/tru approved this pull request.
https://github.com/llvm/llvm-project/pull/78823
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
Thanks @owenca !
https://github.com/llvm/llvm-project/pull/78682
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
@owenca What's the things that still needs to be addressed for this to land?
https://github.com/llvm/llvm-project/pull/70338
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
tru wrote:
@tomekpaszek Hi Tomek, do you think you will have time to work on this soon?
Otherwise, I can probably finish it off for you since we also want this feature.
https://github.com/llvm/llvm-project/pull/70338
___
cfe-commits mailing list
cfe-c
@@ -10,112 +10,70 @@ on:
- 'llvmorg-*'
jobs:
- release-tasks:
-permissions:
- contents: write # To upload assets to release.
+ validate-tag:
+name: Validate Tag
runs-on: ubuntu-latest
if: github.repository == 'llvm/llvm-project'
+outputs:
+
@@ -0,0 +1,74 @@
+name: Release Lit
+
+permissions:
+ contents: read
+
+on:
+ workflow_dispatch:
+inputs:
+ release-version:
+description: 'Release Version'
+required: true
+type: string
+
+ workflow_call:
+inputs:
+ release-version:
+
1 - 100 of 161 matches
Mail list logo
