AST: Inherit access level of an opaque type decl from its naming decl #66515
Conversation
|
@swift-ci please test |
Good idea, I think it makes sense to do that. However, I'd like to make that part of the change on |
|
@swift-ci please test |
tshortli
force-pushed
the
usable-from-inline-opaque-type-decl-linkage
branch
from
01bec1d to
9367f16
Compare
When an `OpaqueTypeDecl` is constructed, the access level attributes of the decl that names the opaque type were copied on to it. However, the `@usableFromInline` attribute is not permitted on every decl, so it does not get copied. This in turn causes access level computations for opaque types to fail to take `@usableFromInline` into account and that results in the emitted symbol getting the wrong linkage during IRGen. The fix is to make access level computations take this quirk of opaque types into account directly (like they already to for several other kinds of decls), instead of relying on copying of attributes. Resolves rdar://110544170
tshortli
force-pushed
the
usable-from-inline-opaque-type-decl-linkage
branch
from
9367f16 to
775b4a4
Compare
|
@swift-ci please test |
|
Removing the attribute copying revealed that my previous approach to the fix was incomplete. I've updated the PR to better match how access level exceptions for other kinds of decls are handled, specifically by updating both |
That's why I enjoy these kinds of cleanups. Thank you for seeing this through! |
When an
OpaqueTypeDeclis constructed, the access level attributes of the decl that names the opaque type are copied on to it. However, the@usableFromInlineattribute is not permitted on every decl, so it does not get copied. This in turn causes effective access level computations for opaque types to fail to take@usableFromInlineinto account and that results in the emitted symbol getting the wrong linkage during IRGen. The fix is to make the effective access computation take this quirk of opaque types into account directly, instead of relying on copying of attributes.Resolves rdar://110544170