-
Notifications
You must be signed in to change notification settings - Fork 34
Improve the test coverage of the C API #447
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clang-tidy made some suggestions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clang-tidy made some suggestions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clang-tidy made some suggestions
6f81874
to
11fea7d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clang-tidy made some suggestions
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #447 +/- ##
==========================================
+ Coverage 72.71% 75.31% +2.59%
==========================================
Files 9 9
Lines 3618 3617 -1
==========================================
+ Hits 2631 2724 +93
+ Misses 987 893 -94
... and 1 file with indirect coverage changes
🚀 New features to boost your workflow:
|
|
||
// C API | ||
auto* I = clang_createInterpreterFromRawPtr(Cpp::GetInterpreter()); | ||
EXPECT_TRUE(clang_hasDefaultConstructor(make_scope(Decls[0], I))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think we should put the tests for the c layer in a separate file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that's practical at the moment because of the low API coverage. We need to use a lot C++ API to set up the environment and do the test.
2a1eca2
to
0420a80
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clang-tidy made some suggestions
This only improved the coverage from 70% to 74% because as I said before nearly half of the code are from libclang. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clang-tidy made some suggestions
I think this is ready to merge. |
Seems so. Please address the clang-tidy suggestions and we should be good to go. |
done! |
@Gnimuc can you rebase? Now that we have automated wasm tests we need to just double check that the new tests pass for an Emscripten build. Once the ci passes after rebase I will approve and merge. |
@mcbarton any hints on how to investigate those Emscripten build errors? |
@anutosh491 I had a quick go at trying to fix the errors without success. Do you have any suggestions about what @Gnimuc can try to debug/fix the failing/crashing tests? |
Hmmm, can look into it in a while |
@anutosh491 does Emscripten build need any special setup when creating the interpreter instance? The current interpreter C API is not equivalent to the C++ one(it's just a thin wrapper over clang::Interpreter with no additional setups), so probably we should just skip those C API tests on Emscripten? |
Yeah absolutely we can do that for now. Its not suprising atleast to me to see things work natively and not with emscripten right now. I would not stress on getting it to pass through this PR itself. Let's skip it for now. @mcbarton as you've been monitoring the emscripten tests my suggestion here is to let this one go and we create a todo-list through an issue to keep track and keep addressing one skipped test at a time. I see only two reasons for tests to fail right now i) some tests are not catered for the emscripten build (for eg the functions for detecting resource dir use system calls that won't (shouldn't) work with emscripten ... so we just update it to returning an empty string cause that's expected) We have all tools to address |
Hey @Gnimuc I see two errors here. I would only expect the 1st one be addressed cause that's doable.
What this basically means is its trying to call an undefined symbol at runtime. Doing some more debugging shows me this is the exact symbol, I had added some PRs back (reasoning on why it is missing should be mentioned there) So if you export this like I did, the first one would be resolved (and possibly we can close my PR then)
Search paths for native cases vs for emscripten cases where a virtual file system is being put to use should work differently. So I would not stress on getting this to pass just yet. Could you please skip this ? I think this should be ready then. P:S Not sure how important those 2 lines are. Probably just commenting them out or removing should be enough too ? |
@anutosh491 Thanks for looking into this. I cherry-picked your commit and did a rebase. 🤞🏻
That's my ugly trick for improving the coverage.😅 Let’s remove them until we figure out a way to do a proper test. |
Oops! Should not just cherry-pick that commit. I manually applied the changes. |
Perfect. Nothing wrong with that I think |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the emscripten tests pass now.
If these are all the tests that were meant to be addressed through this PR (someone can let me know if this is all) then this should be ready I think !
PRIVATE "SHELL: -s WASM_BIGINT" | ||
PRIVATE "SHELL: -s SIDE_MODULE=1" | ||
PRIVATE "SHELL: ${SYMBOLS_LIST}" | ||
PUBLIC "SHELL: -Wl,--export=__clang_Interpreter_SetValueNoAlloc" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These should be added to the exports.ld file we already have. e.g. here https://github.com/Gnimuc/CppInterOp/blob/c-api-test/lib/Interpreter/exports.ld
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be done too through a subsequent PR.
Thanks! |
Description
as per #440 (comment)
Fixes # (issue)
Type of change
Please tick all options which are relevant.
Testing
Please describe the test(s) that you added and ran to verify your changes.
Checklist