fix: "Go to definition" functionality for native LSP

[jbencin]

Description

Fixes: #1829

This PR fixes "Go to definition" functionality for native LSP, which is broken because the following code:

Url::parse(&definition_contract_location.to_string()).ok()

Always returns None for FileLocation::FileSystem paths (because the to_string() output is missing the file:// prefix). This is fixed by implementing TryInto<Url> for FileLocation to do the correct type conversion

Breaking change?

I don't think this will affect the VSCode extension (I'm guessing it always uses FileLocation::Url)

Notes

In a future PR I think we can get rid of FileLocation enum completely and just use Url directly

[codecov]

Codecov Report

Attention: Patch coverage is 37.50000% with 10 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
components/clarinet-files/src/lib.rs	46.15%	7 Missing ⚠️
components/clarity-lsp/src/common/state.rs	0.00%	3 Missing ⚠️

📢 Thoughts on this report? Let us know!

[hugoclrd]

I don't think this will affect the VSCode extension (I'm guessing it always uses FileLocation::Url)

Right, it shouldn't break.
You can give it a try. In component/clarity-vscode run npm i && npm run dev. It'll open a test project in vscode web.

In a future PR I think we can get rid of FileLocation enum completely and just use Url directly

Yes! I agree that the FileLocation is probably not necessary and adds useless complexity

[jbencin]

Right, it shouldn't break

Tried this and goto functionality is still working in VSCode. I don't think it ever uses filesystem paths. Actually, the parts of the Url crate dealing with the filesystem don't even build for this target because it's a no_std environment

[tippenein]