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

We Should Make the Slice Compiler Better Tolerate 'Bad' Identifiers #3321

Open
InsertCreativityHere opened this issue Jan 8, 2025 · 0 comments

Comments

@InsertCreativityHere
Copy link
Member

I'm not suggesting that we loosen our rules, or downgrade errors to warnings, just that we should change the parser to be more graceful when it encounters a Slice definitions that uses a 'bad' identifier.

For example, trying to compile this:

module _hello
{
    interface Foo {...}
}

produces 2 errors: one for illegal leading underscore in identifier ..., but another for interfaces can only be defined within a module.
This 2nd error is totally bogus. The interface was defined in a module.


What's happening is that if we hit a 'bad' name, we don't even bother creating the Slice definition internally.
So, when we parse this, we never create a new instance of Module (since it had a bad name), and when the parser sees an interface,
it looks at it's stack of container contexts and sees it's not in a Module: triggering an error.

The Slice compiler should always construct a new instance of these types, even if it's using a reserved identifier.
The only thing that should change when you use a bad identifier is that we emit an error message. That's it. Nothing else.

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

No branches or pull requests

1 participant