<div dir="ltr"><div><div>Aaron, you are correct.  There is not currently a test for that.  I can either add one to this patch or ensure that one is in the next patch.<br><br></div>DeLesely: That was the assumption that David and I came up with.  This will produce more errors, but should catch more bugs.  There could be a problem, however, when a method does change internal state, but not state that is relevant to the "consumed/unconsumed" status of the object.  This method couldn't be marked constant, and would therefor transition the object out of its known state.<br>
<br></div>- Chris<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 21, 2013 at 3:16 PM, Delesley Hutchins <span dir="ltr"><<a href="mailto:delesley@google.com" target="_blank">delesley@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
  LGTM.<br>
<br>
<br>
================<br>
Comment at: lib/Analysis/Consumed.cpp:446<br>
@@ -419,1 +445,3 @@<br>
+          if (!MethodDecl->isConst())<br>
+            StateMap->setState(PState.getVar(), consumed::CS_Unknown);<br>
         }<br>
----------------<br>
Is the assumption here that calling a non-const method puts the object into an unknown state?  That's a correct, conservative judgement.<br>
<br>
However, an alternative is to assume that unmarked methods do not change the object state, which might be more user-friendly in the common case.<br>
<br>
<br>
<a href="http://llvm-reviews.chandlerc.com/D1468" target="_blank">http://llvm-reviews.chandlerc.com/D1468</a><br>
</blockquote></div><br></div>