Bump actions-rust-lang/setup-rust-toolchain from 1.4.4 to 1.5.0#2
Closed
dependabot[bot] wants to merge 1 commit intomainfrom
Closed
Conversation
Bumps [actions-rust-lang/setup-rust-toolchain](https://github.com/actions-rust-lang/setup-rust-toolchain) from 1.4.4 to 1.5.0. - [Release notes](https://github.com/actions-rust-lang/setup-rust-toolchain/releases) - [Changelog](https://github.com/actions-rust-lang/setup-rust-toolchain/blob/main/CHANGELOG.md) - [Commits](actions-rust-lang/setup-rust-toolchain@v1.4.4...v1.5.0) --- updated-dependencies: - dependency-name: actions-rust-lang/setup-rust-toolchain dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
bot
added
dependencies
Author
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
dependabot
bot
deleted the
dependabot/github_actions/actions-rust-lang/setup-rust-toolchain-1.5.0
branch
hustcer
pushed a commit
that referenced
this pull request
Jun 19, 2023
# Description Fixes a small bug with `rm` where names of files which couldn't be deleted due to error were not printed. Fixes nushell/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
hustcer
pushed a commit
that referenced
this pull request
Jul 21, 2023
# 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
hustcer
pushed a commit
that referenced
this pull request
Aug 3, 2023
# 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
<!-- 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- -c "use std testing; testing run-tests --path
crates/nu-std"` 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.
-->
hustcer
pushed a commit
that referenced
this pull request
Aug 5, 2023
# 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 <!-- 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 -A clippy::needless_collect -A clippy::result_large_err` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass - `cargo run -- -c "use std testing; testing run-tests --path crates/nu-std"` 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. -->
hustcer
pushed a commit
that referenced
this pull request
Aug 28, 2023
- Hopefully closes #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 <!-- 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 std testing; testing run-tests --path crates/nu-std"` 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 There's a PR updating the docs over here nushell/nushell.github.io#1026
hustcer
pushed a commit
that referenced
this pull request
Sep 10, 2023
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
hustcer
pushed a commit
that referenced
this pull request
Oct 4, 2023
related to - nushell/nushell#9373 - nushell/nushell#8639 might be able to close nushell/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
hustcer
pushed a commit
that referenced
this pull request
Oct 20, 2023
follow-up to - nushell/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
hustcer
pushed a commit
that referenced
this pull request
Nov 2, 2023
# 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. #8431 fixed by #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.
hustcer
pushed a commit
that referenced
this pull request
Nov 23, 2023
…. (#10851)
# Description
Fixes: #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: #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
╰────
```
hustcer
pushed a commit
that referenced
this pull request
Nov 30, 2023
Goes towards implementing #10598, which asks for a spread operator in
lists, in records, and when calling commands (continuation of #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
hustcer
pushed a commit
that referenced
this pull request
Dec 6, 2023
# Description
Fixes: #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
hustcer
pushed a commit
that referenced
this pull request
Dec 12, 2023
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 ╰──── ```
hustcer
pushed a commit
that referenced
this pull request
Dec 28, 2023
# 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:
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:
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:
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.
# Tests + Formatting
# After Submitting
hustcer
pushed a commit
that referenced
this pull request
Jan 26, 2024
# Description
This is a follow up to: #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 #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
hustcer
pushed a commit
that referenced
this pull request
Feb 4, 2024
…r ints (#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 <!-- 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 std testing; testing run-tests --path crates/nu-std"` 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. -->
hustcer
pushed a commit
that referenced
this pull request
Feb 9, 2024
# Description Close: #9673 Close: #8277 Close: #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.
hustcer
pushed a commit
that referenced
this pull request
Jun 28, 2024
…#13131) # Description Closes: #13010 It adds an additional check inside `parse_string`, and returns `unbalanced quote` if input string is unbalanced # User-Facing Changes After this pr, the following is no longer allowed: ```nushell ❯ "asdfasdf"asdfasdf Error: nu::parser::extra_token_after_closing_delimiter × Invaild characters after closing delimiter ╭─[entry #1:1:11] 1 │ "asdfasdf"asdfasdf · ────┬─── · ╰── invalid characters ╰──── help: Try removing them. ❯ 'asdfasd'adsfadf Error: nu::parser::extra_token_after_closing_delimiter × Invaild characters after closing delimiter ╭─[entry #2:1:10] 1 │ 'asdfasd'adsfadf · ───┬─── · ╰── invalid characters ╰──── help: Try removing them. ``` # Tests + Formatting Added 1 test
hustcer
pushed a commit
that referenced
this pull request
Nov 27, 2024
…#14385)
# Description
As title, this pr is going to deprecate `--ignore-shell-errors` and
`--ignore-program-errors`.
Because I think these two flags makes `do` command complicate, and it
should be easy to use `-i` instead.
# User-Facing Changes
After the pr, using these two flags will raise deprecated warning.
```nushell
> do --ignore-program-errors { ^pwd }
Error: × Deprecated option
╭─[entry #2:1:1]
1 │ do --ignore-program-errors { ^pwd }
· ─┬
· ╰── `--ignore-program-errors` is deprecated and will be removed in 0.102.0.
╰────
help: Please use the `--ignore-errors(-i)`
/home/windsoilder/projects/nushell
> do --ignore-shell-errors { ^pwd }
Error: × Deprecated option
╭─[entry #3:1:1]
1 │ do --ignore-shell-errors { ^pwd }
· ─┬
· ╰── `--ignore-shell-errors` is deprecated and will be removed in 0.102.0.
╰────
help: Please use the `--ignore-errors(-i)`
/home/windsoilder/projects/nushell
```
# Tests + Formatting
NaN
hustcer
pushed a commit
that referenced
this pull request
Nov 30, 2024
# Description Before this PR, `length` did not check its input type at run-time, so it would attempt to calculate a length for any input with indeterminate type (e.g., `echo` which has an `any` output type). This PR makes `length` only work on the types specifically supported in its input/output types (list/table, binary, and nothing), making the behavior the same at parse-time and at run-time. Fixes #14462 # User-Facing Changes Length will error if passed an unsupported type: Before (only caught at parse-time): ```nushell "hello" | length Error: nu::parser::input_type_mismatch × Command does not support string input. ╭─[entry #2:1:11] 1 │ "hello" | length · ───┬── · ╰── command doesn't support string input ╰──── echo "hello" | length # => 1 ``` After (caught at parse-time and run-time): ```nushell "hello" | length Error: nu::parser::input_type_mismatch × Command does not support string input. ╭─[entry #22:1:11] 1 │ "hello" | length · ───┬── · ╰── command doesn't support string input ╰──── echo "hello" | length Error: nu:🐚:only_supports_this_input_type × Input type not supported. ╭─[entry #23:1:6] 1 │ echo "hello" | length · ───┬─── ───┬── · │ ╰── only list, table, binary, and nothing input data is supported · ╰── input type: string ╰──── ```
hustcer
pushed a commit
that referenced
this pull request
Jan 6, 2025
…re passed in span (#14757) <!-- 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. --> Changes the `Value` variant match arm of `PipelineData::into_value` to use the internal `Value`'s span instead of the span passed in by the user. This aligns more closely with the `ListStream` and `ByteStream` match arms, which already use their internal span, and allows errors to provide better diagnostics since the span information doesn't get lost when `into_value` is called. At the suggestion of @cptpiepmatz, if the `Value` has `Span::unknown` for some reason, then we replace the `Value`'s span with the passed in span. Before: ```nushell {} | get foo bar # => Error: nu::shell::column_not_found # => # => × Cannot find column 'foo' # => ╭─[entry #43:2:6] # => 2 │ {} | get foo bar # => · ─┬─ ─┬─ # => · │ ╰── cannot find column 'foo' # => · ╰── value originates here # => ╰──── ``` After: ```nushell {} | get foo bar # => Error: nu:🐚:column_not_found # => # => × Cannot find column 'foo' # => ╭─[entry #2:2:1] # => 2 │ {} | get foo bar # => · ─┬ ─┬─ # => · │ ╰── cannot find column 'foo' # => · ╰── value originates here # => ╰──── ``` # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> * Some errors may have more accurate info about where the value originates from # 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
hustcer
pushed a commit
that referenced
this pull request
Jan 16, 2025
…#14765) # Description This PR removes the required positional argument from `run-external` and `exec` in favor of the rest arguments, meaning lists of external commands can be spread directly into `run-external` and `exec`. This does have the drawback of making calling `run-external` and `exec` with no arguments a run-time error rather than a parse error, but I don't imagine that is an issue. Before (for both `run-external` and `exec`): ```nushell run-external # => Error: nu::parser::missing_positional # => # => × Missing required positional argument. # => ╭─[entry #9:1:13] # => 1 │ run-external # => ╰──── # => help: Usage: run-external <command> ...(args) . Use `--help` for more # => information. let command = ["cat" "hello.txt"] run-external ...$command # => Error: nu::parser::missing_positional # => # => × Missing required positional argument. # => ╭─[entry #11:1:14] # => 1 │ run-external ...$command # => · ▲ # => · ╰── missing command # => ╰──── # => help: Usage: run-external <command> ...(args) . Use `--help` for more # => information. run-external ($command | first) ...($command | skip 1) # => hello world! ``` After (for both `run-external` and `exec`): ```nushell run-external # => Error: nu:🐚:missing_parameter # => # => × Missing parameter: no command given. # => ╭─[entry #2:1:1] # => 1 │ run-external # => · ──────┬───── # => · ╰── missing parameter: no command given # => ╰──── # => let command = ["cat" "hello.txt"] run-external ...$command # => hello world! ``` # User-Facing Changes Lists can now be spread directly into `run-external` and `exec`: ```nushell let command = [cat hello.txt] run-external ...$command # => hello world! ``` # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting N/A
hustcer
pushed a commit
that referenced
this pull request
Apr 20, 2025
Closes #15543
# Description
1. Simplify code in ``datetime.rs`` based on a suggestion in my last PR
on "datetime from record"
1. Make ``into duration`` work with durations inside a record, provided
as a cell path
1. Make ``into duration`` work with durations as record
# User-Facing Changes
```nushell
# Happy paths
~> {d: '1hr'} | into duration d
╭───┬─────╮
│ d │ 1hr │
╰───┴─────╯
~> {week: 10, day: 2, sign: '+'} | into duration
10wk 2day
# Error paths and invalid usage
~> {week: 10, day: 2, sign: 'x'} | into duration
Error: nu::shell::incorrect_value
× Incorrect value.
╭─[entry #4:1:26]
1 │ {week: 10, day: 2, sign: 'x'} | into duration
· ─┬─ ──────┬──────
· │ ╰── encountered here
· ╰── Invalid sign. Allowed signs are +, -
╰────
~> {week: 10, day: -2, sign: '+'} | into duration
Error: nu:🐚:incorrect_value
× Incorrect value.
╭─[entry #5:1:17]
1 │ {week: 10, day: -2, sign: '+'} | into duration
· ─┬ ──────┬──────
· │ ╰── encountered here
· ╰── number should be positive
╰────
~> {week: 10, day: '2', sign: '+'} | into duration
Error: nu:🐚:only_supports_this_input_type
× Input type not supported.
╭─[entry #6:1:17]
1 │ {week: 10, day: '2', sign: '+'} | into duration
· ─┬─ ──────┬──────
· │ ╰── only int input data is supported
· ╰── input type: string
╰────
~> {week: 10, unknown: 1} | into duration
Error: nu:🐚:unsupported_input
× Unsupported input
╭─[entry #7:1:1]
1 │ {week: 10, unknown: 1} | into duration
· ───────────┬────────── ──────┬──────
· │ ╰── Column 'unknown' is not valid for a structured duration. Allowed columns are: week, day, hour, minute, second, millisecond, microsecond, nanosecond, sign
· ╰── value originates from here
╰────
~> {week: 10, day: 2, sign: '+'} | into duration --unit sec
Error: nu:🐚:incompatible_parameters
× Incompatible parameters.
╭─[entry #2:1:33]
1 │ {week: 10, day: 2, sign: '+'} | into duration --unit sec
· ──────┬────── ─────┬────
· │ ╰── the units should be included in the record
· ╰── got a record as input
╰────
```
# Tests + Formatting
- Add examples and integration tests for ``into duration``
- Add one test for ``into duration``
# After Submitting
If this is merged in time, I'll update my PR on the "datetime handling
highlights" for the release notes.
hustcer
pushed a commit
that referenced
this pull request
Jun 4, 2025
…#15882) **Title**: Better error handling for negative integer exponents in `**` operator --- ### Bug Fix This PR addresses an issue where attempting to raise an integer to a negative power (e.g. `10 ** -1`) incorrectly triggered an `OperatorOverflow` error. This behavior was misleading since the overflow isn't actually the root problem — it's the unsupported operation of raising integers to negative powers. --- ### Fix Summary * Updated `Value::pow` to: * Check for negative exponents when both operands are integers. * Return a `ShellError::IncorrectValue` with a helpful message guiding users to use floating point values instead. #### Example: ```bash > 10 ** -1 Error: nu::shell::incorrect_value × Incorrect value. ╝─[entry #2:1:4] 1 │ 10 ** -1 · ─┬┬ · │╰── encountered here · ╰── Negative exponent for integer power is unsupported; use floats instead. ``` --- ### Testing Manual testing: * `10 ** -1` → now returns a clear and appropriate `IncorrectValue` error. * `10.0 ** -1`, `10 ** -1.0`, etc. continue to work as expected. --- ### Related Fixes #15860 --------- Co-authored-by: Kumar Ujjawal <kumar.ujjawal@greenpista.com>
hustcer
pushed a commit
that referenced
this pull request
Aug 13, 2025
… commands to utilize that (#16414)
# Description
- Implemented `FromValue` for `std::time::Duration`.
- It only converts positive `Value::Duration` values, negative ones
raise `ShellError::NeedsPositiveValue`.
- Refactor `job recv` and `watch` commands to use this implementation
rather than handling it ad-hoc.
- Simplified `watch`'s `debounce` & `debounce-ms` and factored it to a
function. Should make removing `debounce-ms` after its deprecation
period ends.
- `job recv` previously used a numeric cast (`i64 as u64`) which would
result in extremely long duration values rather than raising an error
when negative duration arguments were given.
# User-Facing Changes
Changes in error messages:
- Providing the wrong type (bypassing parse time type checking):
- Before
```
Error: nu::shell::type_mismatch
× Type mismatch.
╭─[entry #40:1:9]
1 │ watch . --debounce (1 | $in) {|| }
· ──────────┬─────────
· ╰── Debounce duration must be a duration
╰────
```
- After
```
Error: nu:🐚:cant_convert
× Can't convert to duration.
╭─[entry #2:1:9]
1 │ watch . --debounce (1 | $in) {|| }
· ──────────┬─────────
· ╰── can't convert int to duration
╰────
```
- Providing a negative duration value:
- Before
```
Error: nu:🐚:type_mismatch
× Type mismatch.
╭─[entry #41:1:9]
1 │ watch . --debounce -100ms {|| }
· ────────┬────────
· ╰── Debounce duration is invalid
╰────
```
- After
```
Error: nu:🐚:needs_positive_value
× Negative value passed when positive one is required
╭─[entry #4:1:9]
1 │ watch . --debounce -100ms {|| }
· ────────┬────────
· ╰── use a positive value
╰────
```
hustcer
pushed a commit
that referenced
this pull request
Nov 21, 2025
This allows all of the inputs to a `LabeledError` structure to be
accessed from inside of Nushell scripts, not just plugins, including:
* multiple labels (see error from `1 + ""`)
* errors inside of errors (see error from `']' | from nuon`)
* custom codes instead of only `nu::shell::error`
* URL's added to errors using the `url` key
This is a complete rewrite of the `error make` command using `FromValue`
to simplify the parsing a _lot_. I did have to write a `FromValue`
implementation for `nu_protocol::Span` that goes from a record into a
`Span` object. The error checking happens in there instead of in `error
make` now.
Here are a few examples:
```
> def foo [pond sink] {
error make {
msg: "this is fishy"
code: "my::error"
label: [
{text: "fish right here" span: (metadata $pond).span}
{text: "don't fish here" span: (metadata $sink).span}
]
help: "something to tell the user as help"
url: "https://nushell.sh"
}
}
> foo "pond" "sink"
Error: my::error (link)
× this is fishy
╭─[entry #2:1:5]
1 │ foo "pond" "sink"
· ───┬── ───┬──
· │ ╰── don't fish here
· ╰── fish right here
╰────
help: something to tell the user as help
> try {
foo pond "not a pond"
} catch {|e|
error make {
msg: "An outer error"
inner: [($e.json | from json)]
}
}
Error: nu:🐚:error
× An outer error
╭─[entry #3:4:5]
3 │ } catch {|e|
4 │ error make {
· ─────┬────
· ╰── originates from here
5 │ msg: "An outer error"
╰────
Error: my::error (link)
× this is fishy
╭─[entry #3:2:9]
1 │ try {
2 │ foo pond "not a pond"
· ──┬─ ──────┬─────
· │ ╰── don't fish here
· ╰── fish right here
3 │ } catch {|e|
╰────
help: something to tell the user as help
```
The `(link)` is clickable if the right `$env.config` settings are
enabled, or it will print `https://example.com` to the screen.
<!--
Thank you for improving Nushell!
Please, read our contributing guide:
https://github.com/nushell/nushell/blob/main/CONTRIBUTING.md
-->
## Release notes summary - What our users need to know
* Add the all parts of the `LabeledError` structure to the
`error_struct` argument of `error make`
## Tasks after submitting
<!-- Remove any tasks which aren't relevant for your PR, or add your own
-->
- [ ] Update the
[documentation](https://github.com/nushell/nushell.github.io)
hustcer
pushed a commit
that referenced
this pull request
Nov 23, 2025
Closes #17031
Commands whose input signatures are declared with `oneof` now accept
streams instead of erroring:
```
> def f []: [oneof<list> -> nothing] {}
> [] | each {} | f
Error: nu::shell::only_supports_this_input_type
× Input type not supported.
╭─[entry #2:1:6]
1 │ [] | each {} | f
· ──┬─ ┬
· │ ╰── only oneof<list<any>> input data is supported
· ╰── input type: list<any>
```
hustcer
pushed a commit
that referenced
this pull request
Dec 19, 2025
## User-facing Changes
* New arguments! (`error make "hello"`)
* New parts for `error_struct`! (`error make {inner: [] labels: []
...}`)
* Pipeline inputs for chained errors! (`try {error make foo} catch
{error make bar}`)
* Pipeline inputs for normal errors! (`"help" | error make`)
* External errors! (`error make {src: {path: $nu.cofig-path} ...}`)
* Backwards compatibility!
### Arguments and Inputs
The main changes are in how the arguments are passed. Everything is
still backwards compatible with the old `error make` commands, there's
just a nice extra layer we get from the pipeline and a few new args
(that were already added in #17037). There are some new ways to
(hopefully intentionally) cause an error, such as using a naked `error
make`, pipelines from records and simple string input!
#### Inputs
Because `error make` will just make an error anyway, it can technically
take any input to make an error, but only properly formatted record
input will create a chain. the `x | f $in` pattern can be used for
string input, if that is more comfortable.
#### With no arguments
This is a completely new way to do this, with no arguments the `error
make` invocation is highlighted, along with a simple `originates from
here` message. This makes normal errors very easy to create without any
special message setup.
```
> error make
Error: nu::shell::error
× originates from here
╭─[entry #4:1:1]
1 │ error make
· ──────────
╰────
```
#### Create a single argument
* With pipeline input: `{msg: foo} | error make`
* With an argument: `error make {msg: foo}`
* With a string argument: `error make foo`
```
Error: nu:🐚:error
× foo
╭─[entry #2:1:12]
1 │ error make {msg: foo}
· ──────────
╰────
```
#### Chaining errors together
These will automatically create a chain of errors, placing the pipeline
as an `inner` to the argument. This can very easily be used to get a bit
more detail in a try loop using the naked `error make`:
```
Error: nu:🐚:error
× originates from here
╭─[source:1:31]
1 │ try {error make "foo"} catch {error make}
· ──────────
╰────
Error: nu:🐚:error
× foo
╭─[source:1:6]
1 │ try {error make "foo"} catch {error make}
· ──────────
╰────
```
Or with more complex errors:
* With both, combining the errors: `{msg: foo} | error make bar`
* With the raw error from try: `try {error make foo} catch {error make
bar}`
Both are equivalent to:
* `error make {msg: bar inner: [{msg: foo}]}`
```
Error: nu:🐚:error
× bar
╭─[entry #1:1:29]
1 │ try {error make foo} catch {error make bar}
· ──────────
╰────
Error: nu:🐚:error
× foo
╭─[entry #1:1:6]
1 │ try {error make foo} catch {error make bar}
· ──────────
╰────
```
### Labels
As is noticeable in the examples above, simple errors no longer use an
extra line for the label. If no label is present, `error make` will
place a bar under the span of itself or the argument to `error make`.
Labels have also gotten a bit of a rewrite, but they're pretty much the
same as those in #17037, except for `label`, which is now only a single
label (not `oneof<list, label>`).
#### Simple Labels
`label.text` and `labels.*.text` is no longer required for a span to
show up, an empty text will simply underline. This example can either
use `label: $record` or be written as `labels: [$record]`:
```
> def f [x] {
error make {msg: here label: {span: (metadata $x).span}}
}
f abcd
Error: nu::shell::error
× here
╭─[entry #7:4:3]
3 │ }
4 │ f abcd
· ────
╰────
```
#### Multiple labels
Any number of labels can be added in the `labels` column, allowing for
more detailed error messages, especially for functions:
```
> def f [x y z] {
error make {msg: here labels: [
{text: "there" span: (metadata $x).span}
{text: "everywhere" span: (metadata $y).span}
{text: "somewhere" span: (metadata $z).span}
]
}
}
f abcd [x y z] {d: a}
Error: nu:🐚:error
× here
╭─[entry #11:9:3]
8 │ }
9 │ f abcd [x y z] {d: a}
· ──┬─ ───┬─── ───┬──
· │ │ ╰── somewhere
· │ ╰── everywhere
· ╰── there
╰────
```
#### External sources
There is a `ShellError::OutsideSpannedLabeledError` that can be used to
refer to external sources, not just the internal nushell spanns. This
has been expanded to allow the multi-label stuff to work using the new
`src` column:
```
> "foo\nbar\nbaz" | save -f /tmp/foo.bar
error make {
msg: 'error here'
src: {path: /tmp/foo.bar}
labels: [
{text: "this" span: {start: 4 end: 7}}
]
}
Error: nu:🐚:outside
× error here
╭─[/tmp/foo.bar:2:1]
1 │ foo
2 │ bar
· ─┬─
· ╰── this
3 │ baz
╰────
```
### Errors That Can't be Caught
These will not work since `try` will never get parsed:
- `try {1 + ""} catch {error make badmath}`
- (TODO: Add more examples)
## Internal Changes
Most of the parsing from an error record to an actual error is now moved
into `nu-protocol`, using `FromValue` to turn it into a useful internal
type.
### `nu-protocol::LabeledError`
This struct has a few changes, the main one being the type of
`LabeledError.inner`. It is now a `ShellError`, not another
`LabeledError`. It should be trivial to do a `.into()` for things that
already use `LabeledError.with_inner(x)`.
### `nu-protocol::ShellError::into_value`
I renamed the old `into_value` to `into_full_value` to better say what
it is, since it doesn't just do the `IntoValue::into_value` method, it
also requires some context to create the `Value`. Now `ShellError` has
an `IntoValue` implementation matching other types.
### `nu-protocol::ShellError::{OutsideSource, OutsideSourceNoUrl}`
Miette's derived types don't have a nice way to maybe include a url, so
there are now two types! These allow using multiple labels on outside
sources. They are used internally for the new `{src: {}}` part of the
`error_struct`, and they look a lot more like the `LabeledError`, but
without the need for a separate type and all the fun `impl`s that would
require for the `Diagnostic::source_code` method.
### Misc
* Spelling fix: `into_chainned` => `into_chained`
## Current bugs:
- [x] `OutsideSpannedLabeledError`
The inner most error of `try {']' from nuon} catch {error make}` will
reference `span: {start: 0, end: 1}`, which in `']' from nuon` will
point to the `]` character, but when it does this in `error make` as an
input it will point to the very first character (probably the `n` in
`nu`).
## Release notes summary - What our users need to know
### New `error make` functionality!
* New arguments! (`error make "hello"`)
* New parts for `error_struct`! (`error make {inner: [] labels: []
...}`)
* Pipeline inputs for chained errors! (`try {error make foo} catch
{error make bar}`)
* Pipeline inputs for normal errors! (`"help" | error make`)
* External errors! (`error make {src: {path: $nu.cofig-path} ...}`)
* Backwards compatibility!
## Tasks after submitting
<!-- Remove any tasks which aren't relevant for your PR, or add your own
-->
- [ ] Update the
[documentation](https://github.com/nushell/nushell.github.io)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps actions-rust-lang/setup-rust-toolchain from 1.4.4 to 1.5.0.
Release notes
Sourced from actions-rust-lang/setup-rust-toolchain's releases.
Changelog
Sourced from actions-rust-lang/setup-rust-toolchain's changelog.
... (truncated)
Commits
f3c84eeMerge pull request #18 from JeanMertz/rustflags1ef811fRestore behavior to not touch existing RUSTFLAGS variable70241abfixes823a4a1fixesaaa7eefrequred -> required24274e4allow disablingRUSTFLAGSconfigcf60eafMerge pull request #19 from actions-rust-lang/better-toolchain-support289d5e6Add changelog661e2d2Explain the new behavior in the READMEb065e5aInstall components and targets after installing everything from the rust-tool...Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)