Check the types of @objcImpl candidates against their requirements and diagnose *most* mismatches.
Unlike typical type matching rules, @objcImpl allows an implementation’s parameter *and* result types to be an IUO when the requirement isn’t. This runs against the normal covariance rules in the case of the result type. It’s meant to allow an implementation to handle nils passed to it and return nils even if the declaration formally claims nils are not permitted; this is occasionally necessary to reimplement Objective-C APIs without breaking ABI compatibility.
Fixes rdar://102063730.
Protocol composition types such as `P & Q` are similar to nested types
like `A.B` because the innermost type syntax node at the given position
doesn't cover the whole type. Adjust by looking back up the tree.
This all feels like a hack, and there should be a better way.
While here, fix the source ranges passed in to create
`CompositionTypeRepr`. We were tripping assertions due to missing
source-location information.
Bridge the simple type attributes like `@autoclosure` into an
`AttributedTypeRepr`. We don't validate the arguments, and we don't
handle more complicated attributes like `@convention(c)` just yet.
There is a modeling difference between the swift-syntax tree and the
C++ type representation (TypeRepr) that is a little odd here, so we
end up parsing the ellipsis on the C++ side rather than looking "up"
the syntax tree to find it.
This covers situations like `Pack{repeat each T1, repeat each T2}`
vs. `Pack{repeat $T1, repeat $T2}` where type variables are allowed
to bind to packs.
Resolves: rdar://109539394
Avoid parsing the syntax tree up-front, and instead
only parse it when required, which happens when either:
1. ASTGen parsing is enabled (currently disabled
by default)
2. Round trip checking is enabled for a primary
file (enabled by default in a debug build,
except when dep scanning or doing an IDE
operation)
3. We need to evaluate a macro in that file
This change therefore means that we now no longer
need to parse the syntax tree for secondary files
by default unless we specifically need to evaluate
a macro in them (e.g if we need to lookup a member
on a decl with an attached macro). And the same
for primaries in release builds.
rdar://109283847
Instead of being a part of 'directDependencies' on a module dependency info, make them a separate array of dependency IDs for Swift Source and Textual modules.
This will allow clients to still distinguish direct module dependencies imported from a given module, versus dependencies added because direct/transitive Clang module dependencies have Swift overlays.
This change does *not* remove overlay dependencies from 'directDependencies' yet, just adds them as a separate field on the module details info. A followup change will remove overlay and bridging header dependencies from 'directDependencies' once the clients have had a chance to adopt to this change.
Sema now diagnoses @objcImpl implementations with:
• The wrong settability (i.e. a `let` used for a `readwrite` property)
• The wrong kind (i.e. a method used for a property)
Before this change it was possible to:
1. Call mutating methods on a consume result.
2. assign into a consume (e.x.: var x = ...; (consume x) = value.
From an implementation perspective, this involved just taking the logic I
already used for the CopyExpr and reusing it for ConsumeExpr with some small
tweaks.
rdar://109479440
Some notes:
1. I implemented this as a contextual keyword that can only apply directly to
lvalues. This ensures that we can still call functions called copy, define
variables named copy, etc. I added tests for both the c++ and swift-syntax based
parsers to validate this. So there shouldn't be any source breaks.
2. I did a little bit of type checker work to ensure that we do not treat
copy_expr's result as an lvalue. Otherwise, one could call mutating functions on
it or assign to it, which we do not want since the result of copy_value is
3. As expected, by creating a specific expr, I was able to have much greater
control of the SILGen codegen and thus eliminate extraneous copies and other
weirdness than if we used a function and had to go through SILGenApply.
rdar://101862423
Opened existentials should be erased to the dependent upper bound
if the dependent member can be reduced to a concrete type. This
allows the generic signature to support parameterized protocol types
and bound generic class types by producing a more specific constraint
instead of just a plain protocol or class.
* Unify macro expansion parsing logic between MacroExpansionExpr and
MacroExpansionDecl
* Diagnose whitespace between '#' and the macro name
* Diagnose keyword as a macro name
The Swift compiler expects the context to remain stable between when a
module is built and loaded by a client. Usually the build system would
rebuild a module if a dependency changes, or the compiler would rebuilt
the module from a swiftinterface on a context change. However, such
changes are not always detected and in that case the compiler may crash
on an inconsistency in the context. We often see this when a clang
module is poorly modularized, the headers are modified in the SDK, or
some clang define change its API.
These are project issues that used to make the compiler crash, it
provided a poor experience and doesn't encourage the developer to fix
them by themselves. Instead, let's keep track of modularization issues
encountered during deserialization and report them as proper errors when
they trigger a fatal failure preventing compilation.
The Clang importer's Clang instance may be configured with a different (higher)
OS version than the compilation target itself in order to be able to load
pre-compiled Clang modules that are aligned with the broader SDK, and match the
SDK deployment target against which Swift modules are also built. In this case,
we must use the Swift compiler's OS version triple in order to generate the
binary as-requested.
This change makes 'ClangImporter' 'Implementation' keep track of a distinct
'TargetInfo' and 'CodeGenOpts' containers that are meant to be used by clients
in IRGen. When '-clang-target' is not set, they are defined to be copies of the
'ClangImporter's built-in module-loading Clang instance. When '-clang-target' is
set, they are configured with the Swift compilation's target triple and OS
version (but otherwise identical) instead. To distinguish IRGen clients from
module loading clients, 'getModuleAvailabilityTarget' is added for module
loading clients of 'ClangImporter'.
The notion of using a different triple for loading Clang modules arises for the
following reason:
- Swift is able to load Swift modules built against a different target triple
than the source module that is being compiled. Swift relies on availability
annotations on the API within the loaded modules to ensure that compilation
for the current target only uses appropriately-available API from its
dependencies.
- Clang, in contrast, requires that compilation only ever load modules (.pcm)
that are precisely aligned to the current source compilation. Because the
target triple (OS version in particular) between Swift source compilation and
Swift dependency module compilation may differ, this would otherwise result in
builtin multiple copies of the same Clang module, against different OS
versions, once for each different triple in the build graph.
Instead, with Explicitly-Built Modules, Swift sets a '-clang-target' argument
that ensures that all Clang modules participating in the build are built against
the SDK deployment target, matching the Swift modules in the SDK, which allows
them to expose a maximally-available API surface as required by
potentially-depending Swift modules' target OS version.
--------------------------------------------
For example:
Suppose we are building a source module 'Foo', targeting 'macosx10.0', using an
SDK with a deployment target of 'macosx12.0'. Swift modules in said SDK will be
built for 'macosx12.0' (as hard-coded in their textual interfaces), meaning they
may reference symbols expected to be present in dependency Clang modules at that
target OS version.
Suppose the source module 'Foo' depends on Swift module 'Bar', which then
depends on Clang module `Baz`. 'Bar' must be built targeting 'macosx12.0'
(SDK-matching deployment target is hard-coded into its textual interface). Which
means that 'Bar' expects 'Baz' to expose symbols that may only be available when
targeting at least 'macosx12.0'. e.g. 'Baz' may have symbols guarded with
'__MAC_OS_X_VERSION_MIN_REQUIRED >= __MAC_12_0'. For this reason, we use
'-clang-target' to ensure 'Baz' is built targeting 'macosx12.0', and can be
loaded by both 'Foo' and 'Bar'.
As a result, we cannot direclty use the Clang instance's target triple here and
must check if we need to instead use the triple of the Swift compiler instance.
Resolves rdar://109228963
Subscripts today don't support any form of ownership specifier
for its parameters Since noncopyable types require such a
specifier, it's not helpful to emit an error suggesting to add
the specifier.
rdar://109233314
We should no longer say "macro implementation must be provided via '-load-plugin-library'" as there are multiple ways to pick up a macro dependency. Here's an improved version:
> warning: external macro implementation type 'MissingModule.MissingType' could not be found for macro 'missingMacro1'; the type must be public and provided by a macro target in a Swift package, or via '-plugin-path' or '-load-plugin-library'
SE-390 concluded with choosing the keyword discard rather than forget for
the statement that disables the deinit of a noncopyable type. This commit
adds parsing support for `discard self` and adds a deprecation warning for
`_forget self`.
rdar://108859077
Suggesting the addition of an `@available` attribute on Linux and Windows is
inapprorpriate given that Swift is not ABI stable on those platforms.
Resolves rdar://107387133
