<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On 30 January 2013 00:19, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>
<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">See this thread:<br>
<br>
<a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120709/060344.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120709/060344.html</a><br>
<br>
and particularly:<br>
<br>
<a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120709/060465.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120709/060465.html</a><br>
<div><div class="h5"><br></div></div></blockquote><div><br></div><div style>Thanks for the context on this Richard. It's a somewhat larger can of worms than I was expecting. I see you agreed with the <span style="color:rgb(0,0,0)">CXXDirectInitExpr proposal from John McCall, but I have a suspicion it might be a fair bit of work to implement, integrate and test? That said, this is a fairly ugly problem for code refactoring currently - but not unsurmountable (I hope).</span></div>
<div> </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><div class="h5">
On Tue, Jan 29, 2013 at 2:53 PM, Will Wilson <<a href="mailto:will@indefiant.com">will@indefiant.com</a>> wrote:<br>
> Hi All,<br>
><br>
> I've been digging into a bug that appears when call-style initializers are<br>
> used for builtin types. For example:<br>
><br>
>     int g_foo(1);<br>
><br>
> Results in an initializer that is solely an IntegerLiteral - the<br>
> ParenListExpr that originally surrounded it is lost during<br>
> Sema::AddInitializerToDecl(). This unfortunately also loses the end location<br>
> for the final ')' and leads the VarDecl::getSourceRange() returning the<br>
> location of the IntegerLiteral for the end location.<br>
><br>
> What should be the correct approach here? Surely the ParenListExpr should be<br>
> preserved in the AST? Or if it really is supposed to be folded away at this<br>
> stage than how can we retain the end location for the expression?<br>
<br>
</div></div>Using ParenListExpr is not appropriate -- that AST node is only<br>
intended for transient use, to represent a syntactic construct which<br>
we have not yet resolved to the right semantic node.<br>
</blockquote></div><br>
</div><div class="gmail_extra" style>Fair enough. I think for now I'll attempt to hack around it but if that fails I may have to investigate doing it properly...</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>
 - Will.</div></div>