Unresolvable diagnostics for access control on import specifiers

[compnerd]

Description

It is impossible to reconcile the diagnostics emitted for access control on imports.

Reproduction

package import typealias SWLLBuild.llbuild_pid_t
public import typealias SWLLBuild.ProcessDelegate
@_exported public import struct SWBLLBuild.CommandExtendedResult

package class TaskProcessDelegate: ProcessDelegate {
  package func processStarted(pid: llbuild_pid_t?) {
  }
}

Expected behavior

You should be able to specify the minimally visible specifier for the types.

1. Module 'SWBLLBuild' is imported as 'public' from the same file; this 'package' access level will be ignored
2. Public import of 'SWBLLBuild' was not used in public declarations or inlinable code

Environment

swiftc -version
Swift version 6.2-dev (LLVM 6447c07cd7bd63f, Swift d9e07280e43d548)
Target: x86_64-unknown-windows-msvc

Additional information

No response

[compnerd]

CC: @artemcm @tshortli @elsh

[tshortli]

You're looking for @xymus :)

[compnerd]

CC: @owenv @jakepetroules - this was prompted from the swiftlang/swift-build code

[xymus]

You should be able to specify the minimally visible specifier for the types.

This feature was considered in the proposal process of the access-level on imports (SE-0409) but we decided against it. So for the moment the following statement means two separate concepts: mark anything imported from SWLLBuild as package and bring in llbuild_pid_t for local use.

package import typealias SWLLBuild.llbuild_pid_t

I'm not certain what would be the best compiler change to accept this use case. I'm currently considering simply silencing the warning about Public import of 'SWBLLBuild' was not used in public declarations or inlinable code on scoped imports. This warning serves only as general help and in this case a proper solution to satisfy the compiler should be to mark all imports of SWBLLBuild as public. We could also add an extra note along with Module 'SWBLLBuild' is imported as 'public' from the same file; this 'package' access level will be ignored to explain the behavior with scoped imports.

My main argument against supporting per-type visibility with scoped imports is simply the complexity it brings. Not only implementing it is basically a distinct feature but it opens the door to some unintuitive configurations that would need a clear design. We also don't generally recommend using scoped imports, even the current integration of @_exported with scoped imports has been known to cause issues.