Support the implicit "-a" in find

[danw]

The find man page says that "expression expression" is equivalent to "expression -a expression".

This reduces the number of shell commands we need to run during regen check of one of the internal android trees by ~10%, which reduced the time spent in regen checking by ~60%.

before: *kati*: shell time (regen): 5.842119 / 516
after:  *kati*: shell time (regen): 2.377083 / 462

[shinh]

The speed up sounds great! IIRC there was no expr expr-style find which consume a lot of time. Perhaps this style was introduced in new code? Anyway, it could be worth considering to disallow find commands which cannot be handled by kati?

Please feel free to merge this as is. The patch itself looks good to me, but I'd prefer code which doesn't have extra check for the first token of <fact>.

[shinh]

Checking if the next token is a prefix of <fact> would work now but in future it can be broken when the definition of <fact> has changed. Maybe better to do something like the following? I'm not very sure if my code works, but I think we shouldn't need two checks for "-not", "\\!", etc.

diff --git a/find.cc b/find.cc
index 1b9e23f..18450d0 100644
--- a/find.cc
+++ b/find.cc
@@ -526,15 +526,20 @@ class FindCommandParser {
     while (true) {
       if (!GetNextToken(&tok))
         return NULL;
-      if (tok != "-and" && tok != "-a") {
-        UngetToken(tok);
-        return c.release();
+      bool has_and = false;
+      if (tok == "-and" || tok == "-a") {
+        has_and = true;
+        if (!GetNextToken(&tok) || tok.empty())
+          return NULL;
       }
-      if (!GetNextToken(&tok) || tok.empty())
-        return NULL;
       unique_ptr<FindCond> r(ParseFact(tok));
       if (!r.get()) {
-        return NULL;
+        if (has_and) {
+          return NULL;
+        } else {
+          UngetToken(tok);
+          return c.release();
+        }
       }
       c.reset(new AndCond(c.release(), r.release()));
     }

[danw]

I had tried something similar, but ParseFact doesn't differentiate between an error and the token not being a fact. And that was necessary in order to parse things properly.

[danw]

The most expensive case (~1.5 seconds on it's own) was new. I'm looking into exposing the unsupported find cases as warnings, with an option to turn them into errors. We've still got a bunch of these though, so I need to figure out whether to fix Kati or fix the source.

I've already fixed the 6 instances that used | sort, which I could have implemented in Kati, but since we only had 6 instances, I just fixed the calls.