Partially revert https://github.com/swiftlang/swift/pull/86309. Keep the
SDKInfo parsing in the ASTContext separately from the search path
configuration. This allows the availablity checking to load SDKSettings
from the correct VFS.
rdar://169886913
Calling `setCurrentWorkingDirectory` on `getRealFileSystem` sets the
working directory for the process itself. This is unsafe for clients
such as SourceKit which can process multiple concurrent requests,
and may be used as an in-process library in e.g sourcekit-lsp. Switch
to `createPhysicalFileSystem` instead, where setting the working
directory is done locally on the FileSystem itself.
Some Darwin platforms like DriverKit use a system prefix on all of their search paths. Even though DriverKit isn't supported, add support to get the system prefix from SDKSettings when constructing the default search paths.
This requires the DarwinSDKInfo to be gotten earlier in CompilerInvocation, pass that down to ASTContext through CompilerInstance.
-platform-availability-inheritance-map-path is no longer needed to support visionOS in tests, remove that and its supporting code that gets an alternative DarwinSDKInfo.
rdar://166277280
This commit adds -sil-output-path and -ir-output-path frontend options that
allow generating SIL and LLVM IR files as supplementary outputs during normal
compilation.
These options can be useful for debugging and analysis tools
workflows that need access to intermediate compilation artifacts
without requiring separate compiler invocations.
Expected behaviour:
Primary File mode:
- SIL: Generates one .sil file per source file
- IR: Generates one .ll file per source file
Single-threaded WMO mode:
- SIL: Generates one .sil file for the entire module
- IR: Generates one .ll file for the entire module
Multi-threaded WMO mode:
- SIL: Generates one .sil file for the entire module
- IR: Generates separate .ll files per source file
File Maps with WMO:
- Both SIL and IR outputs using first entry's naming, which is
consistent with the behaviour of other supplementary outputs.
rdar://160297898
`performNewOperation` may not set a new compiler instance if e.g it
ends up being cancelled, so we need to make sure we reset the cached
compiler instance to ensure future requests don't attempt to re-use
it. Noticed by inspection.
Unfortunately haven't been able to come up with a test case for this,
but there seem to be cases where we're incorrectly picking up
a macro-expanded accessor from the cached AST when searching for the
original decl. Make sure we only consider decls that have been
written by the user.
rdar://151926231
The diagnostic group documentation now point to the swift.org URL rather
than the toolchain path, so it no longer needs to be passed all the way
through sourcekitd.
Resolves rdar://151500502.
Rather than exposing an `addFile` member on
ModuleDecl, have the `create` members take a
lambda that populates the files for the module.
Once module construction has finished, the files
are immutable.
We shouldn't be attempting to append SourceFiles
to the module after-the-fact for syntactic macro
expansion, refactor things such that the SourceFile
is created alongside the ModuleDecl.
This prevents a nullptr dereference in `ASTScope::unqualifiedLookup()` after
querying for the `SourceFile` containing a give source location.
Fixes rdar://137652856 and https://github.com/swiftlang/swift/issues/76944.
ModuleDecl kept track of all of the source files in the module so that it
could find the source file containing a given location, which relied on
a sorted array all of these source files. SourceManager has its own
similar data structure for a similar query mapping the locations to
buffer IDs.
Replace ModuleDecl's dats structure with a use of the SourceManager's version
with the mapping from buffer IDs to source files.
The "buffer ID" in a SourceFile, which is used to find the source file's
contents in the SourceManager, has always been optional. However, the
effectively every SourceFile actually does have a buffer ID, and the
vast majority of accesses to this information dereference the optional
without checking.
Update the handful of call sites that provided `nullopt` as the buffer
ID to provide a proper buffer instead. These were mostly unit tests
and testing programs, with a few places that passed a never-empty
optional through to the SourceFile constructor.
Then, remove optionality from the representation and accessors. It is
now the case that every SourceFile has a buffer ID, simplying a bunch
of code.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
It appears that https://github.com/apple/llvm-project/commit/a6ebd3083dbf8aadae58f6f2a2f1071976649d56 changed the behavior of `-fno-modules-validate-system-headers` (aka. `DisableModulesValidateSystemDependencies`) in conjunction with `-fmodules-validate-once-per-build-session`: Before that change, `-fno-modules-validate-system-headers` needed to be passed for `-fmodules-validate-once-per-build-session` to have any effect (we were always validating system dependencies if `-fno-modules-validate-once-per-build-session` was not set). After the change, `-fno-modules-validate-once-per-build-session` causes system dependencies to never be validated, independent of the build session timestamp.
This change should have no effect on Xcode because it adds `-fmodules-validate-system-headers` to the compiler arguments for Swift files, which overrides `SearchPathOpts.DisableModulesValidateSystemDependencies = true;`
Function body macros allow one to introduce a function body for a
particular function, either providing a body for a function that
doesn't have one, or wholesale replacing the body of a function that
was written with a new one.
This will allow us to run two different completion kinds and deliver results from both of them.
Also: Compute a unified type context for global lookup. Previously, we always used the expected type context of the last lookup. But really, we should be considering all possible types from all constraint system solutions when computing code completion results from the cache.
Steven Wu
Hamish Knight
Ian Anderson
Ryan Mansfield
swift-ci
Anthony Latsis
Ahmed Elrefaey
Ben Barham
Ben Langmuir
Hamish Knight
Jan Svoboda
Meghana Gupta
Allan Shortlidge
Doug Gregor
Alex Hoppen
Jeremy Day
Tim Kientzle
Harlan Haskins
Victor Toni
Rintaro Ishizaki
Holly Borla