| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Move ~100 tests from tests/ui to subdirs
new dirs for some, the rest in old
sweep tests up before they turn cold
to stop our code from growing mold
|
|
Migrate `run-make/no-intermediate-extras` to new `rmake.rs`
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
|
|
|
|
- Move super-fast-paren-parsing test into ui/parser
- Move stmt_expr_attrs test into ui/feature-gates
- Move macro tests into ui/macros
- Move global_asm tests into ui/asm
- Move env tests into ui/process
- Move xcrate tests into ui/cross-crate
- Move unop tests into ui/unop
- Move backtrace tests into ui/backtrace
- Move check-static tests into ui/statics
- Move expr tests into ui/expr
- Move optimization fuel tests into ui/fuel
- Move ffi attribute tests into ui/ffi-attrs
- Move suggestion tests into ui/suggestions
- Move main tests into ui/fn-main
- Move lint tests into ui/lint
- Move repr tests into ui/repr
- Move intrinsics tests into ui/intrinsics
- Move tool lint tests into ui/tool-attributes
- Move return tests into ui/return
- Move pattern tests into ui/patttern
- Move range tests into ui/range
- Move foreign-fn tests into ui/foreign
- Move orphan-check tests into ui/coherence
- Move inference tests into ui/inference
- Reduce ROOT_ENTRY_LIMIT
|
|
refactor: add rustc-perf submodule to src/tools
Currently, it's very challenging to perform a sandboxed `opt-dist`
bootstrap because the tool requires `rustc-perf` to be present, but
there is no proper management/tracking of it. Instead, a specific commit
is hardcoded where it is needed, and a non-checksummed zip is fetched
ad-hoc. This happens in two places:
`src/ci/docker/host-x86_64/dist-x86_64-linux/Dockerfile`:
```dockerfile
ENV PERF_COMMIT 4f313add609f43e928e98132358e8426ed3969ae
RUN curl -LS -o perf.zip https://ci-mirrors.rust-lang.org/rustc/rustc-perf-$PERF_COMMIT.zip && \
unzip perf.zip && \
mv rustc-perf-$PERF_COMMIT rustc-perf && \
rm perf.zip
```
`src/tools/opt-dist/src/main.rs`
```rust
// FIXME: add some mechanism for synchronization of this commit SHA with
// Linux (which builds rustc-perf in a Dockerfile)
// rustc-perf version from 2023-10-22
const PERF_COMMIT: &str = "4f313add609f43e928e98132358e8426ed3969ae";
let url = format!("https://ci-mirrors.rust-lang.org/rustc/rustc-perf-{PERF_COMMIT}.zip");
let client = reqwest::blocking::Client::builder()
.timeout(Duration::from_secs(60 * 2))
.connect_timeout(Duration::from_secs(60 * 2))
.build()?;
let response = retry_action(
|| Ok(client.get(&url).send()?.error_for_status()?.bytes()?.to_vec()),
"Download rustc-perf archive",
5,
)?;
```
This causes a few issues:
1. Maintainers need to be careful to bump PERF_COMMIT in both places
every time
2. In order to run `opt-dist` in a sandbox, you need to provide your own
`rustc-perf` (https://github.com/rust-lang/rust/pull/125125), but to
figure out which commit to provide you need to grep the Dockerfile
3. Even if you manage to provide the correct `rustc-perf`, its
dependencies are not included in the `vendor/` dir created during
`dist`, so it will fail to build from the published source tarballs
4. It is hard to provide any level of automation around updating the
`rustc-perf` in use, leading to staleness
Fundamentally, this means `rustc-src` tarballs no longer contain
everything you need to bootstrap Rust, and packagers hoping to leverage
`opt-dist` need to go out of their way to keep track of this "hidden"
dependency on `rustc-perf`.
This change adds rustc-perf as a git submodule, pinned to the current
`PERF_COMMIT` 4f313add609f43e928e98132358e8426ed3969ae. Subsequent
commits ensure the submodule is initialized when necessary, and make use
of it in `opt-dist`.
|
|
This replaces the hardcoded rustc-perf commit and ad-hoc downloading and
unpacking of its zipped source with defaulting to use the new rustc-perf
submodule.
While it would be nice to make `opt-dist` able to initialize the
submodule automatically when pointing to a Rust checkout _other_ than
the one opt-dist was built in, that would require a bigger refactor that
moved `update_submodule`, from bootstrap, into build_helper.
Regardless, I imagine it must be quite rare to use `opt-dist` with a
checkout that is neither from a rust-src tarball (which will contain the
submodule), nor the checkout opt-dist itself was built (bootstrap will
update the submodule when opt-dist is built).
|
|
Currently, it's very challenging to perform a sandboxed `opt-dist`
bootstrap because the tool requires `rustc-perf` to be present, but
there is no proper management/tracking of it. Instead, a specific commit
is hardcoded where it is needed, and a non-checksummed zip is fetched
ad-hoc. This happens in two places:
`src/ci/docker/host-x86_64/dist-x86_64-linux/Dockerfile`:
```dockerfile
ENV PERF_COMMIT 4f313add609f43e928e98132358e8426ed3969ae
RUN curl -LS -o perf.zip https://ci-mirrors.rust-lang.org/rustc/rustc-perf-$PERF_COMMIT.zip && \
unzip perf.zip && \
mv rustc-perf-$PERF_COMMIT rustc-perf && \
rm perf.zip
```
`src/tools/opt-dist/src/main.rs`
```rust
// FIXME: add some mechanism for synchronization of this commit SHA with
// Linux (which builds rustc-perf in a Dockerfile)
// rustc-perf version from 2023-10-22
const PERF_COMMIT: &str = "4f313add609f43e928e98132358e8426ed3969ae";
let url = format!("https://ci-mirrors.rust-lang.org/rustc/rustc-perf-{PERF_COMMIT}.zip");
let client = reqwest::blocking::Client::builder()
.timeout(Duration::from_secs(60 * 2))
.connect_timeout(Duration::from_secs(60 * 2))
.build()?;
let response = retry_action(
|| Ok(client.get(&url).send()?.error_for_status()?.bytes()?.to_vec()),
"Download rustc-perf archive",
5,
)?;
```
This causes a few issues:
1. Maintainers need to be careful to bump PERF_COMMIT in both places
every time
2. In order to run `opt-dist` in a sandbox, you need to provide your own
`rustc-perf` (https://github.com/rust-lang/rust/pull/125125), but to
figure out which commit to provide you need to grep the Dockerfile
3. Even if you manage to provide the correct `rustc-perf`, its
dependencies are not included in the `vendor/` dir created during
`dist`, so it will fail to build from the published source tarballs
4. It is hard to provide any level of automation around updating the
`rustc-perf` in use, leading to staleness
Fundamentally, this means `rustc-src` tarballs no longer contain
everything you need to bootstrap Rust, and packagers hoping to leverage
`opt-dist` need to go out of their way to keep track of this "hidden"
dependency on `rustc-perf`.
This change adds rustc-perf as a git submodule, pinned to the current
`PERF_COMMIT` 4f313add609f43e928e98132358e8426ed3969ae. Subsequent
commits ensure the submodule is initialized when necessary, and make use
of it in `opt-dist`.
|
|
|
|
GuillaumeGomez:migrate-rustdoc-scrape-examples-test, r=jieyouxu
Migrate `run-make/rustdoc-scrape-examples-test` to new `rmake.rs`
Part of https://github.com/rust-lang/rust/issues/121876.
r? ``@jieyouxu``
|
|
|
|
|
|
Add tests for `-Zunpretty=expanded` ported from stringify's tests
This PR adds a new set of tests for the AST pretty-printer.
Previously, pretty-printer edge cases were tested by way of `stringify!` in [tests/ui/macros/stringify.rs](https://github.com/rust-lang/rust/blob/1.78.0/tests/ui/macros/stringify.rs), such as the tests added by https://github.com/rust-lang/rust/commit/419b26931b73209bfafdb9938c09e12b9d650613 and https://github.com/rust-lang/rust/commit/527e2eac17c5d3709e4e30e8b72ae33a6e8990b1.
Those tests will no longer provide effective coverage of the AST pretty-printer after #124141. `Nonterminal` and `TokenKind::Interpolated` are being removed, and a consequence is that `stringify!` will perform token stream pretty printing, instead of AST pretty printing, in all of the `stringify!` cases including $:expr and all other interpolations.
This PR adds 2 new ui tests with `compile-flags: -Zunpretty=expanded`:
- **tests/ui/unpretty/expanded-exhaustive.rs** — this test aims for exhaustive coverage of all the variants of `ExprKind`, `ItemKind`, `PatKind`, `StmtKind`, `TyKind`, and `VisibilityKind`. Some parts could use being fleshed out further, but the current state is roughly on par with what exists in the old stringify-based tests.
- **tests/ui/unpretty/expanded-interpolation.rs** — this test covers tricky macro metavariable edge cases that require the AST pretty printer to synthesize parentheses in order for the printed code to be valid Rust syntax.
r? `@nnethercote`
|
|
|
|
|
|
Migrate `run-make/issue-28766` to `rmake`
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
|
|
Migrate `run-make/issue64319` to `rmake` and rename
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
~~I noticed that the Makefile was not listed in `allowed-run-makefiles` in Tidy. Does this mean the test was being ignored?~~ EDIT: No, it was there, just not in its expected alphabetical order.
EDIT2: Perhaps it could be interesting to clean this test visually by looping over the `rustc` calls, like in #125227.
|
|
Migrate `run-make/static-unwinding` to `rmake`
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
An easy one after the last one, though the explanatory comment could use some clarification.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Migrate `run-make/panic-impl-transitive` to `rmake`
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
The test itself is quite simple, but the "handle panics by entering infinite loop" part is strange.
|
|
Migrate `run-make/rustdoc-themes` to new rmake.rs
Part of https://github.com/rust-lang/rust/issues/121876.
r? `@jieyouxu`
|
|
|
|
Migrate `run-make/no-cdylib-as-rdylib` to `rmake`
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
> "the test will fail if the cdylib is picked, because it doesn't export any rust symbols"
Is that true? Is there a way to verify?
I suggest maybe extending the test with: (after cleaning the directory)
```rust
rustc()
.input("bar.rs")
.crate_type("cdylib")
.run();
rustc()
.input("foo.rs")
.prefer_dynamic()
.run();
fail();
```
to make sure we're actually testing something here.
|
|
Migrate `run-make/c-link-to-rust-staticlib` to `rmake`
Part of #121876.
r? `@jieyouxu`
|
|
|
|
|
|
|
|
|
|
Migrate `run-make/issue-14500` to new `rmake.rs` format
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Note: I find suspicious that `libbar.a` is hardcoded and is not using the `STATICLIB` call to adapt to Windows platforms. Is this intentional? If not, this will need to be changed.
|
|
Migrate `run-make/c-link-to-rust-va-list-fn` to `rmake`
Part of #121876.
r? `@jieyouxu`
|
|
GuillaumeGomez:migrate-rustdoc-target-spec-json-path, r=jieyouxu
Migrate rustdoc target spec json path
Part of https://github.com/rust-lang/rust/issues/121876.
r? `@jieyouxu`
|
|
|
|
Rewrite 3 very similar `run-make` alloc tests to rmake
Part of #121876
#121918 attempted to port these 3 tests 2 months ago. However, since then, the structure of `run-make-support` has changed a bit and new helper functions were added. Since there has been no activity on the PR, they are good low-hanging fruit to knock down, using the new functions of the current library.
There is also the removal of a useless import on a very similar test.
|
|
|
|
GuillaumeGomez:migrate-rustdoc-scrape-examples-ordering, r=jieyouxu
Migrate rustdoc scrape examples ordering
Part of https://github.com/rust-lang/rust/issues/121876.
This one adds a lot of utility methods/functions. To prevent having too much changes at once, I didn't make the existing rmake tests use these yet but I'll send a follow-up so they all use it.
r? `@jieyouxu`
|
|
|
|
r=jieyouxu
Migrate `run-make/rustdoc-shared-flags` to rmake
Part of https://github.com/rust-lang/rust/issues/121876.
r? ```@jieyouxu```
|
|
|
|
|
|
|
|
|
|
|
|
Tidy check for test revisions that are mentioned but not declared
If a `[revision]` name appears in a test header directive or error annotation, but isn't declared in the `//@ revisions:` header, that is almost always a mistake.
In cases where a revision needs to be temporarily disabled, adding it to an `//@ unused-revision-names:` header will suppress these checks for that name.
Adding the wildcard name `*` to the unused list will suppress these checks for the entire file.
(None of the tests actually use `*`; it's just there because it was easy to add and could be handy as an escape hatch when dealing with other problems.)
---
Most of the existing problems discovered by this check were fairly straightforward to fix (or ignore); the trickiest cases are in `borrowck` tests.
|
|
If a `[revision]` name appears in a test header directive or error annotation,
but isn't declared in the `//@ revisions:` header, that is almost always a
mistake.
In cases where a revision needs to be temporarily disabled, adding it to an
`//@ unused-revision-names:` header will suppress these checks for that name.
Adding the wildcard name `*` to the unused list will suppress these checks for
the entire file.
|
|
|
|
|
