The Swift Simplification pass can do more than the old MandatoryCombine pass: simplification of more instruction types and dead code elimination.
The result is a better -Onone performance while still keeping debug info consistent.
Currently following code patterns are simplified:
* `struct` -> `struct_extract`
* `enum` -> `unchecked_enum_data`
* `partial_apply` -> `apply`
* `br` to a 1:1 related block
* `cond_br` with a constant condition
* `isConcrete` and `is_same_metadata` builtins
More simplifications can be added in the future.
rdar://96708429
rdar://104562580
Some compilation paths access the opaque return type type by itself
without going through its function. So access to the type must be
protected, otherwise deserialization fails at getting the naming decl
when it's unsafe.
rdar://105085860
Resilient modules with testing enabled expose internal non-resilient
internal types. These types cannot be reliably used by testable clients
if they don't have all of their members known. For this reason, this
disabled deserialization safety in modules when testing is enabled.
rdar://104923020
Deserialization recovery lead the compiler to drop public constructors
overridding internal constructors. This limits the logic to dropping the
overriding relationship instead of the whole constructor. This applies
when the overriden constructor fails to deserialize and only when the
overriding relationship was marked as not affecting ABI.
rdar://104704832
A lot of existing regression tests rely on there
being some form of move-only classes, despite
them being something that will not be available
to users (and not complete).
This change introduces a `MoveOnlyClasses`
experimental feature so that those tests don't
need to be fully rewritten just yet. You need to
include `-enable-experimental-feature MoveOnlyClasses` along with
`-enable-experimental-move-only` to get move-only classes.
Loading all possible members for the static type AnyObject can trigger
deserialization of members of non-public types. Deserialization safety
should prevent this by refusing to load the members themselves and even
avoid accessing their context.
When writing decls to a swiftmodule files, the serialization logic
evaluates whether the decl will be safe to deserialize. This is inferred
from the access level of the decl, whether it's local, if the module is
built for testing, etc. If the decl in unsafe to deserialize, a record
will be written down before the decl itself in the swiftmodule file.
On the reader side, attempting to deserialize a decl marked as unsafe
raises a deserialization error early. This error is handled by the existing
deserialization recovery logic.
In theory, we want to consider as safe only decls that are actually needed by
the client. Marking as many internal details as possible as unsafe will
prevent more errors. Getting the right scope may require more work in
the future.
This change reflects the behavior of `DeclAttribute.printImpl` that
prints the `override` keyword in a swiftinterface only when the
overriden decl is also public.
This issue was detected when working on deserialization safety by public
overrides of private functions in the following tests:
test/Interpreter/vtables_multifile.swift
test/Interpreter/vtables_multifile_testable.swift
test/SILGen/accessibility_vtables_testable.swift
test/SILGen/accessibility_vtables_usableFromInline.swift
test/SILGen/vtables_multifile.swift
If the underlying type of an opaque type references an
implementation-only imported type, drop the underlying type information.
Without this fix, once we enable deserialization safety, we see crashes
or dropped decls in more existing tests:
IRGen/mangle-opaque-return-type.swift
IRGen/opaque_result_type_private_underlying.swift
Serialization/Recovery/implementation-only-opaque-type.swift
rdar://103238451
`OpaqueUnderlyingTypeChecker` should skip conditional availability
blocks if none of the conditions restrict the current target.
Resolves: rdar://103445432
