This alias was added in 9897bfb8a ("Fix memset arguments for MSP430
target"), which predates `core::ffi`. Now that it exists we can just use
`core::ffi::c_int`.
```text
warning: function `f32_to_bits` is never used
--> libm/src/math/support/float_traits.rs:367:14
|
367 | pub const fn f32_to_bits(x: f32) -> u32 {
| ^^^^^^^^^^^
|
= note: `#[warn(dead_code)]` on by default
warning: function `f64_to_bits` is never used
--> libm/src/math/support/float_traits.rs:381:14
|
381 | pub const fn f64_to_bits(x: f64) -> u64 {
| ^^^^^^^^^^^
warning: `libm` (lib) generated 2 warnings
```
This is a false positive, see RUST-144060.
This CI workflow will run the https://github.com/rust-lang/josh-sync
tool on Mondays and Thursdays. It will try to do a pull (sync stdarch
changes from rust-lang/rust into this repository). When it runs, three
things can happen:
- There are no rustc changes to be pulled, the bot does nothing.
- There are some new changes to be pulled. In that case, the bot will
either open or update an existing PR titled "Rustc pull update" on this
repository with the changes. After the PR is merged, we should ideally
do the opposite sync (push) manually.
- The pull fails (usually because of a merge conflict), or the bot
determines that a pull PR has been opened for more than a week without
being merged. In that case, it will post a ping to
https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/compiler-builtins.20subtree.20sync.20automation/with/528482375.
Disable docs for `compiler-builtins` and `sysroot`
Bootstrap already had a manual doc filter for the `sysroot` crate, but
other library crates keep themselves out of the public docs by setting
`[lib] doc = false` in their manifest. This seems like a better solution
to hide `compiler-builtins` docs, and removes the `sysroot` hack too.
Fixesrust-lang/rust#143215 (after backport)
```@rustbot``` label beta-nominated
Bootstrap already had a manual doc filter for the `sysroot` crate, but
other library crates keep themselves out of the public docs by setting
`[lib] doc = false` in their manifest. This seems like a better solution
to hide `compiler-builtins` docs, and removes the `sysroot` hack too.
The `rustc` probe done in our build scripts needs to pass `--target` to
get the correct configuration, which usually comes from the `TARGET`
environment variable. However, for targets specified via a `target.json`
file, `TARGET` gets set to the file name without an extension or path.
`rustc` will check a search path to attempt to locate the file, but this
is likely to fail since the directory where Cargo invokes build scripts
(and hence where those scripts invoke `rustc`) might not have any
relation to the JSON spec file.
Resolve this for now by leaving `f16` and `f128` disabled if the `rustc`
command fails. Result of the discussion at CARGO-14208 may eventually
provide a better solution.
A CI test is also added since custom JSON files are an edge case that
could fail in other ways. I verified this fails without the fix here.
The JSON file is the output for `thumbv7em-none-eabi`, just renamed so
`rustc` doesn't identify it.
8521530f4938 ("Fix __divsi3 and __udivsi3 on thumbv6m targets") removed
tests that use these `thumb*-linux` target files in favor of tests that
use the `thumb*-none` targets, which are available via Rustup. The JSON
files haven't been used since then and are outdated, so remove them.
Currently we whether or not to build and test `f16` and `f128` support
mostly based on the target triple. This isn't always accurate, however,
since support also varies by backend and the backend version.
Since recently, `rustc` is aware of this with the unstable config option
`target_has_reliable_{f16,f128}`, which better represents when the types
are actually expected to be available and usable. Switch our
compiler-builtins and libm configuration to use this by probing `rustc`
for the target's settings.
A few small `cfg` fixes are needed with this.
`i256` and `u256`
- operators now use the same overflow convention as primitives
- implement `<<` and `-` (previously just `>>` and `+`)
- implement `Ord` correctly (the previous `PartialOrd` was broken)
- correct `i256::SIGNED` to `true`
The `Int`-trait is extended with `trailing_zeros`, `carrying_add`, and
`borrowing_sub`.
Often our short summaries will pick up a Bors "Auto merge of #xxxx ...`
commit message. Replace these with something like `rust-lang/rust#1234`
to avoid broken links when going between repositories.
Rather than re-opening the archive file for each check, add a wrapper
that keeps the data in memory. Additionally, collect the `--target`
argument so it can be used within this crate.
This PR adds a minimal `triagebot.toml` config to make contributions to
this repository respect upstream rust-lang/rust conventions and avoid
issues when syncing this subtree.
Out-of-tree testing is broken with the most recent update from
rust-lang/rust because it makes `compiler-builtins` depend on `core` by
path, which isn't usually available. In order to enable testing outside
of rust-lang/rust, add a new crate `builtins-shim` that uses the same
source as `compiler-builtins` but drops the `core` dependency. This has
replaced `compiler-builtins` as the workspace member and entrypoint for
tests.
Use a consistent ordering for top-level manifest keys, and remove those
that are now redundant (`homapage` isn't supposed to be the same as
`repository`, and `documentation` automatically points to docs.rs now).
After adding tests, the current implementation for fminimum fails when
provided a negative zero and NaN as inputs:
---- math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f64 stdout ----
thread 'math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f64' panicked at libm/src/math/fminimum_fmaximum_num.rs:240:13:
fmaximum_num(-0x0p+0, NaN)
l: NaN (0x7ff8000000000000)
r: -0.0 (0x8000000000000000)
---- math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f32 stdout ----
thread 'math::fminimum_fmaximum_num::tests::fmaximum_num_spec_tests_f32' panicked at libm/src/math/fminimum_fmaximum_num.rs:240:13:
fmaximum_num(-0x0p+0, NaN)
l: NaN (0x7fc00000)
r: -0.0 (0x80000000)
Add more thorough spec tests for these functions and correct the
implementations.
Canonicalization is also moved to a trait method to centralize
documentation about what it does and doesn't do.
The `build.rs` entrypoint returns early for some targets, so emscripten
and OpenBSD were not getting check-cfg set. Emit these earlier to avoid
the `unexpected_cfgs` lint.
On the ILP32 `x86_64-unknown-linux-gnux32` target, `usize` is 32 bits so
there is a sub-register alignment warning. Specify the 64-bit `r`
registers, which matches the current default as well as the size of the
other operands in the routines.
There are a few places that violate this lint, which showed up in
rust-lang/rust CI (the relevent module is gated behind
`kernel_user_helpers` which is only set for `armv4t`, `armv5te`, and
`arm-linux-androideabi`; none of these are tested in compiler-builtins
CI). Add new `unsafe { /* ... */ }` blocks where needed to address this.
Some blocks should get a more thorough review of their preconditions, so
their safety comments are left as `FIXME`s.
Many of `std`'s dependency have a dependency on the crates.io
`compiler-builtins` when used with the feature
`rustc-std-workspace-core`. Use a Cargo patch to select the in-tree
version instead.
`compiler-builtins` is also added as a dependency of
`rustc-std-workspace-core` so these crates can remove their crates.io
dependency in the future.
This was introduced before `#[panic_handler]` was stable, but should no
longer be needed. Additionally, we only need it for
`builtins-test-intrinsics`, not as a dependency of `compiler-builtins`.
