<div dir="ltr"><div>+        if (isa<BlockDecl>(DC)) {</div><div>+          OS << "block function";</div><div>+          break;</div><div>+        }</div><div>+        if (isLambdaCallOperator(DC)) {</div>
<div>+          OS << "lambda function";</div><div>+          break;</div><div>+        }</div><div><br></div><div>Neither of these terms are used in any existing diagnostics, nor in the relevant specifications. Maybe "block literal" and "lambda expression" would be more appropriate? Also, have you considered using "lambda expression within <name of surrounding entity>" or similar?</div>
<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 2, 2014 at 5:51 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Just some quick notes:<br>
<br>
const Decl *Demangle<br>
<br>
should probably be demangle, or maybe a getDeclForMangledName, since<br>
it does more than demangle a string.<br>
<br>
+  bool LookupRepresentativeDecl(<br>
<br>
should start with a lowercase.<br>
<br>
And a big thanks. This should let us produce far better diagnostics<br>
for things that involve mangled names, like aliases!<br>
<br>
btw, this also improves things a bit for pr18188, right?<br>
<div class=""><div class="h5"><br>
<br>
On 30 May 2014 12:23, Alp Toker <<a href="mailto:alp@nuanti.com">alp@nuanti.com</a>> wrote:<br>
> The attached patch adds driver and frontend support for the GCC<br>
> -Wframe-larger-than=bytes warning.<br>
><br>
> As the first GCC-compatible backend diagnostic built around LLVM's reporting<br>
> feature the patch adds infrastructure to perform reverse lookup from mangled<br>
> names emitted after LLVM code generation. Using that we resolve precise<br>
> locations and originating AST functions, lambdas or block declarations to<br>
> provide rich codegen-guided diagnostics.<br>
><br>
> Supporting changes:<br>
>   * Get rid of the old MangleBuffer class that was only used for blocks<br></div></div></blockquote><div><br></div><div>Can you split out / commit this separately?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5">
>   * Let StringMap maintain unique mangled name strings instead of allocating<br>
> copies<br></div></div></blockquote><div><br></div><div>Do you have an feel for / have you measured the memory usage before and after this patch? I'm not expecting any big surprises here, since we were retaining storage for the mangled names anyway, but it'd be nice to have the extra confidence.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">> The test intentionally conflates driver, frontend and backend facilities for<br>

> now, and I expect parts of the approach to evolve as we get a feel for how<br>
> it'll play ball with LTO etc.</div></div></blockquote><div><br></div><div>We need to have a fallback codepath for the case where the lookup fails; am I right to assume that LTO (and IR from imported modules, and so on) would take that path and gracefully degrade?</div>
</div></div></div>