[clang] [clang-tools-extra] [clang][NFC] Refactor `CXXNewExpr::InitializationStyle` (re-land) (PR #71417)

Balazs Benics via cfe-commits cfe-commits at lists.llvm.org
Thu Jan 18 03:03:49 PST 2024


steakhal wrote:

> Please let us know if this change is disruptive to you though, thanks!

I'm not really well versed about c++ initialization, so I asked my collage @tomasz-kaminski-sonarsource, to double-check how `CXXNewExpr` initialization is done per standard.
I'll try to summarize what we discussed:

The enum we had in the past described the syntax of the new expression. However, after the introduction of the `Implicit` style kind, this enum tries to encode the semantics aspect as well.

Note that the name of the previous kind `CallInit` was misleading, and it should have been called `ParenInit` denoting that in the spelling `(...)`'s were used. So, in the past, `InitializationStyle` did not try to encode whether or not an actual call would be present or not.

To illustrate this, here is a small example:
```c++
struct Derived {
  int data1;
  int data2;
};
void top() {
  // CURRENT STYLE, EXPECTED BEHAVIOR
  // -------------  -----------------
  // const auto *p = new int(); // Call (aka. parens), good (zero inits)
  // const auto *p = new int; // None, good (uninitialized)
  // const auto *p = new Derived; // Implicit, but still leaves everything uninitialized
  // const auto *p = new int[10]; // None, good (uninitialized)
  // const auto *p = new Derived[10]; // Implicit, but still leaves everything uninitialized
}
```

https://github.com/llvm/llvm-project/pull/71417


More information about the cfe-commits mailing list