Added read_entry_boxed_in and get_boxed_info_in that use the allocator_api

[phip1611]

This closes #483. It builds on the foundation created in #559.

It adds the methods read_entry_boxed_in and get_boxed_info_in that need the new unstable_alloc feature. Dir::read_entry_boxed and File::get_boxed_info will work with both, stable and nightly Rust (i.e., default allocation and allocator api).

However, there is one problem: We need to discuss how we integrate unstable features into cargo xtask build/test.

I tested it manually, but we need to test in CI if everything builds with unstable_alloc and without.

Checklist

• Sensible git history (for example, squash "typo" or "fix" commits). See the Rewriting History guide for help.
• Update the changelog (if necessary)

[phip1611]

I noticed that we need to discuss the role of cargo xtask regarding the stable/unstable functionality. Please have a look at the code - I'd suggest reviewing it commit by commit.. what do you think?

[nicholasbishop]

Is a separate feature needed? In #584 (comment) you suggested having a generic unstable feature for all the non-stable stuff, which I think makes sense.

[phip1611]

Eventually, we might end up with

#![cfg_attr(any(all(feature = "unstable", feature = "alloc"), all(feature = "unstable", feature = "foo")), feature(foo))]

and I'd like to prevent that.

Without the separate feature, right now, we'd need #[cfg(all(feature = "alloc", feature = "unsafe"))] at multiple places..

What do you think? @nicholasbishop

Especially, the long form of #[cfg(not(feature = "unstable_alloc"))], hence, #[cfg(not(all(feature = "unstable", feature = "alloc"))] is ugly. :/

[phip1611]

We could also structure it a little different so that users will only need to activate unstable but we still can use "combined features" internally.

For example, unstable = ["unstable_alloc", "unstable_foo"] and unstable_alloc = ["alloc"]? But in that case, unstable would force users to enable alloc..

[nicholasbishop]

I agree the cfg syntax gets quite ugly as it gets longer, but all the same it's an internal detail that doesn't affect end users, and I wouldn't expect long ones to be needed all that often. The first example you gave is indeed quite hard to read, but I don't think #[cfg(all(feature = "alloc", feature = "unsafe"))] is all that bad.

If in the future we find it's getting too unwieldy, we could also use macros to take out some of the boiler plate. But for now I'd rather start simple with just the unstable feature and only worry about complex cases if and when we encounter them.

[phip1611]

I agree the cfg syntax gets quite ugly as it gets longer, but all the same it's an internal detail that doesn't affect end users, and I wouldn't expect long ones to be needed all that often.

Okay, then let's take this way.

[nicholasbishop]

This job can be dropped, the build variations are covered by #590. (The new test-without-unstable job is still needed though, or maybe we could just have one test job that always enables the unstable flag? That's what we currently do with flags like alloc.)

[phip1611]

The problem is, that the unit test for the make_boxed utility has different behavior with and without the unstable feature. I add a comment to the CI step to make it more clear.

[phip1611]

Please review again @nicholasbishop

[phip1611]

TODO @ me: create ticket