Thu, Aug 22
Tue, Aug 20
I wouldn't mind adding something to reduce boilerplate, but I'm not sure it would actually look too different. A wrapper function or subclass constructor would need to take a ClangASTContext and a clang::QualType so we could avoid calls to getAsOpaquePtr() everywhere but that's about it I think?
Mon, Aug 19
Case-sensitive filesystems lol
Wed, Aug 14
I like the idea of using something from llvm instead of rolling our own. The code changes look relatively simple and straightforward, so that's good.
Tue, Aug 13
Mon, Aug 12
I appreciate you adding more error handling. Thank you!
Wed, Aug 7
Tue, Aug 6
Mon, Aug 5
Wed, Jul 31
Tue, Jul 30
Removed argument to GetScratchTypeSystems from SBTarget
Update GetScatchTypeSystems to account for changes to TypeSystem usage
Mon, Jul 29
I think this change has introduced a dependence on x64.
I tried building with the 32b Visual Studio compiler and there are a number of undefined registers in registercontextwindows_x64.cpp.
This is because the version of _CONTEXT included by winnt.h is for x32 and not x64.
i.e., llvm-project\lldb\source\plugins\process\windows\common\x64\registercontextwindows_x64.cpp(297): error C2039: 'Rax': is not a member of '_CONTEXT'
Small logic change in SBModule
I have one remark about the consumeError+LLDB_LOG pattern. As for whether this is better than status quo or not, I still don't have an opinion on that. :)
Fix incorrect error logging pattern
Fri, Jul 26
- Use Expected<TypeSystem&>
- Did some formatting
- Made error checking more explicit
I'm going to update this diff with what I changed to give y'all a better idea of what has been changed. I shoulda done that to begin with... :P
Thu, Jul 25
After going through this and modifying this patch, I can't help but wonder if llvm::Optional<TypeSystem &> would be more appropriate. There are plenty of instances where it's not a hard error if you can't get a TypeSystem and the appropriate action is probably just to log and move on. I am conflicted because I like how Expected forces you to be more rigorous with error handling but I can't help but feel it is the wrong abstraction. Thoughts?
I think this is fine. Using .def files would be okay too, but I like the sanity checks that Jonas introduced in the LLDBPropertyDefEmitter
Jul 24 2019
Jul 23 2019
Jul 22 2019
Thanks for restoring them.
Jul 19 2019
Actually from the looks of it, I completely misunderstood what's going on here. It looks like AddToMap should only be called by things that hold the mutex, meaning that this change isn't actually necessary. I do think that makes this code kind of frustrating to understand though. Closing.
Excellent, thanks for taking care of this! :)
Jul 18 2019
All uses of this new function drop the error on the ground. Does that mean it doesn't matter? If it does, should we return an expected instead? Should we stop on the first error, or is it fine to overwrite when iterating over languages_for_expressions? It seems like the error handling needs some more work here.