The test added in #15115 fails on systems using later versions of `man`
(2.13.0 triggers the issue, at least). This updates the test to ignore
formatting characters.
Thanks to @fdncred and @blindFS for the debugging assistance.
# Description
<img width="642" alt="image"
src="https://github.com/user-attachments/assets/a97e4f33-df12-4240-a221-d4b97a171de0"
/>
Not particularly useful, but better than showing nothing I guess. #14464
Also fixed a markdown syntax issue for mutable variable hovering
# User-Facing Changes
# Tests + Formatting
+1
# After Submitting
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
The banner will now use three new `$env.config.color_config` settings:
- `banner_foreground`: The primary color of the banner text
- `banner_highlight1`: Used for the first set of highlights, e.g.,
`Nushell`, `nu`, `GitHub`, et. al
- `banner_highlight2`: Used for the second set of highlights, e.g.
`Discord`, `Documentation`, et. al.
If the settings above are not defined, `banner` continues to use the
default green/purple/foreground. However, two more lines use the
purple/highlight2 in order to give more separation and consistency to
the colorization.
# Description
There has been multiple instances of users being unable to discover that
`chunks` can be used with binary data.
This should make it easier for users to discover that (using `help -f`).
# User-Facing Changes
Help text of `chunks` updated as mentioned above.
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
Should we consider mentioning commands that can work with binary input
(first, take, chunks, etc) in the help text for `bytes`?
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
# Description
Update some comments and fix potential security issue:
SQL Injection in DELETE statements: The code constructs SQL queries by
interpolating the $key variable directly into the string. If a key
contains malicious input could lead to SQL injection. Need to use
parameterized queries or escaping.
Manually added bindings take priority to the vi-mode state machine in
reedline thus this addition blocked the use of `f/`/`t/` etc.
Partial revert of #14908
Addresses #15096 with a temporary fix. The full solution of that should
resolve it on the reedline side so you can have both the search option
and the availability of `/` in normal mode bindings
# Description
`overlay use` now imports constants exported from modules, just like
`use`.
```nushell
# foo.nu
export const a = 1
export const b = 2
```
- `overlay use foo.nu` being equivalent to `use foo.nu *` and exposing
constants `$a = 1` and `$b = 2`
- `overlay use foo.nu -p` being equivalent to `use foo.nu` and exposing
the constant `$foo = {a: 1, b: 2}`
# User-Facing Changes
`overlay use` now imports constants just like `use`.
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
N/A
# Description
This PR adds two new `ParseError` and `ShellError` cases for type errors
relating to operators.
- `OperatorUnsupportedType` is used when a type is not supported by an
operator in any way, shape, or form. E.g., `+` does not support `bool`.
- `OperatorIncompatibleTypes` is used when a operator is used with types
it supports, but the combination of types provided cannot be used
together. E.g., `filesize + duration` is not a valid combination.
The other preexisting error cases related to operators have been removed
and replaced with the new ones above. Namely:
- `ShellError::OperatorMismatch`
- `ShellError::UnsupportedOperator`
- `ParseError::UnsupportedOperationLHS`
- `ParseError::UnsupportedOperationRHS`
- `ParseError::UnsupportedOperationTernary`
# User-Facing Changes
- `help operators` now lists the precedence of `not` as 55 instead of 0
(above the other boolean operators). Fixes#13675.
- `math median` and `math mode` now ignore NaN values so that `[NaN NaN]
| math median` and `[NaN NaN] | math mode` no longer trigger a type
error. Instead, it's now an empty input error. Fixing this in earnest
can be left for a future PR.
- Comparisons with `nan` now return false instead of causing an error.
E.g., `1 == nan` is now `false`.
- All the operator type errors have been standardized and reworked. In
particular, they can now have a help message, which is currently used
for types errors relating to `++`.
```nu
[1] ++ 2
```
```
Error: nu::parser::operator_unsupported_type
× The '++' operator does not work on values of type 'int'.
╭─[entry #1:1:5]
1 │ [1] ++ 2
· ─┬ ┬
· │ ╰── int
· ╰── does not support 'int'
╰────
help: if you meant to append a value to a list or a record to a table, use the `append` command or wrap the value in a list. For example: `$list ++ $value` should be
`$list ++ [$value]` or `$list | append $value`.
```
- fixes#14559
# Description
Allow using `const` keyword in const contexts. The `run_const` body is
basically empty as the actual logic is already handled by the parser.
# User-Facing Changes
`const` keyword can now be used in `const` contexts.
# Tests + Formatting
I'll add some tests before marking this ready.
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
N/A
---------
Co-authored-by: Bahex <17417311+Bahex@users.noreply.github.com>
After #14906, the test runner was updated to use attributes, along with
the existing `std` modules. However, since that PR was started before
`std-rfc` was in main, it didn't include updates to those tests. Once
#14906 was merged, the `std-rfc` tests no longer ran in CI. This PR
updates the tests accordingly.
Bumps [data-encoding](https://github.com/ia0/data-encoding) from 2.7.0
to 2.8.0.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="284f84626a"><code>284f846</code></a>
Release 2.8.0 (<a
href="https://redirect.github.com/ia0/data-encoding/issues/134">#134</a>)</li>
<li><a
href="b6f9f3b9d6"><code>b6f9f3b</code></a>
Remove MSRV for unpublished crates (<a
href="https://redirect.github.com/ia0/data-encoding/issues/133">#133</a>)</li>
<li><a
href="c060e6873c"><code>c060e68</code></a>
Delete outdated cargo cache to force save (<a
href="https://redirect.github.com/ia0/data-encoding/issues/132">#132</a>)</li>
<li><a
href="d62d722222"><code>d62d722</code></a>
Remove top-level Makefile (<a
href="https://redirect.github.com/ia0/data-encoding/issues/131">#131</a>)</li>
<li><a
href="5e86676a34"><code>5e86676</code></a>
Improve CI workflow (<a
href="https://redirect.github.com/ia0/data-encoding/issues/130">#130</a>)</li>
<li><a
href="8a9537cf64"><code>8a9537c</code></a>
Improve fuzzing (<a
href="https://redirect.github.com/ia0/data-encoding/issues/129">#129</a>)</li>
<li><a
href="27a68f43cd"><code>27a68f4</code></a>
Add missing safety documentation and assertions for testing and fuzzing
(<a
href="https://redirect.github.com/ia0/data-encoding/issues/128">#128</a>)</li>
<li><a
href="06b0d89b11"><code>06b0d89</code></a>
Add BASE32_NOPAD_NOCASE and BASE32_NOPAD_VISUAL (<a
href="https://redirect.github.com/ia0/data-encoding/issues/127">#127</a>)</li>
<li>See full diff in <a
href="https://github.com/ia0/data-encoding/compare/v2.7.0...v2.8.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
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-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will 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 version` will 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 dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
<!--
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 replaces the usage of `proc-macro-error` with
`proc-macro-error2`. At the time of writing `nu-derive-value` this
wasn't an option, at least it wasn't clear that it is the direction to
go. This shouldn't change any of the usage of `nu-derive-value` in any
way but removes one security warning.
`proc-macro-error` depends on `syn 1`, that's why I initially had the
default features for `proc-macro-error` disabled. `proc-macro-error2`
uses `syn 2` as mostly everything. So we can use that.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Same interface, no 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
> ```
-->
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
The tests for `nu-derive-value` do not test spans, so maybe something
changed now but probably not.
# 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.
-->
We still have `quickcheck` which depends on `syn 1` but it seems we need
that for `nu-cmd-lang`. Would be great if, in the future, we can get rid
of `syn 1` as that should improve build times a bit.
# Description
Zyphys found that when parsing `{...{}, ...{}, a: 1}`, the `a:` would be
considered one token, leading to a parse error ([Discord
message](https://discord.com/channels/601130461678272522/614593951969574961/1336762075535511573)).
This PR fixes that.
What would happen is that while getting tokens, the following would
happen in a loop:
1. Get the next two tokens while treating `:` as a special character (so
we get the next field key and a colon token)
2. Get the next token while not treating `:` as a special character (so
we get the next value)
I didn't update this when I added the spread operator. With `{...{},
...{}, a: 1}`, the first two tokens would be `...{}` and `...{}`, and
the next token would be `a:`. This PR changes this loop to first get a
single token, check if it's spreading a record, and move on if so.
Alternatives considered:
- Treat `:` as a special character when getting the value too. This
would simplify the loop greatly, but would mean you can't use colons in
values.
- Merge the loop for getting tokens and the loop for parsing those
tokens. I tried this, but it complicates things if you run into a syntax
error and want to create a garbage span going to the end of the record.
# User-Facing Changes
Nothing new
# Description
Close: #15083
This pr will set `pre` field of version to `Prerelease::EMPTY`, as
nushell does not require this level of checking currently.
# User-Facing Changes
NaN
# Tests + Formatting
Added 1 test
# After Submitting
NaN
# Description
Add custom command attributes.
- Attributes are placed before a command definition and start with a `@`
character.
- Attribute invocations consist of const command call. The command's
name must start with "attr ", but this prefix is not used in the
invocation.
- A command named `attr example` is invoked as an attribute as
`@example`
- Several built-in attribute commands are provided as part of this PR
- `attr example`: Attaches an example to the commands help text
```nushell
# Double numbers
@example "double an int" { 5 | double } --result 10
@example "double a float" { 0.5 | double } --result 1.0
def double []: [number -> number] {
$in * 2
}
```
- `attr search-terms`: Adds search terms to a command
- ~`attr env`: Equivalent to using `def --env`~
- ~`attr wrapped`: Equivalent to using `def --wrapped`~ shelved for
later discussion
- several testing related attributes in `std/testing`
- If an attribute has no internal/special purpose, it's stored as
command metadata that can be obtained with `scope commands`.
- This allows having attributes like `@test` which can be used by test
runners.
- Used the `@example` attribute for `std` examples.
- Updated the std tests and test runner to use `@test` attributes
- Added completions for attributes
# User-Facing Changes
Users can add examples to their own command definitions, and add other
arbitrary attributes.
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
- Add documentation about the attribute syntax and built-in attributes
- `help attributes`
---------
Co-authored-by: 132ikl <132@ikl.sh>
# Description
Pre-cratification of `nu-command` we added tests that covered the whole
command set to ensure consistent documentation style choices and that
the search terms which are added are not uselessly redundant. These
tests are now moved into the suite of the main binary to truly cover all
commands.
- **Move parser quickcheck "fuzz" to `nu-cmd-lang`**
- **Factor out creation of full engine state for tests**
- **Move all-command tests to main context creation**
- **Fix all descriptions**
- **Fix search term duplicate**
# User-Facing Changes
As a result I had to fix a few command argument descriptions. (Doesn't
mean I fully stand behind this choice, but) positionals
(rest/required/optional) and top level descriptions should start with a
capital letter and end with a period. This is not enforced for flags.
# Tests + Formatting
Furthermore I moved our poor-peoples-fuzzer that runs in CI with
`quicktest` over the parser to `nu-cmd-lang` reducing its command set to
just the keywords (similar to
https://github.com/nushell/nushell/pull/15036). Thus this should also
run slightly faster (maybe a slight parallel build cost due to earlier
dependency on quicktest)
# Description
This PR makes `match` no longer run closures as if they were blocks.
This also allows returning closures from `match` without needing to wrap
in an outer subexpression or block.
Before PR:
```nushell
match 1 { _ => {|| print hi} }
# => hi
```
After PR:
```nushell
match 1 { _ => {|| print hi} }
# => closure_1090
```
# User-Facing Changes
* `match` no longer runs closures as if they were blocks
# Tests + Formatting
N/A
# After Submitting
N/A
# Description
The index in `explore --index` starting with 1 is inconsistent with rest
of nushell. Also it tripped me up a few times when I wanted to select a
row with `:nu get n`
# User-Facing Changes
Index in `explore --index` now starts with 0.
# Tests + Formatting
- 🟢 toolkit fmt
- 🟢 toolkit clippy
- 🟢 toolkit test
- 🟢 toolkit test stdlib
# After Submitting
N/A
# Description
Fixes: #15049
The error occurs when using an alias with a module prefix, it can
initially pass through alias checking, but if the alias leads to
commands which have side effects, it doesn't call these functions to
apply side effects.
This pr ensure that in such cases, nushell still calls
`parse_overlay_xxx` functions to apply the side effects.
I want to make my test easier to write, so this pr depends on
https://github.com/nushell/nushell/pull/15054.
# User-Facing Changes
The following code will no longer raise an error:
```
module inner {}
module spam { export alias b = overlay use inner }
use spam
spam b
```
# Tests + Formatting
Added 2 tests.
# After Submitting
NaN
# Description
Fixes: #15048
The issue is happened while `parse_export_in_block`, it makes a call to
`parse_internal_call`, which may be an error.
But in reality, these errors are not useful, all useful errors will be
generated by `parse_xxx` at the end of the function.
# User-Facing Changes
The following code should no longer raise error:
```
export alias a = overlay use
```
# Tests + Formatting
Added 1 test.
# After Submitting
NaN
# Description
fixes#14643 , as well as some nested cell path cases:
```nushell
let foo = {a: [1 {a: 1}]}
$foo.a.1.#<tab>
const bar = {a: 1, b: 2}
$bar.#<tab>
```
So my plan of the refactoring process is that:
1. gradually move those rules of flattened shapes into expression match
branches, until they are gone
2. keep each PR focused, easier to review and track.
# User-Facing Changes
# Tests + Formatting
+2
# After Submitting
Fixes#15061
# User-Facing Changes
Fixes panics when slicing empty input with inclusive ranges:
```nushell
> random binary 0 | bytes at 0..0
Error: x Main thread panicked.
|-> at crates/nu-protocol/src/value/range.rs:118:42
`-> attempt to subtract with overflow
```
# Description
Current CI tests `std-lib-and-python-virtualenv` using Nushell installed
with:
```
cargo install --path . --locked --no-default-features --force
```
However, this disables certain features that may be utilized in `std` or
(now) `std-rfc`; namely `stor` and `into sqlite`.
This PR simply removes the `--no-default-features` flag, which *should*
allow #15042 CI to complete successfully.
Historically, I believe that this was set up to mirror
[`pypa/virtualenv`
CI](https://github.com/pypa/virtualenv/pulls?q=is%3Apr+is%3Amerged+nushell).
However, with all Nushell binary builds now including these features, it
seems to me that a more accurate CI will test with default features. Let
me know if my understanding is off here, and we can look for
alternatives.
# User-Facing Changes
None
# Tests + Formatting
CI Update
# After Submitting
N/A
<!--
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.
-->
In #14968 I grepped the code for `IoError::new` calls with unknown
spans, but I forgot to also grep for
`IoError::new_with_additional_context`, so I missed some. Hopefullly
this is the last P.S. to #14968.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
N/A
# 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
# Description
This PR fixes one reported bug of recent lsp changes.
It exit unexpectedly with empty `root_dir` settings in neovim.
# User-Facing Changes
# Tests + Formatting
+1 test case
# After Submitting
Make sure that when creating a cherry-picked or otherwise diverging
patch release branch the final product still gets checked via CI before
a release is cut.
To trigger this patch release branches MUST follow the pattern:
`patch-release-*` (e.g. `patch-release-0.102.1`)
# Description
The parsing logic for several of our keywords is conditional on the
particular commands for those keywords being in scope:
942030199d/crates/nu-parser/src/parse_keywords.rs (L272-L279)
Thus the following involved parsing logic was not fuzzed by the existing
`parse` fuzz target so far.
This adds an additional fuzz target `parse_with_keywords` that loads the
commands from `nu-cmd-lang`. Those are primarily the keyword
implementations, thus the relevant code paths in the parser that depend
on those `DeclId`s and the potential const eval of `if` etc. get
unlocked.
The existing `parse` target is preserved if you have concerns about the
fuzzing breaking containment in some form due to those commands.
# Tests + Formatting
Found https://github.com/nushell/nushell/issues/14972 with this target
# Description
The `(version).build_os` variable inherits from `shadow_rs` `BUILD_OS`
which points to the OS on which the binary was built but does not
reflect the target if it was cross-compiled. We cross-compile several of
the targets for our binary releases. Thus the info in the banner was
misleading.
# User-Facing Changes
By changing to `build_target` the target triple is shown instead.
This is slightly more verbose but should also allow disambiguation
between the `musl` and `glibc` builds.
# Tests + Formatting
(-)
