[Issue 15092] [REG2.066.0] ICE on duplicated struct declarations in class members

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15092

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from Kenji Hara  ---
https://github.com/D-Programming-Language/dmd/pull/5219

--

[Issue 15092] [REG2.066.0] ICE on duplicated struct declarations in class members

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15092

Kenji Hara  changed:

   What|Removed |Added

   Severity|normal  |regression

--

[Issue 15218] DMD should link dynamically to libphobos by default

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15218

Marco Leise  changed:

   What|Removed |Added

 CC||marco.le...@gmx.de

--- Comment #4 from Marco Leise  ---
(In reply to Adam D. Ruppe from comment #1)
> I absolutely, strongly disagree. Dynamic linking Phobos is a bad idea - it
> will lead to serious breakage around every corner for every application.
> 
> Phobos changes with every release. All executables compiled before an update
> will now be liable to break.

You link to a versioned soname "ldd `which dub`":
libphobos2.so.0.68 => /opt/dmd-2.068/lib64/libphobos2.so.0.68
This way dub wont break when I install 2.069 and the package manager is smart
enough to keep the library around until I recompile dub with the more recent
version of Phobos.

> […]
> 
> Phobos is also not commonly in the system library location, so on Linux,
> this means running programs won't work without either changing that or
> setting the library path, another big annoying hassle. I'd virtually break
> the zip distribution (which is Linux distro agnostic and used by those of us
> who aren't on .rpm or .deb).
> 
> […]
>
> If you want me to ever get on board with dynamic linking phobos, work to get
> it included with all the OSes as an independent end-user component first.

The risk of ABI breakage between compiler versions makes it so that I still
have to install GtkD (and other libraries) into separate compiler-arch-version
specific directories. As for DMD's Phobos itself, two files don't carry the
version in their name:

libphobos2.a
libphobos2.so
libphobos2.so.0.69
libphobos2.so.0.69.0

I'll look into moving the other two into system library path. It still doesn't
solve anything when it comes to additional libraries. God knows what happens
when you compile with dmd-2.069 and link to a library that was compiled against
Phobos-2.068 or with a different D compiler.

--

[Issue 15195] DIP25: Member functions can leak local variables

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15195

Walter Bright  changed:

   What|Removed |Added

   Keywords||performance
 CC||bugzi...@digitalmars.com
   Severity|normal  |enhancement

--- Comment #2 from Walter Bright  ---
Passing the address of a local variable to a nested function causes a closure
to be allocated. It's working as designed, though the analysis is
unsophisticated and could potentially be improved, so marked as an enhancement
request.

--

[Issue 15232] New: Escape analysis should be more sophisticated

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15232

  Issue ID: 15232
   Summary: Escape analysis should be more sophisticated
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timon.g...@gmx.ch

Consider the following code:

void foo()@nogc{
int x;
struct S{ int bar()@nogc{ return x; } }
S s;
}

Error: function foo @nogc function allocates a closure with the GC

No closure should be allocated here and in similar cases.

--

[Issue 10376] Glaring hole in const system

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=10376

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #6 from Jonathan M Davis  ---
This should be legal if the member variable is initialized with an immutable
value, since that doesn't create any holes in the type system. In fact, if it
weren't for issue# 12624, SysTime would have a default value for its timezone
which was immutable (with timezone being Rebindable!(immutable TimeZone) ). But
of course that requires that the member variable either be immutable or
something like Rebindable, immutable(T)*, or immutable(T)[] which can
point/refer to an immutable value but is not itself immutable.

However, it's definitely the case that this should be disallowed when the
initializer is mutable, and while it _could_ work with a const initializer
under some set of circumstances, it's way simpler to just disallow it.

--

[Issue 15195] DIP25: Member functions can leak local variables

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15195

timon.g...@gmx.ch changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from timon.g...@gmx.ch ---
(In reply to Walter Bright from comment #2)
> Passing the address of a local variable to a nested function causes a
> closure to be allocated. It's working as designed, though the analysis is
> unsophisticated and could potentially be improved, so marked as an
> enhancement request.

I have opened https://issues.dlang.org/show_bug.cgi?id=15232.

I'm closing this issue.

--

[Issue 15210] [REG2.064][ICE] (glue.c at 1489) with tuples and AAs

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15210

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/34f10ecaea2a8a3d9dbb20d089bf63217e00ff92
fix Issue 15210 - [ICE] (glue.c at 1489) with tuples and AAs

https://github.com/D-Programming-Language/dmd/commit/0a72d643af818c26b6630b3d93b94b24ed21f2d7
Merge pull request #5216 from 9rnsr/fix15210

[REG2.064] Issue 15210 - [ICE] (glue.c at 1489) with tuples and AAs

--

[Issue 15210] [REG2.064][ICE] (glue.c at 1489) with tuples and AAs

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15210

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

   What|Removed |Added

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

--

[Issue 15092] [REG2.066.0] ICE on duplicated struct declarations in class members

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15092

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/60c9ba49e3f7b1d8a9e1061e524f08a70447918d
fix Issue 15092 - ICE on duplicated struct declarations in class members

Propagate errors in `Dsymbol.addMember()` through `Dsymbol.errors`.

https://github.com/D-Programming-Language/dmd/commit/d432960ce9f9f308479ea86c008a37f4c56ae841
Merge pull request #5219 from 9rnsr/fix15092

[REG2.066.0] Issue 15092 - ICE on duplicated struct declarations in class
members

--

[Issue 12624] Internal error: backend\cgobj.c 2313 with Rebindable!(immutable TimeZone) in std.datetime

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=12624

Jonathan M Davis  changed:

   What|Removed |Added

 CC||yebbl...@gmail.com

--- Comment #4 from Jonathan M Davis  ---
@yebblies At dconf, you were offering to look at this if it was still happening
(which it is, though obviously it took me a while to get around to verifying
that). So, I'm adding you to the cc list. Feel free to look into this or ignore
it as your time allows, but it would be nice if this got fixed.

--

[Issue 15039] Algebraic cannot store a Typedef along with Typedef'ed type

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15039

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull, rejects-valid

--- Comment #2 from Kenji Hara  ---
https://github.com/D-Programming-Language/phobos/pull/3761

--

[Issue 15052] dmd/std/utf.d error on variable std.utf.byCodeUnit!(inout(char)[]).byCodeUnit.ByCodeUnitImpl.r

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15052

Anton Pastukhov  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||pastuho...@gmail.com
 Resolution|INVALID |---

--- Comment #2 from Anton Pastukhov  ---
Unfortunately, this issue is still actual. Just ran into it while trying to
build dlangui with dmd 2.068.2 on openSUSE Tumbleweed. After manual deletion of
phobos dir and reinstallation of dmd errors persist.

--

[Issue 15207] [REG2.069.0-b1] Wrong codegen with -inline

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15207

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/3224f462eacbcd2d1cab663ea2af1e46d8bfd6fd
fix Issue 15207 - Wrong codegen with -inline

When issue 14944 fixed, the ref variable content initializing form had been
flagged by `MemorySet.refValueInit`.

However, inilining may replace `AssignExp.e1` operand with a `STCref` temporary
variable.
When it happens, the `MemorySet.refValueInit` flag will be ignored in
`AssignExp.toElem` and wrong code had generated.

To avoid the issue, instead flag the case "ref varaible initialization" by
`MemorySet.referenceInit`.
Its meaning will be kept beyond inlining stage, and the bug won't happen.

https://github.com/D-Programming-Language/dmd/commit/77463d7b0503a96d0ea367f5f29df15ed7655cad
Merge pull request #5206 from 9rnsr/fix15207

[REG2.069.0-b1] Issue 15207 - Wrong codegen with -inline

--

[Issue 10376] Glaring hole in const system

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=10376

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #5 from Andrei Alexandrescu  ---
The quickest way to stop the bleeding is to disallow the code. It's incorrect
for immutable data and misleading for mutable data. (What an user might expect
is that each data comes with a distinct array.)

--

[Issue 15231] New: opOpAssign allows assignment to rvalue

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15231

  Issue ID: 15231
   Summary: opOpAssign allows assignment to rvalue
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: r...@rcorre.net

unittest {
  struct MyInt {
int _val;

auto opBinary(string op)(int other) {
  return mixin("_val"~op~"other");
}

void opOpAssign(string op)(int other) {
  _val = mixin("_val"~op~"other");
}
  }

  struct Foo {
int _i;
MyInt _mi;

auto i() { return _i; }
auto mi(){ return _mi; }
auto i(int val)  { return _i = val; }
auto mi(int val) { return _mi = MyInt(val); }
  }

  auto f = Foo(1, MyInt(1));
  static assert(!__traits(compiles, f.i += 1));  // f.i is an rvalue
  static assert(!__traits(compiles, f.mi += 1)); // f.mi should be an rvalue
}

The final assert fails.f.mi is not an lvalue, and therefore f.mi += 1 should
not compile. It deceptively appears to increment `mi` while truly doing
nothing. The compiler disallows this for builtin types (e.g. int) but somehow
the use of opOpAssign bypasses this check.

Ideally, I'd love to have support for in-place property modification
(https://issues.dlang.org/show_bug.cgi?id=8006), but failing that, I think this
should be disallowed to avoid confusion.

P.S. not sure whether this belongs in DMD or druntime

--

[Issue 15231] opOpAssign allows assignment to rvalue

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15231

r...@rcorre.net changed:

   What|Removed |Added

 CC||r...@rcorre.net

--

[Issue 15092] [REG2.066.0] ICE on duplicated struct declarations in class members

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15092

Kenji Hara  changed:

   What|Removed |Added

Summary|[REG2.066.0][ICE] ICE on|[REG2.066.0] ICE on
   |duplicated struct   |duplicated struct
   |declarations in class   |declarations in class
   |members |members

--

[Issue 15092] [REG2.066.0][ICE] ICE on duplicated struct declarations in class members

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15092

Kenji Hara  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice
Summary|[REG2.066.0][ICE] Assertion |[REG2.066.0][ICE] ICE on
   |failed: (type->ty !=|duplicated struct
   |Tstruct || ((TypeStruct |declarations in class
   |*)type)->sym == this),  |members
   |function semantic, file |
   |struct.c, line 936. |

--

[Issue 15230] New: Inconsistent std.range.SortedRange predicate checks

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15230

  Issue ID: 15230
   Summary: Inconsistent std.range.SortedRange predicate checks
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: john.loughran.col...@gmail.com

SortedRange doesn't check that it's predicate actually works unless you use one
of lowerbound, upperBound etc. or you compile with -debug, in which case things
will fail internally to std.functional.binaryFun due to the usage of the
predicate in dbgVerifySorted.

Note that people could be signalling sorted-ness using SortedRange, not
considering they have invalid predicates, e.g.

struct S { int a,b; }
void foo(R)(R r)
if(isInstanceOf!(SortedRange, P) && is(ElementType!R == S))
{
//assumes some idea of sorted-ness
}
only(S(0,1), S(0,4), S(3,4), S(4,4)).assumeSorted.foo();

but I guess it's OK to break that because it was technically incorrect, if
rather opaquely so

--

[Issue 15092] [REG2.066.0] ICE on duplicated struct declarations in class members

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15092

Sobirari Muhomori  changed:

   What|Removed |Added

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

--

[Issue 14739] Immutable alias to template triggers dmd assert

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14739

Sobirari Muhomori  changed:

   What|Removed |Added

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

--

[Issue 15207] [REG2.069.0-b1] Wrong codegen with -inline

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15207

--- Comment #4 from ponce  ---
Much thanks!

--

[Issue 14739] Immutable alias to template triggers dmd assert

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=14739

--- Comment #4 from Sobirari Muhomori  ---
---
void f()
{
int a, b;
test!a ta;
test!b tb;
}
struct test(alias a){}
---

For some reason this compiles. Do instances have different mangled name here?

--

[Issue 15229] New: BigInt(Range of chars) too

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15229

  Issue ID: 15229
   Summary: BigInt(Range of chars) too
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: bearophile_h...@eml.cc

This is a slow and naive function to reverse a BigInt:

import std.bigint: BigInt;
import std.conv: to;
import std.conv: text;
import std.range: retro;
BigInt rev(in BigInt n) {
return n.text.retro.text.BigInt;
}
void main() {
assert(125.BigInt.rev == 521); 
}



But I'd like to avoid the second text conversion, and to write:

BigInt rev2(in BigInt n) {
return n.text.retro.BigInt;
}


In general in Phobos there are many functions (and constructors) that could and
sometimes should be range-ifed. An obvious one is to make std.conv.to!() accept
a lazy input too.

--

[Issue 15210] [REG2.064][ICE] (glue.c at 1489) with tuples and AAs

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15210

--- Comment #5 from Kenji Hara  ---
(In reply to Kenji Hara from comment #4)
> https://github.com/D-Programming-Language/dmd/pull/5209

Correction:
https://github.com/D-Programming-Language/dmd/pull/5216

--

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

2015-10-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15094

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #4 from Kenji Hara  ---
https://github.com/D-Programming-Language/dmd/pull/5215

--