to followup on a comment i made in that email thread...
The sanest thing to do would probably be to make parseFunction construct a
local instance of FunctionQParser (with a null SolrQueryRequest) instead
of using QParser.getParser(...). that should be fairly close to the way
it worked in older versions
(hmmm... except FunctionQParser does something similar to get a
ValueSourceParser ... a new constructor for FunctionQParser that
explicitly tells it to use ValueSourceParser.standardValueSourceParsers
might be in order).
I think it goes without saying that QueryParsing.parseFunction should be
deprecated as well ... fortunately it's only used in a few places in the
core code ... unfortunately those places also don't currently have access
to a SolrQueryRequest at the moment:
1) SolrPluginUtils.parseFuncs – should probably be deprecated, callers
of it should start using the QParser APIs.
2) SolrQueryParser.getFieldQuery – it's only used if the
SolrQueryParser was constructed with an IndexSchema and not with a QParser
(in which case it can ask the QParser for a subParser) .. the IndexSchema
constructor should probably be deprecated as well (but i haven't dug in to
see how far down the rabit hole that change would go)
If we gave FunctionQParser a constructor that took in an IndexSchema instead of a SolrQueryRequest, then that new constructor could be used by both QueryParsing.parseFunction and SolrQueryParser.getFieldQuery and – we'd still need to use the ValueSourceParser.standardValueSourceParsers as well, but that would be better then picking the ones declared arbitrarily in the last core.