Commit Graph

32 Commits

Author SHA1 Message Date
Jonathan Turner
77d856fd53
Last unwraps (#1160)
* Work through most of the last unwraps

* Finish removing unwraps
2020-01-04 19:44:17 +13:00
Jonathan Turner
72838cc083
Move to using clippy (#1142)
* Clippy fixes

* Finish converting to use clippy

* fix warnings in new master

* fix windows

* fix windows

Co-authored-by: Artem Vorotnikov <artem@vorotnikov.me>
2019-12-31 20:36:08 +13:00
Yehuda Katz
e8800fdd0c Remove the coloring_in_tokens feature flag
Stabilize and enable
2019-12-12 11:34:43 -08:00
Yehuda Katz
57af9b5040 Add Range and start Signature support
This commit contains two improvements:

- Support for a Range syntax (and a corresponding Range value)
- Work towards a signature syntax

Implementing the Range syntax resulted in cleaning up how operators in
the core syntax works. There are now two kinds of infix operators

- tight operators (`.` and `..`)
- loose operators

Tight operators may not be interspersed (`$it.left..$it.right` is a
syntax error). Loose operators require whitespace on both sides of the
operator, and can be arbitrarily interspersed. Precedence is left to
right in the core syntax.

Note that delimited syntax (like `( ... )` or `[ ... ]`) is a single
token node in the core syntax. A single token node can be parsed from
beginning to end in a context-free manner.

The rule for `.` is `<token node>.<member>`. The rule for `..` is
`<token node>..<token node>`.

Loose operators all have the same syntactic rule: `<token
node><space><loose op><space><token node>`.

The second aspect of this pull request is the beginning of support for a
signature syntax. Before implementing signatures, a necessary
prerequisite is for the core syntax to support multi-line programs.

That work establishes a few things:

- `;` and newlines are handled in the core grammar, and both count as
  "separators"
- line comments begin with `#` and continue until the end of the line

In this commit, multi-token productions in the core grammar can use
separators interchangably with spaces. However, I think we will
ultimately want a different rule preventing separators from occurring
before an infix operator, so that the end of a line is always
unambiguous. This would avoid gratuitous differences between modules and
repl usage.

We already effectively have this rule, because otherwise `x<newline> |
y` would be a single pipeline, but of course that wouldn't work.
2019-12-11 16:41:07 -08:00
Jonathan Turner
35edf22ac3 Test all subcrates 2019-12-04 19:53:06 +13:00
Jonathan Turner
871fc72892 Test all subcrates 2019-12-04 19:49:38 +13:00
Jonathan Turner
ff6026ca79 try again 2019-11-08 07:47:43 +13:00
Jonathan Turner
c6c6c0f295 try again 2019-11-08 07:44:34 +13:00
Jonathan Turner
1cca5557b1 Second attempt to remove rust-toolchain 2019-11-08 07:27:39 +13:00
Jonathan Turner
104b30142f
Move azure pipeline to stable 2019-11-08 06:13:39 +13:00
Yehuda Katz
439889dcef Feature flagging infrastructure
This commit adds the ability to work on features behind a feature flag
that won't be included in normal builds of nu.

These features are not exposed as Cargo features, as they reflect
incomplete features that are not yet stable.

To create a feature, add it to `features.toml`:

```toml
[hintsv1]

description = "Adding hints based on error states in the highlighter"
enabled = false
```

Each feature in `features.toml` becomes a feature flag accessible to `cfg`:

```rs
println!("hintsv1 is enabled");
```

By default, features are enabled based on the value of the `enabled` field.

You can also enable a feature from the command line via the
`NUSHELL_ENABLE_FLAGS` environment variable:

```sh
$ NUSHELL_ENABLE_FLAGS=hintsv1 cargo run
```

You can enable all flags via `NUSHELL_ENABLE_ALL_FLAGS`.

This commit also updates the CI setup to run the build with all flags off and
with all flags on. It also extracts the linting test into its own
parallelizable test, which means it doesn't need to run together with every
other test anymore.

When working on a feature, you should also add tests behind the same flag. A
commit is mergable if all tests pass with and without the flag, allowing
incomplete commits to land on master as long as the incomplete code builds and
passes tests.
2019-10-11 17:19:44 -07:00
Jonathan Turner
27272d3754
Update azure-pipelines.yml 2019-10-03 05:27:03 +13:00
Jonathan Turner
f689434bbc
Update azure-pipelines.yml 2019-10-03 05:06:28 +13:00
Jonathan Turner
03728c1868
Update azure-pipelines.yml 2019-10-03 04:55:29 +13:00
Jonathan Turner
ce771903e5
Trying to fix Azure Pipelines 2019-10-03 04:46:49 +13:00
Maximilian Roos
206998a41a
install correct version 2019-09-11 13:56:30 -04:00
Maximilian Roos
5ca075e38b
already installed in CI 2019-09-11 13:14:31 -04:00
Maximilian Roos
dbefbcb046
CI 2019-09-11 13:06:59 -04:00
Maximilian Roos
45201cb284
combine build & test 2019-09-09 17:04:14 -04:00
Maximilian Roos
cf2c19706e
fix build warnings & add CI 2019-09-09 06:03:01 -04:00
Jonathan Turner
acdecdbb04
Attempt to speed up CI 2019-09-01 19:33:13 +12:00
Jonathan Turner
ac15989bbb
Merge branch 'master' into surf 2019-08-25 17:41:10 +12:00
Jonathan Turner
25750f8bb0 Bump the mac image version 2019-08-25 17:39:37 +12:00
vthriller
4e59d30c83 azure-pipelines: use rust version defined in rust-toolchain file 2019-08-24 23:03:49 +03:00
est31
add48d873b We require a more recent nightly now 2019-08-24 09:25:48 +02:00
Odin Dutton
eec042d7e7 Fail the build on warnings 2019-08-20 15:02:55 +10:00
Jonathan Turner
78b056a109 Bump rustc version 2019-08-10 09:56:41 +12:00
Jonathan Turner
eefb6fd9a0 Bump rustc version. Fix macOS build issue 2019-07-14 05:32:01 +12:00
Jonathan Turner
d64da53d49
Update azure-pipelines.yml 2019-06-30 03:48:00 +12:00
Jonathan Turner
0aa42bf7af
Remove (unneeded?) parts of the pipeline 2019-06-19 06:59:34 +12:00
Jonathan Turner
ba714c3251 Set up CI with Azure Pipelines
[skip ci]
2019-06-18 18:40:37 +12:00
Jonathan Turner
358699d34e Try to add azure pipelines 2019-06-18 16:37:47 +12:00