On Tue, Oct 20, 2015 at 8:22 PM, Greg Clayton wrote:
> Then try running and let me know what your results are!
Hm, there seems to be something seriously wrong. I triple-checked
everything, but Declaration::Compare is not even called when the error
is triggered! How should we
I'm in favor of (b). The less user-required setup to do the right thing on
a test suite, the better IMHO. Those actively trying to make sure one or
another c++ library is getting tested will be looking for the output to
validate which std c++ lib(s) ran.
-Todd
On Wed, Oct 21, 2015 at 3:47 AM,
Oh haha okay. :-)
Thanks for explaining, Ying!
-Todd
On Wed, Oct 21, 2015 at 10:01 AM, Ying Chen wrote:
> Yes, the output of dotest.py goes through LitTestCommand parse.
> The parser is matching for "XPASS", but dotest output is using "UNEXPECTED
> SUCCESS". :)
>
> Thanks,
Yes, the output of dotest.py goes through LitTestCommand parse.
The parser is matching for "XPASS", but dotest output is using "UNEXPECTED
SUCCESS". :)
Thanks,
Ying
On Tue, Oct 20, 2015 at 6:34 PM, Todd Fiala wrote:
> Hi Ying,
>
> Our dotest.py lldb test results go
So first, an addendum: I found a way to make the project build without
using a symlink, and use a direct reference instead. The problem still
persists. It may be that symlink is one of the problems, but it is
certainly not the only problem.
On Tue, Oct 20, 2015 at 8:22 PM, Greg Clayton
I seen very similar error messages when debugging an application compiled
with fission (split/dwo) debug info on Linux with a release version of LLDB
compiled from ToT. When I tested the same with a debug or with a
release+assert build I hit some assertion inside clang. It might worth a
try to
I think it was mostly done to provide an exception safe way to cleanup stuff
without having to override TestBase.tearDown(). I am guessing this cleanup
happens on TestCase.tearDown() and not after the current test case right?
I could see it being used to cleanup after a single test case in
one main benefit to doing this externally is allow this to be done remotely
over any debugger connection. If you can run expressions to
enable/disable/setup the memory buffer/access the buffer contents, then you
don't need to add code into the debugger to actually do this.
Greg
> On Oct 21,
I think we can remove these, provided there is a way to mimic the
functionality they are used for now, which I think shouldn't be hard.
Anything which was set up in the setUp() method should be undone in
tearDown(). Anything which was set up in the test method, can be
undone using a try-finally
[moving this to lldb-dev for more visibility.]
Sorry, I was in a hurry yesterday, so I did not explain myself fully. Let
me try to elaborate.
> What I am trying to avoid here is getting useless noise in build
automation where test cases proclaim their failure, which however tells us
nothing of
10 matches
Mail list logo