[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from Walter Bright  ---
It sounds like the solution is to infer 'scope' for a struct instance on the
stack if it has a destructor.

--

[Issue 17914] [Reg 2.075] Fibers guard page uses a lot more memory mappings

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #9 from Martin Nowak  ---
If scoped isn't enough, you could use automem (~master or the next release) for
ref-counted classes.
http://code.dlang.org/packages/automem

import automem.ref_counted;

auto gen = RefCounted!(Generator!int)({yield(42);});
writeln(gen.front);
gen.popFront;
assert(gen.empty);

--

[Issue 6625] Distribute newer Windows API import libraries

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #5 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/installer

https://github.com/dlang/installer/commit/62adca4f2744d1ef93f7b6e36d90ff63d449494d
fix Issue 6625 - update OMF import libraries

- an update_libs.bat script to regenerate omf import libs from a
  Windows SDK is contained in the .zip archive and will be shipped
  as dmd2/windows/lib/update_libs.bat as well

--

[Issue 6625] Distribute newer Windows API import libraries

[d-bugmail--- via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 17941] arity (and probably others) only consider the first lexically present function

[d-bugmail--- via Digitalmars-d-bugs]

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

Simen Kjaeraas  changed:

   What|Removed |Added

 CC||simen.kja...@gmail.com

--- Comment #1 from Simen Kjaeraas  ---
This happens for all templates in std.traits that deal with properties of
functions. Making the templates fail when presented with an under-specified
overload set would be a breaking change, but documenting the behavior is
definitely worth it.

Phobos currently does not have good tools for working with overload sets -
__traits(getOverloads) is what we've got, and finding a specific overload is
manual work. In order to fix that part of the problem, I've created
getOverloads and overloadFor: https://github.com/dlang/phobos/pull/5818

--

[Issue 17730] [scope][dip1000] std.algorithm.move escapes scope variable in @safe code

[d-bugmail--- via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 17730] [scope][dip1000] std.algorithm.move escapes scope variable in @safe code

[d-bugmail--- via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/a34a25ead947fe6492fb0724b23dc5135c19ea1f
fix Issue 17730 - move escapes scope variable in @safe code

- needs to be annotated with return scope, so that the return value
  lifetime depends on the argument's lifetime
- cannot be tested because phobos doesn't yet work with DIP1000 and
  also because of Issue 17932

https://github.com/dlang/phobos/commit/61b7b517b0ab2a3eed45116f7476a0bd7a68837a
Merge pull request #5798 from MartinNowak/fix17730

fix Issue 17730 - move escapes scope variable in @safe code

--

[Issue 17943] Wrong pointer arithmetic optimization

[d-bugmail--- via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
Works for me when I use dmd 2.076.1 from dlang.org. But it fails when I use a
home-grown 2.076.1 (built with the one from dlang.org).

--

[Issue 17940] bool function parameters loaded from struct sometimes miscompiled with -O

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from FeepingCreature  ---
Proposed fix: https://github.com/dlang/dmd/pull/7252

--

[Issue 17908] Can't alias an overload set with disabled function

[d-bugmail--- via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/0a319dbe2cf87e008e74c370fcbb5e70170f9c2d
Fix Issue 17908 - Can't alias an overload set with disabled function

https://github.com/dlang/dmd/commit/11bf970f0708bed12701a676e3d6a24f4db4f5d9
Merge pull request #7244 from RazvanN7/Issue_17908

Fix Issue 17908 - Can't alias an overload set with disabled function
merged-on-behalf-of: Mathias Lang


--

[Issue 17498] Double error message about use of private

[d-bugmail--- via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Nowak  ---
The access check will be removed once visibility has become an error.
https://github.com/dlang/dmd/pull/7241
We tried to minimize overlap, but some cases weren't that easy to avoid.

--

[Issue 17941] arity (and probably others) only consider the first lexically present function

[d-bugmail--- via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

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

--

[Issue 17914] [Reg 2.075] Fibers guard page uses a lot more memory mappings

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #8 from Martin Nowak  ---
We could keep track of the number of unfinalized Fibers with guard pages and
trigger a GC collection when reaching 30K, but that's too hacky for my taste.

> We don't actually need 30k fibers. We need one fiber at a time 30k times in a 
> row.

As for your specific problem Brian, could you use
`std.typecons.scoped!(Generator!T)` which provides deterministic destruction?
Scoped is only moveable, not copyable.

  auto gen = scoped!(Generator!int)({yield(42);});
  auto gen2 = move(gen); // not copyable
  assert(gen2.front == 42);

Potentially if you have unclear ownership over that Generator and cannot
restrict yourself to `move`, you could combine it with `refCounted`, seems like
that combination doesn't work atm. though :/.

  auto gen = refCounted(scoped!(Generator!int)({yield(42);}));
  auto gen2 = gen; // 2nd reference to generator
  assert(gen2.front == 42);

--

[Issue 17914] [Reg 2.075] Fibers guard page uses a lot more memory mappings

[d-bugmail--- via Digitalmars-d-bugs]

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

Nemanja Boric <4bur...@gmail.com> changed:

   What|Removed |Added

 CC||4bur...@gmail.com

--- Comment #7 from Nemanja Boric <4bur...@gmail.com> ---
(In reply to briancschott from comment #5)
> > The problem is, this either break toy code that just
> > creates lots of useless Fibers or heavy production code
> > that actually needs 30K Fibers.
> 
> That's not entirely accurate. I found this because the range implementation
> for a complex multi-dimensional tree structure was implemented as a
> std.concurrency.Generator. The problem is caused by doing many tree
> traversals in a loop on a machine that has 512GB of memory. We don't
> actually need 30k fibers. We need one fiber at a time 30k times in a row. By
> the time we start using the second fiber we don't need the first one anymore.
> 
> It's possible to re-implement the range in question, but the amount of code
> required to do so is much greater than the current implementation using
> recursion and fibers.

Is it not possible just to use a simple pool for the Fibers? So, instead of
allocating a new fiber, you reset the recycled one to the new state. Is this
not possible with the std.concurrency.Generator?

> If we really need a comprise here, I'd definitely increase the stack size 
> further, e.g. to 64KiB (vibe.d's default).

This could be a problem on 32bit systems, where this would suck available
address space very quickly, if I'm not mistaken. Of course, we could still make
it a default for 64bit systems.

> A possible idea is putting a pattern in the guard data (leave it read/write), 
> and check the guard data on fiber deallocation, and optionally on every yield 
> (could be a performance issue, but maybe only used in debug mode?)

One problem I can see with this is that it doesn't show the problem on the spot
- good thing about protected region is that we die as soon as we try accessing
it. If the fiber does a lot of calls before yields, it may be that we're far
from the place that actually corrupted memory, and it's not that easy to debug.
Of course, it still prevents memory corruption (but at a cost that grows
linearly with the number of fibers).

> I'd err on the side of memory safety. Stack overflows are an actual problem 
> with Fibers and hard to debug.

Yes. I can't emphasize enough how many times we had these issues. And it's
never been a problem for us to confirm that this is what's happening with the
guard page in. It was always a hell to confirm what's going on with the
previous runtime, mostly because of the fact that it's not the fiber that's
actually corrupting memory the one it will crash, but some other poor fiber
that happens to have a stack adjacent to the rouge one.

Having said all this - why not just keep the default guard page on, but if
somebody is confident they don't need it (and they could even do a
`version(debug){}else{guardPageOff}`), simply providing 0 for the guard size in
the Fiber's constructor will turn this entire thing off? Perhaps we could
document this better (as I didn't expect this issue to raise when implementing
this, not much documentation is there).

However, I also thing Steven has a valid point when he says:

> Except this breaks existing code that may not have a stack overflow problem. 
> I hate to say it, but unfortunately, we are stuck with the status quo for now.

--

[Issue 17225] override abstract function by abstract function

[d-bugmail--- via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |INVALID

--- Comment #2 from RazvanN  ---
I'll close this as invalid and if you find a case where it doesn't work, feel
free to open e new bug report. Thanks!

--

[Issue 17253] dmd win32.mak error in 2.073.2

[d-bugmail--- via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from RazvanN  ---
Cannot reproduce on an Ubuntu machine (git HEAD) using wine. Closing as fixed,
please reopen if further problems are encountered.

--

[Issue 17165] missing files in release archives

[d-bugmail--- via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |FIXED

--- Comment #2 from RazvanN  ---
Cannot reproduce on Ubuntu 16.04 on git HEAD. Closing as fixed

--

[Issue 17943] Wrong pointer arithmetic optimization

[d-bugmail--- via Digitalmars-d-bugs]

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

Илья Ярошенко  changed:

   What|Removed |Added

   Keywords||wrong-code

--

[Issue 17943] New: Wrong pointer arithmetic optimization

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 17943
   Summary: Wrong pointer arithmetic optimization
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ilyayaroshe...@gmail.com

unittest
{
int[32] data;
auto p1 = data.ptr + 0;
auto p2 = data.ptr + 3;
assert(p2 - p1 == 3);
}

dmd -release -unittest -main -run test.d
pass

dmd -O -release -unittest -main -run test.d
fails

Tested with DMD 2.076 - 2.077, Linux, OSX.

--