🧠 Feature: Direct function calls #120

New Issue

deavmi · 2023-04-24T10:58:38+01:00

deavmi commented

2023-04-24 10:58:38 +01:00

What is this?

We want to add support to do:

int function()
{
	....
}

function();

Without having to do:

int function()
{
	....
}

discard function();

It is an expression and would need to be seen as such, I recommend we use some technique to detect a function call but then re-wind as effectively we just will have an expression - ensure this works out fine with code queue ordering - it may not so we may need to contain 🤔

We know that FuncCall is an expression and because of that, during the DNode processing post-linearization, it will be picked up in the section where we hoist out all the getEntity() and it is a kind-of Expression.

## What is this? We want to add support to do: ```d int function() { .... } function(); ``` Without having to do: ```d int function() { .... } discard function(); ```` It is an expression and would need to be seen as such, I recommend we use some technique to detect a function call but then re-wind as effectively we just will have an expression - **ensure this works out fine with code queue ordering** - it may not so we may need to contain 🤔 We know that `FuncCall` is an expression and because of that, during the `DNode` processing post-linearization, it will be picked up in the section where we hoist out all the `getEntity()` and it is a kind-of `Expression`.

deavmi referenced this issue

2023-04-24 10:58:45 +01:00

Conditional compilation, size_t, ssize_t, sizeof and so forth #119

deavmi added this to the Basics milestone 2023-04-24 10:58:55 +01:00

deavmi added the

parser

label 2023-04-24 10:58:59 +01:00

deavmi added this to the Parser project 2023-04-24 10:59:02 +01:00

deavmi self-assigned this 2023-04-24 10:59:05 +01:00

deavmi added reference feature/direct_func_call

2023-04-24 13:02:23 +01:00

deavmi changed title from ~~Direct function calls~~ to 🧠 Feature: Direct function calls

2023-04-24 13:02:44 +01:00

deavmi added the due date 2023-04-30

2023-04-24 16:19:33 +01:00

deavmi commented

2023-04-24 16:19:45 +01:00

I want to get this done this week - very soon.

deavmi started working 2023-04-26 10:27:51 +01:00

deavmi commented

2023-04-26 10:36:04 +01:00

I have a working implementation for this (and therefore solution). We simply have had to do the following:

parseName() never returned the actual FunctionCall in such a case
Added missing support for FunctionCall in the generalPass() in the dependency generator
The FunctionCall AST node (parser node) must have a boolean to mark whether it is statement-level or not
- This aids in the stack usage when processing it in the code generator
The generated FuncCallInstr must be marked as statement-level if its corresponding AST node FunctionCall was marked as such
The DGen code emitter now checks the FuncCallInstr to see if it is marked, if so then an additional ";" is appended to the generated emit string

This is all available now in commit 0da9af085df1c378a09d1f592c2458929e6679af.

I have a working implementation for this (and therefore solution). We simply have had to do the following: * `parseName()` never returned the actual `FunctionCall` in such a case * Added missing support for `FunctionCall` in the `generalPass()` in the dependency generator * The `FunctionCall` AST node (parser node) must have a boolean to mark whether it is statement-level or not * This aids in the stack usage when processing it in the code generator * The generated `FuncCallInstr` must be marked as statement-level if its corresponding AST node `FunctionCall` was marked as such * The `DGen` code emitter now checks the `FuncCallInstr` to see if it is marked, if so then an additional `";"` is appended to the generated `emit` string This is all available now in commit `0da9af085df1c378a09d1f592c2458929e6679af`.

deavmi commented

2023-04-26 10:36:38 +01:00