-
-
Notifications
You must be signed in to change notification settings - Fork 5
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
Modified the language server so it sends the results of the interpreter #3
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should ensure that the interpreter doesn't run into an endless loop. For example, the following code will be quite problematic:
while (true) { }
The runInterpreter
call should use a timeout (something like 5 seconds) and throw in case the execution didn't stop within the time limit.
cancellationToken: CancellationToken, | ||
timeout: NodeJS.Timeout, | ||
log: (value: unknown) => MaybePromise<void>, | ||
onStart?: () => void, | ||
} | ||
|
||
class Variables { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think and suggest that you should avoid using UNKNOWN, because UNKNOWN cannot just be a primitive. PLUS, you can add more metadata if needed by trying this pattern:
type XType = 'A'|'B'|'C';
interface XBase {
type: XType;
}
interface A extends XBase {
type: 'A'; // subset of parent definition!
content: string;
}
interface B extends XBase {
type: 'B'; // subset of parent...
content: number;
}
interface C extends XBase {
type: 'C';
content: boolean;
}
type X = A|B|C;
//usage: you can do stuff like this:
const x: X = ... //get from somewhere
if(x.type === 'A') {
//it asserts then that x is of type A, so accessing x.content will be a string, no casts needed!!!
} else if(x.type === 'B') {
//...x.content is number
} else if(x.type === 'C') {
//...x.content is boolean
} else {
assertUnreachable(x.type); //this code is then unreachable (it will be highlighted red when another type D was added)
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe as separated PR, I see it is everywhere O.o...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, maybe that would be better. What do you think @msujew?
let end = false; | ||
|
||
context.variables.enter(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: Coding style: It is normally a good habit to surround such pair calls like enter
/leave
with try-finally
. Why? Because someone could accidentally write return within the section. Then (without try finally) the last part is not called. This can cause some debug time, which could be avoided by such a coding habit.
Are there any reasons against it?
This PR is needed to be merged and published on npm for the langium showcase:
eclipse-langium/langium-website#197