User Details
- User Since
- Oct 7 2020, 6:11 PM (154 w, 4 d)
Aug 22 2023
Aug 17 2023
Aug 4 2023
Aug 3 2023
Are there other users of incremental processing mode, other than the REPL / IncrementalParser?
Jun 30 2023
Jun 29 2023
May 30 2023
May 16 2023
Mar 24 2023
I have decided against doing that, because we can't specify @LINE in the c-index-test command line.
Mar 22 2023
Mar 21 2023
Mar 13 2023
Jan 19 2023
Jan 10 2023
LGTM, thanks Alex!
Dec 21 2022
Dec 19 2022
Dec 13 2022
LGTM. If you could put up a PR after to fix the use of sys::fs::make_absolute that would be appreciated 🙇.
Nov 28 2022
Nov 18 2022
Add missing --target
Nov 15 2022
Nov 8 2022
This seems reasonable to me in general. @dexonsmith in case you have any thoughts.
Nov 3 2022
Oct 31 2022
Thanks Egor!
Oct 24 2022
You're correct that this overhead has been measured on implicit module builds. As I mentioned in the commit message this saves over 20% of the overall built time in some cases. This time is split between module validation (which could be skipped) and HeaderSearch (which cannot be skipped).
Mostly just skimmed so far, will hopefully have some time to look at this more tomorrow. Out of interest, do you have any performance numbers using this change? I assume this mainly impacts implicit modules (since I suspect we'd also be opening the file as well anyway), is that true?
Oct 18 2022
Oct 5 2022
Sep 20 2022
When we try to load such outdated .pcm file, we shouldn't change any already loaded and processed modules.
Aug 5 2022
Aug 3 2022
Aug 2 2022
Thanks 🙇
Aug 1 2022
LGTM, thanks for doing this 🙇
Jun 13 2022
The failure here is likely due to the hack in FileManager::getFileRef:
// FIXME: This hack ensures that `getDir()` will use the path that was // used to lookup this file, even if we found a file by different path // first. This is required in order to find a module's structure when its // headers/module map are mapped in the VFS.
So the directory returned from the FileEntry is the *lookup* directory, but the FileEntryRef will be giving back the directory from the external path (if it has been remapped).
Failing test seems to be because . is turned into the full path at some point. It's possible that this is because getFileRef returns the absolute path (see the massive FIXME there). If that's the case we could fix that by fixing clang-apply-replacements and then change the Status.getName() == Filename to only check whether it's an externally mapped path.
Few small comments, LGTM otherwise.
May 9 2022
May 6 2022
Apr 22 2022
Remove line for <unknown> check
Update title/message
After speaking with Ben, we decided it makes more sense to just remove the reference entirely.
Apr 15 2022
Shadowing of FE almost tripped me up there 😅
Apr 14 2022
Thanks for doing all these Jan!
Apr 12 2022
Thanks Jan :)!
Apr 11 2022
Apr 8 2022
Does clang/test/VFS/external-names-multi-overlay.c need to be formatted or is it fine? It uses split-file so I'd really like to avoid the format here (makes it pretty silly).
Looks like there's more changes required for modulemap-collision.m to actually pass. I'll try figure those out when I have the time.
Apr 5 2022
Added a potential plan to remove the FileManager hacks.
Apr 4 2022
This broke crash reproducers in very specific circumstances, see https://reviews.llvm.org/D123104. I'll re-commit with adding ExposesExternalVFSPath instead of replacing IsVFSMapped.
Mar 30 2022
Mar 29 2022
Keep using the redirection hack for the time being