forked from extern/nushell
3e6e3a207c
* Put parse_definition related funcs into own module * Add failing lexer test * Implement Parsing of definition signature This commit applied changes how the signature of a function is parsed. Before there was a little bit of "quick-and-dirty" string-matching/parsing involved. Now, a signature is a little bit more properly parsed. The grammar of a definition signature understood by these parsing-functions is as follows: `[ (parameter | flag | <eol>)* ]` where parameter is: `name (<:> type)? (<,> | <eol> | (#Comment <eol>))?` flag is: `--name (-shortform)? (<:> type)? (<,> | <eol> | (#Comment <eol>))?` (Note: After the last item no <,> has to come.) Note: It is now possible to pass comments to flags and parameters Example: [ d:int # The required d parameter --x (-x):string # The all powerful x flag --y (-y):int # The accompanying y flag ] (Sadly there seems to be a bug (Or is this expected behaviour?) in the lexer, because of which `--x(-x)` would be treated as one baseline token and is therefore not correctly recognized as 2. For now a space has to be inserted) During the implementation of the module, 2 question arose: Should flag/parameter names be allowed to be type names? Example case: ```shell def f [ string ] { echo $string } ``` Currently an error is thrown * Fix clippy lints * Remove wrong comment * Add spacing * Add Cargo.lock |
||
---|---|---|
.. | ||
nu_plugin_binaryview | ||
nu_plugin_chart | ||
nu_plugin_fetch | ||
nu_plugin_from_bson | ||
nu_plugin_from_sqlite | ||
nu_plugin_inc | ||
nu_plugin_match | ||
nu_plugin_post | ||
nu_plugin_ps | ||
nu_plugin_s3 | ||
nu_plugin_selector | ||
nu_plugin_start | ||
nu_plugin_sys | ||
nu_plugin_textview | ||
nu_plugin_to_bson | ||
nu_plugin_to_sqlite | ||
nu_plugin_tree | ||
nu_plugin_xpath | ||
nu-cli | ||
nu-data | ||
nu-engine | ||
nu-errors | ||
nu-json | ||
nu-parser | ||
nu-plugin | ||
nu-protocol | ||
nu-source | ||
nu-stream | ||
nu-table | ||
nu-test-support | ||
nu-value-ext |