Skip to content
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

[SR-2209] Make a real "AccessScope" type and use it in access checking #44816

Closed
belkadan opened this issue Jul 29, 2016 · 2 comments
Closed
Labels
compiler The Swift compiler in itself diagnostics QoI Bug: Diagnostics Quality of Implementation good first issue Good for newcomers improvement

Comments

@belkadan
Copy link
Contributor

Previous ID SR-2209
Radar None
Original Reporter @belkadan
Type Improvement
Status Closed
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Improvement, DiagnosticsQoI, StarterBug
Assignee gal (JIRA)
Priority Medium

md5: bc3d512877f80019fe70957946ca4ef4

relates to:

Issue Description:

To implement Swift 3's private I introduced a new concept called "access scope", which is used to check if it's okay to use a particular declaration. This is described pretty well in the commit message for 758cf64; the primary entry point is ValueDecl::getFormalAccessScope.

Currently, this function just returns a DeclContext like any other. There are two problems with this: (1) this isn't just any DeclContext, and it's often passed as an argument next to other DeclContexts (usually the use site), and (2) it erases the distinction between private and fileprivate for top-level declarations, which leads to diagnostics claiming something is fileprivate even though the user has written private.

Instead, we should create a new type AccessScope which just wraps a DeclContext, along with a bit saying whether a top-level DeclContext should be treated as private rather than fileprivate.

class AccessScope {
  llvm::PointerIntPair<const DeclContext *, 1, bool> value;
public:
  // useful constructors
  bool isPrivate() const { /*…*/ }
  const DeclContext *getDeclContext() const { /*…*/ }
  // more useful methods
};

The steps to do this are roughly:

1. Make a new AccessScope type that just wraps a plain DeclContext.
2. Propagate it into all uses of ValueDecl::getFormalAccessScope, transitively.
3. Turn all operations that combine access scopes into methods on AccessScope.
4. Add the "private" flag, using PointerIntPair as shown above to keep the overhead low.
5. Update or replace accessibilityFromScopeForDiagnostics in TypeCheckDecl.cpp to check the "private" flag.

I've tagged this as "StarterBug" because even though it involves a bit of spelunking through the codebase, each of these steps should be fairly obvious (i.e. there's not much design work), and you still get diagnostic improvements out at the end. The separate steps can also be reviewed separately, following Swift's incremental development model.

Please feel free to ask me for help on swift-dev!

@swift-ci
Copy link
Collaborator

swift-ci commented Sep 1, 2016

Comment by Aleksey Gaponov (JIRA)

Submitted a PR.

@belkadan
Copy link
Contributor Author

belkadan commented Dec 5, 2016

Aleksey implemented this in #4579 Thanks, Aleksey!

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler The Swift compiler in itself diagnostics QoI Bug: Diagnostics Quality of Implementation good first issue Good for newcomers improvement
Projects
None yet
Development

No branches or pull requests

2 participants