2690 and #2689 both report problems which could have been found if formatted code is checked for compilability. Although the ktlint development version is continuosly run on the ktlint project itself, it will only find compile issues on language constructs which are actively used in the ktlint project itself.
The release testing procedure uses a number of reference project to check for regression bugs. Currently it is not checked whether those projects still can be compiled successfully after ktlint format has changed files.
It could be an idea that in the development version of ktlint the formatted code is parsed again with the build in compiler. If this slows ktlint development too much, it can be added as special CLI option which can be activaed during the release testing procedure. This still does not 100% assure that uncompilable code will always be detected. It could be that the invalid construct is also not present in the reference projects.
2690 and #2689 both report problems which could have been found if formatted code is checked for compilability. Although the ktlint development version is continuosly run on the ktlint project itself, it will only find compile issues on language constructs which are actively used in the ktlint project itself.
The release testing procedure uses a number of reference project to check for regression bugs. Currently it is not checked whether those projects still can be compiled successfully after ktlint format has changed files.
It could be an idea that in the development version of ktlint the formatted code is parsed again with the build in compiler. If this slows ktlint development too much, it can be added as special CLI option which can be activaed during the release testing procedure. This still does not 100% assure that uncompilable code will always be detected. It could be that the invalid construct is also not present in the reference projects.