[cfe-dev] BUG: VarDecl::getSourceRange() incorrect if CallInit style used for builtin type.

[Will Wilson]

On 30 January 2013 00:19, Richard Smith <richard at metafoo.co.uk> wrote:

> See this thread:
>
>
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120709/060344.html
>
> and particularly:
>
>
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120709/060465.html
>
>
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 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).


> On Tue, Jan 29, 2013 at 2:53 PM, Will Wilson <will at indefiant.com> wrote:
> > Hi All,
> >
> > I've been digging into a bug that appears when call-style initializers
> are
> > used for builtin types. For example:
> >
> >     int g_foo(1);
> >
> > Results in an initializer that is solely an IntegerLiteral - the
> > ParenListExpr that originally surrounded it is lost during
> > Sema::AddInitializerToDecl(). This unfortunately also loses the end
> location
> > for the final ')' and leads the VarDecl::getSourceRange() returning the
> > location of the IntegerLiteral for the end location.
> >
> > What should be the correct approach here? Surely the ParenListExpr
> should be
> > preserved in the AST? Or if it really is supposed to be folded away at
> this
> > stage than how can we retain the end location for the expression?
>
> Using ParenListExpr is not appropriate -- that AST node is only
> intended for transient use, to represent a syntactic construct which
> we have not yet resolved to the right semantic node.
>

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...

 - Will.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130130/da3e64d3/attachment.html>