- User Since
- Jan 2 2013, 4:34 PM (246 w, 4 d)
Thu, Sep 21
Wed, Sep 20
lgtm, just nits
lgtm, I actually made this change as part of llvm.dbg.addr (D37768) and then reverted it to keep the diff minimal. Thanks!
Tue, Sep 19
Are you sure you can't reproduce this behavior by checking out the lit subtree with SVN before you deleted that directory, importing some .py files from that tree to create .pycs, and then doing svn up and checking if it creates a conflict? I'd really prefer to have an explanatory comment in here that says why we're setting this mysterious configuration.
Mon, Sep 18
Looks like the correct fix, thanks!
Fri, Sep 15
Closing this, I now realize this was a step in the wrong direction.
Would this help with https://bugs.llvm.org/show_bug.cgi?id=32021 ?
- Mostly s/MDNode/DILocalVariable/
Looks good, sounds like a plan: run lit.py like we used to if we don't have or can't find an llvm-lit.in to configure.
This is problematic because people already complain about how compiler-rt depends on the LLVM source tree for gtest sources: https://bugs.llvm.org/show_bug.cgi?id=33693
Thanks, looks good!
I do remember recommending this approach over IRC, but I thought we concluded that we should leave all the defaults in lib/Basic/Targets/ and make the -cc1 -fwchar-type= and -f[no-]signed-wchar overrides that affected all targets equally. That would avoid the need for these test updates, anyway.
Thu, Sep 14
Wed, Sep 13
lit.cfg.py still isn't a valid name for a python module. I had this idea that in the future we'd import the config module directly to simplify custom test formats defined in lit configuration files, which interact badly with multiprocessing.Pool. I guess that won't work well anyway since all the config files will have the same name, so we still have to move custom test formats out into well-named python modules.
I think this looks good, even without fixing the access control crash, this seems like a diagnostic improvement.
- implement Paul's comments
Tue, Sep 12
Looks good! Make sure to run check-clang and check-llvm. The CGDebugInfo.cpp change might affect clang codegen tests that generate debug info for DWARF.
Does this look good as is? I'd like to use this to gather some user feedback.
I think the main usage model this de-supports is putting tools on PATH and running lit.py directly on tests from the source directory like this:
PATH=$PATH:$build/bin llvm/utils/lit/lit.py llvm/test/Debug/X86/foo.ll
This is awesome! phab doesn't tell you the diffstat, so I patched it in, and it is: 177 insertions(+), 788 deletions(-) Nobody understood that code anyway, so this is great.
Nice! IIUC, now that the gnu ld driver works on Windows we can remove this logic. Thanks!
Mon, Sep 11
This should have an IRGen test. You can probably extend clang/test/CodeGenCXX/debug-info-ms-abi.cpp with a static method.
+1 for dropping the old names