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
This is needed in specific Apple internal configurations -- as a result
of the limited applicability, this option is not exposed through
`build-script` on purpose.
Addresses rdar://127014753
Add a fast path to create swift CompilerInstance when it is only used to
replay output when there is a cache hit. The normal `setup` function is
very expensive to call, especially in cache mode to setup inputs, and it
needs to be called once per input file from libSwiftScan API due to the
current caching granularity.
The fast path will only construct the part that is needed for output
replay, including the CAS, the output backend and caching diagnostic
processor.
rdar://127062609
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
Relying on the corresponding field in the '-explicit-swift-module-map-file' provided by the driver.
Only bridging headers require a module map because that's what aids header include resolution. With lazy module loading today, '.modulemap' parsing which happens when instantiating Clang is responsible for associating headers with modules. Then upon encountering a header include inside the bridging header the compiler knows which module corresponds to said header and is then able to load explicitly-provided PCM for that module. For all other module dependencies, they are only ever queried by-name from Swift, so '.modulemap' parsing is not necessary.
Generated interfaces for Clang modules used to try printing normal
comments between decls extracted from the header text. That was because
doc-comment was not common in C/ObjC headers. But mainly because of
"import as member feature" Clang decls aren't printed in the order as
they appear in the header file, the logic determinig which comment
belongs to which decl was not working property. We've decided to remove
that feature and only print the proper doc-comments as it has been
getting common.
rdar://93731287
This has two benefits:
1. We can now report ambiguous variable types
2. We are more robust in the generation of results for declarations inside closures. If the closure has an error, we won’t apply the solution to the AST and thus any cursor info that tried to get types out of the AST would fail.
rdar://123845208
LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
* Record each IfConfig clause location info in SourceFile
* Update SILProfiler to handle them
* Update SwiftLangSupport::findActiveRegionsInFile() to use the recorded
regions instead of walking into AST to find #if regions
rdar://118082146
We were only setting `RequestBarriersEnabled` after dispatching the request to `requestQueue`. This left a brief gap where new requests could come in that wouldn’t see `RequestBarriersEnabled = true`.
Otherwise they may have module dependencies of their own which will not be detected by the scanner and included in the list of explicit inputs for compilation.
SourceKit-LSP currently parses the XML comment to generate Markdown again but round-tripping a (probably markdown) doc comment to XML to Markdown is lossy in many cases and unnecessary work. Include the comment as it is spelled in source in the cursor info response so that sourcekit-lsp can display it.
Part of rdar://120685874
Sending a `SIGTERM` to sourcekitd XPC service lead to very surprising results: XPC thought that the process was about to die and sends a Connection Interrupted notification to the client. But other than that, we didn’t actually handle the signal and the service stayed alive. This caused us to send a `sema_disabled` notification to the client but since the service never got relaunched, we never sent the corresponding `sema_enabled` notification.
To fix this, just properly die on `SIGTERM` by calling `abort`.
