Bump quick-xml from 0.28.2 to 0.29.0 #3
Closed
Conversation
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
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
Bumps [quick-xml](https://github.com/tafia/quick-xml) from 0.28.2 to 0.29.0. - [Release notes](https://github.com/tafia/quick-xml/releases) - [Changelog](https://github.com/tafia/quick-xml/blob/master/Changelog.md) - [Commits](tafia/quick-xml@v0.28.2...v0.29.0) --- updated-dependencies: - dependency-name: quick-xml dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
bot
added
dependencies
|
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. |
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
Sep 27, 2023
…10430) should close nushell/nushell#10406 # Description when writing a script, with variables you try to `ls` or `open`, you will get a "directory not found" error but the variable won't be expanded and you won't be able to see which one of the variable was the issue... this PR adds this information to the error. # User-Facing Changes let's define a variable ```nushell let does_not_exist = "i_do_not_exist_in_the_current_directory" ``` ### before ```nushell > open $does_not_exist Error: nu::shell::directory_not_found × Directory not found ╭─[entry #7:1:1] 1 │ open $does_not_exist · ───────┬─────── · ╰── directory not found ╰──── ``` ```nushell > ls $does_not_exist Error: nu:🐚:directory_not_found × Directory not found ╭─[entry #8:1:1] 1 │ ls $does_not_exist · ───────┬─────── · ╰── directory not found ╰──── ``` ### after ```nushell > open $does_not_exist Error: nu:🐚:directory_not_found × Directory not found ╭─[entry #3:1:1] 1 │ open $does_not_exist · ───────┬─────── · ╰── directory not found ╰──── help: /home/amtoine/documents/repos/github.com/amtoine/nushell/i_do_not_exist_in_the_current_directory does not exist ``` ```nushell > ls $does_not_exist Error: nu:🐚:directory_not_found × Directory not found ╭─[entry #4:1:1] 1 │ ls $does_not_exist · ───────┬─────── · ╰── directory not found ╰──── help: /home/amtoine/documents/repos/github.com/amtoine/nushell/i_do_not_exist_in_the_current_directory does not exist ``` # Tests + Formatting shouldn't harm anything 🤞 # After Submitting
hustcer
pushed a commit
that referenced
this pull request
Oct 2, 2023
should close #10549
# Description
this PR is twofold
- uses `to nuon --raw` in the error messages to make sure #10549 is
solved and makes a difference between `"1"` and `1`
- tries to introduce slightly better errors, i.e. by putting left /
right on new lines => this should hopefully help when the values become
a bit big 😋
# User-Facing Changes
the original issue:
```nushell
> assert equal {one:1 two:2} {one:"1" two:"2"}
Error: × Assertion failed.
╭─[entry #3:1:1]
1 │ assert equal {one:1 two:2} {one:"1" two:"2"}
· ───────────────┬───────────────
· ╰── These are not equal.
Left : '{one: 1, two: 2}'
Right : '{one: "1", two: "2"}'
╰────
```
a sample for all the assertions and their new messages
```nushell
> assert equal {one:1 two:2} {one:"1" two:"2"}
Error: × Assertion failed.
╭─[entry #3:1:1]
1 │ assert equal {one:1 two:2} {one:"1" two:"2"}
· ───────────────┬───────────────
· ╰── These are not equal.
Left : '{one: 1, two: 2}'
Right : '{one: "1", two: "2"}'
╰────
```
```nushell
> assert equal 1 2
Error: × Assertion failed.
╭─[entry #4:1:1]
1 │ assert equal 1 2
· ─┬─
· ╰── These are not equal.
Left : '1'
Right : '2'
╰────
```
```nushell
> assert less 3 1
Error: × Assertion failed.
╭─[entry #6:1:1]
1 │ assert less 3 1
· ─┬─
· ╰── The condition *left < right* is not satisfied.
Left : '3'
Right : '1'
╰────
```
```nushell
> assert less or equal 3 1
Error: × Assertion failed.
╭─[entry #7:1:1]
1 │ assert less or equal 3 1
· ─┬─
· ╰── The condition *left <= right* is not satisfied.
Left : '3'
Right : '1'
╰────
```
```nushell
> assert greater 1 3
Error: × Assertion failed.
╭─[entry #8:1:1]
1 │ assert greater 1 3
· ─┬─
· ╰── The condition *left > right* is not satisfied.
Left : '1'
Right : '3'
╰────
```
```nushell
> assert greater or equal 1 3
Error: × Assertion failed.
╭─[entry #9:1:1]
1 │ assert greater or equal 1 3
· ─┬─
· ╰── The condition *left < right* is not satisfied.
Left : '1'
Right : '3'
╰────
```
```nushell
> assert length [1 2 3] 2
Error: × Assertion failed.
╭─[entry #10:1:1]
1 │ assert length [1 2 3] 2
· ────┬────
· ╰── This does not have the correct length:
value : [1, 2, 3]
length : 3
expected : 2
╰────
```
```nushell
> assert length [1 "2" 3] 2
Error: × Assertion failed.
╭─[entry #11:1:1]
1 │ assert length [1 "2" 3] 2
· ─────┬─────
· ╰── This does not have the correct length:
value : [1, "2", 3]
length : 3
expected : 2
╰────
```
```nushell
> assert str contains "foo" "bar"
Error: × Assertion failed.
╭─[entry #13:1:1]
1 │ assert str contains "foo" "bar"
· ─────┬─────
· ╰── This does not contain '($right)'.
value: "foo"
╰────
```
# Tests + Formatting
# After Submitting
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 23, 2024
<!-- 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! --> Closes #11561 # 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 will allow string interpolation at parse time. Since the actual config hasn't been loaded at parse time, this uses the `get_config()` method on `StateWorkingSet`. So file sizes and datetimes (I think those are the only things whose string representations depend on the config) may be formatted differently from how users have configured things, which may come as a surprise to some. It does seem unlikely that anyone would be formatting file sizes or date times at parse time. Still, something to think about if/before this PR merged. Also, I changed the `ModuleNotFound` error to include the name of the module. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> Users will be able to do stuff like: ```nu const x = [1 2 3] const y = $"foo($x)" // foo[1, 2, 3] ``` The main use case is `use`-ing and `source`-ing files at parse time: ```nu const file = "foo.nu" use $"($file)" ``` If the module isn't found, you'll see an error like this: ``` Error: nu::parser::module_not_found × Module not found. ╭─[entry #3:1:1] 1 │ use $"($file)" · ─────┬──── · ╰── module foo.nu not found ╰──── help: module files and their paths must be available before your script is run as parsing occurs before anything is evaluated ``` # 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. --> Although there's user-facing changes, there's probably no need to change the docs since people probably already expect string interpolation to work at parse time. Edit: @kubouch pointed out that we'd need to document the fact that stuff like file sizes and datetimes won't get formatted according to user's runtime configs, so I'll make a PR to nushell.github.io after this one
hustcer
pushed a commit
that referenced
this pull request
Aug 6, 2024
# Description When using a format string, `into datetime` would disallow an `int` even when it logically made sense. This was mainly a problem when attempting to convert a Unix epoch to Nushell `datetime`. Unix epochs are often stored or returned as `int` in external data sources. ```nu 1722821463 | into datetime -f '%s' Error: nu::shell::only_supports_this_input_type × Input type not supported. ╭─[entry #3:1:1] 1 │ 1722821463 | into datetime -f '%s' · ─────┬──── ──────┬────── · │ ╰── only string input data is supported · ╰── input type: int ╰──── ``` While the solution was simply to `| to text` the `int`, this PR handles the use-case automatically. Essentially a ~5 line change that just moves the current parsing to a closure that is called for both Strings and Ints-converted-to-Strings. # User-Facing Changes After the change: ```nu [ 1722821463 "1722821463" 0 ] | each { into datetime -f '%s' } ╭───┬──────────────╮ │ 0 │ 10 hours ago │ │ 1 │ 10 hours ago │ │ 2 │ 54 years ago │ ╰───┴──────────────╯ ``` # Tests + Formatting Test case added. - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting
hustcer
pushed a commit
that referenced
this pull request
Aug 13, 2024
…t (#13585) # Description As per our Wednesday meeting, this adds a parse error when something that would be parsed as an external call is present at the top level, unless the head of the external call begins with a caret (to make it explicit). I tried to make the error quite descriptive about what should be done. # User-Facing Changes These now cause a parse error: ```nushell $foo = bar $foo = `bar` ``` These would have been interpreted as strings before this version, but now they'd be interpreted as external calls. This behavior is consistent with `let`/`mut` (which is unaffected by this change). Here is an example of the error: ``` Error: × External command calls must be explicit in assignments ╭─[entry #3:1:8] 1 │ $foo = bar · ─┬─ · ╰── add a caret (^) before the command name if you intended to run and capture its output ╰──── help: the parsing of assignments was changed in 0.97.0, and this would have previously been treated as a string. Alternatively, quote the string with single or double quotes to avoid it being interpreted as a command name. This restriction may be removed in a future release. ``` # Tests + Formatting Tests added to cover the change. Note made about it being temporary.
hustcer
pushed a commit
that referenced
this pull request
Oct 23, 2024
<!-- 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. --> Swagger supports lists (a.k.a arrays) in query parameters: https://swagger.io/docs/specification/v3_0/serialization/ It supports three different styles: - explode=true - spaceDelimited - pipeDelimited With explode=true being the default and hence most common. It is the hardest to use inside of nushell, as the others are just a `string join` away. This commit adds lists with the explode=true format. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> Before: : {a[]: [one two three], b: four} | url build-query Error: nu::shell::unsupported_input × Unsupported input ╭─[entry #33:1:1] 1 │ {a[]: [one two three], b: four} | url build-query · ───────────────┬─────────────── ───────┬─────── · │ ╰── Expected a record with string values · ╰── value originates from here ╰──── After: : {a[]: [one two three], b: four} | url build-query a%5B%5D=one&a%5B%5D=two&a%5B%5D=three&b=four Despite reading CONTRIBUTING.md I didn't get approval before making the change. My judgment is that this doesn't qualify as being "change something significantly". # Tests + Formatting I added the Example instance for the automatic tests. I couldn't figure out how to add an Example for the error case, so I did that with manual testing. E.g.: : {a[]: [one two [three]], b: four} | url build-query Error: nu:🐚:unsupported_input × Unsupported input ╭─[entry #3:1:1] 1 │ {a[]: [one two [three]], b: four} | url build-query · ────────────────┬──────────────── ───────┬─────── · │ ╰── Expected a record with list of string values · ╰── value originates from here ╰──── : {a[]: [one two 3hr], b: four} | url build-query Error: nu:🐚:unsupported_input × Unsupported input ╭─[entry #4:1:1] 1 │ {a[]: [one two 3hr], b: four} | url build-query · ──────────────┬────────────── ───────┬─────── · │ ╰── Expected a record with list of string values · ╰── value originates from here ╰──── <!-- 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 > ``` --> I ran the four cargo commands on my local machine. I had to run the tests with: LANG=C and -j 1 and even then I got one failure: thread 'commands::umkdir::mkdir_umask_permission' panicked at crates/nu-command/tests/commands/umkdir.rs:148:9: assertion `left == right` failed: Most *nix systems have 0o00022 as the umask. So directory permission should be 0o40755 = 0o 40777 & (!0o00022) left: 16893 right: 16877 but this isn't related to this change (I seem to not be running most *nix system; and don't have a lot of RAM for the number of cores). The other three cargo commands didn't have errors or warnings. # After Submitting <!-- 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. --> I will add the new example to [the documentation](https://github.com/nushell/nushell.github.io). # Open questions / possible future work Things I noticed, and would like to mention and am open to adding, but don't think I am deep enough in nushell to do them pro-actively. ## Add an argument for the other query parameter list styles I don't know how frequent they are and I currently don't need them, so following KISS I didn't add them. ## long input_span marked In e.g.: : {a[]: [one two 3hr], b: four} | url build-query Error: nu::shell::unsupported_input × Unsupported input ╭─[entry #4:1:1] 1 │ {a[]: [one two 3hr], b: four} | url build-query · ──────────────┬────────────── ───────┬─────── · │ ╰── Expected a record with list of string values · ╰── value originates from here ╰──── the entire record is marked as input_span instead of just the "3hr" that is causing the problem. Changing that would be trivial, but I'm not deep enough into nushell to understand all the consequences of changing that. ## Error message says string values despite accepting numbers etc. The error message said it only accepted strings despite accepting numbers etc. (anything it can coerce into string). I couldn't find a good wording myself and that was how it was before. I simply added a "list of strings".
hustcer
pushed a commit
that referenced
this pull request
Nov 18, 2024
A more involved solution to the issue pointed out [here](nushell/nushell#14337 (comment)) # Description With `--to-table` - cell-path groupers are used to create column names, similar to `select` - closure groupers result in columns named `closure_{i}` where `i` is the index of argument, with regards to other closures i.e. first closure grouper results in a column named `closure_0` Previously - `group-by foo {...} {...}` => `table<foo, group1, group2, items>` - `group-by {...} foo {...}` => `table<group0, foo, group2, items>` With this PR - `group-by foo {...} {...}` => `table<foo, closure_0, closure_1, items>` - `group-by {...} foo {...}` => `table<closure_0, foo, closure_1, items>` - no grouper argument results in a `table<group, items>` as previously On naming conflicts caused by cell-path groupers named `items` or `closure_{i}`, an error is thrown, suggesting to use a closure in place of a cell-path. ```nushell ❯ ls | rename items | group-by items --to-table Error: × grouper arguments can't be named `items` ╭─[entry #3:1:29] 1 │ ls | rename items | group-by items --to-table · ────────┬──────── · ╰── contains `items` ╰──── help: instead of a cell-path, try using a closure ``` And following the suggestion: ```nushell ❯ ls | rename items | group-by { get items } --to-table ╭─#──┬──────closure_0──────┬───────────────────────────items────────────────────────────╮ │ 0 │ CITATION.cff │ ╭─#─┬────items─────┬─type─┬─size──┬───modified───╮ │ │ │ │ │ 0 │ CITATION.cff │ file │ 812 B │ 3 months ago │ │ │ │ │ ╰─#─┴────items─────┴─type─┴─size──┴───modified───╯ │ │ 1 │ CODE_OF_CONDUCT.md │ ╭─#─┬───────items────────┬─type─┬──size───┬───modified───╮ │ ... ```
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
Dec 7, 2024
…time (#14303)
Alternative solution to:
- #12195
The other approach:
- #14305
# Description
Adds ~`path const`~ `path self`, a parse-time only command for getting
the absolute path of the source file containing it, or any file relative
to the source file.
- Useful for any script or module that makes use of non nuscript files.
- Removes the need for `$env.CURRENT_FILE` and `$env.FILE_PWD`.
- Can be used in modules, sourced files or scripts.
# Examples
```nushell
# ~/.config/nushell/scripts/foo.nu
const paths = {
self: (path self),
dir: (path self .),
sibling: (path self sibling),
parent_dir: (path self ..),
cousin: (path self ../cousin),
}
export def main [] {
$paths
}
```
```nushell
> use foo.nu
> foo
╭────────────┬────────────────────────────────────────────╮
│ self │ /home/user/.config/nushell/scripts/foo.nu │
│ dir │ /home/user/.config/nushell/scripts │
│ sibling │ /home/user/.config/nushell/scripts/sibling │
│ parent_dir │ /home/user/.config/nushell │
│ cousin │ /home/user/.config/nushell/cousin │
╰────────────┴────────────────────────────────────────────╯
```
Trying to run in a non-const context
```nushell
> path self
Error: × this command can only run during parse-time
╭─[entry #1:1:1]
1 │ path self
· ─────┬────
· ╰── can't run after parse-time
╰────
help: try assigning this command's output to a const variable
```
Trying to run in the REPL i.e. not in a file
```nushell
> const foo = path self
Error: × Error: nu:🐚:file_not_found
│
│ × File not found
│ ╭─[entry #3:1:13]
│ 1 │ const foo = path self
│ · ─────┬────
│ · ╰── Couldn't find current file
│ ╰────
│
╭─[entry #3:1:13]
1 │ const foo = path self
· ─────┬────
· ╰── Encountered error during parse-time evaluation
╰────
```
# Comparison with #14305
## Pros
- Self contained implementation, does not require changes in the parser.
- More concise usage, especially with parent directories.
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
hustcer
pushed a commit
that referenced
this pull request
Dec 11, 2024
…m the declaration (#14490) # Description Before this PR, `help commands` uses the name from a command's declaration rather than the name in the scope. This is problematic when trying to view the help page for the `main` command of a module. For example, `std bench`: ```nushell use std/bench help bench # => Error: nu::parser::not_found # => # => × Not found. # => ╭─[entry #10:1:6] # => 1 │ help bench # => · ──┬── # => · ╰── did not find anything under this name # => ╰──── ``` This can also cause confusion when importing specific commands from modules. Furthermore, if there are multiple commands with the same name from different modules, the help text for _both_ will appear when querying their help text (this is especially problematic for `main` commands, see #14033): ```nushell use std/iter help iter find # => Error: nu::parser::not_found # => # => × Not found. # => ╭─[entry #3:1:6] # => 1│ help iter find # => · ────┬──── # => · ╰── did not find anything under this name # => ╰──── help find # => Searches terms in the input. # => # => Search terms: filter, regex, search, condition # => # => Usage: # => > find {flags} ...(rest) # [...] # => Returns the first element of the list that matches the # => closure predicate, `null` otherwise # [...] # (full text omitted for brevity) ``` This PR changes `help commands` to use the name as it is in scope, so prefixing any command in scope with `help` will show the correct help text. ```nushell use std/bench help bench # [help text for std bench] use std/iter help iter find # [help text for std iter find] use std help std bench # [help text for std bench] help std iter find # [help text for std iter find] ``` Additionally, the IR code generation for commands called with the `--help` text has been updated to reflect this change. This does have one side effect: when a module has a `main` command defined, running `help <name>` (which checks `help aliases`, then `help commands`, then `help modules`) will show the help text for the `main` command rather than the module. The help text for the module is still accessible with `help modules <name>`. Fixes #10499, #10311, #11609, #13470, #14033, and #14402. Partially fixes #10707. Does **not** fix #11447. # User-Facing Changes * Help text for commands can be obtained by running `help <command name>`, where the command name is the same thing you would type in order to execute the command. Previously, it was the name of the function as written in the source file. * For example, for the following module `spam` with command `meow`: ```nushell module spam { # help text export def meow [] {} } ``` * Before this PR: * Regardless of how `meow` is `use`d, the help text is viewable by running `help meow`. * After this PR: * When imported with `use spam`: The `meow` command is executed by running `spam meow` and the `help` text is viewable by running `help spam meow`. * When imported with `use spam foo`: The `meow` command is executed by running `meow` and the `help` text is viewable by running `meow`. * When a module has a `main` command defined, `help <module name>` will return help for the main command, rather than the module. To access the help for the module, use `help modules <module name>`. # Tests + Formatting - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting N/A
hustcer
pushed a commit
that referenced
this pull request
Dec 16, 2024
# Description closes #14585 This PR tries to make `polars join --cross` work better. Example taken from https://docs.pola.rs/user-guide/transformations/joins/#cartesian-product ### Before ```nushell ❯ let tokens = [[monopoly_token]; [hat] [shoe] [boat]] | polars into-df ❯ let players = [[name, cash]; [Alice, 78] [Bob, 135]] | polars into-df ❯ $players | polars into-lazy | polars select (polars col name) | polars join --cross $tokens | polars collect Error: nu::parser::missing_positional × Missing required positional argument. ╭─[entry #3:1:92] 1 │ $players | polars into-lazy | polars select (polars col name) | polars join --cross $tokens ╰──── help: Usage: polars join {flags} <other> <left_on> <right_on> . Use `--help` for more information. ``` ### After ```nushell ❯ let players = [[name, cash]; [Alice, 78] [Bob, 135]] | polars into-df ❯ let tokens = [[monopoly_token]; [hat] [shoe] [boat]] | polars into-df ❯ $players | polars into-lazy | polars select (polars col name) | polars join --cross $tokens | polars collect ╭─#─┬─name──┬─monopoly_token─╮ │ 0 │ Alice │ hat │ │ 1 │ Alice │ shoe │ │ 2 │ Alice │ boat │ │ 3 │ Bob │ hat │ │ 4 │ Bob │ shoe │ │ 5 │ Bob │ boat │ ╰─#─┴─name──┴─monopoly_token─╯ ``` Other examples ```nushell ❯ 1..3 | polars into-df | polars join --cross (4..6 | polars into-df) ╭─#─┬─0─┬─0_x─╮ │ 0 │ 1 │ 4 │ │ 1 │ 1 │ 5 │ │ 2 │ 1 │ 6 │ │ 3 │ 2 │ 4 │ │ 4 │ 2 │ 5 │ │ 5 │ 2 │ 6 │ │ 6 │ 3 │ 4 │ │ 7 │ 3 │ 5 │ │ 8 │ 3 │ 6 │ ╰─#─┴─0─┴─0_x─╯ ❯ 1..3 | each {|x| {x: $x}} | polars into-df | polars join --cross (4..6 | each {|y| {y: $y}} | polars into-df) x y ╭─#─┬─x─┬─y─╮ │ 0 │ 1 │ 4 │ │ 1 │ 1 │ 5 │ │ 2 │ 1 │ 6 │ │ 3 │ 2 │ 4 │ │ 4 │ 2 │ 5 │ │ 5 │ 2 │ 6 │ │ 6 │ 3 │ 4 │ │ 7 │ 3 │ 5 │ │ 8 │ 3 │ 6 │ ╰─#─┴─x─┴─y─╯ ``` /cc @ayax79 # User-Facing Changes <!-- 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. -->
hustcer
pushed a commit
that referenced
this pull request
Jan 9, 2025
<!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> This PR adds type checking of all command input types at run-time. Generally, these errors should be caught by the parser, but sometimes we can't know the type of a value at parse-time. The simplest example is using the `echo` command, which has an output type of `any`, so prefixing a literal with `echo` will bypass parse-time type checking. Before this PR, each command has to individually check its input types. This can result in scenarios where the input/output types don't match the actual command behavior. This can cause valid usage with an non-`any` type to become a parse-time error if a command is missing that type in its pipeline input/output (`drop nth` and `history import` do this before this PR). Alternatively, a command may not list a type in its input/output types, but doesn't actually reject that type in its code, which can have unintended side effects (`get` does this on an empty pipeline input, and `sort` used to before #13154). After this PR, the type of the pipeline input is checked to ensure it matches one of the input types listed in the proceeding command's input/output types. While each of the issues in the "before this PR" section could be addressed with each command individually, this PR solves this issue for _all_ commands. **This will likely cause some breakage**, as some commands have incorrect input/output types, and should be adjusted. Also, some scripts may have erroneous usage of commands. In writing this PR, I discovered that `toolkit.nu` was passing `null` values to `str join`, which doesn't accept nothing types (if folks think it should, we can adjust it in this PR or in a different PR). I found some issues in the standard library and its tests. I also found that carapace's vendor script had an incorrect chaining of `get -i`: ```nushell let expanded_alias = (scope aliases | where name == $spans.0 | get -i 0 | get -i expansion) ``` Before this PR, if the `get -i 0` ever actually did evaluate to `null`, the second `get` invocation would error since `get` doesn't operate on `null` values. After this PR, this is immediately a run-time error, alerting the user to the problematic code. As a side note, we'll need to PR this fix (`get -i 0 | get -i expansion` -> `get -i 0.expansion`) to carapace. A notable exception to the type checking is commands with input type of `nothing -> <type>`. In this case, any input type is allowed. This allows piping values into the command without an error being thrown. For example, `123 | echo $in` would be an error without this exception. Additionally, custom types bypass type checking (I believe this also happens during parsing, but not certain) I added a `is_subtype` method to `Value` and `PipelineData`. It functions slightly differently than `get_type().is_subtype()`, as noted in the doccomments. Notably, it respects structural typing of lists and tables. For example, the type of a value `[{a: 123} {a: 456, b: 789}]` is a subtype of `table<a: int>`, whereas the type returned by `Value::get_type` is a `list<any>`. Similarly, `PipelineData` has some special handling for `ListStream`s and `ByteStream`s. The latter was needed for this PR to work properly with external commands. Here's some examples. Before: ```nu 1..2 | drop nth 1 Error: nu::parser::input_type_mismatch × Command does not support range input. ╭─[entry #9:1:8] 1 │ 1..2 | drop nth 1 · ────┬─── · ╰── command doesn't support range input ╰──── echo 1..2 | drop nth 1 # => ╭───┬───╮ # => │ 0 │ 1 │ # => ╰───┴───╯ ``` After this PR, I've adjusted `drop nth`'s input/output types to accept range input. Before this PR, zip accepted any value despite not being listed in its input/output types. This caused different behavior depending on if you triggered a parse error or not: ```nushell 1 | zip [2] # => Error: nu::parser::input_type_mismatch # => # => × Command does not support int input. # => ╭─[entry #3:1:5] # => 1 │ 1 | zip [2] # => · ─┬─ # => · ╰── command doesn't support int input # => ╰──── echo 1 | zip [2] # => ╭───┬───────────╮ # => │ 0 │ ╭───┬───╮ │ # => │ │ │ 0 │ 1 │ │ # => │ │ │ 1 │ 2 │ │ # => │ │ ╰───┴───╯ │ # => ╰───┴───────────╯ ``` After this PR, it works the same in both cases. For cases like this, if we do decide we want `zip` or other commands to accept any input value, then we should explicitly add that to the input types. ```nushell 1 | zip [2] # => Error: nu::parser::input_type_mismatch # => # => × Command does not support int input. # => ╭─[entry #3:1:5] # => 1 │ 1 | zip [2] # => · ─┬─ # => · ╰── command doesn't support int input # => ╰──── echo 1 | zip [2] # => Error: nu:🐚:only_supports_this_input_type # => # => × Input type not supported. # => ╭─[entry #14:2:6] # => 2 │ echo 1 | zip [2] # => · ┬ ─┬─ # => · │ ╰── only list<any> and range input data is supported # => · ╰── input type: int # => ╰──── ``` # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> **Breaking change**: The type of a command's input is now checked against the input/output types of that command at run-time. While these errors should mostly be caught at parse-time, in cases where they can't be detected at parse-time they will be caught at run-time instead. This applies to both internal commands and custom commands. Example function and corresponding parse-time error (same before and after PR): ```nushell def foo []: int -> nothing { print $"my cool int is ($in)" } 1 | foo # => my cool int is 1 "evil string" | foo # => Error: nu::parser::input_type_mismatch # => # => × Command does not support string input. # => ╭─[entry #16:1:17] # => 1 │ "evil string" | foo # => · ─┬─ # => · ╰── command doesn't support string input # => ╰──── # => ``` Before: ```nu echo "evil string" | foo # => my cool int is evil string ``` After: ```nu echo "evil string" | foo # => Error: nu:🐚:only_supports_this_input_type # => # => × Input type not supported. # => ╭─[entry #17:1:6] # => 1 │ echo "evil string" | foo # => · ──────┬────── ─┬─ # => · │ ╰── only int input data is supported # => · ╰── input type: string # => ╰──── ``` Known affected internal commands which erroneously accepted any type: * `str join` * `zip` * `reduce` # Tests + Formatting <!-- Don't forget to add tests that cover your changes. Make sure you've run and fixed any issues with these commands: - `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes) - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> - 🟢 `toolkit fmt` - 🟢 `toolkit clippy` - 🟢 `toolkit test` - 🟢 `toolkit test stdlib` # After Submitting <!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. --> * Play whack-a-mole with the commands and scripts this will inevitably break
hustcer
pushed a commit
that referenced
this pull request
Jan 11, 2025
# Description This PR should address #13530 by explicitly handling ByteStreams. The issue can be replicated easily on linux by running: ```nushell open /dev/urandom | into binary | bytes at ..10 ``` Would leave the output hanging and with no way to cancel it, this was likely because it was trying to collect the input stream and would not complete. I have also put in an error to say that using negative offsets for a bytestream without a length cannot be used. ```nushell ~/git/nushell> open /dev/urandom | into binary | bytes at (-1).. Error: nu::shell::incorrect_value × Incorrect value. ╭─[entry #3:1:35] 1 │ open /dev/urandom | into binary | bytes at (-1).. · ────┬─── ───┬── · │ ╰── encountered here · ╰── Negative range values cannot be used with streams that don't specify a length ╰──── ``` # User-Facing Changes No operation changes, only the warning you get back for negative offsets # Tests + Formatting Ran `toolkit check pr ` with no errors or warnings Manual testing of the example commands above --------- Co-authored-by: Ian Manske <ian.manske@pm.me> Co-authored-by: Simon Curtis <simon.curtis@candc-uk.com>
hustcer
pushed a commit
that referenced
this pull request
Apr 11, 2025
Issue #12289, can be closed when this is merged
# Description
Currently, the ``into datetime`` command's signature indicates that it
supports input as record, but it was actually not supported.
This PR implements this feature.
# User-Facing Changes
``into datetime``'s signature changed (see comments)
**Happy paths**
Note: I'm in +02:00 timezone.
```nushell
> date now | into record | into datetime
Fri, 4 Apr 2025 18:32:34 +0200 (now)
> {year: 2025, month: 12, day: 6, second: 59} | into datetime | into record
╭─────────────┬────────╮
│ year │ 2025 │
│ month │ 12 │
│ day │ 6 │
│ hour │ 0 │
│ minute │ 0 │
│ second │ 59 │
│ millisecond │ 0 │
│ microsecond │ 0 │
│ nanosecond │ 0 │
│ timezone │ +02:00 │
╰─────────────┴────────╯
> {day: 6, second: 59, timezone: '-06:00'} | into datetime | into record
╭─────────────┬────────╮
│ year │ 2025 │
│ month │ 4 │
│ day │ 6 │
│ hour │ 0 │
│ minute │ 0 │
│ second │ 59 │
│ millisecond │ 0 │
│ microsecond │ 0 │
│ nanosecond │ 0 │
│ timezone │ -06:00 │
╰─────────────┴────────╯
```
**Edge cases**
```nushell
{} | into datetime
Fri, 4 Apr 2025 18:35:19 +0200 (now)
```
**Error paths**
- A key has a wrong type
```nushell
> {month: 12, year: '2023'} | into datetime
Error: nu::shell::only_supports_this_input_type
× Input type not supported.
╭─[entry #8:1:19]
1 │ {month: 12, year: '2023'} | into datetime
· ───┬── ──────┬──────
· │ ╰── only int input data is supported
· ╰── input type: string
╰────
```
```nushell
> {month: 12, year: 2023, timezone: 100} | into datetime
Error: nu:🐚:only_supports_this_input_type
× Input type not supported.
╭─[entry #10:1:35]
1 │ {month: 12, year: 2023, timezone: 100} | into datetime
· ─┬─ ──────┬──────
· │ ╰── only string input data is supported
· ╰── input type: int
╰────
```
- Key has the right type but value invalid (e.g. month=13, or day=0)
```nushell
> {month: 13, year: 2023} | into datetime
Error: nu:🐚:incorrect_value
× Incorrect value.
╭─[entry #9:1:1]
1 │ {month: 13, year: 2023} | into datetime
· ───────────┬─────────── ──────┬──────
· │ ╰── one of more values are incorrect and do not represent valid date
· ╰── encountered here
╰────
```
```nushell
> {hour: 1, minute: 1, second: 70} | into datetime
Error: nu:🐚:incorrect_value
× Incorrect value.
╭─[entry #3:1:1]
1 │ {hour: 1, minute: 1, second: 70} | into datetime
· ────────────────┬─────────────── ──────┬──────
· │ ╰── one of more values are incorrect and do not represent valid time
· ╰── encountered here
╰────
```
- Timezone has right type but is invalid
```nushell
> {month: 12, year: 2023, timezone: "+100:00"} | into datetime
Error: nu:🐚:incorrect_value
× Incorrect value.
╭─[entry #11:1:35]
1 │ {month: 12, year: 2023, timezone: "+100:00"} | into datetime
· ────┬──── ──────┬──────
· │ ╰── encountered here
· ╰── invalid timezone
╰────
```
- Record contains an invalid key
```nushell
> {month: 12, year: 2023, unknown: 1} | into datetime
Error: nu:🐚:unsupported_input
× Unsupported input
╭─[entry #12:1:1]
1 │ {month: 12, year: 2023, unknown: 1} | into datetime
· ─────────────────┬───────────────── ──────┬──────
· │ ╰── Column 'unknown' is not valid for a structured datetime. Allowed
columns are: year, month, day, hour, minute, second, millisecond,
microsecond, nanosecond, timezone
· ╰── value originates from here
╰────
```
- If several issues are present, the user can get the error msg for only
one, though
```nushell
> {month: 20, year: '2023'} | into datetime
Error: nu:🐚:only_supports_this_input_type
× Input type not supported.
╭─[entry #7:1:19]
1 │ {month: 20, year: '2023'} | into datetime
· ───┬── ──────┬──────
· │ ╰── only int input data is supported
· ╰── input type: string
╰
```
# Tests + Formatting
Tests added
Fmt + clippy OK
# After Submitting
Maybe indicate that in the release notes
I added an example in the command, so the documentation will be
automatically updated.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 quick-xml from 0.28.2 to 0.29.0.
Release notes
Sourced from quick-xml's releases.
Changelog
Sourced from quick-xml's changelog.
Commits
5a536d0Release v0.29.07629a70Change names of methods that emits events to reflect their purpose70f4a9cChange order of variants, group text variants together621da10Merge pull request #594 from Kriskras99/master858118eAdd a helper macro to help deserialize internally tagged enums with Serde88a2f27Merge pull request #612 from Tpt/empty-doctypea86340bFails on empty doctype358cc58Merge pull request #603 from danjpgriffin/masterd49f2d5TrimTextevents after DOCTYPE so spaces does not produce an event.c8332d9Add tests for comments and processing instructions in XML prologDependabot 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)