<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 4, 2011, at 10:28 AM, John McCall wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jan 4, 2011, at 7:41 AM, Douglas Gregor wrote:</div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jan 4, 2011, at 1:28 AM, Chandler Carruth wrote:</div><blockquote type="cite"><div class="gmail_quote">On Mon, Jan 3, 2011 at 11:25 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div class="im">On Mon, Jan 3, 2011 at 10:57 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>Perhaps we could add this note as a follow-on when an expression statement consists of just a self-assignment?</div>
</div></div></div></blockquote><div>
<br></div></div><div>This is a good idea about how to key the fix-it hint. I'll submit this as a follow-up, and then run it over LLVM and Clang, as it seems we aren't immune to this code pattern. =D</div></div></div>
</blockquote><div><br></div></div><div>I'm finding this a bit ugly to implement... Currently, the diagnostic is nicely isolated in the expression building part of Sema. This is nice because it can catch oddities like f(x = x);, but I don't see a nice way to check that this is the only component of the statement. We could just emit the notes from a separate routine in SemaStmt.cpp, and give it the same location? Is that the best way to do this?</div>
</div></blockquote><div><br></div><div>Here is what I ended up with. Not sure if this is the right way forward, or there are other ways to approach matters. I have some orthogonal cleanups queued as well, but I'll see how this shapes up first.</div></div></blockquote><div><br></div><div>Hrm, this only works correctly when the self-assignment warning was the last warning emitted before we make the callback to specify that the expression is an expression statement. Even if we manage to satisfy that property now, it's going to be hard to guarantee that this property holds in the future. Sorry, I think I led you astray with my "follow-on" comment.</div></div></div></blockquote><div><br></div>I also can't imagine how we would satisfy that property.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>The only feasible idea I have at the moment is a bit of work: add an ActOnSubExpr callback that the parser (and tree transformer) invokes whenever a given expression is used as a subexpression. That way, all expressions either go through ActOnSubExpr or ActOnFinishFullExpr. Both routines would perform the self-assignment check, but the latter would also emit the note (it may need to be extended with some kind of "this result is completely ignored" flag).</div></div></div></blockquote><div><br></div><div>I don't think this really solves the problem, as a parenthesized expression would clearly be a sub-expression and an initializer would be a full-expression.</div><div><br></div><div>Also, the optimal rewrite for "(a = a);" would probably be "(void) (a);", not "((void) a);".</div></div></div></blockquote><div><br></div><div>In my scheme, we just wouldn't end up providing a rewrite for (a = a). I'm okay with that.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>We could have a queue of things to consider at the end of a full-expression. I think there's even a SourceLocation passed in to MaybeCreateExprWithCleanups which should be invalid iff we're in a ignored context. On the other hand, I think we don't always get a callback at the end of a broken full-expression.</div></div></div></blockquote><br></div><div>Sure, that's possible too. I don't much care if we don't emit warnings about a broken full-expression, though.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><br></body></html>