Handle closures that are invalid for Aleo. #28417
Conversation
mikebenfield
force-pushed
the
empty-closure
branch
3 times, most recently
from
0f818b0 to
5cadd8c
Compare
In particular, 1. Insert a dummy instruction for empty closures and finalizers. SnarkVM won't parse these with no instructions. 2. Give an error for Leo functions with no parameters (rather than just generating an invalid Aleo closure). Fixes #28401
mikebenfield
force-pushed
the
empty-closure
branch
from
5cadd8c to
0a5a698
Compare
|
I made the error into a compiler error as you suggested; that makes a little more sense. One other change to note: previously async functions with no body gave an error during typechecking. I've removed this error, and instead they now also have a dummy instruction inserted. My thinking for this is that in principle dead code elimination could remove all the code a user wrote, so we have to be able to handle the empty function case anyway. But let me know if you prefer otherwise. |
|
Do you have an opinion on issuing a warning to the user, whenever a dummy instruction is inserted? |
|
I lean towards thinking we shouldn't. Other programming languages treat empty functions as a normal thing that doesn't need to be warned about, and why would Leo need to be different? But it's not a very strong preference. What do you think? |
|
I'm in agreement. If users are conscious about their emitted code, then it is available to them. |
In particular,
Insert a dummy instruction for empty closures. SnarkVM won't parse closures with no instructions.
Give a parse error for Leo functions with no parameters (rather than just generating
an invalid Aleo closure).
Fixes #28401