Show trait method signature when impl differs
When the trait's span is available, it is already being used, add a
`note` for the cases where the span isn't available:
<pre>
error[E0053]: <b>method `fmt` has an incompatible type for trait</b>
--> $DIR/trait_type.rs:17:4
|
17 | fn fmt(&self, x: &str) -> () { }
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ types differ in mutability
|
= note: expected type `<b>fn(&MyType, &mut std::fmt::Formatter<'_>) -> std::result::Result<(), std::fmt::Error></b>`
found type `<b>fn(&MyType, &str)</b>`
error[E0050]: <b>method `fmt` has 1 parameter but the declaration in trait `std::fmt::Display::fmt` has 2</b>
--> $DIR/trait_type.rs:21:11
|
21 | fn fmt(&self) -> () { }
| ^^^^^ expected 2 parameters, found 1
|
= note: `fmt` from trait: `<b>fn(&Self, &mut std::fmt::Formatter<'_>) -> std::result::Result<(), std::fmt::Error></b>`
error[E0186]: <b>method `fmt` has a `&self` declaration in the trait, but not in the impl</b>
--> $DIR/trait_type.rs:25:4
|
25 | fn fmt() -> () { }
| ^^^^^^^^^^^^^^^^^^ expected `&self` in impl
|
= note: `fmt` from trait: `<b>fn(&Self, &mut std::fmt::Formatter<'_>) -> std::result::Result<(), std::fmt::Error></b>`
error[E0046]: <b>not all trait items implemented, missing: `fmt`</b>
--> $DIR/trait_type.rs:28:1
|
28 | impl std::fmt::Display for MyType4 {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `fmt` in implementation
|
= note: `fmt` from trait: `<b>fn(&Self, &mut std::fmt::Formatter<'_>) -> std::result::Result<(), std::fmt::Error></b>`
</code></pre>
Fix#28011.
When the trait's span is available, it is already being used, add a
`note` for the cases where the span isn't available:
```
error[E0053]: method `fmt` has an incompatible type for trait
--> $DIR/trait_type.rs:17:4
|
17 | fn fmt(&self, x: &str) -> () { }
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ types differ in mutability
|
= note: expected type `fn(&MyType, &mut std::fmt::Formatter<'_>) -> std::result::Result<(), std::fmt::Error>`
found type `fn(&MyType, &str)`
error[E0050]: method `fmt` has 1 parameter but the declaration in trait `std::fmt::Display::fmt` has 2
--> $DIR/trait_type.rs:21:11
|
21 | fn fmt(&self) -> () { }
| ^^^^^ expected 2 parameters, found 1
|
= note: `fmt` from trait: `fn(&Self, &mut std::fmt::Formatter<'_>) -> std::result::Result<(), std::fmt::Error>`
error[E0186]: method `fmt` has a `&self` declaration in the trait, but not in the impl
--> $DIR/trait_type.rs:25:4
|
25 | fn fmt() -> () { }
| ^^^^^^^^^^^^^^^^^^ expected `&self` in impl
|
= note: `fmt` from trait: `fn(&Self, &mut std::fmt::Formatter<'_>) -> std::result::Result<(), std::fmt::Error>`
error[E0046]: not all trait items implemented, missing: `fmt`
--> $DIR/trait_type.rs:28:1
|
28 | impl std::fmt::Display for MyType4 {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `fmt` in implementation
|
= note: `fmt` from trait: `fn(&Self, &mut std::fmt::Formatter<'_>) -> std::result::Result<(), std::fmt::Error>`
```
incr.comp.: Use DefPathHash-based DepNodes in the serialized DepGraph and remove obsolete DefIdDirectory
With this PR we don't store the dep-graph as a set of `DepNode<IndexIntoDefIdDirectory>` anymore but instead as a set of `DepNode<DefPathHash>`. Since a `DefPathHash` is a global identifier that is valid across compilation sessions, we don't need the `DefIdDirectory` anymore.
Since a `DepNode<DefPathHash>` is bigger than a `DepNode<IndexIntoDefIdDirectory>` and our on-disk encoding of the dep-graph is inefficient, this PR will probably increase the amount of space the dep-graph takes up on disk. I'm in the process of gathering some performance data.
The changes in here are a step towards implementing ICH-based `DepNodes` (#42294).
r? @nikomatsakis
Decompose Adjustment into smaller steps and remove the method map.
The method map held method callee information for:
* actual method calls (`x.f(...)`)
* overloaded unary, binary, indexing and call operators
* *every overloaded deref adjustment* (many can exist for each expression)
That last one was a historical ~~accident~~ hack, and part of the motivation for this PR, along with:
* a desire to compose adjustments more freely
* containing the autoderef logic better to avoid mutation within an inference snapshot
* not creating `TyFnDef` types which are incompatible with the original one
* i.e. we used to take a`TyFnDef`'s `for<'a> &'a T -> &'a U` signature and instantiate `'a` using a region inference variable, *then* package the resulting `&'b T -> &'b U` signature in another `TyFnDef`, while keeping *the same* `DefId` and `Substs`
* to fix#3548 by explicitly writing autorefs for the RHS of comparison operators
Individual commits tell their own story, of "atomic" changes avoiding breaking semantics.
Future work based on this PR could include:
* removing the signature from `TyFnDef`, now that it's always "canonical"
* some questions of variance remain, as subtyping *still* treats the signature differently
* moving part of the typeck logic for methods, autoderef and coercion into `rustc::traits`
* allowing LUB coercions (joining multiple expressions) to "stack up" many adjustments
* transitive coercions (e.g. reify or unsize after multiple steps of autoderef)
r? @nikomatsakis
Upgrade ProjectionTy's Name to a DefId
Part of #42171, in preparation for downgrading the contained `TraitRef` to
only its `substs`.
Some inline questions in the diff. Look for `FIXME(tschottdorf)`. These comments
should be addressed before merging.
Explain why a closure is `FnOnce` in closure errors.
Issue: #42065
@nikomatsakis Am I going the right direction with this?
~~I am stuck in a few bits:~~
~~1. How to trace the code to get the upvar instead of the original variable's span?~~
~~2. How to find the node id of the upvar where the move occured?~~
Translate array drop glue using MIR
I was a bit lazy here and used a usize-based index instead of a pointer iteration. Do you think this is important @eddyb?
r? @eddyb
This fixes leakage on panic with arrays & slices. I am using a C-style
for-loop instead of a pointer-based loop because that would be ugly-er
to implement.
extend `struct_tail` to operate over tuples
Not 100% sure why this got exposed when it wasn't before, but this struct definitely seems wrong.
Fixes#42110
r? @eddyb
Ideally, we'd have the `Ty` inserted directly in the dep-node, but since
we can't do that yet, we extract the characteristic def-id of the type
in question.
Use the trait-environment+type as the key. Note that these
are only invoked on types that live for the entire compilation
(no inference artifacts). We no longer need the various special-case
bits and caches that were in place before.