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/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.
Use new utility functions/methods in run-make tests
Little cleanup using new functions/methods I added into the `run-make-support` library.
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.
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.
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`
Display walltime benchmarks with subnanosecond precision
With modern CPUs running at more than one cycle per nanosecond the current precision is insufficient to resolve differences worth several cycles per iteration.
Granted, walltime benchmarks often are noisy but occasionally, especially when no allocations are involved, the difference really is just a few cycles.
example results when benchmarking 1-4 serialized ADD instructions and an empty bench body
```
running 4 tests
test add ... bench: 0.24 ns/iter (+/- 0.00)
test add2 ... bench: 0.48 ns/iter (+/- 0.01)
test add3 ... bench: 0.72 ns/iter (+/- 0.01)
test add4 ... bench: 0.96 ns/iter (+/- 0.01)
test empty ... bench: 0.24 ns/iter (+/- 0.00)
```
Document tests in the `run-make` directory (A to C)
Part of the #121876 project.
This PR adds comments to some `run-make` tests which lack one, explaining _what_ is being tested. If possible, a link to the relevant PR or Issue responsible for the test is also provided.
This will help the porting efforts to `rmake.rs`, and will also allow maintainers to focus efforts on tests which are more pertinent to port. For example, [this test](https://github.com/rust-lang/rust/blob/master/tests/run-make/cat-and-grep-sanity-check/Makefile) will become useless after all tests containing `CGREP` are successfully ported.
In order to simplify review and at the suggestion of Kobzol on the rust-lang #gsoc Zulip, only the first 23 comments are part of this PR. If it is merged, future PRs will ensue commenting the rest of the tests.
Could be an UI test:
- `dep-info-doesnt-run-much`
Allow fmt to run on rmake.rs test files
As discussed with `@jieyouxu,` `rmake.rs` from the `run-make` testsuite would benefit from being formatted as well.
Only thing needed to be done for it to work: allow support for `!` in our `rustfmt.toml` file parsing.
r? `@onur-ozkan`
Add support for inputing via stdin with run-make-support
This PR adds the facility to set a input bytes that will be passed via the standard input.
This is useful for testing `rustc -` (and soon `rustdoc -`).
In #124611 took the approach of having a dedicated `run` method but it is not very convenient to use and would necessitate many functions, one for success, one for fail, ...
Instead this PR takes a different approach and allows setting the input bytes as if it were a parameter and when calling the (now custom) `output` function, we write the input bytes into stdin. I think this gives us maximum flexibility in the implementation and a simple interface for users.
To test this new logic I ported `tests/run-make/stdin-non-utf8/` to an `rmake.rs` one.
r? `@jieyouxu`
Cleanup: Rid the `rmake` test runners of `extern crate run_make_support;`
`run_make_support` is part of the *extern prelude* of `rmake` test runners rendering `extern crate run_make_support` redundant:
80451a485b/src/tools/compiletest/src/runtest.rs (L3826-L3827)
~~Contains some fmt'ing changes because I've enabled format-on-save in my editor and because we don't run `x fmt` for `rmake` test runners yet (this gets addressed by #124613). I can revert those if you'd like me to.~~ (reverted)
r? jieyouxu or testing-devex(?) or boostrap(?)
Port repr128-dwarf run-make test to rmake
This PR ports the repr128-dwarf run-make test to rmake, using the `gimli` crate instead of the `llvm-dwarfdump` command.
Note that this PR changes `rmake.rs` files to be compiled with the 2021 edition (previously no edition was passed to `rustc`, meaning they were compiled with the 2015 edition). This means that `panic!("{variable}")` will now work as expected in `rmake.rs` files (there's already a usage in the [wasm-symbols-not-exported test](aca749eefc/tests/run-make/wasm-symbols-not-exported/rmake.rs (L34)) that this will fix).
Tracking issue: #121876
Rewrite the `no-input-file.stderr` test in Rust and support diff
Rewrite the `no-input-file.stderr` test from #121876.
Use the `similar` lib to replace the `diff` command.
Fix ICE when there is a non-Unicode entry in the incremental crate directory
Fix the ICE that occurs when there is a non-Unicode entry in the incremental crate directory by replacing uses of `to_string_lossy` + `assert_no_characters_lost` with `to_str`. The added test would cause the compiler to ICE before this PR.
Codegen ZSTs without an allocation
This makes sure that &[] is equivalent to unsafe code (from_raw_parts(dangling, 0)). No new stable guarantee is intended about whether or not we do this, this is just an optimization.
This regressed in #67000 (no comments I can see about that regression in the PR, though it did change the test modified here). We had previously performed this optimization since #63635.
Port the 2 `rust-lld` run-make tests to `rmake`
In preparation for finalizing most of the `rust-lld` work, this PR ports the following tests to `rmake`:
- `tests/run-make/rust-lld`
- `tests/run-make/rust-lld-custom-target`
As they use `$(CGREP) -e` I added `regex` as an exported dependency to the `run_make_support` library.
Unfortunately, the most recent versions depend on `memchr` 2.6.0 but it's currently pinned at 2.5.0 in the workspace, and therefore had to settle for the older `regex-1.8.0`.
r? `@jieyouxu`
Allow workproducts without object files.
This pull request partially reverts changes from e16c3b4a44
Original motivation for this assert was described with "A WorkProduct without a saved file is useless"
which was true at the time but now it is possible to have work products with other types of files
(llvm-ir, asm, etc) and there are bugreports for this failure:
For example: https://github.com/rust-lang/rust/issues/123695
Fixes https://github.com/rust-lang/rust/issues/123234
Now existing `assert` and `.unwrap_or_else` are unified into a single
check that emits slightly more user friendly error message if an object
files was meant to be produced but it's missing
This pull request partially reverts changes from e16c3b4a44
Original motivation for this assert was described with "A WorkProduct without a saved file is useless"
which was true at the time but now it is possible to have work products with other types of files
(llvm-ir, asm, etc) and there are bugreports for this failure:
For example: https://github.com/rust-lang/rust/issues/123695
Fixes https://github.com/rust-lang/rust/issues/123234
Now existing `assert` and `.unwrap_or_else` are unified into a single
check that emits slightly more user friendly error message if an object
files was meant to be produced but it's missing
Linker flavors next steps: linker features
This is my understanding of the first step towards `@petrochenkov's` vision for the future of linker flavors, described in https://github.com/rust-lang/rust/pull/119906#issuecomment-1895693162 and the discussion that followed.
To summarize: having `Cc` and `Lld` embedded in linker flavors creates tension about naming, and a combinatorial explosion of flavors for each new linker feature we'd want to use. Linker features are an extension mechanism that is complementary to principal flavors, with benefits described in #119906.
The most immediate use of this flag would be to turn self-contained linking on and off via features instead of flavors. For example, `-Clinker-features=+/-lld` would toggle using lld instead of selecting a precise flavor, and would be "generic" and work cross-platform (whereas linker flavors are currently more tied to targets). Under this scheme, MCP510 is expected to be `-Clink-self-contained=+linker -Zlinker-features=+lld -Zunstable-options` (though for the time being, the original flags using lld-cc flavors still work).
I purposefully didn't add or document CLI support for `+/-cc`, as it would be a noop right now. I only expect that we'd initially want to stabilize `+/-lld` to begin with.
r? `@petrochenkov`
You had requested that minimal churn would be done to the 230 target specs and this does none yet: the linker features are inferred from the flavor since they're currently isomorphic. We of course expect this to change sooner rather than later.
In the future, we can allow targets to define linker features independently from their flavor, and remove the cc and lld components from the flavors to use the features instead, this actually doesn't need to block stabilization, as we discussed.
(Best reviewed per commit)
Set the host library path in run-make v2
When the build is configured with `[rust] rpath = false`, we need to set
`LD_LIBRARY_PATH` (or equivalent) to what would have been the `RPATH`,
so the compiler can find its own libraries. The old `tools.mk` code has
this environment prefixed in the `$(BARE_RUSTC)` variable, so we just
need to wire up something similar for run-make v2.
This is now set while building each `rmake.rs` itself, as well as in the
`rust-make-support` helpers for `rustc` and `rustdoc` commands. This is
also available in a `set_host_rpath` function for manual commands, like
in the `compiler-builtins` test.
When the build is configured with `[rust] rpath = false`, we need to set
`LD_LIBRARY_PATH` (or equivalent) to what would have been the `RPATH`,
so the compiler can find its own libraries. The old `tools.mk` code has
this environment prefixed in the `$(BARE_RUSTC)` variable, so we just
need to wire up something similar for run-make v2.
This is now set while building each `rmake.rs` itself, as well as in the
`rust-make-support` helpers for `rustc` and `rustdoc` commands. This is
also available in a `set_host_rpath` function for manual commands, like
in the `compiler-builtins` test.
Save/restore more items in cache with incremental compilation
Right now they don't play very well together, consider a simple example:
```
$ export RUSTFLAGS="--emit asm"
$ cargo new --lib foo
Created library `foo` package
$ cargo build -q
$ touch src/lib.rs
$ cargo build
error: could not copy
"/path/to/foo/target/debug/deps/foo-e307cc7fa7b6d64f.4qbzn9k8mosu50a5.rcgu.s"
to "/path/to/foo/target/debug/deps/foo-e307cc7fa7b6d64f.s":
No such file or directory (os error 2)
```
Touch triggers the rebuild, incremental compilation detects no changes (yay) and everything explodes while trying to copy files were they should go.
This pull request fixes it by copying and restoring more files in the incremental compilation cache
Fixes https://github.com/rust-lang/rust/issues/89149
Fixes https://github.com/rust-lang/rust/issues/88829
Related: https://internals.rust-lang.org/t/interaction-between-incremental-compilation-and-emit/20551
Port `run-make/issue-7349` to a codegen test
The test does not need to be a run-make test, it can use the codegen test infrastructure.
Also took the opportunity to rename the test to `no-redundant-item-monomorphization` so it's not just some opaque issue number.
Part of #121876.
Rewrite `core-no-fp-fmt-parse` test in Rust
Claiming the simple "core-no-fp-fmt-parse" test from #121876. `run_make_support` was altered with `arg_path` written in #121918 by `@abhay-51,` with additional doc comment.
Preliminary GSoC contribution for the project proposal mentored by `@jieyouxu.`
Simplify trim-paths feature by merging all debuginfo options together
This PR simplifies the trim-paths feature by merging all debuginfo options together, as described in https://github.com/rust-lang/rust/issues/111540#issuecomment-1994010274.
And also do some correctness fixes found during the review.
cc `@weihanglo`
r? `@michaelwoerister`
Rework rmake support library API
### Take 1: Strongly-typed API
Context: https://github.com/rust-lang/rust/pull/122448#discussion_r1523774427
> My 2 cents: from my experience with writing similar "test DSLs", I would suggest to create these helpers as soon as possible in the process (basically the first time someone needs them, not only after N similar usages), and basically treat any imperative code in these high-level tests as a maintenance burden, basically making them as declarative as possible. Otherwise it might be a bit annoying to keep refactoring the tests later once such helpers are available.
>
> I would even discourage the arg method and create explicit methods for setting things like unpretty, the output file etc., but this might be more controversial, as it will make the invoked command-line arguments more opaque.
cc `@Kobzol` for the testing DSL suggestion.
Example:
```rs
let output = Rustc::new()
.input_file("main.rs")
.emit(&[EmitKind::Metadata])
.extern_("stable", &stable_path)
.output();
```
### Take 2: xshell-based macro API
Example:
```rs
let sh = Shell::new()?;
let stable_path = stable_path.to_string_lossy();
let output = cmd!(sh, "rustc main.rs --emit=metadata --extern stable={stable_path}").output()?;
```
### Take 3: Weakly-typed API with a few helper methods
```rs
let output = Rustc::new()
.input("main.rs")
.emit("metadata")
.extern_("stable", &stable_path)
.output();
```
Print a backtrace in const eval if interrupted
Demo:
```rust
#![feature(const_eval_limit)]
#![const_eval_limit = "0"]
const OW: u64 = {
let mut res: u64 = 0;
let mut i = 0;
while i < u64::MAX {
res = res.wrapping_add(i);
i += 1;
}
res
};
fn main() {
println!("{}", OW);
}
```
```
╭ ➜ ben@archlinux:~/rust
╰ ➤ rustc +stage1 spin.rs
^Cerror[E0080]: evaluation of constant value failed
--> spin.rs:8:33
|
8 | res = res.wrapping_add(i);
| ^ Compilation was interrupted
note: erroneous constant used
--> spin.rs:15:20
|
15 | println!("{}", OW);
| ^^
note: erroneous constant used
--> spin.rs:15:20
|
15 | println!("{}", OW);
| ^^
|
= note: this note originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
error: aborting due to previous error
For more information about this error, try `rustc --explain E0080`.
```
"Handle" calls to upstream monomorphizations in compiler_builtins
This is pretty cooked, but I think it works.
compiler-builtins has a long-standing problem that at link time, its rlib cannot contain any calls to `core`. And yet, in codegen we _love_ inserting calls to symbols in `core`, generally from various panic entrypoints.
I intend this PR to attack that problem as completely as possible. When we generate a function call, we now check if we are generating a function call from `compiler_builtins` and whether the callee is a function which was not lowered in the current crate, meaning we will have to link to it.
If those conditions are met, actually generating the call is asking for a linker error. So we don't. If the callee diverges, we lower to an abort with the same behavior as `core::intrinsics::abort`. If the callee does not diverge, we produce an error. This means that compiler-builtins can contain panics, but they'll SIGILL instead of panicking. I made non-diverging calls a compile error because I'm guessing that they'd mostly get into compiler-builtins by someone making a mistake while working on the crate, and compile errors are better than linker errors. We could turn such calls into aborts as well if that's preferred.
fix `long-linker-command-lines` failure caused by `rust.rpath=false`
Fixes `long-linker-command-lines` test failure (which happens when `rust.rpath` is set to `false`) by adjusting `LD_LIBRARY_PATH`.
Fixes https://github.com/rust-lang/rust/issues/90921
