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.
