No std?

[Restioson]

I assume this doesn't support no std. What work needs to be done to make it support it? I would be happy to do it with direction.

[dragostis]

This is an interesting feature and I'm up for putting this under a compilation flag, or even making it completely std-free.

Off the top of my head, these are the few things that might not be available in core:

• Procedural macros (which are mandatory; there's no way to replace this)
• pest's few depedencies (might be possible to open PRs)
• Iterator usage in Pairs

Happy to seea PR with this in case it proves feasible.

[Restioson]

Are procedural macros not available in core? We'll have to check this. Iterators are all fine, and dependencies should be able to be ported.

[Restioson]

@dragostis killercup says that proc macros should be fine as long as they don't generate code that is no std

[dragostis]

Then, it might be possible. The derive might be a bit more complicated since it uses collections and boxes, but I do not necessarily think that having derive be no std is a good idea, since it's supposed to have access to higher level constructs. Same goes for meta. However, cargo's reliance on building everything from source might be an issue here.

[Restioson]

Collections are fine, we can get most of those from alloc.

[dragostis]

I see. It's worth a shot. Is there any reason why meta and derive should also be no std? I envision a future where these crates will be mere binaries downloaded for code-generation purposes. However, the current situation is different and I see no significant progress in this direction.

[Restioson]

I don't know what meta and derive do, but derive seems like it's just a derive macro, so it shouldn't need nostd.

[dragostis]

Meta basically parses the pest grammar and does optomizations. It's part of the whole code generation process that the user should not see.

[Restioson]

If it only generates code then probably not. All code generated/all code included (as library code) needs to be no std iirc.

[jstnlef]

I guess I'm confused as to what's the drive for no std? I mean, there's a wonderful std included with rust. Seems a shame not to use it? Are you looking to do some heavy parsing on embedded devices or as part of an OS kernel?

[Restioson]

Yes. I want to use pest to parse AML for the acpi library (rust-osdev/acpi). It's not a thing of "we should use it because it's nice", it's a thing of it being better to be versatile by using the smallest subset of the stdlib possible (core is just useful stuff like iterators, alloc is heap things, and std is both but with OS functions) to be portable. Most of std is re-exported from core, anyway, such as iterators, from, try from, closures, all the nice traits, etc. Essentially, std = core + alloc + os functions, so core = std - alloc - os functions, which is basically all of the nice stuff in the stdlib anyway 😃

[jstnlef]

So I guess the idea is grab the dependencies from core + alloc + proc_macro specifically? That should be fine. Especially since, fairly recently, we're no longer depending on OS functionality from libc.

[Restioson]

Yeah, exactly.

[Restioson]

Started on this here. Derive macro works and is ported! Tested on some grammar I found in the book:

field = { ('0'..'9' | "." | "-")+ }

[jstnlef]

So this might be a dumb question, but why wouldn't you want to just use the non-std imports all the time? Especially since it seems that std is just re-exporting the names from their underlying modules?

[Restioson]

@jstnelf for the derive macros we can't, since core and alloc aren't available in std builds (so we'd get an undefined reference). For the other crates we can.

[Restioson]

@jstnlef actually in general we can't, since no std requires nightly (alloc is unstable, etc).

[Restioson]

I've mad a bit more progress on this. So far the only thing I've run into is that all the stuff from alloc isn't in the prelude anymore, so what's needed has to be use'd in ever file. This could be a bit annoying to maintain, perhaps? Any ideas? I wish this was merged...

[Restioson]

[jstnlef]

@Restioson That's fine. I actually don't have a lot of experience with running Rust in an non-std env so I would defer to your judgement.

[IsaacWoods]

Could you maybe make a module that pub uses all the stuff you need from alloc, which you could then include conditionally? Bit messy, but it should work

[Restioson]

I have that in mod std? Basically it's a facade that looks and feels like std.

[dragostis]

I've tentatively marked this as abandoned. If anyone is curious to give this a try, let me know.

[Restioson]

Not gonna lie, I completely forgot about this. I can try do more work on this probably soon.

[flying-sheep]

Hi, one year later: I’d still be interested in this 😄

[CAD97]

For tracking purposes, leaving this open until we publish a new version.

[tomtau]

@CAD97 is it ok to close this issue? It seems it's already supported, it's just not released on crates.io. Ideally it'll be released on crates.io eventually, but in the meantime, whoever needs no_std could specify to depend on the git repository instead of crates.io?

[CAD97]

I concur that going ahead and marking this as completed is reasonable.