Bare words now represent literal file names, and globs are a different
syntax shape called "Pattern". This allows commands like `cp` to ask for
a pattern as a source and a literal file as a target.
This also means that attempting to pass a glob to a command that expects
a literal path will produce an error.
Previously, there was a single parsing rule for "bare words" that
applied to both internal and external commands.
This meant that, because `cargo +nightly` needed to work, we needed to
add `+` as a valid character in bare words.
The number of characters continued to grow, and the situation was
becoming untenable. The current strategy would eventually eat up all
syntax and make it impossible to add syntax like `@foo` to internal
commands.
This patch significantly restricts bare words and introduces a new token
type (`ExternalWord`). An `ExternalWord` expands to an error in the
internal syntax, but expands to a bare word in the external syntax.
`ExternalWords` are highlighted in grey in the shell.
Fixes#627
Fixes a regression caused by #579, specifically commit cc8872b4ee .
The code was intended to perform a comparison between the wanted
output type and "Tagged<Value>" in order to be able to provide a
special-cased path for Tagged<Value>. When I wrote the code, I
used "name" as a variable name and only later realized that it
shadowed the "name" param to the function, so I renamed it to
type_name, but forgot to change the comparison.
This broke the special-casing, as the name param only contains
the name of the struct without generics (like "Tagged"), while
`std::any::type_name` (in the current implementation) contains
the full paths of the struct including all generic params
(like "nu::object::meta::Tagged<nu::object::base::Value>").
At the moment the pipeline parser does not enforce
that there must be a pipe between each part of the pipeline,
which can lead to confusing behaviour or misleading errors.
This commit migrates Value's numeric types to BigInt and BigDecimal. The
basic idea is that overflow errors aren't great in a shell environment,
and not really necessary.
The main immediate consequence is that new errors can occur when
serializing Nu values to other formats. You can see this in changes to
the various serialization formats (JSON, TOML, etc.). There's a new
`CoerceInto` trait that uses the `ToPrimitive` trait from `num_traits`
to attempt to coerce a `BigNum` or `BigDecimal` into a target type, and
produces a `RangeError` (kind of `ShellError`) if the coercion fails.
Another possible future consequence is that certain performance-critical
numeric operations might be too slow. If that happens, we can introduce
specialized numeric types to help improve the performance of those
situations, based on the real-world experience.
This commit migrates Value's numeric types to BigInt and BigDecimal. The
basic idea is that overflow errors aren't great in a shell environment,
and not really necessary.
The main immediate consequence is that new errors can occur when
serializing Nu values to other formats. You can see this in changes to
the various serialization formats (JSON, TOML, etc.). There's a new
`CoerceInto` trait that uses the `ToPrimitive` trait from `num_traits`
to attempt to coerce a `BigNum` or `BigDecimal` into a target type, and
produces a `RangeError` (kind of `ShellError`) if the coercion fails.
Another possible future consequence is that certain performance-critical
numeric operations might be too slow. If that happens, we can introduce
specialized numeric types to help improve the performance of those
situations, based on the real-world experience.
with the `help` command to explore and list all commands available.
Enter will also try to see if the location to be entered is an existing
Nu command, if it is it will let you inspect the command under `help`.
This provides baseline needed so we can iterate on it.
This commit is more substantial than it looks: there was basically no
real support for decimals before, and that impacted values all the way
through.
I also made Size contain a decimal instead of an integer (`1.6kb` is a
reasonable thing to type), which impacted a bunch of code.
The biggest impact of this commit is that it creates many more possible
ways for valid nu types to fail to serialize as toml, json, etc. which
typically can't support the full range of Decimal (or Bigint, which I
also think we should support). This commit makes to-toml fallible, and a
similar effort is necessary for the rest of the serializations.
We also need to figure out how to clearly communicate to users what has
happened, but failing to serialize to toml seems clearly superior to me
than weird errors in basic math operations.
