Don't use bytepos offsets when computing semicolon span for removal
Causes problems when we recover confusable characters w/ a different byte width
Fixes#123607
Clean up tests/ui by removing `does-nothing.rs`
In [a previous PR](https://github.com/rust-lang/rust/pull/123297#issuecomment-2039887806), it was suggested that this test be removed:
> it's testing a basic diagnostic for an unknown variable (added over a decade ago for https://github.com/rust-lang/rust/issues/154) that is already covered by probably dozens or hundreds of other tests.
It was then suggested that [opening a new PR](https://github.com/rust-lang/rust/pull/123563#discussion_r1554654102) for this would be more organized.
I'm setting this as a draft, as:
1. The tests/ui directory is rather disorganized, a large quantity of tests are not even contained inside their own directories. This PR could turn into "clean up the UI tests directory", if I were to place everything into categories (for example, everything related to CLI flags could get placed in a cli directory).
2. This will have a merge conflict with #123563 should that get merged. I trust that _this time_, I won't run into [The Incident](https://github.com/rust-lang/rust/pull/123297#issuecomment-2041137569) while rebasing. Edit: Yay, I did it properly!
Unconditionally show update nightly hint on ICE
Instead of trying to guess if a update nightly hint should be shown (by checking for system time, querying version and channel info etc.), just show the update nightly hint for nightly compilers. This avoids breaking tests that match on ICE test outputs on nightly/dev channels.
> Another issue is that the outdated nightly hint triggers for ICE tests, causing a mismatch with the test expectation. There doesn't seem to be any env var to suppress this.
See <https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/stage0.20compiletest.20broken/near/425543681> for context.
Port exit-code run-make test to use rust
As part of https://github.com/rust-lang/rust/issues/121876
~~As draft because formatting will fail because `x fmt` isn't working for me for some reason, I'll debug that later, just opening this now for review, will mark as ready when formatting is fixed~~ (misleading message from x fmt)
cc `@jieyouxu`
When suggesting a type on inference error, do not use `{closure@..}`.
Instead, replace with an appropriate `fn` ptr.
On the error message, use `short_ty_string` and write long types to
disk.
```
error[E0284]: type annotations needed for `Select<{closure@lib.rs:2782:13}, _, Expression<'_>, _>`
--> crates/lang/src/parser.rs:41:13
|
41 | let lit = select! {
| ^^^
42 | Token::Int(i) = e => Expression::new(Expr::Lit(ast::Lit::Int(i.parse().unwrap())), e.span()),
| ---- type must be known at this point
|
= note: the full type name has been written to '/home/gh-estebank/iowo/target/debug/deps/lang-e2d6e25819442273.long-type-4587393693885174369.txt'
= note: cannot satisfy `<_ as chumsky::input::Input<'_>>::Span == SimpleSpan`
help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified
|
41 | let lit: Select<for<'a, 'b> fn(tokens::Token<'_>, &'a mut MapExtra<'_, 'b, _, _>) -> Option<Expression<'_>>, _, Expression<'_>, _> = select! {
| +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
```
instead of
```
error[E0284]: type annotations needed for `Select<{closure@/home/gh-estebank/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-1.0.0-alpha.6/src/lib.rs:2782:13: 2782:28}, _, Expression<'_>, _>`
--> crates/lang/src/parser.rs:41:13
|
41 | let lit = select! {
| ^^^
42 | Token::Int(i) = e => Expression::new(Expr::Lit(ast::Lit::Int(i.parse().unwrap())), e.span()),
| ---- type must be known at this point
|
= note: cannot satisfy `<_ as chumsky::input::Input<'_>>::Span == SimpleSpan`
help: consider giving `lit` an explicit type, where the type for type parameter `I` is specified
|
41 | let lit: Select<{closure@/home/gh-estebank/.cargo/registry/src/index.crates.io-6f17d22bba15001f/chumsky-1.0.0-alpha.6/src/lib.rs:2782:13: 2782:28}, _, Expression<'_>, _> = select! {
| ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
```
Fix#123630.
Unify the output of `suggest_assign_value` and `ty_kind_suggestion`.
Ideally we'd make these a single function, but doing so would likely require modify the crate dependency tree.
This commit does three things:
1. replaces (the last remaining) never true cfgs by the FALSE cfg
2. fix derive-helper-configured.rs (typo in directive)
3. and comment some current unused #[cfg_attr] (missing revisions)
I added this back in 111999, but I no longer think it's a good idea
- It had to get scaled back to only power-of-two things to not break a bunch of targets
- LLVM seems to be getting better at memcpy removal anyway
- Introducing vector instructions has seemed to sometimes (115515) make autovectorization worse
So this removes it from the codegen crates entirely, and instead just tries to use <https://doc.rust-lang.org/nightly/nightly-rustc/rustc_codegen_ssa/traits/builder/trait.BuilderMethods.html#method.typed_place_copy> instead of direct `memcpy` so things will still use load/store for immediates.
Rollup of 8 pull requests
Successful merges:
- #123254 (Do not allocate for ZST ThinBox (attempt 2 using const_allocate))
- #123626 (Add MC/DC support to coverage test tools)
- #123638 (rustdoc: synthetic auto: filter out clauses from the implementor's ParamEnv)
- #123653 (Split `non_local_definitions` lint tests in separate test files)
- #123658 (Stop making any assumption about the projections applied to the upvars in the `ByMoveBody` pass)
- #123662 (Don't rely on upvars being assigned just because coroutine-closure kind is assigned)
- #123665 (Fix typo in `Future::poll()` docs)
- #123672 (compiletest: unset `RUSTC_LOG_COLOR`)
r? `@ghost`
`@rustbot` modify labels: rollup
compiletest: unset `RUSTC_LOG_COLOR`
If this leaks in from the environment then it can make tests fail when they deliberately trigger `WARN` or `ERROR` logging, currently this stops these tests from failing if you set `RUSTC_LOG_COLOR=always` in the parent environment:
- `tests/ui/coherence/occurs-check/associated-type.rs#next`
- `tests/ui/coherence/occurs-check/associated-type.rs#old`
- `tests/ui/higher-ranked/structually-relate-aliases.rs`
- `tests/ui/self/arbitrary-self-from-method-substs.rs#default`
- `tests/ui/traits/next-solver/issue-118950-root-region.rs`
Don't rely on upvars being assigned just because coroutine-closure kind is assigned
Previously, code relied on the implicit assumption that if a coroutine-closure's kind variable was constrained, then its upvars were also constrained. This is because we assign all of them at once at the end up upvar analysis.
However, there's another way that a coroutine-closure's kind can be constrained: from a signature hint in closure signature deduction. After #123350, we use these hints, which means the implicit assumption above no longer holds.
This PR adds the necessary checks so that we don't ICE.
r? oli-obk
Stop making any assumption about the projections applied to the upvars in the `ByMoveBody` pass
So it turns out that because of subtle optimizations like [`truncate_capture_for_optimization`](ab5bda1aa7/compiler/rustc_hir_typeck/src/upvar.rs (L2351)), we simply cannot make any assumptions about the shape of the projections applied to the upvar locals in a coroutine body.
So stop doing that -- the code is resilient to such projections, so the assertion really existed only to "protect against the unknown".
r? oli-obk
Fixes#123650
Split `non_local_definitions` lint tests in separate test files
This PR splits the giant `non_local_definitions` lint UI test in separate test files.
This change is extracted from #123594 (where it was requested https://github.com/rust-lang/rust/pull/123594#discussion_r1555261772), to ease the review of the other PR and to reduce the size of the other PR.
r? ``@compiler-errors``
rustdoc: synthetic auto: filter out clauses from the implementor's ParamEnv
... not just the elaborated clauses.
Fixes another regression introduced by me in #123340, oops!
Fixes https://github.com/rust-lang/rust/pull/123340#issuecomment-2034195786, cc ``@tamird.``
An earlier local iteration of branch `rustdoc-simplify-auto-trait-impl-synth` (PR #123340) contained a fix for issue #111101 before I decided to limit the scope. I must've introduced this bug when manually reverting that part of the code.
r? ``@GuillaumeGomez`` or rustdoc
Add MC/DC support to coverage test tools
Extracted and squashed from #123409 by `@ZhuUx.`
These updates to the coverage test tools can land ahead of the main changes, slightly reducing the size and complexity of that PR.
---
The `coverage-dump` changes aren't directly tested in this PR, but the tests in #123409 demonstrate that they do work on real MC/DC coverage output.
`@rustbot` label +A-code-coverage
Do not allocate for ZST ThinBox (attempt 2 using const_allocate)
There's PR https://github.com/rust-lang/rust/pull/123184 which avoids allocation for ZST ThinBox.
That PR has an issue with unsoundness with padding in `MaybeUninit` (see comments in that PR). Also that PR relies on `Freeze` trait.
This PR is much simpler implementation which does not have this problem, but it uses `const_allocate` feature.
`@oli-obk` suggested that `const_allocate` should not be used for that feature. But I like how easy it to do this feature with `const_allocate`. Maybe it's OK to use `const_allocate` while `ThinBox` is unstable? Or, well, we can abandon this PR.
r? `@oli-obk`
Ensure we do not accidentally insert new early aborts in the analysis passes
pulling the infallible part out into a separate function makes sure that someone needs to change the signature in order to regress this.
We only want to stop compilation in the presence of errors after all analyses are done, but before we start running lints.
per-item we can still stop doing work if previous queries returned errors, but that's a separate story.
If this leaks in from the environment then it can make tests fail when
they deliberately trigger `WARN` or `ERROR` logging.
Signed-off-by: David Wood <david@davidtw.co>
