mirror of
https://github.com/nushell/nushell.git
synced 2025-05-02 00:54:25 +02:00
3bd45c005b
1595 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Darren Schroeder
|
a332712275
|
add function to make env vars case-insensitive (#14390)
# Description This PR adds a new function that allows one to get an env var case-insensitively. I did this so we can hopefully stop having problems when Windows has HKLM as path and HKCU as Path. Instead of just changing every function that used the original one, I chose the ones that I thought were specific to getting the path. I didn't want to go all in and make every env get case insensitive, but maybe we should? 🤷🏻♂️ closes #12676 # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # 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 > ``` --> # 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. --> |
||
PegasusPlusUS
|
c8b5909ee8
|
Feature: PWD-per-drive to facilitate working on multiple drives at Windows (#14411)
This PR implements PWD-per-drive as described in discussion #14355 # Description On Windows, CMD or PowerShell assigns each drive its own current directory. For example, if you are in 'C:\Windows', switch to 'D:', and navigate to 'D:\Game', you can return to 'C:\Windows' by simply typing 'C:'. This PR enables Nushell on Windows to have the same capability, allowing each drive to maintain its own PWD (Present Working Directory). # User-Facing Changes Currently, 'cd' or 'ls' only accept absolute paths if the path starts with 'C:' or another drive letter. With PWD-per-drive, users can use 'cd' (or auto cd) and 'ls' in the same way as 'cd' and 'dir' in PowerShell, or similarly to 'cd' and 'dir' in CMD (noting that cd in CMD has slightly different behavior, 'cd' for another drive only changes current directory of that drive, but does not switch there). Interaction example on switching between drives: ```Nushell ~>D: D:\>cd Test D:\Test\>C: ~>D: D:\Test\>C: ~>cd D:.. D:\>C:x/../y/../z/.. ~>cd D:Test\Test D:\Test\Test>C: ~>D:... D:\> ``` Interaction example on auto-completion at cmd line: ```Nushell ~>cd D:\test[Enter] D:\test>~[Enter] ~>D:[TAB] ~>D:\test[Enter] D:\test>c:.c[TAB] c:\users\nushell\.cargo\ c:\users\nushell\.config\ ``` Interaction example on pass PWD-per-drive to child process: (Note CMD will use it, but PowerShell will ignore it though it still prepares such info for child process) ```Nushell ~>cd D:\Test D:\Test>cd E:\Test E:\Test\>~ ~>CMD Microsoft Windows [Version 10.0.22631.4460] (c) Microsoft Corporation. All rights reserved. C:\Users\Nushell>d: D:\Test>e: E:\Test> ``` # Brief Change Description 1.Added 'crates/nu-path/src/pwd_per_drive.rs' to implement a 26-slot array mapping drive letters to PWDs. Test cases are included in the same file, along with a doctest for the usage of PWD-per-drive. 2. Modified 'crates/nu-path/src/lib.rs' to declare module of pwd_per_drive and export struct for PWD-per-drive. 3. Modified 'crates/nu-protocol/src/engine/stack.rs' to sync PWD when set_cwd() is called. Add PWD-per-drive map as member. Clone between parent and child. Stub/proxy for nu_path::expand_path_with() to facilitate filesystem commands using PWD-per-drive. 4. Modified 'crates/nu-cli/src/repl.rs' auto_cd uses PWD-per-drive to expand path. 5. Modified 'crates/nu-cli/src/completions/completion_common.rs' to expand relative path when press [TAB] at command line. 6. Modified 'crates/nu-engine/src/env.rs' to collect PWD-per-drive info as env vars for child process as CMD or PowerShell do, this can let child process inherit PWD-per-drive info. 7. Modified 'crates/nu-engine/src/eval.rs', caller clone callee's PWD-per-drive info, supporting 'def --env' 8. Modified 'crates/nu-engine/src/eval_ir.rs', 'def --env' support. Remove duplicated fn redirect_env() 9. Modified 'src/run.rs', to init PWD-per-drive when startup. filesystem commands that modified: 1. Modified 'crates/nu-command/src/filesystem/cd.rs', 1 line change to use stackscoped PWD-per-drive. Other commands, commit pending.... Local test def --env OK: ```nushell E:\study\nushell> def --env env_cd_demo [] { ::: cd ~ ::: cd D:\Project ::: cd E:Crates ::: } E:\study\nushell> E:\study\nushell> def cd_no_demo [] { ::: cd ~ ::: cd D:\Project ::: cd E:Crates ::: } E:\study\nushell> cd_no_demo E:\study\nushell> C: C:\>D: D:\>E: E:\study\nushell>env_cd_demo E:\study\nushell\crates> C: ~>D: D:\Project>E: E:\study\nushell\crates> ``` # Tests + Formatting - `cargo fmt --all -- --check` passed. - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` passed. - `cargo test --workspace` passed on Windows developer mode and Ubuntu. - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` passed. - nushell: ``` > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` passed --------- Co-authored-by: pegasus.cadence@gmail.com <pegasus.cadence@gmail.com> |
||
Piepmatz
|
3d5f853b03
|
Start to Add WASM Support Again (#14418)
<!-- 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. --> The [nushell/demo](https://github.com/nushell/demo) project successfully demonstrated running Nushell in the browser using WASM. However, the current version of Nushell cannot be easily built for the `wasm32-unknown-unknown` target, the default for `wasm-bindgen`. This PR introduces initial support for the `wasm32-unknown-unknown` target by disabling OS-dependent features such as filesystem access, IO, and platform/system-specific functionality. This separation is achieved using a new `os` feature in the following crates: - `nu-cmd-lang` - `nu-command` - `nu-engine` - `nu-protocol` The `os` feature includes all functionality that interacts with an operating system. It is enabled by default, but can be disabled using `--no-default-features`. All crates that depend on these core crates now use `--no-default-features` to allow compilation for WASM. To demonstrate compatibility, the following script builds all crates expected to work with WASM. Direct user interaction, running external commands, working with plugins, and features requiring `openssl` are out of scope for now due to their complexity or reliance on C libraries, which are difficult to compile and link in a WASM environment. ```nushell [ # compatible crates "nu-cmd-base", "nu-cmd-extra", "nu-cmd-lang", "nu-color-config", "nu-command", "nu-derive-value", "nu-engine", "nu-glob", "nu-json", "nu-parser", "nu-path", "nu-pretty-hex", "nu-protocol", "nu-std", "nu-system", "nu-table", "nu-term-grid", "nu-utils", "nuon" ] | each {cargo build -p $in --target wasm32-unknown-unknown --no-default-features} ``` ## Caveats This PR has a few caveats: 1. **`miette` and `terminal-size` Dependency Issue** `miette` depends on `terminal-size`, which uses `rustix` when the target is not Windows. However, `rustix` requires `std::os::unix`, which is unavailable in WASM. To address this, I opened a [PR](https://github.com/eminence/terminal-size/pull/68) for `terminal-size` to conditionally compile `rustix` only when the target is Unix. For now, the `Cargo.toml` includes patches to: - Use my forked version of `terminal-size`. - ~~Use an unreleased version of `miette` that depends on `terminal-size@0.4`.~~ These patches are temporary and can be removed once the upstream changes are merged and released. 2. **Test Output Adjustments** Due to the slight bump in the `miette` version, one test required adjustments to accommodate minor formatting changes in the error output, such as shifted newlines. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> This shouldn't break anything but allows using some crates for targeting `wasm32-unknown-unknown` to revive the demo page eventually. # 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` I did not add any extra tests, I just checked that compiling works, also when using the host target but unselecting the `os` feature. # 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. --> ~~Breaking the wasm support can be easily done by adding some `use`s or by adding a new dependency, we should definitely add some CI that also at least builds against wasm to make sure that building for it keep working.~~ I added a job to build wasm. --------- Co-authored-by: Ian Manske <ian.manske@pm.me> |
||
132ikl
|
e1f74a6d57
|
Add label rendering to try/catch rendered errors (#14477)
<!-- 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. --> Before this PR, you can access rendered error values that are raised in a `try/catch` block by accessing the `rendered` element of the catch error value: ``` $ try { ls nonexist.txt } catch {|e| print "my cool error:" $e.rendered } my cool error: nu:🐚:directory_not_found × Directory not found help: /home/rose/nonexist.txt does not exist ``` However, the rendered errors don't include the labels present in the real rendered error, which would look like this: ``` $ ls nonexist.txt Error: nu:🐚:directory_not_found × Directory not found ╭─[entry #46:1:4] 1 │ ls nonexist.txt · ──────┬───── · ╰── directory not found ╰──── help: /home/rose/nonexist.txt does not exist ``` After this PR, the rendered error includes the labels: ``` $ try { ls nonexist.txt } catch {|e| print "my cool error:" $e.rendered } my cool error: Error: nu:🐚:directory_not_found × Directory not found ╭─[entry #4:1:10] 1 │ try { ls nonexist.txt } catch {|e| print "my cool error:" $e.rendered } · ──────┬───── · ╰── directory not found ╰──── help: /home/rose/nonexist.txt does not exist ``` This change is accomplished by using the standard error formatting code to render an error. This respects the error theme as before without any extra scaffolding, but it means that e.g., the terminal size is also respected. I think this is fine because the way the error is rendered already changed based on config, and I think that a "rendered" error should give back _exactly_ what would be shown to the user anyway. @fdncred, let me know if you have any concerns with the way this is handled since you were the one who implemented this feature in the first place. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> The `rendered` element of the `try`/`catch` error record now includes labels in the error output. # 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. --> N/A |
||
Douglas
|
e17f6d654c
|
Deprecate date to-record and date to-table (#14319)
# Description Implements #11234 based on the comments there: * (Previously implemented): `into record` handles nanoseconds (as well as milliseconds and microseconds, which the deprecated commands didn't support). * Added deprecation warning to `date to-record` and `date to-table` * Added new example for `into record` showing the conversion to a table * Changed `std/dt` to use `into record` * Added "Deprecated" category back to nu-protocol::Signature * Assigned the deprecated commands to the Deprecated category so be categorized properly in the online Doc. # User-Facing Changes Deprecated command warning # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting Searched doc for existing uses of `date to-record` and `date to-table`: * For primary English-language docs, there are no uses other than in the auto-generated command help, which will be updated based on this PR * Other language translations appear to have an old use in several places and will need to be updated to match the English-language doc. |
||
Wind
|
817830940b
|
raise ParseError if assign to a non-variable or non-mutable-variable (#14405)
# Description While reviewing #14388, I think we can make some improvement on parser. For the following code: ```nushell let a = 3 a = 10 # should be error $a = 10 # another error ``` I think they can raise `ParseError`, so nushell doesn't need to move forward compiling IR block. # User-Facing Changes ```nushell let a = 3 a = 10 ``` Will raise parse error instead of compile error. # Tests + Formatting Added 1 test. |
||
Ian Manske
|
7f61cbbfd6
|
Add Filesize type (#14369)
# Description Adds a new `Filesize` type so that `FromValue` can be used to convert a `Value::Filesize` to a `Filesize`. Currently, to extract a filesize from a `Value` using `FromValue`, you have to extract an `i64` which coerces `Value::Int`, `Value::Duration`, and `Value::Filesize` to an `i64`. Having a separate type also allows us to enforce checked math to catch overflows. Similarly, it allows us to specify other trait implementations like `Display` in a common place. # User-Facing Changes Multiplication with filesizes now error on overflow. Should not be a breaking change for plugins (i.e., serialization) since `Filesize` is marked with `serde(transparent)`. # Tests + Formatting Updated some tests. |
||
|
Ian Manske
|
6bc695f251
|
Make Hooks fields non-optional to match the new config defaults (#14345)
# Description Follow up to #14341. Changes the fields of `Hooks` to `Vec` or `Hashmap` to match the new config defaults. # User-Facing Changes Mostly the same as #14341. `pre_prompt` and `pre_execution` must now be a list, and `env_change` must be a record. |
||
|
Wind
|
a13a024ac8
|
update miette to 7.3 (#14454)
# Description
The test is failed when updating miette from 7.2 to 7.3. After looking
into the test, I think it's ok to adjust test.
# User-Facing Changes
For the given custom command:
```nushell
def force_error [ x: any ] {
error make {
msg: "oh no!"
label: {
text: "here's the error"
span: (metadata $x).span
}
}
}
```
### Before
```
> force_error "My error"
Error: × oh no!
╭─[entry #8:1:13]
1 │ force_error "My error"
· ─────┬────
· ╰── here's the error
╰────
```
### After
```
> force_error "My error"
Error:
× oh no!
╭─[entry #9:1:13]
1 │ force_error "My error"
· ─────┬────
· ╰── here's the error
╰────
```
As we can see, the message `oh no!` is output in a new line, and there
is one less trailing line. I have makes some testing, and it seems that
it only happened on `error make` command.
# Tests + Formatting
Changed 1 test
# After Submitting
NaN
|
||
|
Ian Manske
|
4edce44689
|
Remove ListStream type (#14425)
# Description List values and list streams have the same type (`list<>`). Rather, streaming is a separate property of the pipeline/command output. This PR removes the unnecessary `ListStream` type. # User-Facing Changes Should be none, except `random dice` now has a more specific output type. |
||
|
Ian Manske
|
4d3283e235
|
Change append operator to concatenation operator (#14344)
# Description The "append" operator currently serves as both the append operator and the concatenation operator. This dual role creates ambiguity when operating on nested lists. ```nu [1 2] ++ 3 # appends a value to a list [1 2 3] [1 2] ++ [3 4] # concatenates two lists [1 2 3 4] [[1 2] [3 4]] ++ [5 6] # does this give [[1 2] [3 4] [5 6]] # or [[1 2] [3 4] 5 6] ``` Another problem is that `++=` can change the type of a variable: ```nu mut str = 'hello ' $str ++= ['world'] ($str | describe) == list<string> ``` Note that appending is only relevant for lists, but concatenation is relevant for lists, strings, and binary values. Additionally, appending can be expressed in terms of concatenation (see example below). So, this PR changes the `++` operator to only perform concatenation. # User-Facing Changes Using the `++` operator with a list and a non-list value will now be a compile time or runtime error. ```nu mut list = [] $list ++= 1 # error ``` Instead, concatenate a list with one element: ```nu $list ++= [1] ``` Or use `append`: ```nu $list = $list | append 1 ``` # After Submitting Update book and docs. --------- Co-authored-by: Douglas <32344964+NotTheDr01ds@users.noreply.github.com> |
||
Yash Thakur
|
671640b0a9
|
Avoid recomputing fuzzy match scores (#13700)
<!-- 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 makes it so that when using fuzzy matching, the score isn't recomputed when sorting. Instead, filtering and sorting suggestions is handled by a new `NuMatcher` struct. This struct accepts suggestions and, if they match the user's typed text, stores those suggestions (along with their scores and values). At the end, it returns a sorted list of suggestions. This probably won't have a noticeable impact on performance, but it might be helpful if we start using Nucleo in the future. Minor change: Makes `find_commands_by_predicate` in `StateWorkingSet` and `EngineState` take `FnMut` rather than `Fn` for the predicate. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> When using case-insensitive matching, if you have two matches `FOO` and `abc`, `abc` will be shown before `FOO` rather than the other way around. I think this way makes more sense than the current behavior. When I brought this up on Discord, WindSoilder did say it would make sense to show uppercase matches first if the user typed, say, `F`. However, that would be a lot more complicated to implement. # 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 > ``` --> Added a test for the changes in https://github.com/nushell/nushell/pull/13302. # 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. --> |
||
|
Ian Manske
|
d8c2493658
|
Deprecate split-by command (#14019)
# Description I'm not quite sure what the point of the `split-by` command is. The only example for the command seems to suggest it's an additional grouping command. I.e., a record that seems to be the output of the `group-by` command is passed to `split-by` which then adds an additional layer of grouping based on a different column. # User-Facing Changes Breaking change, deprecated the command. |
||
|
Douglas
|
4ed25b63a6
|
Always load default env/config values (#14249)
# Release-Notes Short Description * Nushell now always loads its internal `default_env.nu` before the user `env.nu` is loaded, then loads the internal `default_config.nu` before the user's `config.nu` is loaded. This allows for a simpler user-configuration experience. The Configuration Chapter of the Book will be updated soon with the new behavior. # Description Implements the main ideas in #13671 and a few more: * Users can now specify only the environment and config options they want to override in *their* `env.nu` and `config.nu`and yet still have access to all of the defaults: * `default_env.nu` (internally defined) will be loaded whenever (and before) the user's `env.nu` is loaded. * `default_config.nu` (internally defined) will be loaded whenever (and before) the user's `config.nu` is loaded. * No more 900+ line config out-of-the-box. * Faster startup (again): ~40-45% improvement in launch time with a default configuration. * New keys that are added to the defaults in the future will automatically be available to all users after updating Nushell. No need to regenerate config to get the new defaults. * It is now possible to have different internal defaults (which will be used with `-c` and scripts) vs. REPL defaults. This would have solved many of the user complaints about the [`display_errors` implementation](https://www.nushell.sh/blog/2024-09-17-nushell_0_98_0.html#non-zero-exit-codes-are-now-errors-toc). * A basic "scaffold" `config.nu` and `env.nu` are created on first launch (if the config directory isn't present). * Improved "out-of-the-box" experience (OOBE) - No longer asks to create the files; the minimal scaffolding will be automatically created. If deleted, they will not be regenerated. This provides a better "out-of-the-box" experience for the user as they no longer have to make this decision (without much info on the pros or cons) when first launching. * <s>(New: 2024-11-07) Runs the env_conversions process after the `default_env.nu` is loaded so that users can treat `Path`/`PATH` as lists in their own config.</s> * (New: 2024-11-08) Given the changes in #13802, `default_config.nu` will be a minimal file to minimize load-times. This shaves another (on my system) ~3ms off the base launch time. * Related: Keybindings, menus, and hooks that are already internal defaults are no longer duplicated in `$env.config`. The documentation will be updated to cover these scenarios. * (New: 2024-11-08) Move existing "full" `default_config.nu` to `sample_config.nu` for short-term "documentation" purposes. * (New: 2024-11-18) Move the `dark-theme` and `light-theme` to Standard Library and demonstrate their use - Also improves startup times, but we're reaching the limit of optimization. * (New: 2024-11-18) Extensively documented/commented `sample_env.nu` and `sample_config.nu`. These can be displayed in-shell using (for example) `config nu --sample | nu-highlight | less -R`. Note: Much of this will eventually be moved to or (some) duplicated in the Doc. But for now, this some nice in-shell doc that replaces the older "commented/documented default". * (New: 2024-11-20) Runs the `ENV_CONVERSIONS` process (1) after the `default_env.nu` (allows `PATH` to be used as a list in user's `env.nu`) and (2) before `default_config.nu` is loaded (allows user's `ENV_CONVERSIONS` from their `env.nu` to be used in their `config.nu`). * <s>(New: 2024-11-20) The default `ENV_CONVERSIONS` is now an empty record. The internal Rust code handles `PATH` (and variants) conversions regardless of the `ENV_CONVERSIONS` variable. This shaves a *very* small amount of time off the startup.</s> Reset - Looks like there might be a bug in `nu-enginer::env::ensure_path()` on Windows that would need to be fixed in order for this to work. # User-Facing Changes By default, you shouldn't see much, if any, change when running this with your existing configuration. To see the greatest benefit from these changes, you'll probably want to start with a "fresh" config. This can be easily tested using something like: ```nushell let temp_home = (mktemp -d) $env.XDG_CONFIG_HOME = $temp_home $env.XDG_DATA_HOME = $temp_home ./target/release/nu ``` You should see a message where the (mostly empty) `env.nu` and `config.nu` are created on first start. Defaults should be the same (or similar to) those before the PR. Please let me know if you notice any differences. --- Users should now specify configuration in terms of overrides of each setting. For instance, rather than modifying `history` settings in the monolithic `config.nu`, the following is recommended in an updated `config.nu`: ```nu $env.config.history = { file_format: sqlite, sync_on_enter: true isolation: true max_size: 1_000_000 } ``` or even just: ```nu $env.config.history.file_format = sqlite $env.config.history.isolation: true $env.config.history.max_size = 1_000_000 ``` Note: It seems many users are already appending a `source my_config.nu` (or similar pattern) to the end of the existing `config.nu` to make updates easier. In this case, they will likely want to remove all of the previous defaults and just move their `my_config.nu` to `config.nu`. Note: It should be unlikely that there are any breaking changes here, but there's a slim chance that some code, somewhere, *expects* an absence of certain config values. Otherwise, all config values are available before and after this change. # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting Configuration Chapter (and related) of the doc is currently WIP and will be finished in time for 0.101 release. |
||
dependabot[bot]
|
a6e3470c6f
|
Bump thiserror from 1.0.69 to 2.0.3 (#14394)
Bumps [thiserror](https://github.com/dtolnay/thiserror) from 1.0.69 to 2.0.3. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/dtolnay/thiserror/releases">thiserror's releases</a>.</em></p> <blockquote> <h2>2.0.3</h2> <ul> <li>Support the same Path field being repeated in both Debug and Display representation in error message (<a href="https://redirect.github.com/dtolnay/thiserror/issues/383">#383</a>)</li> <li>Improve error message when a format trait used in error message is not implemented by some field (<a href="https://redirect.github.com/dtolnay/thiserror/issues/384">#384</a>)</li> </ul> <h2>2.0.2</h2> <ul> <li>Fix hang on invalid input inside #[error(...)] attribute (<a href="https://redirect.github.com/dtolnay/thiserror/issues/382">#382</a>)</li> </ul> <h2>2.0.1</h2> <ul> <li>Support errors that contain a dynamically sized final field (<a href="https://redirect.github.com/dtolnay/thiserror/issues/375">#375</a>)</li> <li>Improve inference of trait bounds for fields that are interpolated multiple times in an error message (<a href="https://redirect.github.com/dtolnay/thiserror/issues/377">#377</a>)</li> </ul> <h2>2.0.0</h2> <h2>Breaking changes</h2> <ul> <li> <p>Referencing keyword-named fields by a raw identifier like <code>{r#type}</code> inside a format string is no longer accepted; simply use the unraw name like <code>{type}</code> (<a href="https://redirect.github.com/dtolnay/thiserror/issues/347">#347</a>)</p> <p>This aligns thiserror with the standard library's formatting macros, which gained support for implicit argument capture later than the release of this feature in thiserror 1.x.</p> <pre lang="rust"><code>#[derive(Error, Debug)] #[error("... {type} ...")] // Before: {r#type} pub struct Error { pub r#type: Type, } </code></pre> </li> <li> <p>Trait bounds are no longer inferred on fields whose value is shadowed by an explicit named argument in a format message (<a href="https://redirect.github.com/dtolnay/thiserror/issues/345">#345</a>)</p> <pre lang="rust"><code>// Before: impl<T: Octal> Display for Error<T> // After: impl<T> Display for Error<T> #[derive(Error, Debug)] #[error("{thing:o}", thing = "...")] pub struct Error<T> { thing: T, } </code></pre> </li> <li> <p>Tuple structs and tuple variants can no longer use numerical <code>{0}</code> <code>{1}</code> access at the same time as supplying extra positional arguments for a format message, as this makes it ambiguous whether the number refers to a tuple field vs a different positional arg (<a href="https://redirect.github.com/dtolnay/thiserror/issues/354">#354</a>)</p> <pre lang="rust"><code>#[derive(Error, Debug)] #[error("ambiguous: {0} {}", $N)] // ^^^ Not allowed, use #[error("... {0} {n}", n = $N)] pub struct TupleError(i32); </code></pre> </li> <li> <p>Code containing invocations of thiserror's <code>derive(Error)</code> must now have a direct dependency on the <code>thiserror</code> crate regardless of the error data structure's contents (<a href="https://redirect.github.com/dtolnay/thiserror/issues/368">#368</a>, <a href="https://redirect.github.com/dtolnay/thiserror/issues/369">#369</a>, <a href="https://redirect.github.com/dtolnay/thiserror/issues/370">#370</a>, <a href="https://redirect.github.com/dtolnay/thiserror/issues/372">#372</a>)</p> </li> </ul> <h2>Features</h2> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
132ikl
|
d69e131450
|
Rely on display_output hook for formatting values from evaluations (#14361)
# Description I was reading through the documentation yesterday, when I stumbled upon [this section](https://www.nushell.sh/book/pipelines.html#behind-the-scenes) explaining how command output is formatted using the `table` command. I was surprised that this section didn't mention the `display_output` hook, so I took a look in the code and was shocked to discovered that the documentation was correct, and the `table` command _is_ automatically applied to printed pipelines. This auto-tabling has two ramifications for the `display_output` hook: 1. The `table` command is called on the output of a pipeline after the `display_output` has run, even if `display_output` contains the table command. This means each pipeline output is roughly equivalent to the following (using `ls` as an example): ```nushell ls | do $config.hooks.display_output | table ``` 2. If `display_output` returns structured data, it will _still_ be formatted through the table command. This PR removes the auto-table when the `display_output` hook is set. The auto-table made sense before `display_output` was introduced, but to me, it now seems like unnecessary "automagic" which can be accomplished using existing Nushell features. This means that you can now pull back the curtain a bit, and replace your `display_output` hook with an empty closure (`$env.config.hooks.display_output = {||}`, setting it to null retains the previous behavior) to see the values printed normally without the table formatting. I think this is a good thing, and makes it easier to understand Nushell fundamentals. It is important to note that this PR does not change how `print` and other commands (well, specifically only `watch`) print out values. They continue to use `table` with no arguments, so changing your config/`display_output` hook won't affect what `print`ing a value does. Rel: [Discord discussion](https://discord.com/channels/601130461678272522/615329862395101194/1307102690848931904) (cc @dcarosone) # User-Facing Changes Pipelines are no longer automatically formatted using the `table` command. Instead, the `display_output` hook is used to format pipeline output. Most users should see no impact, as the default `display_output` hook already uses the `table` command. # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting Will update mentioned docs page to call out `display_output` hook. |
||
|
Douglas
|
8c1ab7e0a3
|
Add proper config defaults for hooks (#14341)
# Release Notes Excerpt
* Hooks now default to an empty value of the proper type (e.g., `[]` or
`{}`) when not otherwise specified
# Description
```nushell
# Start with no config
nu -n
# Populate with defaults
$env.config = {}
$env.config.hooks
```
* Before: All hooks other than `display_output` were set to `null`.
Attempting to append a hook using `++=` would fail unless it had already
been assigned.
* After:
* `pre_prompt`, `pre_execution`, and `command_not_found` are set to
empty lists. This allows the user to simply append new hooks using
`++=`.
* `env_change` is set to an empty record. This allows the user to add
new hooks using `merge`, although a "helper" command would still be
useful (TODO: stdlib).
Also fixed a typo in an error message.
# User-Facing Changes
There shouldn't be any breaking changes since (before) there were no
guarantees of the hook's value/type. Previously, users would have to
check for `null` and `default` to an empty list before appending. Any
user-strategies for dealing with the problem should continue to work
after this change.
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
Note that, for reasons I cannot ascertain, this PR appears to have
*fixed* the `command_not_found_error_recognizes_non_executable_file`
test that was previously broken by #12953. That PR essentially rewrote
the test to match the new behavior, but it no longer tested what it was
intended to test.
Now, the test is working again as designed (and as it works in the
REPL).
# After Submitting
This will be covered in the Configuration update for #14249. This PR
will simplify several examples in the doc.
|
||
Devyn Cairns
|
215ca6c5ca
|
Remove the NU_DISABLE_IR option (#14293)
# Description Removes the `NU_DISABLE_IR` option and some code related to evaluating blocks with the AST evaluator. Does not entirely remove the AST evaluator yet. We still have some dependencies on expression evaluation in a few minor places which will take a little bit of effort to fix. Also changes `debug profile` to always include instructions, because the output is a little confusing otherwise, and removes the different options for instructions/exprs. # User-Facing Changes - `NU_DISABLE_IR` no longer has any effect, and is removed. There is no way to use the AST evaluator. - `debug profile` no longer has `--exprs`, `--instructions` options. - `debug profile` lists `pc` and `instruction` columns by default now. # Tests + Formatting Eval tests fixed to only use IR. # After Submitting - [ ] release notes - [ ] finish removing AST evaluator, come up with solutions for the expression evaluation. |
||
|
Douglas
|
f0cb2dafbb
|
Allow duration to be added to date (#14295)
# Description Fixes #14294 - Turned out to be a whole lot easier than I expected, but please double-check me on this, since it's an area I haven't been in before. # User-Facing Changes Allow date to be added to a duration type. # Tests + Formatting Tests added: * Duration + Date is allowed * Duration - Date is not allowed |
||
Justin Ma
|
e6f55da080
|
Bump to dev version 0.100.1 (#14328) | ||
|
Justin Ma
|
c9409a2edb
|
Bump version to 0.100.0 (#14312)
<!-- 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. --> Bump version to `0.100.0` # User-Facing Changes The new release `v0.100.0` is coming... |
||
|
Ian Manske
|
e87a35104a
|
Remove as_i64 and as_f64 (#14258)
# Description Turns out there are duplicate conversion functions: `as_i64` and `as_f64`. In most cases, these can be replaced with `as_int` and `as_float`, respectively. |
||
|
Ian Manske
|
9f09930834
|
Div, mod, and floor div overhaul (#14157)
# Description Dividing two ints can currently return either an int or a float. Not having a single return type for an operation between two types seems problematic. Additionally, the type signature for division says that dividing two ints returns only an int which does not match the current implementation (it can also return a float). This PR changes division between almost all types to return a float (except for `filesize / number` or `duration / number`, since there are no float representations for these types). Currently, floor division between certain types is not implemented even though the type signature allows it. Also, the current implementation of floor division uses a combination of clamping and flooring rather than simply performing floor division which this PR fixes. Additionally, the signature was changed so that `int // float`, `float // int`, and `float // float` now return float instead of int. This matches the automatic float promotion in the rest of the operators (as well as how Python does floor division which I think is the original inspiration). Since regular division has always returned fractional values (and now returns a float to reflect that), `mod` is now defined in terms of floor division. That is, `D // d = q`, `D mod d = r`, and `D = d * q + r `. This is just like the `%` operator in Python, which is also based off floor division (at least for ints and floats). Additionally, implementations missing from `mod`'s current type signature have been added (`duration mod int` and `duration mod float`). This PR also overhauls the overflow checking and errors for div, mod, and floor div. If an operation overflows, it will now cause an error. # User-Facing Changes - Div now returns a float in most cases. - Floor division now actually does floor division. - Floor division now does automatic float promotion, returning a float in more instances. - Floor division now actually allows division with filesize and durations as its type signature claimed. - Mod is now defined and implemented in terms of floor division rather than truncating division. - Mod now actually allows filesize and durations as its type signature claimed. - Div, mod, and floor div now all have proper overflow checks. ## Examples When the divisor and the dividend have the same sign, the quotient and remainder will be the same as before. (Except that this PR will give more accurate results, since it does not do an intermediate float conversion). If the signs of the divisor and dividend are different, then the results will be different, or rather actually correct. Before: ```nu let q = 8 // -3 # -3 let r = 8 mod -3 # 2 8 == $q * -3 + $r # false ``` After: ```nu let q = 8 // -3 # -3 let r = 8 mod -3 # -1 8 == $q * -3 + $r # true ``` Before: ```nu let q = -8 // 3 # -3 let r = -8 mod 3 # -2 -8 == $q * 3 + $r # false ``` After: ```nu let q = -8 // 3 # -3 let r = -8 mod 3 # 1 -8 == $q * 3 + $r # true ``` # Tests + Formatting Added a few tests. # After Submitting Probably update the docs. |
||
Charles Taylor
|
20c2de9eed
|
Empty rest args match should be an empty list (#14246)
Fixes #14145 # User-Facing Changes An empty rest match would be `null` previously. Now it will be an empty list. This is a breaking change for any scripts relying on the old behavior. Example script: ```nu match [1] { [_ ..$rest] => { match $rest { null => { "old" } [] => { "new" } } } } ``` This expression would evaluate to "old" on current nu versions and "new" with this patch. |
||
Alex Ionescu
|
1c3ff179bc
|
Improve CellPath display output (#14197)
<!-- 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. --> Fixes: #13362 This PR fixes the `Display` impl for `CellPath`, as laid out in #13362 and #14090: ```nushell > $.0."0" $.0."0" > $."foo.bar".baz $."foo.bar".baz ``` # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> Cell-paths are now printed using the same `$.` notation that is used to create them, and ambiguous column names are properly quoted. # 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 > ``` --> # 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. --> |
||
|
Alex Ionescu
|
03015ed33f
|
Show ? for optional entries when displaying CellPaths (#14042)
<!-- 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 makes the `Display` implementation for `CellPath` show a `?` suffix on every optional entry, which makes the output consistent with the language syntax. Before this PR, the printing of cell paths was confusing, e.g. `$.x` and `$.x?` were both printed as `x`. Now, the second one is printed as `x?`. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> The formatting of cell paths now matches the syntax used to create them, reducing confusion. # 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 > ``` --> All tests pass, including `stdlib` tests. # 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. --> |
||
|
Darren Schroeder
|
69d81cc065
|
add command_type to help (#14165)
# Description This PR adds an indicator when listing subcommands. That indicator tells whether the command is a plugin, alias, or custom_command.  I changed some of the API to make this work a little easier, namely `get_signatures()` is now `get_signatures_and_declids()`. It was used in only one other place (run-external), so I thought it was fine to change it. There is a long-standing issue with aliases where they reference the command name instead of the alias name. This PR doesn't fix that bug. Example. ```nushell ❯ alias "str fill" = str wrap ``` ```nushell ❯ str ... other stuff Subcommands: str wrap (alias) - Alias for `str wrap` str wrap (plugin) - Wrap text passed into pipeline. ``` # User-Facing Changes Slightly different output of subcommands. |
||
|
Darren Schroeder
|
af9c31152a
|
Add metadata on open --raw with bytestreams (#14141)
# Description This PR closes #14137 and allows the display hook to be set on byte streams. So, with a hook like this below. ```nushell display_output: { metadata access {|meta| match $meta.content_type? { "application/x-nuscript" | "application/x-nuon" | "text/x-nushell" => { nu-highlight }, "application/json" => { ^bat --language=json --color=always --style=plain --paging=never }, _ => {}, } } | table } ``` You could type `open toolkit.nu` and the text of toolkit.nu would be highlighted by nu-highlight. This PR also changes the way content-type is assigned with `open`. Previously it would only assign it if `--raw` was specified. Lastly, it changes the `is_external()` function to only say `ByteStreamSource::Child`'s are external instead of both Child and `ByteStreamSource::File`. Again, this was to allow the hook to function properly. I'm not sure what negative ramifications changing `is_external()` could have, but there may be some? # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # 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 > ``` --> # 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. --> |
||
Maxim Zhiburt
|
3ec1c40320
|
Introduce footer_inheritance option (#14070)
```nu $env.config.table.footer_inheritance = true ``` close #14060 |
||
|
Darren Schroeder
|
3a685049da
|
add name to $env.config.keybindings (#14159)
# Description This PR adds the `name` column back to keybindings. This may be considered a hack since the reedline keybinding has no spot for name, but it seems to work. |
||
Joaquín Triñanes
|
f738932bbd
|
Fix range contains (#14011)
# Description This PR changes the range contains logic to take the step into account. ```nushell # before 2 in 1..3.. # true # now 2 in 1..3.. # false ``` --- I encountered another issue while adding tests. Due to floating point precision, `2.1 in 1..1.1..3` will return `false`. The floating point error is even bigger than `f64::EPSILON` (`0.09999999999999876` vs `2.220446049250313e-16`). This issue disappears with bigger numbers. I tried a different algorithm (checking if the estimated number of steps is close enough to any integer) but the results are still pretty bad: ```rust let n_steps = (value - self.start) / self.step; // 14.999999999999988 (n_steps - n_steps.round()).abs() < f64::EPSILON // returns false ``` Maybe it can be shipped like this, the REPL already has floating point errors (`1.1 - 1` returns `0.10000000000000009`). Or maybe there's a way to fix this that I didn't think of. I'm open to ideas! But in any case performing this kind of checks on a range of floats seems more niche than doing it on a range of ints. # User-Facing Changes Code that depended on this behavior to check if a number is between `start` and `end` will potentially return a different value. # Tests + Formatting # After Submitting |
||
|
Darren Schroeder
|
8c8f795e9e |
add rendered and json error messages in try/catch (#14082)
# Description This PR adds a couple more options for dealing with try/catch errors. It adds a `json` version of the error and a `rendered` version of the error. It also respects the error_style configuration point.  # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # 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 > ``` --> # 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. --> |
||
|
Darren Schroeder
|
7e055810b1 |
add like and not-like operators as synonyms for the regex operators =~ and !~ (#14072)
# Description This PR adds `like` as a synonym for `=~` and `not-like` as a synonym for `!~`. This is mainly a quality-of-life change to help those people who think in sql.  closes #13261 # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # 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 > ``` --> # 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. --> |
||
|
Wind
|
d7014e671d |
use command: Don't create a variable with empty record if it doesn't define any constants (#14051)
# Description Fixes: #13967 The key changes lays in `nu-protocol/src/module.rs`, when resolving import pattern, nushell only needs to bring `$module` with a record value if it defines any constants. # User-Facing Changes ```nushell module spam {} use spam ``` Will no longer create a `$spam` variable with an empty record. # Tests + Formatting Adjusted some tests and added some tests. |
||
Stefan Holderbach
|
f061c9a30e
|
Bump to 0.99.2 (#14136) | ||
|
Ian Manske
|
e911ff4d67
|
Fix return setting last exit code (#14120)
# Description Fixes #14113 and #14112. # Tests + Formatting Added a test. |
||
|
Ian Manske
|
28b6db115a
|
Revert PRs for 0.99.1 patch (#14119)
# Description Temporarily reverts PRs merged after the 0.99.1 bump. |
||
|
Darren Schroeder
|
e735bd475f
|
add rendered and json error messages in try/catch (#14082)
# Description This PR adds a couple more options for dealing with try/catch errors. It adds a `json` version of the error and a `rendered` version of the error. It also respects the error_style configuration point.  # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # 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 > ``` --> # 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. --> |
||
|
Darren Schroeder
|
043d1ed9fb
|
add like and not-like operators as synonyms for the regex operators =~ and !~ (#14072)
# Description This PR adds `like` as a synonym for `=~` and `not-like` as a synonym for `!~`. This is mainly a quality-of-life change to help those people who think in sql.  closes #13261 # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # 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 > ``` --> # 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. --> |
||
|
Wind
|
71b49c3374
|
use command: Don't create a variable with empty record if it doesn't define any constants (#14051)
# Description Fixes: #13967 The key changes lays in `nu-protocol/src/module.rs`, when resolving import pattern, nushell only needs to bring `$module` with a record value if it defines any constants. # User-Facing Changes ```nushell module spam {} use spam ``` Will no longer create a `$spam` variable with an empty record. # Tests + Formatting Adjusted some tests and added some tests. |
||
|
Devyn Cairns
|
59d6dee3b3
|
Bump to version 0.99.1 (#14100)
Post-release patch bump. |
||
Jakub Žádník
|
91ff57faa7
|
Bump to version 0.99.0 (#14094)
<!-- 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. --> # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # 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 > ``` --> # 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. --> |
||
|
Wind
|
639bd4fc2e
|
change display_error.exit_code to false (#13873)
The idea comes from @amtoine, I think it would be good to keey `display_error.exit_code` same value, if user is using default config or using no config file at all. |
||
|
Ian Manske
|
de08b68ba8
|
Fix try printing when it is not the last pipeline element (#13992)
# Description Fixes #13991. This was done by more clearly separating the case when a pipeline is drained vs when it is being written (to a file). I also added an `OutDest::Print` case which might not be strictly necessary, but is a helpful addition. # User-Facing Changes Bug fix. # Tests + Formatting Added a test. # After Submitting There are still a few redirection bugs that I found, but they require larger code changes, so I'll leave them until after the release. |
||
|
Darren Schroeder
|
389e7d2502
|
make FooterMode::Auto work (#14063)
# Description @Yethal discovered that `FooterMode::Auto` in the config as `$env.config.footer_mode = auto` did not work. This PR attempts to fix that problem by implementing the auto algorithm that was already supposed to work. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # 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 > ``` --> # 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. --> |
||
|
Ian Manske
|
fce6146576
|
Refactor config updates (#13802)
# Description This PR standardizes updates to the config through a new `UpdateFromValue` trait. For now, this trait is private in case we need to make changes to it. Note that this PR adds some additional `ShellError` cases to create standard error messages for config errors. A follow-up PR will move usages of the old error cases to these new ones. This PR also uses `Type::custom` in lots of places (e.g., for string enums). Not sure if this is something we want to encourage. # User-Facing Changes Should be none. |
||
Piotr Kufel
|
bcb7ef48b6
|
Reduce duplication in history path construction (#13475)
# Description Currently there is a bit of chaos regarding construction of history file paths. Various pieces of code across a number of crates reimplement the same/similar logic: - There is `get_history_path`, but it requires a directory parameter (it really just joins it with a file name). - Some places use a const for the directory parameter, others use a string literal - in all cases the value seems to be `"nushell"`. - Some places assume the `"nushell"` value, other plumb it down from close to the top of the call stack. - Some places use a constant for history file names while others assume it. This PR tries to make it so that the history/config path format is defined in a single places and so dependencies on it are easier to follow: - It removes `get_history_path` and adds a `file_path` method to `HistoryConfig` instead (an extra motivation being, this is a convenient place that can be used from all creates that need a history file path) - Adds a `nu_config_dir` function that returns the nushell configuration directory. - Updates existing code to rely on the above, effectively removing duplicate uses of `"nushell"` and `NUSHELL_FOLDER` and assumptions about file names associated with different history formats # User-Facing Changes None |
||
|
132ikl
|
36c1073441
|
Rework sorting and add cell path and closure comparators to sort-by (#13154)
# Description Closes #12535 Implements sort-by functionality of #8322 Fixes sort-by part of #8667 This PR does two main things: add a new cell path and closure parameter to `sort-by`, and attempt to make Nushell's sorting behavior well-defined. ## `sort-by` features The `columns` parameter is replaced with a `comparator` parameter, which can be a cell path or a closure. Examples are from docs PR. 1. Cell paths The basic interactive usage of `sort-by` is the same. For example, `ls | sort-by modified` still works the same as before. It is not quite a drop-in replacement, see [behavior changes](#behavior-changes). Here's an example of how the cell path comparator might be useful: ```nu > let cities = [ {name: 'New York', info: { established: 1624, population: 18_819_000 } } {name: 'Kyoto', info: { established: 794, population: 37_468_000 } } {name: 'São Paulo', info: { established: 1554, population: 21_650_000 } } ] > $cities | sort-by info.established ╭───┬───────────┬────────────────────────────╮ │ # │ name │ info │ ├───┼───────────┼────────────────────────────┤ │ 0 │ Kyoto │ ╭─────────────┬──────────╮ │ │ │ │ │ established │ 794 │ │ │ │ │ │ population │ 37468000 │ │ │ │ │ ╰─────────────┴──────────╯ │ │ 1 │ São Paulo │ ╭─────────────┬──────────╮ │ │ │ │ │ established │ 1554 │ │ │ │ │ │ population │ 21650000 │ │ │ │ │ ╰─────────────┴──────────╯ │ │ 2 │ New York │ ╭─────────────┬──────────╮ │ │ │ │ │ established │ 1624 │ │ │ │ │ │ population │ 18819000 │ │ │ │ │ ╰─────────────┴──────────╯ │ ╰───┴───────────┴────────────────────────────╯ ``` 2. Key closures You can supply a closure which will transform each value into a sorting key (without changing the underlying data). Here's an example of a key closure, where we want to sort a list of assignments by their average grade: ```nu > let assignments = [ {name: 'Homework 1', grades: [97 89 86 92 89] } {name: 'Homework 2', grades: [91 100 60 82 91] } {name: 'Exam 1', grades: [78 88 78 53 90] } {name: 'Project', grades: [92 81 82 84 83] } ] > $assignments | sort-by { get grades | math avg } ╭───┬────────────┬───────────────────────╮ │ # │ name │ grades │ ├───┼────────────┼───────────────────────┤ │ 0 │ Exam 1 │ [78, 88, 78, 53, 90] │ │ 1 │ Project │ [92, 81, 82, 84, 83] │ │ 2 │ Homework 2 │ [91, 100, 60, 82, 91] │ │ 3 │ Homework 1 │ [97, 89, 86, 92, 89] │ ╰───┴────────────┴───────────────────────╯ ``` 3. Custom sort closure The `--custom`, or `-c`, flag will tell `sort-by` to interpret closures as custom sort closures. A custom sort closure has two parameters, and returns a boolean. The closure should return `true` if the first parameter comes _before_ the second parameter in the sort order. For a simple example, we could rewrite a cell path sort as a custom sort (see [here](https://github.com/nushell/nushell.github.io/pull/1568/files#diff-a7a233e66a361d8665caf3887eb71d4288000001f401670c72b95cc23a948e86R231) for a more complex example): ```nu > ls | sort-by -c {|a, b| $a.size < $b.size } ╭───┬─────────────────────┬──────┬──────────┬────────────────╮ │ # │ name │ type │ size │ modified │ ├───┼─────────────────────┼──────┼──────────┼────────────────┤ │ 0 │ my-secret-plans.txt │ file │ 100 B │ 10 minutes ago │ │ 1 │ shopping_list.txt │ file │ 100 B │ 2 months ago │ │ 2 │ myscript.nu │ file │ 1.1 KiB │ 2 weeks ago │ │ 3 │ bigfile.img │ file │ 10.0 MiB │ 3 weeks ago │ ╰───┴─────────────────────┴──────┴──────────┴────────────────╯ ``` ## Making sort more consistent I think it's important for something as essential as `sort` to have well-defined semantics. This PR contains some changes to try to make the behavior of `sort` and `sort-by` consistent. In addition, after working with the internals of sorting code, I have a much deeper understanding of all of the edge cases. Here is my attempt to try to better define some of the semantics of sorting (if you are just interested in changes, skip to "User-Facing changes") - `sort`, `sort -v`, and `sort-by` now all work the same. Each individual sort implementation has been refactored into two functions in `sort_utils.rs`: `sort`, and `sort_by`. These can also be used in other parts of Nushell where values need to be sorted. - `sort` and `sort-by` used to handle `-i` and `-n` differently. - `sort -n` would consider all values which can't be coerced into a string to be equal - `sort-by -i` and `sort-by -n` would only work if all values were strings - In this PR, insensitive sort only affects comparison between strings, and natural sort only applies to numbers and strings (see below). - (not a change) Before and after this PR, `sort` and `sort-by` support sorting mixed types. There was a lot of discussion about potentially making `sort` and `sort-by` only work on lists of homogeneous types, but the general consensus was that `sort` should not error just because its input contains incompatible types. - In order to try to make working with data containing `null` values easier, I changed the PartialOrd order to sort `Nothing` values to the end of a list, regardless of what other types the list contains. Before, `null` would be sorted before `Binary`, `CellPath`, and `Custom` values. - (not a change) When sorted, lists of mixed types will contain sorted values of each type in order, for the most part - (not a change) For example, `[0x[1] (date now) "a" ("yesterday" | into datetime) "b" 0x[0]]` will be sorted as `["a", "b", a day ago, now, [0], [1]]`, where sorted strings appear first, then sorted datetimes, etc. - (not a change) The exception to this is `Int`s and `Float`s, which will intermix, `Strings` and `Glob`s, which will intermix, and `None` as described above. Additionally, natural sort will intermix strings with ints and floats (see below). - Natural sort no longer coerce all inputs to strings. - I did originally make natural only apply to strings, but @fdncred pointed out that the previous behavior also allowed you to sort numeric strings with numbers. This seems like a useful feature if we are trying to support sorting with mixed types, so I settled on coercing only numbers (int, float). This can be reverted if people don't like it. - Here is an example of this behavior in action, which is the same before and after this PR: ```nushell $ [1 "4" 3 "2"] | sort --natural ╭───┬───╮ │ 0 │ 1 │ │ 1 │ 2 │ │ 2 │ 3 │ │ 3 │ 4 │ ╰───┴───╯ ``` # User-Facing Changes ## New features - Replaces the `columns` string parameter of `sort-by` with a cell path or a closure. - The cell path parameter works exactly as you would expect - By default, the `closure` parameter acts as a "key sort"; that is, each element is transformed by the closure into a sorting key - With the `--custom` (`-c`) parameter, you can define a comparison function for completely custom sorting order. ## Behavior changes <details> <summary><code>sort -v</code> does not coerce record values to strings</summary> This was a bit of a surprising behavior, and is now unified with the behavior of `sort` and `sort-by`. Here's an example where you can observe the values being implicitly coerced into strings for sorting, as they are sorted like strings rather than numbers: Old behavior: ```nushell $ {foo: 9 bar: 10} | sort -v ╭─────┬────╮ │ bar │ 10 │ │ foo │ 9 │ ╰─────┴────╯ ``` New behavior: ```nushell $ {foo: 9 bar: 10} | sort -v ╭─────┬────╮ │ foo │ 9 │ │ bar │ 10 │ ╰─────┴────╯ ``` </details> <details> <summary>Changed <code>sort-by</code> parameters from <code>string</code> to <code>cell-path</code> or <code>closure</code>. Typical interactive usage is the same as before, but if passing a variable to <code>sort-by</code> it must be a cell path (or closure), not a string</summary> Old behavior: ```nushell $ let sort = "modified" $ ls | sort-by $sort ╭───┬──────┬──────┬──────┬────────────────╮ │ # │ name │ type │ size │ modified │ ├───┼──────┼──────┼──────┼────────────────┤ │ 0 │ foo │ file │ 0 B │ 10 hours ago │ │ 1 │ bar │ file │ 0 B │ 35 seconds ago │ ╰───┴──────┴──────┴──────┴────────────────╯ ``` New behavior: ```nushell $ let sort = "modified" $ ls | sort-by $sort Error: nu:🐚:type_mismatch × Type mismatch. ╭─[entry #10:1:14] 1 │ ls | sort-by $sort · ──┬── · ╰── Cannot sort using a value which is not a cell path or closure ╰──── $ let sort = $."modified" $ ls | sort-by $sort ╭───┬──────┬──────┬──────┬───────────────╮ │ # │ name │ type │ size │ modified │ ├───┼──────┼──────┼──────┼───────────────┤ │ 0 │ foo │ file │ 0 B │ 10 hours ago │ │ 1 │ bar │ file │ 0 B │ 2 minutes ago │ ╰───┴──────┴──────┴──────┴───────────────╯ ``` </details> <details> <summary>Insensitve and natural sorting behavior reworked</summary> Previously, the `-i` and `-n` worked differently for `sort` and `sort-by` (see "Making sort more consistent"). Here are examples of how these options result in different sorts now: 1. `sort -n` - Old behavior (types other than numbers, strings, dates, and binary sorted incorrectly) ```nushell $ [2sec 1sec] | sort -n ╭───┬──────╮ │ 0 │ 2sec │ │ 1 │ 1sec │ ╰───┴──────╯ ``` - New behavior ```nushell $ [2sec 1sec] | sort -n ╭───┬──────╮ │ 0 │ 1sec │ │ 1 │ 2sec │ ╰───┴──────╯ ``` 2. `sort-by -i` - Old behavior (uppercase words appear before lowercase words as they would in a typical sort, indicating this is not actually an insensitive sort) ```nushell $ ["BAR" "bar" "foo" 2 "FOO" 1] | wrap a | sort-by -i a ╭───┬─────╮ │ # │ a │ ├───┼─────┤ │ 0 │ 1 │ │ 1 │ 2 │ │ 2 │ BAR │ │ 3 │ FOO │ │ 4 │ bar │ │ 5 │ foo │ ╰───┴─────╯ ``` - New behavior (strings are sorted stably, indicating this is an insensitive sort) ```nushell $ ["BAR" "bar" "foo" 2 "FOO" 1] | wrap a | sort-by -i a ╭───┬─────╮ │ # │ a │ ├───┼─────┤ │ 0 │ 1 │ │ 1 │ 2 │ │ 2 │ BAR │ │ 3 │ bar │ │ 4 │ foo │ │ 5 │ FOO │ ╰───┴─────╯ ``` 3. `sort-by -n` - Old behavior (natural sort does not work when data contains non-string values) ```nushell $ ["10" 8 "9"] | wrap a | sort-by -n a ╭───┬────╮ │ # │ a │ ├───┼────┤ │ 0 │ 8 │ │ 1 │ 10 │ │ 2 │ 9 │ ╰───┴────╯ ``` - New behavior ```nushell $ ["10" 8 "9"] | wrap a | sort-by -n a ╭───┬────╮ │ # │ a │ ├───┼────┤ │ 0 │ 8 │ │ 1 │ 9 │ │ 2 │ 10 │ ╰───┴────╯ ``` </details> <details> <summary> Sorting a list of non-record values with a non-existent column/path now errors instead of sorting the values directly (<code>sort</code> should be used for this, not <code>sort-by</code>) </summary> Old behavior: ```nushell $ [2 1] | sort-by foo ╭───┬───╮ │ 0 │ 1 │ │ 1 │ 2 │ ╰───┴───╯ ``` New behavior: ```nushell $ [2 1] | sort-by foo Error: nu:🐚:incompatible_path_access × Data cannot be accessed with a cell path ╭─[entry #29:1:17] 1 │ [2 1] | sort-by foo · ─┬─ · ╰── int doesn't support cell paths ╰──── ``` </details> <details> <summary><code>sort</code> and <code>sort-by</code> output <code>List</code> instead of <code>ListStream</code> </summary> This isn't a meaningful change (unless I misunderstand the purpose of ListStream), since `sort` and `sort-by` both need to collect in order to do the sorting anyway, but is user observable. Old behavior: ```nushell $ ls | sort | describe -d ╭──────────┬───────────────────╮ │ type │ stream │ │ origin │ nushell │ │ subtype │ {record 3 fields} │ │ metadata │ {record 1 field} │ ╰──────────┴───────────────────╯ ``` ```nushell $ ls | sort-by name | describe -d ╭──────────┬───────────────────╮ │ type │ stream │ │ origin │ nushell │ │ subtype │ {record 3 fields} │ │ metadata │ {record 1 field} │ ╰──────────┴───────────────────╯ ``` New behavior: ```nushell ls | sort | describe -d ╭────────┬─────────────────╮ │ type │ list │ │ length │ 22 │ │ values │ [table 22 rows] │ ╰────────┴─────────────────╯ ``` ```nushell $ ls | sort-by name | describe -d ╭────────┬─────────────────╮ │ type │ list │ │ length │ 22 │ │ values │ [table 22 rows] │ ╰────────┴─────────────────╯ ``` </details> - `sort` now errors when nothing is piped in (`sort-by` already did this) # Tests + Formatting I added lots of unit tests on the new sort implementation to enforce new sort behaviors and prevent regressions. # After Submitting See [docs PR](https://github.com/nushell/nushell.github.io/pull/1568), which is ~2/3 finished. --------- Co-authored-by: NotTheDr01ds <32344964+NotTheDr01ds@users.noreply.github.com> Co-authored-by: Ian Manske <ian.manske@pm.me> |
||
|
Douglas
|
27ebccce80
|
Set proc/env cwd to engine_state value (#14005)
# Description Fixes #14000 by once again calling `set_current_dir()`, but doing so with the `cwd` from the current state, rather than the (previously removed) argument to `merge_env()`. # User-Facing Changes Bug fix # Tests + Formatting If this looks good, I'll look at adding a test case for it. - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting N/A |
||
|
Douglas
|
00709fc5bd
|
Improves startup time when using std-lib (#13842)
Updated summary for commit [ |