I only just realized that this crate only works on nightly if the feature std is not enabled. It should be possible to hide these unstable things behind a feature, right? Adding a feature called nightly and just not reexporting any unstable things if that feature is not enabled. Or am I misunderstanding something?
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
That will depend on the script detecting which features are unstable and can safely be re-exported. Not sure if that's feasible yet, but I can check later.
All unstable modules are now only re-exported if used with the "unstable" flag! The small, though unstable, alloc prelude is now copy-pasted to avoid depending on the module. Before I release 0.1.2, mind checking if this works well for you?
I get this error. Dependency is no-std-compat = { git = "https://gitlab.com/jD91mZM2/no-std-compat/", features = ["alloc"] }.
Compiling no-std-compat v0.1.1 (https://gitlab.com/jD91mZM2/no-std-compat/#3ba40f4f)error[E0432]: unresolved import `__alloc::slice::SliceConcatExt` --> /home/lukas/.cargo/git/checkouts/no-std-compat-f7c23488b2e6b399/3ba40f4/src/generated.rs:129:13 |129 | slice::SliceConcatExt, | ^^^^^^^-------------- | | | | | help: a similar name exists in the module: `SliceConcat` | no `SliceConcatExt` in `slice`
Also note that you should probably release it as 0.2.0 as (if I see it correctly) you remove things from the API.
I think the original semver says 0.x.y means "anything goes", but I also think you're right rust guidelines just shift the x.y.z down one position.
Anyway, hilariously enough I forgot to run generate.py before pushing. And then somehow I must've forgotten to compile it with the alloc feature on stable rust. Working on making sure I don't do that mistake again.
Have you considered asking in the repo to include your crate? I mean no-std-compat crate really sounds like a good idea and that everyone should be using it instead of writing their own compatibility layer. The repo I linked is an example project for no-std libs.
Have you considered porting generate.py to Rust and run it as a build script? Then the generation runs while compiling which seems like a better idea than to push generated stuff to git. Just a suggestion though.
Have you considered asking in the repo to include your crate?
Never heard of that example before, but I could make a PR, sure!
Have you considered porting generate.py to Rust and run it as a build script?
It's an interesting idea which I haven't thought of! But, the generation is currently quite hacky and I wouldn't be surprised if a future rust version breaks it. Therefore having everyone get their own generated.rs file will lead to even more random issues with this crate being outdated, or being unable to reproduce certain issues.
Sure, I could try make it less hacky, I.E. by using a proper Rust parser. The problem is, however, that it takes a lot of time for very little gain. Even if a proper parser will handle things like commented #![unstable] attributes, there'll still be the issue of having #[unstable] be at the module declaration and not in the module file - and then fixing that would take even longer than it would currently (just add a grep).