2023-02-24 15:54:42 +00:00
|
|
|
use crate::*;
|
Add `command_prelude` module (#12291)
# Description
When implementing a `Command`, one must also import all the types
present in the function signatures for `Command`. This makes it so that
we often import the same set of types in each command implementation
file. E.g., something like this:
```rust
use nu_protocol::ast::Call;
use nu_protocol::engine::{Command, EngineState, Stack};
use nu_protocol::{
record, Category, Example, IntoInterruptiblePipelineData, IntoPipelineData, PipelineData,
ShellError, Signature, Span, Type, Value,
};
```
This PR adds the `nu_engine::command_prelude` module which contains the
necessary and commonly used types to implement a `Command`:
```rust
// command_prelude.rs
pub use crate::CallExt;
pub use nu_protocol::{
ast::{Call, CellPath},
engine::{Command, EngineState, Stack},
record, Category, Example, IntoInterruptiblePipelineData, IntoPipelineData, IntoSpanned,
PipelineData, Record, ShellError, Signature, Span, Spanned, SyntaxShape, Type, Value,
};
```
This should reduce the boilerplate needed to implement a command and
also gives us a place to track the breadth of the `Command` API. I tried
to be conservative with what went into the prelude modules, since it
might be hard/annoying to remove items from the prelude in the future.
Let me know if something should be included or excluded.
2024-03-26 21:17:30 +00:00
|
|
|
use nu_protocol::engine::{EngineState, StateWorkingSet};
|
2023-02-24 15:54:42 +00:00
|
|
|
|
|
|
|
pub fn create_default_context() -> EngineState {
|
|
|
|
let mut engine_state = EngineState::new();
|
|
|
|
|
|
|
|
let delta = {
|
|
|
|
let mut working_set = StateWorkingSet::new(&engine_state);
|
|
|
|
|
|
|
|
macro_rules! bind_command {
|
|
|
|
( $( $command:expr ),* $(,)? ) => {
|
|
|
|
$( working_set.add_decl(Box::new($command)); )*
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
// Core
|
|
|
|
bind_command! {
|
|
|
|
Alias,
|
|
|
|
Break,
|
2023-03-24 09:50:23 +00:00
|
|
|
Collect,
|
2023-02-24 15:54:42 +00:00
|
|
|
Const,
|
|
|
|
Continue,
|
|
|
|
Def,
|
|
|
|
Describe,
|
|
|
|
Do,
|
|
|
|
Echo,
|
|
|
|
ErrorMake,
|
|
|
|
ExportAlias,
|
|
|
|
ExportCommand,
|
Module: support defining const and use const variables inside of function (#9773)
<!--
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.
-->
Relative: #8248
After this pr, user can define const variable inside a module.
![image](https://github.com/nushell/nushell/assets/22256154/e3e03e56-c4b5-4144-a944-d1b20bec1cbd)
And user can export const variables, the following screenshot shows how
it works (it follows
https://github.com/nushell/nushell/issues/8248#issuecomment-1637442612):
![image](https://github.com/nushell/nushell/assets/22256154/b2c14760-3f27-41cc-af77-af70a4367f2a)
## About the change
1. To make module support const, we need to change `parse_module_block`
to support `const` keyword.
2. To suport export `const`, we need to make module tracking variables,
so we add `variables` attribute to `Module`
3. During eval, the const variable may not exists in `stack`, because we
don't eval `const` when we define a module, so we need to find variables
which are already registered in `engine_state`
## One more thing to note about the const value.
Consider the following code
```
module foo { const b = 3; export def bar [] { $b } }
use foo bar
const b = 4;
bar
```
The result will be 3 (which is defined in module) rather than 4. I think
it's expected behavior.
It's something like [dynamic
binding](https://www.gnu.org/software/emacs/manual/html_node/elisp/Dynamic-Binding-Tips.html)
vs [lexical
binding](https://www.gnu.org/software/emacs/manual/html_node/elisp/Lexical-Binding.html)
in lisp like language, and lexical binding should be right behavior
which generates more predicable result, and it doesn't introduce really
subtle bugs in nushell code.
What if user want dynamic-binding?(For example: the example code returns
`4`)
There is no way to do this, user should consider passing the value as
argument to custom command rather than const.
## TODO
- [X] adding tests for the feature.
- [X] support export const out of module to use.
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- -c "use std testing; testing run-tests --path
crates/nu-std"` to run the tests for the standard library
> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
2023-07-31 23:09:52 +00:00
|
|
|
ExportConst,
|
2023-02-24 15:54:42 +00:00
|
|
|
ExportDef,
|
|
|
|
ExportExtern,
|
|
|
|
ExportUse,
|
2023-05-06 18:39:54 +00:00
|
|
|
ExportModule,
|
2023-02-24 15:54:42 +00:00
|
|
|
Extern,
|
|
|
|
For,
|
|
|
|
Hide,
|
|
|
|
HideEnv,
|
|
|
|
If,
|
|
|
|
Ignore,
|
|
|
|
Overlay,
|
|
|
|
OverlayUse,
|
|
|
|
OverlayList,
|
|
|
|
OverlayNew,
|
|
|
|
OverlayHide,
|
|
|
|
Let,
|
|
|
|
Loop,
|
2023-03-24 01:52:01 +00:00
|
|
|
Match,
|
2023-02-24 15:54:42 +00:00
|
|
|
Module,
|
|
|
|
Mut,
|
|
|
|
Return,
|
2023-06-20 21:33:01 +00:00
|
|
|
Scope,
|
|
|
|
ScopeAliases,
|
|
|
|
ScopeCommands,
|
|
|
|
ScopeEngineStats,
|
2023-08-17 08:58:38 +00:00
|
|
|
ScopeExterns,
|
2023-06-20 21:33:01 +00:00
|
|
|
ScopeModules,
|
|
|
|
ScopeVariables,
|
2023-02-24 15:54:42 +00:00
|
|
|
Try,
|
|
|
|
Use,
|
|
|
|
Version,
|
|
|
|
While,
|
|
|
|
};
|
|
|
|
|
|
|
|
working_set.render()
|
|
|
|
};
|
|
|
|
|
|
|
|
if let Err(err) = engine_state.merge_delta(delta) {
|
|
|
|
eprintln!("Error creating default context: {err:?}");
|
|
|
|
}
|
|
|
|
|
|
|
|
engine_state
|
|
|
|
}
|