holm/nushell
1
1
Fork 0
forked from extern/nushell
Code Issues Pull Requests Packages Projects Releases Wiki Activity
1d0483c946
nushell/crates/nu-parser/Cargo.toml

32 lines
840 B
TOML
Raw Normal View History

Extract core stuff into own crates This commit extracts five new crates: - nu-source, which contains the core source-code handling logic in Nu, including Text, Span, and also the pretty.rs-based debug logic - nu-parser, which is the parser and expander logic - nu-protocol, which is the bulk of the types and basic conveniences used by plugins - nu-errors, which contains ShellError, ParseError and error handling conveniences - nu-textview, which is the textview plugin extracted into a crate One of the major consequences of this refactor is that it's no longer possible to `impl X for Spanned<Y>` outside of the `nu-source` crate, so a lot of types became more concrete (Value became a concrete type instead of Spanned<Value>, for example). This also turned a number of inherent methods in the main nu crate into plain functions (impl Value {} became a bunch of functions in the `value` namespace in `crate::data::value`).
2019-11-26 03:30:48 +01:00
[package]
Add experimental new parser (#1554) Move to an experimental new parser
2020-04-06 09:16:14 +02:00
authors = ["The Nu Project Contributors"]
Update Cargo.toml
2020-04-21 20:34:32 +02:00
description = "Nushell parser"
Bump to 0.16.1 (#2116)
2020-07-05 22:12:44 +02:00
edition = "2018"
Update Cargo.toml
2020-04-21 20:34:32 +02:00
license = "MIT"
Bump to 0.16.1 (#2116)
2020-07-05 22:12:44 +02:00
name = "nu-parser"
Bump to 0.33.1 (#3671)
2021-06-23 09:57:41 +02:00
version = "0.33.1"
Extract core stuff into own crates This commit extracts five new crates: - nu-source, which contains the core source-code handling logic in Nu, including Text, Span, and also the pretty.rs-based debug logic - nu-parser, which is the parser and expander logic - nu-protocol, which is the bulk of the types and basic conveniences used by plugins - nu-errors, which contains ShellError, ParseError and error handling conveniences - nu-textview, which is the textview plugin extracted into a crate One of the major consequences of this refactor is that it's no longer possible to `impl X for Spanned<Y>` outside of the `nu-source` crate, so a lot of types became more concrete (Value became a concrete type instead of Spanned<Value>, for example). This also turned a number of inherent methods in the main nu crate into plain functions (impl Value {} became a bunch of functions in the `value` namespace in `crate::data::value`).
2019-11-26 03:30:48 +01:00
[dependencies]
Bump to 0.33 (#3667)
2021-06-22 07:22:33 +02:00
bigdecimal = { version="0.2.0", features=["serde"] }
updated dependencies (#2857) Same as #2786 Co-authored-by: sousajo <sousajo@pop-os.localdomain> Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
2021-01-07 01:38:22 +01:00
codespan-reporting = "0.11.0"
Bump to 0.16.1 (#2116)
2020-07-05 22:12:44 +02:00
derive-new = "0.5.8"
Bump to 0.25.2 (#2908)
2021-01-11 19:50:53 +01:00
derive_is_enum_variant = "0.1.1"
Bump to 0.33 (#3667)
2021-06-22 07:22:33 +02:00
indexmap = { version="1.6.1", features=["serde-1"] }
Update some deps (#3011)
2021-02-05 21:54:54 +01:00
log = "0.4"
Bump to 0.33 (#3667)
2021-06-22 07:22:33 +02:00
num-bigint = { version="0.3.1", features=["serde"] }
Document lexer (#2865) * Update dependencies * Document the lexer and lightly improve its names The bulk of this pull request adds a substantial amount of new inline documentation for the lexer. Along the way, I made a few minor changes to the names in the lexer, most of which were internal. The main change that affects other files is renaming `group` to `block`, since the function is actually parsing a block (a list of groups). * Fix rustfmt * Update lock Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com> Co-authored-by: Jonathan Turner <jonathan.d.turner@gmail.com>
2021-01-07 04:03:00 +01:00
num-traits = "0.2.14"
Update some deps (#3011)
2021-02-05 21:54:54 +01:00
serde = "1.0"
Clean up lexer (#2956) * Document the lexer and lightly improve its names The bulk of this pull request adds a substantial amount of new inline documentation for the lexer. Along the way, I made a few minor changes to the names in the lexer, most of which were internal. The main change that affects other files is renaming `group` to `block`, since the function is actually parsing a block (a list of groups). * Further clean up the lexer - Consolidate the logic of the various token builders into a single type - Improve and clean up the event-driven BlockParser - Clean up comment parsing. Comments now contain their original leading whitespace as well as trailing whitespace, and know how to move some leading whitespace back into the body based on how the lexer decides to dedent the comments. This preserves the original whitespace information while still making it straight-forward to eliminate leading whitespace in help comments. * Update meta.rs * WIP * fix clippy * remove unwraps * remove unwraps Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com> Co-authored-by: Jonathan Turner <jonathan.d.turner@gmail.com>
2021-02-04 08:20:21 +01:00
itertools = "0.10.0"
smart-default = "0.6.0"
Extract build.rs
2019-12-02 22:14:51 +01:00
Feature/def signature with comments (#2905) * 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
2021-01-11 18:53:58 +01:00
dunce = "1.0.1"
Bump to 0.33.1 (#3671)
2021-06-23 09:57:41 +02:00
nu-errors = { version="0.33.1", path="../nu-errors" }
nu-path = { version="0.33.1", path="../nu-path" }
nu-protocol = { version="0.33.1", path="../nu-protocol" }
nu-source = { version="0.33.1", path="../nu-source" }
nu-test-support = { version="0.33.1", path="../nu-test-support" }
Clean up expansion of external words Previously, external words accidentally used ExpansionRule::new().allow_external_command(), when it should have been ExpansionRule::new().allow_external_word(). External words are the broadest category in the parser, and are the appropriate category for external arguments. This was just a mistake.
2019-12-03 01:34:33 +01:00
[features]
Remove the coloring_in_tokens feature flag Stabilize and enable
2019-12-12 06:56:12 +01:00
stable = []
Add experimental new parser (#1554) Move to an experimental new parser
2020-04-06 09:16:14 +02:00
trace = []
Reference in New Issue Copy Permalink