Previously the lint would be reported at the right span, but could not be `allow`ed or `expect`ed in that location, because the lint was actually emitted using `CRATE_HIR_ID`
When encountering an inference error where a return type must be known, like when calling `Iterator::sum::<T>()` without specifying `T`, look for all `T` that would satisfy `Sum<S>`. If only one, suggest it.
```
error[E0283]: type annotations needed
--> $DIR/cannot-infer-iterator-sum-return-type.rs:4:9
|
LL | let sum = v
| ^^^
...
LL | .sum(); // `sum::<T>` needs `T` to be specified
| --- type must be known at this point
|
= note: cannot satisfy `_: Sum<i32>`
help: the trait `Sum` is implemented for `i32`
--> $SRC_DIR/core/src/iter/traits/accum.rs:LL:COL
::: $SRC_DIR/core/src/iter/traits/accum.rs:LL:COL
|
= note: in this macro invocation
note: required by a bound in `std::iter::Iterator::sum`
--> $SRC_DIR/core/src/iter/traits/iterator.rs:LL:COL
= note: this error originates in the macro `integer_sum_product` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider giving `sum` an explicit type, where the type for type parameter `S` is specified
|
LL | let sum: i32 = v
| +++++
```
Point turbofish inference errors at the uninferred generic arg
Follow-up to rust-lang/rust#153751.
When a method call has a turbofish with an uninferred generic argument, point the diagnostic span at the specific `_` that couldn't be inferred instead of the method name.
Before:
```rust
LL | S.f::<u32, _>(42);
| ^ cannot infer type of the type parameter `B`
```
After:
```rust
LL | S.f::<u32, _>(42);
| ^ cannot infer type of the type parameter `B`
```
Path expressions (`None::<_>`, `foo::<_>()`) are not handled yet, that's a separate code path.
cc @eggyal
Special case message talking about `Predicate` that couldn't be satisfied when in inference errors so that we don't say "cannot satisfy `_: Trait`" and instead say "type must implement `Trait`".
Provide better suggestions for inference errors on `.collect()?`
When encountering an inference error when calling `.collect()` followed by `?`, detect the return type of the enclosing function and suggest `.collect::<Result<_, _>>()?` instead of `.collect::<Vec<_>>()?`:
```
error[E0283]: type annotations needed
--> $DIR/question-mark-type-infer.rs:10:21
|
LL | l.iter().map(f).collect()?
| ^^^^^^^ cannot infer type of the type parameter `B` declared on the method `collect`
|
= note: cannot satisfy `_: FromIterator<Result<i32, ()>>`
note: required by a bound in `collect`
--> $SRC_DIR/core/src/iter/traits/iterator.rs:LL:COL
help: consider specifying the generic argument
|
LL | l.iter().map(f).collect::<Result<_, _>>()?
| ++++++++++++++++
```
On inference error in let binding, account for `?`:
```
error[E0282]: type annotations needed
--> $DIR/question-mark-type-inference-in-chain.rs:31:9
|
LL | let mut tags = lines.iter().map(|e| parse(e)).collect()?;
| ^^^^^^^^
...
LL | tags.sort();
| ---- type must be known at this point
|
help: consider giving `tags` an explicit type
|
LL | let mut tags: Vec<_> = lines.iter().map(|e| parse(e)).collect()?;
| ++++++++
```
Address rust-lang/rust#129269.
When encountering an inference error when calling `.collect()` followed by `?`, detect the return type of the enclosing function and suggest `.collect::<Result<_, _>>()?` instead of `.collect::<Vec<_>>()?`:
```
error[E0283]: type annotations needed
--> $DIR/question-mark-type-infer.rs:10:21
|
LL | l.iter().map(f).collect()?
| ^^^^^^^ cannot infer type of the type parameter `B` declared on the method `collect`
|
= note: cannot satisfy `_: FromIterator<Result<i32, ()>>`
note: required by a bound in `collect`
--> $SRC_DIR/core/src/iter/traits/iterator.rs:LL:COL
help: consider specifying the generic argument
|
LL | l.iter().map(f).collect::<Result<_, _>>()?
| ++++++++++++++++
```
On inference error in let binding, account for `?`:
```
error[E0282]: type annotations needed
--> $DIR/question-mark-type-inference-in-chain.rs:31:9
|
LL | let mut tags = lines.iter().map(|e| parse(e)).collect()?;
| ^^^^^^^^
...
LL | tags.sort();
| ---- type must be known at this point
|
help: consider giving `tags` an explicit type
|
LL | let mut tags: Vec<_> = lines.iter().map(|e| parse(e)).collect()?;
| ++++++++
```
Rehome 30 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` [#4 of Batch #2]
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
We'll still error due to the `opt_bad_ty` of `method_autoderef_steps`.
This slightly worsens the span of `infer_var.method()` which is now the
same as for `Box::new(infer_var).method()`.
Unlike `structurally_resolve_type`, `probe_op` does not check whether
the infcx is already tainted, so this results in 2 previously not emitted
errors.
std: simplify host lookup
The logic for splitting up a string into a hostname and port is currently duplicated across (nearly) all of the networking implementations in `sys`. Since it does not actually rely on any system internals, this PR moves it to the `ToSocketAddr` implementation for `&str`, making it easier to discover and maintain.
On the other hand, the `ToSocketAddr` implementation (or rather the `resolve_socket_addr` function) contained logic to overwrite the port on the socket addresses returned by `LookupHost`, even though `LookupHost` is already aware of the port and sets the port already on Xous. This PR thus removes this logic by moving the responsibility of setting the port to the system-specific `LookupHost` implementation.
As a consequence of these changes, there remains only one way of creating `LookupHost`, hence I've removed the `TryFrom` implementations in favour of a `lookup_host` function, mirroring other, public iterator-based features.
And finally, I've simplified the parsing logic responsible for recognising IP addresses passed to `<(&str, u16)>::to_socket_addrs()` by using the `FromStr` impl of `IpAddr` rather than duplicating the parsing for both IP versions.
`impl PartialEq<{str,String}> for {Path,PathBuf}`
This is a revival of #105877
Comparison of paths and strings is expected to be possible and needed e.g. in tests. This change adds the impls os `PartialEq` between strings and paths, both owned and unsized, in both directions.
ACP: https://github.com/rust-lang/libs-team/issues/151
`tests/ui/issues/`: The Issues Strike Back [4/N]
Some `tests/ui/issues/` housekeeping, to trim down number of tests directly under `tests/ui/issues/`. Part of https://github.com/rust-lang/rust/issues/133895.
r? ````````@jieyouxu````````
Use `tcx.short_string()` in more diagnostics
`TyCtxt::short_string` ensures that user visible type paths aren't overwhelming on the terminal output, and properly saves the long name to disk as a side-channel. We already use these throughout the compiler and have been using them as needed when users find cases where the output is verbose. This is a proactive search of some cases to use `short_string`.
We add support for shortening the path of "trait path only".
Every manual use of `short_string` is a bright marker that that error should be using structured diagnostics instead (as they have proper handling of long types without the maintainer having to think abou tthem).
`TyCtxt::short_string` ensures that user visible type paths aren't overwhelming on the terminal output, and properly saves the long name to disk as a side-channel. We already use these throughout the compiler and have been using them as needed when users find cases where the output is verbose. This is a proactive search of some cases to use `short_string`.
We add support for shortening the path of "trait path only".
Every manual use of `short_string` is a bright marker that that error should be using structured diagnostics instead (as they have proper handling of long types without the maintainer having to think abou tthem).
When we don't actually print out a shortened type we don't need the "use `--verbose`" note.
On E0599 show type identity to avoid expanding the receiver's generic parameters.
Unify wording on `long_ty_path` everywhere.
zedddie