Introduce a new flag `-export-as` to specify a name used to identify the
target module in swiftinterfaces. This provides an analoguous feature
for Swift module as Clang's `export_as` feature.
In practice it should be used when a lower level module `MyKitCore` is
desired to be shown publicly as a downstream module `MyKit`. This should
be used in conjunction with `@_exported import MyKitCore` from `MyKit`
that allows clients to refer to all services as being part of `MyKit`,
while the new `-export-as MyKit` from `MyKitCore` will ensure that the
clients swiftinterfaces also use the `MyKit` name for all services.
In the current implementation, the export-as name is used in the
module's clients and not in the declarer's swiftinterface (e.g.
`MyKitCore`'s swiftinterface still uses the `MyKitCore` module name).
This way the module swiftinterface can be verified. In the future, we
may want a similar behavior for other modules in between `MyKitCore` and
`MyKit` as verifying a swiftinterface referencing `MyKit` without it
being imported would fail.
rdar://103888618
This lets users of `-explicit-swift-module-map-file` use a single mapping
for all module dependencies, regardless of whether they're Swift or Clang
modules, instead of manually splitting them among this file and command
line flags.
Introduces a concept of a dependency scanning action context hash, which is used to select an instance of a global dependency scanning cache which gets re-used across dependency scanning actions.
When opaque values are enabled, TypeConverter associates to an
address-only type an OpaqueValueTypeLowering. That lowering stores a
single lowered SIL type, and its value category is "object". So long as
the module has not yet been address-lowered, that type has the
appropriate value category. After the module has been address-lowered,
however, that type has the wrong value category: the type is
address-only, and in an address-lowered module, its lowered type's value
category must be "address".
Code that obtains a lowered type expects the value category to reflect
the state of the module. So somewhere, it's necessary to fixup that
single lowered type's value category.
One option would be to update all code that uses lowered types. That
would require many changes across the codebase and all new code that
used lowered types would need to account for this.
Another option would be to update some popular conveniences that call
through to TypeConverter, for example those on SILFunction, and ensure
that all code used those conveniences. Even if this were done
completely, it would be easy enough for new code to be added which
didn't use the conveniences.
A third option would be to update TypeLowering::getLoweredType to take
in the context necessary to determine whether the stored SILType should
be fixed up. That would require each callsite to be changed and
potentially to carry around more context than it already had in order to
be able to pass it along.
A fourth option would be to make TypeConverter aware of the
address-loweredness, and to update its state at the end of
AddressLowering.
Updating TypeConverter's state would entail updating all cached
OpaqueValueTypeLowering instances at the end of the AddressLowering
pass. Additionally, when TypeConverter produces new
OpaqueValueTypeLowerings, they would need to have the "address" value
category from creation.
Of all the options, the last is least invasive and least error-prone, so
it is taken here.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
This change tweaks the 'GlobalModuleDependenciesCache', which persists across scanner invocations with the same 'DependencyScanningTool' to no longer cache discovered Clang modules.
Doing so felt like a premature optimization, and we should instead attempt to share as much state as possible by keeping around the actual Clang scanner's state, which performs its own caching. Caching discovered dependencies both in the Clang scanner instance, and in our own cache is much more error-prone - the Clang scanner has a richer context for what is okay and not okay to cache/re-use.
Instead, we still cache discovered Clang dependencies *within* a given scan, since those are discovered using a common Clang scanner instance and should be safe to keep for the duration of the scan.
This change should make it simpler to pin down the core functionality and correctness of the scanner.
Once we turn our attention to the scanner's performance, we can revisit this strategy and optimize the caching behaviour.
* Lookup for custom derivatives in non-primary source files after typecheck is finished for the primary source.
This registers all custom derivatives before autodiff transformations and makes them available to them.
Fully resolves#55170
Synthesized file units were designed for autodiff to emit synthesized declarations, and also to sidestep the design implications of doing so late in the compiler pipeline.
A call to materialize synthesized file units was added to the GetImplicitSendable request. This introduced a source of iterator invalidation into forEachFileToTypeCheck in whole-module builds. Any call to insert a new file into the module has the potential to cause the underlying SmallVector to reallocate.
This patch provides a narrow workaround that stops using iterators altogether in forEachFileToTypeCheck. However, this bug reveals a severe architectural flaw in the concept of a synthesized file unit. Iterating over the files in a module is an extremely common operation, and there now are myriad ways we could wind up calling a function that mutates the module's list of files in the process. This also means the number and kind of files being visited by compiler analyses is dependent upon whether a request that inserts these files has or has not been called.
This suggests the call to ModuleDecl::addFile in FileUnit::getOrCreateSynthesizedFile is deleterious and should be removed. Doing so will come as part of a larger refactoring.
rdar://94043340
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.
This is some groundwork to make it possible to flip the `-enable-experimental-string-processing` flag on by default if and when it passes Swift Evolution. This PR itself do **not** change the defaults.
- Do not implicitly import _StringProcessing when building a module interface.
- Do not implicitly import _StringProcessing when core libraries, same as _Concurrency.
Replace `-warn-concurrency` with a more granular option
`-swift-concurrency=`, where the developer can select one of three
different "modes":
* `off` disables `Sendable` checking for most cases. (This is the Swift
5.5 and Swift 5.6 behavior.)
* `limited` enables `Sendable` checking within code that has adopted
Swift concurrency. (This is currently the default behavior.)
* `on` enables `Sendable` and other concurrency checking throughout
the module. (This is equivalent to `-warn-concurrency` now).
There is currently no distinction between `off` and `limited`. That
will come soon.
Implements the flag part of rdar://91930849.
We add a new flag to disable the implicit import of `_StringProcessing`, similar to `-disable-implicit-concurrency-module-import`. We need this to build `_RegexParser` when `-enable-experimental-string-processing` is enabled by default, because `_StringProcessing` currently imports `_RegexParser` publicly (non-implementation-only).
Two paths missed setting up overlays:
- `CompletionInstance` when checking files from dependencies
- `SwiftASTManager` when reading in files that it would later replace
all inputs with
(1) would cause the AST context not to be re-used, even though nothing
had changed. (2) caused all non-completion functionality to fail for any
symbols within files only specified by the overlay.
Resolves rdar://85508213.
This change removes the -emit-cxx-header option, and adds a new -emit-clang-header-path option instead. It's aliased to -emit-objc-header-path for now, but in the future, -emit-objc-header-path will alias to it. After this change Swift can start emitting a single header file that can be expose declarations to C, Objective-C, or C++. For now C++ interface is generated (for all public decls) only when -enable-cxx-interop flag is passed, but that behavior will change once attribute is supported.
ABI descriptors should always be emitted as sidecars for library-evolution-enabled modules.
However, generating these files requires traversing the entire module (like indexing), which may
hit additional deserialization issues. To unblock builds, this patch introduces a flag to skip
the traversing logic so that we emit an empty ABI descriptor file. The empty file serves as
a placeholder so that build system doesn't need to know the details.
PublicCMOSymbols stores symbols which are made public by cross-module-optimizations.
Those symbols are primarily stored in SILModule and eventually used by TBD generation and validation.
Instead of checking that the stdlib can be loaded in a variety of places, check it when setting up the compiler instance. This required a couple more checks to avoid loading the stdlib in cases where it’s not needed.
To be able to differentiate stdlib loading failures from other setup errors, make `CompilerInstance::setup` return an error message on failure via an inout parameter. Consume that error on the call side, replacing a previous, more generic error message, adding error handling where appropriate or ignoring the error message, depending on the context.
- Frontend: Implicitly import `_StringProcessing` when frontend flag `-enable-experimental-string-processing` is set.
- Type checker: Set a regex literal expression's type as `_StringProcessing.Regex<(Substring, DynamicCaptures)>`. `(Substring, DynamicCaptures)` is a temporary `Match` type that will help get us to an end-to-end working system. This will be replaced by actual type inference based a regex's pattern in a follow-up patch (soon).
- SILGen: Lower a regex literal expression to a call to `_StringProcessing.Regex.init(_regexString:)`.
- String processing runtime: Add `Regex`, `DynamicCaptures` (matching actual APIs in apple/swift-experimental-string-processing), and `Regex(_regexString:)`.
Upcoming:
- Build `_MatchingEngine` and `_StringProcessing` modules with sources from apple/swift-experimental-string-processing.
- Replace `DynamicCaptures` with inferred capture types.
