There were some issues regarding windows and apple platform, we were
exporting symbols that are already provided by the compiler but weren't
marked as `weak` which resulted in conflicted symbols in the linking
process.
Initially, we didn't add `weak` because we thought it is not supported
on windows and apple platforms, but it looks like its only not supported
on windows-gnu platforms
Signed-off-by: Amjad Alsharafi <26300843+Amjad50@users.noreply.github.com>
Make the following changes:
- Add `rerun-if-changed` to the new `configure.rs`, it seems this was
causing incorrect caching.
- Change from matching `i686` to `x86`. The target triple starts with
`i686` so that is what we were checking before, but the architecture
is `x86`. This change should have been made when we added `struct
Target`, update it now instead.
Replace `public_test_dep!` by placing optionally public items into new
modules, then controlling what is exported with the `public-test-deps`
feature.
This is nicer for automatic formatting and diagnostics.
Since there are more platforms that do not have symbols present, we need
to use `rustc_apfloat` for more conversion tests. Make use of the
fallback like other tests, and refactor so each test gets its own
function.
Previously we were testing both apfloat and system conversion methods
when possible. This changes to only test one or the other, depending on
whether or not the system version is available. This seems reasonable
because it is consistent with all other tests, but we should consider
updating all tests to check both at some point.
This also includes an adjustment of PowerPC configuration to account for
the linking errors at [1].
[1]: https://github.com/rust-lang/compiler-builtins/issues/655
Previously we were building the C versions of these symbols. Since we
added the Rust version and updated compiler builtins, these are no
longer available by default. This is unintentional, but it gives a
better indicator of which symbol versions are not actually provided by
the system.
Use the list of build failures to correct the list of platforms that do
not have `f16` symbols.
By moving the logic for which platforms get symbols to
`compiler_builtins` rather than rust-lang/rust, we can control where
symbols get enabled without relying on Cargo features. Using Cargo
features turned out to be a problem in [1].
This will help resolve errors like [2].
[1]: https://github.com/rust-lang/rust/issues/128358
[2]: https://github.com/rust-lang/rust/issues/128401
This is what `cc-rs` is using and should create a release PR whenever a
change to `master` is made. If the branch is merged, it should publish
the new version.
Includes configuration to disable semver checks and not keep a changelog
since this is an implementation detail.
`unsafe` functions were being matched in a different block that did not
include `extern $abi`. This means that some intrinsics were getting
generated with the Rust ABI rather than C.
Combine the last two blocks using an optional token matcher, which fixes
this problem and is cleaner.
