no_std support? - Githubissues

servo / rust-url

URL parser for Rust

https://docs.rs/url/

Apache License 2.0

1.31k stars 325 forks source link

no_std support? #609

Open cbeck88 opened 4 years ago

cbeck88 commented 4 years ago

Would you be interested in patches to make the url library support a no_std build configuration based on the alloc crate instead? I think it should be possible and will make the library more easily portable.

SimonSapin commented 4 years ago

The crate relies on several items from std::net.

cbeck88 commented 4 years ago

I see, thanks

cbeck88 commented 4 years ago

Are there any other blockers to this besides std::net::{Ipv4Addr, Ipv6Addr} and the SocketAddr thing? I understand that in rust std these have different representations on different OS's, and probably need to be in std. But it seems in principle we should be able to parse IPv4 and IPv6 objects without using platform specific code. I'm trying to scope out what would likely be the biggest difficulty.

SimonSapin commented 4 years ago

In theory we could remove DNS resolution support and use custom types to represent IP addresses. B both would be breaking changes, and upgrading the ecosystem to a semver-incompatible version of the url crate takes significant effort.

cbeck88 commented 4 years ago

Wow, I didn't realize it does DNS resolution support as well -- I guess I don't know the full scope of this library. Thank you!

Plecra commented 4 years ago

@garbageslam Do you have specific features from this crate that you're interested in? I'm working on making my redesign of the uri crate no_std, and it'd be great to know what would be useful for you ^^

cbeck88 commented 4 years ago

@Plecra hi -- I think the specific features are,

FromStr, with a standards conforming implementation,
.as_str() or ToString
ways to get and set the scheme, hostname, port, path, query parameters, fragment

I could give you links to show how we are using it right now, but it's probably TMI

pranav-bhatt commented 3 years ago

Perhaps progress can be made once this issue is resolved?

grego commented 3 years ago

Could the features that require std be placed behind a feature gate?

paolobarbolini commented 3 months ago

I see some very interesting progress with core::net in 1.77 and core::error::Error in 1.81.

mspiegel commented 2 months ago

Hi. I have a patch that completes the no_std conversion for the url crate. Some implementation details:

The Minimum Supported Rust Version remains unchanged for the "std" feature (1.56). The MSRV for no_std support is 1.81. This allows the crate to use std:: for the MSRV and use a more modern core:: to provide no_std support.
Several public methods of the API have been moved behind a "std" feature gate. These are: url::Url::socket_addrs(), url::Url::from_file_path(), url::Url::from_directory_path(), and url::Url::to_file_path().

Should I submit a PR to this repository? Feedback would be much appreciated. You can see a draft of the changes over here: https://github.com/mspiegel/rust-url/pull/1/files

madsmtm commented 2 months ago

There's an existing PR for this, see https://github.com/servo/rust-url/pull/831. The current biggest issue is that it's a breaking change, see https://github.com/servo/rust-url/pull/831#discussion_r1434761298