libexpr: deprecate the bogus "or"-as-variable #11560
Open
+79
−8
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
As a prelude to making
or
work like a normal variable, emit a warning any time thefn 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 toexpr_simple
, and the cursed ExprCall production that is currently part of theexpr_select
nonterminal will be generated "normally" inexpr_app
instead. Any productions that accept anexpr_select
will be affected, except for theexpr_app
nonterminal itself (because, whileexpr_app
has a production accepting a bareexpr_select
, its other production will continue to acceptfn or
expressions). So all we need to do is emit an appropriate warning when anexpr_simple
representing a cursed ExprCall is accepted in one of those productions without first going throughexpr_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 asf (g or)
; similarly[ x y or ]
can be rewritten as[ x (y or) ]
, etc. The parentheses preserve the current grouping behavior, as in the futuref g or
will be parsed as(f g) or
, just likef g anything-else
is grouped. (Mechanically, this suppresses the warning because the problem ExprCalls go through theexpr_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.