Wip/modular nu std/load all submodules #2

amtoine · 2023-04-08T16:44:43Z

state

main issues with the current nushell#8815

we cannot use export use crates/nu-std/lib/<mod>.nu in crates/nu-std/lib/mod.nu because crates/nu-std/ is not available in the final binary => this will work locally only
the submodules are not available after the startup with the current library loader

this proposal

Note

🟢 pros

🔴 cons

⚫ neutral

🟢 passes all the CI
🟢 allows to write a simple export use <mod> * in crates/nu-std/lib/mod.nu
🟢 loads all submodules ⚫ before the main std
🔴 require to write

        let submodules = vec![
            ...
            ("<mod>", include_str!("../lib/<mod>.nu")),
            ...
        ];

in crates/nu-std/src/lib.rs

This commit puts all the "config" variables at the top.

Closes nushell#8546. ### Before: ``` > mv foo.txt bar.txt Error: × Invalid file or pattern ╭─[entry #2:1:1] 1 │ mv foo.txt bar.txt · ───┬─── · ╰── invalid file or pattern ╰──── ``` ### After: ``` > mv foo.txt bar.txt Error: × File(s) not found ╭─[entry #2:1:1] 1 │ mv foo.txt bar.txt · ───┬─── · ╰── could not find any files matching this glob pattern ╰──── ```

This PR makes `?` work with `reject`. For example: ```bash > {} | reject foo Error: nu::shell::column_not_found × Cannot find column ╭─[entry #2:1:1] 1 │ {} | reject foo · ───┬── ─┬─ · │ ╰── cannot find column 'foo' · ╰── value originates here ╰──── > {} | reject foo? ╭──────────────╮ │ empty record │ ╰──────────────╯ ``` This was prompted by [a user question](https://discord.com/channels/601130461678272522/614593951969574961/1091466428546306078). I would like to get this in for 0.78, I think it's low-risk and I want the `?` feature to be as polished as possible for its debut.

# Description Fixes: nushell#8402 nushell#8391 The cause of these issue if when we want to evaluate a expression with `Value::Error`, nushell show error immediately. To fix the issue, we can wrap the `Value::Error` into a `Value::Record`. So user can see the message he want. # User-Facing Changes Before ``` ❯ try { 1 / 0 } catch {|e| echo $"error is ($e)"} Error: nu::shell::division_by_zero × Division by zero. ╭─[entry #2:1:1] 1 │ try { 1 / 0 } catch {|e| echo $"error is ($e)"} · ┬ · ╰── division by zero ╰──── ``` After ``` ❯ try { 1 / 0 } catch {|e| echo $"error is ($e)"} error is {msg: Division by zero., debug: DivisionByZero { span: Span { start: 43104, end: 43105 } }, raw: DivisionByZero { sp an: Span { start: 43104, end: 43105 } }} ``` As we can see, error becomes a record with `msg`, `debug`, `raw` columns. 1. msg column is a user friendly message. 2. debug column is more about `Value::Error` information as a string. 3. raw column is a `Value::Error` itself, if user want to re-raise the error, just use `$e | get raw` # 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 -A clippy::needless_collect` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass > **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 > ``` # 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.

…8290) # Description As title, closes: nushell#7921 closes: nushell#8273 # User-Facing Changes when define a closure without pipe, nushell will raise error for now: ``` ❯ let x = {ss ss} Error: nu::parser::closure_missing_pipe × Missing || inside closure ╭─[entry #2:1:1] 1 │ let x = {ss ss} · ───┬─── · ╰── Parsing as a closure, but || is missing ╰──── help: Try add || to the beginning of closure ``` `any`, `each`, `all`, `where` command accepts closure, it forces user input closure like `{||`, or parse error will returned. ``` ❯ {major:2, minor:1, patch:4} | values | each { into string } Error: nu::parser::closure_missing_pipe × Missing || inside closure ╭─[entry #4:1:1] 1 │ {major:2, minor:1, patch:4} | values | each { into string } · ───────┬─────── · ╰── Parsing as a closure, but || is missing ╰──── help: Try add || to the beginning of closure ``` `with-env`, `do`, `def`, `try` are special, they still remain the same, although it says that it accepts a closure, but they don't need to be written like `{||`, it's more likely a block but can capture variable outside of scope: ``` ❯ def test [input] { echo [0 1 2] | do { do { echo $input } } }; test aaa aaa ``` Just realize that It's a big breaking change, we need to update config and scripts... # 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 -A clippy::needless_collect` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass # 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.

# Description until now, a call to `toolkit` alone would give ```bash Error: nu::shell::external_command × External command failed ╭─[entry #2:1:1] 1 │ toolkit · ───┬─── · ╰── did you mean 'toolkit clippy'? ╰──── help: No such file or directory (os error 2) ``` which i find confusing after a `use toolkit.nu` 🤔 this PR adds a `main` command to `toolkit.nu` which runs the `help` command on the module. # User-Facing Changes now ``` > use toolkit.nu > toolkit Usage: > toolkit Subcommands: toolkit check pr - run all the necessary checks and tests to submit a perfect PR toolkit clippy - check that you're using the standard code style toolkit fmt - check standard code formatting and apply the changes toolkit setup-git-hooks - set up git hooks to run: - `toolkit fmt --check --verbose` on `git commit` - `toolkit fmt --check --verbose` and `toolkit clippy --verbose` on `git push` toolkit test - check that all the tests pass toolkit test stdlib - run the tests for the standard library Flags: -h, --help - Display the help message for this command ``` # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - ⚫ `toolkit test` - ⚫ `toolkit test stdlib` # After Submitting ``` $nothing ```

# Description ## ❌ before this PR ``` >_ std help modules euwioq Error: nu:🐚:external_command × External command failed ╭─[help:259:1] 259 │ if ($found_module | is-empty) { 260 │ module_not_found_error (metadata $module | get span) · ──────────────┬────────────── · ╰── Cannot convert record<start: int, end: int> to a string 261 │ } ╰──── help: All arguments to an external command need to be string-compatible ``` ``` >_ std help externs euwioq Error: × std::help::extern_not_found ╭─[help:401:1] 401 │ 402 │ let extern = ($extern | str join " ") · ─┬─ · ╰── extern not found 403 │ ╰──── ``` > **Note** > same kind of error with all the others ## ✔️ after this PR ``` > std help modules euwioq 04/28/2023 05:45:50 PM Error: × std::help::module_not_found ╭─[entry #2:1:1] 1 │ std help modules euwioq · ───┬── · ╰── module not found ╰──── ``` ``` > std help externs euwioq 04/28/2023 05:45:53 PM Error: × std::help::extern_not_found ╭─[entry #3:1:1] 1 │ std help externs euwioq · ───┬── · ╰── extern not found ╰──── ``` > **Note** > same with the others # User-Facing Changes fixes the errors to have proper messages # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - ⚫ `toolkit test` - ⚫ `toolkit test stdlib` # After Submitting ``` $nothing ```

related to - nushell#9101 - nushell#9039 # Description i actually forgot to fix in nushell#9039 the new "*item*" introduced by nushell#9101... 👀 there it is 😇 # User-facing changes going from ``` > std help git-commiteuwqi Help pages from external command git-commiteuwqi: No manual entry for git-commiteuwqi Error: × std::help::item_not_found ╭─[help:721:1] 721 │ 722 │ let item = ($item | str join " ") · ─┬─ · ╰── item not found 723 │ ╰──── ``` to ``` > std help git-commiteuwqi Help pages from external command git-commiteuwqi: No manual entry for git-commiteuwqi Error: × std::help::item_not_found ╭─[entry #2:1:1] 1 │ std help git-commiteuwqi · ───────┬─────── · ╰── item not found ╰──── ``` # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - ⚫ `toolkit test` - ⚫ `toolkit test stdlib` # After Submitting ``` $nothing ```

# Description Fixes a small bug with `rm` where names of files which couldn't be deleted due to error were not printed. Fixes nushell#9004 # User-Facing Changes Slightly different error message than previously. Nothing significant, though. The new error message looks like this ``` ~/Projects/rust/nushell> rm /proc/1/mem 05/06/2023 01:13:23 PM Error: nu::shell::remove_not_possible × Remove not possible ╭─[entry #3:1:1] 1 │ rm /proc/1/mem · ─────┬───── · ╰── Could not delete /proc/1/mem: Operation not permitted (os error 1) ╰──── ``` or when using a glob (only showing a single entry for brevity) ``` Error: nu:🐚:remove_not_possible × Remove not possible ╭─[entry #2:1:1] 1 │ rm --recursive --force --verbose /proc/1/* · ────┬──── · ╰── Could not delete /proc/1/comm: Operation not permitted (os error 1) ╰──── ``` # Tests + Formatting No new unit tests were added for this change as it is pretty difficult to test this particular case. However, manual testing was run with the following commands ``` rm /proc/1/mem rm --recursive --force --verbose /proc/1/* ``` # After Submitting N/A

this solves the following error ``` error: proc-macro derive panicked --> crates/nu-cmd-extra/src/extra/formats/to/html.rs:79:10 | 79 | #[derive(RustEmbed)] | ^^^^^^^^^ | = help: message: #[derive(RustEmbed)] folder '/home/amtoine/.local/share/git/store/github.com/amtoine/nushell/crates/nu-cmd-extra/assets/' does not exist. cwd: '/home/amtoine/.local/share/git/store/github.com/amtoine/nushell' error[E0599]: no function or associated item named `get` found for struct `Assets` in the current scope --> crates/nu-cmd-extra/src/extra/formats/to/html.rs:228:19 | 81 | struct Assets; | ------------- function or associated item `get` not found for this struct ... 228 | match Assets::get(json_name) { | ^^^ function or associated item not found in `Assets` | = help: items from traits can only be used if the trait is implemented and in scope = note: the following traits define an item `get`, perhaps you need to implement one of them: candidate #1: `SliceIndex` candidate #2: `RustEmbed` For more information about this error, try `rustc --explain E0599`. error: could not compile `nu-cmd-extra` due to 2 previous errors warning: build failed, waiting for other jobs to finish... ```

# Description in the help page of `metadata`, there is the following example ```nushell ls | metadata ``` which gives the following error ``` Error: nu::parser::input_type_mismatch × Command does not support table input. ╭─[entry #2:1:1] 1 │ ls | metadata · ────┬─── · ╰── command doesn't support table input ╰──── ``` this PR adds `any -> record` to the signatures of `metadata` to allow the use of that kind of example. # User-Facing Changes `ls | metadata` will work again # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - ⚫ `toolkit test` - ⚫ `toolkit test stdlib` # After Submitting

# Description This PR updates the `items` command to allow `any` output. items takes a closure so theoretically, any value type of output could be valid. ### Before ```nushell {a: 1 b: 2} | items {|k,v| {key: $k value: $v}} | transpose Error: nu::parser::input_type_mismatch × Command does not support list<string> input. ╭─[entry #2:1:1] 1 │ {a: 1 b: 2} | items {|k,v| {key: $k value: $v}} | transpose · ────┬──── · ╰── command doesn't support list<string> input ╰──── ``` ### After ```nushell ❯ {a: 1 b: 2} | items {|k,v| {key: $k value: $v}} | transpose ╭───┬─────────┬─────────┬─────────╮ │ # │ column0 │ column1 │ column2 │ ├───┼─────────┼─────────┼─────────┤ │ 0 │ key │ a │ b │ │ 1 │ value │ 1 │ 2 │ ╰───┴─────────┴─────────┴─────────╯ ``` # User-Facing Changes  # Tests + Formatting  # After Submitting

# Description This PR changes the signature of the deprecated command `let-env` so that it does not mislead people when invoking it without parameters. ### Before ```nushell > let-env Error: nu::parser::missing_positional × Missing required positional argument. ╭─[entry #2:1:1] 1 │ let-env ╰──── help: Usage: let-env <var_name> = <initial_value> ``` ### After ```nushell ❯ let-env Error: nu:🐚:deprecated_command × Deprecated command let-env ╭─[entry #1:1:1] 1 │ let-env · ───┬─── · ╰── 'let-env' is deprecated. Please use '$env.<environment variable> = ...' instead. ╰──── ``` # User-Facing Changes  # Tests + Formatting  # After Submitting

- Hopefully closes nushell#10120 # Description This PR adds a new config item, `error_style`. It will render errors in a screen reader friendly mode when set to `"simple"`. This is done using `miette`'s own `NarratableReportHandler`, which seamlessly replaces the default one when needed. Before: ``` Error: nu::shell::external_command × External command failed ╭─[entry #2:1:1] 1 │ doesnt exist · ───┬── · ╰── executable was not found ╰──── help: No such file or directory (os error 2) ``` After: ``` Error: External command failed Diagnostic severity: error Begin snippet for entry #4 starting at line 1, column 1 snippet line 1: doesnt exist label at line 1, columns 1 to 6: executable was not found diagnostic help: No such file or directory (os error 2) diagnostic code: nu::shell::external_command ``` ## Things to be determined - ~Review naming. `errors.style` is not _that_ consistent with the rest of the code. Menus use a `style` record, but table rendering mode is set via `mode`.~ As it's a single config, we're using `error_style` for now. - Should this kind of setting be toggable with one single parameter? `accessibility.no_decorations` or similar, which would adjust the style of both errors and tables accordingly. # User-Facing Changes No changes by default, errors will be rendered differently if `error_style` is set to `simple`. # Tests + Formatting  # After Submitting There's a PR updating the docs over here nushell/nushell.github.io#1026

related to - https://discord.com/channels/601130461678272522/615329862395101194/1149717458786197524 # Description because `1_234 | into datetime` takes an integer number of `ns` and `1_234 | into filesize` takes an integer amount of bytes, i think `1_234 | into duration` should also be valid and see `1_234` as an integer amount of `ns` 😋 # User-Facing Changes ## before either ```nushell 1234 | into string | $in ++ "ns" | into duration ``` ```nushell 1234 | $"($in)ns" | into duration ``` or ```nushell 1234 * 1ns ``` and ```nushell > 1_234 | into duration Error: nu::parser::input_type_mismatch × Command does not support int input. ╭─[entry #2:1:1] 1 │ 1_234 | into duration · ──────┬────── · ╰── command doesn't support int input ╰──── ``` ## after ```nushell > 1_234 | into duration 1µs 234ns ``` # Tests + Formatting new example test ```rust Example { description: "Convert a number of ns to duration", example: "1_234_567 | into duration", result: Some(Value::duration(1_234_567, span)), } ``` # After Submitting

errors look like ```nushell > update value (get value) Error: nu::shell::io_error × I/O error help: can't follow path 'value' in empty stream ``` ```nushell > ^echo "foo" | get 0 Error: nu::shell::io_error × I/O error ╭─[entry #2:1:1] 1 │ ^echo "foo" | get 0 · ──┬─ · ╰── can't follow path '0' in external stream ╰──── ```

related to - nushell#9373 - nushell#8639 might be able to close nushell#8639? # Description "can't follow stream paths" errors have always been a bit scary and obnoxious because they give no information about what happens... in this PR i try to slightly improve the error message by telling if the stream was empty or not and give span information when available. # User-Facing Changes ```nushell > update value (get value) Error: nu::shell::incompatible_path_access × Data cannot be accessed with a cell path ╭─[entry #1:1:1] 1 │ update value (get value) · ─┬─ · ╰── empty pipeline doesn't support cell paths ╰──── ``` ```nushell > ^echo "foo" | get 0 Error: nu:🐚:incompatible_path_access × Data cannot be accessed with a cell path ╭─[entry #2:1:1] 1 │ ^echo "foo" | get 0 · ──┬─ · ╰── external stream doesn't support cell paths ╰──── ``` # Tests + Formatting # After Submitting

follow-up to - nushell#10566 # Description this PR deprecates the use of `extern-wrapped` and `export extern-wrapped` these two core commands will be removed in 0.88 # User-Facing Changes using `extern-wrapped` will give a warning ```nushell > extern-wrapped foo [...args] { print "foo" }; foo Error: × Deprecated command ╭─[entry #2:1:1] 1 │ extern-wrapped foo [...args] { print "foo" }; foo · ───────┬────── · ╰── `extern-wrapped` is deprecated and will be removed in 0.88. ╰──── help: Use `def --wrapped` instead foo ``` # Tests + Formatting # After Submitting

# Description Pretty much all operations/commands in Nushell assume that the column names/keys in a record and thus also in a table (which consists of a list of records) are unique. Access through a string-like cell path should refer to a single column or key/value pair and our output through `table` will only show the last mention of a repeated column name. ```nu [[a a]; [1 2]] ╭─#─┬─a─╮ │ 0 │ 2 │ ╰───┴───╯ ``` While the record parsing already either errors with the `ShellError::ColumnDefinedTwice` or silently overwrites the first occurence with the second occurence, the table literal syntax `[[header columns]; [val1 val2]]` currently still allowed the creation of tables (and internally records with more than one entry with the same name. This is not only confusing, but also breaks some assumptions around how we can efficiently perform operations or in the past lead to outright bugs (e.g. nushell#8431 fixed by nushell#8446). This PR proposes to make this an error. After this change another hole which allowed the construction of records with non-unique column names will be plugged. ## Parts - Fix `SE::ColumnDefinedTwice` error code - Remove previous tests permitting duplicate columns - Deny duplicate column in table literal eval - Deny duplicate column in const eval - Deny duplicate column in `from nuon` # User-Facing Changes `[[a a]; [1 2]]` will now return an error: ``` Error: nu::shell::column_defined_twice × Record field or table column used twice ╭─[entry #2:1:1] 1 │ [[a a]; [1 2]] · ┬ ┬ · │ ╰── field redefined here · ╰── field first defined here ╰──── ``` this may under rare circumstances block code from evaluating. Furthermore this makes some NUON files invalid if they previously contained tables with repeated column names. # Tests + Formatting Added tests for each of the different evaluation paths that materialize tables.

nushell#10851) # Description Fixes: nushell#10271 Given the following script: ```shell # test.sh echo aaaaa echo bbbbb 1>&2 echo cc ``` This pr makes the following command possible: ```nushell bash test.sh err> /dev/null | lines | each {|line| $line | str length} ``` ## General idea behind the change: When nushell redirect stderr message to external file 1. it take stdout of external stream, and pass this stream to next command, so it won't block next pipeline command from running. 2. relative stderr stream are handled by `save` command These two streams are handled separately, so we need to delegate a thread to `save` command, or else we'll have a chance to hang nushell, we have meet a similar before: nushell#5625. ### One case to consider What if we're failed to save to an external stream? (Like we don't have a permission to save to a file)? In this case nushell will just print a waning message, and don't stop the following scripts from running. # User-Facing Changes ## Before ```nushell ❯ bash test2.sh err> /dev/null | lines | each {|line| $line | str length} aaaaa cc ``` ## After ```nushell ❯ bash test2.sh err> /dev/null | lines | each {|line| $line | str length} ╭───┬───╮ │ 0 │ 5 │ │ 1 │ 2 │ ╰───┴───╯ ``` BTY, after this pr, the following commands are impossible either, it's important to make sure that the implementation doesn't introduce too much costs: ```nushell ❯ echo a e> a.txt e> a.txt Error: × Can't make stderr redirection twice ╭─[entry #1:1:1] 1 │ echo a e> a.txt e> a.txt · ─┬ · ╰── try to remove one ╰──── ❯ echo a o> a.txt o> a.txt Error: × Can't make stdout redirection twice ╭─[entry #2:1:1] 1 │ echo a o> a.txt o> a.txt · ─┬ · ╰── try to remove one ╰──── ```

Goes towards implementing nushell#10598, which asks for a spread operator in lists, in records, and when calling commands (continuation of nushell#11006, which only implements it in lists) # Description This PR is for adding a spread operator that can be used when building records. Additional functionality can be added later. Changes: - Previously, the `Expr::Record` variant held `(Expression, Expression)` pairs. It now holds instances of an enum `RecordItem` (the name isn't amazing) that allows either a key-value mapping or a spread operator. - `...` will be treated as the spread operator when it appears before `$`, `{`, or `(` inside records (no whitespace allowed in between) (not implemented yet) - The error message for duplicate columns now includes the column name itself, because if two spread records are involved in such an error, you can't tell which field was duplicated from the spans alone `...` will still be treated as a normal string outside records, and even in records, it is not treated as a spread operator when not followed immediately by a `$`, `{`, or `(`. # User-Facing Changes Users will be able to use `...` when building records. ``` > let rec = { x: 1, ...{ a: 2 } } > $rec ╭───┬───╮ │ x │ 1 │ │ a │ 2 │ ╰───┴───╯ > { foo: bar, ...$rec, baz: blah } ╭─────┬──────╮ │ foo │ bar │ │ x │ 1 │ │ a │ 2 │ │ baz │ blah │ ╰─────┴──────╯ ``` If you want to update a field of a record, you'll have to use `merge` instead: ``` > { ...$rec, x: 5 } Error: nu::shell::column_defined_twice × Record field or table column used twice: x ╭─[entry #2:1:1] 1 │ { ...$rec, x: 5 } · ──┬─ ┬ · │ ╰── field redefined here · ╰── field first defined here ╰──── > $rec | merge { x: 5 } ╭───┬───╮ │ x │ 5 │ │ a │ 2 │ ╰───┴───╯ ``` # Tests + Formatting # After Submitting

) # Description Fixes: nushell#11143 # User-Facing Changes Take the following as example: ```nushell module foo { export def bar [] {}; export def baz [] {} } ``` `use foo bar baz` will be error: ``` ❯ use foo c d Error: nu::parser::wrong_import_pattern × Wrong import pattern structure. ╭─[entry #2:1:1] 1 │ use foo c d · ┬ · ╰── Trying to import something but the parent `c` is not a module, maybe you want to try `use <module> [<name1>, <name2>]` ╰──── ``` # Tests + Formatting Done

this will allow to run ```nushell format date --list | get 0 ``` and get ``` ─────────────┬─────────────────────────────────────────────────────────── Specification│%Y Example │2023 Description │The full proleptic Gregorian year, zero-padded to 4 digits. ─────────────┴─────────────────────────────────────────────────────────── ``` instead of currently ``` Error: nu::parser::input_type_mismatch × Command does not support string input. ╭─[entry #2:1:1] 1 │ format date --list | get 0 · ─┬─ · ╰── command doesn't support string input ╰──── ```

# Description Currently, when writing a record, if you don't give the value for a field, the syntax error highlights the entire record instead of pinpointing the issue. Here's some examples: ```nushell > { a: 2, 3 } # Missing colon (and value) Error: nu::parser::parse_mismatch × Parse mismatch during operation. ╭─[entry #2:1:1] 1 │ { a: 2, 3 } · ─────┬───── · ╰── expected record ╰──── > { a: 2, 3: } # Missing value Error: nu::parser::parse_mismatch × Parse mismatch during operation. ╭─[entry #3:1:1] 1 │ { a: 2, 3: } · ──────┬───── · ╰── expected record ╰──── > { a: 2, 3 4 } # Missing colon Error: nu::parser::parse_mismatch × Parse mismatch during operation. ╭─[entry #4:1:1] 1 │ { a: 2, 3 4 } · ──────┬────── · ╰── expected record ╰──── ``` In all of them, the entire record is highlighted red because an `Expr::Garbage` is returned covering that whole span: ![image](https://github.com/nushell/nushell/assets/45539777/36660b50-23be-4353-b180-3f84eff3c220) This PR is for highlighting only the part inside the record that could not be parsed. If the record literal is big, an error message pointing to the start of where the parser thinks things went wrong should help people fix their code. # User-Facing Changes Below are screenshots of the new errors: If there's a stray record key right before the record ends, it highlights only that key and tells the user it expected a colon after it: ![image](https://github.com/nushell/nushell/assets/45539777/94503256-8ea2-47dd-b69a-4b520c66f7b6) If the record ends before the value for the last field was given, it highlights the key and colon of that field and tells the user it expected a value after the colon: ![image](https://github.com/nushell/nushell/assets/45539777/2f3837ec-3b35-4b81-8c57-706f8056ac04) If there are two consecutive expressions without a colon between them, it highlights everything from the second expression to the end of the record and tells the user it expected a colon. I was tempted to add a help message suggesting adding a colon in between, but that may not always be the right thing to do. ![image](https://github.com/nushell/nushell/assets/45539777/1abaaaa8-1896-4909-bbb7-9a38cece5250) # Tests + Formatting # After Submitting

# Description This is a follow up to: nushell#11365 After this pr, `--flag: bool` is no longer allowed. I think `ParseWarning::Deprecated` is useful when we want to deprecated something at syntax level, so I just leave it there for now. # User-Facing Changes ## Before ``` ❯ def foo [--b: bool] {} Error: × Deprecated: --flag: bool ╭─[entry nushell#15:1:1] 1 │ def foo [--b: bool] {} · ──┬─ · ╰── `--flag: bool` is deprecated and will be removed in 0.90. Please use `--flag` instead, more info: https://www.nushell.sh/book/custom_commands.html ╰──── ``` ## After ``` ❯ def foo [--b: bool] {} Error: × Type annotations are not allowed for boolean switches. ╭─[entry #2:1:1] 1 │ def foo [--b: bool] {} · ──┬─ · ╰── Remove the `: bool` type annotation. ╰──── ``` # Tests + Formatting Done

…r ints (nushell#11724) # Description This PR changes `into int` and `into filesize` so that they allow thousands separators. ### Before ```nushell ❯ '1,000' | into filesize Error: nu::shell::cant_convert × Can't convert to int. ╭─[entry #1:1:1] 1 │ '1,000' | into filesize · ───┬─── · ╰── can't convert string to int ╰──── ❯ '1,000' | into int Error: nu:🐚:cant_convert × Can't convert to int. ╭─[entry #2:1:1] 1 │ '1,000' | into int · ────┬─── · ╰── can't convert string to int ╰──── help: string "1,000" does not represent a valid integer ``` ### After ```nushell ❯ '1,000' | into filesize 1.0 KB ❯ '1,000' | into int 1000 ``` This works by getting the system locale and from that, determining what the thousands separator is. So, hopefully, this will work across locales. # User-Facing Changes  # Tests + Formatting  # After Submitting

# Description Close: nushell#9673 Close: nushell#8277 Close: nushell#10944 This pr introduces the following syntax: 1. `e>|`, pipe stderr to next command. Example: `$env.FOO=bar nu --testbin echo_env_stderr FOO e>| str length` 2. `o+e>|` and `e+o>|`, pipe both stdout and stderr to next command, example: `$env.FOO=bar nu --testbin echo_env_mixed out-err FOO FOO e+o>| str length` Note: it only works for external commands. ~There is no different for internal commands, that is, the following three commands do the same things:~ Edit: it raises errors if we want to pipes for internal commands ``` ❯ ls e>| str length Error: × `e>|` only works with external streams ╭─[entry #1:1:1] 1 │ ls e>| str length · ─┬─ · ╰── `e>|` only works on external streams ╰──── ❯ ls e+o>| str length Error: × `o+e>|` only works with external streams ╭─[entry #2:1:1] 1 │ ls e+o>| str length · ──┬── · ╰── `o+e>|` only works on external streams ╰──── ``` This can help us to avoid some strange issues like the following: `$env.FOO=bar (nu --testbin echo_env_stderr FOO) e>| str length` Which is hard to understand and hard to explain to users. # User-Facing Changes Nan # Tests + Formatting To be done # After Submitting Maybe update documentation about these syntax.

amtoine added 9 commits April 8, 2023 17:32

use the names of the modules without path

d83ad30

refactor the library loading with add_file

f777993

add all the modules to the working set manually

1714691

refactor the main loading function

dcc2ef3

This commit puts all the "config" variables at the top.

rename modules into submodules

7b5325f

refactor the main std content in a variable

d72c5ac

format the code

1e17a12

make clippy happy

2b30839

Merge branch 'wip/refactor/stdlib/multi-module-library' into foo

0c7a68e

amtoine marked this pull request as draft April 8, 2023 17:11

amtoine marked this pull request as ready for review April 9, 2023 06:39

amtoine merged commit c3df973 into wip/refactor/stdlib/multi-module-library Apr 9, 2023
15 checks passed

amtoine deleted the wip/modular-nu-std/load-all-submodules branch April 9, 2023 06:40

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Wip/modular nu std/load all submodules #2

Wip/modular nu std/load all submodules #2

amtoine commented Apr 8, 2023 •

edited

Wip/modular nu std/load all submodules #2

Wip/modular nu std/load all submodules #2

Conversation

amtoine commented Apr 8, 2023 • edited

state

this proposal

amtoine commented Apr 8, 2023 •

edited