[Issue 14503] BigInt to binary/octal and lower case "%x" (hexadecimal format)

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14503

--- Comment #5 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/630e227c5a50985cbd5d96144e3dcb95ec9aef21
Merge pull request #3992 from quickfur/bigint_octal

Issue 14503: Implement formatting BigInt in octal

--


[Issue 15839] [REG2.071-b1] this.outer is of wrong type

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15839

--- Comment #9 from Jacob Carlborg  ---
(In reply to Kenji Hara from comment #8)
> https://github.com/D-Programming-Language/dmd/pull/5613
> 
> If a nested class has a parent class over some nested functions, '.outer'
> will properly point instance of the parent class.

So, this pull request will fix the issues I'm having?

--


[Issue 15858] core.sys.posix.dirent.dirent for glibc is invalid

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15858

Ketmar Dark  changed:

   What|Removed |Added

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

--


[Issue 15858] New: core.sys.posix.dirent.dirent for glibc is invalid

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15858

  Issue ID: 15858
   Summary: core.sys.posix.dirent.dirent for glibc is invalid
   Product: D
   Version: D2
  Hardware: x86
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: ket...@ketmar.no-ip.org

core.sys.posix.dirent.dirent struct is invalid: it should be `align(1):` (i.e.
not aligned). at least on GNU/Linux x86.

--


[Issue 15857] New: Confusing/wrong error message with -transition=checkimports

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15857

  Issue ID: 15857
   Summary: Confusing/wrong error message with
-transition=checkimports
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: d...@me.com

Here's an other issue with the -transition=checkimports flag. I've not been
able to create a reduced test case but I get the following error message when
compiling DStep:

clang/Type.d(114,24): Deprecation: local import search method found overloadset
clang.Type.isEmpty instead of overloadset clang.Type.isEmpty

This is where it complains [1], "isEmpty" pulled in from here [2] and declared
here [3].

[1] https://github.com/jacob-carlborg/dstep/blob/master/clang/Type.d#L114
[2] https://github.com/jacob-carlborg/dstep/blob/master/clang/Type.d#L9
[3] https://github.com/jacob-carlborg/mambo/blob/master/mambo/core/Array.d#L110

--


[Issue 15856] New: Confusing error message with -transition=checkimports

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15856

  Issue ID: 15856
   Summary: Confusing error message with -transition=checkimports
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: d...@me.com

Compiling the following code:

class Foo
{
import core.stdc.config;

struct Bar
{
c_long a; // line 7
}
}

With the -transition=checkimports flag the compiler gives the following error
messages:

main.d(1): Deprecation: class main.Foo alias core.stdc.config.c_long found in
local import
main.d(7): Deprecation: local import search method found nothing (null) instead
of alias core.stdc.config.c_long

I'm not sure if the error message is just bad or if there's a bug in the
compiler.

--


[Issue 15842] struct is being copied when returned directly

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15842

--- Comment #2 from hst...@quickfur.ath.cx ---
(Small structs may also be returned via registers alone, but I surmise that
using & on the struct will suppress this.)

--


[Issue 15842] struct is being copied when returned directly

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15842

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

   What|Removed |Added

   Keywords|wrong-code  |
 CC||hst...@quickfur.ath.cx

--- Comment #1 from hst...@quickfur.ath.cx ---
I'm pretty sure this behaviour is according to spec.  Structs are supposed to
behave like glorified ints, meaning they are value types and may be freely
copied around and moved when passing between functions.  This is one reason
it's a bad idea to keep internal pointers to a struct, as the pointers will
become invalid once the struct is moved.  Returning a struct from a function is
generally implemented as storing in a temporary area on the stack, and moving
to the final stack variable once control returns to the caller.

--


[Issue 15850] [VisualD] Host gh-pages at official repo

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15850

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

   What|Removed |Added

 CC||hst...@quickfur.ath.cx
Summary|Host gh-pages at official   |[VisualD] Host gh-pages at
   |repo|official repo

--


[Issue 15853] [std.random] save method must be immutable

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15853

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

   What|Removed |Added

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

--- Comment #2 from hst...@quickfur.ath.cx ---
It's sufficient to make .save const.

--


[Issue 15839] [REG2.071-b1] this.outer is of wrong type

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15839

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull
Summary|this.outer is of wrong type |[REG2.071-b1] this.outer is
   ||of wrong type

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

If a nested class has a parent class over some nested functions, '.outer' will
properly point instance of the parent class.

--


[Issue 15855] "a[{for" causes dmd to segfault

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15855

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

   What|Removed |Added

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

--


[Issue 15855] "a[{for" causes dmd to segfault

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15855

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

https://github.com/D-Programming-Language/dmd/commit/8511fe7ade95dc3a9fd64e214dee15633250
fix Issue 15855 - "a[{for" causes dmd to segfault

https://github.com/D-Programming-Language/dmd/commit/c2276c702eb3237c798584eaccc6ff314474efac
Merge pull request #5612 from 9rnsr/fix15855

Issue 15855 - "a[{for" causes dmd to segfault

--


[Issue 15179] Local imports cause outer imports to be excluded from overload set

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15179

Steven Schveighoffer  changed:

   What|Removed |Added

   Severity|regression  |enhancement

--- Comment #9 from Steven Schveighoffer  ---
(In reply to Jesse Phillips from comment #8)
> It does not. Since I wrote code where selective imports was not necessary,
> an update to a second library being used hijacked my call and the compiler
> gave no warning. That is the hijack problem, the fact that I can modify my
> code to use the desired function is not relevant to how the compiler is
> supposed to help prevent hijacking: http://dlang.org/hijack.html

Of course selective imports aren't necessary. But importing locally without
using selective imports is prone to this issue.

I would argue any time you do a scoped import of a module you don't control,
you should use static, renamed, or selective imports. This narrows the focus of
what you are looking for, and is not subject to overriding or hijacking since
it's treated as a local alias.

D can do some things to prevent hijacking, but you must remember that it
doesn't have a history of code. It cannot always deduce that something was
hijacked and that's not what you intended.

Note, I just realized this isn't a regression, it's an enhancement. The import
rules are working as they were designed. If we are to change anything, it would
be a new design.

--


[Issue 15855] "a[{for" causes dmd to segfault

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15855

Kenji Hara  changed:

   What|Removed |Added

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

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

--


[Issue 15831] IFTI voldemort type exploding bloat

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15831

Ivan Kazmenko  changed:

   What|Removed |Added

 CC||ga...@mail.ru

--


[Issue 15831] IFTI voldemort type exploding bloat

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15831

Johan Engelen  changed:

   What|Removed |Added

 CC||jbc.enge...@gmail.com

--- Comment #2 from Johan Engelen  ---
Hi Anon,
  I've started implementing your idea. But perhaps you already have a beginning
of an implementation? If so, please contact me :)

Thanks,
  Johan

--


[Issue 13116] Should not be able to return ref to 'this'

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13116

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

https://github.com/D-Programming-Language/dmd/commit/b0f45b08924511891473c7a2cb18dc8446a9ad30
fix Issue 13116 - Should not be able to return ref to 'this'

https://github.com/D-Programming-Language/dmd/commit/2d59f2e43e59b1a3c66745c6d9ac9039ff09eed3
Merge pull request #5591 from 9rnsr/fix13116

Issue 13116 - Should not be able to return ref to 'this'

--


[Issue 15839] this.outer is of wrong type

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15839

--- Comment #7 from Jacob Carlborg  ---
I tried modifying my code to explicitly pass in the outer this reference. That
works until you have nested anonymous classes. For example:

interface A {}
interface B {}

class Foo
{
void foo()
{
auto a = new class(this) A {
Foo outer;
this(Foo outer)
{
this.outer = outer;
this.outer.bar();

auto b = new class(this) B {
A outer;
this(A outer)
{
this.outer = outer;
this.outer.outer.bar(); // line 20
}
};
}
};
}

void bar() {}
}

The above will of course fail to compile since there's no "bar" in "A":

main.d(20): Error: no property 'outer' for type 'main.A'

Any suggestions?

--


[Issue 15830] UFCS prevents to select a free function when the parameter has a member with the same name

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15830

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

   What|Removed |Added

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

--


[Issue 15836] [REG 2.071-b1] memory error when a class is not implicitly destructed and constructed with new

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15836

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

   What|Removed |Added

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

--- Comment #3 from b2.t...@gmx.com ---
Ok I close. The problem can be solved without using AddrOf.

--


[Issue 15836] [REG 2.071-b1] memory error when a class is not implicitly destructed and constructed with new

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15836

Rainer Schuetze  changed:

   What|Removed |Added

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

--- Comment #2 from Rainer Schuetze  ---
The trouble is that the destructor of MemoryStream is calling GC.addrOf in the
finalization stage of a collection, and there is a new check that explicitly
disallows this.

At the sweep stage, the GC is in an intermediate state that might not yield
sensible results for GC.addrOf and friends. I think using this as an indicator
whether a block of memory is allocated by the GC depends on its exact
implementation (block immediately "freed" after finalization?), and it might
restrict the inner workings of the GC too much if we make this a requirement.

--


[Issue 15726] [REG2.068.0] forward reference error for circular classes, RefCounted

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15726

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

https://github.com/D-Programming-Language/dmd/commit/ebc83d3c8ef9f16e7aff201757850a9c738650b0
fix Issue 15726 - forward reference error for circular classes, RefCounted

https://github.com/D-Programming-Language/dmd/commit/1d8ce9d8d2669693cb59efd8b00e4a6554467079
Merge pull request #5500 from 9rnsr/fix15726

[REG2.068.0] Issue 15726 - forward reference error for circular classes,
RefCounted

--


[Issue 14666] [REG2.061] Bogus forward reference error

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14666

--- Comment #8 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/711944c56bf50a7e7323cd34008311345e53f57c
Add deferred semantic2 mechanism, and run semantic2 for all imported modules

When a module is only imported from function local scopes, it couldn't get a
change to run semantic2 analysis.
It was "fix" for the issue 14666 case, but the deferred instance size
finalization collides with that.

Now, function local imports can cause module level mutual forward references.
Their resolutions can be deferred until the global level analysis loop in
`mars.d` at maximum, and all function local imports will work as same as module
level ones.

--


[Issue 13975] ICE: dmd crash if -gc and enum member is immutable int

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13975

Rainer Schuetze  changed:

   What|Removed |Added

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

--- Comment #2 from Rainer Schuetze  ---
https://github.com/D-Programming-Language/dmd/pull/5611

--


[Issue 313] [module] Fully qualified names bypass private imports

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=313

Maksim Zholudev  changed:

   What|Removed |Added

 CC||maxim...@gmail.com

--- Comment #21 from Maksim Zholudev  ---
*** Issue 13709 has been marked as a duplicate of this issue. ***

--


[Issue 13709] Can access symbols that are not publicly imported via full name

2016-03-31 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13709

Maksim Zholudev  changed:

   What|Removed |Added

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

--- Comment #1 from Maksim Zholudev  ---


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

--