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

Print only file path when reporting a correction #5596

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

SimplyDanny
Copy link
Collaborator

Omit exact line and column information. Keep the internal logic available for a while in case people complain for good reasons. Then the change can be reverted easily.

Reasons behind this change:

  • What is the position of a correction actually? The position where the rule triggered? The position of the transformed node?
  • If there's more than a single fix, it's highly likely that all positions (except for the first) are wrong no matter what the answer to the first question is.
  • Getting the positions right in a rewriter is hard. And there is always the feeling that something is wrong with them - probably because it is.
  • Even if you get the positions right in a single rule: One run collects positions for all rules that apply to a file and so rewrites in other rules might draw existing positions wrong.
  • We already have checks for more than one correction position disabled in tests due to these issues.

Omit exact line and column information. Keep the internal logic
available for a while in case people complain for good reasons. Then
the change can be reverted easily.

Reasons behind this change:

* What is the position of a correction actually? The position where the rule triggered? The position of the transformed node?
* If there's more than a single fix, it's highly likely that all positions (except for the first) are wrong no matter what the answer to the first question is.
* Getting the positions right in a rewriter is hard. And there is always the feeling that something is wrong with them - probably because it is.
* Even if you get the positions right in a single rule: One run collects positions for all rules that apply to a file and so rewrites in other rules might draw existing positions wrong.
* We already have checks for more than one correction position disabled in tests due to these issues.
@SwiftLintBot
Copy link

17 Messages
📖 Linting Aerial with this PR took 1.13s vs 1.12s on main (0% slower)
📖 Linting Alamofire with this PR took 1.64s vs 1.65s on main (0% faster)
📖 Linting Brave with this PR took 9.41s vs 9.51s on main (1% faster)
📖 Linting DuckDuckGo with this PR took 5.03s vs 5.03s on main (0% slower)
📖 Linting Firefox with this PR took 12.54s vs 12.64s on main (0% faster)
📖 Linting Kickstarter with this PR took 11.53s vs 11.56s on main (0% faster)
📖 Linting Moya with this PR took 0.64s vs 0.65s on main (1% faster)
📖 Linting NetNewsWire with this PR took 3.34s vs 3.37s on main (0% faster)
📖 Linting Nimble with this PR took 0.94s vs 0.93s on main (1% slower)
📖 Linting PocketCasts with this PR took 9.29s vs 9.29s on main (0% slower)
📖 Linting Quick with this PR took 0.5s vs 0.5s on main (0% slower)
📖 Linting Realm with this PR took 5.75s vs 5.77s on main (0% faster)
📖 Linting Sourcery with this PR took 2.9s vs 2.91s on main (0% faster)
📖 Linting Swift with this PR took 5.72s vs 5.72s on main (0% slower)
📖 Linting VLC with this PR took 1.55s vs 1.53s on main (1% slower)
📖 Linting Wire with this PR took 21.37s vs 21.5s on main (0% faster)
📖 Linting WordPress with this PR took 14.26s vs 14.39s on main (0% faster)

Generated by 🚫 Danger

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

2 participants