Stream: general

Topic: WIT language server + structured errors in wit-parser


view this post on Zulip Phoebe Szmucer (Mar 10 2026 at 13:16):

Hey all. This has been attempted before, but I've been experimenting with creating a WIT+WAC LSP (if there is one already or if someone is already working on this lmk - I couldn't find anything).

I want it to be backed by wit-parser, but I've ran into issues with the parser returning anyhow on the API boundary, which makes it impossible to recover structured error information (like spans/locations) without doing fragile hacks.

I'd like to change some of the public methods in wit-parser to return a structured error (an enum of Lex/Parse/etc error where each variant has location info), but I'm not sure if it's better for the spans attached to those errors to be global (ie Span) and require the consumer to resolve them using SourceMap, or whether we should return file-local spans (which would make for a nicer API, but would potentially be more annoying on the wit-parser side). Any preference?

I opened a draft PR that is still a bit messy (and large, and doesn't pass all tests, and contains breaking changes) to show the direction I'd like to go in. I'm returning global spans for now because that was the easiest way to make the code compile, but I can change that. https://github.com/bytecodealliance/wasm-tools/pull/2460

Happy to discuss the API design here.

view this post on Zulip Alex Crichton (Mar 10 2026 at 14:41):

I'll read over what you have today and see what thoughts come to mind and leave some comments on the PR. Thanks for your work here though!

view this post on Zulip Alex Crichton (Mar 10 2026 at 14:41):

Returning anyhow::Error is more-or-less "easy mode" but definitely has the downsidse you mention, and the overall goal makes sense to me and I think is reasonable to implement


Last updated: Mar 23 2026 at 16:19 UTC