# Problem
Before this PR, our formatter reformats
```
squares_out = reduce(arr, 0, fn (i, squares) {
return 1
})
```
to
```
squares_out = reduce(arr, 0, (i, squares) {
return 1
})
```
i.e. it removes the `fn` keyword from the closure. This keyword is required, so, our formatter turned working code into invalid code.
# Cause
When this closure parameter is formatted, the ExprContext is ::Decl, so `Expr::recast` skips adding the `fn` keyword. The reason it's ::Decl is because the `squares_out = ` declaration sets it, and no subsequent call sets the context to something else.
# Solution
When recasting a call expression, set the context for every argument to `ExprContext::Other`.
* Make `=` and `=>` optional in function declarations
And requires `:` for return types
Signed-off-by: Nick Cameron <nrc@ncameron.org>
* Tests
Signed-off-by: Nick Cameron <nrc@ncameron.org>
* Format types in function decls
Signed-off-by: Nick Cameron <nrc@ncameron.org>
* Require in anon function decls
Signed-off-by: Nick Cameron <nrc@ncameron.org>
---------
Signed-off-by: Nick Cameron <nrc@ncameron.org>
Previously, this was the output of the formatter:
```
fn f = () => {
return () => {
return 1
}
}
```
Now the above will be reformatted as
```
fn f = () => {
return () => {
return 1
}
}
```
Much better!
Closes#4021
Allows array ranges (e.g., `[0..10]`) to take expression instead of just numeric literals as their start and end values. Both expressions are required (we don't support `[0..]`, etc.).
I've created a new kind of expression in the AST. The alternative was to represent the internals of an array as some kind of pattern which could initially be fully explicit or ranges. I figured the chosen version was simpler and easier to extend to open ranges, whereas the latter would be easier to extend to mixed ranges or other patterns. I chose simpler, it'll be easy enough to refactor if necessary.
Parsing is tested implicitly by the tests of execution and unparsing.
---------
Signed-off-by: Nick Cameron <nrc@ncameron.org>
Co-authored-by: Adam Chalmers <adam.chalmers@zoo.dev>
* Log any Errors to stderr
This isn't perfect -- in fact, this is maybe not even very good at all,
but it's better than what we have today.
Currently, when we get an Erorr back from the WebSocket, we drop it in
kcl-lib. The web-app logs these to the console (I can't find my commit
doing that off the top of my head, but I remember doing it) -- so this
is some degree of partity.
This won't be very useful at all for wasm usage, but it will fix issues
with the zoo cli silently breaking with a "WebSocket Closed" error --
which is the same issue I was solving for in the desktop app too.
In the future perhaps this can be a real Error? I'm not totally sure
yet, since we can't align to the request-id, so we can't really tie it
to a specific call (yet).
* add to responses
Signed-off-by: Jess Frazelle <github@jessfraz.com>
* A snapshot a day keeps the bugs away! 📷🐛 (OS: ubuntu-latest)
* add a test
Signed-off-by: Jess Frazelle <github@jessfraz.com>
* clippy[
Signed-off-by: Jess Frazelle <github@jessfraz.com>
* A snapshot a day keeps the bugs away! 📷🐛 (OS: ubuntu-latest)
* empty
* fix error
Signed-off-by: Jess Frazelle <github@jessfraz.com>
* updates tests
Signed-off-by: Jess Frazelle <github@jessfraz.com>
* docs
Signed-off-by: Jess Frazelle <github@jessfraz.com>
---------
Signed-off-by: Jess Frazelle <github@jessfraz.com>
Co-authored-by: Jess Frazelle <github@jessfraz.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Jess Frazelle <jessfraz@users.noreply.github.com>
Previously variable declaration required a keyword, e.g.
```kcl
let x = 4
const x = 4
var x = 4
```
These were all valid, and did the exact same thing. As of this PR, they're all still valid, but the KCL formatter will change them all to just:
```kcl
x = 4
```
which is the new preferred way to declare a constant.
But the formatter will remove the var/let/const keywords.
Closes https://github.com/KittyCAD/modeling-app/issues/3985
I think when we make reduce work with objects,
we'll either keep the same function and make it
polymorphic, or we'll have namespaces/modules and
use Array.reduce and Object.reduce. Either way this
name can be changed.
