-
Notifications
You must be signed in to change notification settings - Fork 326
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no_std
support for the url
crate
#831
base: main
Are you sure you want to change the base?
Conversation
Add default feature flag "std" that enables a `std::error::Error` impl for `Errors`.
Went for |
I spent some time trying to get the trait `Serialize` is not implemented for `Ipv6Addr` |
If it breaks stable, that's obviously a no-go. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #831 +/- ##
=======================================
Coverage ? 81.85%
=======================================
Files ? 21
Lines ? 3560
Branches ? 0
=======================================
Hits ? 2914
Misses ? 646
Partials ? 0 ☔ View full report in Codecov by Sentry. |
It should not break stable, it should only "break" |
Moving to |
Since I do need the nightly version, but I can see why some people wouldn't, I added two features:
Else we can wait until the features get stabilised. |
idna/src/uts46.rs
Outdated
@@ -453,7 +453,7 @@ impl Idna { | |||
return Errors::default(); | |||
} | |||
let mut errors = processing(domain, self.config, &mut self.normalized, out); | |||
self.output = std::mem::replace(out, String::with_capacity(out.len())); | |||
self.output = core::mem::replace(out, String::with_capacity(out.len())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI, this fixes a bug in the current idna
no_std support. Why is it not caught in CI, and should I open an extra PR for it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recently dabbled with no_std
stuff as well and I think the sure-fire way to test no_std
compatibility is to:
- target a platform that does not have
std
(certain ARM platforms) OR - have a really simple
no_std
binary crate which uses the libraries
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I'm trying it with cargo +nightly build -Zbuild-std=core,alloc --target aarch64-unknown-none -v --release --no-default-features
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you split this off into a separate PR?
Any news on this? :) |
Error has since landed in core. |
url/src/lib.rs
Outdated
extern crate alloc; | ||
|
||
#[cfg(not(feature = "alloc"))] | ||
compile_error!("the `alloc` feature must be enabled"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue: we should just not have an alloc feature, and unconditionally use alloc::Foo
and core::Foo
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to change it, however I assumed a subset of features may be possible without alloc - and then introducing those will be another breaking change. Adding a feature flag to Crates.toml isn't a lot of work for users
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, all other crates like idna and data-url already have the alloc feature
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we wish to preplan for that I am happy to do so if someone can sketch out a viable plan for it, otherwise it feels like a premature optimization.
Furthermore as I said before adding new default features is typically not considered breaking in the ecosystem, and I do not consider it breaking here.
A very similar discussion is going on over at thiserror: dtolnay/thiserror#304 |
CI is broken I want to merge this only if @valenting also approves of the approach here. |
I downloaded all the 186 possibly affected crates as determined by #831 (comment) (i.e. reverse-dependencies of Results:
I won't comment on whether that's an acceptable amount of breakage or not (I don't maintain this crate, so I don't really know what the general expected breakage is from any change), but it would be fairly actionable to go and submit PRs to fix these (I'm not motivated enough to do it myself) ( |
Oh, thank you so much for doing that work! That does give me some pause but yeah if we know which crates are doing it it's easy to patch out. |
I'm happy to open PRs to a handful of repositories, but since right now we don't have the std feature in url, we can't really do anything |
They just have to remove |
In order to make the rust-url compatible with no_std, the crate needs to introduce a `std` feature and make it default. See servo/rust-url#831. In order to reduce impact, downstream libraries should leave url's default features enabled (no other features are currently `default`).
In order to make the rust-url compatible with no_std, the crate needs to introduce a `std` feature and make it default. See servo/rust-url#831. In order to reduce impact, downstream libraries should leave url's default features enabled (no other features are currently `default`).
In order to make the rust-url compatible with no_std, the crate needs to introduce a `std` feature and make it default. See servo/rust-url#831. In order to reduce impact, downstream libraries should leave url's default features enabled (no other features are currently `default`).
In order to make the rust-url compatible with no_std, the crate needs to introduce a `std` feature and make it default. See servo/rust-url#831. To reduce impact, downstream libraries should leave url's default features enabled (no other features are currently `default`).
In order to make the rust-url compatible with no_std, the crate needs to introduce a `std` feature and make it default. See servo/rust-url#831. To reduce impact, downstream libraries should leave url's default features enabled (no other features are currently `default`).
In order to make the rust-url compatible with no_std, the crate needs to introduce a `std` feature and make it default. See servo/rust-url#831. To reduce impact, downstream libraries should leave url's default features enabled (no other features are currently `default`).
Opened the PRs mentioned in #831 (comment) |
In order to make the rust-url compatible with no_std, the crate needs to introduce a `std` feature and make it default. See servo/rust-url#831. In order to reduce impact, downstream libraries should leave url's default features enabled (no other features are currently `default`). Signed-off-by: Dominik Maier <[email protected]>
In order to make the rust-url compatible with no_std, the crate needs to introduce a `std` feature and make it default. See servo/rust-url#831. In order to reduce impact, downstream libraries should leave url's default features enabled (no other features are currently `default`).
The PRs in both crates have since been merged :) |
In order to make the rust-url compatible with no_std, the crate needs to introduce a `std` feature and make it default. See servo/rust-url#831. To reduce impact, downstream libraries should leave url's default features enabled (no other features are currently `default`).
This extends/rebases/fixes #717.
All checks seem to pass.
For
no_std
support, however, as mentioned in #717, this still needs a bunch of fixes. Specifically, It looks like we'll have to use theip_in_core
nightly feature, or use this crate: https://docs.rs/no-std-net. I'd personally opt for nightly, as it looks like it will be merged eventually, but I could do both./edit: For future reference, in the meantime,
net
and theError
trait have made their way intocore