On Wed Sep 17 12:09:43 2025 +0000, Vibhav Pant wrote:
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.
Hmm, it still doesn't seem good to have two different ways to express an AND, one supported and one not, when both are supposed to be equivalent.
Maybe boolean expressions should be supported first, or maybe we should only support parsing AND (explicit or not) for now, with the joined filters.