许杰友 Jieyou Xu (Joe)
GitHub
commit
9975f62f2b
|
|
@ -1 +1 @@
|
|||
4ecd70ddd1039a3954056c1071e40278048476fa
|
||||
8536f201ffdb2c24925d7f9e87996d7dca93428b
|
||||
|
|
|
|||
|
|
@ -126,4 +126,4 @@ Here is an example of how can `opt-dist` be used locally (outside of CI):
|
|||
[`Environment`]: https://github.com/rust-lang/rust/blob/ee451f8faccf3050c76cdcd82543c917b40c7962/src/tools/opt-dist/src/environment.rs#L5
|
||||
|
||||
> Note: if you want to run the actual CI pipeline, instead of running `opt-dist` locally,
|
||||
> you can execute `python3 src/ci/github-actions/ci.py run-local dist-x86_64-linux`.
|
||||
> you can execute `cargo run --manifest-path src/ci/citool/Cargo.toml run-local dist-x86_64-linux`.
|
||||
|
|
|
|||
|
|
@ -139,12 +139,12 @@ defined in the map. By matching on this, you can find out what sort of
|
|||
node the `HirId` referred to and also get a pointer to the data
|
||||
itself. Often, you know what sort of node `n` is – e.g. if you know
|
||||
that `n` must be some HIR expression, you can do
|
||||
[`tcx.hir().expect_expr(n)`][expect_expr], which will extract and return the
|
||||
[`tcx.hir_expect_expr(n)`][expect_expr], which will extract and return the
|
||||
[`&hir::Expr`][Expr], panicking if `n` is not in fact an expression.
|
||||
|
||||
[find]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.find
|
||||
[`Node`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/enum.Node.html
|
||||
[expect_expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.expect_expr
|
||||
[expect_expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.TyCtxt.html#method.expect_expr
|
||||
[Expr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/hir/struct.Expr.html
|
||||
|
||||
Finally, you can use the HIR map to find the parents of nodes, via
|
||||
|
|
|
|||
|
|
@ -46,10 +46,8 @@ are implemented differently depending on whether `parallel-compiler` is true.
|
|||
|
||||
| data structure | parallel | non-parallel |
|
||||
| -------------------------------- | --------------------------------------------------- | ------------ |
|
||||
| OnceCell | std::sync::OnceLock | std::cell::OnceCell |
|
||||
| Lock\<T> | (parking_lot::Mutex\<T>) | (std::cell::RefCell) |
|
||||
| RwLock\<T> | (parking_lot::RwLock\<T>) | (std::cell::RefCell) |
|
||||
| MTRef<'a, T> | &'a T | &'a mut T |
|
||||
| MTLock\<T> | (Lock\<T>) | (T) |
|
||||
| ReadGuard | parking_lot::RwLockReadGuard | std::cell::Ref |
|
||||
| MappedReadGuard | parking_lot::MappedRwLockReadGuard | std::cell::Ref |
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ Our CI is primarily executed on [GitHub Actions], with a single workflow defined
|
|||
in [`.github/workflows/ci.yml`], which contains a bunch of steps that are
|
||||
unified for all CI jobs that we execute. When a commit is pushed to a
|
||||
corresponding branch or a PR, the workflow executes the
|
||||
[`src/ci/github-actions/ci.py`] script, which dynamically generates the specific CI
|
||||
[`src/ci/citool`] crate, which dynamically generates the specific CI
|
||||
jobs that should be executed. This script uses the [`jobs.yml`] file as an
|
||||
input, which contains a declarative configuration of all our CI jobs.
|
||||
|
||||
|
|
@ -133,29 +133,37 @@ There are several use-cases for try builds:
|
|||
Again, a working compiler build is needed for this, which can be produced by
|
||||
the [dist-x86_64-linux] CI job.
|
||||
- Run a specific CI job (e.g. Windows tests) on a PR, to quickly test if it
|
||||
passes the test suite executed by that job. You can select which CI jobs will
|
||||
be executed in the try build by adding up to 10 lines containing `try-job:
|
||||
<name of job>` to the PR description. All such specified jobs will be executed
|
||||
passes the test suite executed by that job.
|
||||
|
||||
You can select which CI jobs will
|
||||
be executed in the try build by adding lines containing `try-job:
|
||||
<job pattern>` to the PR description. All such specified jobs will be executed
|
||||
in the try build once the `@bors try` command is used on the PR. If no try
|
||||
jobs are specified in this way, the jobs defined in the `try` section of
|
||||
[`jobs.yml`] will be executed by default.
|
||||
|
||||
Each pattern can either be an exact name of a job or a glob pattern that matches multiple jobs,
|
||||
for example `*msvc*` or `*-alt`. You can start at most 20 jobs in a single try build. When using
|
||||
glob patterns, you might want to wrap them in backticks (`` ` ``) to avoid GitHub rendering
|
||||
the pattern as Markdown.
|
||||
|
||||
> **Using `try-job` PR description directives**
|
||||
>
|
||||
> 1. Identify which set of try-jobs (max 10) you would like to exercise. You can
|
||||
> 1. Identify which set of try-jobs you would like to exercise. You can
|
||||
> find the name of the CI jobs in [`jobs.yml`].
|
||||
>
|
||||
> 2. Amend PR description to include (usually at the end of the PR description)
|
||||
> e.g.
|
||||
> 2. Amend PR description to include a set of patterns (usually at the end
|
||||
> of the PR description), for example:
|
||||
>
|
||||
> ```text
|
||||
> This PR fixes #123456.
|
||||
>
|
||||
> try-job: x86_64-msvc
|
||||
> try-job: test-various
|
||||
> try-job: `*-alt`
|
||||
> ```
|
||||
>
|
||||
> Each `try-job` directive must be on its own line.
|
||||
> Each `try-job` pattern must be on its own line.
|
||||
>
|
||||
> 3. Run the prescribed try jobs with `@bors try`. As aforementioned, this
|
||||
> requires the user to either (1) have `try` permissions or (2) be delegated
|
||||
|
|
@ -299,7 +307,7 @@ platform’s custom [Docker container]. This has a lot of advantages for us:
|
|||
- We can avoid reinstalling tools (like QEMU or the Android emulator) every time
|
||||
thanks to Docker image caching.
|
||||
- Users can run the same tests in the same environment locally by just running
|
||||
`python3 src/ci/github-actions/ci.py run-local <job-name>`, which is awesome to debug failures. Note that there are only linux docker images available locally due to licensing and
|
||||
`cargo run --manifest-path src/ci/citool/Cargo.toml run-local <job-name>`, which is awesome to debug failures. Note that there are only linux docker images available locally due to licensing and
|
||||
other restrictions.
|
||||
|
||||
The docker images prefixed with `dist-` are used for building artifacts while
|
||||
|
|
@ -443,7 +451,7 @@ this:
|
|||
[GitHub Actions]: https://github.com/rust-lang/rust/actions
|
||||
[`jobs.yml`]: https://github.com/rust-lang/rust/blob/master/src/ci/github-actions/jobs.yml
|
||||
[`.github/workflows/ci.yml`]: https://github.com/rust-lang/rust/blob/master/.github/workflows/ci.yml
|
||||
[`src/ci/github-actions/ci.py`]: https://github.com/rust-lang/rust/blob/master/src/ci/github-actions/ci.py
|
||||
[`src/ci/citool`]: https://github.com/rust-lang/rust/blob/master/src/ci/citool
|
||||
[rust-lang-ci]: https://github.com/rust-lang-ci/rust/actions
|
||||
[bors]: https://github.com/bors
|
||||
[homu]: https://github.com/rust-lang/homu
|
||||
|
|
|
|||
|
|
@ -74,8 +74,7 @@ The following test suites are available, with links for more information:
|
|||
|
||||
### General purpose test suite
|
||||
|
||||
[`run-make`](#run-make-tests) are general purpose tests using Rust programs (or
|
||||
Makefiles (legacy)).
|
||||
[`run-make`](#run-make-tests) are general purpose tests using Rust programs.
|
||||
|
||||
### Rustdoc test suites
|
||||
|
||||
|
|
@ -396,14 +395,6 @@ your test, causing separate files to be generated for 32bit and 64bit systems.
|
|||
|
||||
### `run-make` tests
|
||||
|
||||
> **Note on phasing out `Makefile`s**
|
||||
>
|
||||
> We are planning to migrate all existing Makefile-based `run-make` tests
|
||||
> to Rust programs. You should not be adding new Makefile-based `run-make`
|
||||
> tests.
|
||||
>
|
||||
> See <https://github.com/rust-lang/rust/issues/121876>.
|
||||
|
||||
The tests in [`tests/run-make`] are general-purpose tests using Rust *recipes*,
|
||||
which are small programs (`rmake.rs`) allowing arbitrary Rust code such as
|
||||
`rustc` invocations, and is supported by a [`run_make_support`] library. Using
|
||||
|
|
@ -424,10 +415,9 @@ Compiletest directives like `//@ only-<target>` or `//@ ignore-<target>` are
|
|||
supported in `rmake.rs`, like in UI tests. However, revisions or building
|
||||
auxiliary via directives are not currently supported.
|
||||
|
||||
Two `run-make` tests are ported over to Rust recipes as examples:
|
||||
|
||||
- <https://github.com/rust-lang/rust/tree/master/tests/run-make/CURRENT_RUSTC_VERSION>
|
||||
- <https://github.com/rust-lang/rust/tree/master/tests/run-make/a-b-a-linker-guard>
|
||||
`rmake.rs` and `run-make-support` may *not* use any nightly/unstable features,
|
||||
as they must be compilable by a stage 0 rustc that may be a beta or even stable
|
||||
rustc.
|
||||
|
||||
#### Quickly check if `rmake.rs` tests can be compiled
|
||||
|
||||
|
|
@ -481,20 +471,6 @@ Then add a corresponding entry to `"rust-analyzer.linkedProjects"`
|
|||
],
|
||||
```
|
||||
|
||||
#### Using Makefiles (legacy)
|
||||
|
||||
<div class="warning">
|
||||
You should avoid writing new Makefile-based `run-make` tests.
|
||||
</div>
|
||||
|
||||
Each test should be in a separate directory with a `Makefile` indicating the
|
||||
commands to run.
|
||||
|
||||
There is a [`tools.mk`] Makefile which you can include which provides a bunch of
|
||||
utilities to make it easier to run commands and compare outputs. Take a look at
|
||||
some of the other tests for some examples on how to get started.
|
||||
|
||||
[`tools.mk`]: https://github.com/rust-lang/rust/blob/master/tests/run-make/tools.mk
|
||||
[`tests/run-make`]: https://github.com/rust-lang/rust/tree/master/tests/run-make
|
||||
[`run_make_support`]: https://github.com/rust-lang/rust/tree/master/src/tools/run-make-support
|
||||
|
||||
|
|
|
|||
|
|
@ -6,10 +6,7 @@
|
|||
FIXME(jieyouxu) completely revise this chapter.
|
||||
-->
|
||||
|
||||
Directives are special comments that tell compiletest how to build and interpret
|
||||
a test. They must appear before the Rust source in the test. They may also
|
||||
appear in `rmake.rs` or legacy Makefiles for [run-make
|
||||
tests](compiletest.md#run-make-tests).
|
||||
Directives are special comments that tell compiletest how to build and interpret a test. They must appear before the Rust source in the test. They may also appear in `rmake.rs` [run-make tests](compiletest.md#run-make-tests).
|
||||
|
||||
They are normally put after the short comment that explains the point of this
|
||||
test. Compiletest test suites use `//@` to signal that a comment is a directive.
|
||||
|
|
@ -142,6 +139,7 @@ Some examples of `X` in `ignore-X` or `only-X`:
|
|||
- Pointer width: `32bit`, `64bit`
|
||||
- Endianness: `endian-big`
|
||||
- Stage: `stage1`, `stage2`
|
||||
- Binary format: `elf`
|
||||
- Channel: `stable`, `beta`
|
||||
- When cross compiling: `cross-compile`
|
||||
- When [remote testing] is used: `remote`
|
||||
|
|
@ -219,8 +217,6 @@ The following directives will check LLVM support:
|
|||
[`aarch64-gnu-debug`]), which only runs a
|
||||
subset of `run-make` tests. Other tests with this directive will not
|
||||
run at all, which is usually not what you want.
|
||||
- Notably, the [`aarch64-gnu-debug`] CI job *currently* only runs `run-make`
|
||||
tests which additionally contain `clang` in their test name.
|
||||
|
||||
See also [Debuginfo tests](compiletest.md#debuginfo-tests) for directives for
|
||||
ignoring debuggers.
|
||||
|
|
|
|||
|
|
@ -53,6 +53,15 @@ Some additional notes about using the interactive mode:
|
|||
containers. With the container name, run `docker exec -it <CONTAINER>
|
||||
/bin/bash` where `<CONTAINER>` is the container name like `4ba195e95cef`.
|
||||
|
||||
The approach described above is a relatively low-level interface for running the Docker images
|
||||
directly. If you want to run a full CI Linux job locally with Docker, in a way that is as close to CI as possible, you can use the following command:
|
||||
|
||||
```bash
|
||||
cargo run --manifest-path src/ci/citool/Cargo.toml run-local <job-name>
|
||||
# For example:
|
||||
cargo run --manifest-path src/ci/citool/Cargo.toml run-local dist-x86_64-linux-alt
|
||||
```
|
||||
|
||||
[Docker]: https://www.docker.com/
|
||||
[`src/ci/docker`]: https://github.com/rust-lang/rust/tree/master/src/ci/docker
|
||||
[`src/ci/docker/run.sh`]: https://github.com/rust-lang/rust/blob/master/src/ci/docker/run.sh
|
||||
|
|
|
|||
|
|
@ -240,30 +240,6 @@ This is much faster, but doesn't always work. For example, some tests include
|
|||
directives that specify specific compiler flags, or which rely on other crates,
|
||||
and they may not run the same without those options.
|
||||
|
||||
## Running `run-make` tests
|
||||
|
||||
### Windows
|
||||
|
||||
Running the `run-make` test suite on Windows is a currently bit more involved.
|
||||
There are numerous prerequisites and environmental requirements:
|
||||
|
||||
- Install msys2: <https://www.msys2.org/>
|
||||
- Specify `MSYS2_PATH_TYPE=inherit` in `msys2.ini` in the msys2 installation directory, run the
|
||||
following with `MSYS2 MSYS`:
|
||||
- `pacman -Syuu`
|
||||
- `pacman -S make`
|
||||
- `pacman -S diffutils`
|
||||
- `pacman -S binutils`
|
||||
- `./x test run-make` (`./x test tests/run-make` doesn't work)
|
||||
|
||||
There is [on-going work][port-run-make] to not rely on `Makefile`s in the
|
||||
run-make test suite. Once this work is completed, you can run the entire
|
||||
`run-make` test suite on native Windows inside `cmd` or `PowerShell` without
|
||||
needing to install and use MSYS2. As of <!--date-check --> Oct 2024, it is
|
||||
already possible to run the vast majority of the `run-make` test suite outside
|
||||
of MSYS2, but there will be failures for the tests that still use `Makefile`s
|
||||
due to not finding `make`.
|
||||
|
||||
## Running tests on a remote machine
|
||||
|
||||
Tests may be run on a remote machine (e.g. to test builds for a different
|
||||
|
|
@ -408,4 +384,3 @@ If you encounter bugs or problems, don't hesitate to open issues on the
|
|||
repository](https://github.com/rust-lang/rustc_codegen_gcc/).
|
||||
|
||||
[`tests/ui`]: https://github.com/rust-lang/rust/tree/master/tests/ui
|
||||
[port-run-make]: https://github.com/rust-lang/rust/issues/121876
|
||||
|
|
|
|||
Loading…
Reference in New Issue