Currently, a failure in `ci-util.py` does not cause the job to fail
because the pipe eats the failure status . Set pipefail to fix this.
Fixes: ff2cc0e38e3e ("ci: Don't print output twice in `ci-util`")
Rather than setting an environment variable in the workflow job based on
whether or not the environment is non-MinGW Windows, we can just check
this in the ci script.
This was originally added in b0f19660f0 ("Add tests for UNC paths on
windows builds") and its followup commits.
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.
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.
The submodule was causing issues in rust-lang/rust, so eliminiate it
here. `build-musl` is also removed from `libm-test`'s default features
so the crate doesn't need to be built by default.
We don't actually need this for now, but eventually it would be nice to
run icount benchmarks on multiple targets. Start tagging artifact names
with the architecture, and allow passing `--tag` to `ci-util.py` in
order to retrieve the correct one.
We may soon want to use some new nightly features in `compiler-builtins`
and `libm`, specifically `cfg_target_has_reliable_f16_f128` which was
added in the past few weeks. This will mean we need a newer toolchain
for benchmarks to continue building.
Bump to the current latest nightly so we are not blocked on this down
the line.
When multiple merges to `master` happen before a CI run completes, the
in-progress job is getting canceled. Fix this by using the commit sha
for the group key if a pull request number is not available, rather than
`github.ref` (which is always `refs/head/master` after merge). This
should prevent jobs running on previous commits from getting cancelled,
while still ensuring there is only ever one active run per pull request.
Many contributions to compiler-builtins don't have any need to touch
libm, and could get by with the few minutes of CI for compiler-builtins
rather than the ~30 minutes for libm. We already have some scripts that
handle changed file detection, so expand its use to skip libm CI if it
doesn't need to run.
Update `run.sh` to start testing `libm`. Currently this is somewhat
inefficient because `builtins-test` gets run more than once on some
targets; this can be cleaned up later.
Apply a handful of changes to reduce the diff between the two:
* Cancel running jobs on new pushes
* Enable log color and backtraces
* Add timeouts
* Specify CI runner versions
* Add an armv7 job
* Replace the name NO_STD with BUILD_ONLY
* Update the extension to the canonical .yaml
* Set AR_ and CC_ environments in docker
* Install requirements to build MPFR
The current setup has the `Cargo.toml` for `compiler-builtins` at the
repository root, which means all support crates and other files are
located within the package root. This works for now but is not the
cleanest setup since files that should or shouldn't be included in the
package need to be configured in `Cargo.toml`. If we eventually merge
`libm` development into this repository, it would be nice to make this
separation more straightforward.
Begin cleaning things up by moving the crate source to a new
`compiler-builtins` directory and adding a virtual manifest. For now the
`libm` submodule is also moved, but in the future it can likely move
back to the top level (ideally `compiler-builtins/src` would contain a
symlink to `libm/src/math`, but unfortunately it seems like Cargo does
not like something about the submodule + symlink combination).
The fix to this issue was synced in [1] so we should no longer need to
keep aarch64 pinned.
This reverts commit b2bcfc838e2a4b72fa62b333e3eb91f250aa4539.
[1]: https://github.com/rust-lang/rust/pull/137661
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.
