[clang-tidy] add new option `--(dump/create)-default-config`

[vbvictor]

After completion of #146482, there would be no default checks enable, which can potentially confuse users.
We should provide an easy way to start using clang-tidy for new users.

I propose a new option --dump-default-config or --create-default-config. This option will create a .clang-tidy config with some checks enabled by default. The default config will be a good start for users to "just run analysis" and later explore more checks.
The list of default checks is largely debatable, possible a mixture of bugprone, modernize, misc and performace that has a low number of false positives.

Alternative solution suggested by @nicovank:

If no checks are enabled, the default config should just be used directly. Maybe adding warnings saying 1. the default config/checks will be used and 2. use --dump-default-config to get started with a custom configuration file in that directory. It's better user experience to just run with the default config immediately rather than add one setup step.

[llvmbot]

@llvm/issue-subscribers-clang-tidy

Author: Baranov Victor (vbvictor)

After completion of https://github.com//issues/146482, there would be no default checks enable, which can potentially confuse users. We should provide an easy way to start using clang-tidy for new users.

I propose a new option --dump-default-config or --create-default-config. This option will create a .clang-tidy config with some checks enabled by default. The default config will be a good start for users to "just run analysis" and later explore more checks.
The list of default checks is largely debatable, possible a mixture of bugprone, modernize, misc and performace that has a low number of false positives.

Alternative solution suggested by @nicovank:

If no checks are enabled, the default config should just be used directly. Maybe adding warnings saying 1. the default config/checks will be used and 2. use --dump-default-config to get started with a custom configuration file in that directory. It's better user experience to just run with the default config immediately rather than add one setup step.

[vbvictor]

Created this issue from #146482 (comment)
cc @carlosgalvezp

[NagyDonat]

This is a really good idea 😄

I agree with the suggestion that the default config should be used directly if there are no explicitly specified checks -- if users want to try this tool quickly, don't force them to "jump through hoops" to get the default config.

In fact, I think the most user-friendly solution would be if the default checks (a set of high-quality low-noise checks that are useful for most users) would be always enabled unless the user explicitly disables them with --no-default-checks (or by individual flags that only disable some of them). This would provide a smoother UX for adding or removing checks incrementally.