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.
The README states that a configuration like `attributes: error` is
valid to only set a different severity level for a rule (the
`attributes` rule here). This was previously only possible for rules
that were accompanied by a plain severity configuration.
I don't think this broke with the automatic parsing code generation.
For some rules it might have worked before, for others not. This change
makes it consistently working for all rules.
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
Vladimir Burdukov