Release new version of codespan-lsp

[brendanzab]

Release new version of codespan-lsp

[Marwes]

I think it would let a 1.0 to be released, but maybe there are some edge case that isn't handled with this I'd expect that to be rare though, if it happens.

Looks like #[non_exhaustive] doesn't let functional record updates work though, so using the current workaround would be better in this case.

Another drawback is that matching on an enum would need a catch all case, even if no additional variants are ever added.

Should float the idea on the lsp-types repo at least to see what other users think.

[brendanzab]

The crate should be available on crates.io now!

[ebkalderon]

@brendanzab @Marwes Many thanks to you both!

[brendanzab]

Ah! Thanks for letting me know. Wish we had a better versioning strategy for lsp-types that meant we didn't have to bump the versions as much 🤔

[Marwes]

Adding a field is a breaking change in rust but it isn't in JSON so hard to avoid doing breaking releases :/

[Marwes]

Looks like #[non_exhaustive] is in FCP rust-lang/rust#44109 ! Perhaps best to wait for that, otherwise it could be faked reasonably well with a

#[doc(hidden)]
pub non_exhaustive: (),

field. There is an ergonomic hit when constructing the lsp-types however as .. Default::default() will be needed in structs.

[brendanzab]

Yeah I was wondering if something like that could be done. It is a bummer to have the ergonomic fit, but it kind of reflects the fact that the LSP is inherently designed to be forwards compatible to some extent. Could also mean that lsp-types could make it to 1.0?