Add serialization/deserialization support for designated protocols fo… #19194
Conversation
|
@swift-ci Please smoke test |
There was a problem hiding this comment.
This should really be serialized as a Decl, not a Type, no?
There was a problem hiding this comment.
Yes that makes sense given that I am only using the type to get to the decl at this point. An earlier version of this added constructors for OperatorDecls that took TypeLocs.
There was a problem hiding this comment.
Note that this has poor recovery (read: will crash) if the protocol can't be deserialized for whatever reason. That's probably fine for now, but really there should be a recovery mechanism.
There was a problem hiding this comment.
What's a better approach? We seem to be doing something very similar in other places.
There was a problem hiding this comment.
Look for the uses of getTypeChecked elsewhere in the file. Moving over to that for everything is a big task, but we probably want new fields to be thinking about recovery.
There was a problem hiding this comment.
I only skimmed your previous proposal, but this confuses me: an identifier isn't enough to uniquely identify a type, so why bother?
There was a problem hiding this comment.
I don't understand what you're asking here, can you clarify?
|
I'll push another version of this once #19202 lands. |
…r operators. Parsing for these protocols in operator declarations is gated by -enable-operator-designated-protocols (added in #19145).
|
@swift-ci Please smoke test |
2 participants
…r operators.
Parsing for these protocols in operator declarations is gated by
-enable-operator-designated-protocols (added in
#19145).