XCTestDynamicOverlay: prefer delay loading XCTFail
#73
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@compnerd Thanks for looking into this and for the PR! It does look like Ubuntu and Wasm aren't happy with the changes, though, at the moment. We have a |
|
Let me see if I can figure out what is going on. |
Similar to the ObjC XCTest, prefer to delay load the XCTest runtime. This is likely to fail on release distributions as XCTest is a developer component. However, if it is available in the library search path on (non-Darwin) Unix or in `Path` on Windows, it will be used. Windows does not (yet) ship a static XCTest library. On Linux, it is unclear whether the linkage is dynamic or static, so we perform a little trick. We pass `RTLD_NOLOAD` to `dlopen` which will get a handle to `libXCTest.so` if it is currently loaded in the address space but not load the library if not already there. In such a case, it will return `NULL`. In such a case, we resort to looking within the main binary (assuming that XCTest may have been statically linked). For both platforms, if we do not find the symbol from XCTest, we will proceed to simply use the fallback path. Note that both `GetProcAddress` and `dlsym` do not know how to cast the resulting pointer to indicate the calling convention. As a result, we rely on the use of `unsafeBitCast` to restore the calling convention to `swiftcall`. To completely avoid the undefined behaviour here, we would need to resort to C to perform the cast as these methods return type erased pointers (i.e. `void *`).
|
@compnerd Looks like just one small compiler error in the Windows debug branch. I pushed an update to Wasm's CI to get it building in case you force push again be sure not to lose it 😄 |
Add a cast for Windows after the last round of tweaks for Linux. Additionally, use `LoadLibraryA` instead of `LoadLibraryW` as we know that the library name is ASCII compliant and the array buffer does not work with `LoadLibraryW` and would require pulling in Foundation.
|
@stephencelis - should be good to go now. |
stephencelis
approved these changes
Jan 17, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Similar to the ObjC XCTest, prefer to delay load the XCTest runtime. This is likely to fail on release distributions as XCTest is a developer component. However, if it is available in the library search path on (non-Darwin) Unix or in
Pathon Windows, it will be used.Windows does not (yet) ship a static XCTest library. On Linux, it is unclear whether the linkage is dynamic or static, so we perform a little trick. We pass
RTLD_NOLOADtodlopenwhich will get a handle tolibXCTest.soif it is currently loaded in the address space but not load the library if not already there. In such a case, it will returnNULL. In such a case, we resort to looking within the main binary (assuming that XCTest may have been statically linked).For both platforms, if we do not find the symbol from XCTest, we will proceed to simply use the fallback path.
Note that both
GetProcAddressanddlsymdo not know how to cast the resulting pointer to indicate the calling convention. As a result, we rely on the use ofunsafeBitCastto restore the calling convention toswiftcall. To completely avoid the undefined behaviour here, we would need to resort to C to perform the cast as these methods return type erased pointers (i.e.void *).