400 response for higher order functions
nikita-fuchs opened this issue · comments
Hey, when doing
entrypoint a_function(test : (int) => int ) : (int) => int =
test
I'm getting 400 from https://latest.compiler.aepps.com/aci instead of a proper response / error message, whereas the compiler itself properly complains.
Does that reproduce on updated local service?
It does not reproduce...
$ make docker
Using default tag: latest
latest: Pulling from aeternity/builder
4007a89234b4: Pull complete
5dfa26c6b9c9: Pull complete
...
$ docker run -p 3080:3080 -it aeternity/aesophia_http:local
...
And then in a different shell:
$ CONTRACT="contract C = entrypoint a_function(test : (int) => int ) : (int) => int = test"
$ curl -v -H "Content-Type: application/json" -d "{\"code\":\"$CONTRACT\",\"options\":{\"backend\":\"fate\"}}" -X POST http://localhost:3080/compile
...
< HTTP/1.1 400 Bad Request
< content-length: 178
< content-type: application/json
< date: Thu, 29 Apr 2021 14:07:28 GMT
< server: Cowboy
<
* Connection #0 to host localhost left intact
[{"message":"The argument\n test : (int) => int\nof entrypoint 'a_function' has a higher-order (contains function types) type.\n","pos":{"col":25,"line":2},"type":"code_error"}]
So works exactly as it should as far as I can tell?
Maybe the hosted http interface is outdated?
@hanssv /compile is not the culprit here, /aci is what's struggling
The /aci endpoint won't compile the (stub-)contract so of course it will not report an error?
Neither will the compiler BTW:
$ ./aesophia_cli --create_json_aci /tmp/bar.aes
[{"contract":{"functions":[{"arguments":[{"name":"test","type":{"function":{"arguments":["int"],"returns":"int"}}}],"name":"a_function","payable":false,"returns":{"function":{"arguments":["int"],"returns":"int"}},"stateful":false}],"name":"C","payable":false,"type_defs":[]}}]
I took a look again, getting a 200now. The errors I'm fetching for aestudio come from https://latest.compiler.aepps.com/aci , and it returns errors, like
[{"message":"Unexpected identifier x.\n","pos":{"col":12,"line":12},"type":"parse_error"}]
Right now, for a contract containing a higher order function, it just returns me a "semi-correct" ACI although the higher order function is not allowed when compiling.
E.g.
entrypoint a_function(test : (int) => int ) : (int) => int =
test
gives an ACI:
"name":"a_function",
"payable":false,
"returns":{
"function":{
"arguments":[
"int"
],
"returns":"int"
}
},
"stateful":false
Although it should be throwing an error.
There is a difference between a parse error and a code error.
It was super duper important that ACI generation was fast (and could be done for stubs)... Go figure. Can't have the cake and eat it.
Most reasonable flows would include compiling the contract first though (like before you try to create it...) and generating ACI (for calling it) only later (and for correctly compiling contracts).
Can't recall importance for fast ACI generation as it's only really needed for after deployment as you correctly pointed out. The only thing having to be fast is something that returns the errors. Currently, the /compile endpoint is called only upon contract deployment. Assuming that endpoint returns a bigger set of error messages formatted the same way as the aestudio is now used to from the /aci endpoint, we could just change ae studio to speak to /compile for dev-time error reporting in the side bar and that's it ?
Hehe, people tend to forget their imagined important requirements :-)
Yes, /compile will provide a (much) bigger set of errors, and according to the spec they should be formatted in the same way.
🤷♂️
will try /compile then.