zturner created this revision.
zturner added reviewers: stella.stamenova, labath, beanz, davide.
Herald added subscribers: jfb, delcypher, mgorny, ki.stfu.
A year or so ago, I re-wrote most of the lit infrastructure in LLVM so that it
wasn't so boilerplate-y. I added lots of common helper type s
stella.stamenova accepted this revision.
stella.stamenova added a comment.
This revision is now accepted and ready to land.
Looks good. The formatting in lit.cfg.py is a bit messy (indentations,
especially), but as long as the tests pass, this is an improvement :). Thanks!
https://reviews.llvm.
zturner added a comment.
In https://reviews.llvm.org/D54009#1284827, @stella.stamenova wrote:
> Looks good. The formatting in lit.cfg.py is a bit messy (indentations,
> especially), but as long as the tests pass, this is an improvement :). Thanks!
Is there something like clang-format for Pytho
This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB346008: Refactor the lit configuration files (authored by
zturner, committed by ).
Herald added subscribers: teemperor, abidh.
Changed prior to commit:
https://reviews.llvm.org/D54009?vs=172254&id=17
JDevlieghere added a comment.
Hi Zachary, looks like this broke GreenDragon:
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/12087/console
Can you have a look please?
Repository:
rLLDB LLDB
https://reviews.llvm.org/D54009
___
lldb-comm
zturner added a subscriber: stella.stamenova.
zturner added a comment.
Fix incoming, sorry about that.
Repository:
rLLDB LLDB
https://reviews.llvm.org/D54009
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/
stella.stamenova added a comment.
In https://reviews.llvm.org/D54009#1284839, @zturner wrote:
> In https://reviews.llvm.org/D54009#1284827, @stella.stamenova wrote:
>
> > Looks good. The formatting in lit.cfg.py is a bit messy (indentations,
> > especially), but as long as the tests pass, this i
stella.stamenova added a comment.
Several of the windows tests that invoke clang-cl have started failing recently
(I am not sure exactly when) and I suspect this change is the culprit. Were you
able to run the tests successfully with this change?
Repository:
rLLDB LLDB
https://reviews.llvm.
zturner added a comment.
I have not run the dotest suite recently, is that where you’re seeing the
failures? I successfully ran the lit suite and unit tests though
Repository:
rLLDB LLDB
https://reviews.llvm.org/D54009
___
lldb-commits mailing li
stella.stamenova added a comment.
In https://reviews.llvm.org/D54009#1290644, @zturner wrote:
> I have not run the dotest suite recently, is that where you’re seeing the
> failures? I successfully ran the lit suite and unit tests though
Yes, they are primarily in the lldb-suite but not only:
zturner added a comment.
It’s possible we lost some environment variable propagation, that would do
it. But I’m curious how it was finding the visual studio installation
before my patch.
It also looks like it’s failing finding link.exe (we really should make
lld-link the default). Another fix is
stella.stamenova added a comment.
I haven't verified this yet - but I suspect it is now picking up the clang-cl
that comes with VS rather than the one that was just built.
Repository:
rLLDB LLDB
https://reviews.llvm.org/D54009
___
lldb-commits m
zturner added a comment.
Actually maybe it’s the other way around. Are you specifying
LLDB_TEST_COMPILER? If it’s picking up VS’s version, it would definitely be
able to find link.exe
Repository:
rLLDB LLDB
https://reviews.llvm.org/D54009
___
lld
stella.stamenova added a comment.
The builds don't specify the two options for LLDB_TEST_C/CXX_COMPILER, so they
should be picking up the freshly build compilers. We don't have an option for
clang-cl though - so it's never been explicitly specified.
Repository:
rLLDB LLDB
https://reviews.ll
aleksandr.urakov added a comment.
I also have some strange failures on Windows x86 (I run tests from x64_86 MSVC
command line). If I locally revert this commit and 3 fix commits right after
this one, then all seems to work. Here is the failure:
C:\Work\llvm\build_x86\bin>llvm-lit.py -v
C:\Wo
aleksandr.urakov added a comment.
But all compiles without errors if I run this manually:
clang-cl -m32 /Z7 /c /GS-
C:\Work\llvm\tools\lldb\lit\SymbolFile\PDB/Inputs/SimpleTypesTest.cpp /o
C:\Work\llvm\build_x86\tools\lldb\lit\SymbolFile\PDB\Output/SimpleTypesTest.cpp.enums.obj
Repository:
zturner added a comment.
I think it must be related to setting up the environment in which to run
clang. In all other projects we call llvm_config.use_clang() which is in
llvm/utils/lit/lit/llvm/config.py, but because here we have an exact path
of a clang we are trying to use, we skip this functi
Fix incoming, sorry about that.
On Fri, Nov 2, 2018 at 2:57 PM Jonas Devlieghere via Phabricator <
revi...@reviews.llvm.org> wrote:
> JDevlieghere added a comment.
>
> Hi Zachary, looks like this broke GreenDragon:
> http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/12087/console
>
> Can y
I have not run the dotest suite recently, is that where you’re seeing the
failures? I successfully ran the lit suite and unit tests though
On Wed, Nov 7, 2018 at 1:32 PM Stella Stamenova via Phabricator <
revi...@reviews.llvm.org> wrote:
> stella.stamenova added a comment.
>
> Several of the windo
It’s possible we lost some environment variable propagation, that would do
it. But I’m curious how it was finding the visual studio installation
before my patch.
It also looks like it’s failing finding link.exe (we really should make
lld-link the default). Another fix is to pass -fuse-ld=lld or sp
Actually maybe it’s the other way around. Are you specifying
LLDB_TEST_COMPILER? If it’s picking up VS’s version, it would definitely be
able to find link.exe
On Wed, Nov 7, 2018 at 2:07 PM Stella Stamenova via Phabricator <
revi...@reviews.llvm.org> wrote:
> stella.stamenova added a comment.
>
>
I think it must be related to setting up the environment in which to run
clang. In all other projects we call llvm_config.use_clang() which is in
llvm/utils/lit/lit/llvm/config.py, but because here we have an exact path
of a clang we are trying to use, we skip this function in LLDB's lit
configura
I took a brief look and I have a question about the usage of clang (rather than
clang-cl).
In general I would agree that we have an exact path of clang (or gcc) that we
are trying to use and they’re specified by using %cc and %cxx in the test
files, but there are a number of test files that sim
I believe that is correct, and perhaps part of the problem. In other
projects we call llvm_config.use_clang(), and that actually explicitly
creates a substitution so that if someone writes "clang" they'll get an
error that says "use %clang instead". Because we have the exact path, that
isn't happ
I am not sure if that’s the right solution for a couple of reasons:
1. As far as I can tell only clang calls use_clang (and only lld calls
use_lld), while the other projects such as lld and llvm rely on the environment
to be setup correctly
2. Lld also has tests that invoke clang-cl and th
Actually, I take 2) back. Lld doesn’t call use_clang, but it only references
clang-cl, it doesn’t expect it to execute.
From: Stella Stamenova
Sent: Tuesday, November 13, 2018 3:47 PM
To: 'Zachary Turner'
Cc: reviews+d54009+public+0e164460da8f1...@reviews.llvm.org; pa...@labath.sk;
chris.biene.
On Tue, Nov 13, 2018 at 3:47 PM Stella Stamenova
wrote:
> I am not sure if that’s the right solution for a couple of reasons:
>
>1. As far as I can tell only clang calls use_clang (and only lld calls
>use_lld), while the other projects such as lld and llvm rely on the
>environment to
Ok so for dotest, it seems to be ignoring the config.cc and config.cxx
entirely. So we can theoretically do whatever we want with it, or change
around the directory structure so that it's more like:
lldb
* lit
* * Dotest
* * Unit
* * Tests
and put the config.cc / config.cxx logic under Tests. T
The plan for the lit tests sounds reasonable to me. I would also remove
LLDB_TEST_C/CXX_COMPILER entirely so that we can reduce confusion since they’re
only used for the lit tests, right?
My only concern is that I’ve been told that there are people who will build
lldb with a different compiler
use_clang() already will fall back on searching the environment variable
'CLANG' to find a path to it.
self.config.clang = self.use_llvm_tool(
'clang', search_env='CLANG', required=required)
But we could make this environment variable a parameter to use_clang() if
we wanted to
Simplifying (and making things more robust in the process) sounds great to me.
I think the current iteration of how parameters are passed to the tests is
quite complicated and unclear, so this will be a step in the right direction
and if there’s a need for gcc later, we can take the time to desi
I think I have a pretty good handle on what the problems are. I'm honestly
surprised the lit test suite ever worked, even before my patch that "broke"
it. We were basically just picking up whatever the system PATH was and
just going with it, so a lot of the substitutions weren't actually
substitu
32 matches
Mail list logo