Thanks to visit codestin.com
Credit goes to github.com

Skip to content

♻️ Enhance reporting errors and warnings in parsing model token #5241

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

mikeleppane
Copy link

This change introduces a new type, InvalidTokenError to hold and represent invalid tokens while parsing source files. This improves the separation of concerns and allows better control and isolation of how invalid tokens should be handled.

Error codes are represented by an enum (surprisingly, as a type ErrorCode). The InvalidTokenError type holds a kind parameter to describe the token's error level, which is either a warning or an error.

Note: The import order is sorted because IDE does that automatically. I assume this is okay.

Related Issue

This change introduces a new type, "InvalidTokenError," to hold and represent invalid tokens while parsing source files. This improves the separation of concerns and allows better control and isolation of how invalid tokens should be handled.
@mikeleppane mikeleppane marked this pull request as draft October 17, 2024 11:46
…g as_warning and as_error custom constructors.

Add docs to InvalidTokenError and ErrorCode types.
Add appropriate unit tests for new business logic.
…quired unnecessarily to check that InvalidTokenError is Error kind and has is_fatal attribute set to true.
@pekkaklarck
Copy link
Member

Sorry for not reviewing this in timely manner @mikeleppane due to there being more important issues in RF 7.2 scope. In the end the deprecation of the pipe-separated format (#5203) what required this enhancement was also postponed to RF 7.3. There are currently no other benefits from this change, so I believe it's best to move #5210 (and this PR) to RF 7.3 as well.

There are some conflicts, but they seem to be easy to fix.

@mikeleppane
Copy link
Author

Sorry for not reviewing this in timely manner @mikeleppane due to there being more important issues in RF 7.2 scope. In the end the deprecation of the pipe-separated format (#5203) what required this enhancement was also postponed to RF 7.3. There are currently no other benefits from this change, so I believe it's best to move #5210 (and this PR) to RF 7.3 as well.

There are some conflicts, but they seem to be easy to fix.

No problem. Okay, let's move it to RF 7.3. I will fix those conflicts when I have time.

While working on this and experimenting with feature proposals, I realized that there is significant room for improvement in error messages and diagnostics to enhance the developer experience (DX). This goes beyond just addressing issue #5203. Consequently, I started a side project to rewrite the parsing logic in Rust with the aim of creating a tool similar to tidy for Robot. My two main objectives are to provide great error messages and achieve high performance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants