-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat: Closure capture inlay hints #14742
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
Conversation
9876c83
to
2403dd1
Compare
2403dd1
to
8081a65
Compare
// FIXME: &mut qux should be &unique qux | ||
|| { | ||
// ^ move | ||
// ^ ( | ||
// ^ &mut baz | ||
// ^ , | ||
// ^ &mut qux | ||
// ^ ) | ||
baz = NonCopy; | ||
*qux = NonCopy; | ||
}; |
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.
@HKalbasi fwiw I still think this is wrong. qux is not a mutable binding so we shouldn't be allowed to take a mutable borrow here. Do you mind pointing me to the part in the rustc code base for this (assuming you have it at hand)?
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.
qux
is not mutable, but we are taking a mutable reference to the *qux
, not qux
itself. For example this code:
let mut t1 = 2;
let mut t2 = 5;
let mut x = &mut t1;
let mut y = || {
//&x;
*x = 3;
};
x = &mut t2;
y();
compiles since y
is capturing *x
by mutable borrow, so x
itself is free to mutate. But if the //&x;
line becomes uncommented, y
will capture the whole x
by unique immutable borrow, and we will get compile error.
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.
I think it will becomes less confusing if we render the whole place.
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.
I think my confusion comes from thinking of old capture logic? Also the rust reference I suppose is outdated then. You are certainly right that we should be rendering the place we capture, as with this mere field captures will render incorrectly already I believe.
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.
I think my confusion comes from thinking of old capture logic? Also the rust reference I suppose is outdated then
Yes the rust reference section for closure is pre edition-2021, and is currently in a misleading state.
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.
Turns out there is a PR for this already so I'll dig into that for now rust-lang/reference#1059
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.
The new writing still refers to this as a unique immutable borrow fwiw https://github.com/sexxi-goose/reference/blob/closure-doc/src/types/closure.md#unique-immutable-borrows-in-captures
🔥 🧨 🚒 |
9fbd202
to
1c99118
Compare
1c99118
to
4c5fd19
Compare
We probably want an image showcasing more complex captures for the changelog, will cook those up some later time this week |
☀️ Test successful - checks-actions |
I'll use the existing one, it seems complex enough to me 😅. |
I opted for a fictional

move(foo, &bar, &mut qux)
syntax here, disabled by default as these are not correct rust syntax and hence could cause confusion.