Skip to content

[Sema] Diagnose exportability of decls limited by a non-public import #64014

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Mar 2, 2023

Conversation

xymus
Copy link
Contributor

@xymus xymus commented Mar 2, 2023

As part of access-level checks, ensure that types imported with a non-public access level are only used in decls with a compatible access-level. For example, we want to error on using a type imported as internal in a public function signature, but allow it in internal functions and lower, as well as allowing it in function bodies.

This change raises errors on wrongful use of types limited by an import and offers a note pointing to the import that did limit the imported type. This affects slightly previous diagnostics when the was wrongful use of a private and a fileprivate type in the same signature, diagnostics now strictly prefer to report the private type even if they both have a file-wide scope.

xymus added 2 commits March 1, 2023 14:41
Using an access-level on imports limit how imported types can be used in
API. This change extends TypeAccessScopeChecker to return both the
access scope of the target type and any import that limits where it can
be used. Diagnostics should use this information to raise errors and
point to related imports.
@xymus
Copy link
Contributor Author

xymus commented Mar 2, 2023

@swift-ci Please smoke test

private import PrivateLib // expected-note 2 {{module 'PrivateLib' imported as 'private' here}}

/// Simple ordering
public func publicFuncUsesPrivate(_ a: PublicImportType, b: PackageImportType, c: InternalImportType, d: FileprivateImportType, e: PrivateImportType) { // expected-error {{function cannot be declared public because its parameter uses a private type}}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this diagnostic indicate which type is the problematic type? I ask because I'm not sure if this only matches a fragment of the diagnostic.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's the whole text of the error, the problematic type is highlighted. I tested the highlights manually as I don't think we have a way to represent them in the verify mode yet, but that would be useful.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, I suppose a highlight makes it clear enough.

Copy link
Contributor Author

@xymus xymus Mar 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, after that error there is also a note pointing to the type definition. From the command line it would tell the type name clearly, from the IDE probably not that much but the highlight does a decent job there.

And then there's the note on the import if it lowered the access level of the problematic type.

Check the API of decls to ensure that imported types are only used in
decls with compatible access-level. For example, error on using a type
import as internal in a public function, but allow it in internal
functions and lower.

This change raises errors on wrongful use of types limited by an import
and offers a note pointing to the import that did limit the imported
type.
@xymus xymus force-pushed the access-level-import branch from c896208 to 75255d1 Compare March 2, 2023 02:36
@xymus
Copy link
Contributor Author

xymus commented Mar 2, 2023

@swift-ci Please smoke test

@xymus
Copy link
Contributor Author

xymus commented Mar 2, 2023

@swift-ci Please smoke test macOS

@xymus xymus merged commit fbac545 into swiftlang:main Mar 2, 2023
@xymus xymus deleted the access-level-import branch March 2, 2023 18:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants