<div dir="ltr">Sorry I lost track of this.<div>Having understood the code a bit more, the current split between the AST/analysis/static analyzer isn't as clear as I thought.</div><div>So I'm not sure the layering is perfect here, but the fault doesn't lie with your patch. Sorry for the noise.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 2, 2018 at 5:43 PM Tim Northover <<a href="mailto:tnorthover@apple.com">tnorthover@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2 Nov 2018, at 15:28, Sam McCall <<a href="mailto:sammccall@google.com" target="_blank">sammccall@google.com</a>> wrote:<br>
> In that case, I don't think it makes sense to think of the format string parser as part of the analyzer - as the build deps suggest, it's now part of AST and gets reused by analyzer. (Similar to how the analyzer uses other bits of AST/clang). If there are parts only relevant to analyzer, it'd be nice to move them out of the AST library, but I don't know to what extent that's feasible.<br>
<br>
The Scanf one could have been left there, but that seems even worse from a consistency point of view.<br>
<br>
> So it does seem to me like all the uses of analyzer namespaces are suspect - moving code from Analyzer to AST is a semantic difference (the layers aren't *just* about making the linker happy, after all!)<br>
<br>
But what it’s doing is still analysis. It seems like we’d just be making up another term for the sake of it if we changed it.<br>
<br>
Cheers.<br>
<br>
Tim</blockquote></div>