<div dir="ltr"><div>+/// Prints a fixit for adding a null initializer for |Entity|. Call this only</div><div>+/// right after emitting a diagnostic.</div><div>+static void maybeEmitNullInitializationFixit(Sema &S,</div>
<div>+                                             InitializationSequence &Sequence,</div><div>+                                             const InitializedEntity &Entity) {</div><div><br></div><div>s/null/zero/g</div>
<div><br></div><div>Otherwise, LGTM.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 22, 2014 at 9:18 AM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir="ltr"><div>Ideas? Easiest would be to put the fixit on a note, but the note would just repeat the snippet from the diag itself, which isn't great.</div>
</div></blockquote><div><br></div></div><div>We do that in a lot of cases; this wouldn't be so bad, and it'd be safer. The current approach is also workable, because we never make a choice based on whether default initialization of a variable is valid, but it seems fragile.</div>


<div><br></div><div>The nice thing about putting it in a separate note is that you can point the caret directly at the place where the fixit text should be inserted, while still having the main diagnostic point at the entity being initialized; that tends to make fixits much more obvious.</div>

</div></div></div></blockquote></div><br></div></div><div class="gmail_extra">Ok, here's a patch that adds the fixit on a note instead. The code change is now very simple. The diagnostic looks like this:</div><div class="gmail_extra">

<br></div><div class="gmail_extra"><div class="gmail_extra">test.cc:2:9: error: default initialization of an object of const type 'const A' without a user-provided default constructor</div><div class="gmail_extra">

const A aasdf;</div><div class="gmail_extra">        ^</div><div class="gmail_extra">test.cc:2:14: note: add an explicit initializer to initialize 'aasdf'</div><div class="gmail_extra">const A aasdf;</div><div class="gmail_extra">

             ^</div><div class="gmail_extra">              = {}</div><div class="gmail_extra">1 error generated.</div><div><br></div><div>Maybe it should be " add an explicit initializer for 'aasdf'"? That's shorter, but it sounds too confident maybe.</div>

<div><br></div><div>The test case updates are mostly boring. In cxx1y-variable-templates_in_class.cpp, the variable name for a template is printed as "…to initialize 'b<int, int>'" with a note "in instantiation of". I found that a bit surprising, but it matches the diagnostic on the same line, so I suppose that's ok.</div>
</div></div></blockquote><div><br></div><div>You could use %q0 in the diagnostic if you want to see 'B4::b<int, int>' here. (If it's not that, I'm not sure which part you find surprising here.)</div>
</div></div></div>