[Issue 17474] non-property being treated as a property

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17474

--- Comment #5 from Stefan Koch  ---
(In reply to Walter Bright from comment #4)
> I'm not sure what the "right" semantics are, either, because each of the
> behaviors can be justified.

I am pretty sure the last thing you want is a function to be invoked as a
setter property if it returns an Lvalue.

--

[Issue 17474] non-property being treated as a property

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17474

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #4 from Walter Bright  ---
I'm not sure what the "right" semantics are, either, because each of the
behaviors can be justified.

But I can suggest avoiding using default function arguments. Default arguments
are a good solution for adding parameters without breaking existing code, but
are not a good practice otherwise. The behavior observed here, as well as its
interaction with overloading, are examples.

The only other thing I can think of is issuing a warning if a function with a
default argument is being used as a setter.

--

[Issue 9287] DMD should read from stdin when an input file is "-"

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=9287

--- Comment #5 from Walter Bright  ---
https://github.com/dlang/dmd/pull/6880

--

[Issue 9287] DMD should read from stdin when an input file is "-"

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=9287

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #4 from Walter Bright  ---
(In reply to Andrej Mitrovic from comment #2)
> This is problematic because DMD uses single dash for arguments, if you
> accidentally run DMD with:
> 
> $ dmd -arg1 - arg2 -arg3
> 
> You're going to get some pretty awful error messages if DMD tries to read
> this.


This is normal for Linux. Look at:

   man cat

and there are both - prefixed switches and - meaning read from stdin.

--

[Issue 17457] Named Return Value Optimization (NRVO) not done with return of constructor call

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17457

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

https://github.com/dlang/dmd/commit/2fd96914cdd3fb2ddf29872b1c80415ce636916d
fix Issue 17457 - Named Return Value Optimization (NRVO) not done with return
of constructor call

https://github.com/dlang/dmd/commit/10e086ab9970750479711f05f4d06128e178377e
Merge pull request #6847 from WalterBright/fix17457

fix Issue 17457 - Named Return Value Optimization (NRVO) not done wit…
merged-on-behalf-of: Andrei Alexandrescu 

--

[Issue 17486] lazy parameters can be used to hijack the pure system

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17486

greensunn...@gmail.com changed:

   What|Removed |Added

 CC||greensunn...@gmail.com
Summary|lazy parameters cannot be   |lazy parameters can be used
   |used in nothrow/@nogc   |to hijack the pure system
   |functions   |

--- Comment #3 from greensunn...@gmail.com ---
For @nogc and nothrow there's already an open issue:

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

The other looks like a recent regression (so I am changing the title).

--

[Issue 17485] bringToFront and/or upperBound slow

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17485

--- Comment #2 from hst...@quickfur.ath.cx ---
More specifically, if (1) both ranges are built-in arrays, (2) they have the
same element type, and (3) the back range is a single element, we can optimize
this way:

If front and back are disjoint: (front.ptr > back.ptr && front.ptr +
front.length < back.ptr)

---
ElementType!InputRange e1 = back[0];
back[0] = front[$-1];
memmove(front.ptr+1, front.ptr, front.length-1);
front[0] = e1;
---

If back is part of front (i.e., front.ptr < back.ptr < front.ptr +
front.length):


ElementType!InputRange e1 = back[0];
memmove(front.ptr+1, front.ptr, back.ptr - front.ptr);
front[0] = e1;


--

[Issue 17485] bringToFront and/or upperBound slow

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17485

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--- Comment #1 from hst...@quickfur.ath.cx ---
>From an initial cursory glance: bringToFrontImpl relies only on forward range
primitives to do its job.  Also, it allows you to transcribe ranges with
different element types across each other (as long as the element type is
implicitly convertible to the target element type).  While this is all great
for generality, it sucks for performance when you're dealing with, e.g.,
built-in arrays.

I think there should definitely be a specialization for built-in arrays at the
very least, if not for slice-assignable random-access ranges in general, when
the element types are identical.  Definitely should consider using memmove() in
these cases to take advantage of years' worth of work C library authors have
put into memmove().

--

[Issue 9287] DMD should read from stdin when an input file is "-"

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=9287

hst...@quickfur.ath.cx changed:

   What|Removed |Added

   Keywords||pull

--- Comment #3 from hst...@quickfur.ath.cx ---
https://github.com/dlang/dmd/pull/6880

--

[Issue 17474] non-property being treated as a property

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17474

Stefan Koch  changed:

   What|Removed |Added

 CC||uplink.co...@gmail.com
   Assignee|nob...@puremagic.com|uplink.co...@gmail.com

--- Comment #3 from Stefan Koch  ---
I have a pr for this.
Could be a bit more polished though.

Comments welcome.

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

--

[Issue 1077] writef and friends won't read/write from/to redirected std handles

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=1077

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--

[Issue 9287] DMD should read from stdin when an input file is "-"

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=9287

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--

[Issue 17487] CTFE should allow casting delegate function attributes

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17487

Eyal  changed:

   What|Removed |Added

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

--- Comment #1 from Eyal  ---
I have a specific use-case:

assertOp!"<="(x, y);

I want x/y to be lazy so I can disable the assert at runtime (and avoid costs
of computing x,y). I also want any exceptions computing x,y to be caught by
assertOp.

I also need assert functions (including this one) to be @nogc but this is not
directly supported due to (https://issues.dlang.org/show_bug.cgi?id=17486).

So I need to use a delegate cast to achieve the combination of @nogc and lazy
params. This rules out any function that indirectly uses assertOp from ctfe,
which is sad.

if(__ctfe) could skip the asserts altogether, but that loses a lot too.

--

[Issue 17486] lazy parameters cannot be used in nothrow/@nogc functions

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17486

Eyal  changed:

   What|Removed |Added

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

--

[Issue 17487] New: CTFE should allow casting delegate function attributes

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17487

  Issue ID: 17487
   Summary: CTFE should allow casting delegate function attributes
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: e...@weka.io

import std.traits;

struct S {
int f() { return 1; }
int delegate() @nogc fAsNoGc() {
alias F = typeof();
enum oldAttrs = functionAttributes!F;
return cast(SetFunctionAttributes!(F, functionLinkage!F, oldAttrs |
FunctionAttribute.nogc))
}
}

int moo() { return S().fAsNoGc()(); }

auto x = moo(); // CTFE, fails
void main() {
auto y = moo(); // runtime, succeeds
}

--

[Issue 17486] lazy parameters cannot be used in nothrow/@nogc functions

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17486

--- Comment #2 from Eyal  ---
Better bug reproduction:

@safe:

void f(ref int counter, lazy int x) pure {
x();
counter++;
x();
}

void main() {
int counter;
int g() {
import std.stdio:writeln;
writeln("counter: ", counter);
return 5;
}
f(counter, g);
}

// prints:
counter: 0
counter: 1

Making it clearer that we're being allowed to pass an impure delegate into a
pure function that then calls it.

--

[Issue 17486] lazy parameters cannot be used in nothrow/@nogc functions

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17486

--- Comment #1 from Eyal  ---
This also breaks purity type checking:

@safe:

import std.stdio:writeln;

void f(lazy int x) pure {
x();
}

unittest {
int g() {
writeln("impure func called by pure func!");
return 5;
}
auto xx = (() => g());
writeln("-> f");
f(xx());
writeln("<- f");
}

outputs:

-> f
impure func called by pure func!
<- f

--

[Issue 17486] New: lazy parameters cannot be used in nothrow/@nogc functions

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17486

  Issue ID: 17486
   Summary: lazy parameters cannot be used in nothrow/@nogc
functions
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: normal
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: e...@weka.io

void f(lazy int x) @nogc {
x; // Error: @nogc function 'f' cannot call non-@nogc delegate 'x'
}
void g(lazy int x) nothrow {
x; // Error: 'x' is not nothrow
}

There's no way to annotate the implicit delegate is @nogc, nothrow, etc.

--

[Issue 17485] bringToFront and/or upperBound slow

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17485

Steven Schveighoffer  changed:

   What|Removed |Added

   Keywords||performance

--

[Issue 17485] New: bringToFront and/or upperBound slow

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17485

  Issue ID: 17485
   Summary: bringToFront and/or upperBound slow
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: schvei...@yahoo.com

See this thread:
https://forum.dlang.org/post/wfackprjkbyxqhesz...@forum.dlang.org

Not any idea why it doesn't go fast, or his other issue with -boundscheck=off
on ldc, but tinkering with the code, I couldn't get much except:

1. It's not the interaction of SortedRange with bringToFront
2. It's not an issue with using functors instead of lambdas
3. It's not an issue with the initial setup, as that should take nowhere near
the 10 seconds I found it takes (consistent with his testing).
4. It *may* be an issue with the comparison, but I switched away from using ==,
and didn't get any better performance.

Ali's message in the thread may give a clue as to why std::rotate is so good
and something we should try and dissect to copy it's speedups:
https://stackoverflow.com/questions/21160875/why-is-stdrotate-so-fast

--

[Issue 17271] dwarfeh(224) fatal error

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17271

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #1 from Vladimir Panteleev  ---
It's appearing randomly in my OS X Travis runs:

https://travis-ci.org/CyberShadow/Digger/jobs/241294012

--

[Issue 16615] std.process is missing functionality for child processes

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16615

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com
 Resolution|FIXED   |WONTFIX

--- Comment #4 from Vladimir Panteleev  ---
Resolving as WONTFIX as per
https://github.com/dlang/phobos/pull/5086#issuecomment-307461557 and
https://github.com/dlang/phobos/pull/5086#issuecomment-307426691 (quoting):

Although it might not be obvious, killing a process is inherently a very
platform specific operation. There is and cannot be an obviously correct way to
do it on both platforms (Windows and POSIX), because the two platforms manage
processes in different way. Windows does not have signals; POSIX does not allow
specifying exit codes; and reparenting is done differently on both. 

Furthermore, the example use case presented in the issue (killing a process
tree) is not possible to correctly implement with just kill - you must suspend
the entire process group, and only then kill them, and I'm not sure that even
that is sufficient. I would advise against attempting to do it in general, and
instead run the process group in a container and kill it wholesale.

--

[Issue 16615] std.process is missing functionality for child processes

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16615

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

https://github.com/dlang/phobos/commit/07602da6334fa250032d302c777b75d17b0e4379
Revert "Partial Fix Issue 16615 - convert os pid to std.process Pid"

https://github.com/dlang/phobos/commit/9bfc82130c0e4af4d1dc95bb261570c6e4f6f5d8
Merge pull request #5456 from dlang/revert-5086-process_enhancement

Revert "Partial Fix Issue 16615 - convert os pid to std.process Pid"
merged-on-behalf-of: Sebastian Wilzbach 

--

[Issue 16615] std.process is missing functionality for child processes

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16615

--- Comment #2 from github-bugzi...@puremagic.com ---
Commit pushed to revert-5086-process_enhancement at
https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/07602da6334fa250032d302c777b75d17b0e4379
Revert "Partial Fix Issue 16615 - convert os pid to std.process Pid"

--

[Issue 17472] [Reg 2.075] typeof(stdin) is no longer a File

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17472

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

   What|Removed |Added

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

--

[Issue 17472] [Reg 2.075] typeof(stdin) is no longer a File

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17472

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

https://github.com/dlang/phobos/commit/3caa34f219cebaf37b75ce7384a3a40dbb87fe1e
fix Issue 17472 - typeof(stdin) is no longer a File

https://github.com/dlang/phobos/commit/ff3c3dfb00d0db8cfb0c6571ad689a9e6080bfd7
Merge pull request #5454 from MartinNowak/fix17472

fix Issue 17472 - typeof(stdin) is no longer a File
merged-on-behalf-of: Andrei Alexandrescu 

--

[Issue 17472] [Reg 2.075] typeof(stdin) is no longer a File

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17472

--- Comment #3 from Andrei Alexandrescu  ---
(In reply to Martin Nowak from comment #2)
> (In reply to Andrei Alexandrescu from comment #1)
> > We really should get rid of library initialization
> > code.
> 
> Why did that became a goal btw?

Thanks for asking. It's "Better support for C-style libraries with light or no
runtime" in https://wiki.dlang.org/Vision/2017H1. Initializing all of druntime
and phobos lazily would make a lot of things better.

--

[Issue 17472] [Reg 2.075] typeof(stdin) is no longer a File

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17472

--- Comment #2 from Martin Nowak  ---
(In reply to Andrei Alexandrescu from comment #1)
> We really should get rid of library initialization
> code.

Why did that became a goal btw?

--

[Issue 7678] Add -cflags switch for DMD that allows passing flags to GCC or ${CC}

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=7678

Martin Nowak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||c...@dawg.eu
 Resolution|--- |DUPLICATE

--- Comment #2 from Martin Nowak  ---
Let's go with LDC's -Xcc switch.

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

--

[Issue 17390] Pass flags to linker driver without -Xlinker

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17390

Martin Nowak  changed:

   What|Removed |Added

 CC||chadj...@gmail.com

--- Comment #2 from Martin Nowak  ---
*** Issue 7678 has been marked as a duplicate of this issue. ***

--

[Issue 5278] gentoo's 'hardended' gcc doesn't work with dmd

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=5278

Martin Nowak  changed:

   What|Removed |Added

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

--- Comment #35 from Martin Nowak  ---
Should work now that we ship phobos with PIC by default (at least on X64).
Executables compiled with dmd's `-fPIC` do create PIEs.

--

[Issue 5278] gentoo's 'hardended' gcc doesn't work with dmd

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=5278
Issue 5278 depends on issue 7678, which changed state.

Issue 7678 Summary: Add -cflags switch for DMD that allows passing flags to GCC 
or ${CC}
https://issues.dlang.org/show_bug.cgi?id=7678

   What|Removed |Added

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

--

[Issue 17390] Pass flags to linker driver without -Xlinker

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17390

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #1 from Martin Nowak  ---
Looks like a duplicate of issue 7678.

--

[Issue 17275] [REG 2.072.0] AssertError@declaration.d(2121): Assertion failure

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17275

--- Comment #5 from Walter Bright  ---
https://github.com/dlang/dmd/pull/6875

--

[Issue 17482] [REG 2.074] comile error: Comparing Nullable!Variant with basic type

2017-06-09 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17482

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #1 from Vladimir Panteleev  ---
Introduced in https://github.com/dlang/phobos/pull/5032

--