tlang/tlang
tlang
/
tlang
mirror of https://github.com/tbklang/tlang.git
2
0
Fork 0
Code Issues 43 Projects 5 Releases Wiki Activity

🐞️ Functions: Expressionless return and enforcing requirement #113

New Issue
Closed
opened 2023-04-21 07:52:43 +01:00 by deavmi · 20 comments
deavmi commented 2023-04-21 07:52:43 +01:00
Owner
Copy Link

Bugfix 🐞️: Expressionless return

Allow a return without an expression:

  • Must be allowed at the parser level
  • Dependency generation must check if an expression exists and only then proceed, else we call expressionPass(null) (on null)
  • Typechecking, we must match function's return type with the type of the return instruction generated and if there is a void type then no expression can be present
  • Typechecking enforce it be present in non-void function declarations
  • Should only be allowed in a function, see where we should do this
    • Solution1: Could be done in the parser technically but I feel that would require us to check anything that has a parseBody() call in it and that feels wrong.
    • Solution 2: We could specifically check, when processing the ReturnStmt in the typechecker/code gen what it's parentOf is and then that would allow us, for ANY return statement to ensure it is in a Container that is a Function only
    • Update: Regarding this it only complains actually when not in parseBody(), I don't have an example fo wehere we use parseBody() in a non-function, thereore so far having such a check wouldn't matter actually. I don't necessarily feels as though this is bad because if for some reason we did come up with some structure that used parseBody() but would not allow return in it then this would be a good way to check for it.
  • Enforce that a function of a non-void type MUST have a return expression.
    • This can be done in the parser when we check for the stuff we do in #112
## Bugfix 🐞️: Expressionless `return` Allow a `return` without an expression: - [x] Must be allowed at the parser level - [x] Dependency generation must check if an expression exists and only then proceed, else we call `expressionPass(null)` (on null) - [x] Typechecking, we must match function's return type with the type of the return instruction generated and if there is a `void` type then no expression can be present - [x] Typechecking enforce it be present in non-`void` function declarations - [x] Should only be allowed in a function, see where we should do this * **Solution1:** Could be done in the parser technically but I feel that would require us to check anything that has a `parseBody()` call in it and that feels wrong. * **Solution 2:** We could specifically check, when processing the `ReturnStmt` in the typechecker/code gen what it's `parentOf` is and then that would allow us, for ANY `return` statement to ensure it is in a `Container` that is a `Function` only * **Update:** Regarding this it only complains actually when not in `parseBody()`, I don't have an example fo wehere we use `parseBody()` in a non-function, thereore so far having such a check wouldn't matter actually. I don't necessarily feels as though this is bad because if for some reason we _did_ come up with some structure that used `parseBody()` but would not allow `return` in it then this would be a good way to check for it. - [x] Enforce that a function of a non-void type MUST have a `return` expression. * This can be done in the parser when we check for the stuff we do in #112
deavmi added the
typing
parser
 labels 2023-04-21 07:54:09 +01:00
deavmi self-assigned this 2023-04-21 07:54:12 +01:00
deavmi added this to the Dependency tree, type-checking and codegen project 2023-04-21 07:54:15 +01:00
deavmi added this to the Basics milestone 2023-04-21 07:54:18 +01:00
deavmi added the due date 2023-04-21 2023-04-21 07:54:23 +01:00
deavmi started working 2023-04-21 07:54:24 +01:00
deavmi added reference bugfix/return_type 2023-04-21 07:55:20 +01:00
deavmi added the
dependency
 label 2023-04-21 08:06:32 +01:00
deavmi commented 2023-04-21 08:08:52 +01:00
Author
Owner
Copy Link

As of commit 4facc5a3f0f32eae1a5fe8c1e0a3809e4cfddf49 we have added support for expressionless returns in the parser and CI/CD checks out ✅

As of commit `4facc5a3f0f32eae1a5fe8c1e0a3809e4cfddf49` we have added support for expressionless returns in the parser and CI/CD checks out ✅
deavmi stopped working 2023-04-21 08:09:02 +01:00
14 minutes 38 seconds
deavmi started working 2023-04-21 08:26:29 +01:00
deavmi commented 2023-04-21 08:31:38 +01:00
Author
Owner
Copy Link

As of commit 98f6c03d22457b63f1998b3c9056a05a587e72f2 we have added a check in the dependency generator to only do expressionPass() when the ReturnStmt has an expression.

Running typecheck test in CI passes ✅ , so this is good

As of commit `98f6c03d22457b63f1998b3c9056a05a587e72f2` we have added a check in the dependency generator to only do `expressionPass()` when the `ReturnStmt` has an expression. Running `typecheck` test in CI passes ✅ , so this is good
deavmi stopped working 2023-04-21 08:31:44 +01:00
5 minutes 15 seconds
deavmi added a new dependency 2023-04-21 09:06:45 +01:00
#112 🐞️ Functions: Return position
deavmi added a new dependency 2023-04-21 14:11:52 +01:00
#114 🐞️ isSameType: Add a base case
deavmi commented 2023-04-21 14:30:50 +01:00
Author
Owner
Copy Link

Going to bring this branch's base up-to-date.

Going to bring this branch's base up-to-date.
deavmi commented 2023-04-21 14:36:49 +01:00
Author
Owner
Copy Link

Going to bring this branch's base up-to-date.

Done and CI fails where it normally did ✅

> Going to bring this branch's base up-to-date. Done and CI fails where it normally did ✅
deavmi added a new dependency 2023-04-21 14:37:01 +01:00
#115 🧠️ Feature: Universal coercion and type enforcer
deavmi commented 2023-04-21 14:37:22 +01:00
Author
Owner
Copy Link

Not continueing this until I get universal coercion working as that makes sense to do rather than coerce everywhere where I could.

Not continueing this until I get universal coercion working as that makes sense to do rather than coerce everywhere where I could.
deavmi started working 2023-07-11 20:14:42 +01:00
deavmi commented 2023-07-11 20:16:06 +01:00
Author
Owner
Copy Link

Taking a look at this again...

Taking a look at this again...
deavmi commented 2023-07-11 20:33:53 +01:00
Author
Owner
Copy Link

Looks good to me

Looks good to me
deavmi commented 2023-07-11 20:38:05 +01:00
Author
Owner
Copy Link

Fixed merge conflict 👍

Fixed merge conflict 👍
deavmi commented 2023-07-11 20:42:12 +01:00
Author
Owner
Copy Link

Awaiting CI/CD...

Awaiting CI/CD...
deavmi stopped working 2023-07-11 21:45:45 +01:00
1 hour 31 minutes
deavmi changed reference from bugfix/return_type to vardec_varass_dependency 2023-07-12 08:56:49 +01:00
deavmi changed reference from vardec_varass_dependency to vardec_varass_dependency 2023-07-12 08:58:13 +01:00
deavmi added spent time 2023-07-12 08:58:20 +01:00
10 minutes
deavmi started working 2023-07-12 08:58:22 +01:00
deavmi commented 2023-07-12 08:58:50 +01:00
Author
Owner
Copy Link

Fixed the lookup of the ReturnStmt's nearest Function-based Container.

Fixed the lookup of the `ReturnStmt`'s nearest `Function`-based `Container`.
deavmi modified the due date from 2023-04-21 to 2023-07-12 2023-07-12 09:02:33 +01:00
deavmi modified the due date from 2023-07-12 to 2023-07-30 2023-07-12 09:02:37 +01:00
deavmi commented 2023-07-12 09:02:57 +01:00
Author
Owner
Copy Link

This will now continue on the feature/universal_coercion branch so I can do the type checking part.

This will now continue on the `feature/universal_coercion` branch so I can do the type checking part.
deavmi changed reference from vardec_varass_dependency to feature/universal_coercion 2023-07-12 09:04:09 +01:00
deavmi commented 2023-07-12 09:04:18 +01:00
Author
Owner
Copy Link

This will now continue on the feature/universal_coercion branch so I can do the type checking part.

Working on merge conflicts now...

> This will now continue on the `feature/universal_coercion` branch so I can do the type checking part. Working on merge conflicts now...
deavmi commented 2023-07-12 09:07:22 +01:00
Author
Owner
Copy Link

This will now continue on the feature/universal_coercion branch so I can do the type checking part.

Working on merge conflicts now...

Merged 👍

Added a TODO where the type enforcement needs to go

> > This will now continue on the `feature/universal_coercion` branch so I can do the type checking part. > > Working on merge conflicts now... Merged 👍 Added a TODO where the type enforcement needs to go
deavmi stopped working 2023-07-12 09:08:37 +01:00
10 minutes 15 seconds
deavmi started working 2023-07-12 09:59:58 +01:00
deavmi commented 2023-07-12 10:00:30 +01:00
Author
Owner
Copy Link

Type enforcement added in commit 0a4cec2013d932c7b4e33a8a7508002047f94db4 on the feature/universal_coercion branch

Type enforcement added in commit `0a4cec2013d932c7b4e33a8a7508002047f94db4` on the `feature/universal_coercion` branch
deavmi commented 2023-07-12 10:02:22 +01:00
Author
Owner
Copy Link

Initial CI/CD all green ✅

Initial CI/CD all green ✅
deavmi commented 2023-07-12 10:04:08 +01:00
Author
Owner
Copy Link

Added two new test cases:

  1. simple_function_return_type_check_bad.t
    • Good failer
  2. simple_function_return_type_check_good.t
    • Good passer

In commit dd66d2e47e6910bc10634f9a26814a97c7fcf830 in branch as above 2nd last comment to this one

Added two new test cases: 1. `simple_function_return_type_check_bad.t` * Good failer 2. `simple_function_return_type_check_good.t` * Good passer In commit `dd66d2e47e6910bc10634f9a26814a97c7fcf830` in branch as above 2nd last comment to this one
deavmi commented 2023-07-12 10:04:55 +01:00
Author
Owner
Copy Link

Added two new test cases:

  1. simple_function_return_type_check_bad.t
    * Good failer
  2. simple_function_return_type_check_good.t
    * Good passer

In commit dd66d2e47e6910bc10634f9a26814a97c7fcf830 in branch as above 2nd last comment to this one

CI/CD all good ✅

> Added two new test cases: > > 1. `simple_function_return_type_check_bad.t` > * Good failer > 2. `simple_function_return_type_check_good.t` > * Good passer > > In commit `dd66d2e47e6910bc10634f9a26814a97c7fcf830` in branch as above 2nd last comment to this one CI/CD all good ✅
deavmi commented 2023-07-12 10:05:10 +01:00
Author
Owner
Copy Link

Bugfix 🐞️: Expressionless return

Allow a return without an expression:

  • Must be allowed at the parser level
  • Dependency generation must check if an expression exists and only then proceed, else we call expressionPass(null) (on null)
  • Typechecking, we must match function's return type with the type of the return instruction generated and if there is a void type then no expression can be present
  • Typechecking enforce it be present in non-void function declarations
  • Should only be allowed in a function, see where we should do this
    • Solution1: Could be done in the parser technically but I feel that would require us to check anything that has a parseBody() call in it and that feels wrong.
    • Solution 2: We could specifically check, when processing the ReturnStmt in the typechecker/code gen what it's parentOf is and then that would allow us, for ANY return statement to ensure it is in a Container that is a Function only
    • Update: Regarding this it only complains actually when not in parseBody(), I don't have an example fo wehere we use parseBody() in a non-function, thereore so far having such a check wouldn't matter actually. I don't necessarily feels as though this is bad because if for some reason we did come up with some structure that used parseBody() but would not allow return in it then this would be a good way to check for it.
  • Enforce that a function of a non-void type MUST have a return expression.
    • This can be done in the parser when we check for the stuff we do in #112

Last bullet point that I need to look at now

> ## Bugfix 🐞️: Expressionless `return` > > Allow a `return` without an expression: > > - [x] Must be allowed at the parser level > - [x] Dependency generation must check if an expression exists and only then proceed, else we call `expressionPass(null)` (on null) > - [x] Typechecking, we must match function's return type with the type of the return instruction generated and if there is a `void` type then no expression can be present > - [x] Typechecking enforce it be present in non-`void` function declarations > - [ ] Should only be allowed in a function, see where we should do this > * **Solution1:** Could be done in the parser technically but I feel that would require us to check anything that has a `parseBody()` call in it and that feels wrong. > * **Solution 2:** We could specifically check, when processing the `ReturnStmt` in the typechecker/code gen what it's `parentOf` is and then that would allow us, for ANY `return` statement to ensure it is in a `Container` that is a `Function` only > * **Update:** Regarding this it only complains actually when not in `parseBody()`, I don't have an example fo wehere we use `parseBody()` in a non-function, thereore so far having such a check wouldn't matter actually. I don't necessarily feels as though this is bad because if for some reason we _did_ come up with some structure that used `parseBody()` but would not allow `return` in it then this would be a good way to check for it. > - [x] Enforce that a function of a non-void type MUST have a `return` expression. > * This can be done in the parser when we check for the stuff we do in #112 > Last bullet point that I need to look at now
deavmi stopped working 2023-07-12 10:05:19 +01:00
5 minutes 21 seconds
deavmi modified the due date from 2023-07-30 to 2023-07-15 2023-07-12 10:08:57 +01:00
deavmi commented 2023-07-13 12:28:46 +01:00
Author
Owner
Copy Link

Bugfix 🐞️: Expressionless return

Allow a return without an expression:

  • Must be allowed at the parser level
  • Dependency generation must check if an expression exists and only then proceed, else we call expressionPass(null) (on null)
  • Typechecking, we must match function's return type with the type of the return instruction generated and if there is a void type then no expression can be present
  • Typechecking enforce it be present in non-void function declarations
  • Should only be allowed in a function, see where we should do this
    • Solution1: Could be done in the parser technically but I feel that would require us to check anything that has a parseBody() call in it and that feels wrong.
    • Solution 2: We could specifically check, when processing the ReturnStmt in the typechecker/code gen what it's parentOf is and then that would allow us, for ANY return statement to ensure it is in a Container that is a Function only
    • Update: Regarding this it only complains actually when not in parseBody(), I don't have an example fo wehere we use parseBody() in a non-function, thereore so far having such a check wouldn't matter actually. I don't necessarily feels as though this is bad because if for some reason we did come up with some structure that used parseBody() but would not allow return in it then this would be a good way to check for it.
  • Enforce that a function of a non-void type MUST have a return expression.
    • This can be done in the parser when we check for the stuff we do in #112

Last bullet point that I need to look at now

Accounted for via:

if(!funcContainer)
{
	throw new TypeCheckerException(this, TypeCheckerException.TypecheckError.GENERAL_ERROR, "A return statement can only appear in the body of a function");
}
> > ## Bugfix 🐞️: Expressionless `return` > > > > Allow a `return` without an expression: > > > > - [x] Must be allowed at the parser level > > - [x] Dependency generation must check if an expression exists and only then proceed, else we call `expressionPass(null)` (on null) > > - [x] Typechecking, we must match function's return type with the type of the return instruction generated and if there is a `void` type then no expression can be present > > - [x] Typechecking enforce it be present in non-`void` function declarations > > - [ ] Should only be allowed in a function, see where we should do this > > * **Solution1:** Could be done in the parser technically but I feel that would require us to check anything that has a `parseBody()` call in it and that feels wrong. > > * **Solution 2:** We could specifically check, when processing the `ReturnStmt` in the typechecker/code gen what it's `parentOf` is and then that would allow us, for ANY `return` statement to ensure it is in a `Container` that is a `Function` only > > * **Update:** Regarding this it only complains actually when not in `parseBody()`, I don't have an example fo wehere we use `parseBody()` in a non-function, thereore so far having such a check wouldn't matter actually. I don't necessarily feels as though this is bad because if for some reason we _did_ come up with some structure that used `parseBody()` but would not allow `return` in it then this would be a good way to check for it. > > - [x] Enforce that a function of a non-void type MUST have a `return` expression. > > * This can be done in the parser when we check for the stuff we do in #112 > > > > Last bullet point that I need to look at now Accounted for via: ```d if(!funcContainer) { throw new TypeCheckerException(this, TypeCheckerException.TypecheckError.GENERAL_ERROR, "A return statement can only appear in the body of a function"); } ```
deavmi started working 2023-07-13 12:28:50 +01:00
deavmi commented 2023-07-13 12:34:27 +01:00
Author
Owner
Copy Link

Bugfix 🐞️: Expressionless return

Allow a return without an expression:

  • Must be allowed at the parser level
  • Dependency generation must check if an expression exists and only then proceed, else we call expressionPass(null) (on null)
  • Typechecking, we must match function's return type with the type of the return instruction generated and if there is a void type then no expression can be present
  • Typechecking enforce it be present in non-void function declarations
  • Should only be allowed in a function, see where we should do this
    • Solution1: Could be done in the parser technically but I feel that would require us to check anything that has a parseBody() call in it and that feels wrong.
    • Solution 2: We could specifically check, when processing the ReturnStmt in the typechecker/code gen what it's parentOf is and then that would allow us, for ANY return statement to ensure it is in a Container that is a Function only
    • Update: Regarding this it only complains actually when not in parseBody(), I don't have an example fo wehere we use parseBody() in a non-function, thereore so far having such a check wouldn't matter actually. I don't necessarily feels as though this is bad because if for some reason we did come up with some structure that used parseBody() but would not allow return in it then this would be a good way to check for it.
  • Enforce that a function of a non-void type MUST have a return expression.
    • This can be done in the parser when we check for the stuff we do in #112

Last bullet point that I need to look at now

Accounted for via:

if(!funcContainer)
{
	throw new TypeCheckerException(this, TypeCheckerException.TypecheckError.GENERAL_ERROR, "A return statement can only appear in the body of a function");
}

All done on commit b01ff34daadcdc53c43d650500f3ebb9a9cc0457

CI/CD :chec

> > > ## Bugfix 🐞️: Expressionless `return` > > > > > > Allow a `return` without an expression: > > > > > > - [x] Must be allowed at the parser level > > > - [x] Dependency generation must check if an expression exists and only then proceed, else we call `expressionPass(null)` (on null) > > > - [x] Typechecking, we must match function's return type with the type of the return instruction generated and if there is a `void` type then no expression can be present > > > - [x] Typechecking enforce it be present in non-`void` function declarations > > > - [ ] Should only be allowed in a function, see where we should do this > > > * **Solution1:** Could be done in the parser technically but I feel that would require us to check anything that has a `parseBody()` call in it and that feels wrong. > > > * **Solution 2:** We could specifically check, when processing the `ReturnStmt` in the typechecker/code gen what it's `parentOf` is and then that would allow us, for ANY `return` statement to ensure it is in a `Container` that is a `Function` only > > > * **Update:** Regarding this it only complains actually when not in `parseBody()`, I don't have an example fo wehere we use `parseBody()` in a non-function, thereore so far having such a check wouldn't matter actually. I don't necessarily feels as though this is bad because if for some reason we _did_ come up with some structure that used `parseBody()` but would not allow `return` in it then this would be a good way to check for it. > > > - [x] Enforce that a function of a non-void type MUST have a `return` expression. > > > * This can be done in the parser when we check for the stuff we do in #112 > > > > > > > Last bullet point that I need to look at now > > Accounted for via: > > ```d > if(!funcContainer) > { > throw new TypeCheckerException(this, TypeCheckerException.TypecheckError.GENERAL_ERROR, "A return statement can only appear in the body of a function"); > } > ``` All done on commit `b01ff34daadcdc53c43d650500f3ebb9a9cc0457` CI/CD :chec
deavmi stopped working 2023-07-13 12:34:43 +01:00
5 minutes 53 seconds
deavmi removed a dependency 2023-07-13 12:34:53 +01:00
#115 🧠️ Feature: Universal coercion and type enforcer
Sign in to join this conversation.
feature/universal_coercion
Branches Tags
Clear current reference
master
vardec_varass_dependency
feature/comments
feature/reporting
bugfix/single_line_comment_bug
feature/logging_upgrade
feature/multi_module
feature/unused_vars_detection
feature/container_methods
feature/strat_resolve_collectors
feature/predicate_based_resolver
feature/modifiers
feature/operator_precedence
feature/poolmngr
hotfix/func_defs_in_dep_generator
feature/lexer_improvements
feature/structs
feature/behavec_preinline
bugfix/fix_multi_compile
feature/annotations
hotfix/simply_varexp_dnode_generation
hotfix/jcli_upgrade_fix
feature/class_static_init
feature/universal_coercion
feature/cloneability
hotfix/expect_exception_change
bugfix/recursive_return_statement_check
bugfix/require_return
bugfix/return_type
feature/cleanup1
feature/clean_lexer_interface
research/gmalloc
feature/type_enforcer_cast_instr_emit
feature/meta_programming
feature/direct_func_call
bugfix/return_position
bugfix/is_same_type_fallback
feature/lexer_interface
feature/parser_interface
arrays
pointers
bugfix/function_parameter_type_parse
casting
compiler_object
extern_symbols
literal_encodings
uniform_stdalone_varass
remove_typequeue
linearizer_cleanup
parsetypedev_fix
modules
loops
conditionals
vdva_func_param_merge
function_parameters_fix
path_dependency
function_dep
compiler_levels
parser
constants
constants_float
develop
typecheck
deps_refactor
codegen
lexer
typecheck_refactor_varexp_makeacyclic
weighting
testing_thing
typecheck_refactor_varexp
typecheck_refactor
type_check_codegen_reducedparseclass_excep
typecheck_codegen
typecheck_codegen_educedparseclass
typecheck_reliancetree
static_support
codegen.sync-conflict-20210606-150925-O3W7KWN
develop.sync-conflict-20210606-150924-O3W7KWN
struct_support
typecheck.sync-conflict-20210606-150925-O3W7KWN
entity_declaration_type_checking
symbol_table
parser.sync-conflict-20210405-185821-O3W7KWN
parser_exception_before
develop_before_lexer_parser_merge_parseName
if_statement_parsing
exception_except
expression_parsing
master.sync-conflict-20210316-165421-O3W7KWN
expression_parsing.sync-conflict-20210316-090018-O3W7KWN
Clear current reference
multimodule/changeset2
multimodule/changeset1
pointer_cast_merge
parsetypeddeclaration_onlytype_parsecast_new
pointers_coerce
v0.5.3
v0.5.2
v0.5.1
v0.5.0
v0.4.4
v0.4.3
v0.4.2
v0.4.1
v0.4.0
v0.3.0
v0.2.0
v0.1.0
v0.0.5
v0.0.4
v0.0.3
v0.0.2
v0.0.1
Labels
Clear labels   
dependency

Dependency tree generation

  
emit

Code emitting

  
hashmapper

Anything pertaining to the HashMapper symbol mapping code

  
lebanonmapper

Anything pertaining to the LebanonMapper symbol mapping code

  
lexer

Related to the tokenizer

  
meta

Meta processor related

  
needsfix

Urgent fix required

  
parser

Parser related

  
qol

Quality-of-life related

  
question

A question, not needed fix

  
resolution

Related to the resolver

  
typing

TypeChecker and Resolver related

No Label
dependency
emit
hashmapper
lebanonmapper
lexer
meta
needsfix
parser
qol
question
resolution
typing
Milestone
Clear milestone
No items
No Milestone
Basics
Projects
Clear projects
No project
Dependency tree, type-checking and codegen
Assignees
Clear assignees
No Assignees
deavmi
1 Participants
Notifications
Total Time Spent: 2 hours 22 minutes
deavmi
2 hours 22 minutes
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

2023-07-15

Depends on
#114 🐞️ isSameType: Add a base case
tlang/tlang
You do not have permission to read 1 dependency
Reference: tlang/tlang#113
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?