I don't use this account anymore. New account name is "bulbazord"
- User Since
- Mar 21 2017, 11:50 AM (220 w, 4 d)
Mon, May 24
Dec 1 2020
May 26 2020
May 12 2020
May 11 2020
Mar 27 2020
we need to build our own and tell LLVM to use it
Mar 9 2020
Thanks for doing this. LGTM, might want to wait for Jason's approval like Jonas said though.
Mar 5 2020
LGTM. If UnwindLLDB is the unwinder, that makes things a little easier for plugin separation.
Mar 3 2020
Thanks for working to make LLDB more language-agnostic!
Mar 2 2020
I like the idea! The one thing that kind of bothers me about this is you can inadvertently break your build without realizing by disabling a plugin that some enabled plugins depend on. Hopefully one day we'll be able to improve the diagnostics around this.
Feb 7 2020
I like where this is going!
Feb 6 2020
I uploaded this patch primarily to get some feedback on possible alternatives because I'm not happy creating a dependency from Core to Target here. Suggestions welcome!
Feb 4 2020
Feb 3 2020
Jan 31 2020
Jan 30 2020
Move TypeSystemClang into its own plugin
Jan 29 2020
Jan 28 2020
Made obsolete by D73517
Jan 27 2020
Sort headers via clang-format
Note: This makes D69820 unnecessary so I will close that if this goes through.
Jan 23 2020
Implement @teemperor's suggestion
Jan 21 2020
Jan 17 2020
Jan 16 2020
Jan 14 2020
I like this idea quite a bit, but have no preference for ClangTypeSystem or TypeSystemClang. +1 from me.
Jan 13 2020
Jan 10 2020
The only things that have touched vim-lldb in the past 5-6 years have been the result of repository-wide changes (e.g. reformatting, documentation changes, python compatability and version transitions, etc).
Jan 8 2020
Jan 2 2020
It's nice to consolidate the logic into one place. I think you will probably need to make an appropriate change on the buildbot side as well (if you haven't done that already).
Dec 23 2019
Dec 17 2019
Adding @vsk since he added the code that you're referencing in your summary.
Dec 16 2019
Dec 12 2019
Landed as commit 3031818a2e9fca1e53cd882ccfcc3718699991b4
Dec 11 2019
Dec 10 2019
I personally prefer the third approach. To make sure I understand correctly, I'll write it in my own words so you can correct me if I misunderstood.
Try to find the dependency, and if we find it then use it. If not, then we can print out something like "Didn't find DEPENDENCY" and continue on our merry way. If the user overwrites the values and something goes wrong, send a fatal error and tell them that what the value they set isn't going to work without further work (e.g. explicitly enable python support but didn't find python? tell the user that you couldn't find python and maybe suggest setting some other CMake variables to help CMake find python).
Dec 9 2019
I'm really excited to see where this goes! :D
Address feedback from @teemperor
Nov 14 2019
Moved this change to the monorepo layout
Moved ClangASTContext::GetScratch to the ClangASTContext header