Consider not using url crate for directory specifiers?

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?

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

@Marwes

This should be fixed now that e3d0ed2 exists in master.

	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,
	}