mirror of https://github.com/tbklang/tlang.git
Function return statement #7
Labels
No Label
dependency
emit
hashmapper
lebanonmapper
lexer
meta
needsfix
parser
qol
question
resolution
typing
No Milestone
No project
No Assignees
1 Participants
Notifications
Total Time Spent: 2 hours 5 minutes
Due Date
deavmi
2 hours 5 minutes
Blocks
#42 Function definitions
tlang/tlang
Reference: tlang/tlang#7
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Add support for function
return
statements.return
transform()
implementationdeavmi referenced this issue2022-10-15 20:58:40 +01:00
parserto vardec_varass_dependencyI should actually get this done today.
I lied to myself 💀
Function return statements being worked on now
Emmiting ✅
I have now done the following:
ReturnInstruction
which embeds the epxresiosn instruction, so it can be pulled out by the emitter later and we can do the following:Dependency ✅
We have the following added to
generalPass(Container, Context)
now:Data (Parser nodes) ✅
We have added a parser node
ReturnStmt
(this has been here for some time but we needed to actually weight it with a weight above the default of0
- which actually misplaced it above variable declarations (Variable
).This should technically have same weighting as Variable as it is a statement. We only really use weighting to re-order definitions like types etc., but we should keepo this as
2
for the following reason:We don't want the code:
To re-order
return
to the bottom, no infact, we should be analysing the body of the parse tree ingeneralPass()
(when analysing function definition) and ensuring that this statement actually appears only ad the end of the funciton).❗ SO yes, this should be kept with weighting of
2
on par I think, we want that order to remain - even if syntactically incorrect (i.e. a return statement must be the last statement in a function's body). As for finding issue with it, that is an aesthetic issue for #59 I think.CodeGen ✅
No typechecking yet, but we do the following in order to pop the expression
Value
instruction that was on the stackcodeQueue
(scratchpad) and then we embed it into theReturnInstruction
and tack that on to the back of thecodeQueue
(scratchpad).😊 We also don't forget to set the context hun 💅 ✨ :
Typechecking is outstanding
Type checking is oustanding But will be handled from #61
All that is left is semantic analysis, which shouldn't be too hard
Tests run and corerct values arise from the
return
statement insimple_functions.t
on commitd1b3319a74efc4ed37c6b492a5d374f93e3f3e74
onvardec_varass_dependency
branch.Return statements are now implemented