BUG: VarDecl::getSourceRange() incorrect if CallInit style used for builtin type.

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?

Any thoughts?

  • Will.

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

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

The workarounds I have for this issue are ugly and I fear more than a little unreliable. Okay if I file a bug for this just to ensure it doesn’t get forgotten about?

Incidentally, I did try bypassing the code that removes the ParenListExpr and things just worked - so perhaps transitioning to a CXXDirectInitExpr may not be too painful if the approach is similar.

  • Will.

The workarounds I have for this issue are ugly and I fear more than a little
unreliable. Okay if I file a bug for this just to ensure it doesn't get
forgotten about?

Please do!

Added as PR15146: http://llvm.org/bugs/show_bug.cgi?id=15146