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.
These aren't enough to enable `-strict-concurrency=complete` for more
modules, but they address some warnings with that flag on and reduces
the scope of what remains to be migrated.
Danny Mösch
Martin Redington
Chandler Wall
waitbutY
deterclosed
Oleg Kohtenko
Marcelo Fabri
JP Simard
Kabir Oberai