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
18 lines
435 B
Rust
18 lines
435 B
Rust
#[macro_use]
|
|
extern crate derive_is_enum_variant;
|
|
|
|
mod errors;
|
|
mod lex;
|
|
mod parse;
|
|
mod path;
|
|
mod scope;
|
|
mod shapes;
|
|
mod signature;
|
|
|
|
pub use lex::{block, lex, LiteBlock, LiteCommand, LiteGroup, LitePipeline};
|
|
pub use parse::{classify_block, garbage, parse, parse_full_column_path, parse_math_expression};
|
|
pub use path::expand_ndots;
|
|
pub use scope::ParserScope;
|
|
pub use shapes::shapes;
|
|
pub use signature::{Signature, SignatureRegistry};
|