Consider comments and bare delimiters the same as an "empty line" for purposes of hiding rendered code output of long multispans. This results in more aggressive shortening of rendered output without losing too much context, specially in `*.stderr` tests that have "hidden" comments.
Get rid of HIR const checker
As far as I can tell, the HIR const checker was implemented in https://github.com/rust-lang/rust/pull/66170 because we were not able to issue useful const error messages in the MIR const checker.
This seems to have changed in the last 5 years, probably due to work like #90532. I've tweaked the diagnostics slightly and think the error messages have gotten *better* in fact.
Thus I think the HIR const checker has reached the end of its usefulness, and we can retire it.
cc `@RalfJung`
Cleanup: delete `//@ pretty-expanded` directive
This PR removes the `//@ pretty-expanded` directive support in compiletest and removes its usage inside ui tests because it does not actually do anything, and its existence is itself misleading. This PR is split into two commits:
1. The first commit just drops `pretty-expanded` directive support in compiletest.
2. The second commit is created by `sd '//@ pretty-expanded.*\n' '' tests/ui/**/*.rs`[^1], reblessing, and slightly adjusting some leading whitespace in a few tests.
We can tell this is fully removed because compiletest doesn't complain about unknown directive when running the `ui` test suite.
cc #23616
### History
Originally, there was some effort to introduce more test coverage for `-Z unpretty=expanded` (in 2015 this was called `--pretty=expanded`). In [Make it an error to not declare used features #23598][pr-23598], there was a flip from `//@ no-pretty-expanded` (opt-out of `-Z
unpretty=expanded` test) to `//@ pretty-expanded` (opt-in to `-Z unpretty=expanded` test). This was needed because back then the dedicated `tests/pretty` ("pretty") test suite did not existed, and the pretty tests were grouped together under `run-pass` tests (I believe the `ui` test suite didn't exist back then either). Unfortunately, in this process the replacement `//@ pretty-expanded` directives contained a `FIXME #23616` linking to [There are very few tests for `-Z unpretty` expansion #23616][issue-23616]. But this was arguably backwards and somewhat misleading, as noted in [#23616](https://github.com/rust-lang/rust/issues/23616#issuecomment-484999901):
The attribute is off by default and things just work if you don't
test it, people have not been adding the `pretty-expanded`
annotation to new tests even if it would work.
Which basically renders this useless.
### Current status
As of Nov 2024, we have a dedicated `pretty` test suite, and some time over the years the split between `run-pass` into `ui` and `pretty` test suites caused all the `//@ pretty-expanded` in `ui` tests to do absolutely nothing: the compiletest logic for `pretty-expanded` only triggers in the *pretty* test suite, but none of the pretty tests use it. Oops.
Nobody remembers this, nobody uses this, it's misleading in ui tests. Let's get rid of this directive altogether.
[pr-23598]: https://github.com/rust-lang/rust/pull/23598
[issue-23616]: https://github.com/rust-lang/rust/issues/23616
### Follow-ups
- [x] Yeet this directive from rustc-dev-guide docs. https://github.com/rust-lang/rustc-dev-guide/pull/2147
[^1]: https://github.com/chmln/sd
r? compiler
The two altered expectation messages both seem like improvements:
- `coerce-expect-unsized-ascribed.stderr` says you can go
`Box<char> -> Box<dyn Debug>`, which you can.
- `upcast_soundness_bug.stderr` used to say that you could go
`Box<dyn Trait<u8, u8>> -> Box<dyn Trait>`, which you can't,
because the type parameters are missing in the destination
and the only ones that work aren't what's needed.
Remove suggestion about iteration count in coerce
Fixes#122561
The iteration count-centric suggestion was implemented in PR #100094, but it was based on the wrong assumption that the type mismatch error depends on the number of times the loop iterates. As it turns out, that is not true (see this comment for details: https://github.com/rust-lang/rust/pull/122679#issuecomment-2017432531)
This PR attempts to remedy the situation by changing the suggestion from the one centered on iteration count to a simple suggestion to add a return value.
It should also fix#100285 by simply making it redundant.
and replace it with a simple note suggesting
returning a value.
The type mismatch error was never due to
how many times the loop iterates. It is more
because of the peculiar structure of what the for
loop desugars to. So the note talking about
iteration count didn't make sense
- Firstly get all the information about generics matching out of the HIR
- Secondly the labelling for the function is more coherent now
- Lastly a few error message improvements
