https://github.com/Endilll closed
https://github.com/llvm/llvm-project/pull/94208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/mizvekov approved this pull request.
https://github.com/llvm/llvm-project/pull/94208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Endilll wrote:
> How will this affect test capacity?
Evidence is anecdotal, but we're looking at about 4 more minutes on Linux CI.
https://github.com/llvm/llvm-project/pull/94208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.ll
mizvekov wrote:
@Endilll This looks good, thanks!
How will this affect test capacity? Right now, the Linux bots are lagging,
while the Windows bot is breezing through.
This is the opposite of the usual. Are we under-provisioned on Linux CI
resources? How much worse will it get when we add thi
Michael137 wrote:
> Given the libc++ experience, let's move forward with this PR as-is. If
> there's an issue in practice, we'll disable the tests on changes to Clang at
> that point.
Do note that libc++ CI only runs a subset of the LLDB tests. Only the ones that
are impacted by libc++. We co
https://github.com/AaronBallman edited
https://github.com/llvm/llvm-project/pull/94208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman approved this pull request.
Given the libc++ experience, let's move forward with this PR as-is. If there's
an issue in practice, we'll disable the tests on changes to Clang at that point.
https://github.com/llvm/llvm-project/pull/94208
___
AaronBallman wrote:
> FYI in the libc++ CI we've been running the LLDB tests for a few months now
> and I haven't seen a single unrelated failure.
Thanks, that's really useful information!
https://github.com/llvm/llvm-project/pull/94208
___
cfe-commi
philnik777 wrote:
FYI in the libc++ CI we've been running the LLDB tests for a few months now and
I haven't seen a single unrelated failure.
https://github.com/llvm/llvm-project/pull/94208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:
Endilll wrote:
>From my side as an author of the PR, I want to see Clang and LLDB code owners
>agree on the way forward, then I'll implement it if I can.
https://github.com/llvm/llvm-project/pull/94208
___
cfe-commits mailing list
cfe-commits@lists.ll
AaronBallman wrote:
I have no objections in theory, but in practice I remain concerned about the
flakiness of lldb's tests for the impacts on Clang reviewers.
There are timeout failures, but they might be limited to Windows and thus not a
problem with your PR (https://lab.llvm.org/buildbot/#/b
@@ -72,7 +72,7 @@ class PrintFunctionsConsumer : public ASTConsumer {
*sema.LateParsedTemplateMap.find(FD)->second;
sema.LateTemplateParser(sema.OpaqueParser, LPT);
llvm::errs() << "late-parsed-decl: \"" << FD->getNameAsString() <<
"\"\n";
-}
+
@@ -72,7 +72,7 @@ class PrintFunctionsConsumer : public ASTConsumer {
*sema.LateParsedTemplateMap.find(FD)->second;
sema.LateTemplateParser(sema.OpaqueParser, LPT);
llvm::errs() << "late-parsed-decl: \"" << FD->getNameAsString() <<
"\"\n";
-}
+
https://github.com/JDevlieghere approved this pull request.
https://github.com/llvm/llvm-project/pull/94208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/JDevlieghere edited
https://github.com/llvm/llvm-project/pull/94208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Endilll wrote:
@AaronBallman @JDevlieghere @Michael137 @adrian-prantl @DavidSpickett @mizvekov
I updated the PR to test LLDB on Clang changes. I hope we can start gathering
approvals to get this PR moving.
https://github.com/llvm/llvm-project/pull/94208
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/94208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/94208
>From 5c757153a3f462d40663add6a9ae7caf42272913 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Mon, 3 Jun 2024 13:33:36 +0300
Subject: [PATCH 1/9] Enable LLDB tests in pre-submit CI
---
.ci/generate-bui
https://github.com/Endilll updated
https://github.com/llvm/llvm-project/pull/94208
>From 5c757153a3f462d40663add6a9ae7caf42272913 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Mon, 3 Jun 2024 13:33:36 +0300
Subject: [PATCH 1/8] Enable LLDB tests in pre-submit CI
---
.ci/generate-bui
https://github.com/jthackray updated
https://github.com/llvm/llvm-project/pull/94208
>From 5c757153a3f462d40663add6a9ae7caf42272913 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov
Date: Mon, 3 Jun 2024 13:33:36 +0300
Subject: [PATCH 1/8] Enable LLDB tests in pre-submit CI
---
.ci/generate-b
mizvekov wrote:
> > 2. Build system does not support Multi-config generators. You can grep for
> > https://cmake.org/cmake/help/latest/variable/CMAKE_CFG_INTDIR.html as an
> > example.
>
> This simply isn't true. Xcode is a multi-config build system and we have [a
> bot](https://ci.swift.org/
slydiman wrote:
We have configured few buildbots for cross lldb tests with Windows x86_64,
Linux x86_64 hosts and Linux Aarch64 targets. Our main setup is Windows host
and currently it is 100% green. We still have a number of local patches. The
biggest changes are related to Makefile.rules to
JDevlieghere wrote:
> 1. Windows support
Windows support is definitely lacking which probably means a bunch of tests
don't run there. We do have [one
buildbot](https://lab.llvm.org/buildbot/#/builders/219) that runs on Windows so
I have a hard time believing it's totally broken. The last runs
medismailben wrote:
> if there's a PR with a clang label and it breaks an lldb test, then lldb
> reviewers get automatically added to the PR
I think it would be reasonable to have the CI add the last (or last few) git
author(s) for the failing test, to help investigate the issue on the lldb si
mizvekov wrote:
> Can you elaborate on what specifically you find hard? Building should be
> fairly straightforward, besides Python and SWIG, which are required to run
> the tests, most of our dependencies are optional. Unlike the compiler, the
> debugger is (1) tied to the system it's running
JDevlieghere wrote:
> But lldb sets itself apart in how hard it is to get a project setup going,
> and how impactful it is.
Can you elaborate on what specifically you find hard? Building should be fairly
straightforward, besides Python and SWIG, which are required to run the test,
most of our
mizvekov wrote:
I would normally have no issue making the changes needed to other projects, and
I mostly try to do that.
But lldb sets itself apart in how hard it is to get a project setup going, and
how impactful it is.
It's a bit concerning when the changes needed are quite trivial, for exam
AaronBallman wrote:
I had a nice chat with @ldionne and @nikic today and we touched on the topic of
precommit CI for lldb being triggered from Clang, and that resulted in a change
of opinion and perhaps a better way for me to phrase what I'm after and how it
relates to this PR.
I think that w
AaronBallman wrote:
> Following the logic in this argument, would you also say it's appropriate for
> someone to commit an LLVM patch that changes how textual LLVM IR is printed
> in a way that it breaks existing tests in Clang — without updating those
> tests?
Possibly! I'm talking about rel
adrian-prantl wrote:
> A revert is not appropriate when:
> lldb tests fail because AST printing has changed in Clang and the printed
> output is valid
Following the logic in this argument, would you also say it's appropriate for
someone to commit an LLVM patch that changes how textual LLVM IR
AaronBallman wrote:
> I would not agree with this specific wording. We have in the past and will in
> the future revert commits that break existing tests elsewhere in the LLVM
> project. If a patch to Clang breaks an existing test in LLDB, it's up to the
> author of the patch to work with the
JDevlieghere wrote:
+1 to what Adrian said. Taht certainly does **not** match my expectations. I'm
not sure why there would be a different policy for LLDB than for any of the
other monorepo projects.
https://github.com/llvm/llvm-project/pull/94208
__
adrian-prantl wrote:
> But also, changes in Clang that break lldb do not necessarily mean that a PR
> is not ready to land. There are conforming changes that can be made to Clang
> which lldb needs to react to as a downstream consumer of Clang as a library
> rather than a PR author needing to
mizvekov wrote:
> I think it makes a lot of sense for lldb to have a precommit CI pipeline
> which tests changes to lldb. I don't think we're at a point where it would
> make sense to enable lldb precommit CI testing for changes to clang, though.
>
> For starters, the false positive rate from
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/94208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Endilll edited
https://github.com/llvm/llvm-project/pull/94208
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
36 matches
Mail list logo
