- User Since
- Mar 21 2017, 11:50 AM (130 w, 8 h)
Fri, Sep 13
Looks fine to me. Any objections @clayborg?
Thu, Sep 12
Rename function in question to CallVoidArgVoidPtrReturn
Rename InferiorCall to CallNoArgNoReturnFunc
make CallNoArgReturnFunc public
Wed, Sep 11
Tue, Sep 10
Mon, Sep 9
Fri, Sep 6
Refactored slightly to be a bit safer
Thu, Sep 5
Hmm, good question. If you call GetAPInt with a byte_size of 0, it should assert when trying to read 0 bytes with the DataExtractor. In the worst case, it gives you a broken APInt. I think guarded the call to GetAPInt to protect against this, but I think that it would also be a good idea to make GetAPInt return llvm::None in that case.
Wed, Aug 28
LGTM, small typo tho
Tue, Aug 27
Mon, Aug 26
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
Aug 14 2019
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.
Aug 13 2019
Aug 12 2019
I appreciate you adding more error handling. Thank you!
Aug 7 2019
Aug 6 2019
Aug 5 2019
Jul 31 2019
Jul 30 2019
Removed argument to GetScratchTypeSystems from SBTarget
Update GetScatchTypeSystems to account for changes to TypeSystem usage
Jul 29 2019
Small logic change in SBModule
Fix incorrect error logging pattern
Jul 26 2019
- 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
Jul 25 2019
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