[cfe-commits] [PATCH] Fix crash printing diagnostic range spanning macros

[Chandler Carruth]

On Thu, Oct 25, 2012 at 9:38 AM, Jordan Rose <jordan_rose at apple.com> wrote:
> I think that's the best we can do. Even if the range had the beginning
> before the end (say, by trying to highlight the entirety of both macros), it
> wouldn't be "correct".  We should not show ranges that don't correspond to
> something meaningful in the text.

I actually think we can do a bit better.

> ...though arguably we could show a line with all macros expanded, and put
> the range there. But that's a big change in what you expect from diagnostic
> printing, and it wouldn't work in IDEs anyway.

We get pretty close with the macro backtrace. I have sometimes
wondered if we should start the error with a synthetic preprocessed
snippet, and then give the code the user wrote in the first note, and
descend through the macro expansions in subsequent notes.
Alternatively, we could add a final note to the macro backtrace that
shows the fully preprocessed source, but that seems more likely to be
ignored.

>
> Jordan
>
>
> On Oct 24, 2012, at 19:36 , Eli Friedman <eli.friedman at gmail.com> wrote:
>
> Patch attached.  Fixes a crash on a testcase like the following:
>
> +#define BAD_CONDITIONAL_OPERATOR (2<3)?4:5
> +int x = BAD_CONDITIONAL_OPERATOR+BAD_CONDITIONAL_OPERATOR;
>
> We try to print a source range which starts at the 5 in the first
> expansion, and ends just after the 3 in the second expansion.

My suggestion would be this:

When you have a source range to highlight, and it's start or stop
location occurs within a macro, grow it to the start (or stop, resp.)
of the macro info's expansion location. This should be the start of
where the macro got expanded into the code.

Then, if there the diagnostic location itself is inside a macro, as
you do the macro backtrace walk you'll need to address the fixme in
the diagnostic code to actually walk the source ranges back through
the macro backtrace as well, and at each level to the analogous
transform to grow the range at that level.

This would hopefully produce something like:

int x = BAD + BAD
        ~~~~^~~~~

and even if you have "#define BAD2 BAD +" we could get:

int x = BAD2 BAD
        ^~~~~~~~

#define BAD2 BAD +
             ~~~~^



> This
> causes an assertion failure in diagnostic emission because the
> beginning of the range appears to be after the end.
>
> My attempted fix is to try to suppress printing source ranges when the
> beginning and end point into different macro expansions (even if the
> physical locations happen to be on the same line).  I'm not confident
> this is the correct fix, but it seems to be roughly on the right
> track.  Any comments welcome.
>
> (This is <rdar://problem/12472249>.)
>
> -Eli
> <sourcerange_assert.txt>_______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>