On Thursday, 5 November 2015 at 22:12:39 UTC, Rainer Schuetze wrote:
>
> Now updated to a new beta:
>
> https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta2

Hello!  A small issue I noticed: If I create a configuration for x64, visual studio doesn't know that this means version(Win64) is true and version(Win32) is false, as seen here:

http://imgur.com/Gui9rYz

I verified that a pointer (using .sizeof) is 8 bytes with x64 configuration and 4 bytes with x86 configuration, so it's just the editor that doesn't know.

On 06.12.2015 01:16, Andrew LaChance wrote:
> On Thursday, 5 November 2015 at 22:12:39 UTC, Rainer Schuetze wrote:
>>
>> Now updated to a new beta:
>>
>> https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta2
>>
>
> Hello!  A small issue I noticed: If I create a configuration for x64,
> visual studio doesn't know that this means version(Win64) is true and
> version(Win32) is false, as seen here:
>
> http://imgur.com/Gui9rYz
>
> I verified that a pointer (using .sizeof) is 8 bytes with x64
> configuration and 4 bytes with x86 configuration, so it's just the
> editor that doesn't know.

Thanks for reporting. You can also file issues at https://issues.dlang.org/enter_bug.cgi?product=D

It seems that this happens for files that are not part of a project. It can be ambiguous what versions have to be defined for the source file, but Win64 should be taken from the selected platform. I remember having trouble detecting this setting for "compile and run", too.

On 05.12.2015 21:50, Andrew LaChance wrote:
> On Thursday, 5 November 2015 at 22:12:39 UTC, Rainer Schuetze wrote:
>>
>>
>> On 01.11.2015 11:29, Rainer Schuetze wrote:
>>> Hi,
>>>
>>> I just uploaded a beta for the next release of Visual D.
>>>
>>> You can find the list of changes and the installer here:
>>>
>>> https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta1
>>>
>>>
>>>
>>> Rainer
>>
>> Now updated to a new beta:
>>
>> https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.43-beta2
>>
>
> Thank you for the update!  It fixed my link issues.
>
> I have found a very strange issue with I *think* visual D.  I have
> condensed into a very small repro here: http://1drv.ms/1Oai14L (entire
> solution).  If I build and run on x86 build config, everything is fine.
> But on x64, debugging (with Debug x64 config) will cause an exception
> somewhere on this line:
>
> writeln(AnotherColor.Red.stringof); // AnotherColor is an enum
>
> But if I were to run the exe from the command line it is fine. Release
> version is fine too.  Also, it is fine if I put a breakpoint on the
> first line in main.d and then step over each line.  But hitting continue
> will throw an exception.  I'm not exactly sure where the exception comes
> from:
>
>      DPlayground.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv() + 0x32 bytes    D
>
>      DPlayground.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv() + 0x6f bytes    D
>
>      DPlayground.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv()
> + 0x3c bytes    D
>
>      DPlayground.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv() + 0x6f bytes    D
>       DPlayground.exe!_d_run_main() + 0x421 bytes    D
>       DPlayground.exe!__entrypoint.main( int argc, char** argv ) + 0x22
> bytes    D
>>     DPlayground.exe!invoke_main() Line 75    D
>       DPlayground.exe!__scrt_common_main_seh() Line 264 + 0x5 bytes    D
>       DPlayground.exe!__scrt_common_main() Line 309    D
>       DPlayground.exe!mainCRTStartup() Line 17    D
>
> Have you seen anything like this before?

I can reproduce the problem here. This is caused by the breakpoint modifying the code at a wrong instruction address, which leads to a bad stack cleanup.

As this happens for all debug engines, it is very likely due to bad debug information emitted by dmd.

On Monday, 7 December 2015 at 08:27:54 UTC, Rainer Schuetze wrote:
>
>
> On 05.12.2015 21:50, Andrew LaChance wrote:
>> [...]
>
> I can reproduce the problem here. This is caused by the breakpoint modifying the code at a wrong instruction address, which leads to a bad stack cleanup.
>
> As this happens for all debug engines, it is very likely due to bad debug information emitted by dmd.

Oh wow, that sounds nasty!  Is there a bug in dmd for this?

On 10.12.2015 05:56, Andrew LaChance wrote:
> On Monday, 7 December 2015 at 08:27:54 UTC, Rainer Schuetze wrote:
>>
>>
>> On 05.12.2015 21:50, Andrew LaChance wrote:
>>> [...]
>>
>> I can reproduce the problem here. This is caused by the breakpoint
>> modifying the code at a wrong instruction address, which leads to a
>> bad stack cleanup.
>>
>> As this happens for all debug engines, it is very likely due to bad
>> debug information emitted by dmd.
>
> Oh wow, that sounds nasty!  Is there a bug in dmd for this?

I have added a report here: https://issues.dlang.org/show_bug.cgi?id=15432