-
Notifications
You must be signed in to change notification settings - Fork 155
Description
Context
In zed-industries/zed#35030 we came across a discrepancy in interpretation of thread ID between Zed and Delve.
Delve sends out a "dummy" thread with a negative ID, whereas Zed expects all thread IDs to be non-negative (they're essentially u64s). We don't mind adjusting our deserialization layer to handle that.
Problem
However, the spec does not actually specify which side is "right". We err on the side of Delve being compliant with the spec, because the spec does not actually specify the numerical ranges of identifiers.
This creates a bad precedent where neither a client nor a server implementing DAP can be sure what's allowed by the spec. Zed can change our u64s to i64s to accomodate for Delve, but there may be a server out there which uses u64::MAX for such cases instead, leaving Zed incompatible with at least one DAP server.
Solution
It would be great if the specification explicitly defined ranges of allowed values for IDs. Language Server Protocol has set a precedent which is very helpful when interpreting the spec. I think DAP should follow suit.