<div class="gmail_quote">On Wed, Jun 6, 2012 at 2:46 PM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Jun 6, 2012, at 8:15 AM, Manuel Klimek <<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>> wrote:</div><br><blockquote type="cite">
<div class="gmail_quote">On Wed, Jun 6, 2012 at 5:04 PM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>></span> wrote:<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>On Jun 6, 2012, at 3:23 AM, Chandler Carruth wrote:</div><br><blockquote type="cite"><div class="gmail_quote">On Wed, Jun 6, 2012 at 3:08 AM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@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>On Wed, Jun 6, 2012 at 12:04 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 class="gmail_quote"><div>On Wed, Jun 6, 2012 at 2:57 AM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@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>Daniel & me have worked on a first proposal to provide an interface for clang formatting as part of the Tooling library.</div></blockquote><div><br></div></div><div>Please re-send the patch as an attachment? Email plays havoc w/ 80-columns. </div>



</div></blockquote><div><br></div></div><div>Done.</div></div></blockquote><div><br></div><div>Thanks!</div><div><br></div><div>I think it would help a lot to have a bit more code & context when evaluating this, even as a very early step.</div>


<div><br></div><div>My concrete suggestion would be this: implement a bozo-formatter. A completely trivial to implement, BS set of rules that only requires lexing. Then we can see the interface, a trivial implementation, and some test cases that use it. I think that'll make this much easier to review and really analyze. It also makes it much closer to something that could get checked in as a stepping stone</div>

</div></blockquote><div><br></div></div>Yes, please! In fact, I don't think we should even try to design the AnalyzableSource interface now, because we're not likely to know what we need until we have at least some basic formatting. </div>

</div></blockquote><div><br></div><div>The problem with doing no design on the AnalyzableSource interface yet is that we'll then need to pass in all kinds of stuff, like the SourceManager, FileManager etc (as we already have use cases where they're owned by a layer above it) and we need to control when to trigger parsing, and we also already have some known requirements on where we don't want to do it because it falls out of another step anyway.</div>

<div><br></div><div>Thus, if with "not trying to design" you mean "it's fine as proposed, but it might turn out very differently later", then I'm in full agreement. If you mean "we should just hand in everything we need", then I disagree.</div>

<div><br></div><div>Which is it? :)</div></div></blockquote><div><br></div></div><div>Either the first one or neither ;)</div><div><br></div>I don't think the AnalyzableSource abstraction belongs here at all, because the question of when to trigger parsing isn't the responsibility of the code formatting tool. The code formatting tool should do its formatting, and as it's doing so it should ask questions (through some abstract interface) about the semantics of particular tokens it encounters. If there happens to be, on the other side of that interface, something that does parsing to answer those questions, fine: that something can handle reparsing, and we can build up some separate infrastructure to do that.</div>
</div></blockquote><div><br></div><div>I think this is an important clarification, and I couldn't agree more. It will fundamentally solve the problem of post-refactoring-reformatting I think. As you refactor, you can re-build the information needed to satisfy these queries, potentially w/o rebuilding a complete AST. You can essentially pass in a somewhat customized implementation of the query interface to the formatter *specific* in its implementation to the refactoring performed, and able to look through that refactoring to the underlying AST and answer the queries.</div>
<div><br></div><div>Hmm, the interesting thing will be how do you query? You have to re-lex the code fragment (at least) in order to cope with edits, but then you don't have common tokens or source locations with the parse that led to the refactoring.</div>
<div><br></div><div>Anyways, I think these are interesting questions, but I agree that they will resolve as we build an actual formatter, even a fairly trivial one.</div></div>