<div dir="ltr"><div dir="ltr">On Thu, Mar 26, 2020 at 7:02 PM <<a href="mailto:alex@lanin.de">alex@lanin.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="DE"><div class="gmail-m_7285926340142906514WordSection1"><p class="MsoNormal"><span>Hi,<u></u><u></u></span></p><p class="MsoNormal"><span><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">If I understand the concept correctly, currently many checkers rely on parsing a few relevant tokens themselves.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">Potentially with the help of some utils/helpers that simplify the checker like the one I’m trying to introduce (see other mail).<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">With TokenBuffer/SyntaxTree, parsing is no longer needed for some/most checkers.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">TokenBuffer/SyntaxTree would abstract “one step further” then e.g. LexerUtils and provide an enhanced/specialized AST.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">However it’s not used that widely throughout llvm.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">Is it new and the way to go?</span></p></div></div></blockquote><div>TokenBuffer is pretty robust, we're using it heavily in clangd. It may have some incomplete parts. This is one step up from LexerUtils.</div><div>Syntax tree is new and ... not finished yet :-) This is a second step up.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="DE"><div class="gmail-m_7285926340142906514WordSection1"><p class="MsoNormal"><span lang="EN-US"> Do you expect clang-tidy checkers to rely on the SyntaxTree in the future?</span></p></div></div></blockquote><div>I don't know, if it gets nicely finished I think it'd be very useful for rewriting code (i.e. checker fixes). But I don't know anyone actively working on it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="DE"><div class="gmail-m_7285926340142906514WordSection1"><p class="MsoNormal"><span lang="EN-US"><u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">It does indeed provide e.g. a BreakStatement which does exactly what I did by introducing a method into LexerUtils.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">Alex<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><b>Von:</b> Sam McCall <<a href="mailto:sammccall@google.com" target="_blank">sammccall@google.com</a>> <br><b>Gesendet:</b> Donnerstag, 26. März 2020 01:08<br><b>An:</b> <a href="mailto:alex@lanin.de" target="_blank">alex@lanin.de</a><br><b>Cc:</b> Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>; John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>><br><b>Betreff:</b> Re: [cfe-dev] Extend Stmt with proper end location?<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Tue, Mar 17, 2020 at 6:11 AM John McCall via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p></div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><div><div><div><p><span style="font-family:Arial,sans-serif">Furthermore, I think expressions are important to consider,<u></u><u></u></span></p></div><div><p><span style="font-family:Arial,sans-serif">because the practical limitations on finding the semicolon after<br>an expression are exactly the same as finding it after </span><code><span style="font-size:10pt;color:black;background:rgb(247,247,247)">break</span></code><span style="font-family:Arial,sans-serif">.<u></u><u></u></span></p></div></div></div></blockquote><div><p class="MsoNormal">To spell this out a little more: formally in `foo();` there's an expression-statement which consists of a the call expression and the semicolon. But clang just uses the CallExpr node to represent both, and CallExpr obviously(?) shouldn't include the semicolon in its source range.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Alex: I think the Syntax library might be more suitable for tasks that need this precise info such as refactoring (and it doesn't suffer in the same way from the multiple masters problem). Unfortunately it's not complete.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">The clang::syntax::TokenBuffer class allows you to capture the expanded token stream (bounds and kind of every token) as the parse runs (using TokenCollector). Effectively this lets you opt into making clang record more token-level info at the cost of memory. You then have to poke at this token stream yourself to find the semicolons you're after.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">The rest of the Syntax library ("syntax trees") uses a clang AST to build up a true syntactic (grammar-based) tree out of these tokens. "TEST_F(SyntaxTreeTest, While)" in TreeTest.cpp shows how this includes the semicolons of the (grammatical) BreakStatement.<u></u><u></u></p></div><div><p class="MsoNormal">The plan is/was to make it easy to then map between semantic and syntactic nodes, e.g. AST BreakStmt to the corresponding syntax BreakStatement. This hasn't been implemented yet I think.<u></u><u></u></p></div></div></div></div></div></blockquote></div></div>