Fix circular dependency between SIL and AST libraries

[aschwaighofer]

No description provided.

[aschwaighofer]

@swift-ci Please smoke test

[slavapestov]

This should be namingDecl->getResilienceExpansion() == ResilienceExpansion::Minimal to correctly handle functions nested inside inlinable functions, accessors of inlinable properties ,etc

[aschwaighofer]

I am confused.

I thought I have to look at the resilience expansion of the context (the function in which I perform the substitution). This happens on the next lines.

The namingDecl is the decl that has the opaque result type. If the namingDecl function is inlinable and from a different resilient module it should still be okay to replace the result type.

ResilientModule.swift

struct ResilientStruct {
     @inlineable
     func namingDecl() -> some P {
         return Int64(1)
    }
}

ContextModule.swift


func context() {
    let r = ResilientStruct()
    let opaque = r.namingDecl() // Okay to specialize to Int64 here
}

[aschwaighofer]

Here are the rules I have currently implemented (or believe to have implemented ;-) :

• if the function with the opaque result type is inline-able allow substitution
  (see example above)
• if the context function in which we perform substitution has maximal resilience expansion and the context function and the opaque type's function are in the same module allow substitution
• if the opaque types's module is not resilient allow substitution
• otherwise disallow substitution

[slavapestov]

Sorry about the confusion. The right way to check if namingDecl is inlineable is "namingDecl->getResilienceExpansion() == ResilienceExpansion::Minimal ". You should never check for the presence of InlineableAttr directly.

[aschwaighofer]

Ah. Okay. Now I got it. Makes sense.

#24478