Esteban Küber 8a568d9f15 Remove less relevant info from diagnostic
```
error[E0277]: the trait bound `dep_2_reexport::Type: Trait` is not satisfied because the trait comes from a different crate version
 --> multiple-dep-versions.rs:7:18
  |
7 |     do_something(Type);
  |                  ^^^^ the trait `Trait` is not implemented for `dep_2_reexport::Type`
  |
note: there are multiple different versions of crate `dependency` in the dependency graph
 --> /home/gh-estebank/rust/build/x86_64-unknown-linux-gnu/test/run-make/crate-loading/rmake_out/multiple-dep-versions-1.rs:4:1
  |
3 | pub struct Type(pub i32);
  | --------------- this type implements the required trait
4 | pub trait Trait {
  | ^^^^^^^^^^^^^^^ this is the required trait
  |
 ::: multiple-dep-versions.rs:1:1
  |
1 | extern crate dep_2_reexport;
  | ---------------------------- one version of crate `dependency` is used here, as a dependency of crate `foo`
2 | extern crate dependency;
  | ------------------------ one version of crate `dependency` is used here, as a direct dependency of the current crate
  |
 ::: /home/gh-estebank/rust/build/x86_64-unknown-linux-gnu/test/run-make/crate-loading/rmake_out/multiple-dep-versions-2.rs:3:1
  |
3 | pub struct Type;
  | --------------- this type doesn't implement the required trait
4 | pub trait Trait {
  | --------------- this is the found trait
  = note: two types coming from two different versions of the same crate are different types even if they look the same
  = help: you can use `cargo tree` to explore your dependency tree
```

The approach to accomplish this is a HACK, and we'd want a better way to do this. I believe that moving E0277 to be a structured diagnostic would help in that regard.
2024-11-07 20:18:00 +00:00
..
2024-07-17 13:34:18 +00:00
2024-08-15 15:44:29 +02:00
2024-07-17 13:34:18 +00:00
2024-08-15 15:44:29 +02:00
2024-07-17 13:34:18 +00:00
2024-07-29 14:33:54 -04:00
2024-09-05 08:43:38 +00:00
2024-09-05 08:43:38 +00:00
2024-07-29 08:26:52 +10:00
2024-06-25 14:27:43 -04:00
2024-07-18 09:28:30 -04:00
2024-07-17 13:34:18 +00:00
2024-07-17 13:34:18 +00:00
2024-07-17 13:34:18 +00:00
2024-07-29 08:26:52 +10:00
2024-07-29 08:26:52 +10:00
2024-07-29 08:26:52 +10:00
2024-07-17 13:34:18 +00:00
2024-08-15 15:44:29 +02:00
2024-08-15 15:44:29 +02:00
2024-09-09 19:39:43 -07:00
2024-09-05 08:43:38 +00:00
2024-09-05 08:43:38 +00:00
2024-08-03 13:02:32 +00:00
2024-07-29 08:26:52 +10:00

The run-make test suite

The run-make test suite contains tests which are the most flexible out of all the rust-lang/rust test suites. run-make tests can basically contain arbitrary code, and are supported by the run_make_support library.

Infrastructure

There are two kinds of run-make tests:

  1. The new rmake.rs version: this allows run-make tests to be written in Rust (with rmake.rs as the main test file).
  2. The legacy Makefile version: this is what run-make tests were written with before support for rmake.rs was introduced.

The implementation for collecting and building the rmake.rs recipes (or Makefiles) are in src/tools/compiletest/src/runtest.rs, in run_rmake_v2_test and run_rmake_legacy_test.

Rust-based run-make tests: rmake.rs

The setup for the rmake.rs version is a 3-stage process:

  1. First, we build the run_make_support library in bootstrap as a tool lib.

  2. Then, we compile the rmake.rs "recipe" linking the support library and its dependencies in, and provide a bunch of env vars. We setup a directory structure within build/<target>/test/run-make/

    <test-name>/
        rmake.exe              # recipe binary
        rmake_out/             # sources from test sources copied over
    

    and copy non-rmake.rs input support files over to rmake_out/. The support library is made available as an extern prelude.

  3. Finally, we run the recipe binary and set rmake_out/ as the working directory.

Formatting

Note that files under tests/ are not formatted by ./x fmt, use rustfmt tests/path/to/file.rs to format a specific file if desired.