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;
|
```
This commit is a continuation of the work originally proposed in
rust-lang/compiler-team#607 and later amended in
rust-lang/compiler-team#695. The end goal is to rename `wasm32-wasi` to
`wasm32-wasip1` to reflect WASI's development and distinguish the
preexisting target from the `wasm32-wasip2` target that WASI is now
developing. Work for this transition began in #120468 which landed in
Rust 1.78 which became stable on 2024-05-02.
This implements the next phase of the transition plan to warn on usage
of `wasm32-wasi`. This is intended to help alert users that a removal is
pending and all release channels have the replacement available as well.
This will reach stable on 2024-09-05. The next stage of the plan is to
remove the `wasm32-wasi` target some time in October 2024 which means
that the removal will reach stable on 2025-01-09. For reference a full
schedule of this transition is listed [here].
Currently this implementation is a simple unconditional warning whenever
`rustc --target wasm32-wasi` is invoked. As-implemented there's no way
to turn off the warning other than to switch to the `wasm32-wasip1`
target.
[here]: https://github.com/rust-lang/rust/pull/120468#issuecomment-1977878747
Replace `move||` with `move ||`
Edit from #126631 to revert changes in `tests/ui`.
There are 18 instances of `move||` across 6 files in the repo:
- `compiler/rustc_hir_typeck/src/typeck_root_ctxt.rs`
- `library/core/src/sync/atomic.rs`
- `library/std/src/sync/condvar.rs`
- `library/std/src/sync/mpsc/mod.rs`
- `library/std/src/sync/barrier.rs`
- `library/std/src/thread/local.rs`
I have replaced all such instances with `move ||` instead as it better adheres to modern formatting standards.
Ideally, we would have this automated by rustfmt or some other tool, but I do not have the time to implement such a feature or tool.
Nonetheless, I would encourage any effort invested into such a tool or feature.
Add `rustc-ice*` to `.gitignore`
I am a bit surprised this wasn't already here but there doesn't seem to be any reason not to add it. This will be nice to cut down on `git {add, diff, etc}` noise when debugging crashes.
hir_typeck: be more conservative in making "note caller chooses ty param" note
In https://github.com/rust-lang/rust/pull/122195 I added a "caller chooses ty for type param" note for when the return expression type a.k.a. found type does not match the expected return type.
#126547 found that this note was confusing when the found return type *contains* the expected type, e.g.
```rs
fn f<T>(t: &T) -> T {
t
}
```
because the found return type `&T` will *always* be different from the expected return type `T`, so the note was needlessly redundant and confusing.
This PR addresses that by not making the note if the found return type contains the expected return type.
r? ``@fmease`` (since you reviewed the original PR)
Fixes https://github.com/rust-lang/rust/issues/126547
Sync fuchsia test runner with clang test runner
This synchronizes the fuchsia test running code with the clang test runner. This brings with it:
* Improved logging
* Uses the fuchsia image from the SDK version
* Caches the product bundle across test runs
* Strips the binaries to reduce the data sent to the emulator
r? ``@tmandry``
safe transmute: support non-ZST, variantful, uninhabited enums
Previously, `Tree::from_enum`'s implementation branched into three disjoint cases:
1. enums that uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple variants
This branching (incorrectly) did not differentiate between variantful and variantless uninhabited enums. In both cases, we assumed (and asserted) that uninhabited enums are zero-sized types. This assumption is false for enums like:
enum Uninhabited { A(!, u128) }
...which, currently, has the same size as `u128`. This faulty assumption manifested as the ICE reported in #126460.
In this PR, we revise the first case of `Tree::from_enum` to consider only the narrow category of "enums that are uninhabited ZSTs". These enums, whose layouts are described with `Variants::Single { index }`, are special in their layouts otherwise resemble the `!` type and cannot be descended into like typical enums. This first case captures uninhabited enums like:
enum Uninhabited { A(!, !), B(!) }
The second case is revised to consider the broader category of "enums that defer their layout to one of their variants"; i.e., enums whose layouts are described with `Variants::Single { index }` and that do have a variant at `index`. This second case captures uninhabited enums that are not ZSTs, like:
enum Uninhabited { A(!, u128) }
...which represent their variants with `Variants::Single`.
Finally, the third case is revised to cover the broader category of "enums with multiple variants", which captures uninhabited enums like:
enum Uninhabited { A(u8, !), B(!, u32) }
...which represent their variants with `Variants::Multiple`.
This PR also adds a comment requested by ````@RalfJung```` in his review of #126358 to `compiler/rustc_const_eval/src/interpret/discriminant.rs`.
Fixes#126460
r? ````@compiler-errors````
Suggest using a standalone doctest for non-local impl defs
This PR tweaks the lint output of the `non_local_definitions` lint to suggest using a standalone doctest instead of a moving the `impl` def to an impossible place as was already done with `macro_rules!` case in https://github.com/rust-lang/rust/pull/124568.
Fixes#126339
r? ```@fmease```
Place tail expression behind terminating scope
This PR implements #123739 so that we can do further experiments in nightly.
A little rewrite has been applied to `for await` lowering. It was previously `unsafe { Pin::unchecked_new(into_async_iter(..)) }`. Under the edition 2024 rule, however, `into_async_iter` gets dropped at the end of the `unsafe` block. This presumably the first Edition 2024 migration rule goes by hoisting `into_async_iter(..)` into `match` one level above, so it now looks like the following.
```rust
match into_async_iter($iter_expr) {
ref mut iter => match unsafe { Pin::unchecked_new(iter) } {
...
}
}
```
