Do not complain about unmentioned fields in recovered patterns
When the parser has to recover from malformed code in a pattern, do not
complain about missing fields.
Fix#59145.
When two multiline span labels point at the same span, we special
case the output to avoid weird behavior:
```
foo(
_____^
|_____|
|| bar,
|| );
|| ^
||______|
|______foo
baz
```
instead showing
```
foo(
_____^
| bar,
| );
| ^
| |
|______foo
baz
```
Generalize diagnostic for `x = y` where `bool` is the expected type
Extracted out of https://github.com/rust-lang/rust/pull/59288.
Currently we special case a diagnostic for `if x = y { ...` since the expected type is `bool` in this case and we instead suggest `if x == y`. This PR generalizes this such that given an expression of form `x = y` (`ExprKind::Assign(..)`) where the expected type is `bool`, we emit a suggestion `x == y`.
r? @oli-obk
Let's do a perf run to make sure this was not the source of regressions in #59288.
Provide suggestion when using field access instead of path
When trying to access an associated constant as if it were a field of
an instance, provide a suggestion for the correct syntax.
Fix#57316.
filter suggestions from extern prelude
Fixes#59027.
Modifies the candidate gathering code to call `filter_fn` on extern crates, which causes them to be filtered out when looking for a type.
make asm diagnostic instruction optional
`DiagnosticInfoInlineAsm::getInstruction` may return a null pointer, so
the instruction shouldn't be blindly unwrapped.
Reopening from #55193. I was unable to trigger the assertion on Windows after rebasing.
Fixes#23458.
Fixes#55216.
When moving out of a for loop head, suggest borrowing it
When encountering code like the following, suggest borrowing the for loop
head to avoid moving it into the for loop pattern:
```
fn main() {
let a = vec![1, 2, 3];
for i in &a {
for j in a {
println!("{} * {} = {}", i, j, i * j);
}
}
}
```
Fix#25534.
When encountering code like the following, suggest borrowing the for loop
head to avoid moving it into the for loop pattern:
```
fn main() {
let a = vec![1, 2, 3];
for i in &a {
for j in a {
println!("{} * {} = {}", i, j, i * j);
}
}
}
```
Rollup of 7 pull requests
Successful merges:
- #59213 (Track changes to robots.txt)
- #59239 (Remove inline assembly from hint::spin_loop)
- #59251 (Use a valid name for graphviz graphs)
- #59296 (Do not encode gensymed imports in metadata)
- #59328 (Implement specialized nth_back() for Box and Windows.)
- #59355 (Fix ICE with const generic param in struct)
- #59377 (Correct minimum system LLVM version in tests)
(WIP) Small fixes in chalkification
Small fixes around region constraints and builtin impls. There are still some type inference errors, for example the following code errors out:
```rust
fn main() {
let mut x: Vec<i32> = Vec::new();
// ^^^^^^^^ cannot infer type for `std::vec::Vec<_>`
}
```
but explicitly specifying `Vec::<i32>::new` works.
With these few fixes, the following code now passes type-checking:
```rust
fn main() {
let mut x: Vec<i32> = Vec::<i32>::new();
x.push(5);
println!("{:?}", x);
}
```
I also fixed the implied bounds bug as discussed on Zulip and in https://github.com/rust-lang-nursery/chalk/pull/206
cc @tmandry
r? @nikomatsakis
Do not encode gensymed imports in metadata
(Unless they are underscore `_` imports which are re-gensymed on crate loading, see https://github.com/rust-lang/rust/pull/56392.)
We cannot encode gensymed imports properly in metadata and if we encode them improperly, we can get erroneous name conflicts downstream.
Gensymed imports are produced by the compiler, so we control their set, and can be sure that none of them needs being encoded for use from other crates.
A workaround that fixes https://github.com/rust-lang/rust/issues/59243.
Remove `track_errors` from `check_match`, `typeck_item_bodies` and `register_plugins`
In the spirit of continuing through errors in type checking (#39275), remove `track_errors` from a couple of locations in the codebase.
