Require explicit statement of all Copyable/Escapable requirements for conditional Copyable/Escapable conformances.
#78705
Conversation
jckarter
requested review from
eeckstein,
ahoppen,
bnbarham,
CodaFi,
DougGregor,
hamishknight,
rintaro,
kavon,
hborla,
slavapestov,
xedin and
tshortli
as code owners
|
@swift-ci Please test |
| } | ||
| // Or it can be implied by a requirement on something that's inherently | ||
| // copyable. | ||
| if (req.req.getKind() == RequirementKind::Superclass) { |
There was a problem hiding this comment.
What about same-type requirements to concrete types like T == Int? Also doesn't T: AnyObject imply Copyable today?
There was a problem hiding this comment.
One thing I was hoping to hear from you (or maybe @kavon) was whether there was a preexisting operation to filter out implied requirements. I see that further down, these get fed into a RequirementMachine, but I'm not sure whether I can do that and still figure out which requirements came from implicit defaults or not in the resulting generic signature.
There was a problem hiding this comment.
I don't think we already have a utility to determine which Copyable/Escapable requirements were explicitly written in source or not. I hadn't built-in state tracking like that, especially since it'd need to survive the RequirementMachine all the way into a GenericSignature. I think you lose that implicit/explicit information after you construct the GenericSignature from the raw StructuralRequirements.
What we do have is a sort of reconstruction of the minimal requirements needed to specify a ProtocolDecl's GenericSignature in this getSyntacticInheritanceClause for the purpose of the ASTPrinter. It filters out all invertible protocols though.
jckarter
force-pushed
the
explicit-conditional-invertible-extension-requirements
branch
from
020782d to
f4898f5
Compare
|
@swift-ci Please test |
jckarter
force-pushed
the
explicit-conditional-invertible-extension-requirements
branch
from
f4898f5 to
a22bafc
Compare
|
@swift-ci Please test |
jckarter
force-pushed
the
explicit-conditional-invertible-extension-requirements
branch
from
a22bafc to
4cba8c1
Compare
|
@swift-ci Please test |
… for conditional `Copyable`/`Escapable` conformances. As specified by the SE-0446 acceptance, extensions that declare a type's conditional `Copyable` or `Escapable` ability must reiterate explicitly all of the `Copyable` and/or `Escapable` requirements, whether required or not required (by e.g. `~Copyable`) that were suppressed in the original type declaration.
jckarter
force-pushed
the
explicit-conditional-invertible-extension-requirements
branch
from
4cba8c1 to
a0a26b8
Compare
|
@swift-ci Please test |
| @@ -11,16 +11,20 @@ struct AttemptImplicitConditionalConformance<T: ~Copyable>: ~Copyable { | |||
| } | |||
| extension AttemptImplicitConditionalConformance: Copyable {} | |||
| // expected-error@-1 {{generic struct 'AttemptImplicitConditionalConformance' required to be 'Copyable' but is marked with '~Copyable'}} | |||
| // expected-error@-2 {{must explicitly state whether 'T' is required to conform to 'Copyable'}} | |||
There was a problem hiding this comment.
We should find a way to suppress the X is required to be Copyable but marked with ~Copyable error, in cases where this new error you've added would be emitted. The T: Copyable isn't inferred anymore on the extension, so it became unconditional and thus the old error appears.
But people are more likely to think T: Copyable is inferred, like other extensions, and your new message explains things much more clearly.
|
@swift-ci Please smoke test Linux |
1 similar comment
|
@swift-ci Please smoke test Linux |
As specified by the SE-0446 acceptance, extensions that declare a type's conditional
CopyableorEscapableability must reiterate explicitly all of theCopyableand/orEscapablerequirements, whether required or not required (by e.g.~Copyable) that were suppressed in the original type declaration.