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.

Sign up for GitHub

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

Add isObject check to ProblemMarker #12251

Closed
wants to merge 1 commit into from
Closed

Add isObject check to ProblemMarker #12251

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions packages/markers/src/common/problem-marker.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,7 @@

import { Marker } from './marker';
import { Diagnostic } from '@theia/core/shared/vscode-languageserver-protocol';
import { isObject } from '@theia/core/lib/common';

export const PROBLEM_KIND = 'problem';

Expand All @@ -24,7 +25,7 @@ export interface ProblemMarker extends Marker<Diagnostic> {
}

export namespace ProblemMarker {
export function is(node: Marker<object>): node is ProblemMarker {
return 'kind' in node && node.kind === PROBLEM_KIND;
export function is(node: unknown): node is ProblemMarker {
return isObject<Marker<object>>(node) && node.kind === PROBLEM_KIND;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this is correct: shouldn't we assert it's a marker first? Right now an object like this wold fit the bill:

{
   kind: 'problem'
}

would fit the bill, even though it's not a marker. But asserting ProblemMarker.is(foo) implies that it's a marker, typing-wise.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tsmaeder I agree, the code is very optimistic. But the previous code did the same assumption.
So I would suggest to tackle this improved marker assertion in a separate ticket.

Copy link
Member

@msujew msujew Mar 2, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, during the runtime, yes. But from a static analysis perspective, it assumed that the node already is a Marker<object>. So we should confirm that as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the static typing problem stems from #12253. That is a considerably bigger fish to fry, though, and it would be asking to much from a PR to fix a concrete problem. @msujew what are you suggesting, concretely?

}
}