Description
The freshly released 0.6.6 version (#20) causes this Travis-CI build to fail: https://travis-ci.org/google/OpenSK/builds/645900468
Checking linked_list_allocator v0.6.6
error[E0432]: unresolved import `alloc::alloc::AllocRef`
--> /home/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/linked_list_allocator-0.6.6/src/lib.rs:14:20
|
14 | use alloc::alloc::{AllocRef, AllocErr, Layout};
| ^^^^^^^^ no `AllocRef` in `alloc`
error: aborting due to previous error
This may be due to the fact that we pin a specific Rust toolchain - which didn't have the AllocRef symbol yet (indeed, the renaming in rust-lang/rust#68529 and rust-lang/rust#68736 was very brief, not leaving much time to migrate to the new name).
One could argue that given that the allocator API in unstable (#[unstable(feature = "allocator_api", issue = "32838")]) such breakage is expected from Rust's stdlib side.
On the one hand, linked-list-allocator >= 0.6.6 doesn't compile with old versions of Rust nightly. On the other hand, versions of linked-list-allocator < 0.6.5 won't compile anymore on new Rust nightlies due to the new name.
This seems to me like it could qualify as a semver breakage, as version ^0.6.5 can mean either 0.6.5 or 0.6.6 (depending on when one updated their crates), but in all cases (except the few days between rust-lang/rust#68529 and rust-lang/rust#68736 where Alloc and AllocRef both existed) either 0.6.5 or 0.6.6 won't compile (depending on the liballoc in the toolchain).
If instead a new 0.7.0 version is released and 0.6.6 is yanked, dependents of linked-list-allocator can choose between 0.6.x and 0.7.x according to their toolchain.