Having package-name flag in non-package interfaces causes them to be built as if
belonging to a package, which causes an issue for a loading client outside of the
package as follows.
For example, when building X that depends on A with the following dependency chain:
X --> A --> B --(package-only)--> C
1. X itself is not in the same package as A, B, and C.
2. When dependency scanning X, and opening up B, because the scan target is in a
different package domain, the scanner decides that B's package-only dependency
on C is to be ignored.
3. When then finally building A itself, it will load its dependencies, but because
the .private.swiftinterface of A still specifies -package-name, when it loads
B, it will then examine its dependencies and deem that this package-only dependency
on C is required.
Because (2) and (3) disagree, we get an error now when building the private A textual interface.
rdar://130701866
Fix the problem that when the only module can be found is an
invalid/out-of-date swift binary module, canImport and import statement
can have different view for if the module can be imported or not.
Now canImport will evaluate to false if the only module can be found for
name is an invalid swiftmodule, with a warning with the path to the
module so users will not be surprised by such behavior.
rdar://128876895
Add support for serialized diagnostics, parseable output, and other
kinds of output from diagnostics engine to the libSwiftScan
replayCompilation API.
rdar://129015959
Separate swift-syntax libs for the compiler and for the library plugins.
Compiler communicates with library plugins using serialized messages
just like executable plugins.
* `lib/swift/host/compiler/lib_Compiler*.dylib`(`lib/CompilerSwiftSyntax`):
swift-syntax libraries for compiler. Library evolution is disabled.
* Compiler (`ASTGen` and `swiftIDEUtilsBridging`) only depends on
`lib/swift/host/compiler` libraries.
* `SwiftInProcPluginServer`: In-process plugin server shared library.
This has one `swift_inproc_plugins_handle_message` entry point that
receives a message and return the response.
* In the compiler
* Add `-in-process-plugin-server-path` front-end option, which specifies
the `SwiftInProcPluginServer` shared library path.
* Remove `LoadedLibraryPlugin`, because all library plugins are managed
by `SwiftInProcPluginServer`
* Introduce abstract `CompilerPlugin` class that has 2 subclasses:
* `LoadedExecutablePlugin` existing class that represents an
executable plugin
* `InProcessPlugins` wraps `dlopen`ed `SwiftInProcPluginServer`
* Unified the code path in `TypeCheckMacros.cpp` and `ASTGen`, the
difference between executable plugins and library plugins are now
abstracted by `CompilerPlugin`
Previously we would call `getMembers`, which could
kick delayed member parsing. Instead, propagate a
`parseIfNeeded` flag through the ASTDumper logic,
and use it to determine whether to parse a
SourceFile, type/extension body, or function body.
This is needed for things like `-dump-parse` which
expects to dump the entire AST tree.
In some cases this import may be superfluous as it's also
`@_exported` imported by the overlay. However, when the overlay
is hidden and the import not printed, the import can go entierly
missing.
Rather than trying to re-compute the cache path manually for the
default, use the clang provided interface to home the module cache. This
ensures that we do not write the files into a top-level directory on
Windows.
Serialize the `-public-autolink-library <name>` option to the
moduleinterface file because it can affect the LINK_LIBRARY entries in a
swiftmodule file. Without saving the option, the library won't be linked
when a module compiled from the moduleinterface is used.
This change marks the `-public-autolink-library` option as a module
interface option and reads it when building a swiftmodule by module
loader.
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)
Make sure the `-Xcc` options to the scanner are correctly considered
when creating ClangImporterCC1 arguments for constructed swift interface
compilation job. Under directcc1 mode, `-Xcc` options should be used to
constructed sub-invocation but should not be added to GenericArgs for
constructing interface compilation jobs.
rdar://128873665
TLDR: This makes it so that we always can parse sending/transferring but changes
the semantic language effects to be keyed on RegionBasedIsolation instead.
----
The key thing that makes this all work is that I changed all of the "special"
semantic changes originally triggered on *ArgsAndResults to now be triggered
based on RegionBasedIsolation being enabled. This makes a lot of sense since we
want these semantic changes specifically to be combined with the checkers that
RegionBasedIsolation turns on. As a result, even though this causes these two
features to always be enabled, we just parse it but we do not use it for
anything semantically.
rdar://128961672
Teach dependency scanner to report all the module canImport check result
to swift-frontend, so swift-frontend doesn't need to parse swiftmodule
or parse TBD file to determine the versions. This ensures dependency
scanner and swift-frontend will have the same resolution for all
canImport checks.
This also fixes two related issues:
* Previously, in order to get consistant results between scanner and
frontend, scanner will request building the module in canImport check
even it is not imported later. This slightly alters the definition of
the canImport to only succeed when the module can be found AND be
built. This also can affect the auto-link in such cases.
* For caching build, the location of the clang module is abstracted away
so swift-frontend cannot locate the TBD file to resolve
underlyingVersion.
rdar://128067152
Stop relying on file system to provide source buffer for diagnostics
when replying. This avoids initializing CASFS which is quite expensive.
Now cached diagnostics contains CASID for the file buffer so it can
initialize its own source manager without relying on the underlying file
system.
rdar://128423393
Enables `-checked-async-objc-bridging` flag by default starting
from swift 6 language mode to provide enhanced debugging and
runtime checking for the correct usage of continuations passed
in a call to ObjC from Swift.
