| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
Improve spans of non-WF implied bound types
Fixes #60980
|
|
|
|
|
|
Tweak wording of fn call with wrong number of args
|
|
|
|
|
|
|
|
Revert "Implement allow-by-default `multiple_supertrait_upcastable` lint"
This is a clean revert of #105484.
I confirmed that reverting that PR fixes the regression reported in #106247. ~~I can't say I understand what this code is doing, but maybe it can be re-landed with a different implementation.~~ **Edit:** https://github.com/rust-lang/rust/issues/106247#issuecomment-1367174384 has an explanation of why #105484 ends up surfacing spurious `where_clause_object_safety` errors. The implementation of `where_clause_object_safety` assumes we only check whether a trait is object safe when somebody actually uses that trait with `dyn`. However the implementation of `multiple_supertrait_upcastable` added in the problematic PR involves checking *every* trait for whether it is object-safe.
FYI `@nbdd0121` `@compiler-errors`
|
|
Trim more paths in obligation types
|
|
This reverts commit b656e2413022de1863b9ea8db87454477b816042.
|
|
Implement allow-by-default `multiple_supertrait_upcastable` lint
The lint detects when an object-safe trait has multiple supertraits.
Enabled in libcore and liballoc as they are low-level enough that many embedded programs will use them.
r? `@nikomatsakis`
|
|
|
|
|
|
Use impl's def id when calculating type to specify in UFCS
Fixes #104327
Fixes #104328
Also addresses https://github.com/rust-lang/rust/pull/102670#discussion_r987381197
|
|
Tweak output for bare `dyn Trait` in arguments
Fix #35825.
|
|
|
|
Fix #35825.
|
|
|
|
|
|
r=compiler-errors
Suggest dereferencing receiver arguments properly
Fixes #105429
|
|
Suggest `collect`ing into `Vec<_>`
Fix #105510.
|
|
fix a stderr
|
|
|
|
|
|
available
|
|
Point out the type of associated types in every method call of iterator chains
Partially address #105184 by pointing out the type of associated types in every method call of iterator chains:
```
note: the expression is of type `Map<std::slice::Iter<'_, {integer}>, [closure@src/test/ui/iterators/invalid-iterator-chain.rs:12:18: 12:21]>`
--> src/test/ui/iterators/invalid-iterator-chain.rs:12:14
|
10 | vec![0, 1]
| ---------- this expression has type `Vec<{integer}>`
11 | .iter()
| ------ associated type `std::iter::Iterator::Item` is `&{integer}` here
12 | .map(|x| { x; })
| ^^^^^^^^^^^^^^^ associated type `std::iter::Iterator::Item` is `()` here
```
We also reduce the number of impls we mention when any of the candidates is an "exact match". This benefits the output of cases with numerics greatly.
Outstanding work would be to provide a structured suggestion for appropriate changes, like in this case detecting the spurious `;` in the closure.
|
|
|
|
|
|
Add some regression tests for #44454
Closes #44454
r? ``@compiler-errors``
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
|
|
|
|
|
|
Detect long types in E0308 and write them to disk
On type error with long types, print an abridged type and write the full type to disk.
Print the widest possible short type while still fitting in the terminal.
|
|
When *any* of the suggested impls is an exact match, *only* show the
exact matches. This is particularly relevant for integer types.
fix fmt
|
|
|
|
On type error with long types, print an abridged type and write the full
type to disk.
Print the widest possible short type while still fitting in the
terminal.
|
|
This reverts commit cbe932801892da06688b53638622be1c8a1c8974.
|
|
Make `deref_into_dyn_supertrait` lint the impl and not the usage
Proposed by ``@compiler-errors`` in https://github.com/rust-lang/rust/issues/89460#issuecomment-1320806785
r? ``@crlf0710``
|
|
|
|
|
|
Fix hang in where-clause suggestion with `predicate_can_apply`
Using `predicate_may_hold` during error reporting causes an evaluation overflow, which (because we use `evaluate_obligation_no_overflow`) then causes the predicate to need to be re-evaluated locally, which results in a hang.
... but since the "add a where clause" suggestion is best-effort, just throw any overflow errors. No need for 100% accuracy.
r? `@lcnr` who has been thinking about overflows... Let me know if you want more context about this issue, and as always, feel free to reassign.
Fixes #104225
|
|
|
|
Allow opaque types in trait impl headers and rely on coherence to reject unsound cases
r? ````@lcnr````
fixes #99840
|
|
compiler-errors:need_migrate_deref_output_trait_object-msg, r=eholk
Probe + better error messsage for `need_migrate_deref_output_trait_object`
1. Use `InferCtxt::probe` in `need_migrate_deref_output_trait_object` -- that normalization *could* technically do type inference as a side-effect, and this is a lint, so it should have no side-effects.
2. Return the trait-ref so we format the error message correctly. See the UI test change -- `(dyn A + 'static)` is not a trait.
|
|
unsound cases
|
|
|
|
`_` might confuse people into believing that the type isn't known,
while `...` is not used anywhere else for types and is not valid
syntax, making it more likely to convey the right understanding.
|