www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - Visual D 1.2.0-rc1 available

reply Rainer Schuetze <r.sagitario gmx.de> writes:
Hi,

I have just uploaded a new release candidate for Visual D at 
https://github.com/dlang/visuald/releases/tag/v1.2.0-rc1

Major changes:

   * added support for VS 2022
   * dmdserver updated to frontend of DMD 2.098.0
   * added option to restart the semantic analysis if memory
     usage goes above a given threshold
   * fixed bugzilla 21877: VS2019 crash with "Show parameter
     storage class at call site"
   * full installer now bundled with DMD 2.098.0 and LDC 1.28.0

Known issues:

   * the signing certificate of the D Language Foundation has
     expired, so the installer cannot be signed digitally ATM
     (the same as the dmd installer).
   * parallel compilation of D files in VC projects doesn't
     work in VS 2022.

Cheers,
Rainer
Nov 29 2021
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 29 November 2021 at 08:47:25 UTC, Rainer Schuetze 
wrote:

 Hi,

 I have just uploaded a new release candidate for Visual D at 
 https://github.com/dlang/visuald/releases/tag/v1.2.0-rc1

 Major changes:

   * added support for VS 2022
   * dmdserver updated to frontend of DMD 2.098.0
   * added option to restart the semantic analysis if memory
     usage goes above a given threshold
   * fixed bugzilla 21877: VS2019 crash with "Show parameter
     storage class at call site"
   * full installer now bundled with DMD 2.098.0 and LDC 1.28.0

 Known issues:

   * the signing certificate of the D Language Foundation has
     expired, so the installer cannot be signed digitally ATM
     (the same as the dmd installer).
   * parallel compilation of D files in VC projects doesn't
     work in VS 2022.

 Cheers,
 Rainer


THANK YOU
Nov 29 2021
prev sibling next sibling parent kinjal kishor <kinjalkishor gmail.com> writes:
On Monday, 29 November 2021 at 08:47:25 UTC, Rainer Schuetze 
wrote:

 Hi,

 I have just uploaded a new release candidate for Visual D at 
 https://github.com/dlang/visuald/releases/tag/v1.2.0-rc1

 Major changes:

   * added support for VS 2022
   * dmdserver updated to frontend of DMD 2.098.0
   * added option to restart the semantic analysis if memory
     usage goes above a given threshold
   * fixed bugzilla 21877: VS2019 crash with "Show parameter
     storage class at call site"
   * full installer now bundled with DMD 2.098.0 and LDC 1.28.0

 Known issues:

   * the signing certificate of the D Language Foundation has
     expired, so the installer cannot be signed digitally ATM
     (the same as the dmd installer).
   * parallel compilation of D files in VC projects doesn't
     work in VS 2022.

 Cheers,
 Rainer


Thank You very much. Did not looked in release section on GitHub 
as 1.1.0 is seen on project page. I find VS code somewhat 
cumbersome and prefer Visual Studio.
Dec 13 2021
prev sibling parent reply Complexity <Matters Universe.com> writes:
On Monday, 29 November 2021 at 08:47:25 UTC, Rainer Schuetze 
wrote:

 Hi,

 I have just uploaded a new release candidate for Visual D at 
 https://github.com/dlang/visuald/releases/tag/v1.2.0-rc1

 Major changes:

   * added support for VS 2022
   * dmdserver updated to frontend of DMD 2.098.0
   * added option to restart the semantic analysis if memory
     usage goes above a given threshold
   * fixed bugzilla 21877: VS2019 crash with "Show parameter
     storage class at call site"
   * full installer now bundled with DMD 2.098.0 and LDC 1.28.0

 Known issues:

   * the signing certificate of the D Language Foundation has
     expired, so the installer cannot be signed digitally ATM
     (the same as the dmd installer).
   * parallel compilation of D files in VC projects doesn't
     work in VS 2022.

 Cheers,
 Rainer



Visual D is crashing Visual Studio 2022 after doing a fresh 
install of both. This seems to be happening when debugging and 
adding breakpoints. Did not happen with 2019 so it's either the 
VisualD release(I think I was using the same) or due to 2022.

I think simply trying to debug a program will give you the crash.
Dec 19 2021
next sibling parent reply Rumbu <rumbu rumbu.ro> writes:
On Sunday, 19 December 2021 at 16:53:44 UTC, Complexity wrote:

 On Monday, 29 November 2021 at 08:47:25 UTC, Rainer Schuetze 
 wrote:

 Hi,

 I have just uploaded a new release candidate for Visual D at 
 https://github.com/dlang/visuald/releases/tag/v1.2.0-rc1

 Major changes:

   * added support for VS 2022
   * dmdserver updated to frontend of DMD 2.098.0
   * added option to restart the semantic analysis if memory
     usage goes above a given threshold
   * fixed bugzilla 21877: VS2019 crash with "Show parameter
     storage class at call site"
   * full installer now bundled with DMD 2.098.0 and LDC 1.28.0

 Known issues:

   * the signing certificate of the D Language Foundation has
     expired, so the installer cannot be signed digitally ATM
     (the same as the dmd installer).
   * parallel compilation of D files in VC projects doesn't
     work in VS 2022.

 Cheers,
 Rainer



 Visual D is crashing Visual Studio 2022 after doing a fresh 
 install of both. This seems to be happening when debugging and 
 adding breakpoints. Did not happen with 2019 so it's either the 
 VisualD release(I think I was using the same) or due to 2022.

 I think simply trying to debug a program will give you the 
 crash.


Debugging works for me in VS 2022.

What is not working for me:
- in x64 mode the linker cannot find phobos64.lib, I must add 
manually windows/lib64 to lib paths in the project configuration.
- icons for visualdproj files are blank.
- syntax highlighting does not work after several edits. It can 
be linked to dmdserver.exe, I end with 5-6 instances after some 
time.

In VS2019 it still works like a charm, thank you Rainer for the 
good work.
Dec 19 2021
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 19/12/2021 21:47, Rumbu wrote:

 Debugging works for me in VS 2022.
 
 What is not working for me:
 - in x64 mode the linker cannot find phobos64.lib, I must add manually 
 windows/lib64 to lib paths in the project configuration.


Is this with the D specific projects (visualdproj), or the Visual C++ 
integration? I cannot reproduce it neither with DMD nor LDC.

If the former, please enable verbose compilation to see what library 
paths are used for linking.


 - icons for visualdproj files are blank.


Indeed, I see it here, too.


 - syntax highlighting does not work after several edits. It can be 
 linked to dmdserver.exe, I end with 5-6 instances after some time.


I don't see dmdserver.exe crashing or restarting, but there seems to be 
something odd as it sometimes produces very few completions after 
initialization. Loading another file helped in this case.


 
 In VS2019 it still works like a charm, thank you Rainer for the good work.
 


Thanks, good to hear :-)
Dec 24 2021
parent reply rumbu <rumbu rumbu.ro> writes:
On Friday, 24 December 2021 at 11:06:42 UTC, Rainer Schuetze 
wrote:

 On 19/12/2021 21:47, Rumbu wrote:

 Debugging works for me in VS 2022.
 
 What is not working for me:
 - in x64 mode the linker cannot find phobos64.lib, I must add 
 manually windows/lib64 to lib paths in the project 
 configuration.


 If the former, please enable verbose compilation to see what 
 library paths are used for linking.


I looked into the build logs and there are 2 diferences when 
loading the same project:

VS2019:
```
set LIB=C:\D\dmd2\windows\bin\..\lib64
```
VS2022:
```
set LIB=
```


VS2019:
```
"C:\Program Files (x86)\VisualD\pipedmd.exe" -msmode -deps 
x64\Debug\WindowsApp11.lnkdep "C:\Program Files (x86)\Microsoft 
Visual 
Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\HostX86\x86\link.exe"
 C:\Users\Rumbu\source\repos\WindowsApp11\x64\Debug\WindowsApp11.link.rsp
```

VS2022:
```
"C:\Program Files (x86)\VisualD\pipedmd.exe" -msmode -deps 
x64\Debug\WindowsApp1.lnkdep link.exe 
 C:\Users\Rumbu\source\repos\WindowsApp11\x64\Debug\WindowsApp11.link.rsp
```



 I don't see dmdserver.exe crashing or restarting, but there 
 seems to be something odd as it sometimes produces very few 
 completions after initialization. Loading another file helped 
 in this case.


Unfortunately, I cannot find a pattern, sometimes works for hours 
perfectly, sometimes it does basic syntax highlighting only (does 
not colorize recognized symbols, only keywords). Restarting 
doesn't help either, after some time it's comming back to the 
normal experience, irrespective of my actions (opening another 
doc, killing dmdserver or DParserComServer). Anyway, as a bottom 
line, it's more stable with DParserComServer than with dmdserver, 
tried both.
Dec 24 2021
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 24/12/2021 19:13, rumbu wrote:

 On Friday, 24 December 2021 at 11:06:42 UTC, Rainer Schuetze wrote:

 On 19/12/2021 21:47, Rumbu wrote:

 Debugging works for me in VS 2022.

 What is not working for me:
 - in x64 mode the linker cannot find phobos64.lib, I must add 
 manually windows/lib64 to lib paths in the project configuration.


 If the former, please enable verbose compilation to see what library 
 paths are used for linking.


 
 I looked into the build logs and there are 2 diferences when loading the 
 same project:
 
 VS2019:
 ```
 set LIB=C:\D\dmd2\windows\bin\..\lib64
 ```
 VS2022:
 ```
 set LIB=


This setting is read from the [Environment64] section in sc.ini in the 
dmd bin folder. Are you using different compiler versions in the 
different VS?


 ```
 
 
 VS2019:
 ```
 "C:\Program Files (x86)\VisualD\pipedmd.exe" -msmode -deps 
 x64\Debug\WindowsApp11.lnkdep "C:\Program Files (x86)\Microsoft Visual 
 Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\HostX86\x86\link.exe" 
  C:\Users\Rumbu\source\repos\WindowsApp11\x64\Debug\WindowsApp11.link.rsp
 ```
 
 VS2022:
 ```
 "C:\Program Files (x86)\VisualD\pipedmd.exe" -msmode -deps 
 x64\Debug\WindowsApp1.lnkdep link.exe 
  C:\Users\Rumbu\source\repos\WindowsApp11\x64\Debug\WindowsApp11.link.rsp
 ```
 


This suggests that sc.ini isn't found at all. In that case the setting 
from Tools->Options->Projects and Solutions->Visual D Settings->DMD 
Directories->x64->Linker isn't applied (which is a bug).

Please verify your settings on that page.


 

 I don't see dmdserver.exe crashing or restarting, but there seems to 
 be something odd as it sometimes produces very few completions after 
 initialization. Loading another file helped in this case.


 
 Unfortunately, I cannot find a pattern, sometimes works for hours 
 perfectly, sometimes it does basic syntax highlighting only (does not 
 colorize recognized symbols, only keywords). Restarting doesn't help 
 either, after some time it's comming back to the normal experience, 
 irrespective of my actions (opening another doc, killing dmdserver or 
 DParserComServer). Anyway, as a bottom line, it's more stable with 
 DParserComServer than with dmdserver, tried both.
 
 



hasn't been updated in years, so I consider it legacy. I'd recommend it 
only to people that cannot run the dmdserver 64-bit executable. Being 


I suspect that crashes depend on the actual code being analyzed. While 
editing, bogus code can crash the dmd frontend or cause ICEs. Maybe some 
logging can be added that allows to analyze them better.
Dec 25 2021
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 19/12/2021 17:53, Complexity wrote:

 On Monday, 29 November 2021 at 08:47:25 UTC, Rainer Schuetze wrote:

 Hi,

 I have just uploaded a new release candidate for Visual D at 
 https://github.com/dlang/visuald/releases/tag/v1.2.0-rc1

 Major changes:

   * added support for VS 2022
   * dmdserver updated to frontend of DMD 2.098.0
   * added option to restart the semantic analysis if memory
     usage goes above a given threshold
   * fixed bugzilla 21877: VS2019 crash with "Show parameter
     storage class at call site"
   * full installer now bundled with DMD 2.098.0 and LDC 1.28.0

 Known issues:

   * the signing certificate of the D Language Foundation has
     expired, so the installer cannot be signed digitally ATM
     (the same as the dmd installer).
   * parallel compilation of D files in VC projects doesn't
     work in VS 2022.

 Cheers,
 Rainer


 
 
 Visual D is crashing Visual Studio 2022 after doing a fresh install of 
 both. This seems to be happening when debugging and adding breakpoints. 
 Did not happen with 2019 so it's either the VisualD release(I think I 
 was using the same) or due to 2022.
 
 I think simply trying to debug a program will give you the crash.


Cannot reproduce here, e.g. on the dmdserver executable. Do you find a 
crashdump of devenv.exe in c:\Users\name\AppData\CrashDumps?
Dec 24 2021
parent reply Complexity <C D.com> writes:
On Friday, 24 December 2021 at 11:12:51 UTC, Rainer Schuetze 
wrote:

 On 19/12/2021 17:53, Complexity wrote:

 On Monday, 29 November 2021 at 08:47:25 UTC, Rainer Schuetze 
 wrote:

 Hi,

 I have just uploaded a new release candidate for Visual D at 
 https://github.com/dlang/visuald/releases/tag/v1.2.0-rc1

 Major changes:

   * added support for VS 2022
   * dmdserver updated to frontend of DMD 2.098.0
   * added option to restart the semantic analysis if memory
     usage goes above a given threshold
   * fixed bugzilla 21877: VS2019 crash with "Show parameter
     storage class at call site"
   * full installer now bundled with DMD 2.098.0 and LDC 1.28.0

 Known issues:

   * the signing certificate of the D Language Foundation has
     expired, so the installer cannot be signed digitally ATM
     (the same as the dmd installer).
   * parallel compilation of D files in VC projects doesn't
     work in VS 2022.

 Cheers,
 Rainer


 
 
 Visual D is crashing Visual Studio 2022 after doing a fresh 
 install of both. This seems to be happening when debugging and 
 adding breakpoints. Did not happen with 2019 so it's either 
 the VisualD release(I think I was using the same) or due to 
 2022.
 
 I think simply trying to debug a program will give you the 
 crash.


 Cannot reproduce here, e.g. on the dmdserver executable. Do you 
 find a crashdump of devenv.exe in 
 c:\Users\name\AppData\CrashDumps?


No, it doens't produce it, although I had a few crash dumps from 
12-30-21 involving the dmd server so maybe it was them.

c:\Users\name\AppData\Local\CrashDumps BTW

It does it both with x64 and x86 although I tried to run it with 
buggy code(trying to modify some code and had a bug(array 
accessor) and it crashed in to the debugger but at the entrypoint 
code with no real information about what happened(but since it 
was a minor change and an array index error(length instead of 
length-1 basically) it was obvious where the bug was. So without 
BP's it does go in to the debugger, more or less but with BP's it 
crashes VS entirely.

This is 100% due to upgrading to Visual Studio 2022. I tried 
another project and I get "cannot launch debbugger on ... hr 
89710016".

I also get the error
Severity	Code	Description	Project	File	Line	Suppression State
Error		Error: file `"Plotter.py"` cannot be found or not in a 
path specified with `-J`
C:\Projects\XXX\XXX.d(125): Path(s) searched (as provided by 
`-J`):		C:\Projects\XXX\XXX.d	125	

Which never occurred before upgrading and seems to not stop the 
program from working(I have the -J and since it's compiling it is 
finding the file so this seems to be another bug, maybe related).

Clearly something is off. I'm pretty sure just a few days ago I 
was able to run that same project(a different one and a new 
project I created recently under the new VS) so the issue with 
launching the debugger maybe because it crashed when I was trying 
to debug the first project and now it can't launch.

I'll reboot and try again later. (The reason I say it must have 
worked is because I had a BP set in the project and don't 
remember it not working at all)

So maybe it is an issue with debug information in projects 
created in previous versions of VS that are not translating debug 
information correctly to newer projects?

If you tried it on a fresh project maybe open up an old one and 
see. (although I do think that the project I used was old but I 
heavily modified it)

Almost surely some type of memory access issue given the nature 
of the crash.

What happens when I place a breakpoint then run the program it 
does show the code and the yellow arrow on top of the red BP disk 
and then it shows the crash dialog about "The instruction at ... 
references memory at .... The memory could not be written.".

If I try to debug it then it opens up a new VS with the 
devenv.exe but nothing really is going on and then if I click 
start debugging it will run VS. If I open up the project then it 
says an exception is thrown with "Exception thrown at .... 
(comctl32.dll) in devenv.exe: 0xC00000005: Access violation 
writing location ....

It also says comctl32.pdb not loaded but not sure if that has 
anything to do with it.

Does any of this make any sense? Maybe the comctl32.dll is 
corrupted or versioned wrong or something?
Jan 11 2022
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 12/01/2022 05:41, Complexity wrote:

 On Friday, 24 December 2021 at 11:12:51 UTC, Rainer Schuetze wrote:

 On 19/12/2021 17:53, Complexity wrote:

 Visual D is crashing Visual Studio 2022 after doing a fresh install 
 of both. This seems to be happening when debugging and adding 
 breakpoints. Did not happen with 2019 so it's either the VisualD 
 release(I think I was using the same) or due to 2022.

 I think simply trying to debug a program will give you the crash.


 Cannot reproduce here, e.g. on the dmdserver executable. Do you find a 
 crashdump of devenv.exe in c:\Users\name\AppData\CrashDumps?


 
 No, it doens't produce it, although I had a few crash dumps from 
 12-30-21 involving the dmd server so maybe it was them.


I forgot that writing the dumps is not enabled by default. Here's a 
description of the necessary registry entries to enable it:

https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps

The next Visual D installer will enable it for dmdserver.exe, but not 
for other applications.


 
 c:\Users\name\AppData\Local\CrashDumps BTW
 
 It does it both with x64 and x86 although I tried to run it with buggy 
 code(trying to modify some code and had a bug(array accessor) and it 
 crashed in to the debugger but at the entrypoint code with no real 
 information about what happened(but since it was a minor change and an 
 array index error(length instead of length-1 basically) it was obvious 
 where the bug was. So without BP's it does go in to the debugger, more 
 or less but with BP's it crashes VS entirely.
 
 This is 100% due to upgrading to Visual Studio 2022. I tried another 
 project and I get "cannot launch debbugger on ... hr 89710016".


Are you using the visualdproj format projects or the integration with 
VC++ projects. If the former, don't use the legacy "Mago" debug engine, 
it is not supported in a 64-bit environment like VS 2022 (though 
unfortunately still the default for new projects). Both "Visual Studio" 
debug engines integrate the Mago debugger extension.


 I also get the error
 Severity    Code    Description    Project    File    Line    
 Suppression State
 Error        Error: file `"Plotter.py"` cannot be found or not in a
path 
 specified with `-J`
 C:\Projects\XXX\XXX.d(125): Path(s) searched (as provided by 
 `-J`):        C:\Projects\XXX\XXX.d    125


This seems unrelated and is likely some option -J missing within the 
language server.


 
 Which never occurred before upgrading and seems to not stop the program 
 from working(I have the -J and since it's compiling it is finding the 
 file so this seems to be another bug, maybe related).
 
 Clearly something is off. I'm pretty sure just a few days ago I was able 
 to run that same project(a different one and a new project I created 
 recently under the new VS) so the issue with launching the debugger 
 maybe because it crashed when I was trying to debug the first project 
 and now it can't launch.
 
 I'll reboot and try again later. (The reason I say it must have worked 
 is because I had a BP set in the project and don't remember it not 
 working at all)
 
 So maybe it is an issue with debug information in projects created in 
 previous versions of VS that are not translating debug information 
 correctly to newer projects?
 
 If you tried it on a fresh project maybe open up an old one and see. 
 (although I do think that the project I used was old but I heavily 
 modified it)
 
 Almost surely some type of memory access issue given the nature of the 
 crash.


Cannot reproduce with some sample projects, e.g. the Visual D istself or 
the D compiler. I suspect it depends on the variables being shown in the 
Locals/Auto Window.


 
 What happens when I place a breakpoint then run the program it does show 
 the code and the yellow arrow on top of the red BP disk and then it 
 shows the crash dialog about "The instruction at ... references memory 
 at .... The memory could not be written.".
 
 If I try to debug it then it opens up a new VS with the devenv.exe but 
 nothing really is going on and then if I click start debugging it will 
 run VS. If I open up the project then it says an exception is thrown 
 with "Exception thrown at .... (comctl32.dll) in devenv.exe: 
 0xC00000005: Access violation writing location ....
 
 It also says comctl32.pdb not loaded but not sure if that has anything 
 to do with it.
 
 Does any of this make any sense? Maybe the comctl32.dll is corrupted or 
 versioned wrong or something?


Hard to say without a full stack trace or dump. Missing symbols for the 
last release, please retry with the next one.
Jan 14 2022