<div dir="ltr"><div>+    }</div><div>+    else { // FPT->getExceptionSpecType() is resolved and the other is not</div><div><br></div><div>You're not checking for this condition; the code here is getting run even if both or neither are unresolved.</div><div><br></div><div>The patch needs rebasing (we have a new helper function in ASTContext to update the exception specification of a declaration), but looks like the right direction.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 6, 2014 at 4:23 AM, Vassil Vassilev <span dir="ltr"><<a href="mailto:vasil.georgiev.vasilev@cern.ch" target="_blank">vasil.georgiev.vasilev@cern.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Richard,<br>
  I am attaching the patch we discussed at the dev meeting. Still haven't found small reproducer...<br>
  The issue appears to stem from the fact that module A contains only a forward declaration of a function and it exception spec cannot be computed. In module B is the definition with computed exception spec, which gets deserialized after the one in module A. This patch teaches the ASTDeclReader to update all the exception specs of the previous decls to the current one.<br>
<br>
  Could you review, please?<br>
Many thanks,<br>
Vassil<br>
</blockquote></div><br></div>