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

Harmonize rule extensions #5272

Merged
merged 2 commits into from Oct 11, 2023
Merged

Conversation

SimplyDanny
Copy link
Collaborator

@SimplyDanny SimplyDanny commented Oct 10, 2023

This allows to reduce existential types later.

@SwiftLintBot
Copy link

SwiftLintBot commented Oct 10, 2023

3 Warnings
⚠️ Big PR
⚠️ If this is a user-facing change, please include a CHANGELOG entry to credit yourself!
You can find it at CHANGELOG.md.
⚠️ This PR may need tests.
17 Messages
📖 Linting Aerial with this PR took 1.18s vs 1.17s on main (0% slower)
📖 Linting Alamofire with this PR took 1.55s vs 1.56s on main (0% faster)
📖 Linting Brave with this PR took 8.78s vs 8.76s on main (0% slower)
📖 Linting DuckDuckGo with this PR took 4.39s vs 4.39s on main (0% slower)
📖 Linting Firefox with this PR took 10.28s vs 10.31s on main (0% faster)
📖 Linting Kickstarter with this PR took 10.81s vs 10.8s on main (0% slower)
📖 Linting Moya with this PR took 0.62s vs 0.62s on main (0% slower)
📖 Linting NetNewsWire with this PR took 3.25s vs 3.25s on main (0% slower)
📖 Linting Nimble with this PR took 0.82s vs 0.81s on main (1% slower)
📖 Linting PocketCasts with this PR took 8.64s vs 8.62s on main (0% slower)
📖 Linting Quick with this PR took 0.4s vs 0.4s on main (0% slower)
📖 Linting Realm with this PR took 11.69s vs 11.62s on main (0% slower)
📖 Linting Sourcery with this PR took 2.79s vs 2.8s on main (0% faster)
📖 Linting Swift with this PR took 5.18s vs 5.18s on main (0% slower)
📖 Linting VLC with this PR took 1.53s vs 1.53s on main (0% slower)
📖 Linting Wire with this PR took 19.19s vs 19.13s on main (0% slower)
📖 Linting WordPress with this PR took 13.03s vs 13.0s on main (0% slower)

Here's an example of your CHANGELOG entry:

* Use consistent `internal` visibility for rule extensions.  
  [SimplyDanny](https://github.com/SimplyDanny)
  [#issue_number](https://github.com/realm/SwiftLint/issues/issue_number)

note: There are two invisible spaces after the entry's text.

Generated by 🚫 Danger

This allows to reduce existential types later.
@jpsim
Copy link
Collaborator

jpsim commented Oct 10, 2023

This allows to reduce existential types later.

How? On its own, I preferred keeping private implementation details of these rules private and inaccessible to the rest of the module.

@SimplyDanny
Copy link
Collaborator Author

SimplyDanny commented Oct 10, 2023

This allows to reduce existential types later.

How? On its own, I preferred keeping private implementation details of these rules private and inaccessible to the rest of the module.

The method that creates the rewriter for a rule

func makeRewriter(file: SwiftLintFile) -> (any ViolationsSyntaxRewriter)?

returns an existential. If the rewriters are internal this can become an opaque result type:

func makeRewriter(file: SwiftLintFile) -> (some Rewriter)? {

@SimplyDanny
Copy link
Collaborator Author

Turns out, the compiler confused me. Visibility can remain private for this to work (which makes more sense admittedly). A few things can still be harmonized, though. Let me update the PR keeping the extensions private ...

@SimplyDanny SimplyDanny changed the title Use consistent internal visibility for rule extensions Harmonize rule extensions Oct 10, 2023
@SimplyDanny SimplyDanny merged commit 6438c77 into realm:main Oct 11, 2023
11 checks passed
@SimplyDanny SimplyDanny deleted the extension-visibility branch October 11, 2023 17:39
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.

None yet

3 participants