| Age | Commit message (Collapse) | Author | Lines |
|
Revert "Download the GCC sources insecurely"
This reverts commit 3da037f82988b8b3aca2ce13c5c81ba975923cab.
This workaround was added after TLS problems with Debian 6 were noted in <https://github.com/rust-lang/rust/pull/86586#issuecomment-868355356>, but we should be well past that since #95026, where our oldest images are now based on CentOS 7.
|
|
Allow older LLVM versions to have missing components
This check was introduced by #77280 to ensure that all tests that are filtered by LLVM component are actually tested in CI. However this causes issues for new targets (e.g. #101069) where support is only available on the latest LLVM version.
This PR restricts the tests to only CI jobs that use the latest LLVM version.
|
|
This reverts commit 3da037f82988b8b3aca2ce13c5c81ba975923cab.
|
|
Spelling src ci
The various src/* items seem slightly disparate, so I'm doing src/* individually.
split from https://github.com/rust-lang/rust/pull/110392
|
|
* architecture
* configures
* preparation
* toolstate
* unknown
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
|
|
Like #107044, this will let us track compatibility with LLVM 16 going
forward, especially after we eventually upgrade our own to the next.
This also drops `tidy` here and in `x86_64-gnu-llvm-15`, syncing with
that change in #106085.
|
|
This check was introduced by #77280 to ensure that all tests that are
filtered by LLVM component are actually tested in CI. However this
causes issues for new targets (e.g. #101069) where support is only
available on the latest LLVM version.
This PR restricts the tests to only CI jobs that use the latest LLVM
version.
|
|
|
|
|
|
|
|
|
|
Use `getentropy()` instead of `/dev/urandom` on Emscripten
`/dev/urandom` is usually available on Emscripten, except when using
the special `NODERAWFS` filesystem backend, which replaces all normal
filesystem access with direct Node.js operations.
Since this filesystem backend directly access the filesystem on the
OS, it is not recommended to depend on `/dev/urandom`, especially
when trying to run the Wasm binary on OSes that are not Unix-based.
This can be considered a non-functional change, since Emscripten
implements `/dev/urandom` in the same way as `getentropy()` when not
linking with `-sNODERAWFS`.
|
|
`getentropy()` is available since Emscripten 2.0.5.
See:
https://github.com/emscripten-core/emscripten/pull/12240
|
|
Use llvm 16.0.0 instead of 16.0.0-rc4 for build-clang.sh
Ref: https://github.com/rust-lang/rust/pull/107224
This PR doesn't make any update on LLVM submodule used by Rust repo, but would be super keen to update it, if necessary (https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html). LLVM 16.0.0 has been [released](https://discourse.llvm.org/t/llvm-16-0-0-release/69326) on March 18, while Rust 1.70 will become stable on June 1.
- https://releases.llvm.org/16.0.0/docs/ReleaseNotes.html
|
|
Upgrade to LLVM 16, again
Relative to the previous attempt in https://github.com/rust-lang/rust/pull/107224:
* Update to GCC 8.5 on dist-x86_64-linux, to avoid std::optional ABI-incompatibility between libstdc++ 7 and 8.
* Cherry-pick https://github.com/llvm/llvm-project/commit/96df79af029b85616ab90e73143e0e8ae89c7b46.
* Cherry-pick https://github.com/llvm/llvm-project/commit/6fc670e5e370e90759b5adecd9980b63609dc2f8.
r? `@cuviper`
|
|
|
|
Fix cross-compiling with dlltool for raw-dylib
Fix for #103939
Issue Details:
When attempting to cross-compile using the `raw-dylib` feature and the GNU toolchain, rustc would attempt to find a cross-compiling version of dlltool (e.g., `i686-w64-mingw32-dlltool`). The has two issues 1) on Windows dlltool is always `dlltool` (no cross-compiling named versions exist) and 2) it only supported compiling to i686 and x86_64 resulting in ARM 32 and 64 compiling as x86_64.
Fix Details:
* On Windows always use the normal `dlltool` binary.
* Add the ARM64 cross-compiling dlltool name (support for this is coming: https://sourceware.org/bugzilla/show_bug.cgi?id=29964)
* Provide the `-m` argument to dlltool to indicate the target machine type.
(This is the first of two PRs to fix the remaining issues for the `raw-dylib` feature (#58713) that is blocking stabilization (#104218))
|
|
|
|
rustdoc: Add GUI test for "Auto-hide item contents for large items" setting
Part of https://github.com/rust-lang/rust/issues/66181.
The `browser-ui-test` version update is because there wasn't `null` check for attributes so I added it (PR is [here](https://github.com/GuillaumeGomez/browser-UI-test/pull/440)).
r? ``@notriddle``
|
|
Add RANLIB_x86_64_unknown_illumos env for dist-x86_64-illumos dockerfile
close https://github.com/rust-lang/cc-rs/issues/798
We already set `AR_x86_64_unknown_illumos` in the dockerfile. So it is reasonable to set the `RANLIB_x86_64_unknown_illumos`.
|
|
While we don't use GCC for the LLVM build, we do use its libstdc++,
and there has been an std::optional ABI break in this version.
This makes the libLLVM.so for LLVM 16 ABI-incompatible with newer
libstdc++ versions, which we use on all other builders, and which
download-ci-llvm users are likely to use.
|
|
|
|
Add tests for configure.py
I highly recommend reviewing this with whitespace disabled.
Notably, verifying that we generate valid toml relies on python 3.11 so
we can use `tomllib`, so this also switches`x86_64-gnu-llvm-14` (one of the PR builders) to use 3.11.
While fixing that, I noticed that we stopped testing python2.7 support on PR CI in https://github.com/rust-lang/rust/pull/106085. `@fee1-dead` `@pietroalbini` please be more careful in the future, there is no CI for CI itself that verifies we are testing everything we should be.
- Separate out functions so that each unit test doesn't create a file on disk
- Add a few unit tests
|
|
Update host compiler to LLVM 16
Update the host compiler for dist-x86_64-linux to LLVM 16. In particular, this pulls in https://github.com/llvm/llvm-project/commit/1de305da428598d79b7d2d9e70962130142f7ca4, which is needed to update Rust's own LLVM (https://github.com/rust-lang/rust/pull/107224).
|
|
This also fixes a regression from
https://github.com/rust-lang/rust/pull/106085 which stopped testing that
we support python2 in PR CI.
|
|
This removes a dependency on ntapi 0.3.x which failed to compiled with
latest beta.
rust-lang/rustc-perf@93dc60d995a57c3cab8d7fb90a6fc7f9f7c5cd0f removed
that dependency in the upstream rustc-perf.
|
|
Signed-off-by: hi-rustin <rustin.liu@gmail.com>
|
|
|
|
|
|
This updates the host compiler for dist-x86_64-linux to LLVM 16,
pulling in the BOLT fix at
https://github.com/llvm/llvm-project/commit/1de305da428598d79b7d2d9e70962130142f7ca4,
which is needed to update Rust to LLVM 16.
|
|
use problem matchers for tidy CI
|
|
|
|
|
|
|
|
Test that the compiler/library builds with validate-mir
Fixes #105706
|
|
r=notriddle
Fix GUI test navigation bug
Following https://github.com/GuillaumeGomez/browser-UI-test/pull/438, we can now remove this `wait-for`.
Should help with #93784.
r? ``@notriddle``
|
|
|
|
|
|
This updates the test runner to the latest version of the SDK and fixes
debugging support for Rust source code.
|
|
|
|
Update the minimum external LLVM to 14
With this change, we'll have stable support for LLVM 14 through 16 (pending release).
For reference, the previous increase to LLVM 13 was #100460.
|
|
|
|
|
|
|
|
Port pgo.sh to Python
This PR ports the `pgo.sh` multi stage build file from bash to Python, to make it easier to add new functionality and gather statistics. Main changes:
1) `pgo.sh` rewritten from Bash to Python. Jump from ~200 Bash LOC to ~650 Python LOC. Bash is, unsurprisingly, more concise for running scripts and binaries.
2) Better logging. Each separate stage is now clearly separated in logs, and the logs can be quickly grepped to find out which stage has completed or failed, and how long it took.
3) Better statistics. At the end of the run, there is now a table that shows the duration of the individual stages, along with a percentual ratio of the total workflow run:
```
2023-01-15T18:13:49.9896916Z stage-build INFO: Timer results
2023-01-15T18:13:49.9902185Z ---------------------------------------------------------
2023-01-15T18:13:49.9902605Z Build rustc (LLVM PGO): 1815.67s (21.47%)
2023-01-15T18:13:49.9902949Z Gather profiles (LLVM PGO): 418.73s ( 4.95%)
2023-01-15T18:13:49.9903269Z Build rustc (rustc PGO): 584.46s ( 6.91%)
2023-01-15T18:13:49.9903835Z Gather profiles (rustc PGO): 806.32s ( 9.53%)
2023-01-15T18:13:49.9904154Z Build rustc (LLVM BOLT): 1662.92s (19.66%)
2023-01-15T18:13:49.9904464Z Gather profiles (LLVM BOLT): 715.18s ( 8.46%)
2023-01-15T18:13:49.9914463Z Final build: 2454.00s (29.02%)
2023-01-15T18:13:49.9914798Z Total duration: 8457.27s
2023-01-15T18:13:49.9915305Z ---------------------------------------------------------
```
A sample run can be seen [here](https://github.com/rust-lang/rust/actions/runs/3923980164/jobs/6707932029).
I tried to keep the code compatible with Python 3.6 and don't use dependencies, which required me to reimplement some small pieces of functionality (like formatting bytes). I suppose that it shouldn't be so hard to upgrade to a newer Python or install dependencies in the CI container, but I'd like to avoid it if it won't be needed.
The code is in a single file `stage-build.py`, so it's a bit cluttered. I can also separate it into multiple files, although having it in a single file has some benefits. The code could definitely be nicer, but I'm a bit wary of introducing a lot of abstraction and similar stuff, as long as the code is stuffed into a single file.
Currently, the Python pipeline should faithfully mirror the bash pipeline one by one. After this PR, I'd like to try to optimize it, e.g. by caching the LLVM builds on S3.
r? `@Mark-Simulacrum`
|
|
Fix maintainer validation message
State clearly why maintainer verification is not activating, ruling out the user thinking they misconfigured something.
|
|
|
|
ci: add runners for vanilla LLVM 14 and 15
As discussed in [zulip #t-infra][1] -- r? Mark-Simulacrum
[1]: https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/testing.20multiple.20llvm.20versions
|
|
fix remove token check for maintainers
fix: rm validate_maintainers function
|