override user defined channel when using precompiled rustc
We need to override `rust.channel` if it's manually specified when using the CI rustc. This is because if the compiler uses a different channel than the one specified in config.toml, tests may fail due to using a different channel than the one used by the compiler during tests.
For more context, see https://github.com/rust-lang/rust/pull/122709#issuecomment-2165246281.
Remove `src/tools/rust-demangler`
`rust-demangler` is a small binary that reads a list of mangled symbols from stdin, demangles them (using the `rustc-demangle` library crate), and prints the demangled symbols to stdout.
It was added as part of the initial implementation of coverage instrumentation in 2020/2021, so that coverage tests could pass it to `llvm-cov --Xdemangler` when generating coverage reports. It has been largely untouched since then.
As of #125816 it is no longer used by coverage tests, and has no remaining in-tree uses.
There is code in bootstrap to build and package the demangler, but it's unclear where the resulting binaries actually end up, or whether there's any reasonable way for `rustup` users to obtain them.
---
For users needing a command-line demangler, `rustfilt` exists and is more actively maintained. It's also quite easy to use the `rustc-demangle` library to build a custom command-line demangler if necessary, with only a few lines of code.
The tool's name (`rust-demangler`) is easily confused with the name of the library crate `rustc-demangle`, so removing the tool will eliminate that confusion. There also doesn't appear to be much reason to use `rust-demangler` over `rustfilt`.
---
This PR therefore removes the tool, and removes all of its associated code from bootstrap.
MCP filed: https://github.com/rust-lang/compiler-team/issues/754
MCDC Coverage: instrument last boolean RHS operands from condition coverage
Fresh PR from #124652
--
This PR ensures that the top-level boolean expressions that are not part of the control flow are correctly instrumented thanks to condition coverage.
See discussion on https://github.com/rust-lang/rust/issues/124120.
Depends on `@Zalathar` 's condition coverage implementation #125756.
Allow constraining opaque types during subtyping in the trait system
Previous attempt: https://github.com/rust-lang/rust/pull/123979
Sometimes we don't immediately perform subtyping, but instead register a subtyping obligation and solve that obligation when its inference variables become resolved. Unlike immediate subtyping, we currently do not allow registering hidden types for opaque types. This PR also allows that.
It now parses outer attributes before collecting tokens. This avoids the
problem where the outer attribute tokens were being stored twice -- for
the attribute tokesn, and also for the expression tokens.
Fixes#86055.
Rollup of 7 pull requests
Successful merges:
- #123782 (Test that opaque types can't have themselves as a hidden type with incompatible lifetimes)
- #124580 (Suggest removing unused tuple fields if they are the last fields)
- #125787 (Migrate `bin-emit-no-symbols` `run-make` test to `rmake`)
- #126553 (match lowering: expand or-candidates mixed with candidates above)
- #126594 (Make async drop code more consistent with regular drop code)
- #126654 (Make pretty printing for `f16` and `f128` consistent)
- #126656 (rustc_type_ir: Omit some struct fields from Debug output)
r? `@ghost`
`@rustbot` modify labels: rollup
Combine `NotYetParsed` and `AttributesParsed` into a single variant,
because (a) that reflects the structure of the code that consumes
`LhsExpr`, and (b) because that variant will have the `Option` removed
in a later commit.
The `Option<AttrWrapper>` one maps to the first two variants, and the
`P<Expr>` one maps to the third. Weird. The code is shorter and clearer
without them.
The call in `parse_expr_prefix` for the `++` case passes an empty
`attrs`, but it doesn' need to. This commit changes it to pass the
parsed `attrs`, which doesn't change any behaviour. As a result,
`parse_expr_dot_or_call` no longer needs an `Option` argument, and no
longer needs to call `parse_or_use_outer_attributes`.
Term search: new tactic for associated item constants
New tactic to cover some more exotic cases that started bothering me.
Associated constants seem to be common in [axum](806bc26e62/examples/readme/src/main.rs (L53)).
feat: add `toggleLSPLogs` command
Implement client-side command to toggle LSP logs in VSCode.
The command replaces the need to add/remove the `"rust-analyzer.trace.server": "verbose"` setting each time one wants to display logs. I've also updated the docs/ instances that reference the now outdated manual method.
The command labeled `rust-analyzer: Toggle LSP Logs` enables the setting project-wide and opens the relevant trace output channel.
Closes#8233
feat: add space after specific keywords in completion
fix#17428.
When completing some specific keywords, it would be convenient if r-a could automatically add a space afterwards.
This PR implements this feature for the following keywords:
- Visibility: `pub`, `pub(crate)`, `pub(super)`, `pub(in xxx)`
- Pattern: `ref` / `mut`
- Others: `unsafe` / `for` / `where`
fix: handle character boundaries for wide chars in extend_selection
fix#17420.
When calling 'extend_selection' within a string, r-a attempts to locate the current word at the cursor. This is done by finding the first char before the cursor which is not a letter, digit, or underscore.
The position of this character is referred to as `start_idx`, and the word is considered to start from `start_idx + 1`. However, for wide characters, `start_idx + 1` is not character boundaries, which leading to panic. We should use `ceil_char_boundary` to ensure that the idx is always on character boundaries.
fix: Only show unlinked-file diagnostic on first line during startup
This partially reverts #17350, based on the feedback in #17397.
If we don't have an autofix, it's more annoying to highlight the whole file. This autofix heuristic fixes the diagnostic being overwhelming during startup.
Make pretty printing for `f16` and `f128` consistent
Currently the docs show e.g.
{transmute(0xfffeffffffffffffffffffffffffffff): f128}
for f128 constants. This should fix that to instead use apfloat for printing, as is done for `f32` and `f64`.
match lowering: expand or-candidates mixed with candidates above
This PR tweaks match lowering of or-patterns. Consider this:
```rust
match (x, y) {
(1, true) => 1,
(2, false) => 2,
(1 | 2, true | false) => 3,
(3 | 4, true | false) => 4,
_ => 5,
}
```
One might hope that this can be compiled to a single `SwitchInt` on `x` followed by some boolean checks. Before this PR, we compile this to 3 `SwitchInt`s on `x`, because an arm that contains more than one or-pattern was compiled on its own. This PR groups branch `3` with the two branches above, getting us down to 2 `SwitchInt`s on `x`.
We can't in general expand or-patterns freely, because this interacts poorly with another optimization we do: or-pattern simplification. When an or-pattern doesn't involve bindings, we branch the success paths of all its alternatives to the same block. The drawback is that in a case like:
```rust
match (1, true) {
(1 | 2, false) => unreachable!(),
(2, _) => unreachable!(),
_ => {}
}
```
if we used a single `SwitchInt`, by the time we test `false` we don't know whether we came from the `1` case or the `2` case, so we don't know where to go if `false` doesn't match.
Hence the limitation: we can process or-pattern alternatives alongside candidates that precede it, but not candidates that follow it. (Unless the or-pattern is the only remaining match pair of its candidate, in which case we can process it alongside whatever).
This PR allows the processing of or-pattern alternatives alongside candidates that precede it. One benefit is that we now process or-patterns in a single place in `mod.rs`.
r? ``@matthewjasper``
Suggest removing unused tuple fields if they are the last fields
Fixes#124556
We now check if dead/unused fields are the last fields of the tuple and suggest their removal instead of suggesting them to be changed to `()`.
Test that opaque types can't have themselves as a hidden type with incompatible lifetimes
fixes#122876
This PR used to add extra logic to prevent those cases, but after https://github.com/rust-lang/rust/pull/113169 this is implicitly rejected, because such usages are not defining.
Condition coverage extends branch coverage to treat the specific case
of last operands of boolean decisions not involved in control flow.
This is ultimately made for MCDC to be exhaustive on all boolean expressions.
This patch adds a call to `visit_branch_coverage_operation` to track the
top-level operand of the said decisions, and changes
`visit_coverage_standalone_condition` so MCDC branch registration is called
when enabled on these _last RHS_ cases.
improve tip for inaccessible traits
Improve the tips when the candidate method is from an inaccessible trait.
For example:
```rs
mod m {
trait Trait {
fn f() {}
}
impl<T> Trait for T {}
}
fn main() {
struct S;
S::f();
}
```
The difference between before and now is:
```diff
error[E0599]: no function or associated item named `f` found for struct `S` in the current scope
--> ./src/main.rs:88:6
|
LL | struct S;
| -------- function or associated item `f` not found for this struct
LL | S::f();
| ^ function or associated item not found in `S`
|
= help: items from traits can only be used if the trait is implemented and in scope
- help: trait `Trait` which provides `f` is implemented but not in scope; perhaps you want to import it
+ help: trait `crate:Ⓜ️:Trait` which provides `f` is implemented but not reachable
|
- LL + use crate:Ⓜ️:Trait;
|
```
