The int_uint feature does not exist anymore in Nightly, using int or uint types, or u or i suffixes is now always an error. Let’s get rid of this one before the next rustup. (Simply use usize and isize types, and remove suffixes if possible or use _usize or _isize).

https://gist.github.com/Manishearth/967bc78db5c751c38d03

I'd avoid slice_patterns since it has so many open memory safety bugs.

I updated the list above, and submitted #16681 and #16680 to remove some unnecessary feature uses.

Now the only uses of the core_intrinsics feature are:

• Expose a stable way to use the breakpoint intrinsic. rust-lang/rfcs#775: breakpoint (used in script::dom::window::WindowMethods::Trap)
• Expose the type_name intrinsic rust-lang/rfcs#1428: type_name (used in debug-only output in JS::trace)

Should we propose stable wrappers for these?

I think the list above was created / is maintained by grepping this repository, so I also had a look at dependencies.

TL;DR: there’s stuff that’s being removed, stuff we can disable, and a couple things in rust-mozjs.

To do so, I ran cargo stable build -j200 repeatedly in the ports/servo directory. The tries to build servo with a stable compile which quickly fails, but makes Cargo schedule as many jobs as the dependency graph allows before that happens. With enough repetition, I think this compiles every crate that can be compiled, leaving only Compiling foo… lines only for those that cause build errors. I then looked at those that were crates.io or git dependencies (i.e. everything not in this repository).

• Some crates had a Cargo feature flag named unstable or nightly that enable optimizations but apparently not library features that we require:
  • In euclid it uses asm and repr_simd features to enable a SideOffsets2DSimdI32 type… that we don’t use, as far as I can tell.
  • In tendril (through html5ever and xml5ever) it uses the nonzero feature to enables Option<Tendril<…>> memory layout optimization.
  • In parking_lot it uses integer_atomics and asm for optimizations (and const_fn to make some fns be const, but we don’t rely on that).
• multistr uses never_type. That can be replaced with the void crate: https://github.com/clarcharr/multistr/pull/2
• parse-hosts uses type_ascription. That can be replaced with specifying a type parameter in a method call. (I’ll send a PR once the multistr one lands).
• js a.k.a. servo/rust-mozjs uses const_fn, nonzero, and link_args.
  • It looks like we do rely on at least one constructor being const, so not much to do here besides nudging const fn tracking issue (RFC 911) rust-lang/rust#24111
  • I think NonZero can be replaced with std::ptr::Shared, which might be stabilized Soon^®: Tracking issue for NonZero/Unique/Shared stabilization rust-lang/rust#27730 (comment)
  • The crate still builds with #![feature(link_args)] commented out. Do we not use it anymore? Was it stabilized?

I think that’s everything. I’ve update the original comment for unsolved stuff.

For const_fn in rust-mozjs we could in theory expose a macro instead of a const fn, but as far as I can tell these new_bitfield_* constructors are generated by rust-bindgen. For nonzero we could have a Cargo feature flag like Tendril to use a no-op wrapper struct instead of NonZero when disabled, but this may not be worth the bother.

With #18854 it’s now possible to disable the use of some unstable features with ./mach build --no-default-features --features default-except-unstable

What is Servo doing with/out box_patterns for match statements?

@jadbox We removed our use of that feature.

It is worth noting that SIMD and other cpu extensions have been stabilized on x86/64 since 1.27 !
https://www.infoq.com/news/2018/06/rust-1.27-simd-support

@LifeIsStrange Yes, but std::arch contains individual architecture-specific instructions whereas components/gfx/text/glyph.rs uses the portable u32x4 type. Using the former is a lot more involved. The latter is under discussion to be stabilized in the standard library eventually rust-lang/rfcs#2366.

Closing since this is out of date and I’m not convinced taking the time to keep it up to date is all that valuable. We can revisit after the main blocker (compiler plugins) is solved.