IRGen: We can't look through opaque archetypes if the underlying type contains a private type #27609
Conversation
… contains a private type Not without more context at least (where the substitution happens). The private type could be from a different TU. Yes, this can probably happen in earlier uses of opaque archetype substitution. For now, fix the known failure. rdar://56093964
|
@swift-ci Please test |
| type = type.subst(replacer, replacer, | ||
| SubstFlags::SubstituteOpaqueArchetypes) | ||
| ->getCanonicalType(); | ||
| auto underlyingTy = |
There was a problem hiding this comment.
Since you have an IRGenModule here, I think you should instead use getTypeInfo(type).isABIAccessible()
There was a problem hiding this comment.
isABIAccessible does not give the right answer for private non resilient types:
/// Whether this type is known to be ABI-accessible, i.e. whether it's
/// actually possible to do ABI operations on it from this current SILModule.
/// See SILModule::isTypeABIAccessible.
///
/// All fixed-size types are currently ABI-accessible, although this would
/// not be difficult to change (e.g. if we had an archetype size constraint
/// that didn't say anything about triviality).
IsABIAccessible_t isABIAccessible() const {
The failure occurs when we build the associated type witness. The associated type resolves to an opaque type and the underlying type contains the private type.
There was a problem hiding this comment.
Ah, good point. In that case, I think it's still worth extracting a new predicate since it might come up elsewhere.
Is 'private' access enough though? It seems if the declaration is internal, you'll run into the same problem.
There was a problem hiding this comment.
You are right internal access is problematic across modules (the problematic case can happen with non-inlineable functions from non resilient modules).
I will fix the code in the ReplaceOpaqueTypesWithUnderlyingTypes utility instead.
There was a problem hiding this comment.
New PR: #27666
|
Build failed |
|
@swift-ci Please smoke test linux |
Not without more context at least (where the substitution happens). The
private type could be from a different TU.
Yes, this can probably happen in earlier uses of opaque archetype
substitution. For now, fix the known failure.
rdar://56093964