VSCode ObjectScript Language extension parsing errors

Question

Question

Victor Gordillo · Nov 11, 2022

Hi guys,

Open question for all of you...

We are getting some warnings in our code of a class definition when switching namespaces in the code, because the classes we use in different namespace wouldn't exist in each other's... an example:

ClassMethod DoSomething() {
     set oldNS=$zutil(5)
     znspace "SECONDNS"
     set ok=##class(MyPackage.MyClass).MyMethod()
     znspace oldNS
}

In that example, the vscode "Intersystems Language Server" extension would tag "MyPackage.MyClass" as a problem because that class only exists in the second namespace.

Besides the simple nuisance that this can cause, it can become a problem because might force the developer to start ignoring the problem warnings provided by vscode, and some other important ones could be lost there...

Is this something that can be fixed anyhow? Is there any place we need to report this? Is it possible that a sort of special tag can be place in the code line to tell the parser to ignore the problem such as a ##; /whatever (not ideal but could do as a workaround)?

Thanks a lot in advance

Product version: IRIS 2022.1

$ZV: IRIS for UNIX (Ubuntu Server 20.04 LTS for x86-64) 2022.1 (Build 164U) Tue Apr 5 2022 01:46:28 EDT

Discussion (7)1

Log in or sign up to continue

Alexey Maslov · Nov 15, 2022

When I inserted your sample call of %apiOBJ nothing bad happened with the parser, maybe the update would help yours. Meanwhile, more standard way of doing the same:

  do $system.Status.DecomposeStatus(sc,.err,"-d")

is apparently better supported with VS Code: pop-up help and parameters prompting are rather handy, aren't they?

0 0

score 1 · Answer 1 · 2022-11-11T12:26:39-05:00

Previously raised at https://github.com/intersystems/language-server/issues/77 and in several other issues that were marked as duplicates of this.

score 0 · Answer 2 · 2022-11-14T11:53:46-05:00

Following the threads that John posted on his reply, I understood that ISC is not going to pursue a solution for this, due that on the parser, they cannot assert accurately the namespace that is being referenced, something, I cannot understand very well as a developer, since that is only true if the namespace is being specified as a variable instead of a hardcoded value, as in my example code...

Besides the above, I also noticed that the parser also fails when calling a %SYS routine as in:

do DecomposeStatus^%apiOBJ(sc,.err,"-d")

Is that also not going to be corrected?

score 0 · Answer 3 · 2022-11-18T03:50:57-05:00

Besides the above, I also noticed that the parser also fails when calling a %SYS routine as in:
do DecomposeStatus^%apiOBJ(sc,.err,"-d")

@Victor Gordillo please clarify what you mean by "the parser fails". Maybe with a screenshot?

InterSystems deletes the source code of many %-routines before shipping, including %apiOBJ. Perhaps this is causing the problem you are seeing.

score 0 · Answer 4 · 2022-11-18T12:00:10-05:00

Hi John,

Thanks for the reply. Sure, I can paste here what I mean:

When using a system % routine, we get the line underlined as an error, and it is shown under the "Problems" of the class.

If for any reason, we reference a system class that actually contains itself some %references, for some reason, the vscode syntax checker also fails like this, even if we do not actually open that file, the vscode seems to check it anyways:

Notice how the Problems tab is not populated with some core classes problems.

I believe this happens when the #dim is used actually.

score 0 · Answer 5 · 2022-11-16T12:07:25-05:00

Have you tried the old trick of running your code inside an execute (X) command? (I sometimes do that for code that only works in non-cache platforms, like DSM, to stop the cache compiler complaining.)

score 0 · Answer 6 · 2022-11-17T11:07:51-05:00

Hi Mike, thanks for the reply!

Well, I am sure that would also work, yes... and also, there is the workaround of using the $classmethod instruction, and neither of them would break the parser...

But the point of the parser itself is to prevent problems from happening in the first place, so if we "hide" our code inside something, then we lose the ability of the editor to warn us from errors in a proactive way...

The one problem on the "%" calls is actually very annoying, since the problems are even also reported on %SYS core classes when they are being referenced in your code, since the VSCode seems to search for problem inside them once you reference them...