Move libm bindings into separate crate

[anatol]

It is a followup for #39473

There is Rust cleanup activity that aims to move complex, platform-specific dependencies outside of std. For examples libc bindings were moved to its own crate and std links to it.

It worth checking if similar thing can be done for libm dependency. Decoupling libm library from std has advantages:

• clear interface between the libraries
• external libm will have its own release cycle independent of the Rust one. If there is a bug in libm crate then it can be released separately without waiting for a new Rust release.
• external libm has more freedom over its implementation. Initially libm is going to be just a wrapper over system shared library. But it is be possible to create a version that statically links to openlibm and avoid dynamic linking. It would be great to see a libm version implemented fully in Rust, similar to what math.rs tries to achieve. And users could switch between libm implementation depending on their requirements.

Another question - do math functions like hyperbolic cosine need to be part of std at all? Would it make more sense to remove libm dependency from std completely and let users plug math crate manually instead?

[nagisa]

Another question - do math functions like hyperbolic cosine need to be part of std at all? Would it make more sense to remove libm dependency from std completely and let users plug math crate manually instead?

This question is irrelevant, because LLVM can and will lower trivial-er operations to library calls anyway. You’d have to remove pretty much every single associated method on floats to make it viable to remove the dependency on libm.

[steveklabnik]

Triage: @japaric has created https://github.com/japaric/libm. Would it be useful in fixing this bug?