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.
* Adds `baseline` and `write_baseline` config file options, so baseline can be used by people who can't pass command line arguments (e.g. plugin users).
* Added PR number
* Fixed change log entry
* Update Source/swiftlint/Helpers/LintOrAnalyzeCommand.swift
Co-authored-by: Danny Mösch <danny.moesch@icloud.com>
* updated
---------
Co-authored-by: Danny Mösch <danny.moesch@icloud.com>
We can also switch back to an exact SwiftSyntax version now with the
plugins in a separate repository. In fact, using the plugin, no direct
dependency to SwiftSyntax is required whatsoever.
Failing immediately when a property is invalid is too strict. It feels
sufficient to allow to report an issue but otherwise continue with a default
value instead of stopping execution completely.
While this is already implemented, it only works when a configuration
is updated by calling `apply(configuration:)` on it somewhere. This
imperceptible detail could lead to confusing. So better prohibit the
use of the feature for the time being as long as a good solution is
found. So far, no explicit configuration keys have been removed.