[PATCH] D127923: [Diagnostics] Accept newline and format diag opts on first line

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

My objection to the original patch was including things like the "" lines 
as remarks to mark a section. I don't think these should be emitted as remarks 
and are a display function the frontend should take care of if we want any kind 
of grouping


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127923/new/

https://reviews.llvm.org/D127923

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127923: [Diagnostics] Accept newline and format diag opts on first line

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D127923#3600422 , @vangthao wrote:

> In D127923#3599451 , @aaron.ballman 
> wrote:
>
>> Is there a reason the remarks can't use individual diagnostic emissions to 
>> simulate newlines? Or is this perhaps a demonstration that the remarks 
>> should not be using the diagnostic engine at all and should be emitting 
>> their output to a user-controllable stream (or file)?
>
> An issue with using multiple diagnostic emissions to simulate newlines is 
> that there are repeated information such as diagnostic location and diagopts 
> reprinted for each line. This creates a lot of noise and makes the output 
> harder to read.

I can see how that's the case if the prefix information is different with each 
diagnostic line, but if they're all repeating the same prefix, that noise 
should be lessened by quite a bit (and for those truly distracted by it, using 
the same prefix each time makes it easier to strip the prefix in an editor). 
e.g.,

  remark: foo.cl:27:0: 6 instructions in function
  remark: foo.cl:27:0: Kernel Name: test_kernel
  remark: foo.cl:27:0: SGPRs: 24
  remark: foo.cl:27:0: VGPRs: 9
  remark: foo.cl:27:0: AGPRs: 43
  remark: foo.cl:27:0: ScratchSize [bytes/thread]: 0
  remark: foo.cl:27:0: Occupancy [waves/SIMD]: 5
  remark: foo.cl:27:0: SGPRs Spill: 0
  remark: foo.cl:27:0: VGPRs Spill: 0
  remark: foo.cl:27:0: LDS Size [bytes/block]: 512
  remark: foo.cl:27:0: --

doesn't look that terrible to me because all the salient information is 
visually aligned. (Line wrapping would be an issue, but the same is true for 
line wrapping mixed with manual newlines.) Do you have the ability to control 
the location of the diagnostic so you can keep the prefix the same throughout 
the report (or use the same prefix within a notional "section" of the report so 
that blocks of related remarks are visually grouped with the same prefix)?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127923/new/

https://reviews.llvm.org/D127923

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127923: [Diagnostics] Accept newline and format diag opts on first line

[Vang Thao via Phabricator via cfe-commits]

vangthao added a comment.

In D127923#3599451 , @aaron.ballman 
wrote:

> Is there a reason the remarks can't use individual diagnostic emissions to 
> simulate newlines? Or is this perhaps a demonstration that the remarks should 
> not be using the diagnostic engine at all and should be emitting their output 
> to a user-controllable stream (or file)?

An issue with using multiple diagnostic emissions to simulate newlines is that 
there are repeated information such as diagnostic location and diagopts 
reprinted for each line. This creates a lot of noise and makes the output 
harder to read. Accepting newlines in diagnostics would allow for a lot more 
flexibility but I do see your point on how it would also encourage longer 
diagnostics.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127923/new/

https://reviews.llvm.org/D127923

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127923: [Diagnostics] Accept newline and format diag opts on first line

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a subscriber: beanz.
aaron.ballman added a comment.

I'm a bit uncomfortable with this as we (at least currently) want to discourage 
non-terse diagnostics, and allowing newlines encourages longer diagnostics. 
There's an RFC kicking around about making more expressive diagnostics and so 
this discomfort may pass with time. (The only three uses of \n in our current 
Clang diagnostics are all driver diagnostics and all three of them are new for 
the HLSL stuff, wrong, and need to be reworded. CC @beanz to look into fixing 
up 
https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/DiagnosticDriverKinds.td#L674).

Is there a reason the remarks can't use individual diagnostic emissions to 
simulate newlines? Or is this perhaps a demonstration that the remarks should 
not be using the diagnostic engine at all and should be emitting their output 
to a user-controllable stream (or file)?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127923/new/

https://reviews.llvm.org/D127923

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127923: [Diagnostics] Accept newline and format diag opts on first line

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.

Thanks for updating the summary.

I'm not too confident around diagnostics though.
I'm going to piggyback on @scott.linder's comments. I think they are on the 
point.

nit: I'm not sure if `size_t` is a thing in c++, `std::size_t` is though.




Comment at: clang/lib/Basic/Diagnostic.cpp:815
 for (char c : S) {
-  if (llvm::sys::locale::isPrint(c) || c == '\t') {
+  if (llvm::sys::locale::isPrint(c) || c == '\t' || c == '\n') {
 OutStr.push_back(c);

Should we account for `'\r'`-s as well? I'm not sure how it works though



Comment at: clang/lib/Frontend/TextDiagnosticPrinter.cpp:119-135
+  // If the diagnostic message is formatted into multiple lines, split the
+  // first line and feed it into printDiagnosticOptions so that we print the
+  // options only on the first line instead of the last line.
+  SmallString<100> InitStr;
+  size_t NewlinePos = OutStr.find_first_of('\n');
+  if (NewlinePos != StringRef::npos) {
+for (size_t I = 0; I != NewlinePos; ++I)

scott.linder wrote:
> Nit: I'd remove the `if`s and just use the behavior of `slice(npos, ...)` 
> returning the empty string
> 
> I also would reword "split the first line and feed it into 
> printDiagnosticOptions", as it could be interpreted as meaning the first line 
> is an input to `printDiagnosticOptions`
Use braces for both branches or no braces at all. [[ 
https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements
 | LLVM CodingStandards ]]


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127923/new/

https://reviews.llvm.org/D127923

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127923: [Diagnostics] Accept newline and format diag opts on first line

[Scott Linder via Phabricator via cfe-commits]

scott.linder added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/TextDiagnostics.cpp:99-103
+  size_t NewlinePos = PD->getShortDescription().find_first_of('\n');
+  if (NewlinePos != std::string::npos)
+OutStr = PD->getShortDescription().str().insert(NewlinePos, 
WarningMsg);
+  else
+OutStr = (PD->getShortDescription() + WarningMsg).str();

scott.linder wrote:
> It's frustrating that `std::string::insert` doesn't follow the pattern of 
> `npos==end-of-string`, but I'd still suggest only doing the actual 
> insert/append once
Or to be more precise, I would try to only have one piece of code doing the 
insert/append


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127923/new/

https://reviews.llvm.org/D127923

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127923: [Diagnostics] Accept newline and format diag opts on first line

[Scott Linder via Phabricator via cfe-commits]

scott.linder added a comment.

Thank you for the patch! I will leave it to others with more knowledge of the 
history of diagnostics to comment on whether the premise is acceptable, but I 
have a few technical comments




Comment at: clang/lib/Frontend/TextDiagnosticPrinter.cpp:119-135
+  // If the diagnostic message is formatted into multiple lines, split the
+  // first line and feed it into printDiagnosticOptions so that we print the
+  // options only on the first line instead of the last line.
+  SmallString<100> InitStr;
+  size_t NewlinePos = OutStr.find_first_of('\n');
+  if (NewlinePos != StringRef::npos) {
+for (size_t I = 0; I != NewlinePos; ++I)

Nit: I'd remove the `if`s and just use the behavior of `slice(npos, ...)` 
returning the empty string

I also would reword "split the first line and feed it into 
printDiagnosticOptions", as it could be interpreted as meaning the first line 
is an input to `printDiagnosticOptions`



Comment at: clang/lib/StaticAnalyzer/Core/TextDiagnostics.cpp:99-103
+  size_t NewlinePos = PD->getShortDescription().find_first_of('\n');
+  if (NewlinePos != std::string::npos)
+OutStr = PD->getShortDescription().str().insert(NewlinePos, 
WarningMsg);
+  else
+OutStr = (PD->getShortDescription() + WarningMsg).str();

It's frustrating that `std::string::insert` doesn't follow the pattern of 
`npos==end-of-string`, but I'd still suggest only doing the actual 
insert/append once



Comment at: clang/lib/StaticAnalyzer/Core/TextDiagnostics.cpp:100
+  size_t NewlinePos = PD->getShortDescription().find_first_of('\n');
+  if (NewlinePos != std::string::npos)
+OutStr = PD->getShortDescription().str().insert(NewlinePos, 
WarningMsg);

I believe they are guaranteed to be equivalent, but this should be 
`StringRef::npos` or you should allocate the `std::string` sooner



Comment at: clang/lib/StaticAnalyzer/Core/TextDiagnostics.cpp:101
+  if (NewlinePos != std::string::npos)
+OutStr = PD->getShortDescription().str().insert(NewlinePos, 
WarningMsg);
+  else

I think you incur an extra copy assignment here, as the `insert` returns an 
lvalue-reference


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127923/new/

https://reviews.llvm.org/D127923

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127923: [Diagnostics] Accept newline and format diag opts on first line

[Vang Thao via Phabricator via cfe-commits]

vangthao updated this revision to Diff 437593.
vangthao added a comment.

Update commit message to include the motivation behind the patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127923/new/

https://reviews.llvm.org/D127923

Files:
  clang/lib/Basic/Diagnostic.cpp
  clang/lib/Frontend/TextDiagnosticPrinter.cpp
  clang/lib/StaticAnalyzer/Core/TextDiagnostics.cpp
  clang/test/Analysis/padding_message.cpp

Index: clang/test/Analysis/padding_message.cpp
===
--- clang/test/Analysis/padding_message.cpp
+++ clang/test/Analysis/padding_message.cpp
@@ -1,11 +1,11 @@
 // RUN: %clang_analyze_cc1 -triple x86_64-unknown-linux -std=c++14 -analyzer-checker=optin.performance -analyzer-config optin.performance.Padding:AllowedPad=2 -verify %s
 
 // expected-warning@+7{{\
-Excessive padding in 'struct IntSandwich' (6 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-i, \
-c1, \
-c2, \
+Excessive padding in 'struct IntSandwich' (6 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+i, \n\
+c1, \n\
+c2, \n\
 }}
 struct IntSandwich {
   char c1;
@@ -14,11 +14,11 @@
 };
 
 // expected-warning@+7{{\
-Excessive padding in 'struct TurDuckHen' (6 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-i, \
-c1, \
-c2, \
+Excessive padding in 'struct TurDuckHen' (6 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+i, \n\
+c1, \n\
+c2, \n\
 }}
 struct TurDuckHen {
   char c1;
@@ -29,15 +29,15 @@
 #pragma pack(push)
 #pragma pack(2)
 // expected-warning@+11{{\
-Excessive padding in 'struct SmallIntSandwich' (4 padding bytes, where 0 is optimal). \
-Optimal fields order: \
-i1, \
-i2, \
-i3, \
-c1, \
-c2, \
-c3, \
-c4, \
+Excessive padding in 'struct SmallIntSandwich' (4 padding bytes, where 0 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+i1, \n\
+i2, \n\
+i3, \n\
+c1, \n\
+c2, \n\
+c3, \n\
+c4, \n\
 }}
 struct SmallIntSandwich {
   char c1;
@@ -57,11 +57,11 @@
 };
 
 // expected-warning@+7{{\
-Excessive padding in 'struct HoldsAUnion' (6 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-u, \
-c1, \
-c2, \
+Excessive padding in 'struct HoldsAUnion' (6 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+u, \n\
+c1, \n\
+c2, \n\
 }}
 struct HoldsAUnion {
   char c1;
@@ -78,11 +78,11 @@
 };
 
 // expected-warning@+7{{\
-Excessive padding in 'struct StructSandwich' (6 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-m, \
-s, \
-s2, \
+Excessive padding in 'struct StructSandwich' (6 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+m, \n\
+s, \n\
+s2, \n\
 }}
 struct StructSandwich {
   struct SmallCharArray s;
@@ -91,11 +91,11 @@
 };
 
 // expected-warning@+7{{\
-Excessive padding in 'TypedefSandwich' (6 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-i, \
-c1, \
-c2, \
+Excessive padding in 'TypedefSandwich' (6 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+i, \n\
+c1, \n\
+c2, \n\
 }}
 typedef struct {
   char c1;
@@ -104,11 +104,11 @@
 } TypedefSandwich;
 
 // expected-warning@+7{{\
-Excessive padding in 'struct StructAttrAlign' (10 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-i, \
-c1, \
-c2, \
+Excessive padding in 'struct StructAttrAlign' (10 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+i, \n\
+c1, \n\
+c2, \n\
 }}
 struct StructAttrAlign {
   char c1;
@@ -117,12 +117,12 @@
 } __attribute__((aligned(8)));
 
 // expected-warning@+8{{\
-Excessive padding in 'struct OverlyAlignedChar' (8185 padding bytes, where 4089 is optimal). \
-Optimal fields order: \
-c, \
-c1, \
-c2, \
-x, \
+Excessive padding in 'struct OverlyAlignedChar' (8185 padding bytes, where 4089 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+c, \n\
+c1, \n\
+c2, \n\
+x, \n\
 }}
 struct OverlyAlignedChar {
   char c1;
@@ -132,11 +132,11 @@
 };
 
 // expected-warning@+7{{\
-Excessive padding in 'struct HoldsOverlyAlignedChar' (8190 padding bytes, where 4094 is optimal). \
-Optimal fields order: \
-o, \
-c1, \
-c2, \
+Excessive padding in 'struct HoldsOverlyAlignedChar' (8190 padding bytes, where 4094 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+o, \n\
+c1, \n\
+c2, \n\
 }}
 struct HoldsOverlyAlignedChar {
   char c1;
@@ -146,11 +146,11 @@
 
 void internalStructFunc() {
   // expected-warning@+7{{\
-Excessive padding in 'struct X' (6 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-t, \
-c1, \
-c2, \
+Excessive padding in 'struct X' (6 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+t, \n\
+c1, \n\
+c2, \n\
 }}
   struct X {
 char c1;
@@ -162,11 

[PATCH] D127923: [Diagnostics] Accept newline and format diag opts on first line

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.

Please, consider updating the summary to clearly specify the motivation for 
making this change.
It describes what this patch intends to do, but I'm about the why.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127923/new/

https://reviews.llvm.org/D127923

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127923: [Diagnostics] Accept newline and format diag opts on first line

[Gabor Marton via Phabricator via cfe-commits]

martong added subscribers: steakhal, NoQ.
martong added a comment.

@NoQ @steakhal FYI


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127923/new/

https://reviews.llvm.org/D127923

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D127923: [Diagnostics] Accept newline and format diag opts on first line

[Vang Thao via Phabricator via cfe-commits]

vangthao created this revision.
Herald added a subscriber: martong.
Herald added a project: All.
vangthao requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Accept newlines when the diagnostic string is being given by an outside source
instead of ignoring newlines. I believe the other processing done in
`FormatDiagnostic()` does not ignore newlines so we should also not ignore it
here.

Also format diagnostic options on the first line when there are multiple lines.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D127923

Files:
  clang/lib/Basic/Diagnostic.cpp
  clang/lib/Frontend/TextDiagnosticPrinter.cpp
  clang/lib/StaticAnalyzer/Core/TextDiagnostics.cpp
  clang/test/Analysis/padding_message.cpp

Index: clang/test/Analysis/padding_message.cpp
===
--- clang/test/Analysis/padding_message.cpp
+++ clang/test/Analysis/padding_message.cpp
@@ -1,11 +1,11 @@
 // RUN: %clang_analyze_cc1 -triple x86_64-unknown-linux -std=c++14 -analyzer-checker=optin.performance -analyzer-config optin.performance.Padding:AllowedPad=2 -verify %s
 
 // expected-warning@+7{{\
-Excessive padding in 'struct IntSandwich' (6 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-i, \
-c1, \
-c2, \
+Excessive padding in 'struct IntSandwich' (6 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+i, \n\
+c1, \n\
+c2, \n\
 }}
 struct IntSandwich {
   char c1;
@@ -14,11 +14,11 @@
 };
 
 // expected-warning@+7{{\
-Excessive padding in 'struct TurDuckHen' (6 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-i, \
-c1, \
-c2, \
+Excessive padding in 'struct TurDuckHen' (6 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+i, \n\
+c1, \n\
+c2, \n\
 }}
 struct TurDuckHen {
   char c1;
@@ -29,15 +29,15 @@
 #pragma pack(push)
 #pragma pack(2)
 // expected-warning@+11{{\
-Excessive padding in 'struct SmallIntSandwich' (4 padding bytes, where 0 is optimal). \
-Optimal fields order: \
-i1, \
-i2, \
-i3, \
-c1, \
-c2, \
-c3, \
-c4, \
+Excessive padding in 'struct SmallIntSandwich' (4 padding bytes, where 0 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+i1, \n\
+i2, \n\
+i3, \n\
+c1, \n\
+c2, \n\
+c3, \n\
+c4, \n\
 }}
 struct SmallIntSandwich {
   char c1;
@@ -57,11 +57,11 @@
 };
 
 // expected-warning@+7{{\
-Excessive padding in 'struct HoldsAUnion' (6 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-u, \
-c1, \
-c2, \
+Excessive padding in 'struct HoldsAUnion' (6 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+u, \n\
+c1, \n\
+c2, \n\
 }}
 struct HoldsAUnion {
   char c1;
@@ -78,11 +78,11 @@
 };
 
 // expected-warning@+7{{\
-Excessive padding in 'struct StructSandwich' (6 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-m, \
-s, \
-s2, \
+Excessive padding in 'struct StructSandwich' (6 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+m, \n\
+s, \n\
+s2, \n\
 }}
 struct StructSandwich {
   struct SmallCharArray s;
@@ -91,11 +91,11 @@
 };
 
 // expected-warning@+7{{\
-Excessive padding in 'TypedefSandwich' (6 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-i, \
-c1, \
-c2, \
+Excessive padding in 'TypedefSandwich' (6 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+i, \n\
+c1, \n\
+c2, \n\
 }}
 typedef struct {
   char c1;
@@ -104,11 +104,11 @@
 } TypedefSandwich;
 
 // expected-warning@+7{{\
-Excessive padding in 'struct StructAttrAlign' (10 padding bytes, where 2 is optimal). \
-Optimal fields order: \
-i, \
-c1, \
-c2, \
+Excessive padding in 'struct StructAttrAlign' (10 padding bytes, where 2 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+i, \n\
+c1, \n\
+c2, \n\
 }}
 struct StructAttrAlign {
   char c1;
@@ -117,12 +117,12 @@
 } __attribute__((aligned(8)));
 
 // expected-warning@+8{{\
-Excessive padding in 'struct OverlyAlignedChar' (8185 padding bytes, where 4089 is optimal). \
-Optimal fields order: \
-c, \
-c1, \
-c2, \
-x, \
+Excessive padding in 'struct OverlyAlignedChar' (8185 padding bytes, where 4089 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+c, \n\
+c1, \n\
+c2, \n\
+x, \n\
 }}
 struct OverlyAlignedChar {
   char c1;
@@ -132,11 +132,11 @@
 };
 
 // expected-warning@+7{{\
-Excessive padding in 'struct HoldsOverlyAlignedChar' (8190 padding bytes, where 4094 is optimal). \
-Optimal fields order: \
-o, \
-c1, \
-c2, \
+Excessive padding in 'struct HoldsOverlyAlignedChar' (8190 padding bytes, where 4094 is optimal).  [optin.performance.Padding]\n\
+Optimal fields order: \n\
+o, \n\
+c1, \n\
+c2, \n\
 }}
 struct HoldsOverlyAlignedChar {
   char c1;
@@ -146,11 +146,11 @@
 
 void internalStructFunc() {
   // expected-warning@+7{{\