This crate builds math symbols from a musl checkout and provides a Rust
interface. The intent is that we will be able to compare our
implementations against musl on more than just linux (which are the only
currently the only targets we run `*-musl` targets against for
comparison).
Musl libc can't compile on anything other than Linux; however, the
routines in `src/math` are cross platform enough to build on MacOS and
windows-gnu with only minor adjustments. We take advantage of this and
build only needed files using `cc`.
The build script also performs remapping (via defines) so that e.g.
`cos` gets defined as `musl_cos`. This gives us more certainty that we
are actually testing against the intended symbol; without it, it is easy
to unknowingly link to system libraries or even Rust's `libm` itself and
wind up with an ineffective test. There is also a small procedure to
verify remapping worked correctly by checking symbols in object files.
* Add docstring to Bessel functions
* Add docstrings to logarithm functions
* Add docstrings to pow functions
* Specify argument bit-size of the Bessel functions
* Specify argument bit-size for pow functions
* Specify argument bit-size for logarithms
* Add docstrings to sin, cos, sincos and sinh functions
* Add docstrings to sqrt
* Add docstrings to tan and tanh functions
* Add an inline link to https://en.wikipedia.org/wiki/Bessel_function to the docstrings of all Bessel functions.
Currently everything we have runs with nightly Rust. Add a stable test
to make sure we don't accidentally make use of behavior that isn't yet
stable without gating it.
Duplicate the settings from rust-lang/rust to this repository. This is
mostly for consistency, but `use_small_heuristics = "Max"` does make a
large difference with lookup tables.
Also apply the needed CI changes to run nightly rustfmt.
Currently both Cargo.toml and the license files indicate that this
library may be used under either MIT or Apache-2.0. However, this is not
accurate; since portions of this library were derived from musl libc,
which is available under the MIT license, this terms of use for this
library must also include use under the MIT license. That is, it is not
correct that this library may be used under only the Apache-2.0 license.
Update the SPDX license identifier to `MIT OR (MIT AND Apache-2.0)` to
indicate that use must include the MIT license, but to clarify that
contributions are made under `MIT OR Apache-2.0`. This is compatible
with the current state of this repository since it has always contained
both license files, and the `Cargo.toml` license field has indicated
`MIT OR Apache-2.0` since it was added.
In accordance with the above, replace the two license files with a
combined LICENSE.txt that makes these terms clear and gives attribution
to works from which this library is derived.
Fixes: https://github.com/rust-lang/libm/issues/215
Link: https://rust-lang.zulipchat.com/#narrow/channel/335408-foundation/topic/Request.20for.20legal.20team.20input.20on.20crate.20licensing
Link: https://git.musl-libc.org/cgit/musl/tree/COPYRIGHT
Having `#![deny(warnings)]` for the entire crate is a bit of a
development annoyance. We already run CI with `RUSTFLAGS=-Dwarnings` so
there isn't much of a reason to check this locally. Thus, remove the
attribute.
Additionally, sort the clippy allows.
We will have more test features in the near future, and it would be nice
for them all to have a common `test-` prefix. Reverse the existing
feature so this is the case.
There isn't any reason for this feature to be exposed or part of the
build script. Move it to a separate crate.
We will also want more tests that require some support functions; this
will create a place for them.
I do not think there is compelling reason to release the ci support as
part of a Rust source code package. In addition, the crate, as it is
released now, gets flagged in some security scans due to the presence of
Dockerfiles which are considered to be following some unsafe practices.
Most Linux distros package using the vendored appraoch and provide a
vendor tarfile of an application's dependencies. Scanners will tend to
expect that the contents of the vendor tarfile will be source code.
These Dockerfiles are already being flagged by some scanners; other
contents of the ci directory may be flagged in future.
