Start small. If it works well we can increase usage bit by bit as time
passes.
Note that we keep using "0" to represent "no specific line" because
changing to `Option<LineNumber>` everywhere is much bigger and noisier
change. That can be done later if wanted.
So that when we later add support for revisions we can use the same
syntax for revisions as elsewhere.
This also prevents people from making typos for commands since
`src/tools/compiletest/src/directives/directive_names.rs` will catch such
typos now.
Note that we one FIXME for a non-trivial change for later:
```
// FIXME(148097): Change `// cdb-checksimple_closure` to `//@ cdb-check:simple_closure`
```
To make debugger stepping intuitive with `-Copt-level=0`. See the
adjusted `basic-stepping.rs` test.
This is kind of a revert of bd0aae92dc, except we don't revert it,
we just make it conditional on `opt-level`. That commit regressed
`basic-stepping.rs`, but it was not noticed since that test did not
exist back then. I have retroactively bisected to find that out.
It seems messy to sprinkle if-cases inside of the
`write_operand_repeatedly()` so make the whole function conditional.
The test that bd0aae92dc added in
`tests/codegen/issues/issue-111603.rs` already use `-Copt-level=3`, so
we don't need to adjust the compiler flags for it to keep passing.
Fixes the bug:
1. git clone https://github.com/rust-lang/rust.git rust-improve-tests
2. cd rust-improve-tests
3. ./x test tidy
Expected:
No tidy errors found
Actual:
```
thread 'pal (library)' (837175) panicked at src/tools/tidy/src/pal.rs:100:5:
assertion failed: saw_target_arch
```
Since the git checkout dir contains the word "tests", the `pal.rs`
`check()` used to erroneously ignore all paths.
In 9253e1206e a bunch of `gdbr-check` (for `rust-gdb`) and
`gdbg-check` (for plain `gdb`) was added. But in two places the author
accidentally wrote `gdbt-check` instead. This commit fixes this typo.
If a user does e.g.
impl From<Bar> for foo::Foo
and get a compilation error about that `From<Bar>` is not implemented
for `Foo`, check if multiple versions of the crate with `Foo` is present
in the dependency graph. If so, give a hint about it.
I encountered this case in the wild and didn't realize I had multiple
versions of a crate in my dependency graph. So I was a bit confused at
first. This fix will make life easier for others.
The linux backtrace unwinder relies on unwind tables to work properly,
and generating and printing a backtrace is done by for example the
default panic hook.
Begin emitting unwind tables by default again with `-C panic=abort` (see
history below) so that backtraces work.
History
=======
Backtraces with `-C panic=abort` used to work in Rust 1.22 but broke in
Rust 1.23, because in 1.23 we stopped emitting unwind tables with `-C
panic=abort` (see 24cc38e3b0).
In 1.45 (see cda994633e) a workaround in the form
of `-C force-unwind-tables=yes` was added.
`-C panic=abort` was added in [Rust
1.10](https://blog.rust-lang.org/2016/07/07/Rust-1.10/#what-s-in-1-10-stable)
and the motivation was binary size and compile time. But given how
confusing that behavior has turned out to be, it is better to make
binary size optimization opt-in with `-C force-unwind-tables=no` rather
than default since the current default breaks backtraces.
Besides, if binary size is a primary concern, there are many other
tricks that can be used that has a higher impact.
It accidentally broke with a48c8e337d. The intention of that commit was
to keep existing behavior if `--exact` is not used, but it had a bug.
This commit fixes that bug.
This fix only changes the behavior when using `--exact` test filtering,
which was quite broken. Before this fix, the following runs 0 tests:
$ ./x test tests/run-make/crate-loading -- --exact
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 431 filtered out; finished in 24.95µs
With the fix the desired test is run:
$ ./x test tests/run-make/crate-loading -- --exact
running 1 tests
test [run-make] tests/run-make/crate-loading ... ok
Without `--exact` the set of run tests is unchanged. This still runs
"too many" tests
$ ./x test tests/run-make/crate-loading
running 3 tests
test [run-make] tests/run-make/crate-loading-crate-depends-on-itself ... ok
test [run-make] tests/run-make/crate-loading-multiple-candidates ... ok
test [run-make] tests/run-make/crate-loading ... ok
This still runs the one and only right test:
$ ./x test tests/ui/lint/unused/unused-allocation.rs
running 1 tests
test [ui] tests/ui/lint/unused/unused-allocation.rs ... ok
We have a few ui tests to ensure we emit an error if we encounter too
big arrays. Before this fix, compiling the tests with `-Cdebuginfo=2`
would not include the spans of the instantiation sites, because the
error is then emitted from a different code path that does not include
the span.
Propagate the span to the error also in the debuginfo case, so the tests
passes regardless of debuginfo level.
We have a ui test to ensure we emit an error if we encounter too big
enums. Before this fix, compiling the test with `-Cdebuginfo=2` would
not include the span of the instantiation site, because the error is
then emitted from a different code path that does not include the span.
Propagate the span to the error also in the debuginfo case, so the test
passes regardless of debuginfo level.
To reduce risk of regressing on generating debuginfo e.g. in the form of
ICE:s. This will also ensure that future ui tests support different
debuginfo levels.
When I looked at run time for different CI jobs, **x86_64-gnu-debug**
was far from the bottle neck, so it should be fine to make it perform
more work.
And introduce two new directives for ui tests:
* `run-crash`
* `run-fail-or-crash`
Normally a `run-fail` ui test like tests that panic shall not be
terminated by a signal like `SIGABRT`. So begin having that as a hard
requirement.
Some of our current tests do terminate by a signal/crash however.
Introduce and use `run-crash` for those tests. Note that Windows crashes
are not handled by signals but by certain high bits set on the process
exit code. Example exit code for crash on Windows: `0xc000001d`.
Because of this, we define "crash" on all platforms as "not exit with
success and not exit with a regular failure code in the range 1..=127".
Some tests behave differently on different targets:
* Targets without unwind support will abort (crash) instead of exit with
failure code 101 after panicking. As a special case, allow crashes for
`run-fail` tests for such targets.
* Different sanitizer implementations handle detected memory problems
differently. Some abort (crash) the process while others exit with
failure code 1. Introduce and use `run-fail-or-crash` for such tests.
codegen tests typically depend on the raw LLVM IR output and are
sensitive to debuginfo level. So do not apply
`rust.debuginfo-level-tests` for codegen tests.
Before this commit:
$ ./x test --set rust.debuginfo-level-tests=2 tests/codegen --force-rerun
test result: FAILED. 654 passed; 136 failed; 75 ignored; 0 measured; 0 filtered out; finished in 3.22s
After this commit:
$ ./x test --set rust.debuginfo-level-tests=2 tests/codegen --force-rerun
NOTE: ignoring `rust.debuginfo-level-tests=2` for codegen tests
test result: ok. 790 passed; 0 failed; 75 ignored; 0 measured; 0 filtered out; finished in 3.21s
The `Display` implementation for `Backtrace` used to print
stack backtrace:
but that print was later removed. To make the existing test pass, the
print was added to the existing test. But it doesn't make sense to check
for something that the test itself does since that will not detect any
regressions in the implementation of `Backtrace`. Fully remove the
checks.
There is one comment at a call site and one comment in the function
definition that are mostly saying the same thing. Fold the call site
comment into the function definition comment to reduce duplication.
There are actually some inaccuracies in the comments but let's
deduplicate before we address the inaccuracies.
If the remote process is terminated by a signal, make `remote-test-client` exit
with the code `128 + <signal-number>` instead of always `3`. This follows common
practice among tools such as bash [^1]:
> When a command terminates on a fatal signal whose number is N, Bash uses the
> value 128+N as the exit status.
It also allows us to differentiate between `run-pass` and `run-crash` ui tests
without special case code in compiletest for that when `remote-test-client` is
used.
[^1]: https://www.gnu.org/software/bash/manual/html_node/Exit-Status.html
Because in the case of for example
pub fn my_fn3(f: impl FnMut()) {}
we want to keep `()` even if it is empty since that matches e.g. Rust
syntax requirements.
Confusingly, this does not make compile test print what command is used
to run a ui test:
./x test tests/ui/panics/abort-on-panic.rs --verbose
It is also necessary to pass `--no-capture`, like this:
./x test tests/ui/panics/abort-on-panic.rs --verbose --no-capture
Now you will see prints like this:
executing cd "/rust/build/x86_64-unknown-linux-gnu/test/ui/panics/abort-on-panic.next" && \
RUSTC="/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" \
RUST_TEST_THREADS="32" \
"/rust/build/x86_64-unknown-linux-gnu/test/ui/panics/abort-on-panic.next/a"
Add a hint in the code for this that would have helped me figure this out.
Because `.as_ptr()` changes the type of the pointer (e.g. `&[u8]`
becomes `*const u8` instead of `*const [u8]`), and it can't be expected
that different types will be formatted the same way.
In the playground the example program terminates with an unpredictable exit
code. The undefined behavior is also detected by miri:
error: Undefined Behavior: using uninitialized data
Since the previos commit renamed `assignment_rhs_span` to just
`rhs_span` there is no need for a variable just to shorten the
expression on the next line. Inline the variable.
A legitimate suggestion would be to change from
&raw const val
to
&raw mut val
But until we have figured out how to make that happen we should at least
stop suggesting invalid syntax.
Mainly so that it is easier to only run all `non-snake-case`-specific
tests but no other tests with:
./x test tests/ui/lint/non-snake-case
But also to reduce the size of the large `tests/ui/lint` directory. And
rename some tests to pass tidy, and remove them from
`src/tools/tidy/src/issues.txt`.
This deprecates `-Cinline-threshold` since using it has no effect. This
has been the case since the new LLVM pass manager started being used,
more than 2 years ago.
I didn't find `crt-static` at first (for `x86_64-unknown-linux-gnu`),
because it was put at the bottom the large and otherwise sorted list.
Fully sort the list before we print it.
Note that `llvm_target_features` starts out sorted and does not need to
be sorted an extra time.
In the stabilization attempt of `#[unix_sigpipe = "sig_dfl"]`, a concern
was raised related to using a language attribute for the feature: Long
term, we want `fn lang_start()` to be definable by any crate, not just
libstd. Having a special language attribute in that case becomes
awkward.
So as a first step towards towards the next stabilization attempt, this
PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag
`-Zon-broken-pipe=...` to remove that concern, since now the language
is not "contaminated" by this feature.
Another point was also raised, namely that the ui should not leak
**how** it does things, but rather what the **end effect** is. The new
flag uses the proposed naming. This is of course something that can be
iterated on further before stabilization.
library/backtrace also declares a feature called `gimli-symbolize` which
appear used, but the feature in std with the same name is unused, so
remove it.
All other arg properties use the `prop = value` style, which makes it
slightly annoying to use the `prop(value)` style for `global`. Change to
`prop = value` also for `global` for consistency.
Add a test that fails if `#[unix_sigpipe = "inherit"]` wrongly results
in `SIGPIPE` being `SIG_DFL` if the parent has `SIG_IGN`. We have no
current test for this particular case.
The `sig_dfl` variant of the attribute is the most likely variant to be
stabilized first, and thus to become the "most allowed" variant of the
attribute. Because of this, it is the most appropriate variant to use in
syntax tests, because even if the most allowed variant is used, the
compiler shall still emit errors if it e.g. is used in the wrong places.
Remove `Word` from the `unix_sigpipe` attribute template so that plain
`#[unix_sigpipe]` is not included in suggestions of valid forms of the
attribute. Also re-arrange diagnostics code slightly to avoid duplicate
diagnostics.
In `auxiliary/sigpipe-utils.rs`, all we want to know is the current
`SIGPIPE` disposition. We should not change it. So use `libc::sigaction`
instead of `libc::signal`. That way we can also remove the code that
restores it.
Fixes:
$ MAGIC_EXTRA_RUSTFLAGS=-Zmove-size-limit=4096 ./x test compiler/rustc_target
error: moving 6216 bytes
--> compiler/rustc_target/src/spec/base/apple/tests.rs:17:19
|
17 | for target in all_sim_targets {
| ^^^^^^^^^^^^^^^ value moved from here
|
= note: The current maximum size is 4096, but it can be customized with the move_size_limit attribute: `#![move_size_limit = "..."]`
= note: `-D large-assignments` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(large_assignments)]`
The test is for the "bare" variant of the attribute that looks like this:
#[unix_sigpipe]
which is not allowed, because it must look like this:
#[unix_sigpipe = "sig_ign"]
Stop allowing `rustc::potential_query_instability` on all of
rustc_mir_transform and instead allow it on a case-by-case basis if it
is safe to do so. In this particular crate, all instances were safe to
allow.
Martin Nordholts
Martin Nordholts