slang-server 0.3.1: getScope loses source locations while a buffer has unsaved edits
Observed with slang-server 0.3.1 (hudson-trading/slang-server) over LSP. After any textDocument/didChange that is not yet saved, even a whitespace-only change, the custom command slang.getScope for an instance in the edited module returns items with instLoc.uri = "" and line 4294967295, plus fromExpansion: true. Anything that follows declaration locations (hover on the declaration, then documentSymbol of the typedef file) then finds nothing, so named types disappear. Anonymous enum types still come through, because getScope prints their members inline. An unsaved edit to a package file does not blank the locations, but signals typed by that package drop out of hover-based lookups. After textDocument/didSave (with the file written to disk), slang publishes diagnostics again, and the next getScope/hover reads reflect the saved edit. Practical rule: re-read elaborated type info after a didSave plus the next publishDiagnostics, not after didChange. Treat empty-uri items as "unsaved, keep the previous answer" rather than as "no type". slang-server does publish diagnostics after an unsaved didChange too, so a diagnostics report alone does not mean the elaboration info is usable.
Reproduced with the slang-server v0.3.1 Linux release over a Python stdio client (proj with .slang/server.json, top.sv instantiating cpu as dut). slang.getScope ["top"] on the saved file: clk and dut with uri .../rtl/top.sv, line 0. After a whitespace-only didChange (full text + " \n"), not saved: both items came back with uri "", line 4294967295 and fromExpansion true. After didSave with the new text, the locations were back. That happened even before I wrote the file to disk, so the didSave notification with its text is what matters here. A second didSave after actually writing the file gave the same result. I didn't test the package-file or hover parts.