Request textDocument/documentSymbol failed. Error: name must not be falsy

[ColinBroughNHS]

Tried to compile some legacy ObjectScript code via Import/Compile in VS Code using the vscode-objectscript extension. Getting an error, and the content of the file is left changed on the filesystem.

We think the error occurs when you have a commented out Property line, with no space after the '//' comment starter. But we've not completed isolated the situations where it occurs. Couple of screenshots attached - first is a before compilation / after compilation of a simple test file, showing what state the extension leaves the file in after an attempt to compile. Second is of the Output tab in VS Code for the extension detailing the error. We only stumbled into this yesterday, so still gather information about when it occurs / doesn't occur. We will be continuing to try and narrow down exactly what combination of syntax triggers the problem, and try and post any clarifying updates here.

[ColinBroughNHS]

Should have added, version of the ObjectScript extension is 3.0.1 and of the Language Server is 2.7.2 (we've got the extensions set to auto update).

[ColinBroughNHS]

Brett, all that is really helpful. 2 and 3 make sense.

On 1, I'm left confused! More by how we got to where we are, rather than by what you are saying...

As I said, we've thousands of class files in our repo which do not appear to have been serialized as you describe above - despite them coming out of a our live production via the Management Portal Classes -> Export route, which should have serialized them (and checks today on specific files confirm they do come out as expected). So, we don't know how we got to where we are and we've got a repo clean-up task to pursue - aargh! Lots of things like the screenshot below - repo version on the left, version once the extension has seen it / its been serialized...

Thanks for prompt engagement - and if I ever do come across what triggered the original error message I'll let you know!

[isc-bsaviano]

Maybe someone edited those classes without a server connection? You can do that refactoring using IRIS pretty easily. All you have to do is a $SYSTEM.OBJ.ImportDir() on the parent directory and then $ORDER through the array of imported files, calling $SYSTEM.OBJ.ExportUDL() on each one. No compilation is required, so you can do this in a scratch namespace or using a Community Edition container.

[ColinBroughNHS]

Managed to reproduce steps to generate the error I first came across:

1. In VS Code, open a new class file
2. Start typing a comment which starts with '//', then hit enter (I think can either be a space after the '//' or text with no space)
3. Type "Property " (don't use one of the pre-built options for Property)
4. At this point the error shows - file has not been saved, but I captured a screengrab.
5. If you subsequently edit the file, even re-doing the edits from an apparently similar starting point, the error does not show up - so far I've only seen it on a newly created file on first edit...
6. 21Mb of log file captured...

Uploading 2025_04_11_InterSystemsLanguageServer.log…

[isc-bsaviano]

Thanks for the reproduction steps! I was able to get a class in the state shown above (Property colored correctly despite having no name), but I have not been able to get the error to happen. It looks like your logs failed to upload as well. Can you open the log file and remove everything before the textDocument/documentSymbol request that triggered the failure? That should make the log much smaller. I'm hoping the log will contain the array of document symbols that failed validation.

[ColinBroughNHS]

OK, cut down log, attempt 2! I've removed everything before the preceding successful textDocument/documentSymbol request, and then in a couple of places replaced a long list of class names sent back in a intersystems/server/makeRESTRequest response with "***** LONG LIST OF CLASSES REMOVED FOR BREVITY *****"

I'm not sure if I've mentioned, but we are using Ensemble 2018.1, rather than a more recent Iris variant, if it makes any difference. It is there in the logs.

If you need the full log I can put it up on a WeTransfer link or similar.

2025_04_11_InterSystemsLanguageServer_A.log

[isc-bsaviano]

Thanks for that Colin! That is exactly what I needed. This is really strange. I am able to create the same behavior on my Mac (a Property with no name), but I don't see an error! VS Code happily accepts a document symbol with a single space for a name. This is independent of the ISC server version and should be independent of platform. I tested this on VS Code 1.99.2 and today's build of VS Code Insiders. I am going to open a Language Server issue for this, link it to this discussion, and add some defensive code so it doesn't return a symbol with an invalid name.

[isc-bsaviano]

@ColinBroughNHS Does this version of the Language Server extension still have the issue?
language-server-2.7.3-SNAPSHOT.vsix.zip

[ColinBroughNHS]

@isc-bsaviano, tried the language server snapshot you provided this morning, and I'm now not getting the error.
Behaviour is as you describe - a Property with no name, highlighted in blue, but (now) no error.
I've not bothered to collect further logs, but am happy to do so if that'd help.

FWIW, I'm on Windows 10 Enterprise Version 22H2 (OS Build 19045). VS Code is 1.99.2, Electron 34.3.2, Chromium 132.0.6834.210, Node.js 20.18.3.

Thanks for your help with this - both in helping us understand the correct behaviour around canonical code, as well as tracking down the error showing in the extension.