polish go1.23 range-over-func UX #3733
Labels
Comments
|
See #3732 (wip) |
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
May 28, 2024
Initial support for stepping in functions that use the new range-over-func statement in go1.23. Does not support: - inlining - viewing variables of the enclosing function from a range-over-func body closure - the correct way to find the enclosing function from a range-over-func body closure (but it should work most of the time). Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
May 28, 2024
Initial support for stepping in functions that use the new range-over-func statement in go1.23. Does not support: - inlining - viewing variables of the enclosing function from a range-over-func body closure - the correct way to find the enclosing function from a range-over-func body closure (but it should work most of the time). Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
May 29, 2024
Initial support for stepping in functions that use the new range-over-func statement in go1.23. Does not support: - inlining - viewing variables of the enclosing function from a range-over-func body closure - the correct way to find the enclosing function from a range-over-func body closure (but it should work most of the time). Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
May 30, 2024
Because of how range-over-func is implemented it is difficult to determine the set of visible local variables during expression compilation (i.e. it is difficulto to keep the HasLocal function correct). This commit moves that logic from expression compilation to expression evaluation. Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
May 30, 2024
Because of how range-over-func is implemented it is difficult to determine the set of visible local variables during expression compilation (i.e. it is difficulto to keep the HasLocal function correct). This commit moves that logic from expression compilation to expression evaluation. Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
May 30, 2024
Initial support for stepping in functions that use the new range-over-func statement in go1.23. Does not support: - inlining - viewing variables of the enclosing function from a range-over-func body closure - the correct way to find the enclosing function from a range-over-func body closure (but it should work most of the time). Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
May 30, 2024
Supports viewing local variables and evaluating expressions correctly when range-over-func is used. The same limitations that the previous commit on this line had still apply (no inlining, wrong way to identify the range parent in some cases). Updates go-delve#3733
derekparker
pushed a commit
that referenced
this issue
Jun 4, 2024
Initial support for stepping in functions that use the new range-over-func statement in go1.23. Does not support: - inlining - viewing variables of the enclosing function from a range-over-func body closure - the correct way to find the enclosing function from a range-over-func body closure (but it should work most of the time). Updates #3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 5, 2024
Because of how range-over-func is implemented it is difficult to determine the set of visible local variables during expression compilation (i.e. it is difficulto to keep the HasLocal function correct). This commit moves that logic from expression compilation to expression evaluation. Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 13, 2024
Because of how range-over-func is implemented it is difficult to determine the set of visible local variables during expression compilation (i.e. it is difficulto to keep the HasLocal function correct). This commit moves that logic from expression compilation to expression evaluation. Updates go-delve#3733
derekparker
pushed a commit
that referenced
this issue
Jun 14, 2024
Because of how range-over-func is implemented it is difficult to determine the set of visible local variables during expression compilation (i.e. it is difficulto to keep the HasLocal function correct). This commit moves that logic from expression compilation to expression evaluation. Updates #3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 15, 2024
Supports viewing local variables and evaluating expressions correctly when range-over-func is used. The same limitations that the previous commit on this line had still apply (no inlining, wrong way to identify the range parent in some cases). Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 15, 2024
Supports viewing local variables and evaluating expressions correctly when range-over-func is used. The same limitations that the previous commit on this line had still apply (no inlining, wrong way to identify the range parent in some cases). Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 17, 2024
Supports viewing local variables and evaluating expressions correctly when range-over-func is used. The same limitations that the previous commit on this line had still apply (no inlining, wrong way to identify the range parent in some cases). Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 17, 2024
Supports viewing local variables and evaluating expressions correctly when range-over-func is used. The same limitations that the previous commit on this line had still apply (no inlining, wrong way to identify the range parent in some cases). Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 18, 2024
Extends support for stepping through range-over-func statement to programs compiled with inlining enabled. Updates go-delve#3733 range-over-func 'rangeoverfunc' on '4b628b81'.
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 18, 2024
Uses special variables .closureptr and #yieldN to correctly identify the parent frame of a range-over-func body closure call. Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 19, 2024
Set a breakpoint on the return address of the current function, if it's a range-over-func body, and clear the stepping breakpoints for the current function (except the entry one) when its hit. Without this what can happen is the following: 1. the range-over-func body finishes and returns to the iterator 2. the iterator calls back into the range-over-func body 3. a stepping breakpoint that's inside the prologue gets hit Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 20, 2024
Supports viewing local variables and evaluating expressions correctly when range-over-func is used. The same limitations that the previous commit on this line had still apply (no inlining, wrong way to identify the range parent in some cases). Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 20, 2024
Extends support for stepping through range-over-func statement to programs compiled with inlining enabled. Updates go-delve#3733 range-over-func 'rangeoverfunc' on '4b628b81'.
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 20, 2024
Uses special variables .closureptr and #yieldN to correctly identify the parent frame of a range-over-func body closure call. Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 20, 2024
Set a breakpoint on the return address of the current function, if it's a range-over-func body, and clear the stepping breakpoints for the current function (except the entry one) when its hit. Without this what can happen is the following: 1. the range-over-func body finishes and returns to the iterator 2. the iterator calls back into the range-over-func body 3. a stepping breakpoint that's inside the prologue gets hit Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 21, 2024
Set a breakpoint on the return address of the current function, if it's a range-over-func body, and clear the stepping breakpoints for the current function (except the entry one) when its hit. Without this what can happen is the following: 1. the range-over-func body finishes and returns to the iterator 2. the iterator calls back into the range-over-func body 3. a stepping breakpoint that's inside the prologue gets hit Updates go-delve#3733
derekparker
pushed a commit
that referenced
this issue
Jun 24, 2024
Supports viewing local variables and evaluating expressions correctly when range-over-func is used. The same limitations that the previous commit on this line had still apply (no inlining, wrong way to identify the range parent in some cases). Updates #3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 25, 2024
Extends support for stepping through range-over-func statement to programs compiled with inlining enabled. Updates go-delve#3733 range-over-func 'rangeoverfunc' on '4b628b81'.
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 25, 2024
Uses special variables .closureptr and #yieldN to correctly identify the parent frame of a range-over-func body closure call. Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 25, 2024
Set a breakpoint on the return address of the current function, if it's a range-over-func body, and clear the stepping breakpoints for the current function (except the entry one) when its hit. Without this what can happen is the following: 1. the range-over-func body finishes and returns to the iterator 2. the iterator calls back into the range-over-func body 3. a stepping breakpoint that's inside the prologue gets hit Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 25, 2024
Extends support for stepping through range-over-func statement to programs compiled with inlining enabled. Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 25, 2024
Uses special variables .closureptr and #yieldN to correctly identify the parent frame of a range-over-func body closure call. Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jun 25, 2024
Set a breakpoint on the return address of the current function, if it's a range-over-func body, and clear the stepping breakpoints for the current function (except the entry one) when its hit. Without this what can happen is the following: 1. the range-over-func body finishes and returns to the iterator 2. the iterator calls back into the range-over-func body 3. a stepping breakpoint that's inside the prologue gets hit Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jul 2, 2024
Uses special variables .closureptr and #yieldN to correctly identify the parent frame of a range-over-func body closure call. Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jul 2, 2024
Set a breakpoint on the return address of the current function, if it's a range-over-func body, and clear the stepping breakpoints for the current function (except the entry one) when its hit. Without this what can happen is the following: 1. the range-over-func body finishes and returns to the iterator 2. the iterator calls back into the range-over-func body 3. a stepping breakpoint that's inside the prologue gets hit Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jul 2, 2024
Uses special variables .closureptr and #yieldN to correctly identify the parent frame of a range-over-func body closure call. Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jul 2, 2024
Set a breakpoint on the return address of the current function, if it's a range-over-func body, and clear the stepping breakpoints for the current function (except the entry one) when its hit. Without this what can happen is the following: 1. the range-over-func body finishes and returns to the iterator 2. the iterator calls back into the range-over-func body 3. a stepping breakpoint that's inside the prologue gets hit Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jul 8, 2024
Uses special variables .closureptr and #yieldN to correctly identify the parent frame of a range-over-func body closure call. Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jul 12, 2024
Set a breakpoint on the return address of the current function, if it's a range-over-func body, and clear the stepping breakpoints for the current function (except the entry one) when its hit. Without this what can happen is the following: 1. the range-over-func body finishes and returns to the iterator 2. the iterator calls back into the range-over-func body 3. a stepping breakpoint that's inside the prologue gets hit Updates go-delve#3733
aarzilli
added a commit
to aarzilli/delve
that referenced
this issue
Jul 12, 2024
Set a breakpoint on the return address of the current function, if it's a range-over-func body, and clear the stepping breakpoints for the current function (except the entry one) when its hit. Without this what can happen is the following: 1. the range-over-func body finishes and returns to the iterator 2. the iterator calls back into the range-over-func body 3. a stepping breakpoint that's inside the prologue gets hit Updates go-delve#3733
derekparker
pushed a commit
that referenced
this issue
Jul 15, 2024
Set a breakpoint on the return address of the current function, if it's a range-over-func body, and clear the stepping breakpoints for the current function (except the entry one) when its hit. Without this what can happen is the following: 1. the range-over-func body finishes and returns to the iterator 2. the iterator calls back into the range-over-func body 3. a stepping breakpoint that's inside the prologue gets hit Updates #3733
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tested with the current master:
UX improvement candidates:
Collapse/hide the range body closure (or give an option like DAP implementation's
HideSystemGoroutinesor config) - Related cmd/compile: debugger support for range-over-func golang/go#66468Hide range closure related variables from the local variable set (e.g.
.closureptr,#state,~r0)The text was updated successfully, but these errors were encountered: