libexpr: deprecate the bogus "or"-as-variable

[rhendric]

Motivation

As a prelude to making or work like a normal variable, emit a warning any time the fn or production is used in a context that will change how it is parsed when that production is refactored.

In detail: in the future, OR_KW will be moved to expr_simple, and the cursed ExprCall production that is currently part of the expr_select nonterminal will be generated "normally" in expr_app instead. Any productions that accept an expr_select will be affected, except for the expr_app nonterminal itself (because, while expr_app has a production accepting a bare expr_select, its other production will continue to accept fn or expressions). So all we need to do is emit an appropriate warning when an expr_simple representing a cursed ExprCall is accepted in one of those productions without first going through expr_app.

As the warning message describes, users can suppress the warning by wrapping their problematic fn or expressions in parentheses. For example, f g or can be made future-proof by rewriting it as f (g or); similarly [ x y or ] can be rewritten as [ x (y or) ], etc. The parentheses preserve the current grouping behavior, as in the future f g or will be parsed as (f g) or, just like f g anything-else is grouped. (Mechanically, this suppresses the warning because the problem ExprCalls go through the expr_app : expr_select production, which resets the cursed status on the ExprCall.)

Context

Forked from #11121, which will be rebased atop this once it is merged and then sit around for however many years it's decided is an appropriate deprecation period.

Priorities and Process

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.