You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sema: Assert that we don't try to do direct-to-storage access of properties in resilient types
Right now, the rule is that any access of a stored property from a
constructor or destructor through 'self' must go directly to storage,
skipping observers or getter/setter overrides.
This means that in particular, constructors of resilient types cannot
be @_transparent, or defined in an extension in another module.
Previously, this was only caught in IRGen when the @_transparent
function was inlined into a function from another module, which made
debugging difficult.
Now, we hit an assert in Sema in this case. Of course it should be a
diagnostic; we'll get there eventually.
We could partially lift the restriction, allowing convenience
initializers to be defined @_transparent or be added in extensions,
by having accesses of stored properties from convenience inits go
through accessors. This would be safe, because at that point, we must
already have performed a self.init() delegation, however it would
potentially break existing code in subtle ways.
Also, this patch marks the RangeIterator and Range types @_fixed_layout,
since they define @_transparent initializers and this tripped the
new assert. Furthermore, note that the @_transparent initializer
must be versioned because it is inlined into another versioned
@_transparent function.
0 commit comments