-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Tracking issue: Allow autoderef and autoref in operators (experiment) #44762
Comments
Note: @arielb1 was going to write-up some mentoring instructions here when they get the time. =) |
Mentor NotesThis basically requires 2 main steps:
1. Changing method-style lookup to allow for lookup based on multiple typesMethod lookup needs to have flags added to it, so it can support operator lookup as specified in RFC 2174. The semantics are actually pretty similar to how it works today, but there are a few needed changes:
The code for looking up methods is in rustc_typeck::method::probe, and it needs to be adapted for all 3 components. You basically want to add a method on rust/src/librustc_typeck/check/method/probe.rs Lines 201 to 283 in d8d5b61
However, I feel that operator dispatch avoids most of the code in Only probing for a specific DefId should be easy - instead of calling Similarly, not probing for mutable autoref just requires having a flag and an if around the call to
Allowing dispatch with 2 receivers is a bit more annoying. I think the cleanest way would be to have an optional "secondary" xform_self_ty field on You will also need to have a variant of method confirmation that handles operators - see rust/src/librustc_typeck/check/method/confirm.rs Lines 80 to 143 in d8d5b61
For that method, you should make the 2. Changing operator dispatch to use method-style lookupFor dispatch, there are 2 kinds of operators, "rvalue" operators and "lvalue" operators (the relevant lvalue operator here is overloaded indexing - implementing autoderef for the For an example of method lookup, see Rvalue operators are implemented in rust/src/librustc_typeck/check/op.rs Lines 156 to 306 in d8d5b61
Array indexing is implemented in rust/src/librustc_typeck/check/mod.rs Lines 2188 to 2290 in d8d5b61
Note: feature gatingThis is a big improvement to operator lookup, which we might not want to be active by default. Initially, we should probably keep the old operator lookup code, and switch between the old and the new code using feature gating. |
I would like to give it a shot! |
That's cool. This is a nice quality-of-life improvement I'm looking forward to seeing. If you need any help, I'm @arielb1 on gitter. |
I've studied a long time the code and the documentation to have a glimse on the working of the code i was going to work with. I'm coming back to you to present a work-in-progress to be sure i'm on the good track : I think I should use the Op enum defined here directly instead of having a is_assign flag. I've taken some shortcut for now using unwrap(), i should add some error handling code instead of making the whole compiler panic x) but i'm not sure what exactly i should do. |
Hi, I have a mostly working MVP for this |
@peckpeck interesting! Where is it? |
Here : https://github.com/peckpeck/rust/tree/autoref_op It looks like confirm_method mess up with the caller's state, even with the exact same return value as with original code, the result is not accepted when i pass through it |
As for the second argument part i looked into it and saw that most rust_type_check::check::method::* code assume that there is only one parameter which can be autoref/autoderef
|
I could use some help in my exploration, I'm pretty sure there are some side effect to the calls of |
Progress information: it is now feature gated with It works for unary ops and self in binary ops, but any attempt with something invalid may break the compilation or the resulting binary. next step is the hard part : implementing autoref for the rhs if any |
Hi, i've now got a working implementation for some use cases, the probe loop is still not checking all use cases and some questions remain, but I think it's starting to be usable. |
It works \o/ and passes existing tests (the current behaviour is unchanged) What would be the next step after this ? |
@peckpeck you can open a PR and put "r? @nikomatsakis" in it |
Hi, i will be offline for a week, so the PR will wait a little bit |
visiting for T-compiler backlog bonanza. Its awesome that @peckpeck picked up the ball and ran with it here, as evidenced at https://github.com/peckpeck/rust/tree/autoref_op But, since nothing has landed in tree yet, we still want the tracking issue's status label to reflect that. (@peckpeck , feel free to reach out if you need help turning your branch into a PR.) @rustbot label: S-tracking-unimplemented |
Can I pick this up if it is still relevant? |
This is a specific issue to track the changes proposed by @arielb1 in RFC 2174. We decided to roll this into a larger experiment around coercions, generics, and Copy type ergonomics and are therefore ready to implement (but not yet stabilize).
The text was updated successfully, but these errors were encountered: