- User Since
- Mar 21 2017, 11:50 AM (112 w, 5 d)
Fri, May 17
This broke windows buildbots. I tried to fix with svn r361083 but there were other things that got broken. @aadsm: We should revisit this patch next week and see what we need to fix up before it goes in.
Landed -- r361079
I like the idea of this commit, it seems like we can have lldb-vscode be more useful than just a DAP frontend to lldb.
Thu, May 16
I noticed you have lots of comments that say "Release has different values for these variables". I think that you could instead guard the Release configuration behind a check. For example:
if (CMAKE_BUILD_TYPE MATCHES Release) # Do the release configuration stuff here else() # Do the development configuration stuff here endif()
Seems like an overall improvement to the structure of this code. At the high level, the structure feels easier to understand.
Wed, May 15
Tue, May 14
Mon, May 13
- Fix minor bug in ItaniumABILanguageRuntime
- Modify test to accomodate new behavior
Unfortunately I can't land this patch as-is. With this patch applied, TestObjCExceptions fails. It looks like c++ exceptions are supported at the bare minimum as a part of the objc exception handling logic.
Fri, May 10
- Fix minor bug
- Return vector by value instead of passing in one by parameter.
Add comments to give better context
Thu, May 9
GetVariantMethodNames -> GetMethodNameVariants
Thanks for the feedback!
Tue, May 7
Ah, this was my bad. Thanks for taking care of this.
Mon, May 6
Thu, May 2
Looks like the right thing to do to me. As beanz said, selectively choosing is unneeded work.
Wed, May 1
Seems like the right thing to do.
Tue, Apr 30
Mon, Apr 29
Tue, Apr 23
Apr 18 2019
Apr 16 2019
Apr 8 2019
If you fail the parse the TTN of a symbol, demangler.Error should be true, no? That seems like a demangler error to me. :P
Apr 5 2019
Apr 4 2019
Apr 3 2019
So I ran the lldb test suite from a standalone build tree, and this patch didn't change anything. I added some logging to the CMake and LLVM_LIBRARY_DIR is being set correctly. It appears to be getting it from the LLVMConfig we get from find_package(LLVM). I think we could also get rid of LLVM_BINARY_DIR if that's the case, since it appears we only set it for lit.
Apr 2 2019
Mar 28 2019
Thank you for taking the time to write this up! I wish I could have read this when I started working on LLDB. :)
Mar 26 2019
Mar 25 2019
Added comment about verify
I changed the default behavior here setting file_spec to some known default unverified value to not setting it at all. It previously relied on there being a relative path to the clang resource dir, of which there are now two to pick from. Additionally, we pass in the directory containing liblldb to ComputeClangResourceDirectory now. The default behavior of HostInfo::ComputePathRelativeToLibrary was just computing it again and munging paths without verifying it. I think that if we fail to find the clang resource directory, the logs here should be sufficient to get started debugging.
- Respect LIBDIR for swift-lldb case
- Loop over a list of known directory suffixes
- Change default behavior to not set file_spec and return false upon failure.