To use _RegexParser from SwiftSyntax.
* Create 'libswiftCompilerModules_SwiftSyntax.a' which is a subset of
'libswiftCompilerModules.a'
* Link 'lib_InternalSwiftSyntaxParser' to
'libswiftCompilerModules_SwiftSyntax.a'
* Factor out swift runtime linking logic in CMake so that dynamic
libraries can link to Swift runtime, in addition to executables
* Link 'lib_InternalSwiftSyntaxParser' to swift runtime
A couple of things that swift-reflection-fuzzer uses have been updated
without updating swift-reflection-fuzzer, the upshot being that it now
won't build (which also blocks use of swift-demangle-fuzzer).
rdar://94143566
This adds C functions that can be called from SwiftSyntax to enable or disable bare slash regex parsing.
It also adds a function to set the Swift language version - while this is not of top priority at the moment it will become important once we introduce a new language mode again.
rdar://93750821
`libInternalSwiftSyntaxParser.dylib` currently doesn’t link against `SwiftExperimentalStringProcessing`, so it can’t use the regex lexing functions defined within. This caused SwiftSyntax to fail if the source code contained regex literals.
Implement a fallback regex lexing function in C++ and use it for SwiftSyntax parsing.
rdar://93580240
Co-authored-by: Rintaro Ishizaki <rishizaki@apple.com>
PR #41550 changed from using `SmallVector::set_size` to `resize_for_overwrite` and `truncate`, but in `sourcekitd-repl` changing from `reserve` changed the size just prior to getting the `end()` of the output array, leading to retrieving the end of the resized array, rather than the array prior to resizing.
The conversion needs to begin at the original output's end, rather than the resized-to-reserve output size, otherwise the conversion triggers the asserts at lines 101 and 116 (with `res == targetExhausted`).
Change the way swiftmodules built against a different SDK than their
clients are rejected. This makes them silently ignored when the module
can be rebuilt from their swiftinterface, instead of reporting a hard
error.
rdar://93257769
#58786 (rdar://93030932) was failing because the `swift-frontend` invocations passed a `swiftExecutablePath` to `Invocation.parseArgs`. This caused the `ClangImporter` instance to point to a `clang` binary next to the `swift-frontend` executable while SourceKit used PATH to find `clang`. The clang executable next to `swift-frontend` doesn’t actually exist because `clang` lives in `llvm-linux-aarch64/bin` and `swift-frontend` lives in `swift-linux-aarch64/bin`.
So some checks for a minimum clang verison failed for the normal build (because the executable doesn’t actually exists) while they pass during the SourceKit build (which used `clang` from `PATH`). This in turn caused the `outline-atomics` to be enabled to the SourceKit clang compiler arguments but not the clang compiler arguments for a normal build and thus resulted in two separate module cache directories (which includes the enabled features in the module directory hash).
To fix this issue, also set the swift executable path for compiler invocations created from SourceKit.
Fixes#58786 (rdar://93030932)
llvm/llvm-project d0262c2394f46bb7da2a75529413d625c70908e5 added a new
default bool param to the two constructors in `SmallVectorMemoryBuffer`.
Since `options.OutputPath` is a `const char *` and that can be promoted
to a `bool`, the constructor being called was changed to the first
constructor (with a default buffer name) - promotion is preferred over
conversion.
Convert the various output paths to a `StringRef` - all their uses
converted to `StringRef` anyway. Also specify the default parameter in
order to maintain the old behaviour, which didn't require a null
terminator.
A `llvm::raw_string_ostream` is unbuffered, but calling `SetBufferSize`
adds a buffer. Since its destructor doesn't flush (as it assumes it is
unbuffered), this then asserts in the `llvm::raw_ostream` destructor.
Remove the `SetBufferSize` call (the string is the underlying buffer)
and also switch to using `llvm::SmallString` instead.
This fixes a crash in `SourceKit/SyntaxTree/basic.swift` and
`SourceKit/SyntaxTree/pound_if.swift`, which are presumably the only two
tests that actually use this.
When a variable is re-declared using shorthand syntax (`[foo]` closure capture or `if let foo {`), the user doesn’t perceive this as a new variable declaration. Thus, we should return the original declaration as a secondary result.
rdar://91311033
rdar://75455650
Previously, the related idents request wouldn’t look through caputred variables like `[foo]`. Change the logic to consider the captured variable as well as the variable that’s implicitly declared for use inside the closure.
rdar://81628899
We might run into situations where `matchesSourceState` reads `DependencyStamps` while they are being written in `buildASTUnit`, causing a crash.
Guard `DependencyStamps` by a mutex to avoid this problem. We don’t need to provide any ordering guarantees about whether `DependencyStamps` have been computed in are accessed because we already assume that the dependencies shouldn't change (much) in the time between an `ASTBuildOperation` is created and until it produced an AST.
rdar://92748564
