-
Notifications
You must be signed in to change notification settings - Fork 10.6k
Dependency Scanning Library #34786
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
Dependency Scanning Library #34786
Conversation
f1dd0aa to
9f5fab0
Compare
|
@swift-ci please smoke test |
|
@nkcsgexi, curious to hear your thoughts on the refactor in |
|
They look good to me for now. Can we first define the C header defining those APIs libSwiftDriver need for scanning and refactor the C++ implementation accordingly? |
I like this idea, yeah, I'll do that. |
6294902 to
fb9ba46
Compare
|
@akyrtzi @benlangmuir, |
|
Likewise, @nkcsgexi. |
|
Some additional things for your consideration:
|
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.
@akyrtzi do you know why CXString has this representation? I was surprised it's not just a pointer.
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.
The only use of the flags seems to be to distinguishing who manages this pointer, whether it was malloc'd locally or points to unmanaged memory.
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 personally dislike CXString, I'd suggest to either use something like indexstore_string_ref_t and be clear what is the lifetime of the returned string (e.g. "same lifetime as the object the string came from") or malloc and return a char * and require the caller to free() it.
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.
be clear what is the lifetime of the returned string (e.g. "same lifetime as the object the string came from")
Note that on the Swift code you are mainly just going to copy it into a Swift string as soon as you call it, so the lifetime aspect it won't make things complicated (it will even simplify things since you won't have to call dispose on it).
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 changed the string implementation to one that resembles index store_string_ref_t and its lifetime is now tied to the object the string comes from. Clients need not worry about freeing string memory, it will be freed automatically when the owning object is disposed of.
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 accessors that return swiftscan_string_t or swiftscan_string_set_t * are not clear about ownership. I see you have swiftscan_string_dispose and swiftscan_string_set_dispose methods, but the implementation looks like they are returned unowned. If not every API is consistent about whether the caller needs to dispose of the result, I recommend putting it in the doc comment for the accessors.
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.
Resolved by tying the lifetime of the string to the object it is associated with. swiftscan_string_dispose and swiftscan_string_set_dispose are no longer part of the public API.
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.
In general, I propose we adopt Foundation-style ownership signals here
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.
In general, I propose we adopt Foundation-style ownership signals here
@CodaFi, thank you taking a look at this PR and proposing this convention.
The API now consistently follows this naming scheme, providing a create and dispose functions for all objects that the library's clients may take ownership of.
Already caught an error by doing this, thank you @akyrtzi! |
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.
You may have some entertaining conflicts with this.
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.
"llvm/Support/CBindingWrapping.h" provides some utilities that might help things here.
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.
Thanks!
… if it is `empty`
…ay struct type fields to be consistent.
…used for batched versioned-PCM scans.
…side string construction (Using string length provided by the type)
…ll of our build compilers.
…hen collecting cross import overlays
…h up-to-date search paths on successive scanner invocations To ensure they do not get stuck with stale search paths when scanning successive targets.
…creation to populate LLVM's target data store.
189da80 to
cc400bf
Compare
|
@swift-ci please test |
|
Build failed |
|
@swift-ci please test Linux platform |
|
@swift-ci please test |
f542987 to
e991ce2
Compare
|
@swift-ci please test Windows platform |
e991ce2 to
4f8c0e4
Compare
|
@swift-ci please test Windows platform |
…opefully work better on windows.
4f8c0e4 to
4eae21c
Compare
|
@swift-ci please test Windows platform |
|
Build failed |
|
@swift-ci please test Linux platform |
|
@swift-ci please test macOS platform |
|
Build failed |
|
@swift-ci please test macOS platform |
|
Build failed |
|
@swift-ci please test macOS platform |
|
🎉 |
This PR introduces a dependency scanning tool/library that is meant to be used by
libSwiftDriver, replacing its current calls toswift-frontend -scan-dependencies.This library is designed to be used for dependency scanning across multiple, different modules, with a common
ModuleDependencyCache, in order to re-use computed information about already-scanned modules.This PR:
DependencyScanningTool).DependencyScanningToollibrary.CompilerInstanceinto callers ofscanDependencies. It is now the responsibility of thescanDependenciescode to instantiate (and share) the cache. e.g.FrontendToolinstantiates a new cache per-scan-dependenciesinvocation, and theDependencyScanningToolkeeps one shared cache across its lifetime. (Effectively un-doing [Dependency Scanner] ShareModuleDependenciesCacheas a part of the CompilerInstance #34646)-scan-clang-dependencies. Since it was introduced, its use-case has been entirely subsumed by batch scanning.include/swift-c/DependencyScan)ScanDependencies.cppis split into two functional groups:swift-frontendexecution modeDependencyScan.h, modelled after theInterModuleDependencyGraphrepresentation in swift-driverResolves rdar://71209248
Resolves rdar://71209311