Temporarily cherry-pick Swift 5.9’s behavior of turning @objcImplementation errors into warnings to 5.10 until we fix the last few bugs in these diagnostics.
The FullApplySite itself can already be null, and indeed this function
was producing `llvm::Some(FullApplySite())` when called on ApplySite
instances which weren't actually full.
This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
This is a very large diagnostic, where the second half is mostly aimed
at macro authors rather than clients. Cut it down to the base
diagnostic.
Resolves rdar://113646544.
This reverts commit 20f99b2822.
The assert triggers in in the i386 build in the function:
// specialized Substring.UnicodeScalarView.replaceSubrange<A>(_:with:)
We fix up the VWT pointer, but not the heap destroyer. This doesn't matter for classes which use ObjC refcounting, which is the common case for dynamic subclasses, because that doesn't use the heap destroyer pointer. But it does matter for classes that use native Swift refcounting, such as classes that don't inherit from NSObject, or actors.
rdar://113657917
This will be used to provide a safe overload of `std::vector::erase` in Swift.
`std::vector::erase` is not currently imported into Swift because it returns a C++ iterator.
rdar://113704853
* add `GlobalVariable.staticInitializerInstructions` to access all initializer instructions of a global
* implement `GlobalVariable.staticInitValue` with `GlobalVariable.staticInitializerInstructions`
* this requires that `InstructionList.reversed()` works without accessing the parent block of the iterator instruction
* allow `Context.erase(instruction:)` to delete instructions from a global's initializer list, which means to handle the case where a deleted instruction has no parent function.
For a redundant pair of pointer-address conversions, e.g.
%2 = address_to_pointer %1
%3 = pointer_to_address %2 [strict]
replace all uses of %3 with %1.
Without this fix, the new 'consuming' and 'borrowing' keywords cannot
be used with trivial types. Which means, for example, they can't be
used in macro expansions that work on various types.
Fixes patterns like:
public func test1(i: consuming Int) -> Int {
takeClosure { [i = copy i] in i }
}
public func test2(i: borrowing Int) -> Int {
takeClosure { [i = copy i] in i }
}
public func test3(i: consuming Int) -> Int {
takeClosure { i }
}
// Sadly, test4 is still incorrectly diagnosed.
public func test4(i: borrowing Int) -> Int {
takeClosure { i }
}
Fixes rdar://112795074 (Crash compiling function that has a macro annotation and uses `consuming`)
