`case:` does not have any effect within nested expressions

[isker]

Here are some input query strings and the results of parsing them. case: seems to not have any effect on the parsed query unless it's in the top-level expression.

foo bar -> (and substr:"foo" substr:"bar")
foo bar case:yes -> (and case_substr:"foo" case_substr:"bar")
foo bar case:no -> (and substr:"foo" substr:"bar")

foo or bar -> (or substr:"foo" substr:"bar")
foo or bar case:yes -> (or case_substr:"foo" case_substr:"bar") 
foo or bar case:no -> (or substr:"foo" substr:"bar") 

# `case:` does nothing if not at the top level.
(foo case:yes) bar -> (and substr:"foo" substr:"bar")
(case:yes foo) bar -> (and substr:"foo" substr:"bar")
(case:yes foo (bar)) -> (and substr:"foo" substr:"bar")

case: has special "application" logic (as it only modifies other expressions instead of doing anything on its own) and I suspect there is something wrong with it in that regard:

zoekt/query/parse.go

Lines 322 to 339 in 2560773

	for _, q := range qs {
	switch s := q.(type) {
	case *caseQ:
	setCase = s.Flavor
	case *Type:
	if s.Type < typeT {
	typeT = s.Type
	}
	default:
	newQS = append(newQS, q)
	}
	}
	qs = mapQueryList(newQS, func(q Q) Q {
	if sc, ok := q.(setCaser); ok {
	sc.setCase(setCase)
	}
	return q
	})

I believe the problem is that the logic to identify caseQ expressions in that for-loop only iterates over top-level expressions. It needs to iterate the entire tree of expressions, with lower caseQs overriding higher ones.

(By that reasoning it may be that Type expressions have the same problem, but I don't really understand what those are supposed to do even normally 🌞.)