- User Since
- May 28 2020, 11:15 AM (184 w, 2 d)
Aug 14 2023
Jul 27 2023
Jul 13 2023
Thanks for the patch!
Jul 11 2023
Jul 10 2023
Jul 7 2023
Apr 4 2023
Apr 3 2023
Hi Usman! This is looking very good and complete now! Thanks for taking the time to learn and fix this.
Mar 30 2023
Mar 27 2023
Please update/add test cases.
Mar 24 2023
LGTM for the ExtractAPIVisitor part.
- update test with @LINE
- the libclang side
Mar 23 2023
Thanks for creating the review!
Mar 22 2023
Good to see refactoring to make ExtractAPI easier to extend and use. Thanks Daniel!
Some comments on the ExtractAPIVisitor part. I'll leave the libclang part to the experts.
Mar 6 2023
Mar 3 2023
Mar 2 2023
This fixes the checking logic, and also works around a build failure with clang/unittest/Interpreter/ExceptionTests which enables exceptions. std::optional::value() throws std::bad_optional_access, which won't build if targeting older versions of macOS
Mar 1 2023
Hi! This broke the asan replaceable_new_delete.cpp test on Darwin because it has a run line using -static-libsan. Could you take a look? Probably need to separate that check out and mark as unsupported on Darwin
Dec 15 2022
Dec 14 2022
Dec 12 2022
Dec 8 2022
Dec 6 2022
Oct 25 2022
Oct 24 2022
Is it easy to/worth checking if the target is actually outside of the current module to keep the output smaller and concise?
Oct 5 2022
With the PrintingPolicy fix in https://reviews.llvm.org/D135295 and landed USR fix, the diff within ExtractAPI tests is only the wording with anonymous enums, and we can drop the lit change:
658c658 < "spelling": "(anonymous)" --- > "spelling": "enum (unnamed)" 661c661 < "title": "(anonymous)" --- > "title": "enum (unnamed)" 664c664 < "(anonymous)" --- > "enum (unnamed)" 706c706 < "(anonymous)", --- > "enum (unnamed)", 746c746 < "spelling": "(anonymous)" --- > "spelling": "enum (unnamed)" 749c749 < "title": "(anonymous)" --- > "title": "enum (unnamed)" 752c752 < "(anonymous)" --- > "enum (unnamed)" 794c794 < "(anonymous)", --- > "enum (unnamed)",
I'm pulling this on top of https://reviews.llvm.org/D135295 to try locally now.
Update on top of the existing PrintingPolicy in the ASTContext instead of creating a new default one.
Set PrintingPolicy properly
Setting PrintingPolicy::AnonymousTagLocations to false in https://reviews.llvm.org/D135295
Ah sorry I just finished reading the discussions. IIUC 20c9ac29250493f5e0a3791dc1e5e9114ff0dc6e should have already fixed the USR generation part, and all of the USR updates in the test cases should be gone now?
Aug 2 2022
Aug 1 2022
Jul 26 2022
Awesome! Thanks Daniel!
LGTM. Thanks Daniel!
May 16 2022
May 5 2022
Well, apparently there are still some corner-case bugs in the logic. ExtractAPI and a few other tests failed. Will look into it tomorrow.
May 4 2022
Whitespace change: clang-format removed an empty line
Accidentally added another test case in my local workspace. Removed in 5f841c71fc2cc77c92f526791cd7a938bcac69aa
Update test case to use cc1 instead of driver
May 3 2022
- Capture whether the include is quoted in KnownFiles
- Misc: use getInputBufferName() instead of string literal
May 2 2022
Convert file path to use slashes for headermap reverse lookup
- Delete test known_files_only_hmap
- Handle quoted includes
- Attempt to fix Windows fails by converting backslashes before matching the framework regex
- Update test relative_include
Apr 28 2022
Apr 25 2022
- Rewrite commit message for preparation
- Remove shortening paths based on the current working directory: it does not work with angled includes, and unnecessary for our use
- XFAIL test known_files_only_hmap.c, as it is not a valid setup with a questionable headermap. Need to determine how to fix that test case or just discard it, as the new relative_include.m test also checks that symbols from external files are dropped
- Create FileManager in PrepareToExecuteAction
- Use FileManager to load headermaps and reverse lookup mappings
- Use FileSystem to correctly get working directory and make absolute paths
The problem is that we are trying to shorten the input file paths in PrepareToExecuteAction, where the CompilerInstance is still primal and doesn't even have a FileManager that we could use. That makes it hard (if possible at all) to reverse lookup headermaps and use the spelled names if we failed to find a search path prefix.
The impact is that we won't be able to get an angled include name for cases where an input doesn't reside in any of the normal search paths, but a headermap entry maps some name to that path. Or we might get the wrong include name where there are both headermap entries and search paths that match the input path and the ordering matters.
- Use first match in getRelativeIncludeName
- Try to get Preprocessor and reverse lookup headermaps in getRelativeIncludeName
- Use getRelativeIncludeName to check for known files in LocationFileChecker
- Misc fixes & adjustments
Apr 14 2022
Add test case to demonstrate the framework case.
Apr 12 2022