Comes from doing foo!(Alias!([AliasSeq!(A,B,C)])) or just foo!(AliasSeq!(A,B,C)) when trying to pass a type for A, removing A works. A is a template parameter from another template.

Shouldn't the errors give line numbers and source code where the error ooccured rather than a bunch of rather useless information? I realize it is a fault but if it can spit out that info maybe it should keep track source code(the compilers).


ERROR: This is a compiler bug.
Please report it via https://issues.dlang.org/enter_bug.cgi
with, preferably, a reduced, reproducible example and the information below.
DustMite (https://github.com/CyberShadow/DustMite/wiki) can help with the reduction.
---
DMD v2.084.0

predefs   DigitalMars Windows CRuntime_Microsoft CppRuntime_Microsoft LittleEndian D_Version2 all D_InlineAsm D_InlineAsm_X86 X86 Win32 assert D_ModuleInfo D_Exceptions D_TypeInfo D_HardFloat
binary    C:\dmd2\windows\bin\dmd.exe
version   v2.084.0

config    C:\dmd2\windows\bin\sc.ini
DFLAGS    -IC:\dmd2\windows\bin\..\..\src\phobos -IC:\dmd2\windows\bin\..\..\src\druntime\import -L/OPT:NOICF
---

object.Error@(0): Access Violation
----------------
0x004E1B1D
0x006E4282

Please provide a minimal reproducing testcase. Bonus points if you can make it happen in https://run.dlang.io .

Also, consider following the instructions the compiler gave you that you pasted, and filing a bug via https://issues.dlang.org/enter_bug.cgi .

On Tuesday, 2 April 2019 at 12:35:18 UTC, Alex wrote:
> Comes from doing foo!(Alias!([AliasSeq!(A,B,C)])) or just foo!(AliasSeq!(A,B,C)) when trying to pass a type for A, removing A works. A is a template parameter from another template.
>
> Shouldn't the errors give line numbers and source code where the error occcured rather than a bunch of rather useless information? I realize it is a fault but if it can spit out that info maybe it should keep track source code(the compilers).

You need to use the debug build of the compiler to get the back trace with the stack of calls and their respective location the compiler source files. This build must be done by yourself.

If you don't want to open an issue in the bugtracker please at least provide a simple example that reproduce the crash. Also try to see if the crash still happens with the latest compiler version (beta 2.085.1 includes a dozen of compiler bugs leading to crashes fixed)

It's also a good idea to check the test case here https://run.dlang.io/is/DA3AnV, with the option to test with all the DMD versions.

Here the bug ultimately ends with an AV so there's chances that it's easy to fix, i.e just an unsafe access to check. If run.dlang.io indicates that it used to work than the history (a.k.a 'the git blame') could help a bit too.

On Tuesday, 2 April 2019 at 13:21:46 UTC, Basile B. wrote:
> On Tuesday, 2 April 2019 at 12:35:18 UTC, Alex wrote:
>> Comes from doing foo!(Alias!([AliasSeq!(A,B,C)])) or just foo!(AliasSeq!(A,B,C)) when trying to pass a type for A, removing A works. A is a template parameter from another template.
>>
>> Shouldn't the errors give line numbers and source code where the error occcured rather than a bunch of rather useless information? I realize it is a fault but if it can spit out that info maybe it should keep track source code(the compilers).
>
> You need to use the debug build of the compiler to get the back trace with the stack of calls and their respective location the compiler source files. This build must be done by yourself.
>
> If you don't want to open an issue in the bugtracker please at least provide a simple example that reproduce the crash. Also try to see if the crash still happens with the latest compiler version (beta 2.085.1 includes a dozen of compiler bugs leading to crashes fixed)
>
> It's also a good idea to check the test case here https://run.dlang.io/is/DA3AnV, with the option to test with all the DMD versions.
>
> Here the bug ultimately ends with an AV so there's chances that it's easy to fix, i.e just an unsafe access to check. If run.dlang.io indicates that it used to work than the history (a.k.a 'the git blame') could help a bit too.

Would it not be nice if dmd came with a debug compiler? Such as dmdd? That would make it real easy to help out better.

On Tuesday, 2 April 2019 at 13:24:51 UTC, Alex wrote:
> On Tuesday, 2 April 2019 at 13:21:46 UTC, Basile B. wrote:
>> [...]
>
> Would it not be nice if dmd came with a debug compiler? Such as dmdd? That would make it real easy to help out better.

With the debug infos the size of the distributions would increase.
Maybe as a secondary download.

On Tuesday, 2 April 2019 at 13:39:35 UTC, Basile B. wrote:
> On Tuesday, 2 April 2019 at 13:24:51 UTC, Alex wrote:
>> On Tuesday, 2 April 2019 at 13:21:46 UTC, Basile B. wrote:
>>> [...]
>>
>> Would it not be nice if dmd came with a debug compiler? Such as dmdd? That would make it real easy to help out better.
>
> With the debug infos the size of the distributions would increase.
> Maybe as a secondary download.

It's not that big already. Compared to some compilers.

On Tuesday, 2 April 2019 at 14:03:03 UTC, Alex wrote:
> On Tuesday, 2 April 2019 at 13:39:35 UTC, Basile B. wrote:
>> On Tuesday, 2 April 2019 at 13:24:51 UTC, Alex wrote:
>>> On Tuesday, 2 April 2019 at 13:21:46 UTC, Basile B. wrote:
>>>> [...]
>>>
>>> Would it not be nice if dmd came with a debug compiler? Such as dmdd? That would make it real easy to help out better.
>>
>> With the debug infos the size of the distributions would increase.
>> Maybe as a secondary download.
>
> It's not that big already. Compared to some compilers.

If you don't want to build DMD yourself, you can just use digger:

dub fetch digger
dub run digger

It's fully automated.
More Infos:

https://github.com/CyberShadow/Digger