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

33 lines
923 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.36 (#3963)
2021-08-24 20:01:17 +02:00
version = "0.36.0"
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]
Use bigdecimal-rs patch (#3905) * Use bigdecimal-rs patch * fix nu-serde's bigdecimal dependency
2021-08-06 23:27:19 +02:00
bigdecimal = { package = "bigdecimal-rs", version = "0.2.1", 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"
Allow custom lib dir path for sourcing nu script libraries. (#3940) Given we can write nu scripts. As the codebase grows, splitting into many smaller nu scripts is necessary. In general, when we work with paths and files we seem to face quite a few difficulties. Here we just tackle one of them and it involves sourcing files that also source other nu files and so forth. The current working directory becomes important here and being on a different directory when sourcing scripts will not work. Mostly because we expand the path on the current working directory and parse the files when a source command call is done. For the moment, we introduce a `lib_dirs` configuration value and, unfortunately, introduce a new dependency in `nu-parser` (`nu-data`) to get a handle of the configuration file to retrieve it. This should give clues and ideas as the new parser engine continues (introduce a way to also know paths) With this PR we can do the following: Let's assume we want to write a nu library called `my_library`. We will have the code in a directory called `project`: The file structure will looks like this: ``` project/my_library.nu project/my_library/hello.nu project/my_library/name.nu ``` This "pattern" works well, that is, when creating a library have a directory named `my_library` and next to it a `my_library.nu` file. Filling them like this: ``` source my_library/hello.nu source my_library/name.nu ``` ``` def hello [] { "hello world" } ``` ``` def name [] { "Nu" end ``` Assuming this `project` directory is stored at `/path/to/lib/project`, we can do: ``` config set lib_dirs ['path/to/lib/project'] ``` Given we have this `lib_dirs` configuration value, we can be anywhere while using Nu and do the following: ``` source my_library.nu echo (hello) (name) ```
2021-08-26 09:04:04 +02:00
Bump to 0.36 (#3963)
2021-08-24 20:01:17 +02:00
nu-errors = { version = "0.36.0", path="../nu-errors" }
Allow custom lib dir path for sourcing nu script libraries. (#3940) Given we can write nu scripts. As the codebase grows, splitting into many smaller nu scripts is necessary. In general, when we work with paths and files we seem to face quite a few difficulties. Here we just tackle one of them and it involves sourcing files that also source other nu files and so forth. The current working directory becomes important here and being on a different directory when sourcing scripts will not work. Mostly because we expand the path on the current working directory and parse the files when a source command call is done. For the moment, we introduce a `lib_dirs` configuration value and, unfortunately, introduce a new dependency in `nu-parser` (`nu-data`) to get a handle of the configuration file to retrieve it. This should give clues and ideas as the new parser engine continues (introduce a way to also know paths) With this PR we can do the following: Let's assume we want to write a nu library called `my_library`. We will have the code in a directory called `project`: The file structure will looks like this: ``` project/my_library.nu project/my_library/hello.nu project/my_library/name.nu ``` This "pattern" works well, that is, when creating a library have a directory named `my_library` and next to it a `my_library.nu` file. Filling them like this: ``` source my_library/hello.nu source my_library/name.nu ``` ``` def hello [] { "hello world" } ``` ``` def name [] { "Nu" end ``` Assuming this `project` directory is stored at `/path/to/lib/project`, we can do: ``` config set lib_dirs ['path/to/lib/project'] ``` Given we have this `lib_dirs` configuration value, we can be anywhere while using Nu and do the following: ``` source my_library.nu echo (hello) (name) ```
2021-08-26 09:04:04 +02:00
nu-data = { version = "0.36.0", path="../nu-data" }
Bump to 0.36 (#3963)
2021-08-24 20:01:17 +02:00
nu-path = { version = "0.36.0", path="../nu-path" }
nu-protocol = { version = "0.36.0", path="../nu-protocol" }
nu-source = { version = "0.36.0", path="../nu-source" }
nu-test-support = { version = "0.36.0", 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 = []
Reference in New Issue Copy Permalink