| Age | Commit message (Collapse) | Author | Lines |
|
|
|
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
|
|
Enable sanitizers for s390x-linux
Include sanitizers supported by LLVM on s390x (asan, lsan, msan, tsan) in the target definition, as well as in the compiletest supported list.
Build sanitizer runtime for the target. Enable sanitizers in the CI.
|
|
ci: upgrade mingw-check to ubuntu:22.04
|
|
Include sanitizers supported by LLVM on s390x (asan, lsan, msan, tsan)
in the target definition, as well as in the compiletest supported list.
Build sanitizer runtime for the target. Enable sanitizers in the CI.
|
|
Ndk update redux
Blocked on https://github.com/rust-lang/blog.rust-lang.org/pull/1055
|
|
|
|
|
|
Update the wasi-libc used for the wasm32-wasi target
This commit updates the wasi-libc revision used to build with the wasm32-wasi target. This notably pulls in WebAssembly/wasi-libc#377 which is needed to fix a use case I've been working on recently. This should be a relatively small update hopefully and is not expected to have any user impact.
|
|
Check compiler docs in PR CI
Fixes #106624
|
|
This commit updates the wasi-libc revision used to build with the
wasm32-wasi target. This notably pulls in WebAssembly/wasi-libc#377
which is needed to fix a use case I've been working on recently. This
should be a relatively small update hopefully and is not expected to
have any user impact.
|
|
Use CI LLVM in `test-various` builder
It was disabled because it needs `lld`, but since #104748 was merged it is no longer needed.
This will speed this test, since it no longer needs to build LLVM.
|
|
|