[Issue 13880] nothrow @nogc std.algorithm.reduce on fixed-size arrays

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13880

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 13880] nothrow @nogc std.algorithm.reduce on fixed-size arrays

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13880

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/ab70319d692639d207665ec50be61110c7d850a1
Fix Issue 13880 - nothrow @nogc std.algorithm.reduce on fixed-size arrays

https://github.com/dlang/phobos/commit/25edf91761ec7a1dbe87933ea8d7f3621860163c
Merge pull request #6398 from wilzbach/fix-13880

Fix Issue 13880 - nothrow @nogc std.algorithm.reduce on fixed-size arrays

--

[Issue 12442] inefficient code with scope(exit)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12442

Basile B.  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||b2.t...@gmx.com
 Resolution|--- |FIXED

--- Comment #6 from Basile B.  ---
Nowadays with -O same code is generated, likely since quire recently
(https://forum.dlang.org/thread/ovbduq$m3a$1...@digitalmars.com).

--

[Issue 18731] Link only with druntime for the runnable tests if Phobos isn't needed

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18731

Seb  changed:

   What|Removed |Added

Summary|Link only druntime for the  |Link only with druntime for
   |runnable tests if Phobos|the runnable tests if
   |isn't needed|Phobos isn't needed

--

[Issue 18731] New: Link only druntime for the runnable tests if Phobos isn't needed

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18731

  Issue ID: 18731
   Summary: Link only druntime for the runnable tests if Phobos
isn't needed
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: bootcamp
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

All 1283 fail_compilation tests compile in ~11s on my machine.
The 774 compilable tests are slightly slower with ~25s ... and you don't want
to know how long runnable takes :/
So the runnable tests are the real bad boys.
(numbers are taken with an i7 4th Gen with full parallelism)

Now a majority of the tests doesn't even need Phobos, so a simple optimization
could be to only link druntime if nothing from Phobos is imported.
At the moment DRuntime has a size of 9.8M whereas Phobos clocks in with 64M
(including druntime).
So just using DRuntime would mean a lot less work for the linker.

At the moment this the linking is defined in `test/Makefile` like
`DFLAGS+=-defaultlib=libphobos2.so`, now in theory it would be as easy as
replacing this with `DFLAGS+=-defaultlib=libdruntime.so.a`, in practice more
work is required because it needs to be done only for the tests that don't use
Phobos (or all tests using Phobos need to be moved to Phobos)

--

[Issue 18235] Group logically similar tests into the same module in the D2 testsuite

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18235

--- Comment #1 from Seb  ---
Not saying anything about the logical grouping, but this is a bit exaggerated
imho:

> Each new file added to the testsuite may as well be adding 5 seconds onto the 
> overall runtime.  

_All_ 1283 fail_compilation tests compile in ~11s on my machine.
The 774 compilable tests are slightly slower with ~25s ... and you don't want
to know how long runnable takes :/
(of course the numbers are taken with full parallelism on an i7 4th Gen)

Anyhow, if someone wants to make the testsuite faster, the runnable tests are
the real bad boys and should be focussed on first.

--

[Issue 18718] ICE in dmd/traits.d:417

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18718

Seb  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17819

--

[Issue 17819] static foreach segfaults on __traits(allMembers)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17819

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=18718

--- Comment #4 from Seb  ---
Not really a fix, but a start https://github.com/dlang/dmd/pull/8125

--

[Issue 18717] Segfault in BitManip

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18717

ag0aep6g  changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #2 from ag0aep6g  ---
(In reply to Cédric Picard from comment #0)
> │   0x5558709cde70  0fa33e bt dword [rsi], edi  
> 
> 
> At that point we have:
> rsi = 0x7f40163e2010   -> our BitArray
> rdi = 0x97174d8b   -> "evilVal"

This is a codegen bug. It should be rdi in the bt instruction, not edi.

It's hard to find information on this, but this page says that the bt
instruction interprets the offset as signed:
. So rdi = 0x97174d8b becomes edi =
-1760080501. That's not intended, of course.

I've filed a new issue for the dmd bug: issue 18730. When that one gets fixed,
this one can be closed as a duplicate. Or thise one can be fixed by working
around the dmd bug in the BitArray code.

> A look at /proc/*/maps shows that the call falls into that section:
> 
> 0x7f40163e2000 # 0x7f4032928000 - usr 453.3M s -rw- unk1 unk1
> 
> IIUC this is what was allocated for our BitArray. However this isn't enough
> as 0x7f4032928000 - 0x7f40163e2000 < 2534886795.

You're comparing bytes to bits there. 2534886795 is the number of bits in the
array. That means, it needs ceil(2534886795 / 8) = 316860850 bytes. And that's
less than 0x7f4032928000 - 0x7f40163e2000.

--

[Issue 18730] New: dmd miscompiles core.bitop.bt with -O

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18730

  Issue ID: 18730
   Summary: dmd miscompiles core.bitop.bt with -O
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: wrong-code
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

Spin-off from issue 18717 which can be closed as a duplicate when this one gets
fixed.


void main()
{
enum bitsPerSizeT = size_t.sizeof * 8;
enum bitIndex = int.max + 1L;
auto a = new size_t[](bitIndex / bitsPerSizeT + 1);
bt(a.ptr, bitIndex);
}

/* Copied from core.bitop. */
int bt(in size_t* p, size_t bitnum) pure @system
{
static if (size_t.sizeof == 8)
return ((p[bitnum >> 6] & (1L << (bitnum & 63 != 0;
else static if (size_t.sizeof == 4)
return ((p[bitnum >> 5] & (1  << (bitnum & 31 != 0;
else
static assert(0);
}


Compile with `-O`. Resulting program segfaults.

Generated code for the bt function:


   0:   55  push   rbp
   1:   48 8b ecmovrbp,rsp
   4:   0f a3 3ebt DWORD PTR [rsi],edi
   7:   19 c0   sbbeax,eax
   9:   f7 d8   negeax
   b:   5d  poprbp
   c:   c3  ret


edi should be rdi in the bt instruction.

It's hard to find information on this, but this page says that bt interprets
the offset as signed: . That explains the
segfault, even though `bitIndex` fits into a uint.

--

[Issue 18715] Non-documented unittests should not use unpredictableSeed or default Random alias

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18715

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/c1d1c0e874b16fe2717e2c62b30c7c3f03e68446
Issue 18715 - Non-documented unittests should not use unpredictableSeed or
default Random alias

https://github.com/dlang/phobos/commit/c1fcea4fdfc4c1b56278c196dbd8908c34d8c11c
Merge pull request #6414 from n8sh/remove-unpredictableseed-from-unittests

Issue 18715 - Non-documented unittests should not use unpredictableSeed or
default Random alias
merged-on-behalf-of: Nathan Sashihara 

--

[Issue 18708] Flow analysis in constructors not done correctly for if, ||, &

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18708

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18708] Flow analysis in constructors not done correctly for if, ||, &

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18708

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/6cc2cd762eb8d147925a928d463cf76aa510e623
fix Issue 18708 - Flow analysis in constructors not done correctly for if, ||,
&&

https://github.com/dlang/dmd/commit/190e2e083df1c56ba6b19091a89da03f1e8fffc8
Merge pull request #8118 from WalterBright/fix18708

fix Issue 18708 - Flow analysis in constructors not done correctly fo…

--

[Issue 18729] New: dmd -run executes in different environment

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18729

  Issue ID: 18729
   Summary: dmd -run executes in different environment
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: johnnymar...@gmail.com

I ran into a problem where I was running a D program via dmd -run that itself
invoked DMD. The resulting program was invoking the compiler with -m64, but the
original dmd -run did not use -m64. This caused a problem because the first
invocation of the compiler set the LINKCMD environment variable to the OPTLINK
executable, which caused the second invocation to use the OPTLINK executable
but it treated it like the MSVC linker because it was running in 64-bit mode. 
You can reproduce this scenario on windows inside the dlang/tools repo by
running this:

dmd -run rdmd.d -m64 rdmd.d

OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
OPTLINK : Warning 9: Unknown Option : OUT
OPTLINK : Warning 9: Unknown Option : LIBPATH
OPTLINK : Warning 9: Unknown Option : LIBPATH
OPTLINK : Warning 9: Unknown Option : LIBPATH
C:\Users\Jonathan\AppData\Local\Temp\.rdmd\rdmd-rdmd.d-C379EA2E17BAC309A238EECC3E638589\objs\rdmd.exe.obj
Offset 0H Record Type 0064
 Error 138: Module or Dictionary corrupt
Error: linker exited with status 1

The solution here is to make sure that "dmd -run" maintain the original
environment during execution. 

PR: https://github.com/dlang/dmd/pull/8121

--

[Issue 18728] New: std.math.fdim does not handle nan correctly

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18728

  Issue ID: 18728
   Summary: std.math.fdim does not handle nan correctly
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

assert(fdim(real.nan, 2.0) == 0);

According to the C spec "If either argument is NaN, NaN is returned"

--

[Issue 18727] New: std.math.fmin does not handle nan correctly

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18727

  Issue ID: 18727
   Summary: std.math.fmin does not handle nan correctly
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

assert(fmin(2.0, real.nan) is real.nan);

According to the C spec

"If one of the two arguments is NaN, the value of the other argument is
returned. Only if both arguments are NaN, NaN is returned."

--

[Issue 18726] New: std.math.fma is not implemented

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18726

  Issue ID: 18726
   Summary: std.math.fma is not implemented
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

fma can be correctly implemented for doubles and floats on all platforms.

in core.math fmal is not correctly implemented for almost any platform. Mostly
it just casts the reals to doubles.

--

[Issue 18675] std.experimental.checkedint.Checked has opEquals but no toHash

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18675

--- Comment #2 from Jack Stouffer  ---
(In reply to vladvitan from comment #1)
> I want to work on this. Could you please give me a starting point for this?
> Should I use the toHash() functionality from druntime?

Yes, or you can use typeid(var).getHash().

You'll have to put this inside of a trusted lambda in order for it to be @safe.

The main thing you need to make sure is that it follows the logic of opEquals,
i.e. two things have the same hash according to opEquals' logic.

--

[Issue 18649] curl on Ubuntu 18.04 depends on libcurl4, .deb installer depends on libcurl3

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18649

--- Comment #8 from Alex Whitman  ---
I've given Martin's suggestion of using Recommends a go and it appears to work.
 The steps I took were:

- Purge existing dmd installation
- Upgrade curl, bringing in libcurl4, removing libcurl3
- Unpacked dmd_2.079.0-0_amd64.deb
- Edited the control file with the changes to the Depends section and added the
Recommends section.
- Repacked the .deb
- Installed the .deb

The installation worked but I don't have anything that uses std.net.curl to
test.

--

[Issue 18725] New: compiler does not check all levels of methods for privateness, if used in invariant

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18725

  Issue ID: 18725
   Summary: compiler does not check all levels of methods for
privateness, if used in invariant
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: sascha.or...@gmail.com

Given this

´´´
void main()
{
auto s = S(); 
assert();  
}

struct S
{
invariant
{
assert(fun); 
}

size_t[] member; 

private bool fun() const
{
return fun1(); 
}

/*private*/ bool fun1() const
{
return true; 
}
}
´´´

The code compiles with or without privateness of fun1. However, if the
privateness for fun1 is missing the run yields a segmentation fault, while when
it is present, the result is as expected. 

If privateness for fun is missing, the compiler complains about using it in the
invariant, as expected.

--

[Issue 14637] Array operations should work on tuples

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14637

--- Comment #7 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/cddd0df51a50e2c370162daa7ed7fca0dad4b979
Fix Issue 4591, 14637 - Array operations should work on tuples

https://github.com/dlang/phobos/commit/a62f6e3c81fe7996c6fc23223249660800ddd449
Merge pull request #6386 from wilzbach/fix-14637

Fix Issue 14637 - Array operations should work on tuples
merged-on-behalf-of: Jack Stouffer 

--

[Issue 4591] Concat of std.typecons.Tuples

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=4591

--- Comment #4 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/cddd0df51a50e2c370162daa7ed7fca0dad4b979
Fix Issue 4591, 14637 - Array operations should work on tuples

--

[Issue 4591] Concat of std.typecons.Tuples

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=4591

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--

[Issue 18136] ICE in dmd/statement.d(426)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18136

--- Comment #2 from Seb  ---
Reduced example without Phobos:


---
template ReturnType(func...)
{
static if (is(FunctionTypeOf!func R ))
alias ReturnType = R;
}

template FunctionTypeOf(func...)
{
static if (is(typeof(func) T))
static if (is(T Fptr ) )
alias FunctionTypeOf = Fptr;
}

enum isInputRange(R) =
is(ReturnType!((R r) => r.empty) )
&& is(typeof((R r) => r.popFront));


@property empty(T)(const(T) ){}


void popFront(T)(T) {}

template unaryFun(alias fun)
{
alias unaryFun = fun;
}

template map(fun...)
{
auto map(Range)(Range ) if (isInputRange!Range)
{
alias RE = Range;
alias _fun = unaryFun!fun;
!is(typeof(_fun(RE.init)) );
}
}

auto joiner(){}

struct RegexMatch(R)
{
void popFront(){}

bool empty() { }
}

auto matchMany(RegEx, R)(R , RegEx ) {
return RegexMatch!R();
}

auto matchAll(R, RegEx)(R input, RegEx re)
{
return matchMany(input, re);
}

void main()
{
string[] messages;

auto issueRE = "foo";
messages.map!(m => m.matchAll(issueRE).map);
}
---

--

[Issue 18675] std.experimental.checkedint.Checked has opEquals but no toHash

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18675

--- Comment #1 from vladvi...@gmail.com ---
I want to work on this. Could you please give me a starting point for this?
Should I use the toHash() functionality from druntime?

--

[Issue 18675] std.experimental.checkedint.Checked has opEquals but no toHash

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18675

vladvi...@gmail.com changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|vladvi...@gmail.com

--

[Issue 18675] std.experimental.checkedint.Checked has opEquals but no toHash

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18675

vladvi...@gmail.com changed:

   What|Removed |Added

 CC||vladvi...@gmail.com
  Alias||vlasebian

--

[Issue 18142] checkedint opOpAssign doesn't accept a checkedint

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18142

Andrei Vasile  changed:

   What|Removed |Added

 CC||andrei.vasil...@gmail.com
   Assignee|nob...@puremagic.com|andrei.vasil...@gmail.com

--

[Issue 18721] ICE in dmd/cond.d(378) when compiling static foreach with -D

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18721

Seb  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code

--- Comment #1 from Seb  ---
A first attempt - https://github.com/dlang/dmd/pull/8128

--

[Issue 18724] New: ICE in dmd/dsymbol.d(890)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18724

  Issue ID: 18724
   Summary: ICE in dmd/dsymbol.d(890)
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: ice
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

Reduced:

---
void main()
{
regex("foo");
}

auto regex(S)(S)
{
S pat;
if (__ctfe)
regexImpl(pat);
}

auto regexImpl(S)(S )
{
import bar ;
}
---

bar.d
---
void ()()
---


---
core.exception.AssertError@dmd/dsymbol.d(890): Assertion failure

??:? _d_assertp [0x1624c651]
??:? _ZN7Dsymbol10oneMembersEP5ArrayIPS_EPS1_P10Identifier [0x16087e48]
??:? _ZN22DsymbolSemanticVisitor5visitEP19TemplateDeclaration [0x16091671]
??:? _ZN19TemplateDeclaration6acceptEP7Visitor [0x1609f24c]
??:? _Z15dsymbolSemanticP7DsymbolP5Scope [0x1608b3d8]
??:? _ZN22DsymbolSemanticVisitor5visitEP6Module [0x1608fe18]
??:? _ZN6Module6acceptEP7Visitor [0x1607c690]
??:? _Z15dsymbolSemanticP7DsymbolP5Scope [0x1608b3d8]
??:? _ZN22DsymbolSemanticVisitor5visitEP6Import [0x1608e38e]
??:? _ZN6Import6acceptEP7Visitor [0x160637b1]
??:? _Z15dsymbolSemanticP7DsymbolP5Scope [0x1608b3d8]
??:? _ZN24StatementSemanticVisitor5visitEP15ImportStatement [0x161656e9]
??:? _ZN15ImportStatement6acceptEP7Visitor [0x16143428]
??:? _Z17statementSemanticP9StatementP5Scope [0x1615975a]
??:? _ZN24StatementSemanticVisitor5visitEP17CompoundStatement [0x16159aa1]
??:? _ZN17CompoundStatement6acceptEP7Visitor [0x1614073c]
??:? _Z17statementSemanticP9StatementP5Scope [0x1615975a]
??:? _ZN16Semantic3Visitor5visitEP15FuncDeclaration [0x1616c893]
??:? _ZN15FuncDeclaration6acceptEP7Visitor [0x160dea98]
??:? _Z9semantic3P7DsymbolP5Scope [0x1616b310]
??:? _ZN16Semantic3Visitor5visitEP16TemplateInstance [0x1616b47f]
??:? _ZN16TemplateInstance6acceptEP7Visitor [0x160aa890]
??:? _Z9semantic3P7DsymbolP5Scope [0x1616b310]
---

--

[Issue 18714] Phobos calls localtime, which is not threadsafe

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18714

FeepingCreature  changed:

   What|Removed |Added

   Severity|enhancement |normal

--

[Issue 18703] Ddoc Backticks inside macro dont work.

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18703

--- Comment #2 from ArturG  ---
this might be the same/similar issue:

$(DDOC_EXAMPLES
---
void fun(int){} // highlighted
$(FUN) // expanded but not highlighted
---
 )
MACROS:
FUN = void fun(int){}

--

[Issue 18130] ICE on zero-length `out` array parameter

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18130

Seb  changed:

   What|Removed |Added

   Keywords||pull
 CC||greensunn...@gmail.com
   Severity|normal  |critical

--- Comment #1 from Seb  ---
All ICEs are critical!

A simple PR that triggers an error instead of the ICE:

https://github.com/dlang/dmd/pull/8127

--

[Issue 17991] ICE with imports without module

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17991

Seb  changed:

   What|Removed |Added

   Keywords||ice, ice-on-valid-code,
   ||pull
 CC||greensunn...@gmail.com
   Severity|major   |critical

--- Comment #2 from Seb  ---
The "good" news - I can reproduce this:

mkdir -p a/b
touch a/b/package.d
touch a/b/c.d
mkdir -p a/e
touch a/e/f.d
echo "import a.b, a.b.c;" > a/e/f.d
dmddev a/e/f.d

Here's the segfault:

---
Program received signal SIGSEGV, Segmentation fault.
0x557de19c in ScopeDsymbol::addAccessiblePackage(Package*, Prot)
(this=0x77e9eba0, p=0x0, protection=...) at dmd/dsymbol.d:1491
1491if (pary.length <= p.tag)
#0  0x557de19c in ScopeDsymbol::addAccessiblePackage(Package*, Prot)
(this=0x77e9eba0, p=0x0, protection=...) at dmd/dsymbol.d:1491
#1  0x557e4076 in DsymbolSemanticVisitor::visit(Import*)
(this=0x7fffca40, imp=0x77e9f010) at dmd/dsymbolsem.d:1379
#2  0x557b57c7 in Import::accept(Visitor*) (this=0x77e9f010,
v=0x7fffca40) at dmd/dimport.d:309
#3  0x557e0dd1 in dsymbolSemantic(Dsymbol*, Scope*)
(dsym=0x77e9f010, sc=0x77e9f300) at dmd/dsymbolsem.d:343
#4  0x557e5e7e in DsymbolSemanticVisitor::visit(Module*)
(this=0x7fffcaf0, m=0x77e9eba0) at dmd/dsymbolsem.d:1916
#5  0x557d0916 in Module::accept(Visitor*) (this=0x77e9eba0,
v=0x7fffcaf0) at dmd/dmodule.d:1322
#6  0x557e0dd1 in dsymbolSemantic(Dsymbol*, Scope*)
(dsym=0x77e9eba0, sc=0x0) at dmd/dsymbolsem.d:343
#7  0x55873175 in dmd.mars.tryMain(ulong, const(char)**)
(argv=0x7fffd6a8, argc=2) at dmd/mars.d:804
#8  0x558744c7 in D main () at dmd/mars.d:1098
---

... and here an attempt to fix it: https://github.com/dlang/dmd/pull/8126

--