- User Since
- Mar 23 2016, 8:38 AM (152 w, 9 h)
Sun, Feb 17
Sat, Feb 16
Fri, Feb 15
@labath Thanks for the hint with the sysroot, but I'm not really sure what's the best way to test this. Making a whole fake sysroot that can be used to compile a std module seems overkill, and not sure if symlinking or so is a good approach either. I'm open to suggestions.
- Rebase on top of Adrian's patch (Thanks!)
- Addressed the feedback from Shafik/Pavel.
- Added #ifdef for 3.8 release.
landed in llvm-svn: 354043
We could also check the libc++ version via _LIBCPP_VERSION and just keep the old code around behind an ifdef?
Thu, Feb 14
Ah yes, that also explains why the test suit failed. Fixed and the test now passes, thanks!
Tue, Feb 12
+1. That's a cleaner version of what I had to do in D58125, so feel free to commit when done. The code is similar enough that rebasing my patch on top shouldn't take too much time.
- Cleaned up setup method.
All the changes regarding extracting module include paths are probably superseded by Adrian's patch (which does the same thing nicer). So all the code related to GetModuleIncludes will be removed from this patch most likely.
Mon, Feb 11
Sun, Feb 10
@JDevlieghere I think this is the LLVM homepage (not LLDB), so I believe there is no RST file to edit?
Fri, Feb 8
Just trying to get some early feedback before I subscribe the mailing list. Also let me know if someone here also wants to mentor for this project and I'll add you.
Thu, Feb 7
Wed, Feb 6
LGTM for the CloneChecker changes.
Mon, Feb 4
Tue, Jan 29
LGTM, thanks for the patch!
Mon, Jan 28
Fri, Jan 25
Thu, Jan 24
- Added missing include.
Tue, Jan 22
So, the idea of going back to the headers and see if we can potentially remove mm_malloc from the modulemap didn't work out (mostly because a lot of headers include it indirectly).
Jan 21 2019
- Moved define to Xcode's Config.h (Thanks Pavel!)
I currently don't have access to a macOS machine and this only affects macOS, so I would appreciate if someone could check if this still compiles/works as intended. Otherwise I can also just commit it and watch the macOS bots.
- Added a comment that the using directives are created by Sema.
Jan 20 2019
- Moved code into the VisitFunctionDecl function.
Jan 15 2019
+1. Especially since our assumption that everything related to C++ is of non-zero size is also not entirely correct. Empty structs for example are actually size 0 for Clang until we reach code gen where we set their size to 1. That's why we have this bug where we can't call functions that return an empty struct.
Jan 13 2019
Didn't really upstream any non-trivial ASTImporter patches yet, so please point out any style errors.
Jan 9 2019
Jan 8 2019
Dec 11 2018
@joerg Yeah, we saw the commit explaining why the original fwd declaration patch was reverted. However, from what I can see, we only have three ways to fix the cyclic dependency between glibc and Clang's internal module:
Dec 10 2018
Dec 9 2018
This looks all good to me and from what see this was requested in a previous review (D44188). Do you need someone to commit this or did you receive commit access?
Dec 8 2018
Dec 6 2018
LGTM modulo the unrelated clang-format changes. Feel free to commit them separately (even though the m_event_names fix looks a bit strange).
Nov 29 2018
Nov 26 2018
Nov 11 2018
Do we also want to get rid of the // C Includes comments that are in some files? LLVM isn't using them either and just removing lines doesn't make git blame more complicated.
Nov 10 2018
LGTM, sorry for that!
Nov 4 2018
Yeah it uses the color settings of the diagnostic engine which are probably set to false in LLDB. I think activating colors there should fix the issue.
I think Pavel's point is to call the dump overload which allows specifying our own custom raw_ostream: https://clang.llvm.org/doxygen/classclang_1_1Decl.html#a278b3b87b6f9d3b20ed566a8684341a6 And our raw_ostream is configured by LLDB to correctly choose if we want color or not.
Nov 2 2018
Minor detail: The revision title only mentions Java, but this revision removes both Go and Java.
This looks nice, just added some minor comments below. Otherwise LGTM after Davide's point is addressed.