How to disable implicit Foundation imports?

hassila · August 17, 2022, 12:53pm

I guess it is not yet capable, there's e.g.:

[SR-12872] dead Public symbols are never stripped

opened 06:33AM - 24 May 20 UTC

bug

| | | |------------------|-----------------|… |Previous ID | SR-12872 | |Radar | None | |Original Reporter | Walter (JIRA User) | |Type | Bug | <details> <summary>Additional Detail from JIRA</summary> | | | |------------------|-----------------| |Votes | 0 | |Component/s | | |Labels | Bug | |Assignee | None | |Priority | Medium | md5: 61a887ce47e57d13e3f175b10c7eb55b </details> **Issue Description:** Symbols declared with public visibility are never dead stripped by the linker, even when linking an executable where there is no expectation that the result would be linked into anything else (build setting "Exported symbols files" refrence to an empty file and thus unused symbols could be safely discarded). Stripping these symbols is important when building an executable that links to a large library that it only uses a portion of, to prevent code bloat. STEPS TO REPRODUCE ``` java public class Foo { func foo1() { print("1111") } } ``` we can write the code above in an empty project and build with linkmap generated, and we will still find symbol "Foo" in the linkmap even though we never call "Foo"

github.com/swiftlang/swift

[SR-14509] Pre-emptive testing for emit-dead-strippable work

opened 07:52PM - 19 Apr 21 UTC

swift-ci

bug compiler

| | | |------------------|-----------------|… |Previous ID | SR-14509 | |Radar | None | |Original Reporter | mren (JIRA User) | |Type | Bug | <details> <summary>Additional Detail from JIRA</summary> | | | |------------------|-----------------| |Votes | 0 | |Component/s | Compiler | |Labels | Bug | |Assignee | None | |Priority | Medium | md5: 9a43f214c5ecb7b52410c36f2eb50cd1 </details> **Issue Description:** Some high level information about emit-dead-strippable: Kuba is working on stripping Swift symbols if they are not used statically via a LTO pass GlobalDCE, which is guarded by emit-dead-strippable flag. This optimization has a great potential to reduce binary size. While testing this with an iOS app, we are hitting a few runtime crashes. The goal is to figure out cases of dynamic references to Swift symbols without a static reference, because that will break GlobalDCE in the sense it will incorrectly strip off symbols that are needed at runtime. objc_classes and objc_categories are such Swift symbols that we may need to selectively keep. Protocol conformances are another case, where instantiateConcreteTypeFromMangledName seems to need some conformance data at runtime where there are no static references to them and they are stripped off by GlobalDCE. Another potential case for runtime protocol conformance check is \`as? Protocol\` casts. We had some email exchanges about this, a quick summary of the issues and potential fixes: 1\> Dynamic lookup of Swift classes via ObjC interop Potential solution: symbolic encoding for ObjC classes as suggested by Joe: Currently we always refer to ObjC classes in mangled names by their runtime name, but we could introduce an escape code to embed a relative reference to the classref, which should be a small performance win for instantiation and also help the linker statically understand the dependency on the classref. 2\> Dynamic lookup of Swift symbols in objc_categories Potential solution: keep them for now 3\> Dynamic lookup of protocol conformances Joe has been working on an encoding for protocol conformances. Joe suggested a shorter-term hack that could unblock dead-stripping in the near-term: what if we emit the mangled strings, but then after the \`\0\` terminator, we can append relative references to all of the runtime entities that the mangled name needs but doesn't directly reference, like ObjC classrefs and protocol conformances? That way we don't need to implement type decoder support for new manglings, and for a nominal cost of 4 const bytes per reference, we prevent the linker from dead-stripping. We have a standalone test case that seems to cause runtime issue when checking conformance at runtime. The test case is currently on a private branch, specifically this commit: https://github.com/apple/swift/commit/13375542ea8d0206498a4368919e8bf834fdaa5b Thanks, Manman