Take enable-testing into account when computing whether a class has resilient metadata

[aschwaighofer]

rdar://87617621

[aschwaighofer]

@swift-ci Please test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 74a0c2c

[aschwaighofer]

@swift-ci test linux

[slavapestov]

Elsewhere we assume that exposed-in-ABI-but-internal-in-source types are fragile. Perhaps the problem is that the client code should be using fragile access patterns instead of assuming the metadata base offset symbol exists for the internal subclass? But maybe it doesn't really matter.

[aschwaighofer]

I don't know which rules are supposed to apply here. My reasoning is the following:

The defining module is compiled with enable-testing (which I read as internal becomes public in importing modules if the import is @testable) and resilience enabled.

The using module imports the defining module with @testable import. Which makes internal -> public. So I believe my choice is reasonable: we behave as if the thing is public which also exposes that symbol.

[aschwaighofer]

the client code should be using fragile access patterns instead of assuming the metadata base offset symbol exists for the internal subclass

That would imply (I believe, right? fragile means known offset?) that you have to co-compile the module that imports the resilient module @testable, effectively disabling resilience for @testable imports, is that the semantics of @testable imports?

[aschwaighofer]

I guess using an internal symbol is already not resilient

[aschwaighofer]

But then we should also not be able to access it outside of the module so the view that it should just be treated as if it is public makes more sense to me.

[slavapestov]

FWIW, testable imports are already effectively non-resilient because we don't enforce resilience constraints on non-public types -- it would be source-breaking to -enable-testing if we did.

[aschwaighofer]

@slavapestov That line of argument make sense to me. Alternative approach: #41044