This was parsed as AND before, it's now just joining filters, is it strictly equivalent?
Yes, both for AQS:
[<query> ::= <query> <query> // Same as <query> AND <query>](https://learn.microsoft.com/en-us/windows/win32/search/-search-3x-advancedqu...)
and `DEVPROP_FILTER_EXPRESSION`:
[If a filter expression does not contain any logical operators specifying how to combine different comparison clauses, then the filter expression assumes that a logical AND should be performed.](https://learn.microsoft.com/en-us/windows/win32/api/devfiltertypes/ns-devfil....)
If the returned filter array structure isn't so important, maybe it'd be simpler to reuse an AND expression here and avoid the extra helper?
Because our devquery implementation does not support explicit boolean operators right now, I figured this would at least let us support implicit compound queries that we test for in `filters_simple` and `filters_no_results`.
I don't see any check on the parsed filters but I guess they only accessible through the undocumented `AqsToDevQueryFilter`?
Yes, I believe the only documented way to parse AQS is to use `IQueryParser` in `structuredquery.h`, which has its own AST types instead of `DEVPROP_FILTER_EXPRESSION`. The devquery APIs will still validate the generated filter expression, though.
What about precedence rules in the filter array, if you have `expr expr OR expr` for instance?
Yes, there is a shift/reduce conflict for queries of the type `NOT expr expr`, `expr expr OR expr` and `expr OR expr expr`. The AQS docs say that all operations bind from left to right, which conflicts with Bison's default approach of performing a shift. Adding explicit rules fixes them, but since we don't support boolean operators anyway, IMO it only makes sense to add that in future MRs. However, I have added a few tests to demonstrate the precedence rules.