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

Let API Consumer decide whether a LintError has to be autocorrected, or not #2671

Merged
merged 33 commits into from
May 28, 2024

Conversation

paul-dingemans
Copy link
Collaborator

Description

When formatting code, the API Consumer should be able to decide whether a LintError has to be autocorrected, or not. In most cases the API Consumer wants to autocorrect all errors that have an autocorrect fix when formatting the code.

The ktlint-intellij-plugin has two use cases in which not all LintError having an autocorrect should be fixed when invoking the format functionality.

  • In manual mode the plugin shows all LintErrors. Users want to be able to choose to autocorrect a specific LintError, while at the same time ignoring other LintErrors.
  • When selecting a block of code in a file, the user want to be able to format only the LintErrors in the selected text.

To avoid breaking changes in Ktlint 1.x, a new RuleAutocorrectApproveHandler interface is added. This interfaces defines the new signatures for functions beforeVisitChildNodes and afterVisitChildNodes. Rules that implement this interface will request the API Consumer to approve to autocorrect a LintError before continuing with formatting the code.

Closes #2658

Checklist

Before submitting the PR, please check following (checks which are not relevant may be ignored):

  • Commit message are well written. In addition to a short title, the commit message also explain why a change is made.
  • At least one commit message contains a reference Closes #<xxx> or Fixes #<xxx> (replace<xxx> with issue number)
  • Tests are added
  • KtLint format has been applied on source code itself and violations are fixed
  • PR title is short and clear (it is used as description in the release changelog)
  • PR description added (background information)

Documentation is updated. See difference between snapshot and release documentation

  • Snapshot documentation in case documentation is to be released together with a code change
  • Release documentation in case documentation is related to a released version of ktlint and has to be published as soon as the change is merged to master

If a rule implements this interface, and changes the methods beforeVisitChildNodes and/or afterVisitChildNodes in compliance with this interface then the rule is able to support fixing of individual violations by requesting approval to autocorrect each violation found. For this the handler needs to be implemented by the API Consumer that is calling the format function of the KtLintRuleEngine.

For now this is implemented in a separate interface to prevent breaking changes in the Rule 1.x API.
…that all lint errors which are found in the autocorrect offset range will be fixed
…ocorrectHandler / rename AutocorrectHandlers
…ault autocorrect value for rules that do not implement the RuleAutocorrectApproveHandler
Linting is same as Format with autocorrect disabled always
@paul-dingemans paul-dingemans added this to the 1.3.0 milestone May 28, 2024
@paul-dingemans paul-dingemans merged commit 32fd86f into master May 28, 2024
22 checks passed
@paul-dingemans paul-dingemans deleted the 2658-fix-single-violation branch May 28, 2024 13:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for formatting a specific violation in a piece of code containing multiple violations
1 participant