Consider not using url crate for directory specifiers?

[dsherret]

Consider a workspace folder sent from a client that sends a folder url like "uri": "file:///dev/my-project" (such as what VSCode does).

lsp-types/src/workspace_folders.rs

Lines 26 to 31 in 962604a

	pub struct WorkspaceFolder {
	/// The associated URI for this workspace folder.
	pub uri: Url,
	/// The name of the workspace folder. Defaults to the uri's basename.
	pub name: String,
	}

Given the JSON of that request, this will be deserialize to a url::Url. The problem though is the trailing slash is significant to the Url crate, so the representation in Url is now incorrect because it now considers this a file url rather than a directory. For example, doing .join will not work properly (https://docs.rs/url/2.3.1/url/struct.Url.html#method.join -- "Note: a trailing slash is significant."). A consumer of this crate must then take the url out as a string and normalize it to have a trailing slash (then I believe the consumer must also maintain a mapping back to the original unnormalized value when using this in any responses).

Perhaps it would be better if these values were not deserialized to the url crate's Url representation?

[gibbz00]

uriparse-rs might be a better alternative. rust-url implements https://url.spec.whatwg.org/, not RFC 3986, the latter is the one being used by the LSP Spec:

The URI’s format is defined in https://tools.ietf.org/html/rfc3986

[gibbz00]

@Marwes

This should be fixed now that e3d0ed2 exists in master.