mirror of
https://github.com/nushell/nushell.git
synced 2025-04-21 19:58:21 +02:00
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> This PR adds type checking of all command input types at run-time. Generally, these errors should be caught by the parser, but sometimes we can't know the type of a value at parse-time. The simplest example is using the `echo` command, which has an output type of `any`, so prefixing a literal with `echo` will bypass parse-time type checking. Before this PR, each command has to individually check its input types. This can result in scenarios where the input/output types don't match the actual command behavior. This can cause valid usage with an non-`any` type to become a parse-time error if a command is missing that type in its pipeline input/output (`drop nth` and `history import` do this before this PR). Alternatively, a command may not list a type in its input/output types, but doesn't actually reject that type in its code, which can have unintended side effects (`get` does this on an empty pipeline input, and `sort` used to before #13154). After this PR, the type of the pipeline input is checked to ensure it matches one of the input types listed in the proceeding command's input/output types. While each of the issues in the "before this PR" section could be addressed with each command individually, this PR solves this issue for _all_ commands. **This will likely cause some breakage**, as some commands have incorrect input/output types, and should be adjusted. Also, some scripts may have erroneous usage of commands. In writing this PR, I discovered that `toolkit.nu` was passing `null` values to `str join`, which doesn't accept nothing types (if folks think it should, we can adjust it in this PR or in a different PR). I found some issues in the standard library and its tests. I also found that carapace's vendor script had an incorrect chaining of `get -i`: ```nushell let expanded_alias = (scope aliases | where name == $spans.0 | get -i 0 | get -i expansion) ``` Before this PR, if the `get -i 0` ever actually did evaluate to `null`, the second `get` invocation would error since `get` doesn't operate on `null` values. After this PR, this is immediately a run-time error, alerting the user to the problematic code. As a side note, we'll need to PR this fix (`get -i 0 | get -i expansion` -> `get -i 0.expansion`) to carapace. A notable exception to the type checking is commands with input type of `nothing -> <type>`. In this case, any input type is allowed. This allows piping values into the command without an error being thrown. For example, `123 | echo $in` would be an error without this exception. Additionally, custom types bypass type checking (I believe this also happens during parsing, but not certain) I added a `is_subtype` method to `Value` and `PipelineData`. It functions slightly differently than `get_type().is_subtype()`, as noted in the doccomments. Notably, it respects structural typing of lists and tables. For example, the type of a value `[{a: 123} {a: 456, b: 789}]` is a subtype of `table<a: int>`, whereas the type returned by `Value::get_type` is a `list<any>`. Similarly, `PipelineData` has some special handling for `ListStream`s and `ByteStream`s. The latter was needed for this PR to work properly with external commands. Here's some examples. Before: ```nu 1..2 | drop nth 1 Error: nu::parser::input_type_mismatch × Command does not support range input. ╭─[entry #9:1:8] 1 │ 1..2 | drop nth 1 · ────┬─── · ╰── command doesn't support range input ╰──── echo 1..2 | drop nth 1 # => ╭───┬───╮ # => │ 0 │ 1 │ # => ╰───┴───╯ ``` After this PR, I've adjusted `drop nth`'s input/output types to accept range input. Before this PR, zip accepted any value despite not being listed in its input/output types. This caused different behavior depending on if you triggered a parse error or not: ```nushell 1 | zip [2] # => Error: nu::parser::input_type_mismatch # => # => × Command does not support int input. # => ╭─[entry #3:1:5] # => 1 │ 1 | zip [2] # => · ─┬─ # => · ╰── command doesn't support int input # => ╰──── echo 1 | zip [2] # => ╭───┬───────────╮ # => │ 0 │ ╭───┬───╮ │ # => │ │ │ 0 │ 1 │ │ # => │ │ │ 1 │ 2 │ │ # => │ │ ╰───┴───╯ │ # => ╰───┴───────────╯ ``` After this PR, it works the same in both cases. For cases like this, if we do decide we want `zip` or other commands to accept any input value, then we should explicitly add that to the input types. ```nushell 1 | zip [2] # => Error: nu::parser::input_type_mismatch # => # => × Command does not support int input. # => ╭─[entry #3:1:5] # => 1 │ 1 | zip [2] # => · ─┬─ # => · ╰── command doesn't support int input # => ╰──── echo 1 | zip [2] # => Error: nu:🐚:only_supports_this_input_type # => # => × Input type not supported. # => ╭─[entry #14:2:6] # => 2 │ echo 1 | zip [2] # => · ┬ ─┬─ # => · │ ╰── only list<any> and range input data is supported # => · ╰── input type: int # => ╰──── ``` # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> **Breaking change**: The type of a command's input is now checked against the input/output types of that command at run-time. While these errors should mostly be caught at parse-time, in cases where they can't be detected at parse-time they will be caught at run-time instead. This applies to both internal commands and custom commands. Example function and corresponding parse-time error (same before and after PR): ```nushell def foo []: int -> nothing { print $"my cool int is ($in)" } 1 | foo # => my cool int is 1 "evil string" | foo # => Error: nu::parser::input_type_mismatch # => # => × Command does not support string input. # => ╭─[entry #16:1:17] # => 1 │ "evil string" | foo # => · ─┬─ # => · ╰── command doesn't support string input # => ╰──── # => ``` Before: ```nu echo "evil string" | foo # => my cool int is evil string ``` After: ```nu echo "evil string" | foo # => Error: nu:🐚:only_supports_this_input_type # => # => × Input type not supported. # => ╭─[entry #17:1:6] # => 1 │ echo "evil string" | foo # => · ──────┬────── ─┬─ # => · │ ╰── only int input data is supported # => · ╰── input type: string # => ╰──── ``` Known affected internal commands which erroneously accepted any type: * `str join` * `zip` * `reduce` # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> * Play whack-a-mole with the commands and scripts this will inevitably break
128 lines
2.8 KiB
Rust
128 lines
2.8 KiB
Rust
use nu_test_support::{nu, pipeline};
|
|
|
|
#[test]
|
|
fn reduce_table_column() {
|
|
let actual = nu!(pipeline(
|
|
r#"
|
|
echo "[{month:2,total:30}, {month:3,total:10}, {month:4,total:3}, {month:5,total:60}]"
|
|
| from json
|
|
| get total
|
|
| reduce --fold 20 { |it, acc| $it + $acc ** 1.05}
|
|
| into string -d 1
|
|
"#
|
|
));
|
|
|
|
assert_eq!(actual.out, "180.6");
|
|
}
|
|
|
|
#[test]
|
|
fn reduce_table_column_with_path() {
|
|
let actual = nu!(pipeline(
|
|
"
|
|
[{month:2,total:30}, {month:3,total:10}, {month:4,total:3}, {month:5,total:60}]
|
|
| reduce --fold 20 { |it, acc| $it.total + $acc ** 1.05}
|
|
| into string -d 1
|
|
"
|
|
));
|
|
|
|
assert_eq!(actual.out, "180.6");
|
|
}
|
|
|
|
#[test]
|
|
fn reduce_rows_example() {
|
|
let actual = nu!(pipeline(
|
|
"
|
|
[[a,b]; [1,2] [3,4]]
|
|
| reduce --fold 1.6 { |it, acc| $acc * ($it.a | into int) + ($it.b | into int) }
|
|
"
|
|
));
|
|
|
|
assert_eq!(actual.out, "14.8");
|
|
}
|
|
|
|
#[test]
|
|
fn reduce_with_return_in_closure() {
|
|
let actual = nu!(pipeline(
|
|
"
|
|
[1, 2] | reduce --fold null { |it, state|
|
|
if $it == 1 {
|
|
return 10
|
|
};
|
|
return ($it * $state)
|
|
}
|
|
"
|
|
));
|
|
|
|
assert_eq!(actual.out, "20");
|
|
assert!(actual.err.is_empty());
|
|
}
|
|
|
|
#[test]
|
|
fn reduce_enumerate_example() {
|
|
let actual = nu!(pipeline(
|
|
"
|
|
echo one longest three bar | enumerate
|
|
| reduce { |it, acc| if ($it.item | str length) > ($acc.item | str length) {echo $it} else {echo $acc}}
|
|
| get index
|
|
"
|
|
));
|
|
|
|
assert_eq!(actual.out, "1");
|
|
}
|
|
|
|
#[test]
|
|
fn reduce_enumerate_integer_addition_example() {
|
|
let actual = nu!(pipeline(
|
|
"
|
|
echo [1 2 3 4]
|
|
| enumerate
|
|
| reduce { |it, acc| { index: ($it.index) item: ($acc.item + $it.item)} }
|
|
| get item
|
|
"
|
|
));
|
|
|
|
assert_eq!(actual.out, "10");
|
|
}
|
|
|
|
#[test]
|
|
fn folding_with_tables() {
|
|
let actual = nu!(pipeline(
|
|
"
|
|
echo [10 20 30 40]
|
|
| reduce --fold [] { |it, acc|
|
|
with-env { value: $it } {
|
|
echo $acc | append (10 * ($env.value | into int))
|
|
}
|
|
}
|
|
| math sum
|
|
"
|
|
));
|
|
|
|
assert_eq!(actual.out, "1000");
|
|
}
|
|
|
|
#[test]
|
|
fn error_reduce_fold_type_mismatch() {
|
|
let actual = nu!(pipeline(
|
|
"echo a b c | reduce --fold 0 { |it, acc| $acc + $it }"
|
|
));
|
|
|
|
assert!(actual.err.contains("mismatch"));
|
|
}
|
|
|
|
#[test]
|
|
fn error_reduce_empty() {
|
|
let actual = nu!(pipeline("reduce { |it, acc| $acc + $it }"));
|
|
|
|
assert!(actual.err.contains("no input value was piped in"));
|
|
}
|
|
|
|
#[test]
|
|
fn enumerate_reduce_example() {
|
|
let actual = nu!(pipeline(
|
|
"[one longest three bar] | enumerate | reduce {|it, acc| if ($it.item | str length) > ($acc.item | str length) { $it } else { $acc }} | get index"
|
|
));
|
|
|
|
assert_eq!(actual.out, "1");
|
|
}
|