Ping (+dgregor, who promised to take a look on irc ;)
On Tue, Jun 19, 2012 at 11:14 AM, Manuel Klimek <[email protected]> wrote: > On Tue, Jun 19, 2012 at 10:59 AM, Stephen Kelly <[email protected]>wrote: > >> Manuel Klimek wrote: >> >> > ... one of the final pieces that we have in the tooling branch are the >> AST >> > matchers. >> > >> > The main user interface is in ASTMatchers.h and ASTMatchFinder.h. >> >> Hi, >> >> There are some case mis-matches between documentation and implementation >> with Has/has forEach/ForEach and hasDescendant/HasDescendant, >> forEachDescendant: >> > > Yep, this is a known problem, and related to the bikeshedding about > whether we want the matcher creator functions to be lower-case or > upper-case first letter. I don't want to switch back and forth a few times, > so I'd like to get a decision, switch to that decision, and clean up all > references ;) > > >> +/// Example matches X, Y (matcher = Class(Has(Class(HasName("X"))) >> ... >> +template <typename ChildT> >> +internal::ArgumentAdaptingMatcher<internal::HasMatcher, ChildT> has( >> >> Apart from that I think it's a good start. Is it considered experimental >> or >> 'stable' in any way, or is it allowed to change in any way at all (source >> incompatibly)? >> > > We're using it for 1.5 years without significant changes to the API. I > consider it pretty stable at this point. > > >> I think there may be a need for some more high-level documentation, but >> that >> could also come later if the API is 'experimental' at this point. The >> scope >> of expected use might also be worth defining. >> > > I'm planning to start writing more docs the moment this lands (like I did > for the tooling parts). > > >> Is it primarily for non-standard, complex problems and one-time-use tools >> (like solving Googles problems), or is it primarily for creation of >> sharable >> tools which can operate on any codebase (like an accurate, >> medium/long-term >> maintained porting tool or other medium-term maintained tools)? >> > > Both :) For the complex problems it's pretty much "good to go as is", as > the productivity of creating the tool is often not the biggest concern - > getting the changes tested and checked in uses up much more of an > engineer's time. > > We're also in the process of starting to write sharable tools based on > this. > > >> I consider this a documentation problem because I think there are ways to >> make the tool I created faster by storing information about compilations >> before doing the porting. Currently I use 'git grep' to find potential >> > > Well, at Google we just use more cores. I am aware that that's not a good > solution for everybody, and am open to suggestions. > > For llvm I am able to run over all translation units with xargs -n1 -P12 > pretty quickly on a 6-core hyperthreading machine. > > >> porting cases, which means that I might needlessly be compiling certain >> TUs >> multiple times because of a text match but not a semantic match. >> >> https://github.com/KDAB/Qt4to5/blob/master/portqt4to5.py >> >> I think this is something Chandler also mentioned there was a solution for >> in his talk (that Google records lots of information from compiles). >> >> I don't expect all of that to be in this patch of course, but it would be >> interesting to confirm that that's the kind of things that are in scope >> and >> can be added in the future. >> >> Given the extensive comments, unit tests, and the fact that I've also used >> this API a bit, I support applying this patch. >> > > Thanks! > /Manuel >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
