Skip to content
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

Compilation errors handling #386

Closed
csgui opened this issue Apr 17, 2024 · 4 comments
Closed

Compilation errors handling #386

csgui opened this issue Apr 17, 2024 · 4 comments
Assignees

Comments

@csgui
Copy link
Collaborator

csgui commented Apr 17, 2024

Interpreter errors (i.e: syntax error, etc...) should be mapped to Wasm compilation errors.

@smcclellan
Copy link

@csgui to add more info to this.

@smcclellan smcclellan moved this from Status: 🆕 New to Status: 📋 Backlog in Stacks Core Eng May 28, 2024
@smcclellan smcclellan moved this from Status: 📋 Backlog to Status: 🆕 New in Stacks Core Eng May 28, 2024
@csgui
Copy link
Collaborator Author

csgui commented Jun 3, 2024

Following a closer look, compilation errors are being handled as a GeneratorError::InternalError. If a new error type is needed in the future, that can be done later.

Closing this issue.

@csgui csgui closed this as completed Jun 3, 2024
@github-project-automation github-project-automation bot moved this from Status: 🆕 New to Status: ✅ Done in Stacks Core Eng Jun 3, 2024
@Acaccia
Copy link
Collaborator

Acaccia commented Jun 6, 2024

@csgui super weird take, why shouldn’t there be clear compilation errors returned to the Clarity dev? Shouldn’t InternalErrors be for the cases where we have a logic error in the compiler code?

@csgui
Copy link
Collaborator Author

csgui commented Jun 6, 2024

@Acaccia As you noticed this issue is related to the #421. I can say that it was closed by mistake. Let's use the issue #421 to work on compilation-time errors.

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

No branches or pull requests

3 participants