test in the CI by amtoine · Pull Request #3 · amtoine/nushell

amtoine · 2023-06-16T09:18:37Z

⚠️ this is a test

as `cargo clippy` and `cargo test` already run with the `--workspace` option triggered, adding `--features` does not do anything.

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

…ushell#10430) should close 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

errors look like ```nushell > update value (get value) Error: nu::shell::io_error × I/O error help: can't follow path '[String { val: "value", span: Span { start: 243376, end: 243381 }, optional: false }]' in empty stream ``` ```nushell > ^echo "foo" | get 0 Error: nu::shell::io_error × I/O error ╭─[entry #3:1:1] 1 │ ^echo "foo" | get 0 · ──┬─ · ╰── can't follow path '[Int { val: 0, span: Span { start: 243417, end: 243418 }, optional: false }]' in external stream ╰──── ```

should close nushell#10549 # Description this PR is twofold - uses `to nuon --raw` in the error messages to make sure nushell#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 nushell#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 nushell#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 nushell#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 nushell#13:1:1] 1 │ assert str contains "foo" "bar" · ─────┬───── · ╰── This does not contain '($right)'. value: "foo" ╰──── ``` # Tests + Formatting # After Submitting

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

@kubouch

Closes nushell#11561 # Description  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  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  # After Submitting  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

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

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

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

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

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

amtoine added 4 commits June 16, 2023 11:14

remove the --features from the CI

87719fc

as `cargo clippy` and `cargo test` already run with the `--workspace` option triggered, adding `--features` does not do anything.

remove the useless nu-coverage job

26ad8b3

TEST: refactor clippy options in env variable

1be509c

be consistent in the env+strategy blocks

a915582

amtoine closed this Jun 18, 2023

amtoine deleted the foo branch June 23, 2023 16:39

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

test in the CI#3

test in the CI#3
amtoine wants to merge 4 commits intomainfrom
foo

amtoine commented Jun 16, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

amtoine commented Jun 16, 2023

⚠️ this is a test

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant