[Issue 16532] New: Add "namespace" Keyword?

2016-09-23 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16532

  Issue ID: 16532
   Summary: Add "namespace" Keyword?
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: gyroh...@gmail.com

Well namespaces are already implemented, but right now they are restricted to
modules. So a namespace can be created in the sense like this:


// file: other/package.d

import Name = other.modul;

// file: other/modul.d

module other.modul;

enum someConstant = 10;

// end -


so now it would be accessed like: Name.someConstant. This is fine but this
involves putting everything into separate files. So if you want different
namespaces that means making a bunch of different files, maybe sometimes even
having just a single "enum" inside of the file. being able to have them in one
file would be better and it is possible using structs as well.


struct Name
{
@disable this(); // bloat that shouldn't exist
@disable this(this);

enum someConstant = 10;
}
struct OtherName
{
@disable this();
@disable this(this);

enum moreConstant = 20;
}
struct EtcName
{
@disable this();
@disable this(this);

enum etcConstant = 000;
}


Even with the @disable it is still possible to declare a variable like so:

Name* ops; // shouldn't be possible

It also adds extra declarations like "Name.init" and "Name.sizeof" all of which
is not needed.

Really namespaces already exist in D, just they are very crudly implemented by
either meaning horrible to maintain with a bunch of extra module files or
through the use of structs. Adding namespaces would just be for sanity so that
code like above isn't possible and so that namespaces are treated as such. As
well adding namespace keyword will also help port from C++ if there is any code
that needs it. Just a thought for a small improvement.

--

[Issue 11657] Pass array literal to typesafe variadic argument on stack

2016-09-23 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=11657

--- Comment #4 from Martin Nowak  ---
(In reply to Martin Nowak from comment #3)
> Well the hole is called bug 5212 :).

issue 5212

--

[Issue 5212] no escape analysis for typesafe variadic function arguments

2016-09-23 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=5212

--- Comment #17 from Martin Nowak  ---
(In reply to Martin Nowak from comment #16)
> We should probably enforce (or automatically) add scope to typesafe variadic
> arguments.

I guess enforcing an explicit scope annotation would make the deprecation a bit
simpler, but not much.

--

[Issue 11135] Nullable(T, T nullValue) does not support NaN

2016-09-23 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=11135

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

https://github.com/dlang/phobos/commit/0efa1d3bf92bcaa6c4a99cad0b574185a537906a
workaround for bug 11135 (typecons.Nullable)

https://github.com/dlang/phobos/commit/bf14b1897e62f996cfbf8fc99dae9cf3476b3dfc
Merge pull request #3797 from Cauterite/issue11135

Issue 11135 - Nullable(T, T nullValue) does not support NaN

--

[Issue 16531] Protected members not accessible in delegate bodies

2016-09-23 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16531

--- Comment #1 from John Chapman  ---
Forgot crucial detail that the error appears when Label is defined in a
separate module from Control.

--

[Issue 16531] New: Protected members not accessible in delegate bodies

2016-09-23 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16531

  Issue ID: 16531
   Summary: Protected members not accessible in delegate bodies
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: johnch_a...@hotmail.com

DMD reports an error when trying to call the protected method of a superclass
from inside the body of a delegate. Code to repro:

void layoutTransaction(void delegate() action) {
  action();
}

class Control {
  protected void onTextChanged() {}
}

class Label : Control {
  protected override void onTextChanged() {
layoutTransaction({
  super.onTextChanged();
});
  }
}

Output: class Control member onTextChanged is not accessible.

I think protected methods should be allowed to be called in this way. Note that
private methods do seem to be accessible.

--

[Issue 16528] @safe inference does not work for mutually recursive functions

2016-09-23 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16528

Lodovico Giaretta  changed:

   What|Removed |Added

 CC||lodov...@giaretart.net

--- Comment #2 from Lodovico Giaretta  ---
Disclaimer: I don't know anything about DMD internals.

It looks like currently, in case of mutual recursion, the compiler takes the
pessimistic approach and does not infer any attribute. This is too
conservative. It is possible to devise an inference algorithm that
optimistically assumes functions to have all attributes, and progressively
removes them as needed.

Cycles due to mutual recursion can be arbitrarily complex, with many functions,
but the informations gathered during instantiation are enough to identify the
entire set of those functions. Then the compiler infers the safety of each of
those function separately, without taking into account call instructions to
other functions of the same recursion set. If this process identifies a
function that does not have a specific attribute, than no function in the set
has that attribute. Otherwise, all functions in the set have it.

I didn't reason that much about the above algorithm, but I'm under the
impression that it works in all cases and is also quite easy to understand and
implement.

--

[Issue 16530] New: -O -cov interaction leads to wrong codegen

2016-09-23 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16530

  Issue ID: 16530
   Summary: -O -cov interaction leads to wrong codegen
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

Code:

double entropy(double[] probs)
{
double result = 0;
// BUG: remove the "ref" below to expose codegen bug in dmd
foreach (p; probs)
{
if (!p) continue;
import std.math : log2;
result -= p * log2(p);
}
return result;
}

void main()
{
import std.stdio;
writeln(entropy([1.0, 0, 0]));
}

To repro, build with -O -cov. It will print -nan. Should print 0.

--

[Issue 16528] @safe inference does not work for mutually recursive functions

2016-09-23 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16528

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com

--- Comment #1 from John Colvin  ---
Ok so this is absolutely hideous and there is definitely something weird going
on with the compiler in this region, but I *think* the following works as
expected. There is probably an adaption of this that can be made simpler, but I
don't have time to find it right now.

template fun1Wrap(T)
{
enum foo = q{
void impl(T value) %s
{
if (value) fun2%s(value - 1);
}
};
import std.format : format;
static if(__traits(compiles, { mixin(format(foo, `@safe`, `Safe`)); }))
mixin(format(foo, `@safe`, `Safe`));
else
mixin(foo);
}

void fun1Safe(T)(T t) @safe
{
fun1Wrap!T.impl(t);
}

void fun1(T)(T t)
{
static if (__traits(compiles, fun1Safe(t) ))
fun1Safe(t);
else
fun1Wrap!T.impl(t);
}

template fun2Wrap(T)
{
enum foo = q{%s void impl(T value)
{
if (value) fun1%s(value - 1);
}
};
import std.format : format;
static if(__traits(compiles, { mixin(format(foo, `@safe`, `Safe`)); }))
mixin(format(foo, `@safe`, `Safe`));
else
mixin(foo);
}

void fun2Safe(T)(T t) @safe
{
fun2Wrap!T.impl(t);
}

void fun2(T)(T t)
{
static if (__traits(compiles, fun1Safe(t) ))
fun2Safe(t);
else
fun2Wrap!T.impl(t);
}

@safe void main()
{
fun1(4);
}

--

[Issue 16529] New: string mixins break ifti

2016-09-23 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16529

  Issue ID: 16529
   Summary: string mixins break ifti
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: john.loughran.col...@gmail.com

template foo(T)
{
mixin(`void foo(T t) {}`);
}

template bar(T)
{
void bar(T t) {}
}

void main()
{
foo(3); // fails
// ifti.d(13): Error: template ifti.foo cannot deduce function from
argument types !()(int), candidates are:
// ifti.d(1):ifti.foo(T)

bar(3); // OK
}

--

[Issue 16517] topN performance very poor on certain data sets

2016-09-23 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16517

--- Comment #2 from Andrei Alexandrescu  ---
More measurements:

$ cut -f 3  /tmp/googlebooks-eng-all-1gram-20120701-0 | ./median_by_sort
median (via sort): 3; lines: 10512769; total time (ms): 2046; sort time (ms):
408
$ cut -f 3  /tmp/googlebooks-eng-all-1gram-20120701-0 | ./median_by_topn
median (via topN): 3; lines: 10512769; total time (ms): 1330; topN time (ms):
64
$ cut -f 4  /tmp/googlebooks-eng-all-1gram-20120701-0 | ./median_by_sort
median (via sort): 2; lines: 10512769; total time (ms): 1964; sort time (ms):
376
$ cut -f 4  /tmp/googlebooks-eng-all-1gram-20120701-0 | ./median_by_topn
median (via topN): 2; lines: 10512769; total time (ms): 1549; topN time (ms):
78

--

[Issue 16517] topN performance very poor on certain data sets

2016-09-23 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16517

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #1 from Andrei Alexandrescu  ---
I don't have a ldc testing rig installed, but with
https://github.com/dlang/phobos/pull/4815 and dmd I get the following for your
code and data:

$ dmd -O -inline -release -ofmedian_by_topn -boundscheck=off -version=topn
issue16517.d 
$ dmd -O -inline -release -ofmedian_by_sort -boundscheck=off issue16517.d  
$ cut -f 2  /tmp/googlebooks-eng-all-1gram-20120701-0 | ./median_by_sort
median (via sort): 1972; lines: 10512769; total time (ms): 2246; sort time
(ms): 412
$ cut -f 2  /tmp/googlebooks-eng-all-1gram-20120701-0 | ./median_by_topn
median (via topN): 1972; lines: 10512769; total time (ms): 1823; topN time
(ms): 35

Although results obtained using dmd are not comparable, the trend is
encouraging. If you could patch your stdlib with the pull request it would be
great. Thanks!

--

[Issue 16528] New: @safe inference does not work for mutually recursive functions

2016-09-23 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16528

  Issue ID: 16528
   Summary: @safe inference does not work for mutually recursive
functions
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

Consider:

void fun1(T)(T value)
{
if (value) fun2(value - 1);
}

void fun2(T)(T value)
{
if (value) fun1(value - 1);
}

@safe void main()
{
fun1(4);
}

This fails to compile although obviously the functions are safe. I'm looking
for a reasonable workaround for the topN work. This doesn't work either:

void fun1(T)(T value)
{
if (value) fun2(value - 1);
}

void fun2(T)(T value)
{
if (value) () @trusted { fun1(value - 1); }();
}

@safe void main()
{
fun1(4);
}

--

[Issue 16527] New: extern( C++ ) Win64 build - return struct by value is broken

2016-09-23 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16527

  Issue ID: 16527
   Summary: extern( C++ ) Win64 build - return struct by value is
broken
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: goober...@gmail.com

DMD 2.071.2, Windows, 64-bit output.

The this pointer should be always stored in RCX, but the functions I'm using
where structs are being returned by value switch the return address from RDX
with RCX.

While I'm actually using raw C++ functions through Binderoo, this is actually
quite reproducible with D code that extern( C++ )'s its functions.

Marking as blocker as there's a ridiculous number of functions we bind to that
return structs by value that are just unusable.

Code as follows:

module thismodule;

import std.stdio;
import std.conv;

align( 16 ) struct SomeCommonStruct
{
float valA = 0;
float valB = 0;
float valC = 0;
float valD = 0;
}

struct SomeObject
{
void doAThing()
{
SomeWrapper aWrapper;

SomeCommonStruct structThing = aWrapper.callme(  );

writeln( to!string( structThing.valD ) );
}

}

extern( C++ ) struct SomeWrapper
{
SomeCommonStruct giveMeACommonStruct( SomeObject* pObject )
{
return structeroo;
}

SomeCommonStruct structeroo = SomeCommonStruct( 1, 0, 3, 4 );

alias FnType = extern( C++ ) SomeCommonStruct function( SomeWrapper* );

__gshared extern( C++ ) SomeCommonStruct function( SomeWrapper* ) callme;
}

int main(string[] argv)
{
SomeWrapper.callme = cast( SomeWrapper.FnType
)cast(void*)

SomeObject someObject;
someObject.doAThing();

return 0;
}

Expected: function SomeObject.doAThing writes the value "4" to stdout
Actual: function SomeObject.doAThing writes rubbish to stdout

--

[Issue 15939] GC.collect causes deadlock in multi-threaded environment

2016-09-23 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15939

--- Comment #25 from Martin Nowak  ---
(In reply to Aleksei Preobrazhenskii from comment #24)
> Since I changed signals to real-time and migrated to recent kernel I haven't
> seen that issue in the release builds, however, I tried running profile
> build recently (unfortunately I only did it for the old kernel) and it was
> consistently stuck every time.

Thanks, good to hear from you.

There is a chance that these are kernel bugs fixed in 3.10
https://github.com/torvalds/linux/commit/b0c29f79ecea0b6fbcefc999e70f2843ae8306db
and 3.18
https://github.com/torvalds/linux/commit/76835b0ebf8a7fe85beb03c75121419a7dec52f0.

--