Lift restrictions of access check for inlinalbe package symbols referenced in interfaces.

[elsh]

Package decls are only printed in interface files if they are inlinable
(@usableFromInline, @inlinable, @_alwaysEmitIntoClient). They could be
referenced by a module outside of its defining module that belong to the same
package determined by the package-name flag. However, the flag is only in
.swiftmodule and .private.swiftinterface, thus type checking references of
inlinable package symbols in public interfaces fails due to the missing flag.
Instead of adding the package-name flag to the public interfaces, which
could raise a security concern, this PR grants access to such cases.

Resolves rdar://116142791

[elsh]

@swift-ci smoke test

[tshortli]

I think we should strive to hide package names from public .swiftinterfaces. What if we just carved out a typechecking exception for @usableFromInline package decls in .swiftinterfaces instead, allowing them to be present without knowing the package name?

[elsh]

I think we should strive to hide package names from public .swiftinterfaces. What if we just carved out a typechecking exception for @usableFromInline package decls in .swiftinterfaces instead, allowing them to be present without knowing the package name?

That was my initial thought but after having discussed more with @xymus this way seemed simpler (so users don't have to figure out why they sometimes see package-name and sometimes don't). I'm open to adding more restrictions though.

[elsh]

@swift-ci smoke test

[tshortli]

I don't think we should be too concerned about users being confused about why -package-name is absent from a public .swiftinterface; most developers have no reason to inspect a .swiftinterface and ultimately they are a compiler implementation detail. The typechecking rule that requires -package-name be specified when using package decls is meant to help developers avoid mistakenly forgetting to configure their package/project properly for package use. That's useful when typechecking source but I don't think the diagnostic makes as much sense in the context of typechecking a swiftinterface. I'd rather we complicate typechecking rules to treat swiftinterfaces differently (we do this a lot already) so that we can avoid leaking unnecessary details in the SDK.

[zoecarver]

Yay! Thank you Ellie!

[tshortli]

If what I'm suggesting is more complicated than I'm imagining to implement, then a version of this approach that would satisfy me more would be to print a placeholder package name instead of the real package name (ideally the placeholder value is known to the compiler and only accepted when parsing interfaces) .

[xymus]

The way is see the alternative suggested by @tshortli would mean to lift the package restriction when building swiftinterfaces, basically treating them as public at that time. I agree that it should work fine, and the real package boundary is enforced during compilation from source and from private swiftinterface. I expect it to be easy enough to implement at this time where only @usableFromInline and @inlinable package decl are in swiftinterfaces but might require more care when we add a package swiftinterface.

I am not too worried about having the package name in the public swiftinterface at this time either. Only swiftpm automatically sets a package name and we can expect this name to already be public. Adopters in Xcode projects have been setting this value manually. Choosing a package name in Xcode is a similar problem to choosing the module name, leaks can be reported by the same tooling.

My main worry about having the package name in the public swiftinterface is for external clients to accidentally use the same package name. The compiler could then error on the import of a module from the same package rebuilt from the swiftinterface. We have a similar problem with module names again.

[elsh]

Modified to print the flag only if the interface contains inlinable (@usableFromInline, @inlinalbe, @_alwaysEmitIntoClient) package decls.

[elsh]

@swift-ci smoke test

[tshortli]

Modified to print the flag only if the interface contains inlinable (@usableFromInline, @inlinalbe, @_alwaysEmitIntoClient) package decls.

That's an improvement over always printing the package name, but I'd still like to know if just lifting the restriction entirely is a reasonable option so that we never have to print the package name .swiftinterfaces which is what I'd prefer.

[elsh]

@swift-ci smoke test

[elsh]

Modified to print the flag only if the interface contains inlinable (@usableFromInline, @inlinalbe, @_alwaysEmitIntoClient) package decls.

That's an improvement over always printing the package name, but I'd still like to know if just lifting the restriction entirely is a reasonable option so that we never have to print the package name .swiftinterfaces which is what I'd prefer.

Modified to lift restrictions instead.

[elsh]

@swift-ci smoke test

[tshortli]

Thanks for implementing the approach I suggested! Looks like it turned out reasonably straightforward.

[elsh]

@swift-ci smoke test

[elsh]

Thanks for implementing the approach I suggested! Looks like it turned out reasonably straightforward.

Np! Thanks for suggesting and sticking with the approach so we can keep internal details hidden from users.

[elsh]

@swift-ci smoke test windows