2019-05-10 18:59:12 +02:00
|
|
|
[package]
|
2022-03-13 19:30:27 +01:00
|
|
|
authors = ["The Nushell Project Developers"]
|
2023-05-20 14:57:51 +02:00
|
|
|
build = "scripts/build.rs"
|
2020-07-05 22:12:44 +02:00
|
|
|
default-run = "nu"
|
2020-04-06 09:16:14 +02:00
|
|
|
description = "A new type of shell"
|
2020-07-05 22:12:44 +02:00
|
|
|
documentation = "https://www.nushell.sh/book/"
|
2023-01-05 13:24:42 +01:00
|
|
|
edition = "2021"
|
2020-07-05 22:12:44 +02:00
|
|
|
exclude = ["images"]
|
|
|
|
|
homepage = "https://www.nushell.sh"
|
|
|
|
|
license = "MIT"
|
|
|
|
|
name = "nu"
|
2019-07-16 21:17:46 +02:00
|
|
|
repository = "https://github.com/nushell/nushell"
|
2024-11-29 21:46:58 +01:00
|
|
|
rust-version = "1.81.0"
|
2024-11-14 10:04:39 +01:00
|
|
|
version = "0.100.1"
|
2021-06-30 03:42:56 +02:00
|
|
|
|
|
|
|
|
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
|
|
|
|
|
|
2022-11-23 17:46:06 +01:00
|
|
|
[package.metadata.binstall]
|
|
|
|
|
pkg-url = "{ repo }/releases/download/{ version }/{ name }-{ version }-{ target }.{ archive-format }"
|
|
|
|
|
pkg-fmt = "tgz"
|
|
|
|
|
|
|
|
|
|
[package.metadata.binstall.overrides.x86_64-pc-windows-msvc]
|
|
|
|
|
pkg-fmt = "zip"
|
|
|
|
|
|
2021-08-25 21:29:36 +02:00
|
|
|
[workspace]
|
2021-10-28 08:12:33 +02:00
|
|
|
members = [
|
2024-03-07 23:40:31 +01:00
|
|
|
"crates/nu-cli",
|
|
|
|
|
"crates/nu-engine",
|
|
|
|
|
"crates/nu-parser",
|
|
|
|
|
"crates/nu-system",
|
|
|
|
|
"crates/nu-cmd-base",
|
|
|
|
|
"crates/nu-cmd-extra",
|
|
|
|
|
"crates/nu-cmd-lang",
|
2024-04-21 14:36:26 +02:00
|
|
|
"crates/nu-cmd-plugin",
|
2024-03-07 23:40:31 +01:00
|
|
|
"crates/nu-command",
|
|
|
|
|
"crates/nu-color-config",
|
|
|
|
|
"crates/nu-explore",
|
|
|
|
|
"crates/nu-json",
|
|
|
|
|
"crates/nu-lsp",
|
|
|
|
|
"crates/nu-pretty-hex",
|
|
|
|
|
"crates/nu-protocol",
|
Add derive macros for `FromValue` and `IntoValue` to ease the use of `Value`s in Rust code (#13031)
# Description
After discussing with @sholderbach the cumbersome usage of
`nu_protocol::Value` in Rust, I created a derive macro to simplify it.
I’ve added a new crate called `nu-derive-value`, which includes two
macros, `IntoValue` and `FromValue`. These are re-exported in
`nu-protocol` and should be encouraged to be used via that re-export.
The macros ensure that all types can easily convert from and into
`Value`. For example, as a plugin author, you can define your plugin
configuration using a Rust struct and easily convert it using
`FromValue`. This makes plugin configuration less of a hassle.
I introduced the `IntoValue` trait for a standardized approach to
converting values into `Value` (and a fallible variant `TryIntoValue`).
This trait could potentially replace existing `into_value` methods.
Along with this, I've implemented `FromValue` for several standard types
and refined other implementations to use blanket implementations where
applicable.
I made these design choices with input from @devyn.
There are more improvements possible, but this is a solid start and the
PR is already quite substantial.
# User-Facing Changes
For `nu-protocol` users, these changes simplify the handling of
`Value`s. There are no changes for end-users of nushell itself.
# Tests + Formatting
Documenting the macros itself is not really possible, as they cannot
really reference any other types since they are the root of the
dependency graph. The standard library has the same problem
([std::Debug](https://doc.rust-lang.org/stable/std/fmt/derive.Debug.html)).
However I documented the `FromValue` and `IntoValue` traits completely.
For testing, I made of use `proc-macro2` in the derive macro code. This
would allow testing the generated source code. Instead I just tested
that the derived functionality is correct. This is done in
`nu_protocol::value::test_derive`, as a consumer of `nu-derive-value`
needs to do the testing of the macro usage. I think that these tests
should provide a stable baseline so that users can be sure that the impl
works.
# After Submitting
With these macros available, we can probably use them in some examples
for plugins to showcase the use of them.
2024-06-18 01:05:11 +02:00
|
|
|
"crates/nu-derive-value",
|
2024-03-07 23:40:31 +01:00
|
|
|
"crates/nu-plugin",
|
2024-04-27 19:08:12 +02:00
|
|
|
"crates/nu-plugin-core",
|
|
|
|
|
"crates/nu-plugin-engine",
|
|
|
|
|
"crates/nu-plugin-protocol",
|
2024-03-23 19:29:54 +01:00
|
|
|
"crates/nu-plugin-test-support",
|
2024-03-07 23:40:31 +01:00
|
|
|
"crates/nu_plugin_inc",
|
|
|
|
|
"crates/nu_plugin_gstat",
|
|
|
|
|
"crates/nu_plugin_example",
|
|
|
|
|
"crates/nu_plugin_query",
|
|
|
|
|
"crates/nu_plugin_custom_values",
|
|
|
|
|
"crates/nu_plugin_formats",
|
2024-04-10 02:31:43 +02:00
|
|
|
"crates/nu_plugin_polars",
|
Local socket mode and foreground terminal control for plugins (#12448)
# Description
Adds support for running plugins using local socket communication
instead of stdio. This will be an optional thing that not all plugins
have to support.
This frees up stdio for use to make plugins that use stdio to create
terminal UIs, cc @amtoine, @fdncred.
This uses the [`interprocess`](https://crates.io/crates/interprocess)
crate (298 stars, MIT license, actively maintained), which seems to be
the best option for cross-platform local socket support in Rust. On
Windows, a local socket name is provided. On Unixes, it's a path. The
socket name is kept to a relatively small size because some operating
systems have pretty strict limits on the whole path (~100 chars), so on
macOS for example we prefer `/tmp/nu.{pid}.{hash64}.sock` where the hash
includes the plugin filename and timestamp to be unique enough.
This also adds an API for moving plugins in and out of the foreground
group, which is relevant for Unixes where direct terminal control
depends on that.
TODO:
- [x] Generate local socket path according to OS conventions
- [x] Add support for passing `--local-socket` to the plugin executable
instead of `--stdio`, and communicating over that instead
- [x] Test plugins that were broken, including
[amtoine/nu_plugin_explore](https://github.com/amtoine/nu_plugin_explore)
- [x] Automatically upgrade to using local sockets when supported,
falling back if it doesn't work, transparently to the user without any
visible error messages
- Added protocol feature: `LocalSocket`
- [x] Reset preferred mode to `None` on `register`
- [x] Allow plugins to detect whether they're running on a local socket
and can use stdio freely, so that TUI plugins can just produce an error
message otherwise
- Implemented via `EngineInterface::is_using_stdio()`
- [x] Clean up foreground state when plugin command exits on the engine
side too, not just whole plugin
- [x] Make sure tests for failure cases work as intended
- `nu_plugin_stress_internals` added
# User-Facing Changes
- TUI plugins work
- Non-Rust plugins could optionally choose to use this
- This might behave differently, so will need to test it carefully
across different operating systems
# Tests + Formatting
- :green_circle: `toolkit fmt`
- :green_circle: `toolkit clippy`
- :green_circle: `toolkit test`
- :green_circle: `toolkit test stdlib`
# After Submitting
- [ ] Document local socket option in plugin contrib docs
- [ ] Document how to do a terminal UI plugin in plugin contrib docs
- [ ] Document: `EnterForeground` engine call
- [ ] Document: `LeaveForeground` engine call
- [ ] Document: `LocalSocket` protocol feature
2024-04-15 20:28:18 +02:00
|
|
|
"crates/nu_plugin_stress_internals",
|
2024-03-07 23:40:31 +01:00
|
|
|
"crates/nu-std",
|
|
|
|
|
"crates/nu-table",
|
|
|
|
|
"crates/nu-term-grid",
|
|
|
|
|
"crates/nu-test-support",
|
|
|
|
|
"crates/nu-utils",
|
create `nuon` crate from `from nuon` and `to nuon` (#12553)
# Description
playing with the NUON format in Rust code in some plugins, we agreed
with the team it was a great time to create a standalone NUON format to
allow Rust devs to use this Nushell file format.
> **Note**
> this PR almost copy-pastes the code from
`nu_commands/src/formats/from/nuon.rs` and
`nu_commands/src/formats/to/nuon.rs` to `nuon/src/from.rs` and
`nuon/src/to.rs`, with minor tweaks to make then standalone functions,
e.g. remove the rest of the command implementations
### TODO
- [x] add tests
- [x] add documentation
# User-Facing Changes
devs will have access to a new crate, `nuon`, and two functions,
`from_nuon` and `to_nuon`
```rust
from_nuon(
input: &str,
span: Option<Span>,
) -> Result<Value, ShellError>
```
```rust
to_nuon(
input: &Value,
raw: bool,
tabs: Option<usize>,
indent: Option<usize>,
span: Option<Span>,
) -> Result<String, ShellError>
```
# Tests + Formatting
i've basically taken all the tests from
`crates/nu-command/tests/format_conversions/nuon.rs` and converted them
to use `from_nuon` and `to_nuon` instead of Nushell commands
- i've created a `nuon_end_to_end` to run both conversions with an
optional middle value to check that all is fine
> **Note**
> the `nuon::tests::read_code_should_fail_rather_than_panic` test does
give different results locally and in the CI...
> i've left it ignored with comments to help future us :)
# After Submitting
mention that in the release notes for sure!!
2024-04-19 13:54:16 +02:00
|
|
|
"crates/nuon",
|
2021-10-28 08:12:33 +02:00
|
|
|
]
|
2021-08-25 21:29:36 +02:00
|
|
|
|
2024-03-07 23:40:31 +01:00
|
|
|
[workspace.dependencies]
|
2024-03-24 00:46:02 +01:00
|
|
|
alphanumeric-sort = "1.5"
|
|
|
|
|
ansi-str = "0.8"
|
`explore`: adopt `anyhow`, support `CustomValue`, remove help system (#12692)
This PR:
1. Adds basic support for `CustomValue` to `explore`. Previously `open
foo.db | explore` didn't really work, now we "materialize" the whole
database to a `Value` before loading it
2. Adopts `anyhow` for error handling in `explore`. Previously we were
kind of rolling our own version of `anyhow` by shoving all errors into a
`std::io::Error`; I think this is much nicer. This was necessary because
as part of 1), collecting input is now fallible...
3. Removes a lot of `explore`'s fancy command help system.
- Previously each command (`:help`, `:try`, etc.) had a sophisticated
help system with examples etc... but this was not very visible to users.
You had to know to run `:help :try` or view a list of commands with
`:help :`
- As discussed previously, we eventually want to move to a less modal
approach for `explore`, without the Vim-like commands. And so I don't
think it's worth keeping this command help system around (it's
intertwined with other stuff, and making these changes would have been
harder if keeping it).
4. Rename the `--reverse` flag to `--tail`. The flag scrolls to the end
of the data, which IMO is described better by "tail"
5. Does some renaming+commenting to clear up things I found difficult to
understand when navigating the `explore` code
I initially thought 1) would be just a few lines, and then this PR blew
up into much more extensive changes 😅
## Before
The whole database was being displayed as a single Nuon/JSON line 🤔
## After
The database gets displayed like a record
## Future work
It is sort of annoying that we have to load a whole SQLite database into
memory to make this work; it will be impractical for large databases.
I'd like to explore improvements to `CustomValue` that can make this
work more efficiently.
2024-05-02 00:34:37 +02:00
|
|
|
anyhow = "1.0.82"
|
2024-05-04 17:16:40 +02:00
|
|
|
base64 = "0.22.1"
|
2024-11-10 14:00:42 +01:00
|
|
|
bracoxide = "0.1.4"
|
2024-10-23 19:40:37 +02:00
|
|
|
brotli = "6.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
byteorder = "1.5"
|
Improve working with `IntoValue` and `FromValue` for byte collections (#13641)
<!--
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.
-->
I was working with byte collections like `Vec<u8>` and
[`bytes::Bytes`](https://docs.rs/bytes/1.7.1/bytes/struct.Bytes.html),
both are currently not possible to be used directly in a struct that
derives `IntoValue` and `FromValue` at the same time. The `Vec<u8>` will
convert itself into a `Value::List` but expects a `Value::String` or
`Value::Binary` to load from. I now also implemented that it can load
from `Value::List` just like the other `Vec<uX>` versions. For further
working with byte collections the type `bytes::Bytes` is wildly used,
therefore I added a implementation for it. `bytes` is already part of
the dependency graph as many crates (more than 5000 to crates.io) use
it.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
User of `nu-protocol` as library, e.g. plugin developers, can now use
byte collections more easily in their data structures and derive
`IntoValue` and `FromValue` for it.
# 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
> ```
-->
I added a few tests that check that these byte collections are correctly
translated in and from `Value`. They live in `test_derive.rs` as part of
the `ByteContainer` and I also explicitely tested that `FromValue` for
`Vec<u8>` works as expected.
- :green_circle: `toolkit fmt`
- :green_circle: `toolkit clippy`
- :green_circle: `toolkit test`
- :green_circle: `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.
-->
Maybe it should be explored if `Value::Binary` should use `bytes::Bytes`
instead of `Vec<u8>`.
2024-08-23 00:59:00 +02:00
|
|
|
bytes = "1"
|
2024-03-24 00:46:02 +01:00
|
|
|
bytesize = "1.3"
|
2024-11-21 13:31:14 +01:00
|
|
|
calamine = "0.26.1"
|
2024-03-24 00:46:02 +01:00
|
|
|
chardetng = "0.1.17"
|
2024-05-04 20:16:20 +02:00
|
|
|
chrono = { default-features = false, version = "0.4.34" }
|
2024-03-24 00:46:02 +01:00
|
|
|
chrono-humanize = "0.2.3"
|
Bump chrono-tz from 0.8.6 to 0.10.0 (#14205)
Bumps [chrono-tz](https://github.com/chronotope/chrono-tz) from 0.8.6 to
0.10.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/chronotope/chrono-tz/releases">chrono-tz's
releases</a>.</em></p>
<blockquote>
<h2>chrono-tz v0.10.0: 2024b</h2>
<p><strong>TZDB</strong> version 2024b (2024-09-05).</p>
<h2>Changes</h2>
<ul>
<li>Make <code>OffsetName::abbreviation</code> return an
<code>Option</code>.
This reflects that numeric values such as <code>+11</code> are no longer
encoded in the upstream TZDB as abbreviations (<a
href="https://redirect.github.com/chronotope/chrono-tz/issues/185">#185</a>).</li>
</ul>
<h2>TZDB 2024b</h2>
<blockquote>
<p>The 2024b release of the tz code and data is available.</p>
<p>This release is prompted by the accumulated weight of many non-urgent
changes to both code and data. It changes one timestamp abbreviation,
for the long-obsolete System V setting TZ='MET'; see below. Otherwise,
the timestamps affected by this release all predate April 2008, so you
can skip this release if your application uses only tzdata and does not
use older timestamps.</p>
<p>This release contains the following changes:</p>
<h3>Briefly:</h3>
<p>Improve historical data for Mexico, Mongolia, and Portugal.
System V names are now obsolescent.
The main data form now uses %z.
The code now conforms to RFC 8536 for early timestamps.
Support POSIX.1-2024, which removes asctime_r and ctime_r.
Assume POSIX.2-1992 or later for shell scripts.
SUPPORT_C89 now defaults to 1.</p>
<h3>Changes to past timestamps</h3>
<p>Asia/Choibalsan is now an alias for Asia/Ulaanbaatar rather than
being a separate Zone with differing behavior before April 2008. This
seems better given our wildly conflicting information about Mongolia's
time zone history. (Thanks to Heitor David Pinto.)</p>
<p>Historical transitions for Mexico have been updated based on official
Mexican decrees. The affected timestamps occur during the years
1921-1927, 1931, 1945, 1949-1970, and 1981-1997. The affected zones are
America/Bahia_Banderas, America/Cancun, America/Chihuahua,
America/Ciudad_Juarez, America/Hermosillo, America/Mazatlan,
America/Merida, America/Mexico_City, America/Monterrey, America/Ojinaga,
and America/Tijuana. (Thanks to Heitor David Pinto.)</p>
<p>Historical transitions for Portugal, represented by Europe/Lisbon,
Atlantic/Azores, and Atlantic/Madeira, have been updated based on a
close reading of old Portuguese legislation, replacing previous data
mainly originating from Whitman and Shanks & Pottenger. These
changes affect a few transitions in 1917-1921, 1924, and 1940 throughout
these regions by a few hours or days, and various timestamps between
1977 and 1993 depending on the region. In particular, the Azores and
Madeira did not observe DST from 1977 to 1981. Additionally, the
adoption of standard zonal time in former Portuguese colonies have been
adjusted: Africa/Maputo in 1909, and Asia/Dili by 22 minutes at the
start of 1912. (Thanks to Tim Parenti.)</p>
<h3>Changes to past tm_isdst flags</h3>
<p>The period from 1966-04-03 through 1966-10-02 in Portugal is now
modeled as DST, to more closely reflect how contemporaneous changes in
law entered into force.</p>
<h3>Changes to data</h3>
<p>Names present only for compatibility with UNIX System V (last
released in the 1990s) have been moved to 'backward'. These names, which
for post-1970 timestamps mostly just duplicate data of geographical
names, were confusing downstream uses. Names moved to 'backward' are now
links to geographical names. This affects behavior for TZ='EET' for some
pre-1981 timestamps, for TZ='CET' for some pre-1947 timestamps, and for
TZ='WET' for some pre-1996 timestamps. Also, TZ='MET' now behaves like
TZ='CET' and so uses the abbreviation "CET" rather than
"MET". Those needing the previous TZDB behavior, which does
not match any real-world clocks, can find the old entries in 'backzone'.
(Problem reported by Justin Grant.)</p>
<p>The main source files' time zone abbreviations now use %z, supported
by zic since release 2015f and used in vanguard form since release
2022b. For example, America/Sao_Paulo now contains the zone continuation
line "-3:00 Brazil %z", which is less error prone than the old
"-3:00 Brazil -03/-02". This does not change the represented
data: the generated TZif files are unchanged. Rearguard form still
avoids %z, to support obsolescent parsers.</p>
<p>Asia/Almaty has been removed from zonenow.tab as it now agrees with
Asia/Tashkent for future timestamps, due to Kazakhstan's 2024-02-29 time
zone change. Similarly, America/Scoresbysund has been removed, as it now
agrees with America/Nuuk due to its 2024-03-31 time zone change.</p>
</blockquote>
<h2>chrono-tz v0.9.0: 2024a</h2>
<p><strong>TZDB</strong> version <a
href="https://mm.icann.org/pipermail/tz-announce/2024-February/000081.html">2024a</a>
(2024-02-01).</p>
<h2>Changes</h2>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/chronotope/chrono-tz/commit/8450e59393b79e5d6062e6bc6f4477903219f489"><code>8450e59</code></a>
Bump chrono-tz-build to 0.4.0</li>
<li><a
href="https://github.com/chronotope/chrono-tz/commit/6154fd2513cea759143641b7e5f563529a9d2d57"><code>6154fd2</code></a>
Bump version number to 0.10.0</li>
<li><a
href="https://github.com/chronotope/chrono-tz/commit/2d0c48978163d3a00ace75bd34f61da664335a23"><code>2d0c489</code></a>
Update tz submodule to 2024b</li>
<li><a
href="https://github.com/chronotope/chrono-tz/commit/0acd431a547f87446cd9338eb492ec8d758f59c2"><code>0acd431</code></a>
Make timezone name optional</li>
<li><a
href="https://github.com/chronotope/chrono-tz/commit/2e955104a8a951b5c1f90a47fac34eca386a48aa"><code>2e95510</code></a>
Test numeric time zone names</li>
<li><a
href="https://github.com/chronotope/chrono-tz/commit/2a675e2f845de476b5cb15fd3b6daf2e9c5c8106"><code>2a675e2</code></a>
chrono-tz-build: resolve fixme</li>
<li><a
href="https://github.com/chronotope/chrono-tz/commit/ca52db80b5d54d70a75f591066b220ee63ceb7a2"><code>ca52db8</code></a>
chrono-tz-build: make phf gated by case-insensitive feature</li>
<li><a
href="https://github.com/chronotope/chrono-tz/commit/e2f421513991659484c694266098851c584f5da9"><code>e2f4215</code></a>
Prepare parse-zoneinfo v0.3.1</li>
<li><a
href="https://github.com/chronotope/chrono-tz/commit/e6f87e20cca4584e87e62dc69ed88c144e39dc26"><code>e6f87e2</code></a>
Symlink LICENSE in parse-zoneinfo</li>
<li><a
href="https://github.com/chronotope/chrono-tz/commit/6e58ce21caabee5bc74b2e513c2764d864ee407e"><code>6e58ce2</code></a>
Remove <code>AsciiExt</code> import</li>
<li>Additional commits viewable in <a
href="https://github.com/chronotope/chrono-tz/compare/v0.8.6...v0.10.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>
2024-10-30 18:14:04 +01:00
|
|
|
chrono-tz = "0.10"
|
2024-03-24 00:46:02 +01:00
|
|
|
crossbeam-channel = "0.5.8"
|
2024-09-06 16:57:45 +02:00
|
|
|
crossterm = "0.28.1"
|
2024-03-24 00:46:02 +01:00
|
|
|
csv = "1.3"
|
2024-03-07 23:40:31 +01:00
|
|
|
ctrlc = "3.4"
|
2024-03-24 00:46:02 +01:00
|
|
|
dialoguer = { default-features = false, version = "0.11" }
|
|
|
|
|
digest = { default-features = false, version = "0.10" }
|
2024-07-16 14:16:26 +02:00
|
|
|
dirs = "5.0"
|
2024-07-19 12:47:07 +02:00
|
|
|
dirs-sys = "0.4"
|
2024-03-24 00:46:02 +01:00
|
|
|
dtparse = "2.0"
|
|
|
|
|
encoding_rs = "0.8"
|
2024-10-30 03:51:21 +01:00
|
|
|
fancy-regex = "0.14"
|
2024-03-24 00:46:02 +01:00
|
|
|
filesize = "0.2"
|
|
|
|
|
filetime = "0.2"
|
|
|
|
|
fuzzy-matcher = "0.3"
|
|
|
|
|
heck = "0.5.0"
|
2024-09-30 18:47:50 +02:00
|
|
|
human-date-parser = "0.2.0"
|
2024-10-09 02:07:21 +02:00
|
|
|
indexmap = "2.6"
|
2024-03-24 00:46:02 +01:00
|
|
|
indicatif = "0.17"
|
2024-06-20 10:10:27 +02:00
|
|
|
interprocess = "2.2.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
is_executable = "1.0"
|
Bump itertools from 0.12.1 to 0.13.0 (#13774)
Bumps [itertools](https://github.com/rust-itertools/itertools) from
0.12.1 to 0.13.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/rust-itertools/itertools/blob/master/CHANGELOG.md">itertools's
changelog</a>.</em></p>
<blockquote>
<h2>0.13.0</h2>
<h3>Breaking</h3>
<ul>
<li>Removed implementation of <code>DoubleEndedIterator</code> for
<code>ConsTuples</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/853">#853</a>)</li>
<li>Made <code>MultiProduct</code> fused and fixed on an empty iterator
(<a
href="https://redirect.github.com/rust-itertools/itertools/issues/835">#835</a>,
<a
href="https://redirect.github.com/rust-itertools/itertools/issues/834">#834</a>)</li>
<li>Changed <code>iproduct!</code> to return tuples for maxi one
iterator too (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/870">#870</a>)</li>
<li>Changed <code>PutBack::put_back</code> to return the old value (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/880">#880</a>)</li>
<li>Removed deprecated <code>repeat_call, Itertools::{foreach, step,
map_results, fold_results}</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/878">#878</a>)</li>
<li>Removed <code>TakeWhileInclusive::new</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/912">#912</a>)</li>
</ul>
<h3>Added</h3>
<ul>
<li>Added <code>Itertools::{smallest_by, smallest_by_key, largest,
largest_by, largest_by_key}</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/654">#654</a>,
<a
href="https://redirect.github.com/rust-itertools/itertools/issues/885">#885</a>)</li>
<li>Added <code>Itertools::tail</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/899">#899</a>)</li>
<li>Implemented <code>DoubleEndedIterator</code> for
<code>ProcessResults</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/910">#910</a>)</li>
<li>Implemented <code>Debug</code> for <code>FormatWith</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/931">#931</a>)</li>
<li>Added <code>Itertools::get</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/891">#891</a>)</li>
</ul>
<h3>Changed</h3>
<ul>
<li>Deprecated <code>Itertools::group_by</code> (renamed
<code>chunk_by</code>) (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/866">#866</a>,
<a
href="https://redirect.github.com/rust-itertools/itertools/issues/879">#879</a>)</li>
<li>Deprecated <code>unfold</code> (use <code>std::iter::from_fn</code>
instead) (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/871">#871</a>)</li>
<li>Optimized <code>GroupingMapBy</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/873">#873</a>,
<a
href="https://redirect.github.com/rust-itertools/itertools/issues/876">#876</a>)</li>
<li>Relaxed <code>Fn</code> bounds to <code>FnMut</code> in
<code>diff_with, Itertools::into_group_map_by</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/886">#886</a>)</li>
<li>Relaxed <code>Debug/Clone</code> bounds for <code>MapInto</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/889">#889</a>)</li>
<li>Documented the <code>use_alloc</code> feature (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/887">#887</a>)</li>
<li>Optimized <code>Itertools::set_from</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/888">#888</a>)</li>
<li>Removed badges in <code>README.md</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/890">#890</a>)</li>
<li>Added "no-std" categories in <code>Cargo.toml</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/894">#894</a>)</li>
<li>Fixed <code>Itertools::k_smallest</code> on short unfused iterators
(<a
href="https://redirect.github.com/rust-itertools/itertools/issues/900">#900</a>)</li>
<li>Deprecated <code>Itertools::tree_fold1</code> (renamed
<code>tree_reduce</code>) (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/895">#895</a>)</li>
<li>Deprecated <code>GroupingMap::fold_first</code> (renamed
<code>reduce</code>) (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/902">#902</a>)</li>
<li>Fixed <code>Itertools::k_smallest(0)</code> to consume the iterator,
optimized <code>Itertools::k_smallest(1)</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/909">#909</a>)</li>
<li>Specialized <code>Combinations::nth</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/914">#914</a>)</li>
<li>Specialized <code>MergeBy::fold</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/920">#920</a>)</li>
<li>Specialized <code>CombinationsWithReplacement::nth</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/923">#923</a>)</li>
<li>Specialized <code>FlattenOk::{fold, rfold}</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/927">#927</a>)</li>
<li>Specialized <code>Powerset::nth</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/924">#924</a>)</li>
<li>Documentation fixes (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/882">#882</a>,
<a
href="https://redirect.github.com/rust-itertools/itertools/issues/936">#936</a>)</li>
<li>Fixed <code>assert_equal</code> for iterators longer than
<code>i32::MAX</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/932">#932</a>)</li>
<li>Updated the <code>must_use</code> message of non-lazy
<code>KMergeBy</code> and <code>TupleCombinations</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/939">#939</a>)</li>
</ul>
<h3>Notable Internal Changes</h3>
<ul>
<li>Tested iterator laziness (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/792">#792</a>)</li>
<li>Created <code>CONTRIBUTING.md</code> (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/767">#767</a>)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/rust-itertools/itertools/commit/d5084d15e959b85d89a49e5cd33ad6267bc541a3"><code>d5084d1</code></a>
Prepare v0.13.0 release (<a
href="https://redirect.github.com/rust-itertools/itertools/issues/937">#937</a>)</li>
<li><a
href="https://github.com/rust-itertools/itertools/commit/d7c99d55daeaa76f482444e95beb99f5744ced4e"><code>d7c99d5</code></a>
<code>TupleCombinations</code> is not lazy but must be used
nonetheless</li>
<li><a
href="https://github.com/rust-itertools/itertools/commit/074c7fcc07c2bfd60f238585c05134ea3eb43f77"><code>074c7fc</code></a>
<code>KMergeBy</code> is not lazy but must be used nonetheless</li>
<li><a
href="https://github.com/rust-itertools/itertools/commit/2ad9e07ae860bb891e48b35edfea5b3286dcb4ab"><code>2ad9e07</code></a>
<code>assert_equal</code>: fix
<code>clippy::default_numeric_fallback</code></li>
<li><a
href="https://github.com/rust-itertools/itertools/commit/0d4efc84323399b47b09ae9da1ff3fdfc2cf95e1"><code>0d4efc8</code></a>
Remove free function <code>get</code></li>
<li><a
href="https://github.com/rust-itertools/itertools/commit/05cc0ee256e84d665e34209053ebc62ef7e4463d"><code>05cc0ee</code></a>
<code>get(s..=usize::MAX)</code> should be fine when <code>s !=
0</code></li>
<li><a
href="https://github.com/rust-itertools/itertools/commit/3c16f14baa5515376adcd8c530f6d3d275b14f44"><code>3c16f14</code></a>
<code>get</code>: when is it ESI and/or DEI</li>
<li><a
href="https://github.com/rust-itertools/itertools/commit/4dd6ba0e7c44bb287dff1098d8fb6ab77c32bf87"><code>4dd6ba0</code></a>
<code>get</code>: panics if the range includes
<code>usize::MAX</code></li>
<li><a
href="https://github.com/rust-itertools/itertools/commit/7a9ce56fc59489668178d696db76afb3580a359c"><code>7a9ce56</code></a>
<code>get(r: Range)</code> as <code>Skip\<Take></code></li>
<li><a
href="https://github.com/rust-itertools/itertools/commit/f676f2f96451220c827c62f714d79ce6454d0184"><code>f676f2f</code></a>
Remove the unspecified check about
<code>.get(exhausted_range_inclusive)</code></li>
<li>Additional commits viewable in <a
href="https://github.com/rust-itertools/itertools/compare/v0.12.1...v0.13.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>
2024-09-04 04:02:48 +02:00
|
|
|
itertools = "0.13"
|
2024-03-24 00:46:02 +01:00
|
|
|
libc = "0.2"
|
|
|
|
|
libproc = "0.14"
|
2024-03-07 23:40:31 +01:00
|
|
|
log = "0.4"
|
2024-03-24 00:46:02 +01:00
|
|
|
lru = "0.12"
|
|
|
|
|
lscolors = { version = "0.17", default-features = false }
|
|
|
|
|
lsp-server = "0.7.5"
|
Fix LSP non-ascii characters offset issues. (#14002)
<!--
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!
-->
This PR is supposed to fix #13582, #11522, as well as related goto
definition/reference issues (wrong position if non ascii characters
ahead).
# 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.
-->
<img width="411" alt="image"
src="https://github.com/user-attachments/assets/9a81953c-81b2-490d-a842-14ccaefd6972">
Changes:
1. span/completion should use byte offset instead of character index
2. lsp Postions related ops in Ropey remain to use character index
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Should be none, tested in neovim with config:
```lua
require("lspconfig").nushell.setup({
cmd = {
"nu",
"-I",
vim.fn.getcwd(),
"--no-config-file",
"--lsp",
},
filetypes = { "nu" },
})
```
# 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
> ```
-->
tests::complete_command_with_utf_line parameters fixed to align with
true lsp requests (in character index, not byte).
As for the issue_11522.nu, manually tested:
<img width="520" alt="image"
src="https://github.com/user-attachments/assets/45496ba8-5a2d-4998-9190-d7bde31ee72c">
# 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.
-->
2024-10-29 12:35:37 +01:00
|
|
|
lsp-types = { version = "0.95.0", features = ["proposed"] }
|
2024-03-24 00:46:02 +01:00
|
|
|
mach2 = "0.4"
|
2024-04-12 22:56:40 +02:00
|
|
|
md5 = { version = "0.10", package = "md-5" }
|
2024-11-27 22:43:36 +01:00
|
|
|
miette = "7.3"
|
2024-08-13 21:27:28 +02:00
|
|
|
mime = "0.3.17"
|
2024-03-24 00:46:02 +01:00
|
|
|
mime_guess = "2.0"
|
2024-11-14 10:20:17 +01:00
|
|
|
mockito = { version = "1.6", default-features = false }
|
2024-12-04 02:38:27 +01:00
|
|
|
multipart-rs = "0.1.13"
|
2024-03-24 00:46:02 +01:00
|
|
|
native-tls = "0.2"
|
2024-09-04 04:03:02 +02:00
|
|
|
nix = { version = "0.29", default-features = false }
|
2024-03-24 00:46:02 +01:00
|
|
|
notify-debouncer-full = { version = "0.3", default-features = false }
|
2024-07-24 00:54:54 +02:00
|
|
|
nu-ansi-term = "0.50.1"
|
2024-03-24 00:46:02 +01:00
|
|
|
num-format = "0.4"
|
|
|
|
|
num-traits = "0.2"
|
2024-10-29 12:32:35 +01:00
|
|
|
oem_cp = "2.0.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
omnipath = "0.1"
|
2024-07-17 03:47:17 +02:00
|
|
|
open = "5.3"
|
2024-06-07 02:08:02 +02:00
|
|
|
os_pipe = { version = "1.2", features = ["io_safety"] }
|
2024-03-07 23:40:31 +01:00
|
|
|
pathdiff = "0.2"
|
|
|
|
|
percent-encoding = "2"
|
2024-04-26 13:23:16 +02:00
|
|
|
pretty_assertions = "1.4"
|
2024-03-24 00:46:02 +01:00
|
|
|
print-positions = "0.6"
|
Add derive macros for `FromValue` and `IntoValue` to ease the use of `Value`s in Rust code (#13031)
# Description
After discussing with @sholderbach the cumbersome usage of
`nu_protocol::Value` in Rust, I created a derive macro to simplify it.
I’ve added a new crate called `nu-derive-value`, which includes two
macros, `IntoValue` and `FromValue`. These are re-exported in
`nu-protocol` and should be encouraged to be used via that re-export.
The macros ensure that all types can easily convert from and into
`Value`. For example, as a plugin author, you can define your plugin
configuration using a Rust struct and easily convert it using
`FromValue`. This makes plugin configuration less of a hassle.
I introduced the `IntoValue` trait for a standardized approach to
converting values into `Value` (and a fallible variant `TryIntoValue`).
This trait could potentially replace existing `into_value` methods.
Along with this, I've implemented `FromValue` for several standard types
and refined other implementations to use blanket implementations where
applicable.
I made these design choices with input from @devyn.
There are more improvements possible, but this is a solid start and the
PR is already quite substantial.
# User-Facing Changes
For `nu-protocol` users, these changes simplify the handling of
`Value`s. There are no changes for end-users of nushell itself.
# Tests + Formatting
Documenting the macros itself is not really possible, as they cannot
really reference any other types since they are the root of the
dependency graph. The standard library has the same problem
([std::Debug](https://doc.rust-lang.org/stable/std/fmt/derive.Debug.html)).
However I documented the `FromValue` and `IntoValue` traits completely.
For testing, I made of use `proc-macro2` in the derive macro code. This
would allow testing the generated source code. Instead I just tested
that the derived functionality is correct. This is done in
`nu_protocol::value::test_derive`, as a consumer of `nu-derive-value`
needs to do the testing of the macro usage. I think that these tests
should provide a stable baseline so that users can be sure that the impl
works.
# After Submitting
With these macros available, we can probably use them in some examples
for plugins to showcase the use of them.
2024-06-18 01:05:11 +02:00
|
|
|
proc-macro-error = { version = "1.0", default-features = false }
|
|
|
|
|
proc-macro2 = "1.0"
|
2024-12-02 21:20:19 +01:00
|
|
|
procfs = "0.17.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
pwd = "1.3"
|
2024-11-19 01:26:31 +01:00
|
|
|
quick-xml = "0.37.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
quickcheck = "1.0"
|
|
|
|
|
quickcheck_macros = "1.0"
|
Add derive macros for `FromValue` and `IntoValue` to ease the use of `Value`s in Rust code (#13031)
# Description
After discussing with @sholderbach the cumbersome usage of
`nu_protocol::Value` in Rust, I created a derive macro to simplify it.
I’ve added a new crate called `nu-derive-value`, which includes two
macros, `IntoValue` and `FromValue`. These are re-exported in
`nu-protocol` and should be encouraged to be used via that re-export.
The macros ensure that all types can easily convert from and into
`Value`. For example, as a plugin author, you can define your plugin
configuration using a Rust struct and easily convert it using
`FromValue`. This makes plugin configuration less of a hassle.
I introduced the `IntoValue` trait for a standardized approach to
converting values into `Value` (and a fallible variant `TryIntoValue`).
This trait could potentially replace existing `into_value` methods.
Along with this, I've implemented `FromValue` for several standard types
and refined other implementations to use blanket implementations where
applicable.
I made these design choices with input from @devyn.
There are more improvements possible, but this is a solid start and the
PR is already quite substantial.
# User-Facing Changes
For `nu-protocol` users, these changes simplify the handling of
`Value`s. There are no changes for end-users of nushell itself.
# Tests + Formatting
Documenting the macros itself is not really possible, as they cannot
really reference any other types since they are the root of the
dependency graph. The standard library has the same problem
([std::Debug](https://doc.rust-lang.org/stable/std/fmt/derive.Debug.html)).
However I documented the `FromValue` and `IntoValue` traits completely.
For testing, I made of use `proc-macro2` in the derive macro code. This
would allow testing the generated source code. Instead I just tested
that the derived functionality is correct. This is done in
`nu_protocol::value::test_derive`, as a consumer of `nu-derive-value`
needs to do the testing of the macro usage. I think that these tests
should provide a stable baseline so that users can be sure that the impl
works.
# After Submitting
With these macros available, we can probably use them in some examples
for plugins to showcase the use of them.
2024-06-18 01:05:11 +02:00
|
|
|
quote = "1.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
rand = "0.8"
|
Start to Add WASM Support Again (#14418)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx
you can also mention related issues, PRs or discussions!
-->
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.
Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
The [nushell/demo](https://github.com/nushell/demo) project successfully
demonstrated running Nushell in the browser using WASM. However, the
current version of Nushell cannot be easily built for the
`wasm32-unknown-unknown` target, the default for `wasm-bindgen`.
This PR introduces initial support for the `wasm32-unknown-unknown`
target by disabling OS-dependent features such as filesystem access, IO,
and platform/system-specific functionality. This separation is achieved
using a new `os` feature in the following crates:
- `nu-cmd-lang`
- `nu-command`
- `nu-engine`
- `nu-protocol`
The `os` feature includes all functionality that interacts with an
operating system. It is enabled by default, but can be disabled using
`--no-default-features`. All crates that depend on these core crates now
use `--no-default-features` to allow compilation for WASM.
To demonstrate compatibility, the following script builds all crates
expected to work with WASM. Direct user interaction, running external
commands, working with plugins, and features requiring `openssl` are out
of scope for now due to their complexity or reliance on C libraries,
which are difficult to compile and link in a WASM environment.
```nushell
[ # compatible crates
"nu-cmd-base",
"nu-cmd-extra",
"nu-cmd-lang",
"nu-color-config",
"nu-command",
"nu-derive-value",
"nu-engine",
"nu-glob",
"nu-json",
"nu-parser",
"nu-path",
"nu-pretty-hex",
"nu-protocol",
"nu-std",
"nu-system",
"nu-table",
"nu-term-grid",
"nu-utils",
"nuon"
] | each {cargo build -p $in --target wasm32-unknown-unknown --no-default-features}
```
## Caveats
This PR has a few caveats:
1. **`miette` and `terminal-size` Dependency Issue**
`miette` depends on `terminal-size`, which uses `rustix` when the target
is not Windows. However, `rustix` requires `std::os::unix`, which is
unavailable in WASM. To address this, I opened a
[PR](https://github.com/eminence/terminal-size/pull/68) for
`terminal-size` to conditionally compile `rustix` only when the target
is Unix. For now, the `Cargo.toml` includes patches to:
- Use my forked version of `terminal-size`.
- ~~Use an unreleased version of `miette` that depends on
`terminal-size@0.4`.~~
These patches are temporary and can be removed once the upstream changes
are merged and released.
2. **Test Output Adjustments**
Due to the slight bump in the `miette` version, one test required
adjustments to accommodate minor formatting changes in the error output,
such as shifted newlines.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
This shouldn't break anything but allows using some crates for targeting
`wasm32-unknown-unknown` to revive the demo page eventually.
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
- :green_circle: `toolkit fmt`
- :green_circle: `toolkit clippy`
- :green_circle: `toolkit test`
- :green_circle: `toolkit test stdlib`
I did not add any extra tests, I just checked that compiling works, also
when using the host target but unselecting the `os` feature.
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
~~Breaking the wasm support can be easily done by adding some `use`s or
by adding a new dependency, we should definitely add some CI that also
at least builds against wasm to make sure that building for it keep
working.~~
I added a job to build wasm.
---------
Co-authored-by: Ian Manske <ian.manske@pm.me>
2024-11-30 14:57:11 +01:00
|
|
|
getrandom = "0.2" # pick same version that rand requires
|
2024-08-23 18:18:51 +02:00
|
|
|
rand_chacha = "0.3.1"
|
2024-03-24 00:46:02 +01:00
|
|
|
ratatui = "0.26"
|
2024-03-27 07:44:17 +01:00
|
|
|
rayon = "1.10"
|
2024-11-12 20:34:46 +01:00
|
|
|
reedline = "0.37.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
regex = "1.9.5"
|
2024-04-26 13:23:16 +02:00
|
|
|
rmp = "0.8"
|
2024-05-02 02:26:00 +02:00
|
|
|
rmp-serde = "1.3"
|
2024-03-24 00:46:02 +01:00
|
|
|
ropey = "1.6.1"
|
|
|
|
|
roxmltree = "0.19"
|
2024-11-15 19:18:01 +01:00
|
|
|
rstest = { version = "0.23", default-features = false }
|
2024-03-24 00:46:02 +01:00
|
|
|
rusqlite = "0.31"
|
2024-07-17 03:47:09 +02:00
|
|
|
rust-embed = "8.5.0"
|
2024-12-02 03:02:48 +01:00
|
|
|
scopeguard = { version = "1.2.0" }
|
2024-09-06 00:57:36 +02:00
|
|
|
serde = { version = "1.0" }
|
2024-03-07 23:40:31 +01:00
|
|
|
serde_json = "1.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
serde_urlencoded = "0.7.1"
|
|
|
|
|
serde_yaml = "0.9"
|
|
|
|
|
sha2 = "0.10"
|
|
|
|
|
strip-ansi-escapes = "0.2.0"
|
Add derive macros for `FromValue` and `IntoValue` to ease the use of `Value`s in Rust code (#13031)
# Description
After discussing with @sholderbach the cumbersome usage of
`nu_protocol::Value` in Rust, I created a derive macro to simplify it.
I’ve added a new crate called `nu-derive-value`, which includes two
macros, `IntoValue` and `FromValue`. These are re-exported in
`nu-protocol` and should be encouraged to be used via that re-export.
The macros ensure that all types can easily convert from and into
`Value`. For example, as a plugin author, you can define your plugin
configuration using a Rust struct and easily convert it using
`FromValue`. This makes plugin configuration less of a hassle.
I introduced the `IntoValue` trait for a standardized approach to
converting values into `Value` (and a fallible variant `TryIntoValue`).
This trait could potentially replace existing `into_value` methods.
Along with this, I've implemented `FromValue` for several standard types
and refined other implementations to use blanket implementations where
applicable.
I made these design choices with input from @devyn.
There are more improvements possible, but this is a solid start and the
PR is already quite substantial.
# User-Facing Changes
For `nu-protocol` users, these changes simplify the handling of
`Value`s. There are no changes for end-users of nushell itself.
# Tests + Formatting
Documenting the macros itself is not really possible, as they cannot
really reference any other types since they are the root of the
dependency graph. The standard library has the same problem
([std::Debug](https://doc.rust-lang.org/stable/std/fmt/derive.Debug.html)).
However I documented the `FromValue` and `IntoValue` traits completely.
For testing, I made of use `proc-macro2` in the derive macro code. This
would allow testing the generated source code. Instead I just tested
that the derived functionality is correct. This is done in
`nu_protocol::value::test_derive`, as a consumer of `nu-derive-value`
needs to do the testing of the macro usage. I think that these tests
should provide a stable baseline so that users can be sure that the impl
works.
# After Submitting
With these macros available, we can probably use them in some examples
for plugins to showcase the use of them.
2024-06-18 01:05:11 +02:00
|
|
|
syn = "2.0"
|
2024-10-17 19:12:45 +02:00
|
|
|
sysinfo = "0.32"
|
2024-08-24 00:35:42 +02:00
|
|
|
tabled = { version = "0.16.0", default-features = false }
|
2024-11-14 10:32:55 +01:00
|
|
|
tempfile = "3.14"
|
2024-11-20 02:20:47 +01:00
|
|
|
terminal_size = "0.4"
|
2024-12-04 02:40:23 +01:00
|
|
|
titlecase = "3.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
toml = "0.8"
|
2024-10-30 03:51:30 +01:00
|
|
|
trash = "5.2"
|
2024-03-24 00:46:02 +01:00
|
|
|
umask = "2.1"
|
2024-09-22 09:16:11 +02:00
|
|
|
unicode-segmentation = "1.12"
|
2024-11-29 02:09:45 +01:00
|
|
|
unicode-width = "0.2"
|
2024-12-04 02:37:52 +01:00
|
|
|
ureq = { version = "2.12", default-features = false }
|
2024-03-24 00:46:02 +01:00
|
|
|
url = "2.2"
|
2024-11-18 02:31:36 +01:00
|
|
|
uu_cp = "0.0.28"
|
|
|
|
|
uu_mkdir = "0.0.28"
|
|
|
|
|
uu_mktemp = "0.0.28"
|
|
|
|
|
uu_mv = "0.0.28"
|
2024-11-18 01:03:21 +01:00
|
|
|
uu_touch = "0.0.28"
|
2024-11-18 02:31:36 +01:00
|
|
|
uu_whoami = "0.0.28"
|
|
|
|
|
uu_uname = "0.0.28"
|
|
|
|
|
uucore = "0.0.28"
|
2024-10-23 07:54:16 +02:00
|
|
|
uuid = "1.11.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
v_htmlescape = "0.15.0"
|
|
|
|
|
wax = "0.6"
|
2024-12-02 21:20:19 +01:00
|
|
|
which = "7.0.0"
|
2024-10-17 19:12:45 +02:00
|
|
|
windows = "0.56"
|
2024-07-19 12:47:07 +02:00
|
|
|
windows-sys = "0.48"
|
2024-03-24 00:46:02 +01:00
|
|
|
winreg = "0.52"
|
2024-03-07 23:40:31 +01:00
|
|
|
|
2024-08-28 23:37:17 +02:00
|
|
|
[workspace.lints.clippy]
|
|
|
|
|
# Warning: workspace lints affect library code as well as tests, so don't enable lints that would be too noisy in tests like that.
|
|
|
|
|
# todo = "warn"
|
|
|
|
|
unchecked_duration_subtraction = "warn"
|
|
|
|
|
|
|
|
|
|
[lints]
|
|
|
|
|
workspace = true
|
|
|
|
|
|
2021-06-30 03:42:56 +02:00
|
|
|
[dependencies]
|
2024-11-14 10:04:39 +01:00
|
|
|
nu-cli = { path = "./crates/nu-cli", version = "0.100.1" }
|
|
|
|
|
nu-cmd-base = { path = "./crates/nu-cmd-base", version = "0.100.1" }
|
|
|
|
|
nu-cmd-lang = { path = "./crates/nu-cmd-lang", version = "0.100.1" }
|
|
|
|
|
nu-cmd-plugin = { path = "./crates/nu-cmd-plugin", version = "0.100.1", optional = true }
|
|
|
|
|
nu-cmd-extra = { path = "./crates/nu-cmd-extra", version = "0.100.1" }
|
|
|
|
|
nu-command = { path = "./crates/nu-command", version = "0.100.1" }
|
|
|
|
|
nu-engine = { path = "./crates/nu-engine", version = "0.100.1" }
|
|
|
|
|
nu-explore = { path = "./crates/nu-explore", version = "0.100.1" }
|
|
|
|
|
nu-lsp = { path = "./crates/nu-lsp/", version = "0.100.1" }
|
|
|
|
|
nu-parser = { path = "./crates/nu-parser", version = "0.100.1" }
|
|
|
|
|
nu-path = { path = "./crates/nu-path", version = "0.100.1" }
|
|
|
|
|
nu-plugin-engine = { path = "./crates/nu-plugin-engine", optional = true, version = "0.100.1" }
|
|
|
|
|
nu-protocol = { path = "./crates/nu-protocol", version = "0.100.1" }
|
|
|
|
|
nu-std = { path = "./crates/nu-std", version = "0.100.1" }
|
|
|
|
|
nu-system = { path = "./crates/nu-system", version = "0.100.1" }
|
|
|
|
|
nu-utils = { path = "./crates/nu-utils", version = "0.100.1" }
|
2024-03-07 23:40:31 +01:00
|
|
|
reedline = { workspace = true, features = ["bashisms", "sqlite"] }
|
2022-09-19 16:28:36 +02:00
|
|
|
|
2024-03-07 23:40:31 +01:00
|
|
|
crossterm = { workspace = true }
|
|
|
|
|
ctrlc = { workspace = true }
|
2024-07-16 14:16:26 +02:00
|
|
|
dirs = { workspace = true }
|
2024-03-07 23:40:31 +01:00
|
|
|
log = { workspace = true }
|
|
|
|
|
miette = { workspace = true, features = ["fancy-no-backtrace", "fancy"] }
|
2024-05-21 07:47:24 +02:00
|
|
|
mimalloc = { version = "0.1.42", default-features = false, optional = true }
|
2024-08-06 22:28:38 +02:00
|
|
|
multipart-rs = { workspace = true }
|
2024-03-07 23:40:31 +01:00
|
|
|
serde_json = { workspace = true }
|
2023-05-26 17:32:48 +02:00
|
|
|
simplelog = "0.12"
|
|
|
|
|
time = "0.3"
|
2022-02-22 16:55:28 +01:00
|
|
|
|
2022-05-26 20:28:59 +02:00
|
|
|
[target.'cfg(not(target_os = "windows"))'.dependencies]
|
|
|
|
|
# Our dependencies don't use OpenSSL on Windows
|
2023-05-26 17:32:48 +02:00
|
|
|
openssl = { version = "0.10", features = ["vendored"], optional = true }
|
2022-05-26 20:28:59 +02:00
|
|
|
|
2022-10-16 23:51:15 +02:00
|
|
|
[target.'cfg(windows)'.build-dependencies]
|
2023-04-26 14:14:55 +02:00
|
|
|
winresource = "0.1"
|
2022-10-16 23:51:15 +02:00
|
|
|
|
|
|
|
|
[target.'cfg(target_family = "unix")'.dependencies]
|
2024-03-07 23:40:31 +01:00
|
|
|
nix = { workspace = true, default-features = false, features = [
|
|
|
|
|
"signal",
|
|
|
|
|
"process",
|
|
|
|
|
"fs",
|
|
|
|
|
"term",
|
`string | fill` counts clusters, not graphemes; and doesn't count ANSI escape codes (#8134)
Enhancement of new `fill` command (#7846) to handle content including
ANSI escape codes for formatting or multi-code-point Unicode grapheme
clusters.
In both of these cases, the content is (many) bytes longer than its
visible length, and `fill` was counting the extra bytes so not adding
enough fill characters.
# Description
This script:
```rust
# the teacher emoji `\u{1F9D1}\u{200D}\u{1F3EB}` is 3 code points, but only 1 print position wide.
echo "This output should be 3 print positions wide, with leading and trailing `+`"
$"\u{1F9D1}\u{200D}\u{1F3EB}" | fill -c "+" -w 3 -a "c"
echo "This output should be 3 print positions wide, with leading and trailing `+`"
$"(ansi green)a(ansi reset)" | fill -c "+" -w 3 -a c
echo ""
```
Was producing this output:
```rust
This output should be 3 print positions wide, with leading and trailing `+`
🧑🏫
This output should be 3 print positions wide, with leading and trailing `+`
a
```
After this PR, it produces this output:
```rust
This output should be 3 print positions wide, with leading and trailing `+`
+🧑🏫+
This output should be 3 print positions wide, with leading and trailing `+`
+a+
```
# User-Facing Changes
Users may have to undo fixes they may have introduced to work around the
former behavior. I have one such in my prompt string that I can now
revert.
# Tests + Formatting
Don't forget to add tests that cover your changes.
-- Done
Make sure you've run and fixed any issues with these commands:
- [x] `cargo fmt --all -- --check` to check standard code formatting
(`cargo fmt --all` applies these changes)
- [x] `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect` to check that you're using the standard code
style
- [x] `cargo test --workspace` to check that all tests pass
# After Submitting
`fill` command not documented in the book, and it still talks about `str
lpad/rpad`. I'll fix.
Note added dependency on a new library `print-positions`, which is an
iterator that yields a complete print position (cluster + Ansi sequence)
per call. Should this be vendored?
2023-02-20 13:32:20 +01:00
|
|
|
] }
|
2022-10-16 23:51:15 +02:00
|
|
|
|
2021-07-30 22:02:16 +02:00
|
|
|
[dev-dependencies]
|
2024-11-14 10:04:39 +01:00
|
|
|
nu-test-support = { path = "./crates/nu-test-support", version = "0.100.1" }
|
|
|
|
|
nu-plugin-protocol = { path = "./crates/nu-plugin-protocol", version = "0.100.1" }
|
|
|
|
|
nu-plugin-core = { path = "./crates/nu-plugin-core", version = "0.100.1" }
|
2023-05-26 17:32:48 +02:00
|
|
|
assert_cmd = "2.0"
|
2024-07-16 14:16:26 +02:00
|
|
|
dirs = { workspace = true }
|
2024-09-22 09:15:58 +02:00
|
|
|
tango-bench = "0.6"
|
2024-04-26 13:23:16 +02:00
|
|
|
pretty_assertions = { workspace = true }
|
Internal representation (IR) compiler and evaluator (#13330)
# Description
This PR adds an internal representation language to Nushell, offering an
alternative evaluator based on simple instructions, stream-containing
registers, and indexed control flow. The number of registers required is
determined statically at compile-time, and the fixed size required is
allocated upon entering the block.
Each instruction is associated with a span, which makes going backwards
from IR instructions to source code very easy.
Motivations for IR:
1. **Performance.** By simplifying the evaluation path and making it
more cache-friendly and branch predictor-friendly, code that does a lot
of computation in Nushell itself can be sped up a decent bit. Because
the IR is fairly easy to reason about, we can also implement
optimization passes in the future to eliminate and simplify code.
2. **Correctness.** The instructions mostly have very simple and
easily-specified behavior, so hopefully engine changes are a little bit
easier to reason about, and they can be specified in a more formal way
at some point. I have made an effort to document each of the
instructions in the docs for the enum itself in a reasonably specific
way. Some of the errors that would have happened during evaluation
before are now moved to the compilation step instead, because they don't
make sense to check during evaluation.
3. **As an intermediate target.** This is a good step for us to bring
the [`new-nu-parser`](https://github.com/nushell/new-nu-parser) in at
some point, as code generated from new AST can be directly compared to
code generated from old AST. If the IR code is functionally equivalent,
it will behave the exact same way.
4. **Debugging.** With a little bit more work, we can probably give
control over advancing the virtual machine that `IrBlock`s run on to
some sort of external driver, making things like breakpoints and single
stepping possible. Tools like `view ir` and [`explore
ir`](https://github.com/devyn/nu_plugin_explore_ir) make it easier than
before to see what exactly is going on with your Nushell code.
The goal is to eventually replace the AST evaluator entirely, once we're
sure it's working just as well. You can help dogfood this by running
Nushell with `$env.NU_USE_IR` set to some value. The environment
variable is checked when Nushell starts, so config runs with IR, or it
can also be set on a line at the REPL to change it dynamically. It is
also checked when running `do` in case within a script you want to just
run a specific piece of code with or without IR.
# Example
```nushell
view ir { |data|
mut sum = 0
for n in $data {
$sum += $n
}
$sum
}
```
```gas
# 3 registers, 19 instructions, 0 bytes of data
0: load-literal %0, int(0)
1: store-variable var 904, %0 # let
2: drain %0
3: drop %0
4: load-variable %1, var 903
5: iterate %0, %1, end 15 # for, label(1), from(14:)
6: store-variable var 905, %0
7: load-variable %0, var 904
8: load-variable %2, var 905
9: binary-op %0, Math(Plus), %2
10: span %0
11: store-variable var 904, %0
12: load-literal %0, nothing
13: drain %0
14: jump 5
15: drop %0 # label(0), from(5:)
16: drain %0
17: load-variable %0, var 904
18: return %0
```
# Benchmarks
All benchmarks run on a base model Mac Mini M1.
## Iterative Fibonacci sequence
This is about as best case as possible, making use of the much faster
control flow. Most code will not experience a speed improvement nearly
this large.
```nushell
def fib [n: int] {
mut a = 0
mut b = 1
for _ in 2..=$n {
let c = $a + $b
$a = $b
$b = $c
}
$b
}
use std bench
bench { 0..50 | each { |n| fib $n } }
```
IR disabled:
```
╭───────┬─────────────────╮
│ mean │ 1ms 924µs 665ns │
│ min │ 1ms 700µs 83ns │
│ max │ 3ms 450µs 125ns │
│ std │ 395µs 759ns │
│ times │ [list 50 items] │
╰───────┴─────────────────╯
```
IR enabled:
```
╭───────┬─────────────────╮
│ mean │ 452µs 820ns │
│ min │ 427µs 417ns │
│ max │ 540µs 167ns │
│ std │ 17µs 158ns │
│ times │ [list 50 items] │
╰───────┴─────────────────╯
```
##
[gradient_benchmark_no_check.nu](https://github.com/nushell/nu_scripts/blob/main/benchmarks/gradient_benchmark_no_check.nu)
IR disabled:
```
╭───┬──────────────────╮
│ 0 │ 27ms 929µs 958ns │
│ 1 │ 21ms 153µs 459ns │
│ 2 │ 18ms 639µs 666ns │
│ 3 │ 19ms 554µs 583ns │
│ 4 │ 13ms 383µs 375ns │
│ 5 │ 11ms 328µs 208ns │
│ 6 │ 5ms 659µs 542ns │
╰───┴──────────────────╯
```
IR enabled:
```
╭───┬──────────────────╮
│ 0 │ 22ms 662µs │
│ 1 │ 17ms 221µs 792ns │
│ 2 │ 14ms 786µs 708ns │
│ 3 │ 13ms 876µs 834ns │
│ 4 │ 13ms 52µs 875ns │
│ 5 │ 11ms 269µs 666ns │
│ 6 │ 6ms 942µs 500ns │
╰───┴──────────────────╯
```
##
[random-bytes.nu](https://github.com/nushell/nu_scripts/blob/main/benchmarks/random-bytes.nu)
I got pretty random results out of this benchmark so I decided not to
include it. Not clear why.
# User-Facing Changes
- IR compilation errors may appear even if the user isn't evaluating
with IR.
- IR evaluation can be enabled by setting the `NU_USE_IR` environment
variable to any value.
- New command `view ir` pretty-prints the IR for a block, and `view ir
--json` can be piped into an external tool like [`explore
ir`](https://github.com/devyn/nu_plugin_explore_ir).
# Tests + Formatting
All tests are passing with `NU_USE_IR=1`, and I've added some more eval
tests to compare the results for some very core operations. I will
probably want to add some more so we don't have to always check
`NU_USE_IR=1 toolkit test --workspace` on a regular basis.
# After Submitting
- [ ] release notes
- [ ] further documentation of instructions?
- [ ] post-release: publish `nu_plugin_explore_ir`
2024-07-11 02:33:59 +02:00
|
|
|
regex = { workspace = true }
|
2024-03-07 23:40:31 +01:00
|
|
|
rstest = { workspace = true, default-features = false }
|
2024-11-14 10:09:48 +01:00
|
|
|
serial_test = "3.2"
|
2024-03-07 23:40:31 +01:00
|
|
|
tempfile = { workspace = true }
|
2021-12-07 21:06:34 +01:00
|
|
|
|
|
|
|
|
[features]
|
2023-01-23 19:57:40 +01:00
|
|
|
plugin = [
|
2024-12-02 16:02:06 +01:00
|
|
|
# crates
|
2024-04-21 14:36:26 +02:00
|
|
|
"nu-cmd-plugin",
|
2024-12-02 16:02:06 +01:00
|
|
|
"nu-plugin-engine",
|
|
|
|
|
|
|
|
|
|
# features
|
2024-03-07 23:40:31 +01:00
|
|
|
"nu-cli/plugin",
|
2024-12-02 16:02:06 +01:00
|
|
|
"nu-cmd-lang/plugin",
|
2024-03-07 23:40:31 +01:00
|
|
|
"nu-command/plugin",
|
|
|
|
|
"nu-engine/plugin",
|
2024-12-02 16:02:06 +01:00
|
|
|
"nu-engine/plugin",
|
|
|
|
|
"nu-parser/plugin",
|
|
|
|
|
"nu-protocol/plugin",
|
2023-01-23 19:57:40 +01:00
|
|
|
]
|
2024-08-28 22:19:13 +02:00
|
|
|
|
|
|
|
|
default = [
|
2024-03-07 23:40:31 +01:00
|
|
|
"plugin",
|
|
|
|
|
"trash-support",
|
|
|
|
|
"sqlite",
|
|
|
|
|
"mimalloc",
|
2024-01-20 15:04:06 +01:00
|
|
|
]
|
2021-12-07 21:06:34 +01:00
|
|
|
stable = ["default"]
|
2023-06-14 23:12:55 +02:00
|
|
|
# NOTE: individual features are also passed to `nu-cmd-lang` that uses them to generate the feature matrix in the `version` command
|
2022-11-21 18:24:25 +01:00
|
|
|
|
2023-10-11 01:13:28 +02:00
|
|
|
# Enable to statically link OpenSSL (perl is required, to build OpenSSL https://docs.rs/openssl/latest/openssl/);
|
2023-09-09 22:34:07 +02:00
|
|
|
# otherwise the system version will be used. Not enabled by default because it takes a while to build
|
2023-05-22 17:42:38 +02:00
|
|
|
static-link-openssl = ["dep:openssl", "nu-cmd-lang/static-link-openssl"]
|
2021-12-07 21:06:34 +01:00
|
|
|
|
2023-06-15 00:27:12 +02:00
|
|
|
mimalloc = ["nu-cmd-lang/mimalloc", "dep:mimalloc"]
|
2024-08-28 22:19:13 +02:00
|
|
|
# Optional system clipboard support in `reedline`, this behavior has problematic compatibility with some systems.
|
|
|
|
|
# Missing X server/ Wayland can cause issues
|
2024-04-18 16:33:41 +02:00
|
|
|
system-clipboard = [
|
|
|
|
|
"reedline/system_clipboard",
|
|
|
|
|
"nu-cli/system-clipboard",
|
|
|
|
|
"nu-cmd-lang/system-clipboard",
|
|
|
|
|
]
|
2023-06-15 00:27:12 +02:00
|
|
|
|
2021-12-07 21:06:34 +01:00
|
|
|
# Stable (Default)
|
2023-05-22 17:42:38 +02:00
|
|
|
trash-support = ["nu-command/trash-support", "nu-cmd-lang/trash-support"]
|
2022-01-20 19:02:53 +01:00
|
|
|
|
2022-11-23 01:58:11 +01:00
|
|
|
# SQLite commands for nushell
|
2023-05-22 17:42:38 +02:00
|
|
|
sqlite = ["nu-command/sqlite", "nu-cmd-lang/sqlite"]
|
2022-04-24 11:29:21 +02:00
|
|
|
|
2021-12-07 21:06:34 +01:00
|
|
|
[profile.release]
|
2023-01-23 19:57:40 +01:00
|
|
|
opt-level = "s" # Optimize for size
|
2022-02-28 13:13:24 +01:00
|
|
|
strip = "debuginfo"
|
2022-03-10 14:37:24 +01:00
|
|
|
lto = "thin"
|
2022-02-28 13:13:24 +01:00
|
|
|
|
2022-03-16 23:21:06 +01:00
|
|
|
# build with `cargo build --profile profiling`
|
2022-02-28 13:13:24 +01:00
|
|
|
# to analyze performance with tooling like linux perf
|
|
|
|
|
[profile.profiling]
|
|
|
|
|
inherits = "release"
|
|
|
|
|
strip = false
|
|
|
|
|
debug = true
|
2021-12-07 21:06:34 +01:00
|
|
|
|
2022-05-16 06:02:11 +02:00
|
|
|
# build with `cargo build --profile ci`
|
|
|
|
|
# to analyze performance with tooling like linux perf
|
|
|
|
|
[profile.ci]
|
|
|
|
|
inherits = "dev"
|
|
|
|
|
strip = false
|
|
|
|
|
debug = false
|
|
|
|
|
|
2019-12-10 01:05:40 +01:00
|
|
|
# Main nu binary
|
2019-06-27 06:56:48 +02:00
|
|
|
[[bin]]
|
|
|
|
|
name = "nu"
|
|
|
|
|
path = "src/main.rs"
|
2023-02-12 23:22:00 +01:00
|
|
|
bench = false
|
2022-09-29 20:37:48 +02:00
|
|
|
|
2022-10-17 23:45:28 +02:00
|
|
|
# To use a development version of a dependency please use a global override here
|
|
|
|
|
# changing versions in each sub-crate of the workspace is tedious
|
2024-08-05 14:59:34 +02:00
|
|
|
[patch.crates-io]
|
2024-11-27 16:42:30 +01:00
|
|
|
reedline = { git = "https://github.com/nushell/reedline", branch = "main" }
|
2023-03-13 23:38:18 +01:00
|
|
|
# nu-ansi-term = {git = "https://github.com/nushell/nu-ansi-term.git", branch = "main"}
|
2023-01-05 20:39:54 +01:00
|
|
|
|
|
|
|
|
# Run all benchmarks with `cargo bench`
|
|
|
|
|
# Run individual benchmarks like `cargo bench -- <regex>` e.g. `cargo bench -- parse`
|
|
|
|
|
[[bench]]
|
2023-01-11 02:51:25 +01:00
|
|
|
name = "benchmarks"
|
2024-10-17 19:01:08 +02:00
|
|
|
harness = false
|
