Unavailable enum elements cannot be instantiated at runtime without invoking
UB. Therefore the optimizer can consider a basic block unreachable if its only
predecessor is a block that terminates in a switch instruction matching an
unavailable enum element. Furthermore, removing the switch instruction cases
that refer to unavailable enum elements is _mandatory_ when
`-unavailable-decl-optimization=complete` is specified because otherwise
lowered IR for these instructions could refer to enum tag accessors that will
not be lowered, resulting in a failure during linking.
Resolves rdar://113872720.
Clang is no longer allowing function prototypes to leave out return types (see 2cb2cd242c). Fix a test header that does this for no particularly good reason.
Part of rdar://113413583.
The `isBoolType` operation within the Clang importer has a historical
definition that excludes the C++ `bool` and its use in C as an
extension. Retain that definition, and check for the actual `bool`
when importing C++ conversion functions into Swift.
Fixes two regressions in the Clang importer:
1. We started to import `bool`-typed Objective-C properties with their
getter names.
2. We started importing `bool`-typed Objective-C methods with an
NSError** parameter as `throws`.
Both of these changes could be considered improvements, but they
cannot be made without breaking source compatibility, so roll those
changes back to maintain source compatibility.
We should have a separate discussion about enabling this behavior for
Swift >= 6.
rdar://105837040
* WIP: Store layout string in type metadata
* WIP: More cases working
* WIP: Layout strings almost working
* Add layout string pointer to struct metadata
* Fetch bytecode layout strings from metadata in runtime
* More efficient bytecode layout
* Add support for interpreted generics in layout strings
* Layout string instantiation, take and more
* Remove duplicate information from layout strings
* Include size of previous object in next objects offset to reduce number of increments at runtime
* Add support for existentials
* Build type layout strings with StructBuilder to support target sizes and metadata pointers
* Add support for resilient types
* Properly cache layout strings in compiler
* Generic resilient types working
* Non-generic resilient types working
* Instantiate resilient type in layout when possible
* Fix a few issues around alignment and signing
* Disable generics, fix static alignment
* Fix MultiPayloadEnum size when no extra tag is necessary
* Fixes after rebase
* Cleanup
* Fix most tests
* Fix objcImplementattion and non-Darwin builds
* Fix BytecodeLayouts on non-Darwin
* Fix Linux build
* Fix sizes in linux tests
* Sign layout string pointers
* Use nullptr instead of debug value
Previously, the test didn't actually verify that the called witness
method was the witness method from the right method--all the methods had
the same implementation and just forwarded the type along to be printed.
Now an id specific to each method is printed as well.
In order to allow supporting `__strong` (and `__weak`) struct fields,
some parts of the ClangImporter needs to understand them. The changes in
this commit allows the type importer to allow the already supported
`__unsafe_unretained` struct fields, but still reject the `__strong` and
`__weak` fields. Later changes will add support for bridging `__strong`
and `__weak` fields.
All the code should be equivalent to the previous code, and since all
the structs with non-trivial copy/destroy are completely discarded, the
code should not even be hit in any case.
The included modifications in the tests check that the error and the
diagnostics note are produced correctly.
A member reference to a function with a dynamic 'Self' result type
can introduce a covariant return expression into the AST. This is
exposed by the (already deeply cursed) -self method on NSObject(Protocol).
Add a regression test and said cursed member to the mock SDK.
when two objc async functions are composed with each other,
i.e., f(g()), then the clean-ups for g() would get emitted
at an unexpected time, namely, during the suspension for
the call to f(). This means that using a clean-up to emit
the executor-hop breadcrumb was incorrect. The hop could
appear between a get_async continuation and its matching
await_continuation, which is an unsupported nested suspension.
This commit fixes that by removing the use of the breadcrumb
clean-up in favor of providing that breadcrumb directly to
the result plan, so that it may be emitted later on when the
result plan sees fit.
Fixes rdar://91502776
In C, one can provide a typedef name for an anonymous tag declaration in
one shot, e.g.,
typedef struct {
double x, y
} Point;
In this case, there are effectively two declarations at the C level:
the typedef and the struct. The Clang importer was only taking
attributes from the anonymous struct (i.e., the tag) and not from the
typedef. However, any attributes put before the `typedef` should apply
as well... so consider those, too.
For now, only do this for `swift_attr` attributes, because we're
seeing this primarily with `Sendable` annotations. In the future, we
can look to generalizing it, but that could have source-breaking
consequences.
Fixes rdar://91632960.
Stop pretending that an optional requirement is immutable via the `StorageImplInfo` request.
This approach has lead astray the conformance checker and may have had a negative impact
on other code paths, and it doesn't work for imported declarations because they bypass the
request. Instead, use a forwarding `AbstractStorageDecl::isSettableInSwift` method
that special-cases optional requirements.
The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
If `__attribute__((swift_attr(“@Sendable”)))` is applied to an ObjC method, ObjC property, C field, C variable, or C function, we will now make its result type `Sendable`.
For some entities, this technically had a different behavior previously, because `@Sendable` can be applied to `func`s to indicate that their interface type should be `@Sendable`. We don’t really want people to use this functionality on non-local functions, so we can safely remove it.
This isn’t quite interacting with `Unmanaged` the way we’d want, but I’ve included test cases for the current behavior with FIXME comments.
Fixes rdar://90491024.
When `__attribute__((swift_attr(“@Sendable”)))` is applied to a clang parameter Swift now attempts to make the type `Sendable` in a more comprehensive way than before:
* If it is a function type, it adds `@Sendable` to it.
* If it is a protocol composition type, it adds `& Sendable` to it.
* If it is a class, protocol, or generic class, it inserts it into a protocol composition and adds `& Sendable`.
* If it is a typealias, it *may* desugar it to a modified version of the underlying type.
* In various other cases, it recurses into the children of the type.
This allows Objective-C methods and functions to require that their arguments have a Sendable type without specifying a particular type they must belong to.
Fixes rdar://87727549.
During actor isolation inference, we would unconditionally choose the
isolation of the overridden decl (when, say, there is no attribute on the decl).
The overridden decl is identified with `getOverriddenDecl`.
This works mostly fine, but initializers have some unusual overridden decls
returned by that method. For example, in the following code:
```swift
@objc class PictureFrame: NSObject {
init(size: Int) { }
}
@MainActor
class FooFrame: PictureFrame {
init() {
super.init(size: 0)
}
}
```
that method claims that `FooFrame.init()` overrides `PictureFrame.init()`, when
it really does not! So, if we were to unconditionally take the isolation from
`PictureFrame.init()` (and thus `NSObject.init()`), then we'd infer that
`FooFrame.init()` has unspecified isolation, despite the nominal it resides in
being marked as `MainActor`. This is in essence the problem in SR-15694, where
placing the isolation directly on the initializer fixes this issue.
If `FooFrame.init()` really does override, then why can it be `MainActor`? Well,
we have a rule in one part of the type-checker saying that if an ObjC-imported
decl has unspecified isolation, then overriding it with isolation is permitted.
But the other part of the type-checker dealing with the isolation inference was
not permitting that.
So, this patch unifies how actor-isolation inference is conducted to reuse that
same logic. In addition, the inference now effectively says that, if the decl
has no inferred isolation, or the inferred isolation is invalid according to the
overriding rules, then we use the isolation of the overridden decl. This
preserves the old behavior of the inference, while also fixing this issue with
ObjC declarations by expanding where isolation is allowed.
For example, as a consequence of this change, in the following code:
```swift
@MainActor
class FooFrame: NotIsolatedPictureFrame {
override func rotate() {
mainActorFn()
}
}
```
if `NotIsolatedPictureFrame` is a plain-old not-isolated class imported from
Objective-C, then `rotate` will now have `MainActor` isolation, instead of
having unspecified isolation like it was inferred to have previously. This
helps make things consistent, because `rotate` is allowed to be `@MainActor` if
it were explicitly marked as such.
resolves rdar://87217618 / SR-15694
[CodeCompletion] Make ExpectedTypeContext a class with explicit getters/setters
This simplifies debugging because you can break when the possible types are set and you can also search for references to `setPossibleType` to figure out where the expected types are being set.
Swift string literals are only permitted to contain well-formed UTF-8, but C does not share this restriction, and ClangImporter wasn't checking for that before it created `StringLiteralExpr`s for imported macros; this could cause crashes when importing a header. This commit makes us drop these macros instead.
Although invalid UTF-8 always *did* cause a segfault in my testing, I'm not convinced that there isn't a way to cause a miscompile with a bug like this. If we somehow did generate code that fed ill-formed UTF-8 to the builtin literal init for Swift.String, the resulting string could cause undefined behavior at runtime. So I have additionally added a defensive assertion to StringLiteralInst that any UTF-8 string represented in SIL is well-formed. Hopefully that will catch any non-crashing compiler bugs like this one.
Fixes rdar://67840900.
If a method has an `async` variant, the non-`async` variant will now mark its completion handler parameter `@Sendable`. This shouldn't be a breaking change in Swift 5 code since these declarations are automatically `@_predatesConcurrency`.
Also adds:
• Support for `@_nonSendable` on parameters, which can be used to override this implicit `@Sendable`
• Support for `@Sendable` on block typedefs; it's generally going to be a good idea to mark completion block typedefs `@Sendable`.
Fixes rdar://85569247.
