Make completers sort while fetching by ysthakur · Pull Request #3 · ysthakur/nushell

ysthakur · 2024-06-23T16:35:44Z

Description

This is just to trigger workflows. Make completers sort while fetching so that completions for files/directories can be sorted taking path segments into account (rather than treating the entire path as a single string).

User-Facing Changes

Tests + Formatting

After Submitting

Previously, there was a separate sort() method for completers, but it's better to let them sort while fetching themselves, so that completions for nested directories don't include slashes when sorting (they can sort by the first component of the path, then the second, then so on)

Used by command, custom, flag, and variable completions

…ll#13541) # Description When using a format string, `into datetime` would disallow an `int` even when it logically made sense. This was mainly a problem when attempting to convert a Unix epoch to Nushell `datetime`. Unix epochs are often stored or returned as `int` in external data sources. ```nu 1722821463 | into datetime -f '%s' Error: nu::shell::only_supports_this_input_type × Input type not supported. ╭─[entry #3:1:1] 1 │ 1722821463 | into datetime -f '%s' · ─────┬──── ──────┬────── · │ ╰── only string input data is supported · ╰── input type: int ╰──── ``` While the solution was simply to `| to text` the `int`, this PR handles the use-case automatically. Essentially a ~5 line change that just moves the current parsing to a closure that is called for both Strings and Ints-converted-to-Strings. # User-Facing Changes After the change: ```nu [ 1722821463 "1722821463" 0 ] | each { into datetime -f '%s' } ╭───┬──────────────╮ │ 0 │ 10 hours ago │ │ 1 │ 10 hours ago │ │ 2 │ 54 years ago │ ╰───┴──────────────╯ ``` # Tests + Formatting Test case added. - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting

nushell#13585) # Description As per our Wednesday meeting, this adds a parse error when something that would be parsed as an external call is present at the top level, unless the head of the external call begins with a caret (to make it explicit). I tried to make the error quite descriptive about what should be done. # User-Facing Changes These now cause a parse error: ```nushell $foo = bar $foo = `bar` ``` These would have been interpreted as strings before this version, but now they'd be interpreted as external calls. This behavior is consistent with `let`/`mut` (which is unaffected by this change). Here is an example of the error: ``` Error: × External command calls must be explicit in assignments ╭─[entry #3:1:8] 1 │ $foo = bar · ─┬─ · ╰── add a caret (^) before the command name if you intended to run and capture its output ╰──── help: the parsing of assignments was changed in 0.97.0, and this would have previously been treated as a string. Alternatively, quote the string with single or double quotes to avoid it being interpreted as a command name. This restriction may be removed in a future release. ``` # Tests + Formatting Tests added to cover the change. Note made about it being temporary.

…ell#14073)  # Description  Swagger supports lists (a.k.a arrays) in query parameters: https://swagger.io/docs/specification/v3_0/serialization/ It supports three different styles: - explode=true - spaceDelimited - pipeDelimited With explode=true being the default and hence most common. It is the hardest to use inside of nushell, as the others are just a `string join` away. This commit adds lists with the explode=true format. # User-Facing Changes  Before: : {a[]: [one two three], b: four} | url build-query Error: nu::shell::unsupported_input × Unsupported input ╭─[entry nushell#33:1:1] 1 │ {a[]: [one two three], b: four} | url build-query · ───────────────┬─────────────── ───────┬─────── · │ ╰── Expected a record with string values · ╰── value originates from here ╰──── After: : {a[]: [one two three], b: four} | url build-query a%5B%5D=one&a%5B%5D=two&a%5B%5D=three&b=four Despite reading CONTRIBUTING.md I didn't get approval before making the change. My judgment is that this doesn't qualify as being "change something significantly". # Tests + Formatting I added the Example instance for the automatic tests. I couldn't figure out how to add an Example for the error case, so I did that with manual testing. E.g.: : {a[]: [one two [three]], b: four} | url build-query Error: nu:🐚:unsupported_input × Unsupported input ╭─[entry #3:1:1] 1 │ {a[]: [one two [three]], b: four} | url build-query · ────────────────┬──────────────── ───────┬─────── · │ ╰── Expected a record with list of string values · ╰── value originates from here ╰──── : {a[]: [one two 3hr], b: four} | url build-query Error: nu:🐚:unsupported_input × Unsupported input ╭─[entry #4:1:1] 1 │ {a[]: [one two 3hr], b: four} | url build-query · ──────────────┬────────────── ───────┬─────── · │ ╰── Expected a record with list of string values · ╰── value originates from here ╰────  I ran the four cargo commands on my local machine. I had to run the tests with: LANG=C and -j 1 and even then I got one failure: thread 'commands::umkdir::mkdir_umask_permission' panicked at crates/nu-command/tests/commands/umkdir.rs:148:9: assertion `left == right` failed: Most *nix systems have 0o00022 as the umask. So directory permission should be 0o40755 = 0o 40777 & (!0o00022) left: 16893 right: 16877 but this isn't related to this change (I seem to not be running most *nix system; and don't have a lot of RAM for the number of cores). The other three cargo commands didn't have errors or warnings. # After Submitting  I will add the new example to [the documentation](https://github.com/nushell/nushell.github.io). # Open questions / possible future work Things I noticed, and would like to mention and am open to adding, but don't think I am deep enough in nushell to do them pro-actively. ## Add an argument for the other query parameter list styles I don't know how frequent they are and I currently don't need them, so following KISS I didn't add them. ## long input_span marked In e.g.: : {a[]: [one two 3hr], b: four} | url build-query Error: nu::shell::unsupported_input × Unsupported input ╭─[entry #4:1:1] 1 │ {a[]: [one two 3hr], b: four} | url build-query · ──────────────┬────────────── ───────┬─────── · │ ╰── Expected a record with list of string values · ╰── value originates from here ╰──── the entire record is marked as input_span instead of just the "3hr" that is causing the problem. Changing that would be trivial, but I'm not deep enough into nushell to understand all the consequences of changing that. ## Error message says string values despite accepting numbers etc. The error message said it only accepted strings despite accepting numbers etc. (anything it can coerce into string). I couldn't find a good wording myself and that was how it was before. I simply added a "list of strings".

) A more involved solution to the issue pointed out [here](nushell#14337 (comment)) # Description With `--to-table` - cell-path groupers are used to create column names, similar to `select` - closure groupers result in columns named `closure_{i}` where `i` is the index of argument, with regards to other closures i.e. first closure grouper results in a column named `closure_0` Previously - `group-by foo {...} {...}` => `table<foo, group1, group2, items>` - `group-by {...} foo {...}` => `table<group0, foo, group2, items>` With this PR - `group-by foo {...} {...}` => `table<foo, closure_0, closure_1, items>` - `group-by {...} foo {...}` => `table<closure_0, foo, closure_1, items>` - no grouper argument results in a `table<group, items>` as previously On naming conflicts caused by cell-path groupers named `items` or `closure_{i}`, an error is thrown, suggesting to use a closure in place of a cell-path. ```nushell ❯ ls | rename items | group-by items --to-table Error: × grouper arguments can't be named `items` ╭─[entry #3:1:29] 1 │ ls | rename items | group-by items --to-table · ────────┬──────── · ╰── contains `items` ╰──── help: instead of a cell-path, try using a closure ``` And following the suggestion: ```nushell ❯ ls | rename items | group-by { get items } --to-table ╭─#──┬──────closure_0──────┬───────────────────────────items────────────────────────────╮ │ 0 │ CITATION.cff │ ╭─#─┬────items─────┬─type─┬─size──┬───modified───╮ │ │ │ │ │ 0 │ CITATION.cff │ file │ 812 B │ 3 months ago │ │ │ │ │ ╰─#─┴────items─────┴─type─┴─size──┴───modified───╯ │ │ 1 │ CODE_OF_CONDUCT.md │ ╭─#─┬───────items────────┬─type─┬──size───┬───modified───╮ │ ... ```

…ushell#14385) # Description As title, this pr is going to deprecate `--ignore-shell-errors` and `--ignore-program-errors`. Because I think these two flags makes `do` command complicate, and it should be easy to use `-i` instead. # User-Facing Changes After the pr, using these two flags will raise deprecated warning. ```nushell > do --ignore-program-errors { ^pwd } Error: × Deprecated option ╭─[entry #2:1:1] 1 │ do --ignore-program-errors { ^pwd } · ─┬ · ╰── `--ignore-program-errors` is deprecated and will be removed in 0.102.0. ╰──── help: Please use the `--ignore-errors(-i)` /home/windsoilder/projects/nushell > do --ignore-shell-errors { ^pwd } Error: × Deprecated option ╭─[entry #3:1:1] 1 │ do --ignore-shell-errors { ^pwd } · ─┬ · ╰── `--ignore-shell-errors` is deprecated and will be removed in 0.102.0. ╰──── help: Please use the `--ignore-errors(-i)` /home/windsoilder/projects/nushell ``` # Tests + Formatting NaN

…time (nushell#14303) Alternative solution to: - nushell#12195 The other approach: - nushell#14305 # Description Adds ~`path const`~ `path self`, a parse-time only command for getting the absolute path of the source file containing it, or any file relative to the source file. - Useful for any script or module that makes use of non nuscript files. - Removes the need for `$env.CURRENT_FILE` and `$env.FILE_PWD`. - Can be used in modules, sourced files or scripts. # Examples ```nushell # ~/.config/nushell/scripts/foo.nu const paths = { self: (path self), dir: (path self .), sibling: (path self sibling), parent_dir: (path self ..), cousin: (path self ../cousin), } export def main [] { $paths } ``` ```nushell > use foo.nu > foo ╭────────────┬────────────────────────────────────────────╮ │ self │ /home/user/.config/nushell/scripts/foo.nu │ │ dir │ /home/user/.config/nushell/scripts │ │ sibling │ /home/user/.config/nushell/scripts/sibling │ │ parent_dir │ /home/user/.config/nushell │ │ cousin │ /home/user/.config/nushell/cousin │ ╰────────────┴────────────────────────────────────────────╯ ``` Trying to run in a non-const context ```nushell > path self Error: × this command can only run during parse-time ╭─[entry #1:1:1] 1 │ path self · ─────┬──── · ╰── can't run after parse-time ╰──── help: try assigning this command's output to a const variable ``` Trying to run in the REPL i.e. not in a file ```nushell > const foo = path self Error: × Error: nu:🐚:file_not_found │ │ × File not found │ ╭─[entry #3:1:13] │ 1 │ const foo = path self │ · ─────┬──── │ · ╰── Couldn't find current file │ ╰──── │ ╭─[entry #3:1:13] 1 │ const foo = path self · ─────┬──── · ╰── Encountered error during parse-time evaluation ╰──── ``` # Comparison with nushell#14305 ## Pros - Self contained implementation, does not require changes in the parser. - More concise usage, especially with parent directories. --------- Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>

…m the declaration (nushell#14490) # Description Before this PR, `help commands` uses the name from a command's declaration rather than the name in the scope. This is problematic when trying to view the help page for the `main` command of a module. For example, `std bench`: ```nushell use std/bench help bench # => Error: nu::parser::not_found # => # => × Not found. # => ╭─[entry nushell#10:1:6] # => 1 │ help bench # => · ──┬── # => · ╰── did not find anything under this name # => ╰──── ``` This can also cause confusion when importing specific commands from modules. Furthermore, if there are multiple commands with the same name from different modules, the help text for _both_ will appear when querying their help text (this is especially problematic for `main` commands, see nushell#14033): ```nushell use std/iter help iter find # => Error: nu::parser::not_found # => # => × Not found. # => ╭─[entry #3:1:6] # => 1│ help iter find # => · ────┬──── # => · ╰── did not find anything under this name # => ╰──── help find # => Searches terms in the input. # => # => Search terms: filter, regex, search, condition # => # => Usage: # => > find {flags} ...(rest) # [...] # => Returns the first element of the list that matches the # => closure predicate, `null` otherwise # [...] # (full text omitted for brevity) ``` This PR changes `help commands` to use the name as it is in scope, so prefixing any command in scope with `help` will show the correct help text. ```nushell use std/bench help bench # [help text for std bench] use std/iter help iter find # [help text for std iter find] use std help std bench # [help text for std bench] help std iter find # [help text for std iter find] ``` Additionally, the IR code generation for commands called with the `--help` text has been updated to reflect this change. This does have one side effect: when a module has a `main` command defined, running `help <name>` (which checks `help aliases`, then `help commands`, then `help modules`) will show the help text for the `main` command rather than the module. The help text for the module is still accessible with `help modules <name>`. Fixes nushell#10499, nushell#10311, nushell#11609, nushell#13470, nushell#14033, and nushell#14402. Partially fixes nushell#10707. Does **not** fix nushell#11447. # User-Facing Changes * Help text for commands can be obtained by running `help <command name>`, where the command name is the same thing you would type in order to execute the command. Previously, it was the name of the function as written in the source file. * For example, for the following module `spam` with command `meow`: ```nushell module spam { # help text export def meow [] {} } ``` * Before this PR: * Regardless of how `meow` is `use`d, the help text is viewable by running `help meow`. * After this PR: * When imported with `use spam`: The `meow` command is executed by running `spam meow` and the `help` text is viewable by running `help spam meow`. * When imported with `use spam foo`: The `meow` command is executed by running `meow` and the `help` text is viewable by running `meow`. * When a module has a `main` command defined, `help <module name>` will return help for the main command, rather than the module. To access the help for the module, use `help modules <module name>`. # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting N/A

@ayax79

# Description closes nushell#14585 This PR tries to make `polars join --cross` work better. Example taken from https://docs.pola.rs/user-guide/transformations/joins/#cartesian-product ### Before ```nushell ❯ let tokens = [[monopoly_token]; [hat] [shoe] [boat]] | polars into-df ❯ let players = [[name, cash]; [Alice, 78] [Bob, 135]] | polars into-df ❯ $players | polars into-lazy | polars select (polars col name) | polars join --cross $tokens | polars collect Error: nu::parser::missing_positional × Missing required positional argument. ╭─[entry #3:1:92] 1 │ $players | polars into-lazy | polars select (polars col name) | polars join --cross $tokens ╰──── help: Usage: polars join {flags} <other> <left_on> <right_on> . Use `--help` for more information. ``` ### After ```nushell ❯ let players = [[name, cash]; [Alice, 78] [Bob, 135]] | polars into-df ❯ let tokens = [[monopoly_token]; [hat] [shoe] [boat]] | polars into-df ❯ $players | polars into-lazy | polars select (polars col name) | polars join --cross $tokens | polars collect ╭─#─┬─name──┬─monopoly_token─╮ │ 0 │ Alice │ hat │ │ 1 │ Alice │ shoe │ │ 2 │ Alice │ boat │ │ 3 │ Bob │ hat │ │ 4 │ Bob │ shoe │ │ 5 │ Bob │ boat │ ╰─#─┴─name──┴─monopoly_token─╯ ``` Other examples ```nushell ❯ 1..3 | polars into-df | polars join --cross (4..6 | polars into-df) ╭─#─┬─0─┬─0_x─╮ │ 0 │ 1 │ 4 │ │ 1 │ 1 │ 5 │ │ 2 │ 1 │ 6 │ │ 3 │ 2 │ 4 │ │ 4 │ 2 │ 5 │ │ 5 │ 2 │ 6 │ │ 6 │ 3 │ 4 │ │ 7 │ 3 │ 5 │ │ 8 │ 3 │ 6 │ ╰─#─┴─0─┴─0_x─╯ ❯ 1..3 | each {|x| {x: $x}} | polars into-df | polars join --cross (4..6 | each {|y| {y: $y}} | polars into-df) x y ╭─#─┬─x─┬─y─╮ │ 0 │ 1 │ 4 │ │ 1 │ 1 │ 5 │ │ 2 │ 1 │ 6 │ │ 3 │ 2 │ 4 │ │ 4 │ 2 │ 5 │ │ 5 │ 2 │ 6 │ │ 6 │ 3 │ 4 │ │ 7 │ 3 │ 5 │ │ 8 │ 3 │ 6 │ ╰─#─┴─x─┴─y─╯ ``` /cc @ayax79 # User-Facing Changes  # Tests + Formatting  # After Submitting

# Description  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 nushell#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 nushell#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 nushell#14:2:6] # => 2 │ echo 1 | zip [2] # => · ┬ ─┬─ # => · │ ╰── only list<any> and range input data is supported # => · ╰── input type: int # => ╰──── ``` # User-Facing 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 nushell#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 nushell#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  - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting  * Play whack-a-mole with the commands and scripts this will inevitably break

# Description This PR should address nushell#13530 by explicitly handling ByteStreams. The issue can be replicated easily on linux by running: ```nushell open /dev/urandom | into binary | bytes at ..10 ``` Would leave the output hanging and with no way to cancel it, this was likely because it was trying to collect the input stream and would not complete. I have also put in an error to say that using negative offsets for a bytestream without a length cannot be used. ```nushell ~/git/nushell> open /dev/urandom | into binary | bytes at (-1).. Error: nu::shell::incorrect_value × Incorrect value. ╭─[entry #3:1:35] 1 │ open /dev/urandom | into binary | bytes at (-1).. · ────┬─── ───┬── · │ ╰── encountered here · ╰── Negative range values cannot be used with streams that don't specify a length ╰──── ``` # User-Facing Changes No operation changes, only the warning you get back for negative offsets # Tests + Formatting Ran `toolkit check pr ` with no errors or warnings Manual testing of the example commands above --------- Co-authored-by: Ian Manske <ian.manske@pm.me> Co-authored-by: Simon Curtis <simon.curtis@candc-uk.com>

Issue nushell#12289, can be closed when this is merged # Description Currently, the ``into datetime`` command's signature indicates that it supports input as record, but it was actually not supported. This PR implements this feature. # User-Facing Changes ``into datetime``'s signature changed (see comments) **Happy paths** Note: I'm in +02:00 timezone. ```nushell > date now | into record | into datetime Fri, 4 Apr 2025 18:32:34 +0200 (now) > {year: 2025, month: 12, day: 6, second: 59} | into datetime | into record ╭─────────────┬────────╮ │ year │ 2025 │ │ month │ 12 │ │ day │ 6 │ │ hour │ 0 │ │ minute │ 0 │ │ second │ 59 │ │ millisecond │ 0 │ │ microsecond │ 0 │ │ nanosecond │ 0 │ │ timezone │ +02:00 │ ╰─────────────┴────────╯ > {day: 6, second: 59, timezone: '-06:00'} | into datetime | into record ╭─────────────┬────────╮ │ year │ 2025 │ │ month │ 4 │ │ day │ 6 │ │ hour │ 0 │ │ minute │ 0 │ │ second │ 59 │ │ millisecond │ 0 │ │ microsecond │ 0 │ │ nanosecond │ 0 │ │ timezone │ -06:00 │ ╰─────────────┴────────╯ ``` **Edge cases** ```nushell {} | into datetime Fri, 4 Apr 2025 18:35:19 +0200 (now) ``` **Error paths** - A key has a wrong type ```nushell > {month: 12, year: '2023'} | into datetime Error: nu::shell::only_supports_this_input_type × Input type not supported. ╭─[entry nushell#8:1:19] 1 │ {month: 12, year: '2023'} | into datetime · ───┬── ──────┬────── · │ ╰── only int input data is supported · ╰── input type: string ╰──── ``` ```nushell > {month: 12, year: 2023, timezone: 100} | into datetime Error: nu:🐚:only_supports_this_input_type × Input type not supported. ╭─[entry nushell#10:1:35] 1 │ {month: 12, year: 2023, timezone: 100} | into datetime · ─┬─ ──────┬────── · │ ╰── only string input data is supported · ╰── input type: int ╰──── ``` - Key has the right type but value invalid (e.g. month=13, or day=0) ```nushell > {month: 13, year: 2023} | into datetime Error: nu:🐚:incorrect_value × Incorrect value. ╭─[entry nushell#9:1:1] 1 │ {month: 13, year: 2023} | into datetime · ───────────┬─────────── ──────┬────── · │ ╰── one of more values are incorrect and do not represent valid date · ╰── encountered here ╰──── ``` ```nushell > {hour: 1, minute: 1, second: 70} | into datetime Error: nu:🐚:incorrect_value × Incorrect value. ╭─[entry #3:1:1] 1 │ {hour: 1, minute: 1, second: 70} | into datetime · ────────────────┬─────────────── ──────┬────── · │ ╰── one of more values are incorrect and do not represent valid time · ╰── encountered here ╰──── ``` - Timezone has right type but is invalid ```nushell > {month: 12, year: 2023, timezone: "+100:00"} | into datetime Error: nu:🐚:incorrect_value × Incorrect value. ╭─[entry nushell#11:1:35] 1 │ {month: 12, year: 2023, timezone: "+100:00"} | into datetime · ────┬──── ──────┬────── · │ ╰── encountered here · ╰── invalid timezone ╰──── ``` - Record contains an invalid key ```nushell > {month: 12, year: 2023, unknown: 1} | into datetime Error: nu:🐚:unsupported_input × Unsupported input ╭─[entry nushell#12:1:1] 1 │ {month: 12, year: 2023, unknown: 1} | into datetime · ─────────────────┬───────────────── ──────┬────── · │ ╰── Column 'unknown' is not valid for a structured datetime. Allowed columns are: year, month, day, hour, minute, second, millisecond, microsecond, nanosecond, timezone · ╰── value originates from here ╰──── ``` - If several issues are present, the user can get the error msg for only one, though ```nushell > {month: 20, year: '2023'} | into datetime Error: nu:🐚:only_supports_this_input_type × Input type not supported. ╭─[entry nushell#7:1:19] 1 │ {month: 20, year: '2023'} | into datetime · ───┬── ──────┬────── · │ ╰── only int input data is supported · ╰── input type: string ╰ ``` # Tests + Formatting Tests added Fmt + clippy OK # After Submitting Maybe indicate that in the release notes I added an example in the command, so the documentation will be automatically updated.

# Description  As a bonus to nushell#16174, I realized it would be trivial to add a similar check to where. Before: ```nushell 1..100 | where 1 # => no output... ``` After: ```nushell 1..100 | where 1 # => Error: nu::parser::type_mismatch # => # => × Type mismatch. # => ╭─[entry #3:1:16] # => 1 │ 1..100 | where 1 # => · ┬ # => · ╰── expected bool, found int # => ╰──── ``` # User-Facing Changes  * `where` should now error on row condition expressions which are not booleans # Tests + Formatting  Added test # After Submitting  N/A

This PR reverts the breaking change of short flag change of `watch -d` to `--debounce` instead of `--debounce-ms`. This fully prevents nushell#16187 from being a breaking change. Before nushell#16187: ```nushell watch -d 1000 foo {} # => Now watching files at "/home/rose/foo". Press ctrl+c to abort. ``` Before this PR (after nushell#16187): ```nushell watch -d 1000 foo {} # => Error: nu::parser::parse_mismatch # => # => × Parse mismatch during operation. # => ╭─[entry nushell#15:1:10] # => 1 │ watch -d 1000 foo {} # => · ──┬─ # => · ╰── expected duration with valid units # => ╰──── ``` After this PR (after nushell#16187): ```nushell watch -d 1000 foo {} # => Warning: nu::parser::deprecated # => # => ⚠ Flag deprecated. # => ╭─[entry #3:1:7] # => 1 │ watch -d 1000 foo {} # => · ─┬ # => · ╰── watch --debounce-ms was deprecated in 0.107.0 and will be removed in 0.109.0. # => ╰──── # => help: `--debounce-ms` will be removed in favour of `--debounce` # => # => Now watching files at "/home/rose/foo". Press ctrl+c to abort. ``` This PR also fixes the `DeprecationEntry` which incorrectly had a `--` in it, which I failed to realize when reviewing nushell#16187. We should add a `debug_assert` or something for this. Rel: nushell#16187 ## Release notes summary - What our users need to know N/A ## Tasks after submitting - [ ] Add `debug_assert` for `DeprecationType::Flag`s with `--`

Fixes nushell#15410 and nushell#16584 (or at least improves the situation) not 100% sure if i chose the best span - if another one is more fitting and available i would be happy to change it. old: ``` Error: × Failed to create table ``` new: ``` Error: × Failed to create table ╭─[entry #3:5:25] 4 │ | each {|i| {"foo": "bar"} } 5 │ | into sqlite -t test test.sqlite · ─────┬───── · ╰── table [test] already exists 6 │ } ╰──── ``` ## Release notes summary - What our users need to know Improved `into sqlite` errors. ## Tasks after submitting * [x] `cargo fmt --all -- --check` * [x] `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` * [ ] `cargo test --workspace`: __**fails**__ (but `shell::environment::env::path_is_a_list_in_repl` seems unrelated to me) * [x] `cd crates/nu-command; cargo test`

This allows all of the inputs to a `LabeledError` structure to be accessed from inside of Nushell scripts, not just plugins, including: * multiple labels (see error from `1 + ""`) * errors inside of errors (see error from `']' | from nuon`) * custom codes instead of only `nu::shell::error` * URL's added to errors using the `url` key This is a complete rewrite of the `error make` command using `FromValue` to simplify the parsing a _lot_. I did have to write a `FromValue` implementation for `nu_protocol::Span` that goes from a record into a `Span` object. The error checking happens in there instead of in `error make` now. Here are a few examples: ``` > def foo [pond sink] { error make { msg: "this is fishy" code: "my::error" label: [ {text: "fish right here" span: (metadata $pond).span} {text: "don't fish here" span: (metadata $sink).span} ] help: "something to tell the user as help" url: "https://nushell.sh" } } > foo "pond" "sink" Error: my::error (link) × this is fishy ╭─[entry #2:1:5] 1 │ foo "pond" "sink" · ───┬── ───┬── · │ ╰── don't fish here · ╰── fish right here ╰──── help: something to tell the user as help > try { foo pond "not a pond" } catch {|e| error make { msg: "An outer error" inner: [($e.json | from json)] } } Error: nu:🐚:error × An outer error ╭─[entry #3:4:5] 3 │ } catch {|e| 4 │ error make { · ─────┬──── · ╰── originates from here 5 │ msg: "An outer error" ╰──── Error: my::error (link) × this is fishy ╭─[entry #3:2:9] 1 │ try { 2 │ foo pond "not a pond" · ──┬─ ──────┬───── · │ ╰── don't fish here · ╰── fish right here 3 │ } catch {|e| ╰──── help: something to tell the user as help ``` The `(link)` is clickable if the right `$env.config` settings are enabled, or it will print `https://example.com` to the screen.  ## Release notes summary - What our users need to know * Add the all parts of the `LabeledError` structure to the `error_struct` argument of `error make` ## Tasks after submitting  - [ ] Update the [documentation](https://github.com/nushell/nushell.github.io)

ysthakur added 15 commits June 23, 2024 10:29

Make sort_completions helper

a055e59

Used by command, custom, flag, and variable completions

Sort inside complete_rec

9744ffd

Sort subcommand completions

8b15366

Make match_suggestions compare all suggestions at once

62c087b

Change expected sort order for file_completion_quoted

3121e4c

test: Shortest compl should be first

bd071f1

Remove Completer.get_sort_by()

2dd0963

Test if dotnu completions are sorted

1919139

Sort dotnu completions

2d64a4e

Update doc comment for Completer

f300049

Use backslash on windows in .nu compl test

d618924

Remove const SORT_BY variable complns

8cec000

Sort subcommands by levenshtein distance

0bdb575

Test subcmd compln sort order

040f30f

ysthakur closed this Jul 4, 2024

ysthakur deleted the comp-sort-order branch July 4, 2024 00:21

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make completers sort while fetching#3

Make completers sort while fetching#3
ysthakur wants to merge 15 commits intomainfrom
comp-sort-order

ysthakur commented Jun 23, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

ysthakur commented Jun 23, 2024

Description

User-Facing Changes

Tests + Formatting

After Submitting

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant