2020-04-06 09:16:14 +02:00
|
|
|
use std::path::PathBuf;
|
|
|
|
|
|
|
|
use serde::{Deserialize, Serialize};
|
|
|
|
|
2019-06-22 03:36:57 +02:00
|
|
|
use derive_new::new;
|
Extract core stuff into own crates
This commit extracts five new crates:
- nu-source, which contains the core source-code handling logic in Nu,
including Text, Span, and also the pretty.rs-based debug logic
- nu-parser, which is the parser and expander logic
- nu-protocol, which is the bulk of the types and basic conveniences
used by plugins
- nu-errors, which contains ShellError, ParseError and error handling
conveniences
- nu-textview, which is the textview plugin extracted into a crate
One of the major consequences of this refactor is that it's no longer
possible to `impl X for Spanned<Y>` outside of the `nu-source` crate, so
a lot of types became more concrete (Value became a concrete type
instead of Spanned<Value>, for example).
This also turned a number of inherent methods in the main nu crate into
plain functions (impl Value {} became a bunch of functions in the
`value` namespace in `crate::data::value`).
2019-11-26 03:30:48 +01:00
|
|
|
use nu_protocol::{PathMember, ShellTypeName};
|
2020-04-06 09:16:14 +02:00
|
|
|
use nu_protocol::{Primitive, UntaggedValue};
|
|
|
|
use num_traits::ToPrimitive;
|
|
|
|
|
Extract core stuff into own crates
This commit extracts five new crates:
- nu-source, which contains the core source-code handling logic in Nu,
including Text, Span, and also the pretty.rs-based debug logic
- nu-parser, which is the parser and expander logic
- nu-protocol, which is the bulk of the types and basic conveniences
used by plugins
- nu-errors, which contains ShellError, ParseError and error handling
conveniences
- nu-textview, which is the textview plugin extracted into a crate
One of the major consequences of this refactor is that it's no longer
possible to `impl X for Spanned<Y>` outside of the `nu-source` crate, so
a lot of types became more concrete (Value became a concrete type
instead of Spanned<Value>, for example).
This also turned a number of inherent methods in the main nu crate into
plain functions (impl Value {} became a bunch of functions in the
`value` namespace in `crate::data::value`).
2019-11-26 03:30:48 +01:00
|
|
|
use nu_source::{
|
2020-04-06 09:16:14 +02:00
|
|
|
b, DebugDocBuilder, HasSpan, PrettyDebug, PrettyDebugRefineKind, PrettyDebugWithSource,
|
Extract core stuff into own crates
This commit extracts five new crates:
- nu-source, which contains the core source-code handling logic in Nu,
including Text, Span, and also the pretty.rs-based debug logic
- nu-parser, which is the parser and expander logic
- nu-protocol, which is the bulk of the types and basic conveniences
used by plugins
- nu-errors, which contains ShellError, ParseError and error handling
conveniences
- nu-textview, which is the textview plugin extracted into a crate
One of the major consequences of this refactor is that it's no longer
possible to `impl X for Spanned<Y>` outside of the `nu-source` crate, so
a lot of types became more concrete (Value became a concrete type
instead of Spanned<Value>, for example).
This also turned a number of inherent methods in the main nu crate into
plain functions (impl Value {} became a bunch of functions in the
`value` namespace in `crate::data::value`).
2019-11-26 03:30:48 +01:00
|
|
|
};
|
2020-04-06 09:16:14 +02:00
|
|
|
use nu_source::{IntoSpanned, Span, Spanned, SpannedItem};
|
|
|
|
|
|
|
|
use bigdecimal::BigDecimal;
|
|
|
|
use indexmap::IndexMap;
|
|
|
|
use log::trace;
|
|
|
|
use num_bigint::BigInt;
|
|
|
|
use num_traits::identities::Zero;
|
|
|
|
use num_traits::FromPrimitive;
|
|
|
|
|
|
|
|
#[derive(Debug, Ord, PartialOrd, Eq, PartialEq, Clone, Hash, Deserialize, Serialize)]
|
|
|
|
pub struct ExternalCommand {
|
|
|
|
pub name: Spanned<String>,
|
|
|
|
pub args: Vec<Spanned<String>>,
|
|
|
|
}
|
2019-06-22 03:36:57 +02:00
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
#[derive(Debug, Ord, PartialOrd, Eq, PartialEq, Clone, Hash, Copy, Deserialize, Serialize)]
|
|
|
|
pub enum Unit {
|
|
|
|
// Filesize units
|
|
|
|
Byte,
|
|
|
|
Kilobyte,
|
|
|
|
Megabyte,
|
|
|
|
Gigabyte,
|
|
|
|
Terabyte,
|
|
|
|
Petabyte,
|
|
|
|
|
|
|
|
// Duration units
|
|
|
|
Second,
|
|
|
|
Minute,
|
|
|
|
Hour,
|
|
|
|
Day,
|
|
|
|
Week,
|
|
|
|
Month,
|
|
|
|
Year,
|
|
|
|
}
|
2019-08-16 00:18:18 +02:00
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
#[derive(Debug, Ord, PartialOrd, Eq, PartialEq, Clone, Hash, Deserialize, Serialize)]
|
|
|
|
pub enum Member {
|
|
|
|
String(/* outer */ Span, /* inner */ Span),
|
|
|
|
Int(BigInt, Span),
|
|
|
|
Bare(Spanned<String>),
|
|
|
|
}
|
2019-06-22 03:36:57 +02:00
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
impl Member {
|
|
|
|
// pub fn int(span: Span, source: &Text) -> Member {
|
|
|
|
// if let Ok(big_int) = BigInt::from_str(span.slice(source)) {
|
|
|
|
// Member::Int(big_int, span)
|
|
|
|
// } else {
|
|
|
|
// unreachable!("Internal error: could not convert text to BigInt as expected")
|
|
|
|
// }
|
|
|
|
// }
|
2019-06-29 10:55:42 +02:00
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
pub fn to_path_member(&self) -> PathMember {
|
|
|
|
match self {
|
|
|
|
//Member::String(outer, inner) => PathMember::string(inner.slice(source), *outer),
|
|
|
|
Member::Int(int, span) => PathMember::int(int.clone(), *span),
|
|
|
|
Member::Bare(spanned_string) => {
|
|
|
|
PathMember::string(spanned_string.item.clone(), spanned_string.span)
|
|
|
|
}
|
|
|
|
_ => unimplemented!("Need to finish to_path_member"),
|
|
|
|
}
|
|
|
|
}
|
2019-12-04 22:14:52 +01:00
|
|
|
}
|
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
impl PrettyDebugWithSource for Member {
|
|
|
|
fn pretty_debug(&self, source: &str) -> DebugDocBuilder {
|
|
|
|
match self {
|
|
|
|
Member::String(outer, _) => b::value(outer.slice(source)),
|
|
|
|
Member::Int(int, _) => b::value(format!("{}", int)),
|
|
|
|
Member::Bare(span) => b::value(span.span.slice(source)),
|
2019-12-04 22:14:52 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
impl HasSpan for Member {
|
2019-12-04 22:14:52 +01:00
|
|
|
fn span(&self) -> Span {
|
2020-04-06 09:16:14 +02:00
|
|
|
match self {
|
|
|
|
Member::String(outer, ..) => *outer,
|
|
|
|
Member::Int(_, int) => *int,
|
|
|
|
Member::Bare(name) => name.span,
|
|
|
|
}
|
2019-12-04 22:14:52 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
#[derive(Debug, Ord, PartialOrd, Eq, PartialEq, Clone, Hash, Deserialize, Serialize)]
|
|
|
|
pub enum Number {
|
|
|
|
Int(BigInt),
|
|
|
|
Decimal(BigDecimal),
|
2019-12-04 22:14:52 +01:00
|
|
|
}
|
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
impl PrettyDebug for Number {
|
|
|
|
fn pretty(&self) -> DebugDocBuilder {
|
|
|
|
match self {
|
|
|
|
Number::Int(int) => b::primitive(int),
|
|
|
|
Number::Decimal(decimal) => b::primitive(decimal),
|
|
|
|
}
|
|
|
|
}
|
2019-11-21 15:33:14 +01:00
|
|
|
}
|
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
macro_rules! primitive_int {
|
|
|
|
($($ty:ty)*) => {
|
|
|
|
$(
|
|
|
|
impl From<$ty> for Number {
|
|
|
|
fn from(int: $ty) -> Number {
|
|
|
|
Number::Int(BigInt::zero() + int)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl From<&$ty> for Number {
|
|
|
|
fn from(int: &$ty) -> Number {
|
|
|
|
Number::Int(BigInt::zero() + *int)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
)*
|
2020-01-17 23:46:18 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
primitive_int!(i8 u8 i16 u16 i32 u32 i64 u64 i128 u128);
|
|
|
|
|
|
|
|
macro_rules! primitive_decimal {
|
|
|
|
($($ty:tt -> $from:tt),*) => {
|
|
|
|
$(
|
|
|
|
impl From<$ty> for Number {
|
|
|
|
fn from(decimal: $ty) -> Number {
|
|
|
|
if let Some(num) = BigDecimal::$from(decimal) {
|
|
|
|
Number::Decimal(num)
|
|
|
|
} else {
|
|
|
|
unreachable!("Internal error: BigDecimal 'from' failed")
|
|
|
|
}
|
|
|
|
}
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
}
|
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
impl From<&$ty> for Number {
|
|
|
|
fn from(decimal: &$ty) -> Number {
|
|
|
|
if let Some(num) = BigDecimal::$from(*decimal) {
|
|
|
|
Number::Decimal(num)
|
|
|
|
} else {
|
|
|
|
unreachable!("Internal error: BigDecimal 'from' failed")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
)*
|
2019-11-21 15:33:14 +01:00
|
|
|
}
|
2019-06-22 03:36:57 +02:00
|
|
|
}
|
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
primitive_decimal!(f32 -> from_f32, f64 -> from_f64);
|
2019-09-10 17:31:21 +02:00
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
impl std::ops::Mul for Number {
|
|
|
|
type Output = Number;
|
2019-06-22 03:36:57 +02:00
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
fn mul(self, other: Number) -> Number {
|
|
|
|
match (self, other) {
|
|
|
|
(Number::Int(a), Number::Int(b)) => Number::Int(a * b),
|
|
|
|
(Number::Int(a), Number::Decimal(b)) => Number::Decimal(BigDecimal::from(a) * b),
|
|
|
|
(Number::Decimal(a), Number::Int(b)) => Number::Decimal(a * BigDecimal::from(b)),
|
|
|
|
(Number::Decimal(a), Number::Decimal(b)) => Number::Decimal(a * b),
|
|
|
|
}
|
|
|
|
}
|
2019-06-22 03:36:57 +02:00
|
|
|
}
|
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
// For literals
|
|
|
|
impl std::ops::Mul<u32> for Number {
|
|
|
|
type Output = Number;
|
|
|
|
|
|
|
|
fn mul(self, other: u32) -> Number {
|
2019-06-30 08:14:40 +02:00
|
|
|
match self {
|
2020-04-06 09:16:14 +02:00
|
|
|
Number::Int(left) => Number::Int(left * (other as i64)),
|
|
|
|
Number::Decimal(left) => Number::Decimal(left * BigDecimal::from(other)),
|
2019-06-30 08:14:40 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
impl PrettyDebug for Unit {
|
|
|
|
fn pretty(&self) -> DebugDocBuilder {
|
|
|
|
b::keyword(self.as_str())
|
|
|
|
}
|
2019-11-21 15:33:14 +01:00
|
|
|
}
|
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
fn convert_number_to_u64(number: &Number) -> u64 {
|
|
|
|
match number {
|
|
|
|
Number::Int(big_int) => {
|
|
|
|
if let Some(x) = big_int.to_u64() {
|
|
|
|
x
|
|
|
|
} else {
|
|
|
|
unreachable!("Internal error: convert_number_to_u64 given incompatible number")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
Number::Decimal(big_decimal) => {
|
|
|
|
if let Some(x) = big_decimal.to_u64() {
|
|
|
|
x
|
|
|
|
} else {
|
|
|
|
unreachable!("Internal error: convert_number_to_u64 given incompatible number")
|
|
|
|
}
|
2019-11-21 15:33:14 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
impl Unit {
|
|
|
|
pub fn as_str(self) -> &'static str {
|
|
|
|
match self {
|
|
|
|
Unit::Byte => "B",
|
|
|
|
Unit::Kilobyte => "KB",
|
|
|
|
Unit::Megabyte => "MB",
|
|
|
|
Unit::Gigabyte => "GB",
|
|
|
|
Unit::Terabyte => "TB",
|
|
|
|
Unit::Petabyte => "PB",
|
|
|
|
Unit::Second => "s",
|
|
|
|
Unit::Minute => "m",
|
|
|
|
Unit::Hour => "h",
|
|
|
|
Unit::Day => "d",
|
|
|
|
Unit::Week => "w",
|
|
|
|
Unit::Month => "M",
|
|
|
|
Unit::Year => "y",
|
|
|
|
}
|
|
|
|
}
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
pub fn compute(self, size: &Number) -> UntaggedValue {
|
|
|
|
let size = size.clone();
|
|
|
|
|
|
|
|
match self {
|
|
|
|
Unit::Byte => number(size),
|
|
|
|
Unit::Kilobyte => number(size * 1024),
|
|
|
|
Unit::Megabyte => number(size * 1024 * 1024),
|
|
|
|
Unit::Gigabyte => number(size * 1024 * 1024 * 1024),
|
|
|
|
Unit::Terabyte => number(size * 1024 * 1024 * 1024 * 1024),
|
|
|
|
Unit::Petabyte => number(size * 1024 * 1024 * 1024 * 1024 * 1024),
|
|
|
|
Unit::Second => duration(convert_number_to_u64(&size)),
|
|
|
|
Unit::Minute => duration(60 * convert_number_to_u64(&size)),
|
|
|
|
Unit::Hour => duration(60 * 60 * convert_number_to_u64(&size)),
|
|
|
|
Unit::Day => duration(24 * 60 * 60 * convert_number_to_u64(&size)),
|
|
|
|
Unit::Week => duration(7 * 24 * 60 * 60 * convert_number_to_u64(&size)),
|
|
|
|
Unit::Month => duration(30 * 24 * 60 * 60 * convert_number_to_u64(&size)),
|
|
|
|
Unit::Year => duration(365 * 24 * 60 * 60 * convert_number_to_u64(&size)),
|
2019-11-21 15:33:14 +01:00
|
|
|
}
|
|
|
|
}
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
}
|
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
fn number(number: impl Into<Number>) -> UntaggedValue {
|
|
|
|
let number = number.into();
|
2019-11-21 15:33:14 +01:00
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
match number {
|
|
|
|
Number::Int(int) => UntaggedValue::Primitive(Primitive::Int(int)),
|
|
|
|
Number::Decimal(decimal) => UntaggedValue::Primitive(Primitive::Decimal(decimal)),
|
2019-11-21 15:33:14 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
pub fn duration(secs: u64) -> UntaggedValue {
|
|
|
|
UntaggedValue::Primitive(Primitive::Duration(secs))
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Ord, PartialOrd, Eq, PartialEq, Clone, Hash, Deserialize, Serialize)]
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
pub struct SpannedExpression {
|
|
|
|
pub expr: Expression,
|
2019-11-21 15:33:14 +01:00
|
|
|
pub span: Span,
|
|
|
|
}
|
|
|
|
|
2020-02-09 03:24:33 +01:00
|
|
|
impl SpannedExpression {
|
|
|
|
pub fn new(expr: Expression, span: Span) -> SpannedExpression {
|
|
|
|
SpannedExpression { expr, span }
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
impl std::ops::Deref for SpannedExpression {
|
|
|
|
type Target = Expression;
|
2019-11-21 15:33:14 +01:00
|
|
|
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
fn deref(&self) -> &Expression {
|
2019-11-21 15:33:14 +01:00
|
|
|
&self.expr
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
impl HasSpan for SpannedExpression {
|
2019-11-21 15:33:14 +01:00
|
|
|
fn span(&self) -> Span {
|
|
|
|
self.span
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
impl ShellTypeName for SpannedExpression {
|
|
|
|
fn type_name(&self) -> &'static str {
|
|
|
|
self.expr.type_name()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl PrettyDebugWithSource for SpannedExpression {
|
|
|
|
fn refined_pretty_debug(&self, refine: PrettyDebugRefineKind, source: &str) -> DebugDocBuilder {
|
|
|
|
match refine {
|
|
|
|
PrettyDebugRefineKind::ContextFree => self.refined_pretty_debug(refine, source),
|
|
|
|
PrettyDebugRefineKind::WithContext => match &self.expr {
|
|
|
|
Expression::Literal(literal) => literal
|
|
|
|
.clone()
|
|
|
|
.into_spanned(self.span)
|
|
|
|
.refined_pretty_debug(refine, source),
|
|
|
|
Expression::ExternalWord => {
|
|
|
|
b::delimit("e\"", b::primitive(self.span.slice(source)), "\"").group()
|
|
|
|
}
|
|
|
|
Expression::Synthetic(s) => match s {
|
|
|
|
Synthetic::String(_) => {
|
|
|
|
b::delimit("s\"", b::primitive(self.span.slice(source)), "\"").group()
|
|
|
|
}
|
|
|
|
},
|
2020-04-06 09:16:14 +02:00
|
|
|
Expression::Variable(Variable::Other(_, _)) => b::keyword(self.span.slice(source)),
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
Expression::Variable(Variable::It(_)) => b::keyword("$it"),
|
|
|
|
Expression::Binary(binary) => binary.pretty_debug(source),
|
|
|
|
Expression::Range(range) => range.pretty_debug(source),
|
|
|
|
Expression::Block(_) => b::opaque("block"),
|
2020-04-06 09:16:14 +02:00
|
|
|
Expression::Garbage => b::opaque("garbage"),
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
Expression::List(list) => b::delimit(
|
|
|
|
"[",
|
|
|
|
b::intersperse(
|
|
|
|
list.iter()
|
|
|
|
.map(|item| item.refined_pretty_debug(refine, source)),
|
|
|
|
b::space(),
|
|
|
|
),
|
|
|
|
"]",
|
|
|
|
),
|
|
|
|
Expression::Path(path) => path.pretty_debug(source),
|
|
|
|
Expression::FilePath(path) => b::typed("path", b::primitive(path.display())),
|
|
|
|
Expression::ExternalCommand(external) => {
|
2020-04-06 09:16:14 +02:00
|
|
|
b::keyword("^") + b::keyword(external.name.span.slice(source))
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
}
|
|
|
|
Expression::Command(command) => b::keyword(command.slice(source)),
|
|
|
|
Expression::Boolean(boolean) => match boolean {
|
|
|
|
true => b::primitive("$yes"),
|
|
|
|
false => b::primitive("$no"),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-11-21 15:33:14 +01:00
|
|
|
fn pretty_debug(&self, source: &str) -> DebugDocBuilder {
|
|
|
|
match &self.expr {
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
Expression::Literal(literal) => {
|
|
|
|
literal.clone().into_spanned(self.span).pretty_debug(source)
|
|
|
|
}
|
|
|
|
Expression::ExternalWord => {
|
2019-11-21 15:33:14 +01:00
|
|
|
b::typed("external word", b::primitive(self.span.slice(source)))
|
|
|
|
}
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
Expression::Synthetic(s) => match s {
|
2019-11-21 15:33:14 +01:00
|
|
|
Synthetic::String(s) => b::typed("synthetic", b::primitive(format!("{:?}", s))),
|
|
|
|
},
|
2020-04-06 09:16:14 +02:00
|
|
|
Expression::Variable(Variable::Other(_, _)) => b::keyword(self.span.slice(source)),
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
Expression::Variable(Variable::It(_)) => b::keyword("$it"),
|
|
|
|
Expression::Binary(binary) => binary.pretty_debug(source),
|
|
|
|
Expression::Range(range) => range.pretty_debug(source),
|
|
|
|
Expression::Block(_) => b::opaque("block"),
|
2020-04-06 09:16:14 +02:00
|
|
|
Expression::Garbage => b::opaque("garbage"),
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
Expression::List(list) => b::delimit(
|
2019-11-21 15:33:14 +01:00
|
|
|
"[",
|
|
|
|
b::intersperse(
|
|
|
|
list.iter().map(|item| item.pretty_debug(source)),
|
|
|
|
b::space(),
|
|
|
|
),
|
|
|
|
"]",
|
|
|
|
),
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
Expression::Path(path) => path.pretty_debug(source),
|
|
|
|
Expression::FilePath(path) => b::typed("path", b::primitive(path.display())),
|
|
|
|
Expression::ExternalCommand(external) => b::typed(
|
|
|
|
"command",
|
2020-04-06 09:16:14 +02:00
|
|
|
b::keyword("^") + b::primitive(external.name.span.slice(source)),
|
2019-11-21 15:33:14 +01:00
|
|
|
),
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
Expression::Command(command) => {
|
2019-11-21 15:33:14 +01:00
|
|
|
b::typed("command", b::primitive(command.slice(source)))
|
|
|
|
}
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
Expression::Boolean(boolean) => match boolean {
|
2019-11-21 15:33:14 +01:00
|
|
|
true => b::primitive("$yes"),
|
|
|
|
false => b::primitive("$no"),
|
|
|
|
},
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2019-06-22 03:36:57 +02:00
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
#[derive(Debug, Ord, PartialOrd, Eq, PartialEq, Clone, Hash, Deserialize, Serialize)]
|
|
|
|
pub enum Variable {
|
|
|
|
It(Span),
|
|
|
|
Other(String, Span),
|
|
|
|
}
|
2019-07-24 00:22:11 +02:00
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
#[derive(Debug, Clone, Copy, PartialOrd, Ord, Eq, Hash, PartialEq, Deserialize, Serialize)]
|
|
|
|
pub enum CompareOperator {
|
|
|
|
Equal,
|
|
|
|
NotEqual,
|
|
|
|
LessThan,
|
|
|
|
GreaterThan,
|
|
|
|
LessThanOrEqual,
|
|
|
|
GreaterThanOrEqual,
|
|
|
|
Contains,
|
|
|
|
NotContains,
|
|
|
|
}
|
2019-06-22 03:36:57 +02:00
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
#[derive(Debug, Ord, PartialOrd, Eq, PartialEq, Clone, Hash, Deserialize, Serialize, new)]
|
|
|
|
pub struct Binary {
|
|
|
|
pub left: SpannedExpression,
|
|
|
|
pub op: SpannedExpression, //Spanned<CompareOperator>,
|
|
|
|
pub right: SpannedExpression,
|
|
|
|
}
|
2019-11-04 16:47:03 +01:00
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
impl PrettyDebugWithSource for Binary {
|
|
|
|
fn pretty_debug(&self, source: &str) -> DebugDocBuilder {
|
|
|
|
b::delimit(
|
|
|
|
"<",
|
|
|
|
self.left.pretty_debug(source)
|
|
|
|
+ b::space()
|
|
|
|
+ b::keyword(self.op.span.slice(source))
|
|
|
|
+ b::space()
|
|
|
|
+ self.right.pretty_debug(source),
|
|
|
|
">",
|
|
|
|
)
|
|
|
|
.group()
|
Overhaul the expansion system
The main thrust of this (very large) commit is an overhaul of the
expansion system.
The parsing pipeline is:
- Lightly parse the source file for atoms, basic delimiters and pipeline
structure into a token tree
- Expand the token tree into a HIR (high-level intermediate
representation) based upon the baseline syntax rules for expressions
and the syntactic shape of commands.
Somewhat non-traditionally, nu doesn't have an AST at all. It goes
directly from the token tree, which doesn't represent many important
distinctions (like the difference between `hello` and `5KB`) directly
into a high-level representation that doesn't have a direct
correspondence to the source code.
At a high level, nu commands work like macros, in the sense that the
syntactic shape of the invocation of a command depends on the
definition of a command.
However, commands do not have the ability to perform unrestricted
expansions of the token tree. Instead, they describe their arguments in
terms of syntactic shapes, and the expander expands the token tree into
HIR based upon that definition.
For example, the `where` command says that it takes a block as its first
required argument, and the description of the block syntactic shape
expands the syntax `cpu > 10` into HIR that represents
`{ $it.cpu > 10 }`.
This commit overhauls that system so that the syntactic shapes are
described in terms of a few new traits (`ExpandSyntax` and
`ExpandExpression` are the primary ones) that are more composable than
the previous system.
The first big win of this new system is the addition of the `ColumnPath`
shape, which looks like `cpu."max ghz"` or `package.version`.
Previously, while a variable path could look like `$it.cpu."max ghz"`,
the tail of a variable path could not be easily reused in other
contexts. Now, that tail is its own syntactic shape, and it can be used
as part of a command's signature.
This cleans up commands like `inc`, `add` and `edit` as well as
shorthand blocks, which can now look like `| where cpu."max ghz" > 10`
2019-09-18 00:26:27 +02:00
|
|
|
}
|
2020-04-06 09:16:14 +02:00
|
|
|
}
|
Overhaul the expansion system
The main thrust of this (very large) commit is an overhaul of the
expansion system.
The parsing pipeline is:
- Lightly parse the source file for atoms, basic delimiters and pipeline
structure into a token tree
- Expand the token tree into a HIR (high-level intermediate
representation) based upon the baseline syntax rules for expressions
and the syntactic shape of commands.
Somewhat non-traditionally, nu doesn't have an AST at all. It goes
directly from the token tree, which doesn't represent many important
distinctions (like the difference between `hello` and `5KB`) directly
into a high-level representation that doesn't have a direct
correspondence to the source code.
At a high level, nu commands work like macros, in the sense that the
syntactic shape of the invocation of a command depends on the
definition of a command.
However, commands do not have the ability to perform unrestricted
expansions of the token tree. Instead, they describe their arguments in
terms of syntactic shapes, and the expander expands the token tree into
HIR based upon that definition.
For example, the `where` command says that it takes a block as its first
required argument, and the description of the block syntactic shape
expands the syntax `cpu > 10` into HIR that represents
`{ $it.cpu > 10 }`.
This commit overhauls that system so that the syntactic shapes are
described in terms of a few new traits (`ExpandSyntax` and
`ExpandExpression` are the primary ones) that are more composable than
the previous system.
The first big win of this new system is the addition of the `ColumnPath`
shape, which looks like `cpu."max ghz"` or `package.version`.
Previously, while a variable path could look like `$it.cpu."max ghz"`,
the tail of a variable path could not be easily reused in other
contexts. Now, that tail is its own syntactic shape, and it can be used
as part of a command's signature.
This cleans up commands like `inc`, `add` and `edit` as well as
shorthand blocks, which can now look like `| where cpu."max ghz" > 10`
2019-09-18 00:26:27 +02:00
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
#[derive(Debug, Ord, PartialOrd, Eq, PartialEq, Clone, Hash, Deserialize, Serialize)]
|
|
|
|
pub enum Synthetic {
|
|
|
|
String(String),
|
|
|
|
}
|
Overhaul the expansion system
The main thrust of this (very large) commit is an overhaul of the
expansion system.
The parsing pipeline is:
- Lightly parse the source file for atoms, basic delimiters and pipeline
structure into a token tree
- Expand the token tree into a HIR (high-level intermediate
representation) based upon the baseline syntax rules for expressions
and the syntactic shape of commands.
Somewhat non-traditionally, nu doesn't have an AST at all. It goes
directly from the token tree, which doesn't represent many important
distinctions (like the difference between `hello` and `5KB`) directly
into a high-level representation that doesn't have a direct
correspondence to the source code.
At a high level, nu commands work like macros, in the sense that the
syntactic shape of the invocation of a command depends on the
definition of a command.
However, commands do not have the ability to perform unrestricted
expansions of the token tree. Instead, they describe their arguments in
terms of syntactic shapes, and the expander expands the token tree into
HIR based upon that definition.
For example, the `where` command says that it takes a block as its first
required argument, and the description of the block syntactic shape
expands the syntax `cpu > 10` into HIR that represents
`{ $it.cpu > 10 }`.
This commit overhauls that system so that the syntactic shapes are
described in terms of a few new traits (`ExpandSyntax` and
`ExpandExpression` are the primary ones) that are more composable than
the previous system.
The first big win of this new system is the addition of the `ColumnPath`
shape, which looks like `cpu."max ghz"` or `package.version`.
Previously, while a variable path could look like `$it.cpu."max ghz"`,
the tail of a variable path could not be easily reused in other
contexts. Now, that tail is its own syntactic shape, and it can be used
as part of a command's signature.
This cleans up commands like `inc`, `add` and `edit` as well as
shorthand blocks, which can now look like `| where cpu."max ghz" > 10`
2019-09-18 00:26:27 +02:00
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
impl ShellTypeName for Synthetic {
|
|
|
|
fn type_name(&self) -> &'static str {
|
|
|
|
match self {
|
|
|
|
Synthetic::String(_) => "string",
|
Overhaul the expansion system
The main thrust of this (very large) commit is an overhaul of the
expansion system.
The parsing pipeline is:
- Lightly parse the source file for atoms, basic delimiters and pipeline
structure into a token tree
- Expand the token tree into a HIR (high-level intermediate
representation) based upon the baseline syntax rules for expressions
and the syntactic shape of commands.
Somewhat non-traditionally, nu doesn't have an AST at all. It goes
directly from the token tree, which doesn't represent many important
distinctions (like the difference between `hello` and `5KB`) directly
into a high-level representation that doesn't have a direct
correspondence to the source code.
At a high level, nu commands work like macros, in the sense that the
syntactic shape of the invocation of a command depends on the
definition of a command.
However, commands do not have the ability to perform unrestricted
expansions of the token tree. Instead, they describe their arguments in
terms of syntactic shapes, and the expander expands the token tree into
HIR based upon that definition.
For example, the `where` command says that it takes a block as its first
required argument, and the description of the block syntactic shape
expands the syntax `cpu > 10` into HIR that represents
`{ $it.cpu > 10 }`.
This commit overhauls that system so that the syntactic shapes are
described in terms of a few new traits (`ExpandSyntax` and
`ExpandExpression` are the primary ones) that are more composable than
the previous system.
The first big win of this new system is the addition of the `ColumnPath`
shape, which looks like `cpu."max ghz"` or `package.version`.
Previously, while a variable path could look like `$it.cpu."max ghz"`,
the tail of a variable path could not be easily reused in other
contexts. Now, that tail is its own syntactic shape, and it can be used
as part of a command's signature.
This cleans up commands like `inc`, `add` and `edit` as well as
shorthand blocks, which can now look like `| where cpu."max ghz" > 10`
2019-09-18 00:26:27 +02:00
|
|
|
}
|
|
|
|
}
|
2020-04-06 09:16:14 +02:00
|
|
|
}
|
Overhaul the expansion system
The main thrust of this (very large) commit is an overhaul of the
expansion system.
The parsing pipeline is:
- Lightly parse the source file for atoms, basic delimiters and pipeline
structure into a token tree
- Expand the token tree into a HIR (high-level intermediate
representation) based upon the baseline syntax rules for expressions
and the syntactic shape of commands.
Somewhat non-traditionally, nu doesn't have an AST at all. It goes
directly from the token tree, which doesn't represent many important
distinctions (like the difference between `hello` and `5KB`) directly
into a high-level representation that doesn't have a direct
correspondence to the source code.
At a high level, nu commands work like macros, in the sense that the
syntactic shape of the invocation of a command depends on the
definition of a command.
However, commands do not have the ability to perform unrestricted
expansions of the token tree. Instead, they describe their arguments in
terms of syntactic shapes, and the expander expands the token tree into
HIR based upon that definition.
For example, the `where` command says that it takes a block as its first
required argument, and the description of the block syntactic shape
expands the syntax `cpu > 10` into HIR that represents
`{ $it.cpu > 10 }`.
This commit overhauls that system so that the syntactic shapes are
described in terms of a few new traits (`ExpandSyntax` and
`ExpandExpression` are the primary ones) that are more composable than
the previous system.
The first big win of this new system is the addition of the `ColumnPath`
shape, which looks like `cpu."max ghz"` or `package.version`.
Previously, while a variable path could look like `$it.cpu."max ghz"`,
the tail of a variable path could not be easily reused in other
contexts. Now, that tail is its own syntactic shape, and it can be used
as part of a command's signature.
This cleans up commands like `inc`, `add` and `edit` as well as
shorthand blocks, which can now look like `| where cpu."max ghz" > 10`
2019-09-18 00:26:27 +02:00
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
#[derive(Debug, Ord, PartialOrd, Eq, PartialEq, Clone, Hash, Deserialize, Serialize)]
|
|
|
|
pub struct Range {
|
|
|
|
pub left: SpannedExpression,
|
|
|
|
pub dotdot: Span,
|
|
|
|
pub right: SpannedExpression,
|
2019-07-24 00:22:11 +02:00
|
|
|
}
|
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
impl PrettyDebugWithSource for Range {
|
|
|
|
fn pretty_debug(&self, source: &str) -> DebugDocBuilder {
|
|
|
|
b::delimit(
|
|
|
|
"<",
|
|
|
|
self.left.pretty_debug(source)
|
|
|
|
+ b::space()
|
|
|
|
+ b::keyword(self.dotdot.slice(source))
|
|
|
|
+ b::space()
|
|
|
|
+ self.right.pretty_debug(source),
|
|
|
|
">",
|
|
|
|
)
|
|
|
|
.group()
|
2019-06-29 10:55:42 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
#[derive(Debug, Ord, PartialOrd, Eq, PartialEq, Clone, Hash, Deserialize, Serialize)]
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
pub enum Literal {
|
2019-08-30 19:29:04 +02:00
|
|
|
Number(Number),
|
2020-04-06 09:16:14 +02:00
|
|
|
Size(Spanned<Number>, Spanned<Unit>),
|
|
|
|
Operator(CompareOperator),
|
|
|
|
String(String),
|
2019-10-27 02:01:58 +01:00
|
|
|
GlobPattern(String),
|
2019-11-04 16:47:03 +01:00
|
|
|
ColumnPath(Vec<Member>),
|
2020-04-10 09:56:48 +02:00
|
|
|
Bare(String),
|
2019-06-22 03:36:57 +02:00
|
|
|
}
|
|
|
|
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
impl Literal {
|
|
|
|
pub fn into_spanned(self, span: impl Into<Span>) -> SpannedLiteral {
|
|
|
|
SpannedLiteral {
|
2019-11-21 15:33:14 +01:00
|
|
|
literal: self,
|
|
|
|
span: span.into(),
|
|
|
|
}
|
Overhaul the expansion system
The main thrust of this (very large) commit is an overhaul of the
expansion system.
The parsing pipeline is:
- Lightly parse the source file for atoms, basic delimiters and pipeline
structure into a token tree
- Expand the token tree into a HIR (high-level intermediate
representation) based upon the baseline syntax rules for expressions
and the syntactic shape of commands.
Somewhat non-traditionally, nu doesn't have an AST at all. It goes
directly from the token tree, which doesn't represent many important
distinctions (like the difference between `hello` and `5KB`) directly
into a high-level representation that doesn't have a direct
correspondence to the source code.
At a high level, nu commands work like macros, in the sense that the
syntactic shape of the invocation of a command depends on the
definition of a command.
However, commands do not have the ability to perform unrestricted
expansions of the token tree. Instead, they describe their arguments in
terms of syntactic shapes, and the expander expands the token tree into
HIR based upon that definition.
For example, the `where` command says that it takes a block as its first
required argument, and the description of the block syntactic shape
expands the syntax `cpu > 10` into HIR that represents
`{ $it.cpu > 10 }`.
This commit overhauls that system so that the syntactic shapes are
described in terms of a few new traits (`ExpandSyntax` and
`ExpandExpression` are the primary ones) that are more composable than
the previous system.
The first big win of this new system is the addition of the `ColumnPath`
shape, which looks like `cpu."max ghz"` or `package.version`.
Previously, while a variable path could look like `$it.cpu."max ghz"`,
the tail of a variable path could not be easily reused in other
contexts. Now, that tail is its own syntactic shape, and it can be used
as part of a command's signature.
This cleans up commands like `inc`, `add` and `edit` as well as
shorthand blocks, which can now look like `| where cpu."max ghz" > 10`
2019-09-18 00:26:27 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
//, Eq, PartialEq, Ord, PartialOrd, Hash, Serialize, Deserialize
|
|
|
|
#[derive(Debug, Clone)]
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
pub struct SpannedLiteral {
|
|
|
|
pub literal: Literal,
|
2019-11-21 15:33:14 +01:00
|
|
|
pub span: Span,
|
Overhaul the expansion system
The main thrust of this (very large) commit is an overhaul of the
expansion system.
The parsing pipeline is:
- Lightly parse the source file for atoms, basic delimiters and pipeline
structure into a token tree
- Expand the token tree into a HIR (high-level intermediate
representation) based upon the baseline syntax rules for expressions
and the syntactic shape of commands.
Somewhat non-traditionally, nu doesn't have an AST at all. It goes
directly from the token tree, which doesn't represent many important
distinctions (like the difference between `hello` and `5KB`) directly
into a high-level representation that doesn't have a direct
correspondence to the source code.
At a high level, nu commands work like macros, in the sense that the
syntactic shape of the invocation of a command depends on the
definition of a command.
However, commands do not have the ability to perform unrestricted
expansions of the token tree. Instead, they describe their arguments in
terms of syntactic shapes, and the expander expands the token tree into
HIR based upon that definition.
For example, the `where` command says that it takes a block as its first
required argument, and the description of the block syntactic shape
expands the syntax `cpu > 10` into HIR that represents
`{ $it.cpu > 10 }`.
This commit overhauls that system so that the syntactic shapes are
described in terms of a few new traits (`ExpandSyntax` and
`ExpandExpression` are the primary ones) that are more composable than
the previous system.
The first big win of this new system is the addition of the `ColumnPath`
shape, which looks like `cpu."max ghz"` or `package.version`.
Previously, while a variable path could look like `$it.cpu."max ghz"`,
the tail of a variable path could not be easily reused in other
contexts. Now, that tail is its own syntactic shape, and it can be used
as part of a command's signature.
This cleans up commands like `inc`, `add` and `edit` as well as
shorthand blocks, which can now look like `| where cpu."max ghz" > 10`
2019-09-18 00:26:27 +02:00
|
|
|
}
|
|
|
|
|
2019-11-21 15:33:14 +01:00
|
|
|
impl ShellTypeName for Literal {
|
|
|
|
fn type_name(&self) -> &'static str {
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
match &self {
|
|
|
|
Literal::Number(..) => "number",
|
|
|
|
Literal::Size(..) => "size",
|
|
|
|
Literal::String(..) => "string",
|
|
|
|
Literal::ColumnPath(..) => "column path",
|
2020-04-10 09:56:48 +02:00
|
|
|
Literal::Bare(_) => "string",
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
Literal::GlobPattern(_) => "pattern",
|
2020-04-06 09:16:14 +02:00
|
|
|
Literal::Operator(_) => "operator",
|
2019-07-24 00:22:11 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
impl PrettyDebugWithSource for SpannedLiteral {
|
|
|
|
fn refined_pretty_debug(&self, refine: PrettyDebugRefineKind, source: &str) -> DebugDocBuilder {
|
|
|
|
match refine {
|
|
|
|
PrettyDebugRefineKind::ContextFree => self.pretty_debug(source),
|
|
|
|
PrettyDebugRefineKind::WithContext => match &self.literal {
|
|
|
|
Literal::Number(number) => number.pretty(),
|
|
|
|
Literal::Size(number, unit) => (number.pretty() + unit.pretty()).group(),
|
2020-04-06 09:16:14 +02:00
|
|
|
Literal::String(string) => b::primitive(format!("{:?}", string)), //string.slice(source))),
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
Literal::GlobPattern(pattern) => b::primitive(pattern),
|
|
|
|
Literal::ColumnPath(path) => {
|
|
|
|
b::intersperse_with_source(path.iter(), b::space(), source)
|
|
|
|
}
|
2020-04-10 09:56:48 +02:00
|
|
|
Literal::Bare(bare) => b::delimit("b\"", b::primitive(bare), "\""),
|
2020-04-06 09:16:14 +02:00
|
|
|
Literal::Operator(operator) => b::primitive(format!("{:?}", operator)),
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
},
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-11-21 15:33:14 +01:00
|
|
|
fn pretty_debug(&self, source: &str) -> DebugDocBuilder {
|
|
|
|
match &self.literal {
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
Literal::Number(number) => number.pretty(),
|
|
|
|
Literal::Size(number, unit) => {
|
|
|
|
b::typed("size", (number.pretty() + unit.pretty()).group())
|
|
|
|
}
|
|
|
|
Literal::String(string) => b::typed(
|
|
|
|
"string",
|
2020-04-06 09:16:14 +02:00
|
|
|
b::primitive(format!("{:?}", string)), //string.slice(source))),
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 23:45:03 +01:00
|
|
|
),
|
|
|
|
Literal::GlobPattern(pattern) => b::typed("pattern", b::primitive(pattern)),
|
|
|
|
Literal::ColumnPath(path) => b::typed(
|
2019-11-21 15:33:14 +01:00
|
|
|
"column path",
|
|
|
|
b::intersperse_with_source(path.iter(), b::space(), source),
|
|
|
|
),
|
2020-04-10 09:56:48 +02:00
|
|
|
Literal::Bare(bare) => b::typed("bare", b::primitive(bare)),
|
2020-04-06 09:16:14 +02:00
|
|
|
Literal::Operator(operator) => {
|
|
|
|
b::typed("operator", b::primitive(format!("{:?}", operator)))
|
|
|
|
}
|
2019-06-30 08:14:40 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-06 09:16:14 +02:00
|
|
|
#[derive(Debug, Ord, PartialOrd, Eq, PartialEq, Clone, Hash, new, Deserialize, Serialize)]
|
|
|
|
pub struct Path {
|
|
|
|
pub head: SpannedExpression,
|
|
|
|
pub tail: Vec<PathMember>,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl PrettyDebugWithSource for Path {
|
|
|
|
fn pretty_debug(&self, source: &str) -> DebugDocBuilder {
|
|
|
|
self.head.pretty_debug(source)
|
|
|
|
+ b::operator(".")
|
|
|
|
+ b::intersperse(self.tail.iter().map(|m| m.pretty()), b::operator("."))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Ord, PartialOrd, Eq, PartialEq, Clone, Hash, Deserialize, Serialize)]
|
|
|
|
pub enum Expression {
|
|
|
|
Literal(Literal),
|
|
|
|
ExternalWord,
|
|
|
|
Synthetic(Synthetic),
|
|
|
|
Variable(Variable),
|
|
|
|
Binary(Box<Binary>),
|
|
|
|
Range(Box<Range>),
|
|
|
|
Block(Vec<SpannedExpression>),
|
|
|
|
List(Vec<SpannedExpression>),
|
|
|
|
Path(Box<Path>),
|
|
|
|
|
|
|
|
FilePath(PathBuf),
|
|
|
|
ExternalCommand(ExternalCommand),
|
|
|
|
Command(Span),
|
|
|
|
|
|
|
|
Boolean(bool),
|
|
|
|
|
|
|
|
// Trying this approach out: if we let parsing always be infallible
|
|
|
|
// we can use the same parse and just place bad token markers in the output
|
|
|
|
// We can later throw an error if we try to process them further.
|
|
|
|
Garbage,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl ShellTypeName for Expression {
|
|
|
|
fn type_name(&self) -> &'static str {
|
|
|
|
match self {
|
|
|
|
Expression::Literal(literal) => literal.type_name(),
|
|
|
|
Expression::Synthetic(synthetic) => synthetic.type_name(),
|
|
|
|
Expression::Command(..) => "command",
|
|
|
|
Expression::ExternalWord => "external word",
|
|
|
|
Expression::FilePath(..) => "file path",
|
|
|
|
Expression::Variable(..) => "variable",
|
|
|
|
Expression::List(..) => "list",
|
|
|
|
Expression::Binary(..) => "binary",
|
|
|
|
Expression::Range(..) => "range",
|
|
|
|
Expression::Block(..) => "block",
|
|
|
|
Expression::Path(..) => "variable path",
|
|
|
|
Expression::Boolean(..) => "boolean",
|
|
|
|
Expression::ExternalCommand(..) => "external",
|
|
|
|
Expression::Garbage => "garbage",
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl IntoSpanned for Expression {
|
|
|
|
type Output = SpannedExpression;
|
|
|
|
|
|
|
|
fn into_spanned(self, span: impl Into<Span>) -> Self::Output {
|
|
|
|
SpannedExpression {
|
|
|
|
expr: self,
|
|
|
|
span: span.into(),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Expression {
|
|
|
|
pub fn integer(i: i64) -> Expression {
|
|
|
|
Expression::Literal(Literal::Number(Number::Int(BigInt::from(i))))
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn decimal(f: f64) -> Expression {
|
|
|
|
Expression::Literal(Literal::Number(Number::Decimal(BigDecimal::from(f))))
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn string(s: String) -> Expression {
|
|
|
|
Expression::Literal(Literal::String(s))
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn operator(operator: CompareOperator) -> Expression {
|
|
|
|
Expression::Literal(Literal::Operator(operator))
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn range(left: SpannedExpression, dotdot: Span, right: SpannedExpression) -> Expression {
|
|
|
|
Expression::Range(Box::new(Range {
|
|
|
|
left,
|
|
|
|
dotdot,
|
|
|
|
right,
|
|
|
|
}))
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn pattern(p: String) -> Expression {
|
|
|
|
Expression::Literal(Literal::GlobPattern(p))
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn file_path(file_path: PathBuf) -> Expression {
|
|
|
|
Expression::FilePath(file_path)
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn simple_column_path(members: Vec<Member>) -> Expression {
|
|
|
|
Expression::Literal(Literal::ColumnPath(members))
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn path(head: SpannedExpression, tail: Vec<impl Into<PathMember>>) -> Expression {
|
|
|
|
let tail = tail.into_iter().map(|t| t.into()).collect();
|
|
|
|
Expression::Path(Box::new(Path::new(head, tail)))
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn unit(i: Spanned<i64>, unit: Spanned<Unit>) -> Expression {
|
|
|
|
Expression::Literal(Literal::Size(
|
|
|
|
Number::Int(BigInt::from(i.item)).spanned(i.span),
|
|
|
|
unit,
|
|
|
|
))
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn variable(v: String, span: Span) -> Expression {
|
|
|
|
if v == "$it" {
|
|
|
|
Expression::Variable(Variable::It(span))
|
|
|
|
} else {
|
|
|
|
Expression::Variable(Variable::Other(v, span))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Clone, Deserialize, Serialize)]
|
|
|
|
pub enum NamedValue {
|
|
|
|
AbsentSwitch,
|
|
|
|
PresentSwitch(Span),
|
|
|
|
AbsentValue,
|
|
|
|
Value(Span, SpannedExpression),
|
|
|
|
}
|
|
|
|
|
|
|
|
impl PrettyDebugWithSource for NamedValue {
|
|
|
|
fn pretty_debug(&self, source: &str) -> DebugDocBuilder {
|
|
|
|
match self {
|
|
|
|
NamedValue::AbsentSwitch => b::typed("switch", b::description("absent")),
|
|
|
|
NamedValue::PresentSwitch(_) => b::typed("switch", b::description("present")),
|
|
|
|
NamedValue::AbsentValue => b::description("absent"),
|
|
|
|
NamedValue::Value(_, value) => value.pretty_debug(source),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn refined_pretty_debug(&self, refine: PrettyDebugRefineKind, source: &str) -> DebugDocBuilder {
|
|
|
|
match refine {
|
|
|
|
PrettyDebugRefineKind::ContextFree => self.pretty_debug(source),
|
|
|
|
PrettyDebugRefineKind::WithContext => match self {
|
|
|
|
NamedValue::AbsentSwitch => b::value("absent"),
|
|
|
|
NamedValue::PresentSwitch(_) => b::value("present"),
|
|
|
|
NamedValue::AbsentValue => b::value("absent"),
|
|
|
|
NamedValue::Value(_, value) => value.refined_pretty_debug(refine, source),
|
|
|
|
},
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Clone, Deserialize, Serialize)]
|
|
|
|
pub struct Call {
|
|
|
|
pub head: Box<SpannedExpression>,
|
|
|
|
pub positional: Option<Vec<SpannedExpression>>,
|
|
|
|
pub named: Option<NamedArguments>,
|
|
|
|
pub span: Span,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Call {
|
|
|
|
pub fn switch_preset(&self, switch: &str) -> bool {
|
|
|
|
self.named
|
|
|
|
.as_ref()
|
|
|
|
.map(|n| n.switch_present(switch))
|
|
|
|
.unwrap_or(false)
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn set_initial_flags(&mut self, signature: &nu_protocol::Signature) {
|
|
|
|
for (named, value) in signature.named.iter() {
|
|
|
|
if self.named.is_none() {
|
|
|
|
self.named = Some(NamedArguments::new());
|
|
|
|
}
|
|
|
|
|
|
|
|
if let Some(ref mut args) = self.named {
|
|
|
|
match value.0 {
|
|
|
|
nu_protocol::NamedType::Switch(_) => args.insert_switch(named, None),
|
|
|
|
_ => args.insert_optional(named, Span::new(0, 0), None),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl PrettyDebugWithSource for Call {
|
|
|
|
fn refined_pretty_debug(&self, refine: PrettyDebugRefineKind, source: &str) -> DebugDocBuilder {
|
|
|
|
match refine {
|
|
|
|
PrettyDebugRefineKind::ContextFree => self.pretty_debug(source),
|
|
|
|
PrettyDebugRefineKind::WithContext => {
|
|
|
|
self.head
|
|
|
|
.refined_pretty_debug(PrettyDebugRefineKind::WithContext, source)
|
|
|
|
+ b::preceded_option(
|
|
|
|
Some(b::space()),
|
|
|
|
self.positional.as_ref().map(|pos| {
|
|
|
|
b::intersperse(
|
|
|
|
pos.iter().map(|expr| {
|
|
|
|
expr.refined_pretty_debug(
|
|
|
|
PrettyDebugRefineKind::WithContext,
|
|
|
|
source,
|
|
|
|
)
|
|
|
|
}),
|
|
|
|
b::space(),
|
|
|
|
)
|
|
|
|
}),
|
|
|
|
)
|
|
|
|
+ b::preceded_option(
|
|
|
|
Some(b::space()),
|
|
|
|
self.named.as_ref().map(|named| {
|
|
|
|
named.refined_pretty_debug(PrettyDebugRefineKind::WithContext, source)
|
|
|
|
}),
|
|
|
|
)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn pretty_debug(&self, source: &str) -> DebugDocBuilder {
|
|
|
|
b::typed(
|
|
|
|
"call",
|
|
|
|
self.refined_pretty_debug(PrettyDebugRefineKind::WithContext, source),
|
|
|
|
)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Call {
|
|
|
|
pub fn new(head: Box<SpannedExpression>, span: Span) -> Call {
|
|
|
|
Call {
|
|
|
|
head,
|
|
|
|
positional: None,
|
|
|
|
named: None,
|
|
|
|
span,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Copy, Clone, Eq, PartialEq, Ord, PartialOrd)]
|
|
|
|
pub enum Delimiter {
|
|
|
|
Paren,
|
|
|
|
Brace,
|
|
|
|
Square,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Copy, Clone)]
|
|
|
|
pub enum FlatShape {
|
|
|
|
OpenDelimiter(Delimiter),
|
|
|
|
CloseDelimiter(Delimiter),
|
|
|
|
Type,
|
|
|
|
Identifier,
|
|
|
|
ItVariable,
|
|
|
|
Variable,
|
|
|
|
CompareOperator,
|
|
|
|
Dot,
|
|
|
|
DotDot,
|
|
|
|
InternalCommand,
|
|
|
|
ExternalCommand,
|
|
|
|
ExternalWord,
|
|
|
|
BareMember,
|
|
|
|
StringMember,
|
|
|
|
String,
|
|
|
|
Path,
|
|
|
|
Word,
|
|
|
|
Keyword,
|
|
|
|
Pipe,
|
|
|
|
GlobPattern,
|
|
|
|
Flag,
|
|
|
|
ShorthandFlag,
|
|
|
|
Int,
|
|
|
|
Decimal,
|
|
|
|
Garbage,
|
|
|
|
Whitespace,
|
|
|
|
Separator,
|
|
|
|
Comment,
|
|
|
|
Size { number: Span, unit: Span },
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Clone, Default, Deserialize, Serialize)]
|
|
|
|
pub struct NamedArguments {
|
|
|
|
pub named: IndexMap<String, NamedValue>,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl NamedArguments {
|
|
|
|
pub fn new() -> NamedArguments {
|
|
|
|
Default::default()
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn iter(&self) -> impl Iterator<Item = (&String, &NamedValue)> {
|
|
|
|
self.named.iter()
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn get(&self, name: &str) -> Option<&NamedValue> {
|
|
|
|
self.named.get(name)
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn is_empty(&self) -> bool {
|
|
|
|
self.named.is_empty()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl NamedArguments {
|
|
|
|
pub fn insert_switch(&mut self, name: impl Into<String>, switch: Option<Flag>) {
|
|
|
|
let name = name.into();
|
|
|
|
trace!("Inserting switch -- {} = {:?}", name, switch);
|
|
|
|
|
|
|
|
match switch {
|
|
|
|
None => self.named.insert(name, NamedValue::AbsentSwitch),
|
|
|
|
Some(flag) => self
|
|
|
|
.named
|
|
|
|
.insert(name, NamedValue::PresentSwitch(flag.name)),
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn insert_optional(
|
|
|
|
&mut self,
|
|
|
|
name: impl Into<String>,
|
|
|
|
flag_span: Span,
|
|
|
|
expr: Option<SpannedExpression>,
|
|
|
|
) {
|
|
|
|
match expr {
|
|
|
|
None => self.named.insert(name.into(), NamedValue::AbsentValue),
|
|
|
|
Some(expr) => self
|
|
|
|
.named
|
|
|
|
.insert(name.into(), NamedValue::Value(flag_span, expr)),
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn insert_mandatory(
|
|
|
|
&mut self,
|
|
|
|
name: impl Into<String>,
|
|
|
|
flag_span: Span,
|
|
|
|
expr: SpannedExpression,
|
|
|
|
) {
|
|
|
|
self.named
|
|
|
|
.insert(name.into(), NamedValue::Value(flag_span, expr));
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn switch_present(&self, switch: &str) -> bool {
|
|
|
|
self.named
|
|
|
|
.get(switch)
|
|
|
|
.map(|t| match t {
|
|
|
|
NamedValue::PresentSwitch(_) => true,
|
|
|
|
_ => false,
|
|
|
|
})
|
|
|
|
.unwrap_or(false)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl PrettyDebugWithSource for NamedArguments {
|
|
|
|
fn refined_pretty_debug(&self, refine: PrettyDebugRefineKind, source: &str) -> DebugDocBuilder {
|
|
|
|
match refine {
|
|
|
|
PrettyDebugRefineKind::ContextFree => self.pretty_debug(source),
|
|
|
|
PrettyDebugRefineKind::WithContext => b::intersperse(
|
|
|
|
self.named.iter().map(|(key, value)| {
|
|
|
|
b::key(key)
|
|
|
|
+ b::equals()
|
|
|
|
+ value.refined_pretty_debug(PrettyDebugRefineKind::WithContext, source)
|
|
|
|
}),
|
|
|
|
b::space(),
|
|
|
|
),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn pretty_debug(&self, source: &str) -> DebugDocBuilder {
|
|
|
|
b::delimit(
|
|
|
|
"(",
|
|
|
|
self.refined_pretty_debug(PrettyDebugRefineKind::WithContext, source),
|
|
|
|
")",
|
|
|
|
)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash)]
|
|
|
|
pub enum FlagKind {
|
|
|
|
Shorthand,
|
|
|
|
Longhand,
|
|
|
|
}
|
|
|
|
|
|
|
|
#[derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash, new)]
|
|
|
|
pub struct Flag {
|
|
|
|
pub(crate) kind: FlagKind,
|
|
|
|
pub(crate) name: Span,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl PrettyDebugWithSource for Flag {
|
|
|
|
fn pretty_debug(&self, source: &str) -> DebugDocBuilder {
|
|
|
|
let prefix = match self.kind {
|
|
|
|
FlagKind::Longhand => b::description("--"),
|
|
|
|
FlagKind::Shorthand => b::description("-"),
|
|
|
|
};
|
|
|
|
|
|
|
|
prefix + b::description(self.name.slice(source))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Flag {
|
|
|
|
pub fn color(&self, span: impl Into<Span>) -> Spanned<FlatShape> {
|
|
|
|
match self.kind {
|
|
|
|
FlagKind::Longhand => FlatShape::Flag.spanned(span.into()),
|
|
|
|
FlagKind::Shorthand => FlatShape::ShorthandFlag.spanned(span.into()),
|
|
|
|
}
|
|
|
|
}
|
2019-06-22 03:36:57 +02:00
|
|
|
}
|