[Issue 16072] New: std.container.binaryheap should be extendable for arrays

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16072

  Issue ID: 16072
   Summary: std.container.binaryheap should be extendable for
arrays
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

I don't see any reason why the following shouldn't work:

import std.container.binaryheap;
auto q = heapify!"a > b"([1, 4, 5]);
q.insert(2);

--

[Issue 16071] New: Source file path and module name should match exactly

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16071

  Issue ID: 16071
   Summary: Source file path and module name should match exactly
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: pro.mathias.l...@gmail.com

Extract from https://dlang.org/spec/module.html :

```
The Identifiers preceding the rightmost are the Packages that the module is in.
The packages correspond to directory names in the source file path. Package
names cannot be keywords, hence the corresponding directory names cannot be
keywords, either. 
```

According to this definition, one cannot use a different name for the enclosing
directory, nor can one introduce virtual package namespace, e.g. :

src/foo/bar.d -> module hello.world.bar;

However this is currently allowed. Using this kind of scheme breaks separated
compilation badly, as the compiler rely on the module name for import. However,
if the module is provided via command line, the compiler will first
'importAll', and the bug won't be visible.

Even worst, the module declaration is ignored and the path is preferred in some
cases, not others:

 Import using the path 
`src/main.d -> module main; import foo.bar;`
Separate compilation: `dmd -c -o- -Isrc src/main.d` => Works
All at once : `dmd -c -o- src/main.d src/foo/bar.d` => Doesn't work


 Import using the given name 
`src/main.d -> module main; import hello.world.bar;`
Separate compilation: `dmd -c -o- -Isrc src/main.d` => Doesn't work
All at once : `dmd -c -o- src/main.d src/foo/bar.d` => Works

In addition, the specs provides the possibility to rename a file name with an
invalid identifier (e.g. `foo-bar.d` -> `module foo_bar;`), and that suffers
from the same problems.

Even DMD is affected by this, as files are e.g. `src/mars.d` but the module
name is `ddmd.mars`.

--

[Issue 15941] [REG v2.069] rbtree no longer supports classes

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15941

Steven Schveighoffer  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #3 from Steven Schveighoffer  ---
PR: https://github.com/dlang/phobos/pull/4353

Note, this will be fixed in stable, since this is a regression.

--

[Issue 16063] DLL projects seem to ignore DllMain, won't link

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16063

Rainer Schuetze  changed:

   What|Removed |Added

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

--- Comment #2 from Rainer Schuetze  ---
I noticed this too recently. This only happens when using the MS linker (also
for 32-bit DLLs), not with optlink.

--

[Issue 16070] std.meta.{ApplyLeft,ApplyRight} fail with mixed type/value arguments

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16070

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from ag0ae...@gmail.com ---
https://github.com/dlang/phobos/pull/4352

--

[Issue 16070] New: std.meta.{ApplyLeft,ApplyRight} fail with mixed type/value arguments

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16070

  Issue ID: 16070
   Summary: std.meta.{ApplyLeft,ApplyRight} fail with mixed
type/value arguments
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

Should work:

alias Templ(T, string name) = AliasSeq!(T, name);

alias PartialL = ApplyLeft!(Templ, int);
alias FullL = PartialL!"foo";

static assert(is(FullL[0] == int));
static assert(FullL[1] == "foo");

alias PartialR = ApplyRight!(Templ, "bar");
alias FullR = PartialR!int;

static assert(is(FullR[0] == int));
static assert(FullR[1] == "bar");


--

[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15925

--- Comment #7 from Dicebot  ---
What about public imports? Previously you have stated that mixins should be
viewed identical to imports when it comes to symbol visibility/access but that
would be not true if public ones are not propagated.

--

[Issue 15941] [REG v2.069] rbtree no longer supports classes

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15941

Steven Schveighoffer  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|schvei...@yahoo.com

--- Comment #2 from Steven Schveighoffer  ---
This is really a problem with Object.toString not working by default for const
objects. I will try and make code that optionally adds toString if it can
toString each element, this should work once we fix the issue with Object.

--

[Issue 16064] std.experimental.allocator.dispose can't be used in @nogc blocks

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16064

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

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|nob...@puremagic.com|b2.t...@gmx.com

--

[Issue 16069] New: std.regex.splitter should accept any random access range with slicing

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16069

  Issue ID: 16069
   Summary: std.regex.splitter should accept any random access
range with slicing
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

Currently it rejects string.byCodeUnit. I singled out splitter because I know
for a fact that that function doesn't need strings.

--

[Issue 9149] Disallow converting delegates to const

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=9149

--- Comment #5 from timon.g...@gmx.ch ---
(In reply to timon.gehr from comment #4)
> (In reply to Sobirari Muhomori from comment #3)
> > How about this?
> > 
> > class A
> > {
> > int i;
> > const void delegate() dg;
> > this() pure { dg= }
> > void f(){ i++; }
> > }
> > 
> > unittest
> > {
> > const A a = new A;
> > a.dg();
> > }
> 
> The assignment in the constructor shouldn't compile.

And indeed, DMD rejects the assignment.

--

[Issue 9149] Disallow converting delegates to const

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=9149

--- Comment #4 from timon.g...@gmx.ch ---
(In reply to Sobirari Muhomori from comment #3)
> How about this?
> 
> class A
> {
>   int i;
>   const void delegate() dg;
>   this() pure { dg= }
>   void f(){ i++; }
> }
> 
> unittest
> {
>   const A a = new A;
>   a.dg();
> }

The assignment in the constructor shouldn't compile.

--

[Issue 16068] New: DDoc sections have serious design issues

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16068

  Issue ID: 16068
   Summary: DDoc sections have serious design issues
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: leandro.lucare...@sociomantic.com

Created attachment 1598
  --> https://issues.dlang.org/attachment.cgi?id=1598=edit
DDoc output

I don't want to make a full rant about DDoc (although I think is to D what the
D preprocessor is to C/C++).

I found a very fundamental problem. According to how sections are parsed, you
can accidentally build new unintended sections just by formatting your
paragraphs.

For example:
---
The contains() function is more convenient for trivial lookup
cases:
---
if (contains ("fubar", '!'))
...
---
---

This is a real example of text inside DDoc. This text produces the attached
output (basically "cases:" is interpreted as a new section).

I'm not sure this has a solution, is just the whole DDoc system seems too
broken by design, but if someone can think of any heuristics to make this more
sensible (maybe requiring sections to have an empty line before?), it would be
interesting to know.

--

[Issue 16068] DDoc sections have serious design issues

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16068

Leandro Lucarella  changed:

   What|Removed |Added

   Keywords||ddoc

--

[Issue 16067] New: Invalid source lines shown with disassembly with gdb and objdump

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16067

  Issue ID: 16067
   Summary: Invalid source lines shown with disassembly with gdb
and objdump
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: christo...@meessen.net

Looking at disassembly with interleaved source code I detected a mismatch.
Trying with the following simple program app.d

  1import std.stdio;
  2
  3void main()
  4{
  5int a = 10;
  6
  7a += 3;
  8
  9++a;
 10
 11writefln("Value: %d", a);
 12
 13writeln("Helloworld!");
 14
 15}

I get this output with '$ objdump -d -S app' for the function _Dmain

0043aae8 <_Dmain>:
import std.stdio;

void main()
  43aae8:   55  push   %rbp
  43aae9:   48 8b ecmov%rsp,%rbp
  43aaec:   48 83 ec 10 sub$0x10,%rsp
{
int a = 10;
  43aaf0:   c7 45 f8 0a 00 00 00movl   $0xa,-0x8(%rbp)

a += 3;
  43aaf7:   83 45 f8 03 addl   $0x3,-0x8(%rbp)

++a;
  43aafb:   ff 45 f8incl   -0x8(%rbp)

writefln("Value: %d", a);
  43aafe:   ba 60 e5 46 00  mov$0x46e560,%edx
  43ab03:   be 09 00 00 00  mov$0x9,%esi
{
int a = 10;

a += 3;

++a;
  43ab08:   8b 7d f8mov-0x8(%rbp),%edi
  43ab0b:   e8 18 00 00 00  callq  43ab28
<_D3std5stdio19__T8writeflnTAyaTiZ8writeflnFNfAyaiZv>

writefln("Value: %d", a);

writeln("Helloworld!");
  43ab10:   ba 6a e5 46 00  mov$0x46e56a,%edx
  43ab15:   bf 0b 00 00 00  mov$0xb,%edi
  43ab1a:   48 89 d6mov%rdx,%rsi
  43ab1d:   e8 e6 9b 00 00  callq  444708
<_D3std5stdio16__T7writelnTAyaZ7writelnFNfAyaZv>
  43ab22:   31 c0   xor%eax,%eax

}
  43ab24:   c9  leaveq
  43ab25:   c3  retq
  43ab26:   66 90   xchg   %ax,%ax

0043ab28 <_D3std5stdio19__T8writeflnTAyaTiZ8writeflnFNfAyaiZv>:
}

Looking at the debug line table for the main function with the command '$
objdump --dwarf=decodedline app | less' I get this

./app.d:[++]
app.d  30x43aae8
app.d  50x43aaf0
app.d  70x43aaf7
app.d  90x43aafb
app.d 110x43aafe
app.d  90x43ab08
app.d 130x43ab10
app.d 150x43ab24

After closer inspection of the disassembly code it appears that the second line
with 9 should not be present. Removing it should provide a correct debug table. 

I didn't check the possible frequency of occurrence in a more complex program.

--

[Issue 8845] Can't pass immediate or rvalue args to ref function parameters

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=8845

Nick Treleaven  changed:

   What|Removed |Added

 CC||ntrel-...@mybtinternet.com
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=9238

--- Comment #20 from Nick Treleaven  ---
(In reply to Manu from comment #0)
> I've heard arguments about the safety of the operation, but the 'workaround'
> is just to create a temporary, which has identical security properties.
> ...
> Perhaps this behaviour could be restricted to ref const, or ref in, if we're
> getting worried about the safety of the operation? That would perhaps even
> improve on how behaves now.

I think rvalues could be passed to const ref parameters so long as that
parameter is not return ref. The reason is in case we decide to support local
refs initialized from a return ref function.

--

[Issue 9238] Support rvalue references

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=9238

Nick Treleaven  changed:

   What|Removed |Added

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

--

[Issue 15918] [2.070] Results from findSplit can no longer be assigned to each other

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15918

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

https://github.com/dlang/phobos/commit/54f05971e493201fd468eacfbdc3c41126aa897a
Fix Issue 15918

https://github.com/dlang/phobos/commit/8f24656082cc6353af25717886e5a5b31ed04018
Merge pull request #4349 from nordlow/findSplit-opAssign

Fix Issue 15918

--

[Issue 16058] `immutable delegate()` and `immutable delegate() immutable` are considered equal but treated differently

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16058

--- Comment #2 from ag0ae...@gmail.com ---
(In reply to Eyal Lotem from comment #1)
> I think it makes sense for the types not to be considered equal.
> (Head-mutable ptrs to immutable data exist, so why should delegates be
> inconsistent?)

A head mutable delegate would be `void delegate() immutable`, no? That is
considered different from the two types this is about.

--

[Issue 16066] Implement KnuthMorrisPrattFinder

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16066

greensunn...@gmail.com changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--

[Issue 16065] Provide digitally signed binaries for Windows

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16065

--- Comment #1 from Sobirari Muhomori  ---
Signature on binaries can be forged in the same way: obtain a valid certificate
with a similar CN and use it.

--

[Issue 9149] Disallow converting delegates to const

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=9149

--- Comment #3 from Sobirari Muhomori  ---
How about this?

class A
{
int i;
const void delegate() dg;
this() pure { dg= }
void f(){ i++; }
}

unittest
{
const A a = new A;
a.dg();
}

--

[Issue 16058] `immutable delegate()` and `immutable delegate() immutable` are considered equal but treated differently

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16058

Sobirari Muhomori  changed:

   What|Removed |Added

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

--

[Issue 1983] Delegates violate const

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=1983

Sobirari Muhomori  changed:

   What|Removed |Added

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

--- Comment #18 from Sobirari Muhomori  ---
issue 16058 - looks like there is some progress on this issue?

--

[Issue 1983] Delegates violate const

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=1983

Sobirari Muhomori  changed:

   What|Removed |Added

 CC||eyal.lo...@gmail.com

--- Comment #17 from Sobirari Muhomori  ---
*** Issue 16056 has been marked as a duplicate of this issue. ***

--

[Issue 16056] immutable delegate can mutate through context pointer

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16056

Sobirari Muhomori  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from Sobirari Muhomori  ---


*** This issue has been marked as a duplicate of issue 1983 ***

--

[Issue 16031] [REG2.071] dmd internal error when compiling druntime with PIC=1

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16031

--- Comment #2 from Martin Krejcirik  ---
(In reply to Walter Bright from comment #1)
> What does the PIC=1 do? PIC isn't anywhere in posix.mak

It's there, it adds -fPIC to DFLAGS.

--

[Issue 15619] [REG 2.066] Floating-point x86_64 codegen regression, when involving array ops

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15619

--- Comment #7 from ponce  ---
FWIW I don't use array ops anymore, to the exception of:

 slice[] = value;
 sliveA[] = sliceB[];

--

[Issue 16066] New: Implement KnuthMorrisPrattFinder

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16066

  Issue ID: 16066
   Summary: Implement KnuthMorrisPrattFinder
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: q...@web.de

Phobos has std.algorithm.searching.BoyerMooreFinder to use the Boyer-Moore
string search algorithm with find.

For some data [0,1] the Knuth-Morris-Pratt algorithm is superior. Phobos should
have a KnuthMorrisPrattFinder as well, so people can easily try and benchmark
both.

[0]
https://stackoverflow.com/questions/12656160/what-are-the-main-differences-between-the-knuth-morris-pratt-and-boyer-moore-sea
[1]
https://stackoverflow.com/questions/16085201/when-would-you-use-kmp-over-boyer-moore

--

[Issue 15918] [2.070] Results from findSplit can no longer be assigned to each other

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15918

Per Nordlöw  changed:

   What|Removed |Added

 CC||per.nord...@gmail.com

--- Comment #1 from Per Nordlöw  ---
Solved at https://github.com/dlang/phobos/pull/4349

--

[Issue 16058] `immutable delegate()` and `immutable delegate() immutable` are considered equal but treated differently

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16058

Eyal Lotem  changed:

   What|Removed |Added

 CC||eyal.lo...@gmail.com

--- Comment #1 from Eyal Lotem  ---
I think it makes sense for the types not to be considered equal.
(Head-mutable ptrs to immutable data exist, so why should delegates be
inconsistent?)

--

[Issue 16056] immutable delegate can mutate through context pointer

2016-05-24 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16056

--- Comment #6 from Eyal Lotem  ---
(In reply to ag0aep6g from comment #5)
> (In reply to Eyal Lotem from comment #4)
> > immutable void delegate() pure
> > 
> > vs.
> > 
> > immutable void delegate() immutable pure
> 
> When the delegate is part of an immutable struct instance, it has the former
> type, too:
> 
> 
> struct S { void delegate() pure f; }
> immutable s = S();
> pragma(msg, typeof(s.f)); /* immutable(void delegate() pure) */
> 
> 
> I suppose your point is that it should be the latter type, with two
> "immutable"s.
> 
> Fair enough, but I don't think that distinction is worth having. D doesn't
> have head const with pointers. Why should we make delegates a special case?
> 
> So in my opinion, `immutable void delegate()` should imply an immutable
> context pointer, making it the same type as `immutable void delegate()
> immutable`. Just like `immutable(int*)` is the same as
> `immutable(immutable(int)*)`.
> 
> The compiler agrees (to some extent):
> 
> 
> alias A = immutable int* delegate();
> alias B = immutable int* delegate() immutable;
> static assert(is(A == B)); /* passes */
> 
> 
> But then there's this:
> 
> 
> void main()
> {
> int x = 1;
> const void delegate() dg1 = { ++x; };
> const void delegate() const dg2 = { ++x; };
> }
> 
> 
> That compiles, but when you take the dg1 line away, then the dg2 line isn't
> accepted anymore. And when you swap them around, both lines are rejected.
> There's obviously something wrong here. I've filed a separate issue:
> https://issues.dlang.org/show_bug.cgi?id=16058

I agree `immutable delegate ..`  should imply the context is immutable too
(i.e: no head-const ptrs).
But possibly not the other way around.
It makes sense to have a mutable delegate with an immutable context (like a
mutable ptr to immutable data).

--