message_buffer_create(1024) returns .data = "" — an empty slice — while reporting capacity = 1024. Any argument, same result.
The existing test passes:
test "lsp_message_buffer_create" {
const buf = message_buffer_create(1024);
try std.testing.expect(buf.capacity == 1024);
}
It reads capacity, which the function simply copies from its argument. It never touches data, which is the field the function would have to earn.
Added as a failing test rather than repaired:
test "lsp_message_buffer_has_the_room_it_claims" {
const buf = message_buffer_create(1024);
try std.testing.expect(buf.data.len >= buf.capacity);
}
The fix is an API decision, not a typing one: the signature takes no allocator, so backing the buffer means changing what every caller passes. That is the owner's call. Until it is made, the red test says what is true.
lsp/protocol now reports 29 passed, 2 failed, both deliberate and labelled in the spec — this, and lsp_completion_request_create asserting a method length of 21 where METHOD_COMPLETION is 23.
message_buffer_create(1024)returns.data = ""— an empty slice — while reportingcapacity = 1024. Any argument, same result.The existing test passes:
It reads
capacity, which the function simply copies from its argument. It never touchesdata, which is the field the function would have to earn.Added as a failing test rather than repaired:
The fix is an API decision, not a typing one: the signature takes no allocator, so backing the buffer means changing what every caller passes. That is the owner's call. Until it is made, the red test says what is true.
lsp/protocolnow reports 29 passed, 2 failed, both deliberate and labelled in the spec — this, andlsp_completion_request_createasserting a method length of 21 whereMETHOD_COMPLETIONis 23.