More progress on SE-0025 ('private' and 'fileprivate') #3755
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@swift-ci Please test |
Similar to the work in swiftlang/swift-corelibs-foundation#445. Groundwork for SE-0025 ('private' and 'fileprivate'). No intended functionality change.
More detail: some members are intended to have the same the access as their containing types. This doesn't fly for SE-0025 'private', which would limit the members to only being accessed from lexically within the type decl, instead anywhere the type itself can be seen. Instead, follow the rule for user-written members---internal by default---and then raise the access level to 'public' if necessary. This affects: - enum cases - deinitializers - protocol requirements - generic parameters - implicit initializers - inherited initializers - derived conformance members - synthesized typealiases for associated types
Similar to swiftlang#3753. Groundwork for SE-0025 ('private' and 'fileprivate'). No intended functionality change.
Parameters are normally given 'private' access, because they can only
be referred to within the body of the owning function. However,
single-expression closures allow a parameter to appear in a constraint
system in the containing context. Mark closure parameters as
'fileprivate' instead.
Similarly, 'private' at the top level is normally equivalent to
'fileprivate', but not for a decl that appears within top-level
imperative code, which has a TopLevelCodeDecl context. This currently
only happens for bindings in a top-level 'guard' statement; mark
these variables and constants as 'fileprivate' as well.
More progress on SE-0025 ('private' and 'fileprivate').
jrose-apple
force-pushed
the
private-and-fileprivate
branch
from
e74f8e3
to
ebdee21
Compare
|
Passed before rebase and passed locally. Merging. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
internal.fileprivate.Also contains the changes in #3753, because (a) the results should be consistent, and (b) I am just one person working on this and am doing it on one branch.
See the individual commit messages for more detail (and as a better way to review any of the changes).
This should be the last bit of groundwork on SE-0025 before flipping the switch!
Before merging this pull request to apple/swift repository:
Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
A smoke test on macOS does the following:
device standard libraries are not built.
version of these tests are not run.
A smoke test on Linux does the following:
tests are not run.
Validation Testing
Lint Testing
Note: Only members of the Apple organization can trigger swift-ci.