www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.debugger - Debug variables showing when not in scope in Visual D

reply Michelle Long <HappyDance321 gmail.com> writes:
Debug variables are showing when not in scope. Is it possible to 
remove them? They also show before they are actually defined in 
the source code.



int x = 0; < BP here, y and z are shown in the locals.

int y = 3;
{
    int z = 4;
}

// z is when when here.


One ends up with a huge list of variables of all the locals when 
they don't even "exist". I'm using the Mago debugger.
Oct 28 2018
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 28/10/2018 18:35, Michelle Long wrote:
 Debug variables are showing when not in scope. Is it possible to remove
 them? They also show before they are actually defined in the source code.
 
 
 
 int x = 0; < BP here, y and z are shown in the locals.
 
 int y = 3;
 {
    int z = 4;
 }
 
 // z is when when here.
 
 
 One ends up with a huge list of variables of all the locals when they
 don't even "exist". I'm using the Mago debugger.
That used to work for dmd, but it seems to have regressed (still works for try/catch blocks). IIRC LDC does not emit appropriate debug information.
Oct 29 2018
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 29/10/2018 08:32, Rainer Schuetze wrote:
 
 
 On 28/10/2018 18:35, Michelle Long wrote:
 Debug variables are showing when not in scope. Is it possible to remove
 them? They also show before they are actually defined in the source code.



 int x = 0; < BP here, y and z are shown in the locals.

 int y = 3;
 {
    int z = 4;
 }

 // z is when when here.


 One ends up with a huge list of variables of all the locals when they
 don't even "exist". I'm using the Mago debugger.
That used to work for dmd, but it seems to have regressed (still works for try/catch blocks). IIRC LDC does not emit appropriate debug information.
Sorry, I slightly misremembered. The respective debug information is only emitted by dmd if there are multiple declarations with the same variables in different scopes in the same function. This still works fine.
Oct 29 2018
parent reply Michelle Long <HappyDance321 gmail.com> writes:
On Monday, 29 October 2018 at 07:39:14 UTC, Rainer Schuetze wrote:
 On 29/10/2018 08:32, Rainer Schuetze wrote:
 
 
 On 28/10/2018 18:35, Michelle Long wrote:
 Debug variables are showing when not in scope. Is it possible 
 to remove them? They also show before they are actually 
 defined in the source code.



 int x = 0; < BP here, y and z are shown in the locals.

 int y = 3;
 {
    int z = 4;
 }

 // z is when when here.


 One ends up with a huge list of variables of all the locals 
 when they don't even "exist". I'm using the Mago debugger.
That used to work for dmd, but it seems to have regressed (still works for try/catch blocks). IIRC LDC does not emit appropriate debug information.
Sorry, I slightly misremembered. The respective debug information is only emitted by dmd if there are multiple declarations with the same variables in different scopes in the same function. This still works fine.
Can Visual D detect scopes while debugging? E.g., if one is at some line can it determine properly the scope of things? e.g., what symbol is in the current scope and what is not? Or is this all up to dmd? If dmd is the cause of most of these debugging issues, should dmd give as much info as it can so the debugging experience can be optimal? It makes no sense for a compiler to make the debugging experience more difficult because debugging is naturally part of the equation.
Oct 30 2018
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 30/10/2018 16:38, Michelle Long wrote:
 On Monday, 29 October 2018 at 07:39:14 UTC, Rainer Schuetze wrote:
 On 29/10/2018 08:32, Rainer Schuetze wrote:
 On 28/10/2018 18:35, Michelle Long wrote:
 Debug variables are showing when not in scope. Is it possible to
 remove them? They also show before they are actually defined in the
 source code.



 int x = 0; < BP here, y and z are shown in the locals.

 int y = 3;
 {
    int z = 4;
 }

 // z is when when here.


 One ends up with a huge list of variables of all the locals when
 they don't even "exist". I'm using the Mago debugger.
That used to work for dmd, but it seems to have regressed (still works for try/catch blocks). IIRC LDC does not emit appropriate debug information.
Sorry, I slightly misremembered. The respective debug information is only emitted by dmd if there are multiple declarations with the same variables in different scopes in the same function. This still works fine.
Can Visual D detect scopes while debugging? E.g., if one is at some line can it determine properly the scope of things? e.g., what symbol is in the current scope and what is not? Or is this all up to dmd? If dmd is the cause of most of these debugging issues, should dmd give as much info as it can so the debugging experience can be optimal? It makes no sense for a compiler to make the debugging experience more difficult because debugging is naturally part of the equation.
I'd consider it a dmd issue and created an enhancement request: https://issues.dlang.org/show_bug.cgi?id=19349
Nov 03 2018
parent steve brat <haribanbacha69 gmail.com> writes:
On Saturday, 3 November 2018 at 08:08:59 UTC, Rainer Schuetze 
wrote:
 On 30/10/2018 16:38, Michelle Long wrote:
 On Monday, 29 October 2018 at 07:39:14 UTC, Rainer Schuetze 
 wrote:
 On 29/10/2018 08:32, Rainer Schuetze wrote:
 On 28/10/2018 18:35, Michelle Long wrote:
 [...]
That used to work for dmd, but it seems to have regressed (still works for try/catch blocks). IIRC LDC does not emit appropriate debug information.
Sorry, I slightly misremembered. The respective debug information is only emitted by dmd if there are multiple declarations with the same variables in different scopes in the same function. This still works fine.
Can Visual D detect scopes while debugging? E.g., if one is at some line can it determine properly the scope of things? e.g., what symbol is in the current scope and what is not? Or is this all up to dmd? If dmd is the cause of most of these debugging issues, should dmd give as much info as it can so the debugging experience can be optimal? It makes no sense for a compiler to make the debugging experience more difficult because debugging is naturally part of the equation.
I'd consider it a dmd issue and created an enhancement request: https://issues.dlang.org/show_bug.cgi?id=19349
The process for the following aspects which will be going to have the variables that are showing the work for the part https://epsonsupports.net/blog/fix-epson-error-code-0x69/ where the work needs to be checked whether it is performing or not in visual part.
Nov 17 2018