Closed blindFS closed 2 weeks ago
BTW, I don't know whether this is desired:
But it makes unquoted strings easier to parse and current grammar works in the same way.
If so, _expr_unary_minus
doesn't make much sense then.
Is you screenshot the "before" or "after" this PR?
x is supposed to be a string here
❯ {k: a}
╭───┬───╮
│ k │ a │
╰───┴───╯
❯ {k: a} | describe -d | table -e
╭─────────┬────────────────╮
│ type │ record │
│ │ ╭───┬────────╮ │
│ columns │ │ k │ string │ │
│ │ ╰───┴────────╯ │
╰─────────┴────────────────╯
@fdncred The screenshot with error is before this PR, should be fine after this.
(nu_script [0, 0] - [3, 0]
(pipeline [0, 0] - [3, 0]
(pipe_element [0, 0] - [2, 1]
(val_record [0, 0] - [2, 1]
(record_body [1, 2] - [2, 0]
entry: (record_entry [1, 2] - [1, 8]
key: (identifier [1, 2] - [1, 3])
value: (val_string [1, 5] - [1, 8])))))))
_expr_unary_minus
however is left as it was, which is not exactly current nushell's behaviour. It's not related to $.val_record, just some random stuff found during the code cleansing.
Thanks
This PR fixes situations where record value is an unquoted string
Also cleaned list_entry rule a little bit since signed numbers, flags and unquoted string start with
+/-
are more easy to distinguish.