Teach scanner to respect the working directory set in the invocation
through scanner C API.
Also add test infrastructure to testing scanner from C API. Break up
DependencyScan lib into two so the swift-scan-test and remain small
without understanding swift AST.
rdar://127626011
This change modifies the dependency scanner to keep track of source locations of each encountered 'import' statement, in order to be able to emit diagnostics with source locations if an import failed to resolve.
- Keep track of each 'import' statement's source buffer, line number, and column number when adding it. The dependency scanner utilizes separate compilation instances, and therefore separate Source Managers for scanning `import` statements of user sources and textual interfaces of Swift dependencies. Since import resolution may happen in the main scanner compilation instance while the `import` itself was found by an interface-scanning sub-instance, we cannot simply hold on to the import's `SourceLoc`.
- Add libSwiftScan API for diagnostics to carry above source locations to clients.
This was briefly failing to build because of an ambiguous initializer
while making other changes, it's better to be explicit with method names
anyway.
rdar://127548384
Placeholder expansion should be a syntactic operation, but
`SourceEntityWalker` can invoke type checking operations, which causes
unexpected bahaviors including crashes.
rdar://121360941`
Add a new demangler option which excludes a closure's type signature.
This will be used in lldb.
Closures are not subject to overloading, and so the signature will never be used to
disambiguate. A demangled closure is uniquely identifiable by its index(s) and parent.
Where opaque types are involved, the concrete type signature can be quite complex. This
demangling option allows callers to avoid printing the underlying complex nested
concrete types.
Example:
before: `closure #1 (Swift.Int) -> () in closure #1 (Swift.Int) -> () in main`
after: `closure #1 in closure #1 in main`
There were a couple of accesses not guarded by
`CacheMtx`, introduce a couple of methods that
guard them, renaming `getASTProducer` while here.
Also make sure we don't ever insert a producer
after it has been purposefully removed by e.g a
close that removes the cached AST.
We were linking with the newly built `swiftrt.o` when in hosttools mode,
which is wrong because the newly built `swiftrt.o` does not match the
compiler we were using for the `SwiftCompilerSources`.
This manifests as a failure in
`SwiftCompilerSources/Sources/Optimizer/Utilities/Verifier.swift`
because `self is ForwardingInstruction` fails as we can't find the
protocol conformance records.
rdar://123504095
