After https://github.com/apple/swift/pull/40793, alloc_boxes all have
their lifetimes protected by a lexical borrow scope. In that PR, DI had
been updated to see through begin_borrow instructions from a project_box
to a mark_uninitialized. It did not, however, correct the end_borrow
instructions when destroy_values of mark_uninitializeds were replaced
with destroy_addrs of project_boxes. That is done here.
In a bit more detail, in the following context
%box = alloc_box
%mark_uninit = mark_uninitialized %box
%lifetime = begin_borrow [lexical] %mark_uninit
%proj_box = project_box %lifetime
When it is not statically known whether a field is initialized, we are
replacing the instruction
// before
destroy_value %mark_uninit
// after
with the following diamond
// before
%initialized = load
cond_br %initialized, yes, no
yes:
destroy_addr %proj_box
br bottom
no:
br bottom
bottom:
dealloc_box %box
br keep_going
keep_going:
// after
Doing so is problematic, though, because by SILGen construction the
destroy_value is always preceded by an end_borrow:
end_borrow %lifetime
destroy_value %mark_uninit
Previously, that end_borrow remained above the
%initialized = load
instruction in the above. That was invalid because the the newly
introduced
destroy_addr %proj_box
was a use of the borrow scope (%proj_box is a projection of the
begin_borrow) and consequently must be within the borrow scope.
Note also that it would not be sufficient to simply emit the diamond
before the end_borrow. The end_borrow must come before the destruction
of the value whose lifetime it is protecting (%box), and the diamond
contains the instruction to destroy that value (dealloc_box) in its
bottom block.
To resolve this issue, just move the end_borrow instruction from where
it was to before the dealloc box. (This is actually done by moving it to
the top of the diamond's "continue" block prior to the emission of that
dealloc_box instruction.)
rdar://89984216
There are three kinds of invariant 'Self' uses here:
- 'Self' appears as the left hand side of a same-type requirement between type parameters
- 'Self' appears as a structural component of the right hand side of a concrete type requirement
- 'Self' appears as a structural component of the right hand side of a superclass requirement
My previous fix only handled the first case. Generalize it to handle all three.
Fixes rdar://problem/74944514.
There is an edge case where the Requirement Machine produces a different
minimal signature than the GenericSignatureBuilder:
protocol P {
associatedtype X where X == Self
}
class C : P {
typealias X = C
}
<T where T : P, T : C>
The GenericSignatureBuilder produces <T where T == C> and the Requirement
Machine produces <T where T : C>. The new interpretation makes more sense
with the 'concrete contraction' pre-processing pass that is done now.
The GenericSignatureBuilder's interpretation is slightly more correct,
however the entire conformance is actually invalid if the class is not
final, and we warn about it now.
I'm going to see if we can get away with this minor ABI change without
breaking anything.
This avoids feeding invalid type parameters to the Requirement Machine
when a protocol requirement looks similar to a protocol requirement in
the inherited protocol but has an incompatible type.
Fixes https://bugs.swift.org/browse/SR-15826 / rdar://problem/89641535.
See the comment at the top of ConcreteContraction.cpp for a detailed explanation.
This can be turned off with the -disable-requirement-machine-concrete-contraction
pass, mostly meant for testing. A few tests now run with this pass both enabled
and disabled, to exercise code paths which are otherwise trivially avoided by
concrete contraction.
Fixes rdar://problem/88135912.
When emitting a diagnostic, mark the TypeRepr as invalid and
return an ErrorType to ensure that the diagnostic is not
emitted again, and to muffle downstream diagnostics.
This could happen previously when computing the existential type
for a given archetype. In cases where an archetype is only constrained
to a class, return the class type directly rather than wrapping it
in an existential type.
The current check in MiscDiagnostics can only handle local 2-cycles as in:
func foo() -> some P { return bar() }
func bar() -> some P { return foo() }
Larger cycles, such as the 3-cycle present in the validation test in this patch cannot be detected without resolving all substitutions up front. Therefore, we take the tact that we can at least prevent the compiler from crashing. At runtime, instead, type resolution will blow out the stack.
The check here is simple: Plumb through a set of opaque type decls that the resolution machinery has already seen, and if we encounter a recursive opaque type substitution bail with the original opaque type.
rdar://87121502
Covers a missing case in codable synthesis for enums with argument
payloads that have internal and external labels. When the name of the
var decl is used, the internal name of the parameter becomes the key
instead of the API name. In this case, this causes an invalid reference
to an enum case with the internal name as an argument to be synthesized
in the derived Decodable conformance which (hopefully) crashes
downstream.
rdar://86339848
These fail with -requirement-machine-protocol-signatures=verify because
the GSB produces incorrect output. Enable the requirement machine
unconditionally for these tests, bypassing verification.
A new file test/Generics/same_type_requirements_in_protocol.swift
contains reduced versions of all of the failures, with FileCheck
used to confirm the exact requirement signature output.
Previously, when we reached the maximum nesting level, we changed the current token’s kind to an EOF token. A lot of places in the parser are not set up to expect this token change. The intended workaround was to check whether pushing a structure marker failed (which would change the token kind) and bail out parsing if this happened. This was fragile and caused assertion failures in assert builds.
Instead of changing the current token’s kind, and failing to push the structure marker, let the lexer know that it should cut off lexing, essentially making the input buffer stop at the current position. The parser will continue to consume its current token (`Parser.Tok`) and the next token that’s already lexed in the lexer (`Lexer.NextToken`) before reaching the emulated EOF token. Thus two more tokens are parsed than before, but that shouldn’t make much of a difference.
The concurrency runtime now deploys back to macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, which corresponds to the 5.1 release of the stdlib.
Adjust macro usages accordingly.
