We need to keep the original linkage because it would be illegal to call a shared not-serialized function from a serialized function.
Also, rename the API to create the specialized function.
As recommended in feedback on https://github.com/apple/swift/pull/71302, cache
the underlying clang module after loading it in `ImportResolver`, rather than
filtering it out of the overall set of resolved imports. This is more efficient
and results in less duplicated code that must identify the underlying clang
module.
Use similar scheme as DeclAttribute.
* Create `BridgedTypeAttribute.createSimple()` and
`BridgedTypeAttributes.add()`, instead of
`BridgedTypeAttributes.addSimple()`
* Create `DeclAttributes::createSimple()` to align with `TypeAttribute`
SE-0364 was implemented to discourage "retroactive" conformances that might
conflict with conformances that could be introduced by other modules in the
future. These diagnostics should not apply to conformances that involve types
and protocols imported from the underlying clang module of a Swift module since
the two modules are assumed to be developed in tandem by the same owners,
despite technically being separate modules from the perspective of the
compiler.
The diagnostics implemented in https://github.com/apple/swift/pull/36068 were
designed to take underlying clang modules into account. However, the
implementation assumed that `ModuleDecl::getUnderlyingModuleIfOverlay()` would
behave as expected when called on the Swift module being compiled.
Unfortunately, it would always return `nullptr` and thus conformances involving
the underlying clang module are being diagnosed unexpectedly.
The fix is to make `ModuleDecl::getUnderlyingModuleIfOverlay()` behave as
expected when it is made up of `SourceFile`s.
Resolves rdar://121478556
that are suppressed or downgraded until Swift 6.
There are a few benefits to using a `UntilSwiftVersion` diagnostic engine API,
including the diagnostic wrapping to communicate that the mistake will be an
error in Swift 6, and to include the mistake in the frontend statistic for
Swift 6 errors.
This should allow us to eventually simplify parsing of simple string literals in the new parse by not having to handle indentation of multiline string literals.
We run the builder, then use a small program that converts the JSON output into C code that generates the data. Compile that into a bundle, then load it as the prespecializations library. Then scan all the entries in the table and compare them with what the runtime builds dynamically.
Unify the implementation between single-expression
and multi-statement closures. Because we're now
storing a contextual type for single expression
closure returns, update a code completion test to
bring its behavior inline with the multi-statement
case.
This wasn't consistently used, and consequently
could result in some expressions getting their
parents invalidated. Instead, replace it with a
query to make sure we don't try and add an
expression we've already computed the parent info
for.
