[clang-tidy] New check cppcoreguidelines-prefer-member-initializer

[baloghadamsoftware]

Summary

Finds member initializations in the constructor body which can be placed into the initialization list instead. This does not only improves the readability of the code but also affects positively its performance. Class-member assignments inside a control statement or following the first control statement are ignored.

[sylvestre.ledru]

affects positively its performance.

Interesting! Do you have some numbers you could share? thanks

[whisperity]

Can you refresh my memory on whether a rule for "if init expr is constant, initialise in class body instead" exists for init list members? If so, this will be a funny "two pass needed to fix" kind of check.

clang-tools-extra/clang-tidy/readability/PreferInitializationListCheck.cpp

19 ↗

(On Diff #232816)

I'm working on a checker which has the need for similarly knowing occurrences of "control flow breaking statements". How about goto and calling a [[noreturn]] function, such as (std::)longjmp? Or there is no point in matching such in your checker?

71 ↗

(On Diff #232816)

FIXME remained. Did you upload the right patch set?

85 ↗

(On Diff #232816)

can -> should?

clang-tools-extra/clang-tidy/readability/PreferInitializationListCheck.h

18 ↗

(On Diff #232816)

FIXME remained here.

clang-tools-extra/docs/clang-tidy/checks/readability-prefer-initialization-list.rst

7 ↗

(On Diff #232816)

improves -> improve

8 ↗

(On Diff #232816)

word order: also positively affects

27 ↗

(On Diff #232816)

typo: construcotr

27–28 ↗

(On Diff #232816)

[l]ist, unlike m, as m's initialization follow a control statement (if)

[whisperity]

clang-tools-extra/test/clang-tidy/checkers/readability-prefer-initialization-list.cpp

221 ↗

(On Diff #232816)

Comment diverged from what's actually written in the code.

[Eugene.Zelenko]

Clang-tidy also has modernize-use-default-member-init. Will be good idea to mention this check in documentation and otherwise as well as draw distinction (C++ version, coding guidelines, etc) in use cases.

clang-tools-extra/clang-tidy/readability/PreferInitializationListCheck.cpp

66 ↗

(On Diff #232816)

Will be good idea to check for C++.

clang-tools-extra/docs/ReleaseNotes.rst

112

Please synchronize with first statement in documentation.

[baloghadamsoftware]

Updated according to some comments.

[aaron.ballman]

In D71199#1775083, @whisperity wrote:

Can you refresh my memory on whether a rule for "if init expr is constant, initialise in class body instead" exists for init list members? If so, this will be a funny "two pass needed to fix" kind of check.

This worries me as well -- we already have checks that prefer doing an in-class initialization to using a constructor member initialization list. How should this check interact with modernize-use-default-member-init?

clang-tools-extra/clang-tidy/readability/ReadabilityTidyModule.cpp

91 ↗

(On Diff #233087)

I have a concern with the name using initialization-list -- that sounds a lot like the check is going to prefer {42} to = 42. Perhaps the name should be prefer-ctor-member-initialization or something along those lines?

[baloghadamsoftware]

In D71199#1777887, @aaron.ballman wrote:

In D71199#1775083, @whisperity wrote:

Can you refresh my memory on whether a rule for "if init expr is constant, initialise in class body instead" exists for init list members? If so, this will be a funny "two pass needed to fix" kind of check.

This worries me as well -- we already have checks that prefer doing an in-class initialization to using a constructor member initialization list. How should this check interact with modernize-use-default-member-init?

This check is to enforce C++ core guideline C.49 while the modernize check enforces guideline C.48. The two must be synchronized, and I think that this new check should do that: for initializations that should be done using in-class initializers according to the other checker this checker must suggest the same. For the rest we should suggest member initializers in the constructor.

[Eugene.Zelenko]

This check is to enforce C++ core guideline C.49 while the modernize check enforces guideline C.48. The two must be synchronized, and I think that this new check should do that: for initializations that should be done using in-class initializers according to the other checker this checker must suggest the same. For the rest we should suggest member initializers in the constructor.

It should be in cppcoreguidelines module.

[baloghadamsoftware]

Now checker proposes default member initialization if applicable. Thus it is in sync with checker modernize-use-default-member-init. Also moved to ícppcoreguidelinesí group.

[Eugene.Zelenko]

clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.cpp

53

Please elide braces.

clang-tools-extra/docs/ReleaseNotes.rst

70

Is it relevant?

73

Is it relevant?

clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-prefer-member-initializer.rst

16

Enum should be in double back-ticks as language construct.

[baloghadamsoftware]

Updated according to the comments.

[baloghadamsoftware]

Thank you for the comments.

clang-tools-extra/docs/ReleaseNotes.rst

70

Absouletely not, it is nonsense. Just added by the renaming script without me knowing about it.

73

The same as above.

[Eugene.Zelenko]

By the word, please rebase, because Release Notes were reset after version 10 branching.

[baloghadamsoftware]

Rebased.

[Eugene.Zelenko]

clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-prefer-member-initializer.rst

73

Please make indentation 2 characters, same as in above code snippets.

[baloghadamsoftware]

Indentation of the code fixed in the documentation.

[aaron.ballman]

clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp

48

Please keep this list sorted alphabetically.

clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.cpp

44

What about other kinds of literals like user-defined literals, or literal class types? Should this be using E->getType()->isLiteralType()?

[baloghadamsoftware]

Minor update.

[baloghadamsoftware]

clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.cpp

44

E->getType()->isLiteralType() does not work since it tells about the type, not the expression itself. Here we should return true for literals only, not for any expressions whose type is a literal type. Thus int is a literal type, 5 is an int literal, but n or return_any_int() not.

[aaron.ballman]

clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.cpp

26

How about throw expressions?

62–66

if (const auto *DRE = dyn_cast<DeclRefExpr>(Value))
  return isa<EnumConstantDecl>(DRE->getDecl())
return false;

127–129

This can be hoisted into the matcher with hasBody(anything()) I believe. One interesting test case that's somewhat related are constructors that use a function-try-block instead of a compound statement. e.g.,

class C {
  int i;

public:
  C() try {
    i = 12;
  } catch (...) {
  }
};

clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-prefer-member-initializer.rst

7

placed to the -> converted into

8

does not -> not

[baloghadamsoftware]

Updated according to the comments.

[baloghadamsoftware]

clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.cpp

127–129

I think we should skip these cases similarly to initialization inside a try block in a body that is compound statement. Maybe the initialization throws thus it is inappropriate to convert it to member initializer. I also added a test case for this.

[baloghadamsoftware]

Fix from CPlusPlus2a to CPlusPlus20 after rebase.

[baloghadamsoftware]

Code reformatted.

[aaron.ballman]

clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.cpp

107–108

This should now be done by overriding bool isLanguageVersionSupported(const LangOptions &LangOpts) const override;, see bugprone/ThrowKeywordMissingCheck.h for an example.

clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-prefer-member-initializer.rst

4

You should probably link to the rule from somewhere in these docs.

clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-prefer-member-initializer-assignment.cpp

29 ↗

(On Diff #266277)

By my reading of the core guideline (https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c48-prefer-in-class-initializers-to-member-initializers-in-constructors-for-constant-initializers), it looks like n should also be diagnosed because all of the constructors in the class initialize the member to the same constant value. Is there a reason to deviate from the rule (or have I missed something)?

Also, I'd like to see a test case like:

class C {
  int n;
public:
  C() { n = 0; }
  explicit C(int) { n = 12; }
};

[baloghadamsoftware]

Updated according to the comments.

[baloghadamsoftware]

clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-prefer-member-initializer-assignment.cpp

29 ↗

(On Diff #266277)

This check only cares for initializations inside the body (rule C.49, but if the proper fix is to convert them to default member initializer according to rule C.48 then we follow that rule in the fix). For initializations implemented as constructor member initializers but according to C.48 they should have been implemented as default member initializers we already have check modernize-use-default-member-init.

[aaron.ballman]

clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-prefer-member-initializer-assignment.cpp

29 ↗

(On Diff #266277)

Thank you for the explanation. I have the feeling that these two rules are going to have some really weird interactions together. For instance, the example you added at my request shows behavior I can't easily explain as a user:

class Complex19 {
  int n;
  // CHECK-FIXES: int n{0};
public:
  Complex19() {
    n = 0;
    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n' should be initialized in an in-class default member initializer [cppcoreguidelines-prefer-member-initializer]
    // CHECK-FIXES: {{^\ *$}}
  }

  explicit Complex19(int) {
    // CHECK-FIXES: Complex19(int) : n(12) {
    n = 12;
    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
    // CHECK-FIXES: {{^\ *$}}
  }

  ~Complex19() = default;
};

Despite both constructors having the assignment expression n = <literal>; one gets one diagnostic + fixit and the other gets a different diagnostic + fixit.

Also, from reading C.49, I don't see anything about using in-class initialization. I see C.49 as being about avoiding the situation where the ctor runs a constructor for a data member only to then immediately in the ctor body make an assignment to that member. You don't need to initialize then reinitialize when you can use a member init list to construct the object properly initially.

[baloghadamsoftware]

clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-prefer-member-initializer-assignment.cpp

29 ↗

(On Diff #266277)

Thank you for your comment. While I can agree with you, I think that this check should be fully consistent with modernize-use-default-member-init. Thus I tried it on the following example:

class C {
  int n;
public:
  C() : n(1) {}
  C(int nn) : n(nn) {}

  int get_n() { return n; }
};

I got the following message from Clang-Tidy:

warning: use default member initializer for 'n' [modernize-use-default-member-init]
  int n;
      ^
       {1}

This is no surprise, however. If you take a look on the example in C.48: Prefer in-class initializers to member initializers in constructors for constant initializers you can see that our code is almost the same as the example considered bad there. So rule C.49 does not speak anything about in-class initialization, but C.48 does, our check enforcing C.49 must not suggest a fixit the the check enforcing C.48 fixes again. We should not force the user to run Clang-Tidy in multiple passes. Maybe we can mention the numbers of the rules in the error messages to make them clearer.

[aaron.ballman]

clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-prefer-member-initializer-assignment.cpp

29 ↗

(On Diff #266277)

This is no surprise, however.

Agreed, but it's also a different example from the one I posted where the behavior is mysterious.

We should not force the user to run Clang-Tidy in multiple passes.

Agreed, but the checks are also independent of one another (e.g., I can run one but not the other) and that use case needs to be considered as well as the combined use case.

I personally don't use the C++ Core Guidelines and so I'm not as well-versed in their nuances -- I'm happy to let someone more familiar with the standard sway my opinion, but this smells a bit like the two rules are less orthogonal than the rule authors may believe. Both rules say to prefer something regarding member initialization, but neither rule says what the priority ordering is for those preferences when either approach works. Is it implicitly assumed that lower-numbered rules take precedence and so we should prefer in-class initialization over member initialization over assignment (that would seem defensible, but isn't stated anywhere in the rules)?

[njames93]

Just my 2 cents, but would it not be wise to introduce a test case that runs the 2 aforementioned checks together demonstrating how they interact with each other. This will also force compliance if either check is updated down the line.

[baloghadamsoftware]

In D71199#2125602, @njames93 wrote:

Just my 2 cents, but would it not be wise to introduce a test case that runs the 2 aforementioned checks together demonstrating how they interact with each other. This will also force compliance if either check is updated down the line.

I can do that, and I will do it. However, all checks work on the original files, thus no interaction is expected.

clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-prefer-member-initializer-assignment.cpp

29 ↗

(On Diff #266277)

Agreed, but it's also a different example from the one I posted where the behavior is mysterious.

The example in C.48 is the result of the fixit of this check for C.49 if I do not take C.48 in account. Thus without considering C.48 the check would suggest fixits which is bad according to C.48. This means that if the user accepts these fixits and runs Clang-Tidy again then the other check marks these fixits as bad and suggests another fixit for them.

The big question is that which one is the majority? Users who wish to conform to all the core guidelines or users who accept C.49 but not C.48. My wild guess is the first one. So in my opinion the biggest problem is that if we suggest a fixit by one check considered as bad by another one than the problem that we suggest different fixits for initializations in the default constructors than in other constructors.

Of course, the ideal solution would be to define the execution order of the checks and every check should work on a code fixed by the previous check. I do not think this would ever happen. It could also help if I could examine in this check whether the other one is enabled. However, I do not think this is possible either.

[aaron.ballman]

clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-prefer-member-initializer-assignment.cpp

29 ↗

(On Diff #266277)

The example in C.48 is the result of the fixit of this check for C.49 if I do not take C.48 in account. Thus without considering C.48 the check would suggest fixits which is bad according to C.48. This means that if the user accepts these fixits and runs Clang-Tidy again then the other check marks these fixits as bad and suggests another fixit for them.

Yup, and that's the situation I'm worried about.

The big question is that which one is the majority? Users who wish to conform to all the core guidelines or users who accept C.49 but not C.48. My wild guess is the first one. So in my opinion the biggest problem is that if we suggest a fixit by one check considered as bad by another one than the problem that we suggest different fixits for initializations in the default constructors than in other constructors.

My experience has been that users frequently disable individual warning flags and checks, but as a reaction to a poor-quality diagnostic in the project, and so they usually leave the entire group of checks enabled at first. So I'd say both are likely situations.

It could also help if I could examine in this check whether the other one is enabled. However, I do not think this is possible either.

This is possible, but it's something we should really stop and think about before we decide to open the floodgates because I can imagine the testing matrix for these sort of interactions getting out of control. e.g., when this check is enabled, but not if it's spelled using that alias, then this other check behaves differently, but it may depend on options set for the first check, etc. But you can use ClangTidyContext::isCheckEnabled() to test this.

[baloghadamsoftware]

Since no better idea cam to my mind, in this version I check whether modernize-use-default-member-init is enabled. If it is, then we issue a warning and suggest a fix that uses default member initializer. We also take into account the option for that checker whether we should use brackets or assignment. This checker has no options now. If the other checker is not enabled, we always warn and suggest fix to use constructor member initializer.

[aaron.ballman]

In D71199#2215719, @baloghadamsoftware wrote:

Since no better idea cam to my mind, in this version I check whether modernize-use-default-member-init is enabled. If it is, then we issue a warning and suggest a fix that uses default member initializer. We also take into account the option for that checker whether we should use brackets or assignment. This checker has no options now. If the other checker is not enabled, we always warn and suggest fix to use constructor member initializer.

While I don't feel awesome about this approach, I don't have a better idea either. Unless @alexfh, @gribozavr2, or one of the other reviewers has concerns, this LGTM. Thank you for your patience while we thought our way through this!

[njames93]

clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.cpp

104

OptionsView::get(...) is specialized for bools, so you can just pass false as the second argument and negate the need to compare against zero

[baloghadamsoftware]

Updated according to a comment.

[lebedev.ri]

So i've just reverted this in rGebf496d805521b53022a351f35854de977fee844.

@aaron.ballman @baloghadamsoftware how's QC going on nowadays here?
Was this evaluated on anything other than it's tests?

It appears to be either unacceptably slow, or subtly broken, because it takes at least 100x time more than all of the other clang-tidy checks enabled, and e.g.
clang-tidy-12 --checks="-*,cppcoreguidelines-prefer-member-initializer" -p . /repositories/llvm-project/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
never finishes (minutes and counting).

[baloghadamsoftware]

In D71199#2265594, @lebedev.ri wrote:

So i've just reverted this in rGebf496d805521b53022a351f35854de977fee844.

@aaron.ballman @baloghadamsoftware how's QC going on nowadays here?
Was this evaluated on anything other than it's tests?

Surely. After I commit a patch, lots of buildbots verify it. They passed so far.

It appears to be either unacceptably slow, or subtly broken, because it takes at least 100x time more than all of the other clang-tidy checks enabled, and e.g.
clang-tidy-12 --checks="-*,cppcoreguidelines-prefer-member-initializer" -p . /repositories/llvm-project/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
never finishes (minutes and counting).

I see nothing there that could be slow, thus this is probably some hang. I will investigate it.

[lebedev.ri]

In D71199#2265692, @baloghadamsoftware wrote:

In D71199#2265594, @lebedev.ri wrote:

So i've just reverted this in rGebf496d805521b53022a351f35854de977fee844.

@aaron.ballman @baloghadamsoftware how's QC going on nowadays here?
Was this evaluated on anything other than it's tests?

Surely. After I commit a patch, lots of buildbots verify it. They passed so far.

@baloghadamsoftware, i think you understand that wasn't the question.

It appears to be either unacceptably slow, or subtly broken, because it takes at least 100x time more than all of the other clang-tidy checks enabled, and e.g.
clang-tidy-12 --checks="-*,cppcoreguidelines-prefer-member-initializer" -p . /repositories/llvm-project/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
never finishes (minutes and counting).

I see nothing there that could be slow, thus this is probably some hang. I will investigate it.

[aaron.ballman]

In D71199#2265693, @lebedev.ri wrote:

In D71199#2265692, @baloghadamsoftware wrote:

In D71199#2265594, @lebedev.ri wrote:

So i've just reverted this in rGebf496d805521b53022a351f35854de977fee844.

@aaron.ballman @baloghadamsoftware how's QC going on nowadays here?
Was this evaluated on anything other than it's tests?

Surely. After I commit a patch, lots of buildbots verify it. They passed so far.

@baloghadamsoftware, i think you understand that wasn't the question.

This feedback is a bit terse and not very constructive. FWIW, we don't typically ask patch authors to run their patch over a large corpus of code unless a reviewer expects there to be a performance concern and asks explicitly. Given that this checks constructor bodies, there was no obvious reason to ask for that here. Also, I can't recall a time when we expected a patch reviewer to do that work. I appreciate that you noticed an issue and reverted so we could investigate, but when reporting an issue like this, please try to keep in mind that we're all in the same community trying to make a great product.

[baloghadamsoftware]

I found the problem: hasBody() always returns true if the function has somewhere a body. This means that also the hasBody matcher matches forward declarations. However, I only need the definition. This far I could not find any method to achieve that: isDefinition() also returns true for forward declarations, as well as comparing with the CanonicalDecl. I am looking further...

[baloghadamsoftware]

OK, I reversed the matcher expression now, it seems to work, but I will check it on the LLVM/Clang codebase first.

[baloghadamsoftware]

It looks like it was not entirely my fault: D87527.

[lebedev.ri]

Thank you for looking into it.

[whisperity]

Minor inline comments.

Could you please add a test case where the constructor is defined out of line? So far in every test, the constructor body was inside the class. Something like:

struct S {
  int i, j;
  S();
};

S::S() {
  i = 1;
  j = 2;
}

I'm also particularly interested in the case when the constructor is implemented in its "own" translation unit. Where will the initialiser be moved in that case? Into the header, where the record is defined, still?

clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.cpp

22–24

It was you who figured out in D85728 that isa has changed recently and is now variadic. Then this function can be simplified with the variadic version.

40–42

Ditto.

127

clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-prefer-member-initializer.rst

7

[whisperity]

clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.cpp

44

@baloghadamsoftware The original comment by Aaron is left unmarked as "done" here.

[baloghadamsoftware]

No crash, no hang, no false positives on the LLVM Project.

[baloghadamsoftware]

Updated according to the comments.

[baloghadamsoftware]

Prerequeisite patch is committed, the check is tested now on the LLVM Project. @lebedev.ri, @aaron.ballman can I recommit it?

[lebedev.ri]

In D71199#2285076, @baloghadamsoftware wrote:

Prerequeisite patch is committed, the check is tested now on the LLVM Project. @lebedev.ri, @aaron.ballman can I recommit it?

Thank you! SGTM.

[Rechi]

clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.cpp

184

The following example generates invalid fixes, if modernize-use-default-member-init check isn't enabled, because Ctor->getNumCtorInitializers() returns 1.

class Example
{
public:
  Example() { a = 0; };
  int a;
  std::string string;
};

[njames93]

clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.cpp

184

I've done a little work trying to fix some issues I've noticed while running this check in the wild. I have a feeling this shortcoming has been addressed in there - D97132.

clang-tools-extra/clang-tidy/cppcoreguidelines/CMakeLists.txt

 set(LLVM_LINK_COMPONENTS
   FrontendOpenMP
   Support
   )
 
 add_clang_library(clangTidyCppCoreGuidelinesModule
   AvoidGotoCheck.cpp
   AvoidNonConstGlobalVariablesCheck.cpp
   CppCoreGuidelinesTidyModule.cpp
   InitVariablesCheck.cpp
   InterfacesGlobalInitCheck.cpp
   MacroUsageCheck.cpp
   NarrowingConversionsCheck.cpp
   NoMallocCheck.cpp
   OwningMemoryCheck.cpp
+  PreferMemberInitializerCheck.cpp
   ProBoundsArrayToPointerDecayCheck.cpp
   ProBoundsConstantArrayIndexCheck.cpp
   ProBoundsPointerArithmeticCheck.cpp
   ProTypeConstCastCheck.cpp
   ProTypeCstyleCastCheck.cpp
   ProTypeMemberInitCheck.cpp
   ProTypeReinterpretCastCheck.cpp
   ProTypeStaticCastDowncastCheck.cpp

clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp

 #include "AvoidGotoCheck.h"
 #include "AvoidNonConstGlobalVariablesCheck.h"
 #include "InitVariablesCheck.h"
 #include "InterfacesGlobalInitCheck.h"
 #include "MacroUsageCheck.h"
 #include "NarrowingConversionsCheck.h"
 #include "NoMallocCheck.h"
 #include "OwningMemoryCheck.h"
+#include "PreferMemberInitializerCheck.h"
 #include "ProBoundsArrayToPointerDecayCheck.h"
 #include "ProBoundsConstantArrayIndexCheck.h"
 #include "ProBoundsPointerArithmeticCheck.h"
 #include "ProTypeConstCastCheck.h"
 #include "ProTypeCstyleCastCheck.h"
 #include "ProTypeMemberInitCheck.h"
 #include "ProTypeReinterpretCastCheck.h"
 #include "ProTypeStaticCastDowncastCheck.h"
 #include "ProTypeUnionAccessCheck.h"
 #include "ProTypeVarargCheck.h"
 #include "SlicingCheck.h"
 #include "SpecialMemberFunctionsCheck.h"
 
 namespace clang {
 namespace tidy {
 namespace cppcoreguidelines {
 
 /// A module containing checks of the C++ Core Guidelines
 class CppCoreGuidelinesModule : public ClangTidyModule {
 public:
   void addCheckFactories(ClangTidyCheckFactories &CheckFactories) override {
     CheckFactories.registerCheck<modernize::AvoidCArraysCheck>(
         "cppcoreguidelines-avoid-c-arrays");
     CheckFactories.registerCheck<AvoidGotoCheck>(
         "cppcoreguidelines-avoid-goto");
     CheckFactories.registerCheck<readability::MagicNumbersCheck>(
         "cppcoreguidelines-avoid-magic-numbers");
     CheckFactories.registerCheck<AvoidNonConstGlobalVariablesCheck>(
         "cppcoreguidelines-avoid-non-const-global-variables");
     CheckFactories.registerCheck<modernize::UseOverrideCheck>(
         "cppcoreguidelines-explicit-virtual-functions");
     CheckFactories.registerCheck<InitVariablesCheck>(
         "cppcoreguidelines-init-variables");
     CheckFactories.registerCheck<InterfacesGlobalInitCheck>(
         "cppcoreguidelines-interfaces-global-init");
     CheckFactories.registerCheck<MacroUsageCheck>(
         "cppcoreguidelines-macro-usage");
     CheckFactories.registerCheck<NarrowingConversionsCheck>(
         "cppcoreguidelines-narrowing-conversions");
     CheckFactories.registerCheck<NoMallocCheck>("cppcoreguidelines-no-malloc");
     CheckFactories.registerCheck<misc::NonPrivateMemberVariablesInClassesCheck>(
         "cppcoreguidelines-non-private-member-variables-in-classes");
     CheckFactories.registerCheck<OwningMemoryCheck>(
         "cppcoreguidelines-owning-memory");
+    CheckFactories.registerCheck<PreferMemberInitializerCheck>(
+        "cppcoreguidelines-prefer-member-initializer");
     CheckFactories.registerCheck<ProBoundsArrayToPointerDecayCheck>(
         "cppcoreguidelines-pro-bounds-array-to-pointer-decay");
     CheckFactories.registerCheck<ProBoundsConstantArrayIndexCheck>(
         "cppcoreguidelines-pro-bounds-constant-array-index");
     CheckFactories.registerCheck<ProBoundsPointerArithmeticCheck>(
         "cppcoreguidelines-pro-bounds-pointer-arithmetic");
     CheckFactories.registerCheck<ProTypeConstCastCheck>(
         "cppcoreguidelines-pro-type-const-cast");

clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.h

+//===--- PreferMemberInitializerCheck.h - clang-tidy ------------*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CPPCOREGUIDELINES_PREFERMEMBERINITIALIZERCHECK_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CPPCOREGUIDELINES_PREFERMEMBERINITIALIZERCHECK_H
+
+#include "../ClangTidyCheck.h"
+
+namespace clang {
+namespace tidy {
+namespace cppcoreguidelines {
+
+/// Finds member initializations in the constructor body which can be placed
+/// into the initialization list instead.
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-prefer-member-initializer.html
+class PreferMemberInitializerCheck : public ClangTidyCheck {
+public:
+  PreferMemberInitializerCheck(StringRef Name, ClangTidyContext *Context);
+  bool isLanguageVersionSupported(const LangOptions &LangOpts) const override {
+    return LangOpts.CPlusPlus;
+  }
+  void storeOptions(ClangTidyOptions::OptionMap &Opts) override;
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult &Result) override;
+
+  const bool IsUseDefaultMemberInitEnabled;
+  const bool UseAssignment;
+};
+
+} // namespace cppcoreguidelines
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CPPCOREGUIDELINES_PREFERMEMBERINITIALIZERCHECK_H

clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.cpp

+//===--- PreferMemberInitializerCheck.cpp - clang-tidy -------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "PreferMemberInitializerCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Lex/Lexer.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace cppcoreguidelines {
+
+static bool isControlStatement(const Stmt *S) {
+  return isa<IfStmt, SwitchStmt, ForStmt, WhileStmt, DoStmt, ReturnStmt,
+             GotoStmt, CXXTryStmt, CXXThrowExpr>(S);
+}
+
+static bool isNoReturnCallStatement(const Stmt *S) {
+  const auto *Call = dyn_cast<CallExpr>(S);
+  if (!Call)
+    return false;
+
+  const FunctionDecl *Func = Call->getDirectCallee();
+  if (!Func)
+    return false;
+
+  return Func->isNoReturn();
+}
+
+static bool isLiteral(const Expr *E) {
+  return isa<StringLiteral, CharacterLiteral, IntegerLiteral, FloatingLiteral,
+             CXXBoolLiteralExpr, CXXNullPtrLiteralExpr>(E);
+}
+
+static bool isUnaryExprOfLiteral(const Expr *E) {
+  if (const auto *UnOp = dyn_cast<UnaryOperator>(E))
+    return isLiteral(UnOp->getSubExpr());
+  return false;
+}
+
+static bool shouldBeDefaultMemberInitializer(const Expr *Value) {
+  if (isLiteral(Value) || isUnaryExprOfLiteral(Value))
+    return true;
+
+  if (const auto *DRE = dyn_cast<DeclRefExpr>(Value))
+    return isa<EnumConstantDecl>(DRE->getDecl());
+
+  return false;
+}
+
+static const std::pair<const FieldDecl *, const Expr *>
+isAssignmentToMemberOf(const RecordDecl *Rec, const Stmt *S) {
+  if (const auto *BO = dyn_cast<BinaryOperator>(S)) {
+    if (BO->getOpcode() != BO_Assign)
+      return std::make_pair(nullptr, nullptr);
+
+    const auto *ME = dyn_cast<MemberExpr>(BO->getLHS()->IgnoreParenImpCasts());
+    if (!ME)
+      return std::make_pair(nullptr, nullptr);
+
+    const auto *Field = dyn_cast<FieldDecl>(ME->getMemberDecl());
+    if (!Field)
+      return std::make_pair(nullptr, nullptr);
+
+    if (isa<CXXThisExpr>(ME->getBase()))
+      return std::make_pair(Field, BO->getRHS()->IgnoreParenImpCasts());
+  } else if (const auto *COCE = dyn_cast<CXXOperatorCallExpr>(S)) {
+    if (COCE->getOperator() != OO_Equal)
+      return std::make_pair(nullptr, nullptr);
+
+    const auto *ME =
+        dyn_cast<MemberExpr>(COCE->getArg(0)->IgnoreParenImpCasts());
+    if (!ME)
+      return std::make_pair(nullptr, nullptr);
+
+    const auto *Field = dyn_cast<FieldDecl>(ME->getMemberDecl());
+    if (!Field)
+      return std::make_pair(nullptr, nullptr);
+
+    if (isa<CXXThisExpr>(ME->getBase()))
+      return std::make_pair(Field, COCE->getArg(1)->IgnoreParenImpCasts());
+  }
+
+  return std::make_pair(nullptr, nullptr);
+}
+
+PreferMemberInitializerCheck::PreferMemberInitializerCheck(
+    StringRef Name, ClangTidyContext *Context)
+    : ClangTidyCheck(Name, Context),
+      IsUseDefaultMemberInitEnabled(
+          Context->isCheckEnabled("modernize-use-default-member-init")),
+      UseAssignment(OptionsView("modernize-use-default-member-init",
+                                Context->getOptions().CheckOptions)
+                        .get("UseAssignment", false)) {}
+
+void PreferMemberInitializerCheck::storeOptions(
+    ClangTidyOptions::OptionMap &Opts) {
+  Options.store(Opts, "UseAssignment", UseAssignment);
+}
+
+void PreferMemberInitializerCheck::registerMatchers(MatchFinder *Finder) {
+  Finder->addMatcher(
+      cxxConstructorDecl(hasBody(compoundStmt()), unless(isInstantiated()))
+          .bind("ctor"),
+      this);
+}
+
+void PreferMemberInitializerCheck::check(
+    const MatchFinder::MatchResult &Result) {
+  const auto *Ctor = Result.Nodes.getNodeAs<CXXConstructorDecl>("ctor");
+  const auto *Body = cast<CompoundStmt>(Ctor->getBody());
+
+  const CXXRecordDecl *Class = Ctor->getParent();
+  SourceLocation InsertPos;
+  bool FirstToCtorInits = true;
+
+  for (const Stmt *S : Body->body()) {
+    if (S->getBeginLoc().isMacroID()) {
+      StringRef MacroName =
+        Lexer::getImmediateMacroName(S->getBeginLoc(), *Result.SourceManager,
+                                     getLangOpts());
+      if (MacroName.contains_lower("assert"))
+        return;
+    }
+    if (isControlStatement(S))
+      return;
+
+    if (isNoReturnCallStatement(S))
+      return;
+
+    if (const auto *CondOp = dyn_cast<ConditionalOperator>(S)) {
+      if (isNoReturnCallStatement(CondOp->getLHS()) ||
+          isNoReturnCallStatement(CondOp->getRHS()))
+        return;
+    }
+
+    const FieldDecl *Field;
+    const Expr *InitValue;
+    std::tie(Field, InitValue) = isAssignmentToMemberOf(Class, S);
+    if (Field) {
+      if (IsUseDefaultMemberInitEnabled && getLangOpts().CPlusPlus11 &&
+          Ctor->isDefaultConstructor() &&
+          (getLangOpts().CPlusPlus20 || !Field->isBitField()) &&
+          (!isa<RecordDecl>(Class->getDeclContext()) ||
+           !cast<RecordDecl>(Class->getDeclContext())->isUnion()) &&
+          shouldBeDefaultMemberInitializer(InitValue)) {
+        auto Diag =
+            diag(S->getBeginLoc(), "%0 should be initialized in an in-class"
+                                   " default member initializer")
+            << Field;
+
+        SourceLocation FieldEnd =
+            Lexer::getLocForEndOfToken(Field->getSourceRange().getEnd(), 0,
+                                       *Result.SourceManager, getLangOpts());
+        Diag << FixItHint::CreateInsertion(FieldEnd,
+                                           UseAssignment ? " = " : "{")
+             << FixItHint::CreateInsertionFromRange(
+                    FieldEnd,
+                    CharSourceRange(InitValue->getSourceRange(), true))
+             << FixItHint::CreateInsertion(FieldEnd, UseAssignment ? "" : "}");
+
+        SourceLocation SemiColonEnd =
+            Lexer::findNextToken(S->getEndLoc(), *Result.SourceManager,
+                                 getLangOpts())
+                ->getEndLoc();
+        CharSourceRange StmtRange =
+            CharSourceRange::getCharRange(S->getBeginLoc(), SemiColonEnd);
+
+        Diag << FixItHint::CreateRemoval(StmtRange);
+      } else {
+        auto Diag =
+            diag(S->getBeginLoc(), "%0 should be initialized in a member"
+                                   " initializer of the constructor")
+            << Field;
+
+        bool AddComma = false;
+        if (!Ctor->getNumCtorInitializers() && FirstToCtorInits) {
+          SourceLocation BodyPos = Ctor->getBody()->getBeginLoc();
+          SourceLocation NextPos = Ctor->getBeginLoc();
+          do {
+            InsertPos = NextPos;
+            NextPos = Lexer::findNextToken(NextPos, *Result.SourceManager,
+                                           getLangOpts())
+                          ->getLocation();
+          } while (NextPos != BodyPos);
+          InsertPos = Lexer::getLocForEndOfToken(
+              InsertPos, 0, *Result.SourceManager, getLangOpts());
+
+          Diag << FixItHint::CreateInsertion(InsertPos, " : ");
+        } else {
+          bool Found = false;
+          for (const auto *Init : Ctor->inits()) {
+            if (Init->isMemberInitializer()) {
+              if (Result.SourceManager->isBeforeInTranslationUnit(
+                      Field->getLocation(), Init->getMember()->getLocation())) {
+                InsertPos = Init->getSourceLocation();
+                Found = true;
+                break;
+              }
+            }
+          }
+
+          if (!Found) {
+            if (Ctor->getNumCtorInitializers()) {
+              InsertPos = Lexer::getLocForEndOfToken(
+                  (*Ctor->init_rbegin())->getSourceRange().getEnd(), 0,
+                  *Result.SourceManager, getLangOpts());
+            }
+            Diag << FixItHint::CreateInsertion(InsertPos, ", ");
+          } else {
+            AddComma = true;
+          }
+        }
+        Diag << FixItHint::CreateInsertion(InsertPos, Field->getName())
+             << FixItHint::CreateInsertion(InsertPos, "(")
+             << FixItHint::CreateInsertionFromRange(
+                    InsertPos,
+                    CharSourceRange(InitValue->getSourceRange(), true))
+             << FixItHint::CreateInsertion(InsertPos, ")");
+        if (AddComma)
+          Diag << FixItHint::CreateInsertion(InsertPos, ", ");
+
+        SourceLocation SemiColonEnd =
+            Lexer::findNextToken(S->getEndLoc(), *Result.SourceManager,
+                                 getLangOpts())
+                ->getEndLoc();
+        CharSourceRange StmtRange =
+            CharSourceRange::getCharRange(S->getBeginLoc(), SemiColonEnd);
+
+        Diag << FixItHint::CreateRemoval(StmtRange);
+        FirstToCtorInits = false;
+      }
+    }
+  }
+}
+
+} // namespace cppcoreguidelines
+} // namespace tidy
+} // namespace clang

clang-tools-extra/docs/ReleaseNotes.rst

 Improvements to clang-rename
 ----------------------------
 
 The improvements are...
 
 Improvements to clang-tidy
 --------------------------
 
 New modules
 ^^^^^^^^^^^
 
 - New ``altera`` module.
 
   Includes checks related to OpenCL for FPGA coding guidelines, based on the
   `Altera SDK for OpenCL: Best Practices Guide
   <https://www.altera.com/en_US/pdfs/literature/hb/opencl-sdk/aocl_optimization_guide.pdf>`_.
 
 New checks
 ^^^^^^^^^^
 
 - New :doc:`altera-struct-pack-align
   <clang-tidy/checks/altera-struct-pack-align>` check.
 
   Finds structs that are inefficiently packed or aligned, and recommends
   packing and/or aligning of said structs as needed.
 
+- New :doc:`cppcoreguidelines-prefer-member-initializer
+  <clang-tidy/checks/cppcoreguidelines-prefer-member-initializer>` check.
+
+  Finds member initializations in the constructor body which can be placed into
+  the initialization list instead.
+
 - New :doc:`bugprone-misplaced-pointer-arithmetic-in-alloc
   <clang-tidy/checks/bugprone-misplaced-pointer-arithmetic-in-alloc>` check.
 
 - New :doc:`bugprone-redundant-branch-condition
   <clang-tidy/checks/bugprone-redundant-branch-condition>` check.
 
   Finds condition variables in nested ``if`` statements that were also checked
   in the outer ``if`` statement and were not changed.
 
 Changes in existing checks
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 - Improved :doc:`readability-identifier-naming
   <clang-tidy/checks/readability-identifier-naming>` check.
 
   Added an option `GetConfigPerFile` to support including files which use
   different naming styles.
 
 Improvements to include-fixer
 -----------------------------
 
 The improvements are...
 
 Improvements to clang-include-fixer
 -----------------------------------
 
 The improvements are...

clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-prefer-member-initializer.rst

+.. title:: clang-tidy - cppcoreguidelines-prefer-member-initializer
+
+cppcoreguidelines-prefer-member-initializer
+===========================================
+
+Finds member initializations in the constructor body which can be  converted
+into member initializers of the constructor instead. This not only improves
+the readability of the code but also positively affects its performance.
+Class-member assignments inside a control statement or following the first
+control statement are ignored.
+
+This check implements `C.49 <https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c49-prefer-initialization-to-assignment-in-constructors>`_ from the CppCoreGuidelines.
+
+If the language version is `C++ 11` or above, the constructor is the default
+constructor of the class, the field is not a bitfield (only in case of earlier
+language version than `C++ 20`), furthermore the assigned value is a literal,
+negated literal or ``enum`` constant then the preferred place of the
+initialization is at the class member declaration.
+
+This latter rule is `C.48 <https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c48-prefer-in-class-initializers-to-member-initializers-in-constructors-for-constant-initializers>`_ from CppCoreGuidelines.
+
+Please note, that this check does not enforce this latter rule for
+initializations already implemented as member initializers. For that purpose
+see check `modernize-use-default-member-init <modernize-use-default-member-init.html>`_.
+
+Example 1
+---------
+
+.. code-block:: c++
+
+  class C {
+    int n;
+    int m;
+  public:
+    C() {
+      n = 1; // Literal in default constructor
+      if (dice())
+        return;
+      m = 1;
+    }
+  };
+
+Here ``n`` can be initialized using a default member initializer, unlike
+``m``, as ``m``'s initialization follows a control statement (``if``):
+
+.. code-block:: c++
+
+  class C {
+    int n{1};
+    int m;
+  public:
+    C() {
+      if (dice())
+        return;
+      m = 1;
+    }
+
+Example 2
+---------
+
+.. code-block:: c++
+
+  class C {
+    int n;
+    int m;
+  public:
+    C(int nn, int mm) {
+      n = nn; // Neither default constructor nor literal
+      if (dice())
+        return;
+      m = mm;
+    }
+  };
+
+Here ``n`` can be initialized in the constructor initialization list, unlike
+``m``, as ``m``'s initialization follows a control statement (``if``):
+
+.. code-block:: c++
+
+  C(int nn, int mm) : n(nn) {
+    if (dice())
+      return;
+    m = mm;
+  }
+
+.. option:: UseAssignment
+
+   If this option is set to non-zero (default is `0`), the check will initialize
+   members with an assignment. In this case the fix of the first example looks
+   like this:
+
+.. code-block:: c++
+
+  class C {
+    int n = 1;
+    int m;
+  public:
+    C() {
+      if (dice())
+        return;
+      m = 1;
+    }
+  };

clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-prefer-member-initializer-modernize-use-default-member-init-assignment.cpp

+// RUN: %check_clang_tidy %s cppcoreguidelines-prefer-member-initializer,modernize-use-default-member-init %t -- \
+// RUN: -config="{CheckOptions: [{key: modernize-use-default-member-init.UseAssignment, value: 1}]}"
+
+class Simple1 {
+  int n;
+  // CHECK-FIXES: int n = 0;
+  double x;
+  // CHECK-FIXES: double x = 0.0;
+
+public:
+  Simple1() {
+    n = 0;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n' should be initialized in an in-class default member initializer [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+    x = 0.0;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'x' should be initialized in an in-class default member initializer [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+  }
+
+  Simple1(int nn, double xx) {
+    // CHECK-FIXES: Simple1(int nn, double xx) : n(nn), x(xx) {
+    n = nn;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+    x = xx;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'x' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+  }
+
+  ~Simple1() = default;
+};

clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-prefer-member-initializer-modernize-use-default-member-init.cpp

+// RUN: %check_clang_tidy %s cppcoreguidelines-prefer-member-initializer,modernize-use-default-member-init %t
+
+class Simple1 {
+  int n;
+  // CHECK-FIXES: int n{0};
+  double x;
+  // CHECK-FIXES: double x{0.0};
+
+public:
+  Simple1() {
+    n = 0;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n' should be initialized in an in-class default member initializer [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+    x = 0.0;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'x' should be initialized in an in-class default member initializer [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+  }
+
+  Simple1(int nn, double xx) {
+    // CHECK-FIXES: Simple1(int nn, double xx) : n(nn), x(xx) {
+    n = nn;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+    x = xx;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'x' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+  }
+
+  ~Simple1() = default;
+};

clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-prefer-member-initializer.cpp

+// RUN: %check_clang_tidy %s cppcoreguidelines-prefer-member-initializer %t -- -- -fcxx-exceptions
+
+extern void __assert_fail (__const char *__assertion, __const char *__file,
+    unsigned int __line, __const char *__function)
+     __attribute__ ((__noreturn__));
+#define assert(expr) \
+  ((expr)  ? (void)(0)  : __assert_fail (#expr, __FILE__, __LINE__, __func__))
+
+class Simple1 {
+  int n;
+  double x;
+
+public:
+  Simple1() {
+    // CHECK-FIXES: Simple1() : n(0), x(0.0) {
+    n = 0;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+    x = 0.0;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'x' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+  }
+
+  Simple1(int nn, double xx) {
+    // CHECK-FIXES: Simple1(int nn, double xx) : n(nn), x(xx) {
+    n = nn;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+    x = xx;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'x' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+  }
+
+  ~Simple1() = default;
+};
+
+class Simple2 {
+  int n;
+  double x;
+
+public:
+  Simple2() : n(0) {
+    // CHECK-FIXES: Simple2() : n(0), x(0.0) {
+    x = 0.0;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'x' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+  }
+
+  Simple2(int nn, double xx) : n(nn) {
+    // CHECK-FIXES: Simple2(int nn, double xx) : n(nn), x(xx) {
+    x = xx;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'x' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+  }
+
+  ~Simple2() = default;
+};
+
+class Simple3 {
+  int n;
+  double x;
+
+public:
+  Simple3() : x(0.0) {
+    // CHECK-FIXES: Simple3() : n(0), x(0.0) {
+    n = 0;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+  }
+
+  Simple3(int nn, double xx) : x(xx) {
+    // CHECK-FIXES: Simple3(int nn, double xx) : n(nn), x(xx) {
+    n = nn;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+  }
+
+  ~Simple3() = default;
+};
+
+int something_int();
+double something_double();
+
+class Simple4 {
+  int n;
+
+public:
+  Simple4() {
+    // CHECK-FIXES: Simple4() : n(something_int()) {
+    n = something_int();
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+  }
+
+  ~Simple4() = default;
+};
+
+static bool dice();
+
+class Complex1 {
+  int n;
+  int m;
+
+public:
+  Complex1() : n(0) {
+    if (dice())
+      m = 1;
+    // NO-MESSAGES: initialization of 'm' is nested in a conditional expression
+  }
+
+  ~Complex1() = default;
+};
+
+class Complex2 {
+  int n;
+  int m;
+
+public:
+  Complex2() : n(0) {
+    if (!dice())
+      return;
+    m = 1;
+    // NO-MESSAGES: initialization of 'm' follows a conditional expression
+  }
+
+  ~Complex2() = default;
+};
+
+class Complex3 {
+  int n;
+  int m;
+
+public:
+  Complex3() : n(0) {
+    while (dice())
+      m = 1;
+    // NO-MESSAGES: initialization of 'm' is nested in a conditional loop
+  }
+
+  ~Complex3() = default;
+};
+
+class Complex4 {
+  int n;
+  int m;
+
+public:
+  Complex4() : n(0) {
+    while (!dice())
+      return;
+    m = 1;
+    // NO-MESSAGES: initialization of 'm' follows a conditional loop
+  }
+
+  ~Complex4() = default;
+};
+
+class Complex5 {
+  int n;
+  int m;
+
+public:
+  Complex5() : n(0) {
+    do {
+      m = 1;
+      // NO-MESSAGES: initialization of 'm' is nested in a conditional loop
+    } while (dice());
+  }
+
+  ~Complex5() = default;
+};
+
+class Complex6 {
+  int n;
+  int m;
+
+public:
+  Complex6() : n(0) {
+    do {
+      return;
+    } while (!dice());
+    m = 1;
+    // NO-MESSAGES: initialization of 'm' follows a conditional loop
+  }
+
+  ~Complex6() = default;
+};
+
+class Complex7 {
+  int n;
+  int m;
+
+public:
+  Complex7() : n(0) {
+    for (int i = 2; i < 1; ++i) {
+      m = 1;
+    }
+    // NO-MESSAGES: initialization of 'm' is nested into a conditional loop
+  }
+
+  ~Complex7() = default;
+};
+
+class Complex8 {
+  int n;
+  int m;
+
+public:
+  Complex8() : n(0) {
+    for (int i = 0; i < 2; ++i) {
+      return;
+    }
+    m = 1;
+    // NO-MESSAGES: initialization of 'm' follows a conditional loop
+  }
+
+  ~Complex8() = default;
+};
+
+class Complex9 {
+  int n;
+  int m;
+
+public:
+  Complex9() : n(0) {
+    switch (dice()) {
+    case 1:
+      m = 1;
+      // NO-MESSAGES: initialization of 'm' is nested in a conditional expression
+      break;
+    default:
+      break;
+    }
+  }
+
+  ~Complex9() = default;
+};
+
+class Complex10 {
+  int n;
+  int m;
+
+public:
+  Complex10() : n(0) {
+    switch (dice()) {
+    case 1:
+      return;
+      break;
+    default:
+      break;
+    }
+    m = 1;
+    // NO-MESSAGES: initialization of 'm' follows a conditional expression
+  }
+
+  ~Complex10() = default;
+};
+
+class E {};
+int risky(); // may throw
+
+class Complex11 {
+  int n;
+  int m;
+
+public:
+  Complex11() : n(0) {
+    try {
+      risky();
+      m = 1;
+      // NO-MESSAGES: initialization of 'm' follows is nested in a try-block
+    } catch (const E& e) {
+      return;
+    }
+  }
+
+  ~Complex11() = default;
+};
+
+class Complex12 {
+  int n;
+  int m;
+
+public:
+  Complex12() : n(0) {
+    try {
+      risky();
+    } catch (const E& e) {
+      return;
+    }
+    m = 1;
+    // NO-MESSAGES: initialization of 'm' follows a try-block
+  }
+
+  ~Complex12() = default;
+};
+
+class Complex13 {
+  int n;
+  int m;
+
+public:
+  Complex13() : n(0) {
+    return;
+    m = 1;
+    // NO-MESSAGES: initialization of 'm' follows a return statement
+  }
+
+  ~Complex13() = default;
+};
+
+class Complex14 {
+  int n;
+  int m;
+
+public:
+  Complex14() : n(0) {
+    goto X;
+    m = 1;
+    // NO-MESSAGES: initialization of 'm' follows a goto statement
+  X:
+    ;
+  }
+
+  ~Complex14() = default;
+};
+
+void returning();
+
+class Complex15 {
+  int n;
+  int m;
+
+public:
+  Complex15() : n(0) {
+    // CHECK-FIXES: Complex15() : n(0), m(1) {
+    returning();
+    m = 1;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'm' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+  }
+
+  ~Complex15() = default;
+};
+
+[[noreturn]] void not_returning();
+
+class Complex16 {
+  int n;
+  int m;
+
+public:
+  Complex16() : n(0) {
+    not_returning();
+    m = 1;
+    // NO-MESSAGES: initialization of 'm' follows a non-returning function call
+  }
+
+  ~Complex16() = default;
+};
+
+class Complex17 {
+  int n;
+  int m;
+
+public:
+  Complex17() : n(0) {
+    throw 1;
+    m = 1;
+    // NO-MESSAGES: initialization of 'm' follows a 'throw' statement;
+  }
+
+  ~Complex17() = default;
+};
+
+class Complex18 {
+  int n;
+
+public:
+  Complex18() try {
+    n = risky();
+    // NO-MESSAGES: initialization of 'n' in a 'try' body;
+  } catch (const E& e) {
+    n = 0;
+  }
+
+  ~Complex18() = default;
+};
+
+class Complex19 {
+  int n;
+public:
+  Complex19() {
+    // CHECK-FIXES: Complex19() : n(0) {
+    n = 0;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+  }
+
+  explicit Complex19(int) {
+    // CHECK-FIXES: Complex19(int) : n(12) {
+    n = 12;
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+  }
+
+  ~Complex19() = default;
+};
+
+class Complex20 {
+  int n;
+  int m;
+
+public:
+  Complex20(int k) : n(0) {
+    assert(k > 0);
+    m = 1;
+    // NO-MESSAGES: initialization of 'm' follows an assertion
+  }
+
+  ~Complex20() = default;
+};
+
+class VeryComplex1 {
+  int n1, n2, n3;
+  double x1, x2, x3;
+  int n4, n5, n6;
+  double x4, x5, x6;
+
+  VeryComplex1() : n3(something_int()), x3(something_double()),
+                   n5(something_int()), x4(something_double()),
+                   x5(something_double()) {
+    // CHECK-FIXES: VeryComplex1() : n2(something_int()), n1(something_int()), n3(something_int()), x2(something_double()), x1(something_double()), x3(something_double()),
+    // CHECK-FIXES:                  n4(something_int()), n5(something_int()), n6(something_int()), x4(something_double()),
+    // CHECK-FIXES:                  x5(something_double()), x6(something_double()) {
+
+// FIXME: Order of elements on the constructor initializer list should match
+//        the order of the declaration of the fields. Thus the correct fixes
+//        should look like these:
+//
+    // C ECK-FIXES: VeryComplex1() : n2(something_int()), n1(something_int()), n3(something_int()), x2(something_double()), x1(something_double()), x3(something_double()),
+    // C ECK-FIXES:                  n4(something_int()), n5(something_int()), n6(something_int()), x4(something_double()),
+    // C ECK-FIXES:                  x5(something_double()), x6(something_double()) {
+//
+//        However, the Diagnostics Engine processes fixes in the order of the
+//        diagnostics and insertions to the same position are handled in left to
+//        right order thus in the case two adjacent fields are initialized
+//        inside the constructor in reverse order the provided fix is a
+//        constructor initializer list that does not match the order of the
+//        declaration of the fields.
+
+    x2 = something_double();
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'x2' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+    n2 = something_int();
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n2' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+    x6 = something_double();
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'x6' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+    x1 = something_double();
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'x1' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+    n6 = something_int();
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n6' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+    n1 = something_int();
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n1' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+    n4 = something_int();
+    // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: 'n4' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+  }
+};
+
+struct Outside {
+  int n;
+  double x;
+  Outside();
+};
+
+Outside::Outside() {
+    // CHECK-FIXES: Outside::Outside() : n(1), x(1.0) {
+  n = 1;
+    // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'n' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+  x = 1.0;
+    // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'x' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
+    // CHECK-FIXES: {{^\ *$}}
+}