[Issue 16011] [REG2.068] recursive RefCounted used to work

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16011

--- Comment #4 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7196

--

[Issue 17883] Error: undefined identifier: Static if bodies depend on order of declarations

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17883

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 16011] [REG2.068] recursive RefCounted used to work

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16011

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #3 from Walter Bright  ---
Compiling this now gives the following error:

core.exception.AssertError@dstruct.d(380): Assertion failure

0x005FD23F in _d_assertp
0x00408EFA in AttribDeclaration at C:\cbx\mars\attrib.d(181)
0x0045F5D7 in StructDeclaration at C:\cbx\mars\dstruct.d(373)
0x0045F5D7 in StructDeclaration at C:\cbx\mars\dstruct.d(373)
0x00474D79 in TemplateInstance at C:\cbx\mars\dtemplate.d(8272)
0x00474DDC in TemplateInstance at C:\cbx\mars\dtemplate.d(8290)
0x00470E61 in TemplateInstance at C:\cbx\mars\dtemplate.d(6361)
0x004714BB in TemplateInstance at C:\cbx\mars\dtemplate.d(6595)
0x004ECA1E in TypeInstance at C:\cbx\mars\mtype.d(8004)
0x004ECAE2 in TypeInstance at C:\cbx\mars\mtype.d(8027)
0x00434BE8 in VarDeclaration at C:\cbx\mars\declaration.d(1180)
0x0045F5D7 in StructDeclaration at C:\cbx\mars\dstruct.d(373)
0x00454D54 in Module at C:\cbx\mars\dmodule.d(1065)
0x004D9F9F in int ddmd.mars.tryMain(uint, const(char)**) at
C:\cbx\mars\mars.d(847)
0x004DAB43 in _Dmain at C:\cbx\mars\mars.d(1086)
0x005FF73B in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFNlZv
0x005FF6FF in scope void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll()
0x005FF600 in _d_run_main
0x004DCDD8 in main at C:\cbx\mars\root\stringtable.d(7)
0x0061B245 in mainCRTStartup
0x74F3336A in BaseThreadInitThunk
0x77359902 in RtlInitializeExceptionChain
0x773598D5 in RtlInitializeExceptionChain

It appears to be a forward reference error. The code itself cannot work because
RefCounted stores an instance of S in itself, and a struct cannot have itself
as a field. In fact, the same error occurs with the following example:

  struct RefCounted {
S s;
  }

  struct S {
int x;
RefCounted s;
  }

--

[Issue 15985] [REG2.068/2.069] Code doesn't link unless compiled with -debug

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15985

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #3 from Walter Bright  ---
Reduced it a bit to:

struct S()
{
void delegate() d;
}

S!() f_Ds(U)()
{
static if (is(U == struct))
return S!()
(
{
foreach (i, field; U.init.tupleof)
f_Ds!(typeof(field))();
}
);

else
return f_Ds!(D)();
}

void f_E()
{
auto f = S!()
(
{
enum x = is(typeof(f_Ds!(D*)()));
f_Ds!(D*)();
}
);
}

struct A
{
D* d;
}

struct D
{
A a;
int b;
}

void main()
{
f_E();
f_Ds!(D*)();
}

--

[Issue 17884] fwd reference leads to dmd assert failure

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17884

Walter Bright  changed:

   What|Removed |Added

   Keywords||ice

--

[Issue 17884] New: fwd reference leads to dmd assert failure

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17884

  Issue ID: 17884
   Summary: fwd reference leads to dmd assert failure
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

struct S()
{
void delegate() d;
}

S!() f_Ds(U)()
{
pragma(msg,U);
static if (is(U == struct))
return S!()
(
{
foreach (i, field; U.init.tupleof)
f_Ds!(typeof(field))();
}
);

else
return f_Ds!(D)();
}

void f_E()
{
auto f = S!()
(
{
enum x = is(typeof(f_Ds!(D*)()));
f_Ds!(D*)();
}
);
}

struct A
{
D d;
}

struct D
{
A a;
int b;
}

void main()
{
f_E();
f_Ds!(D*)();
}
---
dmd bug
bug.d(40): Error: struct bug.A no size because of forward reference

core.exception.AssertError@dstruct.d(380): Assertion failure

0x005FD23F in _d_assertp
0x0040477A in AggregateDeclaration at C:\cbx\mars\aggregate.d(339)
0x00404890 in AggregateDeclaration at C:\cbx\mars\aggregate.d(377)
0x004EE4E0 in TypeStruct at C:\cbx\mars\mtype.d(8662)
0x00434C64 in VarDeclaration at C:\cbx\mars\declaration.d(1199)
0x0045F5D7 in StructDeclaration at C:\cbx\mars\dstruct.d(373)
0x00454D54 in Module at C:\cbx\mars\dmodule.d(1065)
0x004D9F9F in int ddmd.mars.tryMain(uint, const(char)**) at
C:\cbx\mars\mars.d(847)
0x004DAB43 in _Dmain at C:\cbx\mars\mars.d(1086)
0x005FF73B in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFNlZv
0x005FF6FF in scope void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll()
0x005FF600 in _d_run_main
0x004DCDD8 in main at C:\cbx\mars\root\stringtable.d(7)
0x0061B245 in mainCRTStartup
0x74F3336A in BaseThreadInitThunk
0x77359902 in RtlInitializeExceptionChain
0x773598D5 in RtlInitializeExceptionChain

--

[Issue 16100] [REG 2.069] Error with -O of struct enumeration value and comma operator

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16100

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #3 from Walter Bright  ---
I cannot reproduce this problem.

--

[Issue 17883] Error: undefined identifier: Static if bodies depend on order of declarations

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17883

Iain Buclaw  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||ibuc...@gdcproject.org

--

[Issue 17883] New: Error: undefined identifier: Static if bodies depend on order of declarations

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17883

  Issue ID: 17883
   Summary: Error: undefined identifier: Static if bodies depend
on order of declarations
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ibuc...@gdcproject.org

This does not compile:
---
public import core.sys.posix.sys.mman;
import core.sys.linux.config;

static if (__USE_MISC)
{
enum MAP_RENAME = MAP_ANONYMOUS;
}

static if (__USE_MISC)
{
enum MAP_ANONYMOUS = MAP_ANON;
}
---

Swapping the static ifs around, however, and it does.

This is particular bug is causing SPARC, SPARC64, MIPS and MIPS64 builds to
fail.

--

[Issue 16984] Make more modules runnable on dlang.org

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16984

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

https://github.com/dlang/phobos/commit/2e96d0654bb7146d40f71697c66a8fa6826440ee
Issue 16984 - Make std.math runnable

https://github.com/dlang/phobos/commit/c2d03bf75492c9141026fc58db865e5e0ca4d5e8
Issue 16984 - Make std.stdio runnable

https://github.com/dlang/phobos/commit/3cc63005e1bb05fdf78fd3017c1d9eb3c41705cc
Issue 16984 - Make std.traits runnable

https://github.com/dlang/phobos/commit/ff6c0f1dfc2405b4d0f92d08079d390fc4cc14a0
Issue 16984 - Make stdx.allocator.building_blocks.quantizer runnable

https://github.com/dlang/phobos/commit/5a20f69160443a17a0fbc1abe2e676b60e5485d2
Issue 16984 - Make stdx.allocator.building_blocks.free_list runnable

https://github.com/dlang/phobos/commit/d661120ff3bef457f1e9413965ebef3dd3f14fff
Fix Issue 16984 - Remove runnable blacklist

--

[Issue 17798] [2.076] "static foreach" not documented

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17798

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

https://github.com/dlang/dlang.org/commit/4caec8e66773560bef9e2f9df1f11c4b1e5378df
fix Issue 17798 - [2.076] "static foreach" not documented

https://github.com/dlang/dlang.org/commit/c190c0c29c3f1bd733936f94b69ec56548c33ce3
Merge pull request #1884 from tgehr/fix17798

fix Issue 17798 - [2.076] "static foreach" not documented
merged-on-behalf-of: Petar Kirov 

--

[Issue 17190] [REG2.072] isNumeric!string conflict std.traits std.string

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17190

--- Comment #3 from Jonathan M Davis  ---
https://github.com/dlang/phobos/pull/5763

--

[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17326

--- Comment #7 from Rainer Schuetze  ---
Benjamin Thaut has prototyped it and showed it at Dconf
http://dconf.org/2016/talks/thaut.html. 
Development seems to have stalled at the moment, though. Latest version should
be this: https://github.com/Ingrater/dmd/tree/DllSupportD2

--

[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17326

werero...@gmail.com changed:

   What|Removed |Added

 CC||werero...@gmail.com

--- Comment #6 from werero...@gmail.com ---
I'd be lovely to have a doc on how it should be used in the complex cases - if
it works at all :/

--

[Issue 17619] [REG2.072] Wrong debug line information with single line loops

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17619

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

   What|Removed |Added

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

--

[Issue 17619] [REG2.072] Wrong debug line information with single line loops

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17619

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

https://github.com/dlang/dmd/commit/056160d108df108d99783b77ea5b9e0b04a9d592
fix issue 17619: for statements without curly braces, default endloc to
location of last token, not next token

https://github.com/dlang/dmd/commit/64fda491f77ca98a1814dd20e7be917c1c767369
Merge pull request #7189 from rainers/fix_17619

 fix issue 17619:  [REG2.072] Wrong debug line information with single line
loops
merged-on-behalf-of: Walter Bright 

--

[Issue 17870] recursive template "T is nested in both"

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17870

bitwise  changed:

   What|Removed |Added

 CC||nicolas.jincher...@gmail.co
   ||m

--

[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17326

--- Comment #5 from Rainer Schuetze  ---
That's why I've been saying for years that
https://wiki.dlang.org/Win32_DLLs_in_D#D_code_calling_D_code_in_DLLs needs a
big red warning that it doesn't work but in very simple cases.

--

[Issue 17864] POD struct not equivalent to primitive type in comparison

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17864

bitwise  changed:

   What|Removed |Added

 CC|nicolas.jincher...@gmail.co |
   |m   |

--

[Issue 17864] POD struct not equivalent to primitive type in comparison

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17864

bitwise  changed:

   What|Removed |Added

 CC||nicolas.jincher...@gmail.co
   ||m

--

[Issue 17824] wrong visibility deduced for method

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17824

bitwise  changed:

   What|Removed |Added

 CC||nicolas.jincher...@gmail.co
   ||m

--

[Issue 17865] property/non-property overloads not detected until used

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17865

bitwise  changed:

   What|Removed |Added

 CC||nicolas.jincher...@gmail.co
   ||m

--

[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17326

--- Comment #4 from Walter Bright  ---
Coming up again:

http://www.digitalmars.com/d/archives/digitalmars/D/learn/DLL_hell_S_96980.html

--

[Issue 17559] [REG2.073.0] Wrong line number in stack trace

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17559

Rainer Schuetze  changed:

   What|Removed |Added

   Keywords||pull, symdeb

--- Comment #7 from Rainer Schuetze  ---
https://github.com/dlang/dmd/pull/6947

--

[Issue 6244] Add powmod / modpow function to std.math

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=6244

alex.jercai...@gmail.com changed:

   What|Removed |Added

 CC||alex.jercai...@gmail.com
   Assignee|nob...@puremagic.com|alex.jercai...@gmail.com

--

[Issue 17882] [The D Style] unittest attributes

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17882

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from b2.t...@gmx.com ---
(In reply to Mario Kroeplin from comment #3)
> (In reply to b2.temp from comment #2)
> 
> The issue is just the wording of the guideline:
> "to ensure the existence of attributes on the templated function":
> which "templated function"?

in the example it's "call2". Maybe if you're not comfy enough with D try 

https://forum.dlang.org/group/learn

before opening an issue.

--

[Issue 17881] Provide mechanism to preallocate memory from the GC

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17881

--- Comment #6 from Steven Schveighoffer  ---
(In reply to Rainer Schuetze from comment #5)
> A slightly simpler API could be to add allocating N same-sized chunks from
> the GC that returns them in a free-list-like chain.

I think an array is best, since the data already is an array, and a free-list
requires building a linked list before-hand.

> I agree with Andrei that we should not complicate the GC interface for every
> possible allocation pattern a user might want to optimize for, though.

Hm... I'm trying to find the most generic interface for this. It's not
necessarily limited to AA, as allocating a bunch of blocks in a loop isn't an
uncommon thing.

If there was a way to "re-flavor" the blocks from one giant block into
individual ones, then we could do this outside the GC.

> If you call GC.reserve(20_000_000*(Key.sizeof+Value.sizeof)) before
> inserting elements, there should be no collection while filling the AA.

Limiting the collection in the example I posted shaves off about 300-400msec,
but it still is 1.5 seconds vs. 0.1 for the local array version.

> If we add thread local free-lists to the GC, the overhead of allocating
> these from the GC instead of caching them in the AA would be rather small.

Agreed, I think keeping the lists inside the GC is the most useful, and does
not expose any implementation details to the user.

--

[Issue 17882] [The D Style] unittest attributes

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17882

Mario Kroeplin  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #3 from Mario Kroeplin  ---
(In reply to b2.temp from comment #2)

The issue is just the wording of the guideline:
"to ensure the existence of attributes on the templated function":
which "templated function"?

--

[Issue 17882] [The D Style] unittest attributes

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17882

--- Comment #2 from b2.t...@gmx.com ---
to be perfectly clear about the invalidity, see:

https://dlang.org/spec/function.html#function-attribute-inference


void call1 () @safe{} // non templatized so no attrib inference
void call2 ()(){} // attrib infered by the caller

@safe unittest
{
  // everything inside **must** be safe or trused.
  call1();
  call2();
}

//is like

void test() @safe
{
  call1();
  call2(); // @safe is infered on call2, so that if not supported compil stops.
}

--

[Issue 17619] [REG2.072] Wrong debug line information with single line loops

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17619

Rainer Schuetze  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #6 from Rainer Schuetze  ---
https://github.com/dlang/dmd/pull/7189

--

[Issue 17882] [The D Style] unittest attributes

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17882

b2.t...@gmx.com changed:

   What|Removed |Added

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

--- Comment #1 from b2.t...@gmx.com ---
attributes of the unittest blocks are tried on the free functions that are used
inside. Actually you can see a unittest{} as a function itself. (the
getunittests traits returns some void function()).

--

[Issue 17882] New: [The D Style] unittest attributes

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17882

  Issue ID: 17882
   Summary: [The D Style] unittest attributes
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: kroepli...@googlemail.com

"Every unittest should be annotated (e.g. pure nothrow @nogc @safe unittest {
... }) to ensure the existence of attributes on the templated function."

But, templated functions should not be annotated. So, do you mean "... on a
non-templated function"? Or maybe "... on the tested function"?

--

[Issue 17635] [REG 2.066.0] cannot convert unique immutable(int)** to immutable

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17635

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #9 from ag0ae...@gmail.com ---
The original test case has been fixed, but it can be made to fail again by
changing the parameter type slightly. As far as I can tell, the parameter type
shouldn't matter, as long as it's not mutable.


alias T = immutable int;

T** f(I)(const I input) pure
{
T** output;
return output;
}

void main()
{
/* Not regressions in 2.066 (i.e. 2.065 also rejected these): */

T*** a1;
immutable T** r1 = f(a1);

static struct S2 { T* foo; }
S2* a2;
immutable T** r2 = f(a2);

/* But this one compiles with 2.065, so it's another regression: */

static struct S3 { T foo; }
S3* a3;
immutable T** r3 = f(a3);
}


Tested with DMD64 D Compiler v2.076.1-b1-166-g2f98e66e5.

Reopening. Let me know if I should file a new issue (or multiple ones) instead.

--

[Issue 15538] [REG 2.064] wrong code with switch

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15538

--- Comment #12 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7188

--

[Issue 15538] [REG 2.064] wrong code with switch

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15538

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com
 OS|Linux   |All

--- Comment #11 from Walter Bright  ---
Happens on Win64 too.

--

[Issue 17881] Provide mechanism to preallocate memory from the GC

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17881

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #5 from Rainer Schuetze  ---
A slightly simpler API could be to add allocating N same-sized chunks from the
GC that returns them in a free-list-like chain.

I agree with Andrei that we should not complicate the GC interface for every
possible allocation pattern a user might want to optimize for, though.

If you call GC.reserve(20_000_000*(Key.sizeof+Value.sizeof)) before inserting
elements, there should be no collection while filling the AA.

If we add thread local free-lists to the GC, the overhead of allocating these
from the GC instead of caching them in the AA would be rather small.

--