| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
solaris build environment should include libsendfile/liblgrp
As of version 0.2.120 of the libc crate, the solaris target now requires
some additional libraries to be present in the sysroot. Note that the
solaris target doesn't really build against files from Solaris, but
rather against some files from DilOS (a platform similar to both Solaris
and illumos). Pull in the extra libraries and their compilation links
from that apt repository.
This aims to assist with rust-lang/rust#94052.
|
|
|
|
|
|
Update browser-ui-test version to 0.8.2
It brings mostly debugging improvements: it doesn't stop at the first failing command but rather at the first "fatal error".
r? `@notriddle`
|
|
|
|
|
|
|
|
As of version 0.2.120 of the libc crate, the solaris target now requires
some additional libraries to be present in the sysroot. Note that the
solaris target doesn't really build against files from Solaris, but
rather against some files from DilOS (a platform similar to both Solaris
and illumos). Pull in the extra libraries and their compilation links
from that apt repository.
|
|
Gather LLVM PGO profiles from `rustc-perf` suite on real-world crates
This PR expands the benchmark suite used to gather LLVM PGO profiles in CI from `libcore` to several real-world crates. I hand-picked a few crates, but the list is up for debate.
Previous results that we got from running `syn,cargo,serde` looked pretty [good](https://perf.rust-lang.org/compare.html?start=2631aeef823a9e16d31f999d3f07001e5fcc4b3d&end=abf097afa10dde1aa3d8a1d422724a46aab79bf3).
Running `libcore` + `rustc-perf` with some number of crates is repeated now (and for BOLT it will also be needed), so maybe we can extract it to a bash function?
r? `@Mark-Simulacrum`
|
|
|
|
|
|
LLVM PGO
|
|
|
|
For some reason, `tar` behaves differently in such a way that it does
not create symlinks on Windows correctly, resulting in
`Cannot create symlink to 'ld.gold': No such file or directory`
errors.
|
|
|
|
|
|
Update to Ubuntu 20.04 and crosstool-ng 1.24.0. I've updated the
ct-ng config and then manually reset the kernel and glibc versions
to the oldest supported.
Specifically, we're updating from kernel 2.6.32.68 to 2.6.32.71
and glibc 2.11.1 to 2.12.1 here. The compiler toolchain is also
updated, but I don't think that's relevant for compatibility.
|
|
Update dist-x86_64-musl to Ubuntu 20.04
This updates the dist-x86_64-musl image to use Ubuntu 20.04. The current Ubuntu 16.04 based image only works due to the Docker cache, it's not possible anymore to run it locally because of the usual certificate expiration issue.
I believe updating the OS here is relatively safe because this targets musl, so there are no concerns about raising the glibc baseline. There is some risk here in that it updates the compiler toolchain used to produce artifacts, though I'm not aware of any specific issues that could cause.
r? ``@Mark-Simulacrum``
|
|
|
|
|
|
Update dist-(arm|armv7|armhf)-linux to Ubuntu 20.04
I believe this should be safe, as actual artifacts will be produced by a cross toolchain. The build ran through cleanly locally.
This came up in https://github.com/rust-lang/rust/pull/93577, where the host GCC ICEd during the LLD build. (Though I wonder why we build LLD for the host at all...)
r? `@Mark-Simulacrum`
|
|
|
|
|
|
|
|
I believe this should be safe, as actual artifacts will be
produced by a cross toolchain. The build ran through cleanly
locally.
|
|
Build libcore as 2021 in a few more places
The `Cargo.toml` has `edition = "2021"` (as of #92068), so that's what these command lines should use too.
|
|
The `Cargo.toml` has `edition = "2021"`, so that's what these command lines should use too.
|
|
Update CPU idle tracking for apple hosts
The previous setup did not properly consider hyperthreads (at least in local
testing), which likely skews CI results as well. The new code is both simpler
and hopefully will produce more accurate results; locally it matches behavior
of the Linux version of this script.
|
|
The previous setup did not properly consider hyperthreads (at least in local
testing), which likely skews CI results as well. The new code is both simpler
and hopefully will produce more accurate results.
|
|
|
|
|
|
|
|
Update Linux runners to Ubuntu 20.04
r? `@Mark-Simulacrum`
|
|
|
|
This builder is the slowest in the fleet. This should cut a considerable
amount of time. The manifest should now include the docs from
x86_64-apple-darwin. Although those docs are slightly different, it
should be close enough. When aarch64-apple-darwin heads towards tier 1,
we can revisit whether or not to re-enable the docs.
|
|
|
|
|
|
Also update Node to v16.9.0, es-check to 6.1.1, and eslint to 8.6.0.
|
|
Fix mobile toggles position
Before:
After:
r? `@jsha`
|
|
|
|
|
|
Update browser-ui-test version and improve rustdoc-gui tests readability
Since the `0.5.1`, we can use trailing commas. I also used the opportunity to clean up the existing tests.
r? `@notriddle`
|
|
|
|
|
|
Update certificates in some Ubuntu 16 images.
These images use crosstool-ng, which needs to download various things off the internet. The certificate for `www.kernel.org` no longer works with the ca-certificates in Ubuntu 16. This resolves the issue by grabbing from a newer image a certificate bundle from https://curl.se/ca/cacert.pem, which is usually somewhat up to date.
|
|
checking colors
|
|
Build musl dist artifacts with debuginfo enabled
Since our musl targets link to a version of musl we build and bundle
with the targets, if users need to debug into musl or generate
backtraces which contain parts of the musl library, they will be unable
to do so unless we enable and ship the debug info.
This patch changes our dist builds so they enabled debug info when
building musl. This patch also includes a fix for CFI detection in
musl's `configure` script which has been [posted upstream](https://www.openwall.com/lists/musl/2021/10/21/2).
The net effect of this is that we now ship debug info for musl in those
targets. This adds ~90kb to those artifacts but running `strip` on
binaries produced removes all of that. For a "hello world" Rust binary
on x86_64, the numbers are:
| | debug | release | release + strip |
| - | - | - | - |
| without musl debuginfo | 507kb | 495kb | 410kb |
| with musl debuginfo | 595kb | 584kb | 410kb |
Once stripped, the final binaries are the same size (down to the byte).
Fixes #90103
r? `@Mark-Simulacrum`
|
|
The detectportal.firefox.com server seems to return a random-ish date; for
example I see the following across 5 curl's done consecutively locally, where
the real date is approximaly 15 Nov 2021 06:36 UTC.
Date: Mon, 15 Nov 2021 13:34:53 GMT
Date: Mon, 15 Nov 2021 12:20:21 GMT
Date: Mon, 15 Nov 2021 00:06:47 GMT
Date: Mon, 15 Nov 2021 17:14:33 GMT
Date: Mon, 15 Nov 2021 13:33:21 GMT
|
|
Before, you could have the confusing situation where the command to
generate a component had no relation to the name of that component (e.g.
the `rustc` component was generated with `src/librustc`). This changes
the name to make them match up.
|
