Patch for Vector Literal source ranges (Bug 15095)
Richard Smith
richard at metafoo.co.uk
Fri Feb 1 17:36:04 PST 2013
This looks fine. Please also provide a new testcase for
unittests/AST/SourceLocationTest.cpp.
On Fri, Feb 1, 2013 at 5:29 PM, John Stratton <john at multicorewareinc.com>wrote:
> Thanks for the feedback. Here's an updated patch. To some extent,
> yes, this situation is weird, but I think the only valid input
> exercising this code path should are cases where it would have been
> semantically equivalent to braces anyway.
>
> --John
>
> On 1/30/13, Richard Smith <richard at metafoo.co.uk> wrote:
> > On Wed, Jan 30, 2013 at 10:57 AM, John Stratton
> > <john at multicorewareinc.com> wrote:
> >> Hello. I've attached a small patch that fixes the 15095 bug I filed a
> >> couple of days ago, and makes sure that the CompoundLiteral and child
> >> AST nodes created from a vector literal have correct source-location
> >> information. Does this make sense to the veteran Clang developers?
> >
> > It's a bit weird that we're building a CompoundLiteralExpr here for a
> > construct which used parentheses not braces, but given that's our
> > representation, it seems appropriate to pretend the braces are where
> > the parens of the initializer were.
> >
> > + if (isVectorLiteral) {
> > + SourceLocation litLParenLoc = (PE ? PE->getLParen() :
> > PLE->getLParenLoc());
> > + SourceLocation litRParenLoc = (PE ? PE->getRParen() :
> > PLE->getRParenLoc());
> >
> > Please compute these locations in BuildVectorLiteral instead (within
> > its 'if (ParenListExpr *PE = dyn_cast<ParenListExpr>(E))' code).
> >
> > Also, variable names should start with an uppercase letter (this code
> > breaks the convention in a few places, but new code should conform).
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130201/e29dd2c4/attachment.html>
More information about the cfe-commits
mailing list