⚡ Feature: Support for access modifiers, init scope #165

New Issue

deavmi · 2024-02-29T16:31:47Z

deavmi commented

2024-02-29 16:31:47 +00:00

Purpose ✍️

To add support for public, private, protected, static etc. to the following:

Parser
- To add parsing support
- Class modifiers
- Function declarations
  - AccMods
  - InitScopes
- Variable delcrations
  - AccMods
  - InitScopes
- Struct type declarations
  - AccMods
  - InitScopes
- InitScopes will only be valid in certain places, so we must make that a potential optional argument or something only in places where it could potentially be applied
- Added unittest
TypeChecker/Dependency generation
- To see if access is allowed
DGen
- For generating exports (only make sense when #157 is completed)
- Find out why stuff isn't working for the multi-module test case
- Make depenedency generator complain when accessing something not visible
- Highly configurable and automatic access checking API

# Purpose ✍️ To add support for `public`, `private`, `protected`, `static` etc. to the following: - [ ] `Parser` * To add parsing support - [x] Class modifiers - [x] Function declarations - [x] AccMods - [x] InitScopes - [x] Variable delcrations - [x] AccMods - [x] InitScopes - [x] Struct type declarations - [x] AccMods - [x] InitScopes * `InitScope`s will only be valid in certain places, so we must make that a potential optional argument or something only in places where it _could_ potentially be applied - [x] Added unittest - [ ] `TypeChecker`/Dependency generation * To see if access is allowed - [ ] `DGen` * For generating exports (only make sense when #157 is completed) - [x] Find out why stuff isn't working for the multi-module test case - [ ] Make depenedency generator complain when accessing something not visible - [ ] Highly configurable and automatic access checking API

deavmi added reference feature/modifiers

2024-02-29 16:31:51 +00:00

deavmi self-assigned this 2024-02-29 16:31:53 +00:00

deavmi added spent time 2024-02-29 16:31:59 +00:00

34 minutes

deavmi started working 2024-02-29 16:32:01 +00:00

deavmi added the due date 2024-04-04

2024-02-29 16:32:06 +00:00

deavmi added the

parser

label 2024-02-29 16:32:12 +00:00

deavmi added this to the Parser project 2024-02-29 16:32:15 +00:00

deavmi added this to the Basics milestone 2024-02-29 16:32:17 +00:00

deavmi commented

2024-02-29 16:39:30 +00:00

Added the required functions for managing the ModifierItem queue. ✅

Added the required functions for managing the `ModifierItem` queue. ✅

deavmi commented

2024-02-29 16:47:58 +00:00

Support for acecss modifiers and initscopes added for parseClass() ✅

Support for acecss modifiers and initscopes added for `parseClass()` ✅

deavmi stopped working 2024-02-29 16:49:44 +00:00

17 minutes 43 seconds

deavmi started working 2024-02-29 16:50:32 +00:00

deavmi commented

2024-02-29 16:56:16 +00:00

Can now apply access modifiers (not yet initscopes) to variable and function declarations ✅

deavmi commented

2024-02-29 16:57:44 +00:00

Can now apply acecss modifiers (not yet initscopes) to struct declarations ✅

deavmi stopped working 2024-02-29 16:58:12 +00:00

7 minutes 40 seconds

deavmi started working 2024-02-29 17:00:15 +00:00

deavmi stopped working 2024-02-29 17:00:17 +00:00

2 seconds

deavmi started working 2024-02-29 17:17:08 +00:00

deavmi added a new dependency 2024-02-29 17:17:18 +00:00

#157 ⚡ Feature: Multi-module support

deavmi commented

2024-02-29 17:20:38 +00:00

Structs now have a toggalble InitScope allowance and if so then apply it ✅

Structs now have a toggalble `InitScope` allowance and if so then apply it ✅

deavmi commented

2024-02-29 17:24:05 +00:00

Structs now have a toggalble InitScope allowance and if so then apply it ✅

Will be doing this for variable and function definitions in a moment

> Structs now have a toggalble `InitScope` allowance and if so then apply it ✅ Will be doing this for variable and function definitions in a moment

deavmi stopped working 2024-02-29 17:24:09 +00:00

7 minutes 1 second

deavmi started working 2024-02-29 17:30:55 +00:00

deavmi commented

2024-02-29 17:38:09 +00:00

Found some fixes I want to apply to parseClass() and parseStruct() on vardec_varass_dependency probably.

Found some fixes I want to apply to `parseClass()` and `parseStruct()` on `vardec_varass_dependency` probably.

deavmi commented

2024-02-29 17:41:58 +00:00

Found some fixes I want to apply to parseClass() and parseStruct() on vardec_varass_dependency probably.

Pushed fix for it, upstreaming now...

> Found some fixes I want to apply to `parseClass()` and `parseStruct()` on `vardec_varass_dependency` probably. Pushed fix for it, upstreaming now...

deavmi commented

2024-02-29 17:42:18 +00:00

Found some fixes I want to apply to parseClass() and parseStruct() on vardec_varass_dependency probably.

Pushed fix for it, upstreaming now...

Merged ✅

> > Found some fixes I want to apply to `parseClass()` and `parseStruct()` on `vardec_varass_dependency` probably. > > Pushed fix for it, upstreaming now... Merged ✅

deavmi stopped working 2024-02-29 17:42:28 +00:00

11 minutes 34 seconds

deavmi started working 2024-02-29 17:45:48 +00:00

deavmi stopped working 2024-02-29 17:45:50 +00:00

3 seconds

deavmi added spent time 2024-02-29 17:45:54 +00:00

5 minutes

deavmi started working 2024-02-29 17:45:56 +00:00

deavmi commented

2024-02-29 17:46:02 +00:00

When parsing body statements of class or struct we now allow initscopes to be set for function and variable declarations (if encountered) ✅

deavmi commented

2024-02-29 17:46:30 +00:00

Enough for now, looks like unittests are what is needed next

deavmi stopped working 2024-02-29 17:46:34 +00:00

38 seconds

deavmi started working 2024-02-29 17:50:51 +00:00

deavmi stopped working 2024-02-29 17:55:48 +00:00

4 minutes 58 seconds

deavmi added spent time 2024-02-29 19:50:28 +00:00

10 minutes

deavmi added spent time 2024-02-29 20:14:47 +00:00

5 minutes

deavmi added spent time 2024-03-01 16:55:31 +00:00

10 minutes

deavmi started working 2024-03-01 16:55:34 +00:00

deavmi commented

2024-03-01 16:56:45 +00:00

I know what is happening, in the case of:

private func_a()
{
    int i;
}

The ending iteration of parseBody() for int i is getting the queue item private (ACC_MOD). And leaving nothing for the function. We must update parseBody() to have something to tweak whether or not acc mods are allowed.

I know what is happening, in the case of: ```d private func_a() { int i; } ``` The ending iteration of `parseBody()` for `int i` is getting the queue item `private` (ACC_MOD). And leaving nothing for the function. We must update `parseBody()` to have something to tweak whether or not acc mods are allowed.

deavmi stopped working 2024-03-01 16:57:28 +00:00

1 minute 53 seconds

deavmi started working 2024-03-01 17:09:10 +00:00

deavmi stopped working 2024-03-01 17:10:09 +00:00

59 seconds

deavmi started working 2024-03-01 17:25:33 +00:00

deavmi commented

2024-03-01 17:31:16 +00:00

It's parseFuncDef() -> parseBody(true) -> parseStatement(SymbolType.SEMICOLON, true).

It is at the point of parseStatement(SymbolType.SEMICOLON, true) that any time we come across an isAccessor(tok) or isModifier(tok) we then check that second argument, if true we go ahead and parseAccessor() and parseInitScope() respectively, else we throw an exception.

It's `parseFuncDef()` -> `parseBody(true)` -> `parseStatement(SymbolType.SEMICOLON, true)`. It is at the point of `parseStatement(SymbolType.SEMICOLON, true)` that any time we come across an `isAccessor(tok)` or `isModifier(tok)` we then check that second argument, if `true` we go ahead and `parseAccessor()` and `parseInitScope()` respectively, else we throw an exception.

deavmi commented

2024-03-01 17:35:41 +00:00

It's parseFuncDef() -> parseBody(true) -> parseStatement(SymbolType.SEMICOLON, true).

It is at the point of parseStatement(SymbolType.SEMICOLON, true) that any time we come across an isAccessor(tok) or isModifier(tok) we then check that second argument, if true we go ahead and parseAccessor() and parseInitScope() respectively, else we throw an exception.

So this is a valid fix but that wasn't it. It is within the parseName(...) call in parseStatement()

> It's `parseFuncDef()` -> `parseBody(true)` -> `parseStatement(SymbolType.SEMICOLON, true)`. > > It is at the point of `parseStatement(SymbolType.SEMICOLON, true)` that any time we come across an `isAccessor(tok)` or `isModifier(tok)` we then check that second argument, if `true` we go ahead and `parseAccessor()` and `parseInitScope()` respectively, else we throw an exception. So this *is* a valid fix but that wasn't it. It is within the `parseName(...)` call in `parseStatement()`

deavmi commented

2024-03-01 18:55:45 +00:00

Been spending this time adding debugging helper methods to niknaks to make sorting this out a lot easier.

Been spending this time adding debugging helper methods to niknaks to make sorting this out _a lot_ easier.

deavmi commented

2024-03-01 19:21:48 +00:00

Been spending this time adding debugging helper methods to niknaks to make sorting this out a lot easier.

Enough for tonight. Will continue tomorrow, finalize and bring it into tlang code base for usage here and then the debugging shall continue.

> Been spending this time adding debugging helper methods to niknaks to make sorting this out _a lot_ easier. Enough for tonight. Will continue tomorrow, finalize and bring it into tlang code base for usage here and then the debugging shall continue.

deavmi stopped working 2024-03-01 19:22:07 +00:00

1 hour 56 minutes

deavmi commented

2024-03-02 09:37:16 +00:00

Been spending this time adding debugging helper methods to niknaks to make sorting this out a lot easier.

Enough for tonight. Will continue tomorrow, finalize and bring it into tlang code base for usage here and then the debugging shall continue.

Done and now in TLang, just need to use it.

> > Been spending this time adding debugging helper methods to niknaks to make sorting this out _a lot_ easier. > > Enough for tonight. Will continue tomorrow, finalize and bring it into tlang code base for usage here and then the debugging shall continue. Done and now in TLang, just need to use it.

deavmi added spent time 2024-03-02 09:37:24 +00:00

20 minutes

deavmi started working 2024-03-03 09:56:06 +00:00

deavmi stopped working 2024-03-03 09:58:05 +00:00

1 minute 59 seconds

deavmi added spent time 2024-03-05 18:38:27 +00:00

10 minutes

deavmi started working 2024-03-05 18:38:29 +00:00

deavmi commented

2024-03-05 18:50:54 +00:00

Aii, hierdie technique is ass.

deavmi commented

2024-03-05 18:52:25 +00:00

Not all is lost, I think.

deavmi commented

2024-03-05 18:54:15 +00:00

I might need to, prior to entering sme sort of nested shit, actually pop off the modifiers as soon as they are n a valid thing (or before that valid thing is created).

By this I mean that when I am doing parseFuncDef() I must check if there are any modifiers available, pop them and save them and then apply them right at the end.

I shouldn't be leaving anything for things which are invalid.

We shall still make use of allowModifiers because the generated Function may be in a class where init scopes are allowed or in a module level (where they are not). So it is still a valid control.

I might need to, prior to entering sme sort of nested shit, actually pop off the modifiers as soon as they are n a valid thing (or before that valid thing is created). By this I mean that when I am doing `parseFuncDef()` I must check if there are any modifiers available, pop them and save them and then apply them right at the end. I shouldn't be leaving anything for things which are invalid. --- We shall still make use of `allowModifiers` because the generated `Function` may be in a `class` where init scopes are allowed or in a module level (where they are not). So it is still a valid control.

deavmi commented

2024-03-05 19:17:23 +00:00

Holy moly, it worked 🇱🇧

deavmi commented

2024-03-05 19:47:44 +00:00

Got that done, CI/CD is now passing ✅

I think I came across a good solution for this.

Got that done, CI/CD is now passing ✅ --- I think I came across a good solution for this.

deavmi stopped working 2024-03-05 19:48:56 +00:00

1 hour 10 minutes

deavmi started working 2024-03-05 19:52:10 +00:00

deavmi commented

2024-03-05 19:52:23 +00:00

Added negative test cases ✅

deavmi stopped working 2024-03-05 19:52:47 +00:00

37 seconds

deavmi added spent time 2024-03-06 19:40:35 +00:00

10 minutes

deavmi started working 2024-03-06 19:40:38 +00:00

deavmi stopped working 2024-03-06 19:41:23 +00:00

45 seconds

deavmi started working 2024-03-10 10:45:12 +00:00

deavmi stopped working 2024-03-10 10:45:15 +00:00

3 seconds

deavmi started working 2024-03-10 10:46:23 +00:00

deavmi commented

2024-03-10 10:47:18 +00:00

Functions now have a default access modifier of PRIVATE ✅

Functions now have a default access modifier of `PRIVATE` ✅

deavmi stopped working 2024-03-10 10:47:28 +00:00

1 minute 5 seconds

deavmi pinned this 2024-04-01 21:28:54 +01:00

deavmi removed a dependency 2024-04-08 11:48:35 +01:00

#157 ⚡ Feature: Multi-module support

deavmi started working 2024-05-05 13:09:43 +01:00

deavmi removed the due date 2024-04-04

2024-05-05 13:09:45 +01:00

deavmi added the due date 2024-05-11

2024-05-05 13:09:51 +01:00

deavmi commented

2024-05-05 13:09:57 +01:00

Working on this now...

deavmi commented

2024-05-05 13:34:31 +01:00

Working on this now...

Sorted out the merge conflicts now ✅

> Working on this now... Sorted out the merge conflicts now ✅

deavmi commented

2024-05-05 13:39:12 +01:00

Having weird issuesd compiling some stuff now thonmking

deavmi commented

2024-05-05 13:42:36 +01:00

Having weird issuesd compiling some stuff now thonmking

So doThing() is private by default, so if I prepend its delcaration with public then things sort out the first error. Similar story with accessing k() from the generated a.c

> Having weird issuesd compiling some stuff now thonmking So `doThing()` is `private` by default, so if I prepend its delcaration with `public` then things sort out the first error. Similar story with accessing `k()` from the generated `a.c`

deavmi commented

2024-05-05 13:46:31 +01:00

Having weird issuesd compiling some stuff now thonmking

So doThing() is private by default, so if I prepend its delcaration with public then things sort out the first error. Similar story with accessing k() from the generated a.c

Weird stuff, this:

Gives this ⏰:

> > Having weird issuesd compiling some stuff now thonmking > > So `doThing()` is `private` by default, so if I prepend its delcaration with `public` then things sort out the first error. Similar story with accessing `k()` from the generated `a.c` **Weird stuff**, this: ![image](/attachments/268b0cd9-c1e0-4060-96e8-0eeea18849a1) Gives **this** ⏰: ![image](/attachments/ddc8a63f-b0a7-44c6-9701-88530ce9fec5)

image.png

94 KiB

image.png

193 KiB

deavmi commented

2024-05-05 13:58:23 +01:00

Having weird issuesd compiling some stuff now thonmking

So doThing() is private by default, so if I prepend its delcaration with public then things sort out the first error. Similar story with accessing k() from the generated a.c

Weird stuff, this:

Gives this ⏰:

Looks like variables are not having access modifications applied to them actually.

> > > Having weird issuesd compiling some stuff now thonmking > > > > So `doThing()` is `private` by default, so if I prepend its delcaration with `public` then things sort out the first error. Similar story with accessing `k()` from the generated `a.c` > > **Weird stuff**, this: > > ![image](/attachments/268b0cd9-c1e0-4060-96e8-0eeea18849a1) > > Gives **this** ⏰: > > ![image](/attachments/ddc8a63f-b0a7-44c6-9701-88530ce9fec5) Looks like variables are not having access modifications applied to them actually.

deavmi commented

2024-05-05 14:01:49 +01:00

Having weird issuesd compiling some stuff now thonmking

So doThing() is private by default, so if I prepend its delcaration with public then things sort out the first error. Similar story with accessing k() from the generated a.c

Weird stuff, this:

Gives this ⏰:

Looks like variables are not having access modifications applied to them actually.

Added a forceful quit, looks like this IS the reason why! :)

[DEBUG] resolveWithin(cntnr=Module [name: a]) container has statements [Function (Name: ident, ReturnType: int, Args: int), Function (Name: main, ReturnType: int, Args: ), Variable (Ident: j, Type: ubyte)]
[ERROR] Var kak:  Variable (Ident: j, Type: ubyte) UNKNOWN
Segmentation fault (core dumped)
0
deavmi@fedora:~/Documents/

> > > > Having weird issuesd compiling some stuff now thonmking > > > > > > So `doThing()` is `private` by default, so if I prepend its delcaration with `public` then things sort out the first error. Similar story with accessing `k()` from the generated `a.c` > > > > **Weird stuff**, this: > > > > ![image](/attachments/268b0cd9-c1e0-4060-96e8-0eeea18849a1) > > > > Gives **this** ⏰: > > > > ![image](/attachments/ddc8a63f-b0a7-44c6-9701-88530ce9fec5) > > Looks like variables are not having access modifications applied to them actually. Added a forceful quit, looks like this **IS** the reason why! :) ``` [DEBUG] resolveWithin(cntnr=Module [name: a]) container has statements [Function (Name: ident, ReturnType: int, Args: int), Function (Name: main, ReturnType: int, Args: ), Variable (Ident: j, Type: ubyte)] [ERROR] Var kak: Variable (Ident: j, Type: ubyte) UNKNOWN Segmentation fault (core dumped) 0 deavmi@fedora:~/Documents/ ```

deavmi commented

2024-05-05 14:14:04 +01:00

Having weird issuesd compiling some stuff now thonmking

So doThing() is private by default, so if I prepend its delcaration with public then things sort out the first error. Similar story with accessing k() from the generated a.c

Weird stuff, this:

Gives this ⏰:

Looks like variables are not having access modifications applied to them actually.

Added a forceful quit, looks like this IS the reason why! :)
[DEBUG] resolveWithin(cntnr=Module [name: a]) container has statements [Function (Name: ident, ReturnType: int, Args: int), Function (Name: main, ReturnType: int, Args: ), Variable (Ident: j, Type: ubyte)]
[ERROR] Var kak:  Variable (Ident: j, Type: ubyte) UNKNOWN
Segmentation fault (core dumped)
0
deavmi@fedora:~/Documents/

Looks like I fixed it, will push later

> > > > > Having weird issuesd compiling some stuff now thonmking > > > > > > > > So `doThing()` is `private` by default, so if I prepend its delcaration with `public` then things sort out the first error. Similar story with accessing `k()` from the generated `a.c` > > > > > > **Weird stuff**, this: > > > > > > ![image](/attachments/268b0cd9-c1e0-4060-96e8-0eeea18849a1) > > > > > > Gives **this** ⏰: > > > > > > ![image](/attachments/ddc8a63f-b0a7-44c6-9701-88530ce9fec5) > > > > Looks like variables are not having access modifications applied to them actually. > > Added a forceful quit, looks like this **IS** the reason why! :) > > ``` > [DEBUG] resolveWithin(cntnr=Module [name: a]) container has statements [Function (Name: ident, ReturnType: int, Args: int), Function (Name: main, ReturnType: int, Args: ), Variable (Ident: j, Type: ubyte)] > [ERROR] Var kak: Variable (Ident: j, Type: ubyte) UNKNOWN > Segmentation fault (core dumped) > 0 > deavmi@fedora:~/Documents/ > ``` Looks like I fixed it, will push later

deavmi commented

2024-05-05 14:15:10 +01:00

Having weird issuesd compiling some stuff now thonmking

So doThing() is private by default, so if I prepend its delcaration with public then things sort out the first error. Similar story with accessing k() from the generated a.c

Weird stuff, this:

Gives this ⏰:

Looks like variables are not having access modifications applied to them actually.

Added a forceful quit, looks like this IS the reason why! :)
[DEBUG] resolveWithin(cntnr=Module [name: a]) container has statements [Function (Name: ident, ReturnType: int, Args: int), Function (Name: main, ReturnType: int, Args: ), Variable (Ident: j, Type: ubyte)]
[ERROR] Var kak:  Variable (Ident: j, Type: ubyte) UNKNOWN
Segmentation fault (core dumped)
0
deavmi@fedora:~/Documents/
Looks like I fixed it, will push later

Fixed and pushed ✅

> > > > > > Having weird issuesd compiling some stuff now thonmking > > > > > > > > > > So `doThing()` is `private` by default, so if I prepend its delcaration with `public` then things sort out the first error. Similar story with accessing `k()` from the generated `a.c` > > > > > > > > **Weird stuff**, this: > > > > > > > > ![image](/attachments/268b0cd9-c1e0-4060-96e8-0eeea18849a1) > > > > > > > > Gives **this** ⏰: > > > > > > > > ![image](/attachments/ddc8a63f-b0a7-44c6-9701-88530ce9fec5) > > > > > > Looks like variables are not having access modifications applied to them actually. > > > > Added a forceful quit, looks like this **IS** the reason why! :) > > > > ``` > > [DEBUG] resolveWithin(cntnr=Module [name: a]) container has statements [Function (Name: ident, ReturnType: int, Args: int), Function (Name: main, ReturnType: int, Args: ), Variable (Ident: j, Type: ubyte)] > > [ERROR] Var kak: Variable (Ident: j, Type: ubyte) UNKNOWN > > Segmentation fault (core dumped) > > 0 > > deavmi@fedora:~/Documents/ > > ``` > > Looks like I fixed it, will push later Fixed and pushed ✅

deavmi commented

2024-05-05 14:42:49 +01:00

Need to fix calls for parsename(...) or so, to allow init scopes for variables in certain cases.

Need to fix calls for `parsename(...)` or so, to allow init scopes for variables in certain cases.

deavmi commented

2024-05-05 14:49:14 +01:00

Need to fix calls for parsename(...) or so, to allow init scopes for variables in certain cases.

Nvm, all is fine ✅

> Need to fix calls for `parsename(...)` or so, to allow init scopes for variables in certain cases. Nvm, all is fine ✅

deavmi stopped working 2024-05-05 14:49:36 +01:00

1 hour 39 minutes

deavmi added spent time 2024-05-05 15:00:47 +01:00

1 minute

deavmi started working 2024-05-05 15:00:50 +01:00

deavmi stopped working 2024-05-05 15:01:13 +01:00

22 seconds

deavmi started working 2024-05-05 15:10:35 +01:00

deavmi commented

2024-05-05 15:17:09 +01:00

Purpose ✍️

To add support for public, private, protected, static etc. to the following:

Parser

To add parsing support

Class modifiers

Function declarations

AccMods

InitScopes

Variable delcrations

AccMods

InitScopes

Struct type declarations

AccMods

InitScopes

InitScopes will only be valid in certain places, so we must make that a potential optional argument or something only in places where it could potentially be applied

Added unittest

TypeChecker/Dependency generation

To see if access is allowed

DGen

For generating exports (only make sense when #157 is completed)

Find out why stuff isn't working for the multi-module test case

Make depenedency generator complain when accessing something not visible

Make depenedency generator complain when accessing something not visible

Working on this now

> # Purpose ✍️ > > To add support for `public`, `private`, `protected`, `static` etc. to the following: > > - [ ] `Parser` > * To add parsing support > - [x] Class modifiers > - [x] Function declarations > - [x] AccMods > - [x] InitScopes > - [x] Variable delcrations > - [x] AccMods > - [x] InitScopes > - [x] Struct type declarations > - [x] AccMods > - [x] InitScopes > * `InitScope`s will only be valid in certain places, so we must make that a potential optional argument or something only in places where it _could_ potentially be applied > - [x] Added unittest > - [ ] `TypeChecker`/Dependency generation > * To see if access is allowed > - [ ] `DGen` > * For generating exports (only make sense when #157 is completed) > - [x] Find out why stuff isn't working for the multi-module test case > - [ ] Make depenedency generator complain when accessing something not visible > Make depenedency generator complain when accessing something not visible Working on this now

deavmi stopped working 2024-05-05 15:29:22 +01:00

18 minutes 47 seconds

deavmi started working 2024-05-05 16:42:40 +01:00

deavmi commented

2024-05-05 16:55:08 +01:00

Purpose ✍️

To add support for public, private, protected, static etc. to the following:

Parser

To add parsing support

Class modifiers

Function declarations

AccMods

InitScopes

Variable delcrations

AccMods

InitScopes

Struct type declarations

AccMods

InitScopes

InitScopes will only be valid in certain places, so we must make that a potential optional argument or something only in places where it could potentially be applied

Added unittest

TypeChecker/Dependency generation

To see if access is allowed

DGen

For generating exports (only make sense when #157 is completed)

Find out why stuff isn't working for the multi-module test case

Make depenedency generator complain when accessing something not visible

Make depenedency generator complain when accessing something not visible

Working on this now

Looks like it is beginning to work. done for today though

> > # Purpose ✍️ > > > > To add support for `public`, `private`, `protected`, `static` etc. to the following: > > > > - [ ] `Parser` > > * To add parsing support > > - [x] Class modifiers > > - [x] Function declarations > > - [x] AccMods > > - [x] InitScopes > > - [x] Variable delcrations > > - [x] AccMods > > - [x] InitScopes > > - [x] Struct type declarations > > - [x] AccMods > > - [x] InitScopes > > * `InitScope`s will only be valid in certain places, so we must make that a potential optional argument or something only in places where it _could_ potentially be applied > > - [x] Added unittest > > - [ ] `TypeChecker`/Dependency generation > > * To see if access is allowed > > - [ ] `DGen` > > * For generating exports (only make sense when #157 is completed) > > - [x] Find out why stuff isn't working for the multi-module test case > > - [ ] Make depenedency generator complain when accessing something not visible > > > Make depenedency generator complain when accessing something not visible > > Working on this now Looks like it is beginning to work. done for today though

deavmi stopped working 2024-05-05 16:55:14 +01:00

12 minutes 34 seconds

deavmi added spent time 2024-05-05 17:36:35 +01:00

10 minutes

deavmi started working 2024-05-05 17:36:38 +01:00

deavmi commented

2024-05-05 17:40:46 +01:00

I know what is to be done and it need not use Context (which is something I want to deprecate anyways)

I know what is to be done and it need not use `Context` (which is something I want to deprecate anyways)

deavmi stopped working 2024-05-05 17:41:42 +01:00

5 minutes 4 seconds

deavmi added the