- User Since
- Aug 15 2014, 7:40 AM (283 w, 3 d)
Fri, Jan 10
Updated the patch to refactor mode code.
Thu, Jan 9
Wed, Jan 8
Remove some FIXMEs that are now done.
Change the approach: handle type merging for tag types using the ODRHash mechanism
Dec 19 2019
Dec 12 2019
Nov 22 2019
I have to assume there was a point in the past where they were just one class, but it's been pretty confusing for a while. I think it's time to fix it.
Nov 14 2019
Nov 12 2019
LGTM with some minor comment below!
Nov 11 2019
Oct 29 2019
Oct 18 2019
While adding the documentation I realized that a better name for this option would be -fmodules-strict-context-hash to make it clear which hash it's referring to.
Oct 17 2019
*using implicit modules in a build where compiler flags in different invocations aren't homogeneous, or something along those lines.
LGTM with one minor change. Can you add an entry in the modules docs for this flag and mention that using it can lead to more PCMs in an implicit build?
Oct 15 2019
Oct 14 2019
This approach looks overall much better! Unless @sammccall has any extra comments, it LGTM.
Hi Michael, thanks for working on this!
Oct 1 2019
Sep 16 2019
Sep 13 2019
Did you try xxHash64?
Sep 10 2019
Update the patch to use two ::Fixed, 32 in abbrev to encode hash.
Sep 6 2019
Remove pasto from one of the testcases
Update testcase to use a more portable version of touch
Nice! Are you planning to address the FIXME's in a later update of this patch?
Sep 5 2019
Sep 3 2019
Aug 30 2019
Aug 29 2019
Aug 28 2019
Nice! Is this something that can be tested for in unittests/Basic/FileManagerTest.cpp?
Thanks for fixing this, LGTM!
Aug 16 2019
I'm curious to know if you measured the impact on the PCM size after this change (example: PCMs from building macOS public SDK)? For instance, PPD_SKIPPED_RANGES currently explodes for some specific inputs, just wonder what's the story here.
LGTM with one minor change.
Aug 9 2019
Aug 7 2019
Internal compiler error: LFS error for "/Users/jfb/s/llvmm/debug/tools/clang/test/Index/Output/pch-from-libclang.c.tmp.mcp/14EC4PG1UTVLY/modules.idx"failed to create unique file /Users/jfb/s/llvmm/debug/tools/clang/test/Index/Output/pch-from-libclang.c.tmp.mcp/14EC4PG1UTVLY/modules.idx.lock-0ae18733: No such file or directory
Aug 5 2019
Thanks for working on this JF!
It seems conceptually a little strange to have the working directory be part of a serialized "FS", as it's fundamentally a property of a process and only transiently a property of the VFS.
Jul 2 2019
Thanks for working on this. Can you add unit tests for those?
Jul 1 2019
I am currently working on the next part of clang interface stubs that will take the interface stubs per compilation unit and merge them into one text stub (which will be used by something like llvm-elfabi to generate a stubbed out ELF .so file). I was using llvm-nm, but there are cases where the symbol is present in the .o file but it is marked as HIDDEN and llvm-readelf was what I was using to determine if the symbol was in fact marked as hidden. In these cases, the linker will not emit the symbol in the final .so file but it still needs the symbol as part of linking.
Jun 25 2019
Jun 19 2019
Hi JF. Thanks for working on this, nice improvement to error handling!
Mar 6 2019
ninja check-clang passes... is there anything else I should be testing?
Mar 4 2019
Thanks for working on this, the approach & patch LGTM.
InMemoryModuleCache seems like a way more appropriate name here. Also thanks for improving some of the comments.
Nice, note that a subset of this information can be achieved with -Wauto-import, but this is way more general and solid, since it will handles @imports and pragma imports too. LGTM with a minor nitpick, see comments.
Feb 12 2019
I missed that the DependencyCollector already marks them virtual, you are just making it obvious here. I think you can omit the ones that are already virtual and only add to the ones that are on the intend of this patch.
Feb 11 2019
Not really. Would making only the attachTo* methods virtual enough though?
How much of the ModuleDependencyCollector will be reused as is by LLDB? I wonder about the tradeoff versus inheriting from DependencyCollector directly.
Jan 29 2019
Thanks for working on this! LGTM