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>
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.
Use different issues to make inlineable configurations work in both
scenarios, namely being used standalone and nested as part of another
configuration. In the latter case, finding no values to parse in a raw
configuration is okay, while as a standalone configuration it's not.
This allows to infer names of options from their names in a configuration. CamelCase is translated into snake_case automatically when `apply` is triggered.
* Don't have all `RuleConfiguration`s conform to `InlinableOptionType`. Mark types that must have this capability explicitly. Same for `AcceptableByConfigurationElement`.
* A type being an `InlinableOptionType` doesn't mean it's automatically inlined. This also doesn't depend on the fact of having a name for its key configured any longer. Instead, an `inline` attribute must explicitly be set to `true` in `@ConfigurationElement`.
* Key name inference is optional and can be overwritten by specifying a key name in the attribute.
* Inlined configurations only fail in `apply` when they are really sure that something is odd. Otherwise, they accept to not being updated.
Danny Mösch
Martin Redington
wanxiangchwng
Koichiro Ueki
Chandler Wall
waitbutY
deterclosed
Oleg Kohtenko
Marcelo Fabri