[Serialization] Expect missing custom attributes in deserializeDeclCommon #62328
Conversation
|
@swift-ci Please smoke test |
| @@ -5306,7 +5306,7 @@ llvm::Error DeclDeserializer::deserializeDeclCommon() { | |||
|
|
|||
| // Do a quick check to see if this attribute is a move only attribute. If | |||
| // so, emit a nice error if we don't have experimental move only enabled. | |||
| if (Attr->getKind() == DeclAttrKind::DAK_MoveOnly && | |||
| if (Attr && Attr->getKind() == DeclAttrKind::DAK_MoveOnly && | |||
There was a problem hiding this comment.
Could also move this into AddAttribute where it's not null any more, or move into the if below (though I haven't looked where skipAttr is set, so maybe that's not possible?).
There was a problem hiding this comment.
It looks like skipAttr is set to true whenever Attr remains null. We could likely remove skipAttr, or just exit when we can't set the attribute.
|
FWIW this is a little confusing to me, I'd expect basically any test that deserializes custom attributes to be crashing if this was the case 🤔. Does it only happen in very specific circumstances? |
|
It would only crash when a custom attribute depends on implementation-only imported details, in such a case we ignore the attribute. In this case the attribute was applied to a private var, so we shouldn't even try to deserialize it. |
Attr can be null here if it was a custom attribute from an implementation-only dependency. rdar://102525437
xymus
changed the title
|
Added back a test case that would have triggered this crash, using an implementation-only imported property wrapper on a private field. @swift-ci Please smoke test |
Attrcan be null here if it was a custom attribute from an implementation-only dependency.rdar://102525437