-
Notifications
You must be signed in to change notification settings - Fork 536
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
Implement Support for no_std #341
Conversation
This adds a new `std` feature to chrono that is enabled by default. By deactivating this feature via `default-features = false` you can now use chrono in applications that don't use the standard library. The `serde` feature is supported as well. Resolves chronotope#336
Well looks like I definitely need help with that CI script. |
Thank you! I will look at the CI script. |
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've got a couple nits that I'd be happy to take care of if you don't feel like it, otherwise this seems great!
use std::time::{SystemTime, UNIX_EPOCH}; | ||
use oldtime::Duration as OldDuration; | ||
|
||
#[cfg(not(any(feature = "std", test)))] | ||
use alloc::string::{String, ToString}; |
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.
It seems like it might be worth sticking this (and what seems like the two functions that return strings) behind a separate alloc
feature flag?
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 added an alloc
feature now. I'm kind of sad how much is missing without it though. And it's mostly only because the timezone offset is stored as a String in the DelayedFormat.
src/format/mod.rs
Outdated
mod core_only { | ||
/// Core only | ||
#[derive(Debug, PartialEq, Eq, PartialOrd, Ord)] | ||
pub struct Box<T: ?Sized>(core::marker::PhantomData<T>); |
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.
This thing is kind of hacky, but it allows at least partially supporting some of the format module stuff.
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.
Can you explain how/if this actually works/what the runtime experience would be? Or is there some explanation of this pattern somewhere?
Alternatively, would you mind adding some small code to the core test file that demonstrates what this ends up doing?
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.
It's only so the Item enum actually compiles as there's Box<str>
in there. I'm not sure if we even need this enum when alloc isn't compiled in. I honestly don't know what even works in that module at all if DelayedFormat isn't compiled in.
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.
Does the timezone for the DelayedFormat really need to be a String or could it be turned into a &'static str? (I'm not sure if there ever are any truly dynamic timezones that would need String)
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.
Wait, what is OwnedLiteral and OwnedSpace even used for? I don't see them being used anywhere.
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 ended up putting these variants behind the same feature gate, I'm not sure that it will have any effect on usability. Potentially if people were compiling their own format::Item
lists it could have been a thing?
Also with alloc this is now slightly a breaking change as the serde feature is now called Although it requires a semver incompatible version bump anyway, as adding new features such as |
To ensure that we don't accidentaly not verify that chrono compiles for core.
Hm that's a good point, I'll need to think about that. Does SemVer apply to compilation flags? I've taken things out of the --no-default-features install without bumping the patch version before and I'm not sure that I've gotten bug reports about it. This is a much more dramatic change than before, though, so maybe not.
Yeah that's true, but you can rely on optional dependencies as though they're features, so I think that it's fine to just use |
I believe if you activate the serde feature without the alloc feature now, you get weird compilation errors. I guess if it's properly documented that you need to also activate alloc then, it might not be a problem. Or you could even do something like: #[cfg(all(feature = "serde", not(feature = "alloc"))]
compile_error!("For the serde feature you also need the alloc feature."); (this is not the full cfg, as std and test are also valid) |
Yeah that's a good point, I didn't quite realize that it was possible for people to want to be able to use serde without std, but in retrospect it makes sense. |
Just to be clear, you mean that |
I'd be surprised if it works, but I guess it might? I'll check tomorrow. |
Slightly easier to reason about the code via some code movement, printing some banners to make it more obvious when cargo is being run since it is run so many times.
Part of this means that we don't actually need to allocate to write to Serde any more, which is a win in its own right.
I just pushed a change that should remove all intermediary allocation even when the serde feature is enabled. I didn't look into how that plays with the core::box placeholder. I tried to simplify the features, as well, let me know how it feels to you to use this way. |
That does not seem to build if you build with serde and no alloc:
|
Oh, I thought i had fixed that correctly, I'll get it working. |
This seems like it's working on stable, now. The failures had to do with using core in 1.13, which I'm not super interested in debugging unless someone actively wants it. |
Yeah it seems to be working now across all the different combinations :) |
WooHoo! Okay I'd like to see what we can do about the stub core module that you created, ideally we can make it unnecessary. I doubt I'll have any time to look at it before friday, if you're interested. |
Do you still want me to check it? I don't really understand the formatting module enough, but I could take a closer look and try to understand it if you don't have time to look into it yourself. I'd like to get this merged (and released) fairly soon, as the other crates that are blocking me almost all have released new versions and the few remaining are intending to do so within the next weeks. |
This means that a few more features of formatting items don't compile in non-alloc environments, but they wouldn't have worked correctly anyway.
I am happy with this as is now, we can add and improve things as they come up. Thanks for this! |
This adds a new
std
feature to chrono that is enabled by default. By deactivating this feature viadefault-features = false
you can now use chrono in applications that don't use the standard library. Theserde
feature is supported as well.Resolves #336