Don't call `query_normalize` when reporting similar impls
Firstly, It's sketchy to be using `query_normalize` at all during HIR typeck -- it's asking for an ICE 😅. Secondly, we're normalizing an impl trait ref that potentially has parameter types in `ty::ParamEnv::empty()`, which is kinda sketchy as well.
The only UI test change from removing this normalization is that we don't evaluate anonymous constants in impls, which end up giving us really ugly suggestions:
```
error[E0277]: the trait bound `[X; 35]: Default` is not satisfied
--> /home/gh-compiler-errors/test.rs:4:5
|
4 | <[X; 35] as Default>::default();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Default` is not implemented for `[X; 35]`
|
= help: the following other types implement trait `Default`:
&[T]
&mut [T]
[T; 32]
[T; core::::array::{impl#30}::{constant#0}]
[T; core::::array::{impl#31}::{constant#0}]
[T; core::::array::{impl#32}::{constant#0}]
[T; core::::array::{impl#33}::{constant#0}]
[T; core::::array::{impl#34}::{constant#0}]
and 27 others
```
So just fold the impls with a `BottomUpFolder` that calls `ty::Const::eval`. This doesn't work totally correctly with generic-const-exprs, but it's fine for stable code, and this is error reporting after all.
Rollup of 7 pull requests
Successful merges:
- #112931 (Enable zlib in LLVM on aarch64-apple-darwin)
- #113158 (tests: unset `RUSTC_LOG_COLOR` in a test)
- #113173 (CI: include workflow name in concurrency group)
- #113335 (Reveal opaques in new solver)
- #113390 (CGU formation tweaks)
- #113399 (Structurally normalize again for byte string lit pat checking)
- #113412 (Add basic types to SMIR)
r? `@ghost`
`@rustbot` modify labels: rollup
New lint [`manual_partial_ord_and_ord_impl`]
Lints when both `PartialOrd` and `Ord` are manually implemented yet the body of `PartialOrd::partial_cmp` isn't `Some(self.cmp(<other>))`.
This is in `correctness` currently but I'm ok with elsewhere.
Closes#10744
---
changelog: new lint [`needless_partial_ord_impl`]
[#10788](https://github.com/rust-lang/rust-clippy/pull/10788)
cargo dev fmt
cargo test passes
cargo test passes
refactor a lil
Update bool_comparison.stderr
heavily refactor + bump `clippy::version`
refactor
refactor
check bounds to increase accuracy, and add todos
Stop inserting semicolon when extracting match arm
# Overview
Extracting a match arm value that has type unit into a function, when a
comma already follows the match arm value, results in an invalid (syntax
error) semicolon added between the newly generated function's generated
call and the comma.
# Example
Running this extraction
```rust
fn main() {
match () {
_ => $0()$0,
};
}
```
would lead to
```rust
fn main() {
match () {
_ => fun_name();,
};
}
fn fun_name() {
}
```
# Issue / Fix details
This happens because when there is no comma, rust-analyzer would simply
add the comma and wouldn't even try to evaluate whether it needs to add
a semicolon. But when the comma is there, it proceeds to evaluate
whether it needs to add a semicolon and it looks like the evaluation
logic erroneously ignores the possibility that we're in a match arm.
IIUC it never makes sense to add a semicolon when we're extracting from
a match arm value, so I've adjusted the logic to always decide against
adding a semicolon when we're in a match arm
Remind user to check $PATH after installation.
fixes#14882 . I don't think that this is the correct wording to express this but I at least wanted to take the initiative :)
Structurally normalize again for byte string lit pat checking
We need to structurally normalize the pointee of a match scrutinee when trying to match byte string patterns -- we used[^1] to call `structurally_resolve_type`, which errors for type vars[^2], but lcnr added `try_structurally_resolve_type`[^3] in the mean time, which is the right thing to use here since it's totally opportunistic.
Fixes rust-lang/trait-system-refactor-initiative#38
[^1]: #112428
[^2]: #112993
[^3]: #113086
Reveal opaques in new solver
We were testing against the wrong reveal mode 😨
Also a couple of misc commits that I don't want to really put in separate prs
r? ``@lcnr``
CI: include workflow name in concurrency group
Currently, this won't change anything, because we only have one relevant workflow (`CI`), but for future proofing we should probably include the workflow name in the concurrency group.
Found by ``@klensy`` [here](https://github.com/rust-lang/rust/pull/113059#discussion_r1247213606).
tests: unset `RUSTC_LOG_COLOR` in a test
Setting `RUSTC_LOG_COLOR=always` is sometimes useful if tools that one pipes `RUSTC_LOG` into support coloured output, but it makes this test fail because it has a `.stderr` file with `WARN` log output.
Enable zlib in LLVM on aarch64-apple-darwin
Works on macOS 13.4, Xcode version 14.3.1.0.1.1683849156
This was disabled in #75500 on Apple Silicon Developer Transition Kit, but Apple appears to have fixed their zlib now
Rename `adjustment::PointerCast` and variants using it to `PointerCoercion`
It makes it sounds like the `ExprKind` and `Rvalue` are supposed to represent all pointer related casts, when in reality their just used to share a little enum variants. Make it clear there these are only coercions and that people who see this and think "why are so many pointer related casts not in these variants" aren't insane.
This enum was added in #59987. I'm not sure whether the variant sharing is actually worth it, but this at least makes it less confusing.
r? oli-obk
Rename `adjustment::PointerCast` and variants using it to `PointerCoercion`
It makes it sounds like the `ExprKind` and `Rvalue` are supposed to represent all pointer related casts, when in reality their just used to share a little enum variants. Make it clear there these are only coercions and that people who see this and think "why are so many pointer related casts not in these variants" aren't insane.
This enum was added in #59987. I'm not sure whether the variant sharing is actually worth it, but this at least makes it less confusing.
r? oli-obk
# Overview
Extracting a match arm value that has type unit into a function, when a
comma already follows the match arm value, results in an invalid (syntax
error) semicolon added between the newly generated function's generated
call and the comma.
# Example
Running this extraction
```rust
fn main() {
match () {
_ => $0()$0,
};
}
```
would lead to
```rust
fn main() {
match () {
_ => fun_name();,
};
}
fn fun_name() {
}
```
# Issue / Fix details
This happens because when there is no comma, rust-analyzer would simply
add the comma and wouldn't even try to evaluate whether it needs to add
a semicolon. But when the comma is there, it proceeds to evaluate
whether it needs to add a semicolon and it looks like the evaluation
logic erroneously ignores the possibility that we're in a match arm.
IIUC it never makes sense to add a semicolon when we're extracting from
a match arm value, so I've adjusted the logic to always decide against
adding a semicolon when we're in a match arm
Rollup of 8 pull requests
Successful merges:
- #113413 (Add needs-triage to all new issues)
- #113426 (Don't ICE in `resolve_bound_vars` when associated return-type bounds are in bad positions)
- #113427 (Remove `variances_of` on RPITIT GATs, remove its one use-case)
- #113441 (miri: check that assignments do not self-overlap)
- #113453 (Remove unused from_method from rustc_on_unimplemented)
- #113456 (Avoid calling report_forbidden_specialization for RPITITs)
- #113466 (Update cargo)
- #113467 (Fix comment of `fn_can_unwind`)
r? `@ghost`
`@rustbot` modify labels: rollup
Update cargo
1 commits in 5b377cece0e0dd0af686cf53ce4637d5d85c2a10..45782b6b8afd1da042d45c2daeec9c0744f72cc7
2023-06-30 00:01:00 +0000 to 2023-07-05 16:54:51 +0000
- docs(ref): Provide guidance on version requirements (rust-lang/cargo#12323)
r? ``@ghost``
Remove unused from_method from rustc_on_unimplemented
Fixes#113439
`on_unimplemented_note` was calling `item_name` for RPITITs and that produced ICEs. I've added a regression test for that but also have removed `from_method` symbol entirely because it wasn't even used and by doing that the `item_name` call was also removed.
r? ``@compiler-errors``
Remove `variances_of` on RPITIT GATs, remove its one use-case
It doesn't make sense to implement variances on a GAT anyways, since we don't relate GATs with variance:
85bf07972a/compiler/rustc_middle/src/ty/relate.rs (L569-L579)
r? ``@spastorino``
Don't ICE in `resolve_bound_vars` when associated return-type bounds are in bad positions
I couldn't find a better way to avoid hitting this ICE, so let's just delay it.
The problem is that we really shouldn't even be *trying* to visit associated type bounds in `resolve_bound_vars` when they show up in impl headers, but we don't have enough context to do this.
Fixes#113423
