mirror of
https://github.com/NixOS/nix
synced 2024-10-18 14:32:45 -04:00
da332d678e
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.)
12 lines
372 B
Nix
12 lines
372 B
Nix
let
|
|
# These are cursed and should warn
|
|
cursed0 = builtins.length (let or = 1; in [ (x: x) or ]);
|
|
cursed1 = let or = 1; in (x: x * 2) (x: x + 1) or;
|
|
cursed2 = let or = 1; in { a = 2; }.a or (x: x) or;
|
|
|
|
# These are uses of `or` as an identifier that are not cursed
|
|
allowed0 = let or = (x: x); in map or [];
|
|
allowed1 = let f = (x: x); or = f; in f (f or);
|
|
in
|
|
0
|