| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
r=Dylan-DPC
Reword unused variable warning
Fixes #66636
|
|
|
|
|
|
Previously, metadata encoding used DUMMY_SP to represent any spans that
referenced an 'imported' SourceFile - e.g. a SourceFile from an upstream
dependency. These leads to sub-optimal error messages in certain cases
(see the included test).
This PR changes how we encode and decode spans in crate metadata. We
encode spans in one of two ways:
* 'Local' spans, which reference non-imported SourceFiles, are encoded
exactly as before.
* 'Foreign' spans, which reference imported SourceFiles, are encoded
with the CrateNum of their 'originating' crate. Additionally, their
'lo' and 'high' values are rebased on top of the 'originating' crate,
which allows them to be used with the SourceMap data encoded for that
crate.
The `ExternalSource` enum is renamed to `ExternalSourceKind`. There is
now a struct called `ExternalSource`, which holds an
`ExternalSourceKind` along with the original line number information for
the file. This is used during `Span` serialization to rebase spans onto
their 'owning' crate.
|
|
|
|
On mismatched argument count point at arguments
|
|
Update tests
Extend to other operations
Refractor check in a separate function
Fix more tests
|
|
|
|
|
|
When suggesting associated fn with type parameters, include in the structured suggestion
Address #50734.
```
error[E0046]: not all trait items implemented, missing: `foo`, `bar`, `baz`
--> file.rs:14:1
|
14 | impl TraitA<()> for S {
| ^^^^^^^^^^^^^^^^^^^^^ missing `foo`, `bar`, `baz` in implementation
|
= help: implement the missing item: `fn foo<T>(_: T) -> Self where T: TraitB, TraitB::Item = A { unimplemented!() }`
= help: implement the missing item: `fn bar<T>(_: T) -> Self { unimplemented!() }`
= help: implement the missing item: `fn baz<T>(_: T) -> Self where T: TraitB, <T as TraitB>::Item: std::marker::Copy { unimplemented!() }`
```
It doesn't work well for associated types with `ty::Predicate::Projection`s as we need to resugar `T: Trait, Trait::Assoc = K` → `T: Trait<Assoc = K>`.
|
|
|
|
|
|
|
|
parser: syntactically allow `self` in all `fn` contexts
Part of https://github.com/rust-lang/rust/pull/68728.
`self` parameters are now *syntactically* allowed as the first parameter irrespective of item context (and in function pointers). Instead, semantic validation (`ast_validation`) is used.
r? @petrochenkov
|
|
|
|
|
|
|
|
Unify output of "variant not found" errors
Fix #49566.
|
|
|
|
|
|
|
|
This still doesn't handle the case entirely correctly, requiring a more
targeted approach with a better suggestion, but at least now the
suggested syntax makes *some* sense.
|
|
r=estebank
Indicate origin of where type parameter for uninferred types
Based on #65951 (which is not merge yet), fixes #67277.
This PR improves a little the diagnostic for code like:
```
async fn foo() {
bar().await;
}
async fn bar<T>() -> () {}
```
by showing:
```
error[E0698]: type inside `async fn` body must be known in this context
--> unresolved_type_param.rs:9:5
|
9 | bar().await;
| ^^^ cannot infer type for type parameter `T` declared on the function `bar`
|
...
```
(The
```
declared on the function `bar`
```
part is new)
A small side note: `Vec` and `slice` seem to resist this change, because querying `item_name()` panics, and `get_opt_name()` returns `None`.
r? @estebank
|
|
Use structured suggestion for disambiguating method calls
Fix #65635.
|
|
Suggest associated type when the specified one cannot be found
Fixes #67386, so code like this:
```
use std::ops::Deref;
fn homura<T: Deref<Trget = i32>>(_: T) {}
fn main() {}
```
results in:
```
error[E0220]: associated type `Trget` not found for `std::ops::Deref`
--> type-binding.rs:6:20
|
6 | fn homura<T: Deref<Trget = i32>>(_: T) {}
| ^^^^^^^^^^^ help: there is an associated type with a similar name: `Target`
error: aborting due to previous error
```
(The `help` is new)
I used an `all_candidates: impl Fn() -> Iterator<...>` instead of `collect`ing to avoid the cost of allocating the Vec when no errors are found, at the expense of a little added complexity.
r? @estebank
|
|
Unify binop wording
Closes #60497
r? @estebank
|
|
|
|
|
|
|
|
|
|
Fix #65635.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This fixes some ordering problems around assignment expressions.
|
|
|
|
Remove "here" from "expected one of X here"
|
|
Update some build-pass ui tests to use check-pass where applicable
Helps with issue https://github.com/rust-lang/rust/issues/62277.
|
|
|
|
|
|
Use ident.span instead of def_span in dead-code pass
Hello! First time contributor! :)
This should fix #58729.
According to @estebank in the duplicate #63064, def_span scans forward on the line until it finds a {,
and if it can't find one, falls back to the span for the whole item. This
was apparently written before the identifier span was explicitly tracked on
each node.
This means that if an unused function signature spans multiple lines, the
entire function (potentially hundreds of lines) gets flagged as dead code.
This could, for example, cause IDEs to add error squiggly's to the whole
function.
By using the span from the ident instead, we narrow the scope of this in
most cases. In a wider sense, it's probably safe to use ident.span
instead of def_span in most locations throughout the whole code base,
but since this is my first contribution, I kept it small.
Some interesting points that came up while I was working on this:
- I reorganized the tests a bit to bring some of the dead code ones all
into the same location
- A few tests were for things unrelated to dead code (like the
path-lookahead for parens), so I added #![allow(dead_code)] and
cleaned up the stderr file to reduce noise in the future
- The same fix doesn't apply to const and static declarations. I tried
adding these cases to the match expression, but that created a much
wider change to tests and error messages, so I left it off until I
could get some code review to validate the approach.
|
|
If item.span is part of a macro invocation, this has several downstream
implications. To name two that were found while working on this:
- The dead-code error gets annotated with a "in this macro invocation"
- Some errors get canceled if they refer to remote crates
Ideally, we should annotate item.ident.span with the same macro info,
but this is a larger change (see: #66095), so for now we just fall
back to the old behavior if this item was generated by a macro.
I use span.macro_backtrace().len() to detect if it's part of a macro,
because that (among other things) is what is used by the code which
adds the "in this macro invocation" annotations mentioned above.
|
|
|
