| <!DOCTYPE HTML> |
| <html lang="en" class="light sidebar-visible" dir="ltr"> |
| <head> |
| <!-- Book generated using mdBook --> |
| <meta charset="UTF-8"> |
| <title>Running tests - Rust Compiler Development Guide</title> |
| |
| |
| <!-- Custom HTML head --> |
| |
| <meta name="description" content="A guide to developing the Rust compiler (rustc)"> |
| <meta name="viewport" content="width=device-width, initial-scale=1"> |
| <meta name="theme-color" content="#ffffff"> |
| |
| <link rel="icon" href="../favicon.svg"> |
| <link rel="shortcut icon" href="../favicon.png"> |
| <link rel="stylesheet" href="../css/variables.css"> |
| <link rel="stylesheet" href="../css/general.css"> |
| <link rel="stylesheet" href="../css/chrome.css"> |
| <link rel="stylesheet" href="../css/print.css" media="print"> |
| |
| <!-- Fonts --> |
| <link rel="stylesheet" href="../FontAwesome/css/font-awesome.css"> |
| <link rel="stylesheet" href="../fonts/fonts.css"> |
| |
| <!-- Highlight.js Stylesheets --> |
| <link rel="stylesheet" id="highlight-css" href="../highlight.css"> |
| <link rel="stylesheet" id="tomorrow-night-css" href="../tomorrow-night.css"> |
| <link rel="stylesheet" id="ayu-highlight-css" href="../ayu-highlight.css"> |
| |
| <!-- Custom theme stylesheets --> |
| <link rel="stylesheet" href="../pagetoc.css"> |
| |
| |
| <!-- Provide site root and default themes to javascript --> |
| <script> |
| const path_to_root = "../"; |
| const default_light_theme = "light"; |
| const default_dark_theme = "navy"; |
| window.path_to_searchindex_js = "../searchindex.js"; |
| </script> |
| <!-- Start loading toc.js asap --> |
| <script src="../toc.js"></script> |
| </head> |
| <body> |
| <div id="mdbook-help-container"> |
| <div id="mdbook-help-popup"> |
| <h2 class="mdbook-help-title">Keyboard shortcuts</h2> |
| <div> |
| <p>Press <kbd>←</kbd> or <kbd>→</kbd> to navigate between chapters</p> |
| <p>Press <kbd>S</kbd> or <kbd>/</kbd> to search in the book</p> |
| <p>Press <kbd>?</kbd> to show this help</p> |
| <p>Press <kbd>Esc</kbd> to hide this help</p> |
| </div> |
| </div> |
| </div> |
| <div id="body-container"> |
| <!-- Work around some values being stored in localStorage wrapped in quotes --> |
| <script> |
| try { |
| let theme = localStorage.getItem('mdbook-theme'); |
| let sidebar = localStorage.getItem('mdbook-sidebar'); |
| |
| if (theme.startsWith('"') && theme.endsWith('"')) { |
| localStorage.setItem('mdbook-theme', theme.slice(1, theme.length - 1)); |
| } |
| |
| if (sidebar.startsWith('"') && sidebar.endsWith('"')) { |
| localStorage.setItem('mdbook-sidebar', sidebar.slice(1, sidebar.length - 1)); |
| } |
| } catch (e) { } |
| </script> |
| |
| <!-- Set the theme before any content is loaded, prevents flash --> |
| <script> |
| const default_theme = window.matchMedia("(prefers-color-scheme: dark)").matches ? default_dark_theme : default_light_theme; |
| let theme; |
| try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { } |
| if (theme === null || theme === undefined) { theme = default_theme; } |
| const html = document.documentElement; |
| html.classList.remove('light') |
| html.classList.add(theme); |
| html.classList.add("js"); |
| </script> |
| |
| <input type="checkbox" id="sidebar-toggle-anchor" class="hidden"> |
| |
| <!-- Hide / unhide sidebar before it is displayed --> |
| <script> |
| let sidebar = null; |
| const sidebar_toggle = document.getElementById("sidebar-toggle-anchor"); |
| if (document.body.clientWidth >= 1080) { |
| try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { } |
| sidebar = sidebar || 'visible'; |
| } else { |
| sidebar = 'hidden'; |
| sidebar_toggle.checked = false; |
| } |
| if (sidebar === 'visible') { |
| sidebar_toggle.checked = true; |
| } else { |
| html.classList.remove('sidebar-visible'); |
| } |
| </script> |
| |
| <nav id="sidebar" class="sidebar" aria-label="Table of contents"> |
| <!-- populated by js --> |
| <mdbook-sidebar-scrollbox class="sidebar-scrollbox"></mdbook-sidebar-scrollbox> |
| <noscript> |
| <iframe class="sidebar-iframe-outer" src="../toc.html"></iframe> |
| </noscript> |
| <div id="sidebar-resize-handle" class="sidebar-resize-handle"> |
| <div class="sidebar-resize-indicator"></div> |
| </div> |
| </nav> |
| |
| <div id="page-wrapper" class="page-wrapper"> |
| |
| <div class="page"> |
| <div id="menu-bar-hover-placeholder"></div> |
| <div id="menu-bar" class="menu-bar sticky"> |
| <div class="left-buttons"> |
| <label id="sidebar-toggle" class="icon-button" for="sidebar-toggle-anchor" title="Toggle Table of Contents" aria-label="Toggle Table of Contents" aria-controls="sidebar"> |
| <i class="fa fa-bars"></i> |
| </label> |
| <button id="theme-toggle" class="icon-button" type="button" title="Change theme" aria-label="Change theme" aria-haspopup="true" aria-expanded="false" aria-controls="theme-list"> |
| <i class="fa fa-paint-brush"></i> |
| </button> |
| <ul id="theme-list" class="theme-popup" aria-label="Themes" role="menu"> |
| <li role="none"><button role="menuitem" class="theme" id="default_theme">Auto</button></li> |
| <li role="none"><button role="menuitem" class="theme" id="light">Light</button></li> |
| <li role="none"><button role="menuitem" class="theme" id="rust">Rust</button></li> |
| <li role="none"><button role="menuitem" class="theme" id="coal">Coal</button></li> |
| <li role="none"><button role="menuitem" class="theme" id="navy">Navy</button></li> |
| <li role="none"><button role="menuitem" class="theme" id="ayu">Ayu</button></li> |
| </ul> |
| <button id="search-toggle" class="icon-button" type="button" title="Search (`/`)" aria-label="Toggle Searchbar" aria-expanded="false" aria-keyshortcuts="/ s" aria-controls="searchbar"> |
| <i class="fa fa-search"></i> |
| </button> |
| </div> |
| |
| <h1 class="menu-title">Rust Compiler Development Guide</h1> |
| |
| <div class="right-buttons"> |
| <a href="../print.html" title="Print this book" aria-label="Print this book"> |
| <i id="print-button" class="fa fa-print"></i> |
| </a> |
| <a href="https://github.com/rust-lang/rustc-dev-guide" title="Git repository" aria-label="Git repository"> |
| <i id="git-repository-button" class="fa fa-github"></i> |
| </a> |
| <a href="https://github.com/rust-lang/rustc-dev-guide/edit/main/src/tests/running.md" title="Suggest an edit" aria-label="Suggest an edit" rel="edit"> |
| <i id="git-edit-button" class="fa fa-edit"></i> |
| </a> |
| |
| </div> |
| </div> |
| |
| <div id="search-wrapper" class="hidden"> |
| <form id="searchbar-outer" class="searchbar-outer"> |
| <div class="search-wrapper"> |
| <input type="search" id="searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="searchresults-outer" aria-describedby="searchresults-header"> |
| <div class="spinner-wrapper"> |
| <i class="fa fa-spinner fa-spin"></i> |
| </div> |
| </div> |
| </form> |
| <div id="searchresults-outer" class="searchresults-outer hidden"> |
| <div id="searchresults-header" class="searchresults-header"></div> |
| <ul id="searchresults"> |
| </ul> |
| </div> |
| </div> |
| |
| <!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM --> |
| <script> |
| document.getElementById('sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible'); |
| document.getElementById('sidebar').setAttribute('aria-hidden', sidebar !== 'visible'); |
| Array.from(document.querySelectorAll('#sidebar a')).forEach(function(link) { |
| link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1); |
| }); |
| </script> |
| |
| <div id="content" class="content"> |
| <main> |
| <h1 id="running-tests"><a class="header" href="#running-tests">Running tests</a></h1> |
| <p>You can run the entire test collection using <code>x</code>. |
| But note that running the <em>entire</em> test collection is almost never what you want to do during local |
| development because it takes a really long time. |
| For local development, see the subsection after on how to run a subset of tests.</p> |
| <div class="warning"> |
| <p>Running plain <code>./x test</code> will build the stage 1 compiler and then run the whole test suite. |
| This not only includes <code>tests/</code>, but also <code>library/</code>, <code>compiler/</code>, |
| <code>src/tools/</code> package tests and more.</p> |
| <p>You usually only want to run a subset of the test suites (or even a smaller set |
| of tests than that) which you expect will exercise your changes. |
| PR CI exercises a subset of test collections, and merge queue CI will exercise all of the test |
| collection.</p> |
| </div> |
| <pre><code class="language-text">./x test |
| </code></pre> |
| <p>The test results are cached and previously successful tests are <code>ignored</code> during testing. |
| The stdout/stderr contents as well as a timestamp file for every test |
| can be found under <code>build/<target-tuple>/test/</code> for the given |
| <code><target-tuple></code>. To force-rerun a test (e.g. in case the test runner fails to |
| notice a change) you can use the <code>--force-rerun</code> CLI option.</p> |
| <blockquote> |
| <p><strong>Note on requirements of external dependencies</strong></p> |
| <p>Some test suites may require external dependencies. This is especially true of |
| debuginfo tests. Some debuginfo tests require a Python-enabled gdb. You can |
| test if your gdb install supports Python by using the <code>python</code> command from |
| within gdb. Once invoked you can type some Python code (e.g. <code>print("hi")</code>) |
| followed by return and then <code>CTRL+D</code> to execute it. If you are building gdb |
| from source, you will need to configure with |
| <code>--with-python=<path-to-python-binary></code>.</p> |
| </blockquote> |
| <h2 id="running-a-subset-of-the-test-suites"><a class="header" href="#running-a-subset-of-the-test-suites">Running a subset of the test suites</a></h2> |
| <p>When working on a specific PR, you will usually want to run a smaller set of tests. |
| For example, a good "smoke test" that can be used after modifying rustc |
| to see if things are generally working correctly would be to exercise the <code>ui</code> |
| test suite (<a href="https://github.com/rust-lang/rust/tree/HEAD/tests/ui"><code>tests/ui</code></a>):</p> |
| <pre><code class="language-text">./x test tests/ui |
| </code></pre> |
| <p>Of course, the choice of test suites is somewhat arbitrary, and may not suit the task you are doing. |
| For example, if you are hacking on debuginfo, you may be better off with the debuginfo test suite:</p> |
| <pre><code class="language-text">./x test tests/debuginfo |
| </code></pre> |
| <p>If you only need to test a specific subdirectory of tests for any given test |
| suite, you can pass that directory as a filter to <code>./x test</code>:</p> |
| <pre><code class="language-text">./x test tests/ui/const-generics |
| </code></pre> |
| <blockquote> |
| <p><strong>Note for MSYS2</strong></p> |
| <p>On MSYS2 the paths seem to be strange and <code>./x test</code> neither recognizes |
| <code>tests/ui/const-generics</code> nor <code>tests\ui\const-generics</code>. In that case, you can |
| workaround it by using e.g. <code>./x test ui --test-args="tests/ui/const-generics"</code>.</p> |
| </blockquote> |
| <p>Likewise, you can test a single file by passing its path:</p> |
| <pre><code class="language-text">./x test tests/ui/const-generics/const-test.rs |
| </code></pre> |
| <p><code>x</code> doesn't support running a single tool test by passing its path yet. |
| You'll have to use the <code>--test-args</code> argument as described |
| <a href="#running-an-individual-test">below</a>.</p> |
| <pre><code class="language-text">./x test src/tools/miri --test-args tests/fail/uninit/padding-enum.rs |
| </code></pre> |
| <h3 id="run-only-the-tidy-script"><a class="header" href="#run-only-the-tidy-script">Run only the tidy script</a></h3> |
| <pre><code class="language-text">./x test tidy |
| </code></pre> |
| <h3 id="run-tests-on-the-standard-library"><a class="header" href="#run-tests-on-the-standard-library">Run tests on the standard library</a></h3> |
| <pre><code class="language-text">./x test --stage 0 library/std |
| </code></pre> |
| <p>Note that this only runs tests on <code>std</code>; |
| if you want to test <code>core</code> or other crates, you have to specify those explicitly.</p> |
| <h3 id="run-the-tidy-script-and-tests-on-the-standard-library"><a class="header" href="#run-the-tidy-script-and-tests-on-the-standard-library">Run the tidy script and tests on the standard library</a></h3> |
| <pre><code class="language-text">./x test --stage 0 tidy library/std |
| </code></pre> |
| <h3 id="run-tests-on-the-standard-library-using-a-stage-1-compiler"><a class="header" href="#run-tests-on-the-standard-library-using-a-stage-1-compiler">Run tests on the standard library using a stage 1 compiler</a></h3> |
| <pre><code class="language-text">./x test --stage 1 library/std |
| </code></pre> |
| <p>By listing which test suites you want to run, |
| you avoid having to run tests for components you did not change at all.</p> |
| <div class="warning"> |
| <p>Note that bors only runs the tests with the full stage 2 build; |
| therefore, while the tests <strong>usually</strong> work fine with stage 1, there are some limitations.</p> |
| </div> |
| <h3 id="run-all-tests-using-a-stage-2-compiler"><a class="header" href="#run-all-tests-using-a-stage-2-compiler">Run all tests using a stage 2 compiler</a></h3> |
| <pre><code class="language-text">./x test --stage 2 |
| </code></pre> |
| <div class="warning"> |
| You almost never need to do this; |
| CI will run these tests for you. |
| </div> |
| <h2 id="run-unit-tests-on-the-compilerlibrary"><a class="header" href="#run-unit-tests-on-the-compilerlibrary">Run unit tests on the compiler/library</a></h2> |
| <p>You may want to run unit tests on a specific file with following:</p> |
| <pre><code class="language-text">./x test compiler/rustc_data_structures/src/thin_vec/tests.rs |
| </code></pre> |
| <p>But unfortunately, it's impossible. |
| You should invoke the following instead:</p> |
| <pre><code class="language-text">./x test compiler/rustc_data_structures/ --test-args thin_vec |
| </code></pre> |
| <h2 id="running-an-individual-test"><a class="header" href="#running-an-individual-test">Running an individual test</a></h2> |
| <p>Another common thing that people want to do is to run an <strong>individual test</strong>, |
| often the test they are trying to fix. |
| As mentioned earlier, you may pass the |
| full file path to achieve this, or alternatively one may invoke <code>x</code> with the <code>--test-args</code> option:</p> |
| <pre><code class="language-text">./x test tests/ui --test-args issue-1234 |
| </code></pre> |
| <p>Under the hood, the test runner invokes the standard Rust test runner (the same |
| one you get with <code>#[test]</code>), so this command would wind up filtering for tests |
| that include "issue-1234" in the name. |
| Thus, <code>--test-args</code> is a good way to run a collection of related tests.</p> |
| <h2 id="passing-arguments-to-rustc-when-running-tests"><a class="header" href="#passing-arguments-to-rustc-when-running-tests">Passing arguments to <code>rustc</code> when running tests</a></h2> |
| <p>It can sometimes be useful to run some tests with specific compiler arguments, |
| without using <code>RUSTFLAGS</code> (during development of unstable features, with <code>-Z</code> flags, for example).</p> |
| <p>This can be done with <code>./x test</code>'s <code>--compiletest-rustc-args</code> option, to pass |
| additional arguments to the compiler when building the tests.</p> |
| <h2 id="editing-and-updating-the-reference-files"><a class="header" href="#editing-and-updating-the-reference-files">Editing and updating the reference files</a></h2> |
| <p>If you have changed the compiler's output intentionally, or you are making a new |
| test, you can pass <code>--bless</code> to the test subcommand.</p> |
| <p>As an example, if some tests in <code>tests/ui</code> are failing, you can run this command:</p> |
| <pre><code class="language-text">./x test tests/ui --bless |
| </code></pre> |
| <p>It automatically adjusts the <code>.stderr</code>, <code>.stdout</code>, or <code>.fixed</code> files of all <code>test/ui</code> tests. |
| Of course you can also target just specific tests with the <code>--test-args your_test_name</code> flag, |
| just like when running the tests without the <code>--bless</code> flag.</p> |
| <h2 id="configuring-test-running"><a class="header" href="#configuring-test-running">Configuring test running</a></h2> |
| <p>There are a few options for running tests:</p> |
| <ul> |
| <li><code>bootstrap.toml</code> has the <code>rust.verbose-tests</code> option. If <code>false</code>, each test will |
| print a single dot (the default). |
| If <code>true</code>, the name of every test will be printed. |
| This is equivalent to the <code>--quiet</code> option in the <a href="https://doc.rust-lang.org/rustc/tests/">Rust test |
| harness</a>.</li> |
| <li>The environment variable <code>RUST_TEST_THREADS</code> can be set to the number of |
| concurrent threads to use for testing.</li> |
| </ul> |
| <h2 id="passing---pass-mode"><a class="header" href="#passing---pass-mode">Passing <code>--pass $mode</code></a></h2> |
| <p>Pass UI tests now have three modes, <code>check-pass</code>, <code>build-pass</code> and <code>run-pass</code>. |
| When <code>--pass $mode</code> is passed, these tests will be forced to run under the given |
| <code>$mode</code> unless the directive <code>//@ ignore-pass</code> exists in the test file. |
| For example, you can run all the tests in <code>tests/ui</code> as <code>check-pass</code>:</p> |
| <pre><code class="language-text">./x test tests/ui --pass check |
| </code></pre> |
| <p>By passing <code>--pass $mode</code>, you can reduce the testing time. |
| For each mode, please see <a href="ui.html#controlling-passfail-expectations">Controlling pass/fail |
| expectations</a>.</p> |
| <h2 id="running-tests-with-different-compare-modes"><a class="header" href="#running-tests-with-different-compare-modes">Running tests with different "compare modes"</a></h2> |
| <p>UI tests may have different output depending on certain "modes" that the compiler is in. |
| For example, when using the Polonius mode, a test <code>foo.rs</code> will |
| first look for expected output in <code>foo.polonius.stderr</code>, falling back to the |
| usual <code>foo.stderr</code> if not found. |
| The following will run the UI test suite in Polonius mode:</p> |
| <pre><code class="language-text">./x test tests/ui --compare-mode=polonius |
| </code></pre> |
| <p>See <a href="compiletest.html#compare-modes">Compare modes</a> for more details.</p> |
| <h2 id="running-tests-manually"><a class="header" href="#running-tests-manually">Running tests manually</a></h2> |
| <p>Sometimes it's easier and faster to just run the test by hand. |
| Most tests are just <code>.rs</code> files, so after <a href="../building/how-to-build-and-run.html#creating-a-rustup-toolchain">creating a rustup |
| toolchain</a>, you |
| can do something like:</p> |
| <pre><code class="language-text">rustc +stage1 tests/ui/issue-1234.rs |
| </code></pre> |
| <p>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.</p> |
| <h2 id="running-tests-on-a-remote-machine"><a class="header" href="#running-tests-on-a-remote-machine">Running tests on a remote machine</a></h2> |
| <p>Tests may be run on a remote machine (e.g. to test builds for a different |
| architecture). |
| This is done using <code>remote-test-client</code> on the build machine to |
| send test programs to <code>remote-test-server</code> running on the remote machine. |
| <code>remote-test-server</code> executes the test programs and sends the results back to the build machine. |
| <code>remote-test-server</code> provides <em>unauthenticated remote code |
| execution</em> so be careful where it is used.</p> |
| <p>To do this, first build <code>remote-test-server</code> for the remote machine |
| (using RISC-V as an example):</p> |
| <pre><code class="language-text">./x build src/tools/remote-test-server --target riscv64gc-unknown-linux-gnu |
| </code></pre> |
| <p>The binary will be created at <code>./build/host/stage2-tools/$TARGET_ARCH/release/remote-test-server</code>. |
| Copy this over to the remote machine.</p> |
| <p>On the remote machine, run the <code>remote-test-server</code> with the <code>--bind 0.0.0.0:12345</code> flag (and optionally <code>--verbose</code> flag). |
| Output should look like this:</p> |
| <pre><code class="language-console">$ ./remote-test-server --verbose --bind 0.0.0.0:12345 |
| starting test server |
| listening on 0.0.0.0:12345! |
| </code></pre> |
| <p>Note that binding the server to 0.0.0.0 will allow all hosts able to reach your |
| machine to execute arbitrary code on your machine. |
| We strongly recommend either |
| setting up a firewall to block external access to port 12345, or to use a more |
| restrictive IP address when binding.</p> |
| <p>You can test if the <code>remote-test-server</code> is working by connecting to it and sending <code>ping\n</code>. |
| It should reply <code>pong</code>:</p> |
| <pre><code class="language-console">$ nc $REMOTE_IP 12345 |
| ping |
| pong |
| </code></pre> |
| <p>To run tests using the remote runner, set the <code>TEST_DEVICE_ADDR</code> environment |
| variable then use <code>x</code> as usual. |
| For example, to run <code>ui</code> tests for a RISC-V machine with the IP address <code>1.2.3.4</code> use</p> |
| <pre><code class="language-text">export TEST_DEVICE_ADDR="1.2.3.4:12345" |
| ./x test tests/ui --target riscv64gc-unknown-linux-gnu |
| </code></pre> |
| <p>If <code>remote-test-server</code> was run with the verbose flag, output on the test |
| machine may look something like</p> |
| <pre><code class="language-text">[...] |
| run "/tmp/work/test1007/a" |
| run "/tmp/work/test1008/a" |
| run "/tmp/work/test1009/a" |
| run "/tmp/work/test1010/a" |
| run "/tmp/work/test1011/a" |
| run "/tmp/work/test1012/a" |
| run "/tmp/work/test1013/a" |
| run "/tmp/work/test1014/a" |
| run "/tmp/work/test1015/a" |
| run "/tmp/work/test1016/a" |
| run "/tmp/work/test1017/a" |
| run "/tmp/work/test1018/a" |
| [...] |
| </code></pre> |
| <p>Tests are built on the machine running <code>x</code> not on the remote machine. |
| Tests which fail to build unexpectedly (or <code>ui</code> tests producing incorrect build |
| output) may fail without ever running on the remote machine.</p> |
| <h2 id="testing-on-emulators"><a class="header" href="#testing-on-emulators">Testing on emulators</a></h2> |
| <p>Some platforms are tested via an emulator for architectures that aren't readily available. |
| For architectures where the standard library is well supported and |
| the host operating system supports TCP/IP networking, see the above instructions |
| for testing on a remote machine (in this case the remote machine is emulated).</p> |
| <p>There is also a set of tools for orchestrating running the tests within the emulator. |
| Platforms such as <code>arm-android</code> and <code>arm-unknown-linux-gnueabihf</code> are |
| set up to automatically run the tests under emulation on GitHub Actions. |
| The following will take a look at how a target's tests are run under emulation.</p> |
| <p>The Docker image for <a href="https://github.com/rust-lang/rust/tree/HEAD/src/ci/docker/host-x86_64/armhf-gnu/Dockerfile">armhf-gnu</a> includes <a href="https://www.qemu.org/">QEMU</a> to emulate the ARM CPU architecture. |
| Included in the Rust tree are the tools <a href="https://github.com/rust-lang/rust/tree/HEAD/src/tools/remote-test-client">remote-test-client</a> and |
| <a href="https://github.com/rust-lang/rust/tree/HEAD/src/tools/remote-test-server">remote-test-server</a> which are programs for sending test programs and libraries |
| to the emulator, and running the tests within the emulator, and reading the results. |
| The Docker image is set up to launch <code>remote-test-server</code> and the |
| build tools use <code>remote-test-client</code> to communicate with the server to |
| coordinate running tests (see <a href="https://github.com/rust-lang/rust/blob/HEAD/src/bootstrap/src/core/build_steps/test.rs">src/bootstrap/src/core/build_steps/test.rs</a>).</p> |
| <p>To run on the iOS/tvOS/watchOS/visionOS simulator, we can similarly treat it as a "remote" machine. |
| A curious detail here is that the network is shared between |
| the simulator instance and the host macOS, so we can use the local loopback address <code>127.0.0.1</code>. |
| Something like the following should work:</p> |
| <pre><code class="language-sh"># Build the test server for the iOS simulator: |
| ./x build src/tools/remote-test-server --target aarch64-apple-ios-sim |
| |
| # If you already have a simulator instance open, copy the device UUID from: |
| xcrun simctl list devices booted |
| UDID=01234567-89AB-CDEF-0123-456789ABCDEF |
| |
| # Alternatively, create and boot a new simulator instance: |
| xcrun simctl list runtimes |
| xcrun simctl list devicetypes |
| UDID=$(xcrun simctl create $CHOSEN_DEVICE_TYPE $CHOSEN_RUNTIME) |
| xcrun simctl boot $UDID |
| # See https://nshipster.com/simctl/ for details. |
| |
| # Spawn the runner on port 12345: |
| xcrun simctl spawn $UDID ./build/host/stage2-tools/aarch64-apple-ios-sim/release/remote-test-server -v --bind 127.0.0.1:12345 |
| |
| # In a new terminal, run tests via the runner: |
| export TEST_DEVICE_ADDR="127.0.0.1:12345" |
| ./x test --host='' --target aarch64-apple-ios-sim --skip tests/debuginfo |
| # FIXME(madsmtm): Allow debuginfo tests to work (maybe needs `.dSYM` folder to be copied to the target?). |
| </code></pre> |
| <h2 id="testing-tests-on-wasi-wasm32-wasip1"><a class="header" href="#testing-tests-on-wasi-wasm32-wasip1">Testing tests on wasi (wasm32-wasip1)</a></h2> |
| <p>Some tests are specific to wasm targets. |
| To run theste tests, you have to pass <code>--target wasm32-wasip1</code> to <code>x test</code>. |
| Additionally, you need the wasi sdk. |
| Follow the install instructions from the <a href="https://github.com/WebAssembly/wasi-sdk">wasi sdk repository</a> to get a sysroot on your computer. |
| On the <a href="https://github.com/rust-lang/rust/blob/HEAD/src/doc/rustc/src/platform-support/wasm32-wasip1.md#building-the-target.">wasm32-wasip1 target support page</a> a minimum version is specified that your sdk must be able to build. |
| Some cmake commands that take a while and give a lot of very concerning c++ warnings... |
| Then, in <code>bootstrap.toml</code>, point to the sysroot like so:</p> |
| <pre><code class="language-toml">[target.wasm32-wasip1] |
| wasi-root = "<wasi-sdk location>/build/sysroot/install/share/wasi-sysroot" |
| </code></pre> |
| <p>In my case I git-cloned it next to my rust folder, so it was <code>../wasi-sdk/build/....</code> |
| Now, tests should just run, you don't have to set up anything else.</p> |
| |
| </main> |
| |
| <nav class="nav-wrapper" aria-label="Page navigation"> |
| <!-- Mobile navigation buttons --> |
| <a rel="prev" href="../tests/intro.html" class="mobile-nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left"> |
| <i class="fa fa-angle-left"></i> |
| </a> |
| |
| <a rel="next prefetch" href="../tests/docker.html" class="mobile-nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right"> |
| <i class="fa fa-angle-right"></i> |
| </a> |
| |
| <div style="clear: both"></div> |
| </nav> |
| </div> |
| </div> |
| |
| <nav class="nav-wide-wrapper" aria-label="Page navigation"> |
| <a rel="prev" href="../tests/intro.html" class="nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left"> |
| <i class="fa fa-angle-left"></i> |
| </a> |
| |
| <a rel="next prefetch" href="../tests/docker.html" class="nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right"> |
| <i class="fa fa-angle-right"></i> |
| </a> |
| </nav> |
| |
| </div> |
| |
| |
| |
| |
| <script> |
| window.playground_copyable = true; |
| </script> |
| |
| |
| <script src="../elasticlunr.min.js"></script> |
| <script src="../mark.min.js"></script> |
| <script src="../searcher.js"></script> |
| |
| <script src="../clipboard.min.js"></script> |
| <script src="../highlight.js"></script> |
| <script src="../book.js"></script> |
| |
| <!-- Custom JS scripts --> |
| <script src="../mermaid.min.js"></script> |
| <script src="../mermaid-init.js"></script> |
| <script src="../pagetoc.js"></script> |
| |
| |
| |
| </div> |
| </body> |
| </html> |
