When you prefix the request JSON with 'time', it will display the time
taken for the request. e.g.
(SourceKit) time { key.request: source.request.compiler_version }
request time: 0.177 ms
{
key.version_major: 5,
key.version_minor: 6,
key.version_patch: 0
}
(SourceKit)
These modules are part of the experimental declarative string processing feature. If accepted to the Standard Library, _StringProcessing will be available via implicit import just like _Concurrency, though _MatchingEngine will still be hidden as an implementation detail.
`_MatchingEngine` will contain the general-purpose pattern matching engine ISA, bytecode, and executor. `_StringProcessing` will contain regular expression and pattern matching APIs whose implementation depends on the matching engine..
Also consolidates frontend flag `-enable-experimental-regex` as `-enable-experimental-string-processing`.
Resolves rdar://85478647.
This setting is set early in SourceKit's CMake logic to match Swift's CMake settings.
However, it was then reset back to the empty string. The CMake logic would then see that it was unset and use the host OS as the deployment target.
Thankfully, the compiled binaries have been correct without this change, but sourcekitd.framework's Info.plist when building for iOS was incorrect.
By removing the reset, the correct value propagates to the right places.
This is for <rdar://problem/85511244> and addresses <rdar://problem/68656762>.
The shared arguments should come first, followed by the headers.
Otherwise, things don't work correctly, and CMake thinks there are no sources in sourcekitdInProc_Static.
This is for <rdar://problem/85511244>.
The reason why I am doing this is that we are going to be enabling lexical
lifetimes early in the pipeline so that I can use it for the move operator's
diagnostics.
To make it easy for passes to know whether or not they should support lexical
lifetimes, I included a query on SILOptions called
supportsLexicalLifetimes. This will return true if the pass (given the passed in
option) should insert the lexical lifetime flag. This ensures that passes that
run in both pipelines (e.x.: AllocBoxToStack) know whether or not to set the
lexical lifetime flag without having to locally reason about it.
This is just chopping off layers of a larger patch I am upstreaming.
NOTE: This is technically NFC since it leaves the default alone of not inserting
lexical lifetimes at all.
llvm-project `ErrorHandling.h` was updated to remove std::string. This
added a new `report_fatal_error` overload taking a `const Twine &`,
removed the overload that took `const std::string &`, and updated
`fatal_error_handler_t` to use `const char *` rather than `const
std::string &`.
Fix uses of these functions to take into account these updates. Note
that without the `const std::string &` overload, passing a `std::string`
into `report_fatal_error` now results in an ambiguous match between the
`StringRef` and `Twine` overloads so we need to be explicit about one or
the other.
This allows the client to dispose of a request handle manually, cleaning up memory leaks that could previoulsy resulted from cancelling a request that has finished. It also gives us more flexibility to change to a different representation of request handles that require manual disposal in the future.
Previously, `SwiftASTManager` and `SlowRequestSimulator` maintained their own list of in-progress cancellation tokens. With code completion cancellation coming up, there would need to be yet another place to track in-progress requests, so let’s centralize it.
While at it, also support cancelling requests before they are scheduled, eliminating the need for a `sleep` in a test case.
The current implementaiton leaks tiny amounts of memory if a request is cancelled after if finishes. I think this is fine because it is a pretty nieche case and the leaked memory is pretty small (a `std::map` entry pointing to a `std::function` + `bool`). Alternatively, we could require the client to always dispose of the cancellation token manually.
A keypath using dynamic member lookup results in various `KeyPathExpr`
that have components with no location. Ignore these and any other
references that have a missing location.
Resolves rdar://85237365
All of these are tools that are only meant to be used when testing swift. Thus
it doesn't make sense to include them in the catch all 'tools' install component
that distributions use to build all the tools.
I verified that all of the mac/linux presets in tree that have tools also has
testsuite-tools so this should be NFC. On Windows, I needed to add
testsuite-tools to build-windows.bat so should be NFC there as well.
Othwerise we were performing the syntactic parsing on a background queue that had a reduced stack size which could result in stack overflows.
rdar://84474387
Fixes a linux build error.
It doesn’t make sense to let add HAS_LIBSWIFT to add_swift_host_library(). This was added to work around a linker bug (d22b348adb). Instead do the workaround in libSwiftScan/CMakeLists.txt.
Don't build the swiftCore module files in the bootstrapping phases. Instead use the module files in the SDK.
This reduces the build time overhead from 3min -> 30seconds.
Mark implicit declarations with a `synthesized` field, since while we
still want them to have a cursor info result (eg. for their USR to find
possible overrides), it's likely that clients will want to treat them
differently to results that have a real location in source.
An alternative could be to remove the location entirely, but:
- the module name would also have to be removed to prevent wasted
lookups in the generated interface
- having the location could still be useful as the location that
caused the synthesized declaration (though at the moment only
synthesized initializers have a location)
Resolves rdar://84990655
Leaks checking is not thread safe and e.g. lldb creates multiple SILModules in multiple threads, which would result in false alarms.
Ideally we would make it thread safe, e.g. by putting the instruction counters in the SILModule, but this would be a big effort and it's not worth doing it. Leaks checking in the frontend's and SILOpt's SILModule (not including SILModules created for module interface building) is a good enough test.
rdar://84688015
This tool was mostly already compatible with copying
`libswift_Concurrency.dylib` based on whether or not the executables it
was scanning linked it. The only thing missing was that it can now end
up copying from different source directories, the older `swift-5.0`
directory, and the new `swift-5.5` directory.
This change allows users to pass `--source-libraries` multiple times
(or picks a default with both) in order to have it scan both directories
for any libraries the app links. The biggest part of this change is
instead of storing just the library name throughout this logic we now
store the actual discovered path, so that we don't have to loop through
all potential source directories each time we need to find the library,
only the first time.
