Give BuiltinProtocolConformance a generic signature, which can be used to
describe the generic parameters used within the builtin conformance, e.g.,
`<T1, T2, T3>` for a tuple type `(T1, T2, T3)`. Also store the
conditional requirements as trailing objects, requiring them to be
precomputed by whatever builds the conformances. Together, this means
that builtin protocol conformances act like normal conformances with
respect to conditional requirements and substitutions: they will be
defined generically, then a specialized conformance will be layered on
top to provide the substitutions.
Start treating the null {Can}GenericSignature as a regular signature
with no requirements and no parameters. This not only makes for a much
safer abstraction, but allows us to simplify a lot of the clients of
GenericSignature that would previously have to check for null before
using the abstraction.
This code path can report compiler inconsistencies, so let's make the
pretty stacktrace more useful when debugging. We probably want to make
the assert on witness.getDecl() a hard error too, but this would break
existing projects at this time.
Parse and provide semantic checking for '@unchecked Sendable', for a
Sendable conformance that doesn't perform additional semantic checks
for correctness.
Part of rdar://78269000.
The toString has been updated so that it doesn't return a std::string
anymore. Instead, you have to pass the memory buffer in. This patch
cleans that up.
Access to a missing member on an AnyObject triggers a typo correction
that looks at all class members in imported modules. Make sure it
recovers from deserializing members referencing implementation-only
imported types.
rdar://79427805
It's a known issue that we are using arm64e interfaces contents for the arm64 target,
meaning the encoded module flags are specifying -target arm64e-x-x instead of
-target arm64-x-x. Fortunately, we can tell the target arch from the interface file
name, so we could sanitize the target to use by inferring arch from the file name.
Foundation imports CoreFoundation with `@_implementationOnly`,
so CoreFoundation's modulemap won't be read, and the dependent libraries
of CoreFoundation will not be automatically linked when using static
linking.
For example, CoreFoundation depends on libicui18n and it's modulemap has
`link "icui18n"` statement. If Foundation imports CoreFoundation with
`@_implementationOnly` as a private dependency, the toolchain doesn't have
CoreFoundation's modulemap and Foundation's swiftmodule doesn't import
CoreFoundation. So the swiftc can't know that libicui18n is required.
This new option will add LINK_LIBRARY entry in swiftmodule to
specify dependent libraries (in the example case, Foundation's
swiftmodule should have LINK_LIBRARY entry of libicui18n)
See also: [Autolinking behavior of @_implementationOnly with static linking](https://forums.swift.org/t/autolinking-behavior-of-implementationonly-with-static-linking/44393)
SILGen this builtin to a mandatory hop_to_executor with an actor type
operand.
e.g.
Task.detached {
Builtin.hopToActor(MainActor.shared)
await suspend()
}
Required to fix a bug in _runAsyncMain.
This is just a shortcut for @_semantics("optremark") to make it easier for
people to remember how to enable assembly vision remarks.
Now one can just type:
```
@_assemblyVision
func foo() {
...
}
```
and get all normal opt-remarks + assembly vision remarks.
This showed up when trying to convert swift-package-manager to build
using static linking on Windows. We would not correctly identify the
module as being static due to there being no DeclContext for emission.
Rather than outputting diagnostics and to stderr, output all the extra
information added when deserialization fatally fails to the pretty stack
trace instead. Since the pretty stack trace is added to crash logs, this
should avoid the dance of requesting the compiler output
- Moves the previous "**** DESERIALIZATION FAILURE ..." output to the
last pretty stack trace line
- Removes the module and compiler version notes added to the fatal
diagnostic
- Adds a new effective compiler version line for all frontend failure.
Somewhat duplicates the line from the driver, but adds in the
effective version
- Adds a new line for the full misc version of the module that failed.
May double up with previous "While reading from ..." lines that are
added in various deserialization methods, but better to have it
twice than not at all
Most invalid attributes are skipped from serialization entirely, but
custom attributes don't have their invalid bit set - the particular
custom attribute (eg. a property wrapper) is requested when needed and
skipped if invalid. Those checks can't set the invalid bit since the
attribute could be a different custom attribute (eg. a result builder).
When allowing errors any attribute could be on any decl, so don't verify
whether an attribute can appear on a decl. Note that these attributes
aren't serialized anyway since they'll be set to invalid during
typechecking and hence skipped.
It's currently not obvious in crash reports whether compiling with
errors is enabled or not. Since this option can make previously
"impossible" paths now possible, add a message to both the pretty stack
output and fatal deserialization diagnostics to point out that it is
enabled.
Titled as "// swift-module-flags-ignorable:", this new field contains new
frontend arguments that can be safely ignored by the older version of the compiler.
For compilers that don't know the field at all, all arguments in it are ignored.
rdar://78233352
