about summary refs log tree commit diff
path: root/src/bootstrap/test.rs
AgeCommit message (Collapse)AuthorLines
2019-12-17Revert "Auto merge of #67362 - Mark-Simulacrum:par-4-default, r=alexcrichton"Mark Rousskov-13/+13
This reverts commit 3ed3b8bb7b100afecf7d5f52eafbb70fec27f537, reversing changes made to 99b89533d4cdf7682ea4054ad0ee36c351d05df1. We will reland a similar patch at a future date but for now we should get a nightly released in a few hours with the parallel patch, so this should be reverted to make sure that the next nightly is not parallel-enabled.
2019-12-17Disable cargo tests for nowMark Rousskov-13/+13
These depend on rustc being bug-free and it looks like that's not currently entirely the case (e.g., we know of at least one bug that introduces nondeterminism).
2019-12-11rustc: Link LLVM directly into rustc againAlex Crichton-1/+1
This commit builds on #65501 continue to simplify the build system and compiler now that we no longer have multiple LLVM backends to ship by default. Here this switches the compiler back to what it once was long long ago, which is linking LLVM directly to the compiler rather than dynamically loading it at runtime. The `codegen-backends` directory of the sysroot no longer exists and all relevant support in the build system is removed. Note that `rustc` still supports a dynamically loaded codegen backend as it did previously, it just no longer supports dynamically loaded codegen backends in its own sysroot. Additionally as part of this the `librustc_codegen_llvm` crate now once again explicitly depends on all of its crates instead of implicitly loading them through the sysroot. This involved filling out its `Cargo.toml` and deleting all the now-unnecessary `extern crate` annotations in the header of the crate. (this in turn required adding a number of imports for names of macros too). The end results of this change are: * Rustbuild's build process for the compiler as all the "oh don't forget the codegen backend" checks can be easily removed. * Building `rustc_codegen_llvm` is much simpler since it's simply another compiler crate. * Managing the dependencies of `rustc_codegen_llvm` is much simpler since it's "just another `Cargo.toml` to edit" * The build process should be a smidge faster because there's more parallelism in the main rustc build step rather than splitting `librustc_codegen_llvm` out to its own step. * The compiler is expected to be slightly faster by default because the codegen backend does not need to be dynamically loaded. * Disabling LLVM as part of rustbuild is still supported, supporting multiple codegen backends is still supported, and dynamic loading of a codegen backend is still supported.
2019-11-11Update clippyManish Goregaokar-0/+5
2019-10-26use plain cargo to install xargoRalf Jung-11/+1
2019-10-26bootstrap now takes care of installing xargoRalf Jung-4/+21
2019-10-21Remove `src/llvm-emscripten` submoduleAlex Crichton-2/+1
With #65251 landed there's no need to build two LLVM backends and ship them with rustc, every target we have now uses the same LLVM backend! This removes the `src/llvm-emscripten` submodule and additionally removes all support from rustbuild for building the emscripten LLVM backend. Multiple codegen backend support is left in place for now, and this is intended to be an easy 10-15 minute win on CI times by avoiding having to build LLVM twice.
2019-10-19adjust miri sysroot determinationRalf Jung-6/+4
2019-10-16Upgrade Emscripten targets to use upstream LLVM backendThomas Lively-2/+3
- Compatible with Emscripten 1.38.46-upstream or later upstream. - Refactors the Emscripten target spec to share code with other wasm targets. - Replaces the old incorrect wasm32 C call ABI with the correct one, preserving the old one as wasm32_bindgen_compat for wasm-bindgen compatibility. - Updates the varargs ABI used by Emscripten and deletes the old one. - Removes the obsolete wasm32-experimental-emscripten target. - Uses EMCC_CFLAGS on CI to avoid the timeout problems with #63649.
2019-10-05Revert "Auto merge of #63649 - tlively:emscripten-upstream-upgrade, ↵Tyler Mandry-3/+2
r=alexcrichton" This reverts commit 7870050796e5904a0fc85ecbe6fa6dde1cfe0c91, reversing changes made to 2e7244807a7878f6eca3eb7d97ae9b413aa49014.
2019-10-04Fix ABI, run and fix more tests, re-enable CI for PRsThomas Lively-2/+5
2019-10-04Upgrade Emscripten targets to use upstream LLVM backendThomas Lively-4/+2
- Refactors the Emscripten target spec to share code with other wasm targets. - Replaces the incorrect wasm32 C call ABI with the old asmjs version, which is correct for both wasm32 and JS. - Updates the varargs ABI used by Emscripten and deletes the old one. - Removes the obsolete wasm32-experimental-emscripten target. - Temporarily makes Emscripten targets use panic=abort by default because supporting unwinding will require an LLVM patch.
2019-09-23Move handling of `-Cprefer-dynamic` into `builder.rs`Alex Crichton-4/+0
This logic is *super* old and can be tweaked and moved into `builder.rs`
2019-09-23Allow adding `RUSTFLAGS` after `Builder::cargo`Alex Crichton-19/+19
This commit changes the return type of `Builder::cargo` to return a builder that allows dynamically adding more `RUSTFLAGS` values after-the-fact. While not used yet, this will later be used to delete more of `rustc.rs`
2019-09-23bootstrap: Remove usage of `RUSTC_TARGET_LINKER`Alex Crichton-11/+1
Cargo has a native enviroment variable for this.
2019-09-05Explicitly create test tempdirMark Rousskov-1/+4
2019-08-28std: Remove the `wasm_syscall` featureAlex Crichton-10/+0
This commit removes the `wasm_syscall` feature from the wasm32-unknown-unknown build of the standard library. This feature was originally intended to allow an opt-in way to interact with the operating system in a posix-like way but it was never stabilized. Nowadays with the advent of the `wasm32-wasi` target that should entirely replace the intentions of the `wasm_syscall` feature.
2019-08-23bootstrap: Merge the libtest build step with libstdAlex Crichton-28/+8
Since its inception rustbuild has always worked in three stages: one for libstd, one for libtest, and one for rustc. These three stages were architected around crates.io dependencies, where rustc wants to depend on crates.io crates but said crates don't explicitly depend on libstd, requiring a sysroot assembly step in the middle. This same logic was applied for libtest where libtest wants to depend on crates.io crates (`getopts`) but `getopts` didn't say that it depended on std, so it needed `std` built ahead of time. Lots of time has passed since the inception of rustbuild, however, and we've since gotten to the point where even `std` itself is depending on crates.io crates (albeit with some wonky configuration). This commit applies the same logic to the two dependencies that the `test` crate pulls in from crates.io, `getopts` and `unicode-width`. Over the many years since rustbuild's inception `unicode-width` was the only dependency picked up by the `test` crate, so the extra configuration necessary to get crates building in this crate graph is unlikely to be too much of a burden on developers. After this patch it means that there are now only two build phasese of rustbuild, one for libstd and one for rustc. The libtest/libproc_macro build phase is all lumped into one now with `std`. This was originally motivated by rust-lang/cargo#7216 where Cargo was having to deal with synthesizing dependency edges but this commit makes them explicit in this repository.
2019-08-20Remove serialization of diagnostics to filesMark Rousskov-2/+1
This is no longer used by the index generator and was always an unstable compiler detail, so strip it out. This also leaves in RUSTC_ERROR_METADATA_DST since the stage0 compiler still needs it to be set.
2019-08-08don't set RUSTC_DEBUG_ASSERTIONS here; let cargo-miri do thatRalf Jung-2/+0
2019-08-08install and use xargo inside the build dirRalf Jung-0/+4
2019-08-08let us try to find out where that panic is coming fromRalf Jung-0/+2
2019-08-08dont test Miri by default (also be more verbose when being verbose)Ralf Jung-1/+1
2019-08-08more commentsRalf Jung-0/+1
2019-08-08remove test-miri flag from bootstrapRalf Jung-2/+1
2019-08-08Miri test: call 'cargo miri test' and use the sysroot it has set upRalf Jung-11/+71
2019-08-02Fix rustc-guide toolstate tracking.Eric Huss-1/+6
2019-08-01replace what I think is an erroneous try_run_quiet by try_runRalf Jung-1/+1
2019-07-30Auto merge of #62766 - alexcrichton:stabilize-pipelined-compilation, r=oli-obkbors-0/+3
rustc: Stabilize options for pipelined compilation This commit stabilizes options in the compiler necessary for Cargo to enable "pipelined compilation" by default. The concept of pipelined compilation, how it's implemented, and what it means for rustc are documented in #60988. This PR is coupled with a PR against Cargo (rust-lang/cargo#7143) which updates Cargo's support for pipelined compliation to rustc, and also enables support by default in Cargo. (note that the Cargo PR cannot land until this one against rustc lands). The technical changes performed here were to stabilize the functionality proposed in #60419 and #60987, the underlying pieces to enable pipelined compilation support in Cargo. The issues have had some discussion during stabilization, but the newly stabilized surface area here is: * A new `--json` flag was added to the compiler. * The `--json` flag can be passed multiple times. * The value of the `--json` flag is a comma-separated list of directives. * The `--json` flag cannot be combined with `--color` * The `--json` flag must be combined with `--error-format=json` * The acceptable list of directives to `--json` are: * `diagnostic-short` - the `rendered` field of diagnostics will have a "short" rendering matching `--error-format=short` * `diagnostic-rendered-ansi` - the `rendered` field of diagnostics will be colorized with ansi color codes embedded in the string field * `artifacts` - JSON blobs will be emitted for artifacts being emitted by the compiler The unstable `-Z emit-artifact-notifications` and `--json-rendered` flags have also been removed during this commit as well. Closes #60419 Closes #60987 Closes #60988
2019-07-29Fix rustc-guide build failure ignoring no-fail-fast.kennytm-3/+1
This caused clippy not being built on Linux previously.
2019-07-27Remove run-pass test suitesVadim Petrochenkov-20/+0
2019-07-26rustc: Stabilize options for pipelined compilationAlex Crichton-0/+3
This commit stabilizes options in the compiler necessary for Cargo to enable "pipelined compilation" by default. The concept of pipelined compilation, how it's implemented, and what it means for rustc are documented in #60988. This PR is coupled with a PR against Cargo (rust-lang/cargo#7143) which updates Cargo's support for pipelined compliation to rustc, and also enables support by default in Cargo. (note that the Cargo PR cannot land until this one against rustc lands). The technical changes performed here were to stabilize the functionality proposed in #60419 and #60987, the underlying pieces to enable pipelined compilation support in Cargo. The issues have had some discussion during stabilization, but the newly stabilized surface area here is: * A new `--json` flag was added to the compiler. * The `--json` flag can be passed multiple times. * The value of the `--json` flag is a comma-separated list of directives. * The `--json` flag cannot be combined with `--color` * The `--json` flag must be combined with `--error-format=json` * The acceptable list of directives to `--json` are: * `diagnostic-short` - the `rendered` field of diagnostics will have a "short" rendering matching `--error-format=short` * `diagnostic-rendered-ansi` - the `rendered` field of diagnostics will be colorized with ansi color codes embedded in the string field * `artifacts` - JSON blobs will be emitted for artifacts being emitted by the compiler The unstable `-Z emit-artifact-notifications` and `--json-rendered` flags have also been removed during this commit as well. Closes #60419 Closes #60987 Closes #60988
2019-07-26`run_quiet` outputs stdout/stderr when things go wrong.Giles Cope-1/+1
(was `run` uses `run_silent` under the covers.)
2019-07-15ci: Remove Travis/AppVeyor configurationAlex Crichton-15/+0
Now that we've fully moved to Azure Pipelines and bors has been updated to only gate on Azure this commit removes the remaining Travis/AppVeyor support contained in this repository. Most of the deletions here are related to producing better output on Travis by folding certain sections. This isn't supported by Azure so there's no need to keep it around, and if Azure ever adds support we can always add it back!
2019-07-06Add linkcheck command to rustbook toolAndré Luis Leal Cardoso Junior-1/+25
2019-07-06add ./x.py test src/doc/rustc-guideAndré Luis Leal Cardoso Junior-0/+1
2019-06-24bootstrap: pass '--pass' on to compiletest.Mazdak Farrokhzad-0/+5
2019-06-23Make tidy quieter by defaultMark Rousskov-2/+2
2019-05-30Auto merge of #61212 - alexcrichton:skip-rustc, r=pietroalbinibors-9/+5
ci: Attempt to skip a full rustc compile on dist* Currently when we're preparing cross-compiled compilers it can take quite some time because we have to build the compiler itself three different times. The first is the normal bootstrap, the second is a second build for the build platform, and the third is the actual target architecture compiler. The second compiler was historically built exclusively for procedural macros, and long ago we didn't actually need it. This commit tries out avoiding that second compiled compiler, meaning we only compile rustc for the build platform only once. Some local testing shows that this is promising, but bors is of course the ultimate test!
2019-05-28rustbuild: Tweak how stage1 compilers are selectedAlex Crichton-9/+5
This commit furthers the previous one to ensure that we don't build an extra stage of the compiler in CI. A test has been added to rustbuild to ensure that this doesn't regress, and then in debugging this test it was hunted down that the `dist::Std` target was the one erroneously pulling in the wrong compiler. The `dist::Std` step was updated to instead account for the "full bootstrap" or not flag, ensuring that the correct compiler for compiling the final standard library was used. This was another use of the `force_use_stage1` function which was in theory supposed to be pretty central, so existing users were all evaluated and a new function, `Builder::compiler_for`, was introduced. All existing users of `force_use_stage1` have been updated to use `compiler_for`, where the semantics of `compiler_for` are similar to that of `compiler` except that it doesn't guarantee the presence of a sysroot for the arguments passed (as they may be modified). Perhaps one day we can unify `compiler` and `compiler_for`, but the usage of `Builder::compiler` is so ubiquitous it would take quite some time to evaluate whether each one needs the sysroot or not, so it's hoped that can be done in parallel.
2019-05-27Only build clang_rt when RUSTBUILD_FORCE_CLANG_BASED_TESTS is set.Michael Woerister-18/+3
2019-05-24rustbuild: Simplify debuginfo configurationVadim Petrochenkov-3/+1
2019-05-23Auto merge of #60970 - MaulingMonkey:pr-compiletest-cdb-support, r=alexcrichtonbors-6/+2
Add basic CDB support to debuginfo compiletest s, to help catch `*.natvis` regressions, like those fixed in #60687. First draft, feedback welcome. Several Microsoft debuggers (VS, VS Code, WinDbg, CDB, ...) consume the `*.natvis` files we embed into rust `*.pdb` files. While this only tests CDB, that test coverage should help for all of them. # Changes ## src\bootstrap - test.rs: Run CDB debuginfo tests on MSVC targets ## src\test\debuginfo - issue-13213.rs: CDB has trouble with this, skip for now (newly discovered regression?) - pretty-std.rs: Was ignored, re-enable for CDB only to start with, add CDB tests. - should-fail.rs: Add CDB tests. ## src\tools\compiletest: - Added "-cdb" option - Added Mode::DebugInfoCdb ("debuginfo-cdb") - Added run_debuginfo_cdb_test[_no_opt] - Renamed Mode::DebugInfoBoth -> DebugInfoGdbLldb ("debuginfo-gdb+lldb") since it's no longer clear what "Both" means. - Find CDB at the default Win10 SDK install path "C:\Program Files (x86)\Windows Kits\10\Debugger\\*\cdb.exe" - Ignore CDB tests if CDB not found. # Issues - `compute_stamp_hash`: not sure if there's any point in hashing `%ProgramFiles(x86)%` - `OsString` lacks any `*.natvis` entries (would be nice to add in a followup changelist) - DSTs (array/string slices) which work in VS & VS Code fail in CDB. - I've avoided `Mode::DebugInfoAll` as 3 debuggers leads to pow(2,3)=8 possible combinations. # Reference CDB is not part of the base Visual Studio install, but can be added via the Windows 10 SDK: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk Installing just "Debugging Tools for Windows" is sufficient. CDB appears to already be installed on appveyor CI, where this changelist can find it, based on it's use here: https://github.com/rust-lang/rust/blob/0ffc57311030a1930edfa721fe57d0000a063af4/appveyor.yml#L227 CDB commands and command line reference: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-reference
2019-05-19Add basic CDB support to debuginfo compiletest s, to help catch `*.natvis` ↵MaulingMonkey-6/+2
regressions, like those fixed in #60687. Several Microsoft debuggers (VS, VS Code, WinDbg, CDB, ...) consume the `*.natvis` files we embed into rust `*.pdb` files. While this only tests CDB, that test coverage should help for all of them. CHANGES src\bootstrap - test.rs: Run CDB debuginfo tests on MSVC targets src\test\debuginfo - issue-13213.rs: CDB has trouble with this, skip for now (newly discovered regression?) - pretty-std.rs: Was ignored, re-enable for CDB only to start with, add CDB tests. - should-fail.rs: Add CDB tests. src\tools\compiletest: - Added "-cdb" option - Added Mode::DebugInfoCdb ("debuginfo-cdb") - Added run_debuginfo_cdb_test[_no_opt] - Renamed Mode::DebugInfoBoth -> DebugInfoGdbLldb ("debuginfo-gdb+lldb") since it's no longer clear what "Both" means. - Find CDB at the default Win10 SDK install path "C:\Program Files (x86)\Windows Kits\10\Debugger\*\cdb.exe" - Ignore CDB tests if CDB not found. ISSUES - `compute_stamp_hash`: not sure if there's any point in hashing `%ProgramFiles(x86)%` - `OsString` lacks any `*.natvis` entries (would be nice to add in a followup changelist) - DSTs (array/string slices) which work in VS & VS Code fail in CDB. - I've avoided `Mode::DebugInfoAll` as 3 debuggers leads to pow(2,3)=8 possible combinations. REFERENCE CDB is not part of the base Visual Studio install, but can be added via the Windows 10 SDK: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk Installing just "Debugging Tools for Windows" is sufficient. CDB appears to already be installed on appveyor CI, where this changelist can find it, based on it's use here: https://github.com/rust-lang/rust/blob/0ffc57311030a1930edfa721fe57d0000a063af4/appveyor.yml#L227 CDB commands and command line reference: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-reference
2019-05-18Fix tests not running locallyGuillaume Gomez-1/+1
2019-05-14Rollup merge of #60719 - varkor:xpy-test-folder, r=Mark-SimulacrumMazdak Farrokhzad-2/+13
Allow subdirectories to be tested by x.py test Fixes https://github.com/rust-lang/rust/issues/60718. As far as I can tell, multiple `--test-args` flags are ignored (only the first is respected), so if you specify a subdirectory, you won't also be able to filter using `--test-args`. If you don't specify a subdirectory, `--test-args` will continue working as usual, so this is strictly an improvement on the current state of affairs.
2019-05-14Add commentvarkor-0/+6
2019-05-11Allow subdirectories to be tested by x.py testvarkor-2/+7
2019-05-10Make tests compatible with musl hostMateusz Mikuła-0/+4
2019-05-09remove unneeded `extern crate`s from build toolsAndy Russell-1/+1
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 01:07:00 +0000