-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[SR-488] Crash when emitting store into a generic member, from initializer in an extension #43105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I think the issue arises from the condition |
cc @slavapestov who might have some chance at fixing this. I think |
Extensions have different archetypes than the extended type. I think the problem is that the archetype from the context of the type should not be showing up in the SIL at all. I'll take a look. |
We cannot just re-use original archetypes in the extension, because it might have a different set of generic parameters, eg 'extension SomeClass where T.AssocType == Int'. |
The pattern initializer expression is always written in terms of the original archetypes, and SILGen just blindly emits it into the constructor, even if the constructor is in a different context. |
What we need to do is emit each initializer into its own SIL function, with a new kind of SILDeclRef to refer to pattern initializer functions. Extension initializers will then call these functions instead of directly emitting the expression in the initializer. This function will have a generic signature and interface type, and re-use the original archetypes from the containing declaration. When called from an extension, the right substitutions will be used. |
My knowledge of this is limited, but shouldn't the extension have awareness of the extended type's archetypes too? Shouldn't it be possible to simply enumerate the members that are being initialized, and emit the initializers with correct knowledge of the type of the member (which, as you said, may be less constrained than the extension's own archetypes)? |
Joe also mentioned there's an orthogonal issue – we need Sema diagnostics to ban extensions from adding designated initializers outright, if any of these are true:
|
Archetypes are specific to a given scope (more precisely, a DeclContext). a SILFunction's body can only use archetypes from that context, because SIL and IRGen rely extensively on the pointer identity of archetypes making sense. The problem is that initializers are arbitrary Exprs, so unless we rework all of SILGen to remap types arbitrarily, it won't work in the general case. Putting initializers in their own function makes sense for other reasons too. We've had bugs in the past with closures and such crashing in initializer expressions because of bits of SILGen not being set up to emit Exprs more than once. Emitting the initializer expression once in its own function associated with the original type is the sanest fix. |
An analogous situation exists with default argument initializers – take a look at how we emit those, and how they're handled in type lowering and SILDeclRefs, etc. Jacob, if you wanted to take this on, I'd be happy to help in any way I can! 🙂 |
Fixed in #3949 |
Attachment: Download
Additional Detail from JIRA
md5: 4cc3ecb039495bae0b76cbb3c7e41251
is duplicated by:
relates to:
Issue Description:
When a generic type
Blah<Value>
contains a generic property with a default value, such asvar backing: Value? = nil
, the compiler will crash if an initializer is placed in an extension (even in the same file).The stack trace is:
The text was updated successfully, but these errors were encountered: