[Issue 15191] DIP25: Taking address of ref return is not type checked soundly

[via Digitalmars-d-bugs]

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

--- Comment #2 from Walter Bright  ---
The trouble here is the following:


int[N]* bar(return ref int[N] s) @safe
{
return (s);  // <== taking the address of a reference should be an
error
}

--

[Issue 15191] DIP25: Taking address of ref return is not type checked soundly

[via Digitalmars-d-bugs]

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

--- Comment #1 from Walter Bright  ---
Reformatting for readability:

enum N=100;

ref int[N] foo(return ref int[N] s)@safe
{
return s;
}

int[N]* bar(return ref int[N] s) @safe
{
return (s);
}

ref int[N] baz()@safe
{
int[N] s;
return *bar(s);
}

void bang(ref int[N] x) @safe
{
x[]=0x25BAD;
}

void main() @safe
{
bang(baz());
}

--

[Issue 14238] DIP25: escape checks can be circumvented with delegate

[via Digitalmars-d-bugs]

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

--- Comment #1 from Walter Bright  ---
The problem here is that 'scope' is not implemented.

--

[Issue 16220] User-defined synchronized implementation

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

Summary|sync|User-defined synchronized
   ||implementation

--

[Issue 16220] New: sync

[via Digitalmars-d-bugs]

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

  Issue ID: 16220
   Summary: sync
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: petar.p.ki...@gmail.com

The current implementation of `synchronized` leaves much to be desired:
1. It adds the overhead of a monitor field to every class, even when it's never
used. Also makes object creation / finalization in druntime more complex.

2. It requires that all monitors/mutexes are implemented as classes, derived
from Object.Monitor, which also excludes struct-based implementations.

3. It does not allow custom implementation - e.g. `struct` objects can't be
synchronized.

4. Can't be `nothrow`/`@nogc`/etc. by design - because `Object.Monitor` tries
to be maximally inclusive, similarly to the Object.op* attribute problem.

Instead there should be a well defined, easily accessible protocol (e.g.
`opLock`, `opUnlock`, `opTryLock` non-static member functions) that is
recognized by the compiler (similar to how it already recognizes both struct
and class based input ranges) which would be used whenever `obj` in
`synchronized (obj)` implements it.

Another option would be to allow users to implement the `__monitor` field
themselves, provided that it has the required methods (at least `lock` and
`unlock` or `opLock`/`opUnlock`).

A third option would be to allow user overloads (non-extern) of
`_d_monitorenter` `_d_monitorexit` as free functions that are looked up
similarly to how `std.math.pow` is for the `^^` operator.

--

[Issue 12132] Object.Monitor and core.sync primitives should be shared

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

[Issue 8993] Implement unique references/isolated memory

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

   Keywords||safe
 CC||petar.p.ki...@gmail.com

--

[Issue 7902] [TDPL] sychronized is supposed to be for classes, not functions

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

   Keywords||safe
 CC||petar.p.ki...@gmail.com

--

[Issue 13727] std.stdio.File not thread-safe

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

   Keywords||safe
 CC||petar.p.ki...@gmail.com

--

[Issue 16057] [TDPL] synchronized (a, b) compiles and runs with wrong semantics

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

   Keywords||safe
 CC||petar.p.ki...@gmail.com

--

[Issue 14251] synchronized (mtx) doesn't check attributes (pure, const)

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

   Keywords||safe
 CC||petar.p.ki...@gmail.com

--

[Issue 15387] slice in extern(C++) ICE's

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

[Issue 15191] DIP25: Taking address of ref return is not type checked soundly

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

[Issue 15192] DIP25: Nested ref returns are type checked unsoundly

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

[Issue 16216] struct equality compares padding

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

[Issue 15193] DIP25 (implementation): Lifetimes of temporaries tracked incorrectly

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

[Issue 14242] destruction of static arrays with elaborate destructor elements does not propagate attributes

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

[Issue 16208] moduleinfo importedModules contains needless duplicates

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

[Issue 14485] .front of empty filtered zip range is accessible

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/ad7dbaa0505a2f0b4f6982625e6cca1163fd3c56
Fixed Issue 14485: .front of empty filtered zip range is accessible

https://github.com/dlang/phobos/commit/d89aea0ccfb3dfa17968ab84f010eb9652001472
Merge pull request #4488 from JackStouffer/issue14485

[Issue 14485] .front of empty filtered zip range is accessible

--

[Issue 14485] .front of empty filtered zip range is accessible

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 16219] std.experimental.allocator.makeArray does unnecessary allocations for ranges with length

[via Digitalmars-d-bugs]

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

--- Comment #1 from Jack Stouffer  ---
https://github.com/dlang/phobos/pull/4503

--

[Issue 16219] New: std.experimental.allocator.makeArray does unnecessary allocations for ranges with length

[via Digitalmars-d-bugs]

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

  Issue ID: 16219
   Summary: std.experimental.allocator.makeArray does unnecessary
allocations for ranges with length
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

makeArray does not use length information for input ranges if it exists,
causing extra calls to malloc.

--

[Issue 15387] slice in extern(C++) ICE's

[via Digitalmars-d-bugs]

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

uplink.co...@googlemail.com changed:

   What|Removed |Added

   Severity|enhancement |normal

--- Comment #1 from uplink.co...@googlemail.com ---
I hit the same issue. 
This is annoying.

--

[Issue 15387] slice in extern(C++) ICE's

[via Digitalmars-d-bugs]

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

uplink.co...@googlemail.com changed:

   What|Removed |Added

 CC||uplink.co...@googlemail.com

--

[Issue 16214] [REG2.069] ICE: Assertion `fd->semanticRun == PASSsemantic3done' failed.

[via Digitalmars-d-bugs]

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

Marc Schütz  changed:

   What|Removed |Added

 CC||schue...@gmx.net

--- Comment #1 from Marc Schütz  ---
This is the culprit, according to digger:

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

--

[Issue 15193] DIP25 (implementation): Lifetimes of temporaries tracked incorrectly

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||safe
 CC||bugzi...@digitalmars.com

--

[Issue 15192] DIP25: Nested ref returns are type checked unsoundly

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||safe
 CC||bugzi...@digitalmars.com

--

[Issue 15191] DIP25: Taking address of ref return is not type checked soundly

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||safe
 CC||bugzi...@digitalmars.com

--

[Issue 14475] man page is outdated

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com
  Component|dmd |dlang.org
   Hardware|x86_64  |All

--

[Issue 14238] DIP25: escape checks can be circumvented with delegate

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||safe
 CC||bugzi...@digitalmars.com
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 16218] New: Windows std.file.readImpl should be marked @system

[via Digitalmars-d-bugs]

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

  Issue ID: 16218
   Summary: Windows std.file.readImpl should be marked @system
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Keywords: safe
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: schvei...@yahoo.com

For some reason, the function is split into 90% islands of @trusted code, there
is very little actual @safe code in there. In addition, the function shouldn't
actually be @trusted, as it takes a null-terminated string. Better to mark it
@system, and mark the uses of it @trusted (or mark the whole thing @trusted,
and change the API to take a string array).

--

[Issue 16217] New: Wrong code with -O -inline on function with right shift

[via Digitalmars-d-bugs]

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

  Issue ID: 16217
   Summary: Wrong code with -O -inline on function with right
shift
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: db...@joakim.fea.st

There was a recent off-by-one bug in Phobos, where toChars was incorrectly
slicing its result:

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

It ended up right-shifting by a negative number and I wondered why dmd didn't
warn about this.  I see now that static analysis or a runtime check is not done
with such functions, so the compiler doesn't know and the binary can't tell you
what went wrong at runtime.

However, when creating an equivalent test to see what's going on, I seem to
have stumbled on another inlining/optimization combo bug in dmd.

Here's the code I wrote to mimic the toChars issue linked above:

int check_shift(int x) { return 16 >>> ((2 - x) * 4);}
unittest
{
assert(check_shift(3)  ==  16);
//assert(( 16 >>> (2-3) * 4)  ==  16);
}

If the second assert isn't commented out, dmd always evaluates that expression
at compile-time and gives this error:

shift.d(5): Error: shift by -4 is outside the range 0..31

If it's left commented out and the file is compiled with this command,

./2.071.1/linux/bin64/dmd -O -unittest -main shift.d

the resulting binary asserts at runtime on line 4, ie the first assert.  If I
compile again with inlining,

./2.071.1/linux/bin64/dmd -O -inline -unittest -main shift.d

the test passes, because the entire unittest block is "optimized" out, ie it's
simply removed from the resulting assembly:

00422b80 <_D5shift14__unittestL2_1FZv>:
422b80:   50  push   %rax
422b81:   58  pop%rax
422b82:   c3  retq
422b83:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)

This doesn't happen with inlining alone, the binary asserts there.  The problem
is reproducible with dmd 2.063.2 on linux/x64 also, which is the oldest dmd I
had lying around.  Fwiw, ldc 1.0.0 for linux/x64 also passes the test if
optimization and inlining are enabled.

--