Don't consider external functions in inter-procedural analysis, like …

[eeckstein]

…side-effect or escape analysis.

The behavior of functions in other libraries may change in past/future versions of the library. So the compiler should not make any assumptions about them.

rdar://problem/32275048

[eeckstein]

@swift-ci smoke test and merge

[jrose-apple]

This is conservative but not really what we want, especially since you've applied it to all functions and not just those that come from resilient modules. Also, does it include shared_external functions, which will get re-emitted anyway?

[eeckstein]

@jrose-apple good point about shared_external. I'll exclude such functions.

How do I check if a function comes from a non-resilient module?

[jrose-apple]

The ModuleDecl that the ModuleFile is attached to knows, but I don't think SIL functions store their origin at the moment. It might need to be something we track on SIL functions. (We already have getResilienceExpansion() there, but that's designed for the defining side, not the calling side.)

@atrick may have some thoughts here. (And Slava, of course, when he gets back.)

[atrick]

I don't have a better idea. I think it's safer to add an explicit flag with asserts rather than overload existing flags with new meanings.