⚡ Feature: Better error reporting, messaging #169

New Issue

Open

opened 2024-04-02 07:36:23 +01:00 by deavmi · 16 comments

deavmi commented 2024-04-02 07:36:23 +01:00

Owner

Copy Link

Purpose ✍️

I want to have better error reporting, which entails:

• Showing where the error happened. Think about line information
• Better print outs for errors

Example

If for example we have source code int i = 3; then the tokens should be as follows:

1. int
2. i
3. =
4. 3
5. ;

And the getOrigin()'s of each of these Token(s) should be as follows:

1. int
2. int i
3. int i =
4. int i = 3
5. int i = 3;

How

I think we should implement something in every Statement to have a LineInfo struct associated with it which is a string of associated Token(s) which can be restrung together on the fly. This means we get proper line information.

• Coords
• Token to have getCoords()
• LineInfo defined
• Statement to have methods to get and set LineInfo
• Parser to attach LineInfo to all Statements
• BasicLexer to do setOrigin(string) when needed @gusmeyer
• BasicLexer to have better (x,y) saving @gusmeyer
• Common error reporting mechansim. Something whereby we give it the Statement and it automagically prints out the problem, we could even optionally position the cursor (this would imply knowing where which at that stage is probably not possible)
  • The Parser's expect() method should be correctly updated
  • In future we should maybe keep the origin transferred over to the Statement so errors that are not only in the Parser can be reported on
    • Transfer over to each Statement in parsing/core.d

## Purpose ✍️ I want to have better error reporting, which entails: - [x] Showing _where_ the error happened. Think about line information - [x] Better print outs for errors ### Example If for example we have source code `int i = 3;` then the tokens should be as follows: 1. `int` 2. `i` 3. `=` 4. `3` 5. `;` And the `getOrigin()`'s of each of these `Token`(s) should be as follows: 1. `int` 2. `int i` 3. `int i =` 4. `int i = 3` 5. `int i = 3;` ## How I think we should implement something in every `Statement` to have a `LineInfo` struct associated with it which is a string of associated `Token`(s) which can be restrung together on the fly. This means we get proper line information. - [x] `Coords` - [x] `Token` to have `getCoords()` - [x] `LineInfo` defined - [x] `Statement` to have methods to get and set `LineInfo` - [ ] ~~Parser to attach `LineInfo` to all `Statement`s~~ - [ ] `BasicLexer` to do `setOrigin(string)` when needed @gusmeyer - [ ] `BasicLexer` to have better `(x,y)` saving @gusmeyer - [ ] Common error reporting mechansim. Something whereby we give it the `Statement` and it automagically prints out the problem, we could even optionally position the cursor (this would imply knowing where which at that stage is probably not possible) - [x] The `Parser`'s `expect()` method should be correctly updated - [ ] In future we should maybe keep the origin transferred over to the `Statement` so errors that are not only in the `Parser` can be reported on - [ ] Transfer over to each `Statement` in `parsing/core.d`

deavmi added this to the Clean ups milestone 2024-04-02 07:36:23 +01:00

deavmi added spent time 2024-04-02 07:47:16 +01:00

10 minutes

deavmi started working 2024-04-02 07:47:18 +01:00

deavmi added the

parser

lexer

labels 2024-04-02 07:47:27 +01:00

deavmi self-assigned this 2024-04-02 07:47:30 +01:00

deavmi added this to the Parser project 2024-04-02 07:47:35 +01:00

deavmi added reference feature/reporting 2024-04-02 07:51:44 +01:00

deavmi commented 2024-04-02 08:07:09 +01:00

Author

Owner

Copy Link

Most of the requirements are done ✅

Most of the requirements are done ✅

deavmi stopped working 2024-04-02 08:16:07 +01:00

28 minutes 49 seconds

deavmi started working 2024-04-02 08:53:41 +01:00

deavmi commented 2024-04-02 08:58:10 +01:00

Author

Owner

Copy Link

We are calling track(Token) on each and then saving afterwards:

Then this gives us this:

We are calling `track(Token)` on each and then saving afterwards:  Then this gives us this: 

image.png

109 KiB

image.png

52 KiB

deavmi commented 2024-04-02 09:01:00 +01:00

Author

Owner

Copy Link

The current tracking mechanism may not be the best. It may need nesting. It really depends on what we want but yes, definately it would need to be a little smarter.

We would like to have the expression in the while(<expression>) also have its own line info. Therefore we can maintain this maybe using enter() and leave() semantics.

The current tracking mechanism may not be the best. It may need nesting. It really depends on what we want but yes, definately it would need to be a little smarter. We would like to have the `expression` in the `while(<expression>)` also have its own line info. Therefore we can maintain this maybe using `enter()` and `leave()` semantics.

deavmi commented 2024-04-02 09:06:47 +01:00

Author

Owner

Copy Link

openTracking() should push to a stack a new LineInfo which is used as the current one.

Mmmh, however we need like actually a trail where every open'd LineInfo gets tacked onto, that makes the most sense.

`openTracking()` should push to a stack a new `LineInfo` which is used as the current one. Mmmh, however we need like actually a trail where every open'd `LineInfo` gets tacked onto, that makes the most sense.

deavmi commented 2024-04-02 09:12:37 +01:00

Author

Owner

Copy Link

I wonder f this is even the best way to do this? It feels bloated reconsttucting it from Token(s) when perhaps the lexer should be storing the line of each token. Whenever a newline is found you then restart that line.

I wonder f this is even the best way to do this? It feels bloated reconsttucting it _from_ `Token`(s) when perhaps the lexer should be storing the line of each token. Whenever a newline is found you then restart that line.

deavmi commented 2024-04-02 09:17:25 +01:00

Author

Owner

Copy Link

I feel as though the Token should have an originString which holds the line the token belongs to and then from there all we do our side is, because Tokens have a getCoord() we can place that along said string for error messages.

I feel as though the `Token` should have an `originString` which holds the line the token belongs to and then from there all we do our side is, because `Token`s have a `getCoord()` we can place that along said string for error messages.

deavmi commented 2024-04-02 09:17:33 +01:00

Author

Owner

Copy Link

Going to need @gusmeyer 's help for this

Going to need @gusmeyer 's help for this

deavmi commented 2024-04-02 09:41:16 +01:00

Author

Owner

Copy Link

I feel as though the Token should have an originString which holds the line the token belongs to and then from there all we do our side is, because Tokens have a getCoord() we can place that along said string for error messages.

The idea is right though:

> I feel as though the `Token` should have an `originString` which holds the line the token belongs to and then from there all we do our side is, because `Token`s have a `getCoord()` we can place that along said string for error messages. The idea is right though: 

image.png

60 KiB

deavmi commented 2024-04-02 09:43:49 +01:00

Author

Owner

Copy Link

Reporting mechanism is basically done

I feel as though the Token should have an originString which holds the line the token belongs to and then from there all we do our side is, because Tokens have a getCoord() we can place that along said string for error messages.

The idea is right though:

Reporting mechanism is basically done > > I feel as though the `Token` should have an `originString` which holds the line the token belongs to and then from there all we do our side is, because `Token`s have a `getCoord()` we can place that along said string for error messages. > > The idea is right though: > > 

gusmeyer was assigned by deavmi 2024-04-02 09:43:58 +01:00

deavmi stopped working 2024-04-02 09:44:07 +01:00

50 minutes 26 seconds

deavmi changed title from Better error reporting, messaging to ⚡ Feature: Better error reporting, messaging 2024-04-02 17:33:24 +01:00

deavmi started working 2024-04-02 17:36:13 +01:00

deavmi stopped working 2024-04-02 17:38:49 +01:00

2 minutes 36 seconds

deavmi started working 2024-04-02 17:39:32 +01:00

deavmi commented 2024-04-02 17:55:32 +01:00

Author

Owner

Copy Link

Working on making the reporting system more generic from first prinmciples and then building it out on a per-usae case scenario.

Working on making the reporting system more generic from first prinmciples and then building it out on a per-usae case scenario.

deavmi commented 2024-04-02 18:05:39 +01:00

Author

Owner

Copy Link

Working on making the reporting system more generic from first prinmciples and then building it out on a per-usae case scenario.

Added in ✅

> Working on making the reporting system more generic from first prinmciples and then building it out on a per-usae case scenario. Added in ✅

deavmi stopped working 2024-04-02 18:11:33 +01:00

32 minutes

deavmi added the due date 2024-04-05 2024-04-02 18:11:39 +01:00

deavmi added spent time 2024-04-02 18:13:14 +01:00

2 minutes

deavmi started working 2024-04-02 18:13:20 +01:00

deavmi commented 2024-04-02 18:28:38 +01:00

Author

Owner

Copy Link

Finalizing some cleanup, but moet gaan stort eerstens 🚿

Finalizing some cleanup, but moet gaan stort eerstens 🚿

deavmi commented 2024-04-02 18:31:48 +01:00

Author

Owner

Copy Link

Finalizing some cleanup, but moet gaan stort eerstens 🚿

Finalized now ✅

> Finalizing some cleanup, but moet gaan stort eerstens 🚿 Finalized now ✅

deavmi stopped working 2024-04-02 18:32:19 +01:00

18 minutes 58 seconds

deavmi started working 2024-04-02 20:19:51 +01:00

deavmi commented 2024-04-02 20:29:41 +01:00

Author

Owner

Copy Link

Purpose ✍️

I want to have better error reporting, which entails:

• Showing where the error happened. Think about line information
• Better print outs for errors

Example

If for example we have source code int i = 3; then the tokens should be as follows:

1. int
2. i
3. =
4. 3
5. ;

And the getOrigin()'s of each of these Token(s) should be as follows:

1. int
2. int i
3. int i =
4. int i = 3
5. int i = 3;

How

I think we should implement something in every Statement to have a LineInfo struct associated with it which is a string of associated Token(s) which can be restrung together on the fly. This means we get proper line information.

• Coords

• Token to have getCoords()

• LineInfo defined

• Statement to have methods to get and set LineInfo

• Parser to attach LineInfo to all Statements

• Common error reporting mechansim. Something whereby we give it the Statement and it automagically prints out the problem, we could even optionally position the cursor (this would imply knowing where which at that stage is probably not possible)

  • The Parser's expect() method should be correctly updated
  • In future we should maybe keep the origin transferred over to the Statement so errors that are not only in the Parser can be reported on

The Parser's expect() method should be correctly updated

This has been completed by updating SyntaxError to use report(string, Token) ✅

> ## Purpose ✍️ > > I want to have better error reporting, which entails: > > - [ ] Showing _where_ the error happened. Think about line information > - [ ] Better print outs for errors > > > ### Example > > If for example we have source code `int i = 3;` then the tokens should be as follows: > > 1. `int` > 2. `i` > 3. `=` > 4. `3` > 5. `;` > > And the `getOrigin()`'s of each of these `Token`(s) should be as follows: > > 1. `int` > 2. `int i` > 3. `int i =` > 4. `int i = 3` > 5. `int i = 3;` > > ## How > > I think we should implement something in every `Statement` to have a `LineInfo` struct associated with it which is a string of associated `Token`(s) which can be restrung together on the fly. This means we get proper line information. > > - [x] `Coords` > - [x] `Token` to have `getCoords()` > - [x] `LineInfo` defined > - [x] `Statement` to have methods to get and set `LineInfo` > - [ ] ~~Parser to attach `LineInfo` to all `Statement`s~~ > > - [ ] Common error reporting mechansim. Something whereby we give it the `Statement` and it automagically prints out the problem, we could even optionally position the cursor (this would imply knowing where which at that stage is probably not possible) > - [ ] The `Parser`'s `expect()` method should be correctly updated > - [ ] In future we should maybe keep the origin transferred over to the `Statement` so errors that are not only in the `Parser` can be reported on >The Parser's expect() method should be correctly updated This has been completed by updating `SyntaxError` to use `report(string, Token)` ✅

deavmi stopped working 2024-04-02 20:33:16 +01:00

13 minutes 25 seconds

deavmi started working 2024-04-02 20:55:42 +01:00

deavmi commented 2024-04-02 21:02:09 +01:00

Author

Owner

Copy Link

Purpose ✍️

I want to have better error reporting, which entails:

• Showing where the error happened. Think about line information
• Better print outs for errors

Example

If for example we have source code int i = 3; then the tokens should be as follows:

1. int
2. i
3. =
4. 3
5. ;

And the getOrigin()'s of each of these Token(s) should be as follows:

1. int
2. int i
3. int i =
4. int i = 3
5. int i = 3;

How

I think we should implement something in every Statement to have a LineInfo struct associated with it which is a string of associated Token(s) which can be restrung together on the fly. This means we get proper line information.

• Coords
• Token to have getCoords()
• LineInfo defined
• Statement to have methods to get and set LineInfo
• Parser to attach LineInfo to all Statements
• BasicLexer to do setOrigin(string) when needed @gusmeyer
• BasicLexer to have better (x,y) saving @gusmeyer
• Common error reporting mechansim. Something whereby we give it the Statement and it automagically prints out the problem, we could even optionally position the cursor (this would imply knowing where which at that stage is probably not possible)
  • The Parser's expect() method should be correctly updated
  • In future we should maybe keep the origin transferred over to the Statement so errors that are not only in the Parser can be reported on

Trying to think of the best way to do this because, look, it could span multiple lines then and then you're in for trouble with a relatively complicated system. Maybe we should just assume best effort?

In future we should maybe keep the origin transferred over to the Statement so errors that are not only in the Parser can be reported on

> ## Purpose ✍️ > > I want to have better error reporting, which entails: > > - [x] Showing _where_ the error happened. Think about line information > - [x] Better print outs for errors > > > ### Example > > If for example we have source code `int i = 3;` then the tokens should be as follows: > > 1. `int` > 2. `i` > 3. `=` > 4. `3` > 5. `;` > > And the `getOrigin()`'s of each of these `Token`(s) should be as follows: > > 1. `int` > 2. `int i` > 3. `int i =` > 4. `int i = 3` > 5. `int i = 3;` > > ## How > > I think we should implement something in every `Statement` to have a `LineInfo` struct associated with it which is a string of associated `Token`(s) which can be restrung together on the fly. This means we get proper line information. > > - [x] `Coords` > - [x] `Token` to have `getCoords()` > - [x] `LineInfo` defined > - [x] `Statement` to have methods to get and set `LineInfo` > - [ ] ~~Parser to attach `LineInfo` to all `Statement`s~~ > - [ ] `BasicLexer` to do `setOrigin(string)` when needed @gusmeyer > - [ ] `BasicLexer` to have better `(x,y)` saving @gusmeyer > - [ ] Common error reporting mechansim. Something whereby we give it the `Statement` and it automagically prints out the problem, we could even optionally position the cursor (this would imply knowing where which at that stage is probably not possible) > - [x] The `Parser`'s `expect()` method should be correctly updated > - [ ] In future we should maybe keep the origin transferred over to the `Statement` so errors that are not only in the `Parser` can be reported on Trying to think of the best way to do this because, look, it could span multiple lines then and then you're in for trouble with a relatively complicated system. Maybe we should just assume best effort? >In future we should maybe keep the origin transferred over to the Statement so errors that are not only in the Parser can be reported on

deavmi stopped working 2024-04-02 21:24:37 +01:00

28 minutes 55 seconds

deavmi started working 2024-04-02 21:26:10 +01:00

deavmi stopped working 2024-04-05 16:45:19 +01:00

2 days 19 hours

deavmi commented 2024-04-05 16:45:34 +01:00

Author

Owner

Copy Link

Forgot to stop the timer 🤡

Forgot to stop the timer 🤡

deavmi modified the due date from 2024-04-05 to 2024-04-09 2024-04-05 17:09:35 +01:00

deavmi pinned this 2024-04-08 16:00:57 +01:00

deavmi started working 2024-04-14 10:01:32 +01:00

deavmi modified the due date from 2024-04-09 to 2024-04-30 2024-04-14 10:04:50 +01:00

deavmi stopped working 2024-04-14 10:12:42 +01:00

11 minutes 10 seconds

Sign in to join this conversation.

feature/reporting

Branches Tags

Clear current reference

master

feature/modifiers

feature/comments

feature/operator_precedence

vardec_varass_dependency

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/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

Clean ups

Projects

Clear projects

No project

Parser

Assignees

Clear assignees

No Assignees

deavmi

gusmeyer

1 Participants

Notifications

Subscribe

Total Time Spent: 2 days 22 hours

deavmi

2 days 22 hours

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

2024-04-30

Dependencies

No dependencies set.

Reference: tlang/tlang#169

No description provided.