| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit 1cb555a1dc809a8d310354678ef9c43f01e41ad4.
|
|
r=Centril
Backport only: avoid ICE on bad placeholder type
#69148 has a proper fix, but it is too big to backport.
This change avoids the ICE by actually emitting an appropriate error. The
output will be duplicated in some cases, but that's better than the
avoidable ICE.
r? @Centril
|
|
|
|
#69148 has a proper fix, but it is too big to backport.
This change avoids the ICE by actually emitting an appropriate error. The
output will be duplicated in some cases, but that's better than the
avoidable ICE.
|
|
|
|
|
|
suggestions when possible
|
|
Stemming from the thread at https://twitter.com/indygreg/status/1223279056398929920
|
|
|
|
|
|
Suggest calling method when first argument is `self`
Closes: #66782
I've explored different approaches for this MR but I think the most straightforward is the best one.
I've tried to find out if the methods for given type exist (to maybe have a better suggestion), but we don't collect them anywhere and collecting them is quite problematic. Moreover, collecting all the methods would require rewriting big part of the code and also could potentially include performance degradation, which I don't think is necessary for this simple case.
|
|
r=estebank
Suggest adding a lifetime constraint for opaque type
Fixes #67577, where code like this:
```
struct List {
data: Vec<String>,
}
impl List {
fn started_with<'a>(&'a self, prefix: &'a str) -> impl Iterator<Item=&'a str> {
self.data.iter().filter(|s| s.starts_with(prefix)).map(|s| s.as_ref())
}
}
```
will show this error:
```
Compiling playground v0.0.1 (/playground)
error[E0597]: `prefix` does not live long enough
--> src/lib.rs:6:47
|
5 | fn started_with<'a>(&'a self, prefix: &'a str) -> impl Iterator<Item=&'a str> {
| -- lifetime `'a` defined here --------------------------- opaque type requires that `prefix` is borrowed for `'a`
...
```
but without suggesting the lovely `help: you can add a constraint..`.
r? @estebank
|
|
`bound`
|
|
|
|
When encountering `_` type placeholder in fn arguments and return type,
suggest using generic type parameters.
Expand what counts as an inferable return type to slice, array and
tuples of `_`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously, only Self, &Self, &mut Self, Arc<Self>, Rc<Self>,
and Box<Self> were available as stable method receivers.
This commit stabilizes nested uses of all the above types.
However, nested receivers remain non-object-safe.
|
|
Suggest to add lifetime constraint at explicit ouput of functions
Closes #62097
|
|
|
|
|
|
Point at the span for the definition of ADTs internal to the current
crate.
Look at the leading char of the ident to determine whether we're
expecting a likely fn or any of a fn, a tuple struct or a tuple variant.
Turn fn `add_typo_suggestion` into a `Resolver` method.
|
|
Make the spacing between the code snippet and verbose structured
suggestions consistent with note and help messages.
|
|
Object safe for dispatch
cc #43561
|
|
These are a squashed series of commits.
|
|
Change untagged_unions to not allow union fields with drop
This is a rebase of #56440, massaged to solve merge conflicts and make the test suite pass.
Change untagged_unions to not allow union fields with drop
Union fields may now never have a type with attached destructor. This for example allows unions to use arbitrary field types only by wrapping them in `ManuallyDrop` (or similar).
The stable rule remains, that union fields must be `Copy`. We use the new rule for the `untagged_union` feature.
Tracking issue: https://github.com/rust-lang/rust/issues/55149
|
|
|
|
|
|
typo: fix typo in E0392
See #64931.
---
Cc: @Centril @estebank
|
|
See #64931.
|
|
r=cramertj
extract expected return type for async fn generators
Fixes #60424
cc @Centril, I know you've been eager to see this fixed.
r? @cramertj
|
|
|
|
|
|
|
|
Make it clearer that a type or lifetime argument not being used can be
fixed by referencing it in a struct's fields, not just using `PhathomData`.
|
|
Add Long error explanation for E0531
Part of #61137.
|
|
|
|
|
|
|