When a module has been imported `@preconcurrency` in source, when it is printed
in a `swiftinterface` file it should be printed along with the attribute to
ensure that type checking of the module's public declarations behaves
consistently.
This fix is a little unsatisfying because it adds another a linear scan over
all imports in the source for each printed import. This should be improved, but
it can be done later.
Resolves rdar://136857313.
When emitting diagnostics for the Embedded Swift restrictions outside
of Embedded Swift mode, consider `#if $Embedded` and `#if
hasFeature(Embedded)` configurations. If the code where we would emit
the diagnostic would be disabled in Embedded Swift by one of those
checks, don't emit the diagnostic. This helps code that can compile
either with Embedded or regular Swift stay within the restrictions on
Embedded Swift.
Untyped throws depends on existentials (`any Error`), and is therefore
not available in Embedded Swift. Introduce a diagnostic that diagnoses
any use of untyped throws, suggesting that one use typed throws
instead.
Make this an opt-in diagnostic enabled with `-Wwarning
EmbeddedRestrictions`, whether in Embedded Swift or not, using the
"default ignore" flag on these new warnings. Document this new
diagnostic group, and put the existing Embedded Swift error about
weak/unowned references in it as well.
Part of the general push to have the type checker identify code that
will not compile as Embedded Swift earlier, rdar://133874555.
We still need to solve a branch with a ReturnStmt to avoid leaving
the contextual result type unbound. This isn't currently legal anyway,
so isn't likely to come up often in practice, but make sure we can
still solve.
If a `.swiftinterface` file does not include an explicit `-language-mode`
option (or its predecessor `swift-version`) and needs to be built as a
dependency of a client compilation, then the invocation to build the module
from interface would end up inheriting the language mode that the client code
is built with. This can result in spurious type checking diagnostics or even
mis-compilation. To ensure that a module interface is always built using the
language mode that its source code was originally built with, require an
explicit `-language-mode` option when emitting swiftinterface files.
Resolves rdar://145168219.
An always enabled availability domain is implicitly available in all contexts,
so uses of declarations that are marked as `@available` in the domain are never
rejected. This is useful for an availability domain representing a feature flag
that has become permanently enabled.
Partially resolves rdar://157593409.
This change introduces a thread-safe version of the 'SerializedDiagnosticConsumer' and refactors scanning compilation instance creation code to ensure this consumer gets added when the scanner query configuration command-line includes '-serialized-diagnostics-path' option.
This is useful for ArrowExpr when the sub-expressions aren't valid
TypeExprs. Rather than throwing away the AST, attach it to the
ErrorTypeRepr to ensure we can still type-check it. This ensures
semantic functionality still works correctly, and fixes a crash where
we'd stop visiting an invalid binding pattern, losing track of the
nested VarDecl.
We would crash in some cases, or produce a slightly misleading
diagnostic about same-element requirements, which are related but
not quite the same.
In the fullness of time, we should figure out this corner of the
language. Until then, add a new diagnostic since this is really
about same-type requirements between concrete types and packs.
Fixes rdar://159790557.