| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Currently `run-make` tests do not support revisions.
|
|
|
|
|
|
This was previously only including ordinary `aux-build` crates, and not files
associated with the other three kinds of auxiliary crate.
|
|
|
|
|
|
compiletest: Simplify the choice of `--emit` mode for assembly tests
Tiny little cleanup that I noticed while working on #131524. No functional change.
Historically, the original code structure (#58791) predates the `Emit` enum (#103298), so it was manually adding `--emit` flags to the compiler invocation. But now the match can just evaluate to the appropriate `Emit` value directly.
|
|
|
|
This hack was intended to handle the case where `-Clto=thin` causes the
compiler to emit multiple output files (when producing LLVM-IR or assembly).
The hack only affects 4 tests, of which 3 are just meta-tests for the hack
itself. The one remaining test that motivated the hack currently doesn't even
need it!
(`tests/codegen/issues/issue-81408-dllimport-thinlto-windows.rs`)
|
|
add test infra to explicitely test rustc with autodiff/enzyme disabled
I assume this is not what you want for now, but I'll update the PR once I understand how the ignore- directives work.
To summarize the situation, we want a feature gate test where we don't enable the autodiff feature using `#![feature(autodiff)]`. There are two situations.
1) We have a rustc which was build without autodiff support (current default): It gives one error about the feature being needed and one error about this rustc version being build without autodiff support.
2) We have a rustc which was build with autodiff support (i.e. for now a custom build): It gives one error about the feature being needed.
We have a `//`````@needs-enzyme`````` directive which we can use in revisions for the second case.
However, we have no way to specify that needs-enzyme implies that the second error should not be seen.
This ads a way of passing the following test:
```
//@ revisions: has_support no_support
//`````@[has_support]````` needs-enzyme
//`````@[no_support]````` needs-enzyme-disabled
#![crate_type = "lib"]
#[autodiff(dfoo, Reverse)]
//[has_support]~^ ERROR use of unstable library feature 'autodiff' [E0658]
//[no_support]~^^ ERROR use of unstable library feature 'autodiff' [E0658]
//[no_support]~| ERROR this rustc version does not support autodiff
fn foo() {}
```
Cherry picking this PR to my frontend pr makes the test above pass in both configurations (enzyme=true/false in config.toml).
I'm open to other changes that make this testcase pass.
r? `````@jieyouxu`````
Tracking:
- https://github.com/rust-lang/rust/issues/124509
|
|
|
|
Add "reference" as a known compiletest header
This adds the "reference" compiletest header so that the Rust reference can add annotations to the test suite in order to link tests to individual rules in the reference.
Tooling in the reference repo will be responsible for collecting these annotations and linking to the tests.
More details are in MCP 783: https://github.com/rust-lang/compiler-team/issues/783
There is a change from the MCP in that I am not adding the JSON collection to compiletest (at least, not yet). In looking at this more closely, that actually makes things more difficult for our tooling, so I'm leaving it out for now. If in the future it looks like something we want, then I think we can add it later.
There are a few tests here which need adjusting due to the legacy header check. `@jieyouxu` indicated on Zulip that we could potentially remove the legacy header check, in which case those changes can be dropped from this PR.
r? `@jieyouxu`
|
|
This adds the "reference" compiletest header so that the Rust reference
can add annotations to the test suite in order to link tests to
individual rules in the reference.
Tooling in the reference repo will be responsible for collecting these
annotations and linking to the tests.
More details are in MCP 783: https://github.com/rust-lang/compiler-team/issues/783
|
|
This cache struct entry was a relic from when profiler availability was
communicated via an environment variable rather than a command-line flag.
|
|
|
|
|
|
Simplify the compiletest directives for ignoring coverage-test modes
Follow-up to #131346.
Given that these directives are now restricted to ignoring coverage-test modes only, we can drop the clunky `ignore-mode-*` naming convention, and just call them `ignore-coverage-map` and `ignore-coverage-run`.
r? jieyouxu
|
|
|
|
Sufficient time has passed (> 6 months) since we migrated from `//` to
`//@`, so let's drop the legacy directive check as it causes friction
due to false positives.
|
|
Remove valgrind test suite and support from compiletest, bootstrap and opt-dist
The `run-pass-valgrind` test suite is not exercised in CI, and as far as I'm aware nobody runs it (asked in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Are.20the.20valgrind.20tests.20even.20used.20by.20anyone.3F). What's remaining of valgrind support in compiletest isn't even properly hooked up with bootstrap.
The existing valgrind logic in compiletest is also straight up questionable, i.e.
https://github.com/rust-lang/rust/blob/1b3b8e7b0265162853c650ead09905bc3cdaeae9/src/tools/compiletest/src/runtest/valgrind.rs#L7-L12
It just runs valgrind tests as `rpass` if no valgrind path is provided to compiletest from bootstrap -- but bootstrap doesn't even pass a valgrind path to compiletest in the first place, so this always ran as `rpass` tests. So what is this even testing?
So if it's not testing anything, let's delete it.
Closes #44816 by deleting the test suite :3
<img src="https://github.com/user-attachments/assets/99525bf7-e85b-40ba-9281-e4e1e275c4e8" width=300 />
|
|
Add documentation for `runtest::check_rustdoc_test_option` method
r? `@jieyouxu`
|
|
|
|
|
|
These are only valid for coverage test modes.
|
|
|
|
Implement RFC3137 trim-paths sysroot changes - take 2
This PR is a continuation of https://github.com/rust-lang/rust/pull/118149. Nothing really changed, except for https://github.com/rust-lang/rust/pull/129408 which I was able to trigger locally.
Original description:
> Implement parts of #111540
>
> Right now, backtraces into sysroot always shows /rustc/$hash in diagnostics, e.g.
>
> ```
> thread 'main' panicked at 'hello world', map-panic.rs:2:50
> stack backtrace:
> 0: std::panicking::begin_panic
> at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:616:12
> 1: map_panic::main::{{closure}}
> at ./map-panic.rs:2:50
> 2: core::option::Option<T>::map
> at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/option.rs:929:29
> 3: map_panic::main
> at ./map-panic.rs:2:30
> 4: core::ops::function::FnOnce::call_once
> at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/ops/function.rs:248:5
> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
> ```
>
> [RFC 3127 said](https://rust-lang.github.io/rfcs/3127-trim-paths.html#changing-handling-of-sysroot-path-in-rustc)
>
> > We want to change this behaviour such that, when rust-src source files can be discovered, the virtual path is discarded and therefore the local path will be embedded, unless there is a --remap-path-prefix that causes this local path to be remapped in the usual way.
>
> This PR implements this behaviour. When `rust-src` is present at compile time, rustc replaces /rustc/$hash with a real path into local rust-src with best effort. To sanitise this, users must explicitly supply `--remap-path-prefix=<path to rust-src>=foo`.
cc `@cbeuw`
Fix #105907
Fix #85463
try-job: dist-x86_64-linux
try-job: x86_64-msvc
try-job: dist-x86_64-msvc
try-job: armhf-gnu
|
|
in case the real paths into the libstd/libcore are located inside the
the build directory, maybe because it's coming from an extracted dist
component in the build dir (cc opt-dist)
|
|
with the test directory
r? jieyouxu
|
|
|
|
|
|
cargo_metadata, thorin-dwp, windows
|
|
|
|
rustdoc: redesign toolbar and disclosure widgets
Fixes #77899
Fixes #90310
## Preview
| before | after
| ------ | -----
|  | 
|  | 
|  | 
|  | 
|  | 
| N/A | 
|  | 
|  | 
https://notriddle.com/rustdoc-html-demo-12/toolbar-v2/std/index.html
## Description
This adds labels to the icons and moves them away from the search box.
These changes are made together, because they work together, but are based on several complaints:
* The [+/-] thing are a Reddit-ism. They don't look like buttons, but look like syntax <https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/More.20visual.20difference.20for.20the.20.2B.2F-.20.20Icons>, <https://github.com/rust-lang/rust/issues/59851> (some of these are laundry lists with more suggestions, but they all mention [+/-] looking wrong)
* The settings, help, and summary buttons are also too hard to recognize <https://lwn.net/Articles/987070/>, <https://github.com/rust-lang/rust/issues/90310>, <https://github.com/rust-lang/rust/issues/14475#issuecomment-274241997>, <https://internals.rust-lang.org/t/improve-rustdoc-design/12758> ("Not all functionality is self-explanatory, for example the [+] button in the top right corner, the theme picker or the settings button.")
The toggle-all and toggle-individual buttons both need done at once, since we want them to look like they go together. This changes them from both being [+/-] to both being arrows.
CC <https://github.com/rust-lang/rust/pull/113074#issuecomment-1677469680> and ``@jsha`` regarding the use of triangles for disclosure, which is what everyone wanted, but was pending a good toggle-all button. This PR adds a toggle-all button that should work.
Settings and Help are also migrated, so that the whole group can benefit from being described using actual words.
The breadcrumbs also get redesigned, so that they use less space, by shrinking the parent module path parts. This is done at the same time as the toolbar redesign because it's, effectively, moving space from the toolbar to the breadcrumbs.
This is aimed at avoiding any line wrapping at desktop sizes.
## Prior art
This style of toolbar, with explicit labels on the buttons, used to be more popular. It's not very common in web browsers nowadays, and for truly universal icons like :arrow_left: I can understand why, but words are great when icons fail.
|
|
|
|
A couple tests were using `BOOTSTRAP_CARGO` with `-Zbuild-std`, but that
stage0 cargo might not always be in sync with in-tree changes. In
particular, those tests started failing on the beta branch because the
older cargo couldn't find the library `Cargo.lock`, and then couldn't
build the latest version of `compiler_builtins` that had nightly changes.
|
|
Break up compiletest `runtest.rs` into smaller helper modules
Previously compiletest's `runtest.rs` was a massive 4700 lines file that made reading and navigation very awkward. This PR breaks the `runtest.rs` file up into smaller helper modules, one for each test suite/mode.
> [!NOTE]
> This PR should not contain functional changes, it is intended to be mostly code motion to breakup `runtest.rs` into smaller helper modules to make it easier to digest.
>
> This PR intentionally does not neatly reorganize where all the methods on `TestCx` goes, that is intended for a follow-up PR. Some methods on `TestCx` do not need to be on `TestCx`. It also does not address a weirdness in valgrind, that is intended for a follow-up PR as well.
Part of a series of compiletest cleanups #130565.
Fixes #89475.
r? `@ghost` (I need to do a self-review pass first)
|
|
|
|
Previously compiletest's `runtest.rs` was a massive 4700 lines file that
made reading and navigation very awkward.
This commit intentionally does not neatly reorganize where all the
methods on `TestCx` goes, that is intended for a follow-up PR.
|
|
|
|
refactor merge base logic and fix `x fmt`
When remote upstream is not configured, using [get_git_modified_files](https://github.com/rust-lang/rust/blob/38e3a5771cefc9362976a605549f8b04d5707311/src/tools/build_helper/src/git.rs#L114) to find modified files fails because [get_rust_lang_rust_remote](https://github.com/rust-lang/rust/blob/38e3a5771cefc9362976a605549f8b04d5707311/src/tools/build_helper/src/git.rs#L46-L48) can not resolve "rust-lang/rust" from the git output. The changes in this PR makes bootstrap to find the latest bors commit, treating it as the "closest upstream commit" so that the change tracker logic can use it to find the diffs.
In addition, [skips formatting](https://github.com/rust-lang/rust/commit/e3924544832668a6e239153a90d3be2077fbdce4) if there are no modified files.
Fixes #130147
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
This adds labels to the icons and moves them away from the search box.
These changes are made together, because they work together, but are based on
several complaints:
* The [+/-] thing are a Reddit-ism. They don't look like buttons, but look
like syntax
<https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/More.20visual.20difference.20for.20the.20.2B.2F-.20.20Icons>,
<https://github.com/rust-lang/rust/issues/59851>
(some of these are laundry lists with more suggestions, but they all
mention [+/-] looking wrong)
* The settings, help, and summary buttons are also too hard to recognize
<https://lwn.net/Articles/987070/>,
<https://github.com/rust-lang/rust/issues/90310>,
<https://github.com/rust-lang/rust/issues/14475#issuecomment-274241997>,
<https://internals.rust-lang.org/t/improve-rustdoc-design/12758>
("Not all functionality is self-explanatory, for example the [+] button in
the top right corner, the theme picker or the settings button.")
The toggle-all and toggle-individual buttons both need done at once, since we
want them to look like they go together. This changes them from both being
[+/-] to both being arrows.
Settings and Help are also migrated, so that the whole group can benefit from
being described using actual words.
Additionally, the Help button is only shown on SERPs, not all the time.
This is done for two major reasons:
* Most of what's in there is search-related. The things that aren't are
keyboard commands, and the search box tells you about that anyway.
Pressing <kbd>?</kbd> will temporarily show the button and its popover.
* I'm trading it off by showing the help button, even on mobile.
It's useful since you can use the search engine suggestions there.
* The three buttons were causing line wrapping on too many desktop layouts.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
When running tests without the `--force-rerun` flag, compiletest will
automatically skip any tests that (in its judgement) don't need to be run again
since the last time they were run.
This patch adds an explicit reason to those skipped tests, which is visible
when running with `rust.verbose-tests = true` in `config.toml`.
|
|
enable -Zrandomize-layout in debug CI builds
This builds rustc/libs/tools with `-Zrandomize-layout` on *-debug CI runners.
Only a handful of tests and asserts break with that enabled, which is promising. One test was fixable, the rest is dealt with by disabling them through new cargo features or compiletest directives.
The config.toml flag `rust.randomize-layout` defaults to false, so it has to be explicitly enabled for now.
|
|
Additionally teach compiletest to ignore tests that rely on deterministic layout.
Tests themselves aren't built with randomization but they can still observe
slight changes in std or rustc
|
|
explicitly disable `-Zmir-include-spans` in mir-opt tests
This will override the NLL default of true, and keep the blessed dumps
easier to work with.
|
|
|
