<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 class="im"><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> </div><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>Personally, I think we can get fairly far with lexer-based formatting, and I think we should start there. From that, I hope that we can build a semantic interface that allows partial information to be useful, e.g., "is this identifier 'foo' at line 5, column before a '<' referring to a template name or not?". We can definitely answer with a parse, but we can also guess if we have a little knowledge of the names of templates in our system.</div>
</div></blockquote><div><br></div><div>That is one of the ideas. </div><div><br></div><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>Allowing the use of partial information is important because we'll probably want to use this code formatting tool even in places where getting an AST is either too expensive or not generally possible, e.g., within an editor.</div>
</div></blockquote><div><br></div><div>Ack.</div><div> </div><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 class="im"><blockquote type="cite">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Questions:</div><div>- please point out anything that might make this interface not viable for your own use cases</div>




<div>- are we missing the point somewhere?</div><div>- is Tooling/ the right place for this?</div></blockquote></div></div></div></blockquote></div></div></blockquote><div><br></div><div>I think Tooling is the right place because I think essentially every tool anyone writes will want to have *some* formatting applied to it. Leveraging this from an existing tool and composing cleanly w/ it will almost certainly be important.</div>
</div></blockquote><div><br></div></div><div>It seems more general than tooling. In particular, I'd like to expose this through libclang, which doesn't need any of the other tooling infrastructure. How about the Edit lib?</div>
</div></div></blockquote><div><br></div><div>I'm fine with that. Chandler?</div><div><br></div><div>Cheers,</div><div>/Manuel</div></div>