SLES11 binaries for rc3 uploaded.
55b63de8adc12c67eb11abcf1a5f7132cca59b4e
clang+llvm-6.0.0-rc3-x86_64-linux-sles11.3.tar.xz
On Fri, Feb 23, 2018 at 9:14 AM, Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:
> Dear testers,
>
> 6.0.0-rc3 was just tagged, after r325901 o
> On Feb 23, 2018, at 3:17 PM, Vedant Kumar via lldb-dev
> wrote:
>
> Hi,
>
> At the moment, I'm seeing two issues with the unit tests on my machine.
>
> First, TestBase.LaunchModePreservesEnvironment is failing:
>
>> [ RUN ] TestBase.LaunchModePreservesEnvironment
>> /Users/vsk/src/llv
On 23 February 2018 at 16:19, Adrian McCarthy wrote:
> I'm also seeing windows appear and quickly vanish a several times while
> running the lit tests.
That's because the tests run inferiors and lldb on windows will always
run them in a separate console window. IIRC, there is a special hack
in do
Yeah, if a lit test fails, the dotest tests will not get run. That is
fine, but having a target which only runs dotest tests would probably
be nice as well.
On 23 February 2018 at 16:15, Vedant Kumar wrote:
> check-lldb-lit should just be a dependency of check-lldb, so the dotest.py
> tests shoul
https://bugs.llvm.org/show_bug.cgi?id=36494
Vedant Kumar changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Actually, it appears one of the lit tests is unexpectedly passing:
Unexpected Passing Tests (1):
lldb :: Expr/TestCallStdStringFunction.test
lit then returns an error code, and ninja bails before starting the
dotest.py tests:
FAILED: cmd.exe /C "cd /D D:\src\llvm\build\mono\tools\lldb\lit &&
check-lldb-lit should just be a dependency of check-lldb, so the dotest.py
tests should still run.
Are one of the lit tests failing? That might explain why subsequent tests
aren't run.
vedant
> On Feb 23, 2018, at 4:13 PM, Adrian McCarthy wrote:
>
> As of this afternoon, it seems ninja check
As of this afternoon, it seems ninja check-lldb runs *only* the lit tests
and not the dotest.py tests. Was this an intentional change?
On Fri, Feb 23, 2018 at 3:36 PM, Vedant Kumar via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Cool, I'll work up a patch for this.
>
> And thanks for commenting
Cool, I'll work up a patch for this.
And thanks for commenting on PR36494, I'm testing a fix out right now :).
vedant
> On Feb 23, 2018, at 3:35 PM, Pavel Labath wrote:
>
> On 23 February 2018 at 15:17, Vedant Kumar wrote:
>> Second, TestClient::SendMessage is generating quite a lot of "INFO"
On 23 February 2018 at 15:17, Vedant Kumar wrote:
> Second, TestClient::SendMessage is generating quite a lot of "INFO" output
> which clutters up the terminal. Pavel, would you mind if I removed this
> logging?
>
Yeah, we should probably do that. The idea here was that the packet
log would pro
Has anyone seen anything like this?
RESULT: PASSED (1 passes, 0 failures, 0 errors, 0 skipped, 0 expected
failures, 0 unexpected successes)
terminating with uncaught exception of type std::__1::system_error: mutex
lock failed: Invalid argument
[TestDataFormatterVarScriptFormatting.py FAILED]
It s
Hi,
At the moment, I'm seeing two issues with the unit tests on my machine.
First, TestBase.LaunchModePreservesEnvironment is failing:
> [ RUN ] TestBase.LaunchModePreservesEnvironment
> /Users/vsk/src/llvm.org-lldbsan/llvm/tools/lldb/unittests/tools/lldb-server/tests/LLGSTest.cpp:30:
> Fa
https://bugs.llvm.org/show_bug.cgi?id=36494
Bug ID: 36494
Summary: TestBase.LaunchModePreservesEnvironment is failing on
Darwin
Product: lldb
Version: unspecified
Hardware: PC
OS: MacOS X
Status:
A couple of things here:
- there should be no performance difference between doing build in
setUp and the test function as setUp is called once per test function
- my change was to run have the paralelization at a file level
(previously it was at folder-level). All test functions in a single
file a
https://bugs.llvm.org/show_bug.cgi?id=36435
Jim Ingham changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
I tried to put @skipIf(...) before setUp, but it didn't work. Currently I
have the build inside an if, checking for Hexagon. We don't support this use
of shared libraries, so all tests are skipped.
I certainly don't want to build the testcase 6 times, given that we're
moving away from that! But we
https://bugs.llvm.org/show_bug.cgi?id=36490
lab...@google.com changed:
What|Removed |Added
CC||lab...@google.com
Resolution|---
https://bugs.llvm.org/show_bug.cgi?id=36490
Bug ID: 36490
Summary: Segmentation fault when accessing any Python script
object
Product: lldb
Version: 3.6
Hardware: Other
OS: Linux
Status: NEW
Dear testers,
6.0.0-rc3 was just tagged, after r325901 on the branch.
There are still a few open blockers, but I'm not sure we'll actually
end up blocking on all of them. So depending on what comes up, this
release candidate is probably pretty close to what the final release
will look like (I'm s
On Wed, Feb 21, 2018 at 4:48 PM Hans Wennborg wrote:
>
> Alex: There seems to be good release notes for clang-tidy, but do you
> know if there should be notes for the others tools? Who are the right
> people to ping about this?
>
Adding folks responsible for clangd and some other tools.
Ah, ok so the default DWARF version for g++ 5 (and 6) is 2, compiling with
-gdwarf-3 solves my problem.
Thanks for the help,
Bryan.
On Thu, 22 Feb 2018 at 17:02 Greg Clayton wrote:
>
>
> On Feb 19, 2018, at 1:51 AM, Bryan Bennetts via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi,
>
> Ap
21 matches
Mail list logo
