-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decompose Adjustment into smaller steps and remove the method map. #42281
Conversation
Started crater run. |
The current Travis failures are in UI tests due to error output changed (intentionally), e.g.: error[E0277]: the trait bound `{integer}: std::ops::Mul<()>` is not satisfied
- --> $DIR/binops.rs:14:5
+ --> $DIR/binops.rs:14:7
|
14 | 3 * ();
- | ^^^^^^ no implementation for `{integer} * ()`
+ | ^ no implementation for `{integer} * ()`
|
= help: the trait `std::ops::Mul<()>` is not implemented for `{integer}` cc @rust-lang/docs @nikomatsakis @jonathandturner Is this is an improvement? |
@eddyb: I don't think it is. It should still underline the whole expression. |
I personally consider it an improvement, as it points at the thing that isn't implemented. The operands aren't really part of the problem; making the span as small as possible seems better. |
Crater report is clean (modulo the usual network errors and lint plugins). |
I'm with @Mark-Simulacrum here. The error text still says which specific kind of multiplication isn't implemented, and pointing directly at the operator can save some confusion if it were part of a larger/more complicated expression. |
@eddyb - yes, pointing at the offending operator looks like an improvement to me. As @QuietMisdreavus points out, this becomes more important with larger expressions, but even small ones seem to be a little clearer |
Thanks everyone! I pushed an update to the UI tests. |
☔ The latest upstream changes (presumably #42264) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a few nits, but r=me. Very cool!
src/librustc/ty/adjustment.rs
Outdated
/// Represents coercing a value to a different type of value. | ||
/// | ||
/// We transform values by following the following steps in order: | ||
/// 1. Apply a step of `Adjust` (see its variants for details). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should say "apply the base transformation described by kind
", right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean by "base"? But yeah I could use kind
and then refer to "variants of Adjust
".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh look at the latest version of this comment, that was transient.
src/librustc/ty/context.rs
Outdated
.map_or_else(|| self.expr_ty(expr), |adj| adj.target) | ||
} | ||
|
||
pub fn expr_ty_adjusted_opt(&self, expr: &hir::Expr) -> Option<Ty<'tcx>> { | ||
self.adjustments.get(&expr.id) | ||
self.expr_adjustments(expr).last() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: I'd find this easier to read if each step in the chain (i.e., .last()
, .map()
, and .or_else()
were on their own line). Or at least .map()
and .or_else()
.
@@ -134,22 +134,22 @@ fn test_push() { | |||
fn test_push_unique() { | |||
let mut heap = BinaryHeap::<Box<_>>::from(vec![box 2, box 4, box 9]); | |||
assert_eq!(heap.len(), 3); | |||
assert!(*heap.peek().unwrap() == box 9); | |||
assert!(**heap.peek().unwrap() == 9); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's happening here? some lints firing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yupp! Comparison operators are now understood by the "unnecessary allocation" lint.
| | ||
34 | n + sum_to(n - 1) | ||
| ^^^^^^^^^^^^^^^^^ no implementation for `u32 + impl Foo` | ||
| ^ no implementation for `u32 + impl Foo` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice
Regarding the new spans -- yes, I consider it an improvement. I believe this is what clang does. Part of the reason I think this is better: mutil-line spans are terrible, and this avoids that. |
I was wondering what happened to those changes.... |
@nikomatsakis I actually rebased those on top of this branch today, but tried to keep this PR separate. |
@bors r=nikomatsakis |
📌 Commit e3b49c5 has been approved by |
☔ The latest upstream changes (presumably #42336) made this pull request unmergeable. Please resolve the merge conflicts. |
@bors r=nikomatsakis |
📌 Commit 5fb37be has been approved by |
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
☀️ Test successful - status-appveyor, status-travis |
The method map held method callee information for:
x.f(...)
)That last one was a historical
accidenthack, and part of the motivation for this PR, along with:TyFnDef
types which are incompatible with the original oneTyFnDef
'sfor<'a> &'a T -> &'a U
signature and instantiate'a
using a region inference variable, then package the resulting&'b T -> &'b U
signature in anotherTyFnDef
, while keeping the sameDefId
andSubsts
Individual commits tell their own story, of "atomic" changes avoiding breaking semantics.
Future work based on this PR could include:
TyFnDef
, now that it's always "canonical"rustc::traits
r? @nikomatsakis