[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile

2014-11-08 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8887

Mike Parker aldac...@gmail.com changed:

   What|Removed |Added

 CC||aldac...@gmail.com

--- Comment #14 from Mike Parker aldac...@gmail.com ---
(In reply to Dicebot from comment #7)
 The fact that `ref` parameters are allowed for extern(C) functions is even
 more bizzare than the fact that static array arguments crash programs. Need
 to check if it works, I would have never guessed to even try it.
 

This is documented. See the section Passing D Array Arguments to C Functions
at http://dlang.org/interfaceToC.html. 

If anyone wants examples of existing code that will be broken by this, see
Derelict. DerelictODE in particular, in which the matrix and vertex types are
typedefed on the C side as fixed-size arrays and passed as such to all the
functions that use them. Personally, I don't see the problem with prototyping
such C functions with ref. I hope it *doesn't* change.

--


[Issue 13700] New: Rejected valid conversion from slice to fixed size array

2014-11-08 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13700

  Issue ID: 13700
   Summary: Rejected valid conversion from slice to fixed size
array
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Keywords: rejects-valid
  Severity: enhancement
  Priority: P1
 Component: DMD
  Assignee: nob...@puremagic.com
  Reporter: bearophile_h...@eml.cc

I think this whole program should be accepted:


void main() {
int[char[2]] aa;
string s = hello;
immutable i = 1;
aa[s[i .. i + 2]] = 1; // OK
auto j = 1;
aa[s[j .. j + 2]] = 1; // Error
char[2] aux = s[j .. j + 2];
aa[aux] = 1;   // OK
}


DMD 2.067alpha gives:

test.d(7,9): Error: cannot implicitly convert expression
(s[cast(uint)j..cast(uint)(j + 2)]) of type string to char[2]

--


[Issue 13701] New: Associative array values ignore immutability

2014-11-08 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13701

  Issue ID: 13701
   Summary: Associative array values ignore immutability
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Keywords: accepts-invalid
  Severity: normal
  Priority: P1
 Component: DMD
  Assignee: nob...@puremagic.com
  Reporter: bearophile_h...@eml.cc

DMD 2.067alpha compiles and runs this without errors:


void main() {
immutable(int)[int] aa;
aa[10] = 20;
aa[10]++;
}

--


[Issue 13702] New: One missed 'may cause GC allocation' error message

2014-11-08 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13702

  Issue ID: 13702
   Summary: One missed 'may cause GC allocation' error message
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Keywords: diagnostic
  Severity: normal
  Priority: P1
 Component: DMD
  Assignee: nob...@puremagic.com
  Reporter: bearophile_h...@eml.cc

This program contains two similar functions, both contain two cases of GC
allocations, but in 'bar' the D compiler misses one of them (it catches it
later if you remove the first GC allocation inside 'bar'):


int[] foo(bool b) @nogc {
if (b)
return [1];
return 1 ~ [2];
}
int[] bar(bool b) @nogc {
if (b)
return [1];
auto aux = 1 ~ [2];
return aux;
}
void main() {}



DMD 2.067alpha gives:

test.d(3,16): Error: array literal in @nogc function foo may cause GC
allocation
test.d(4,16): Error: array literal in @nogc function foo may cause GC
allocation
test.d(9,20): Error: array literal in @nogc function bar may cause GC
allocation

--


[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile

2014-11-08 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8887

--- Comment #15 from Dicebot pub...@dicebot.lv ---
(In reply to Steven Schveighoffer from comment #13)
  This is abuse and needs to be fixed. We have pragma(mangle) to override
  mangling.
 
 I wasn't aware that we had a C mangling feature. We should change this ASAP,
 as I don't like the idea of specifying C functions for the sole purpose of
 escaping typechecking. If we fixed this, perhaps you have a better case for
 changing this.

Are there any legit extern(C) declaration in druntime at all or everything
needs to be updated? I'll do the PR.

--


[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile

2014-11-08 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8887

Dicebot pub...@dicebot.lv changed:

   What|Removed |Added

   Priority|P1  |P2
   Severity|regression  |critical

--- Comment #16 from Dicebot pub...@dicebot.lv ---
(In reply to Mike Parker from comment #14)
 (In reply to Dicebot from comment #7)
  The fact that `ref` parameters are allowed for extern(C) functions is even
  more bizzare than the fact that static array arguments crash programs. Need
  to check if it works, I would have never guessed to even try it.
  
 
 This is documented. See the section Passing D Array Arguments to C
 Functions at http://dlang.org/interfaceToC.html. 

I don't think complementary articles can be considered part of main spec - need
to copy that definitions to `extern(C)` spec itself or at least place a direct
link there.

 If anyone wants examples of existing code that will be broken by this, see
 Derelict. DerelictODE in particular, in which the matrix and vertex types
 are typedefed on the C side as fixed-size arrays and passed as such to all
 the functions that use them. Personally, I don't see the problem with
 prototyping such C functions with ref. I hope it *doesn't* change.

I am not proposing to prohibit ref-static-arrays, it would have been too much
of a breakage indeed. But situation with plain static array arguments does
sound too error-prone and impractical too keep. Think about it that way -
because of this issue you can't just take C header and tweak it until it
compiles as D code - it can still segfault at runtime after.

I will lower importance/priority though because of mentioned workaround with
`ref` that makes it possible to preserve API safety

--


[Issue 13697] Private method hides public static method

2014-11-08 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13697

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

   What|Removed |Added

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

--


[Issue 13701] Associative array values ignore immutability

2014-11-08 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13701

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

   What|Removed |Added

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

--


[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile

2014-11-08 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8887

--- Comment #17 from Mike Parker aldac...@gmail.com ---
(In reply to Dicebot from comment #16)

 I am not proposing to prohibit ref-static-arrays, it would have been too
 much of a breakage indeed. But situation with plain static array arguments
 does sound too error-prone and impractical too keep. Think about it that way
 - because of this issue you can't just take C header and tweak it until it
 compiles as D code - it can still segfault at runtime after.
 

Yes, I see. I got things mixed up. No argument there. That actually was a
problem for me before I realized that ref worked.

--


[Issue 13677] Add function template explanation on dlang.org

2014-11-08 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13677

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

   What|Removed |Added

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

--


[Issue 8136] Stack unwinding example uses OutOfMemoryError

2014-11-08 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=8136

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

   What|Removed |Added

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

--


[Issue 10155] deprecated delete used in http://www.digitalmars.com/d/2.0/memory.html

2014-11-08 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=10155

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

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||hst...@quickfur.ath.cx
 Resolution|--- |WORKSFORME

--- Comment #1 from hst...@quickfur.ath.cx ---
This page has been replaced with a redirect to a new Wiki page on the subject,
that no longer uses operator delete. I guess this bug can be closed. Please
reopen if operator delete is still being used somewhere in the documentation.
Thanks!

--


[Issue 10311] gdb prints wrong value for variable updated from closure

2014-11-08 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=10311

--- 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/7298c30d6fe45ec1f88c76d991af0c090b5d1a12
Fix Issue 10311 - GDB prints wrong value for variable updated from closure

https://github.com/D-Programming-Language/dmd/commit/dfb31be7edcec3a4210e06733f5f3843210514df
Merge pull request #4074 from tramker/bug10311

Fix Issue 10311 - GDB prints wrong value for variable updated from closure

--


[Issue 11216] Make synchronized statement `nothrow`

2014-11-08 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=11216

--- Comment #4 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/47c679964003ca75290e3174df85b0641eb5d282
fix Issue 11216 - Make synchronized statement `nothrow`

- mark _d_monitorenter/exit as nothrow

https://github.com/D-Programming-Language/dmd/commit/dc118391e51ddb69093780c157b1ca41e26add90
Merge pull request #4115 from MartinNowak/fix11216

fix Issue 11216 - Make synchronized statement `nothrow`

--


[Issue 13561] enumProcessThreads should be nothrow

2014-11-08 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13561
Issue 13561 depends on issue 11216, which changed state.

Issue 11216 Summary: Make synchronized statement `nothrow`
https://issues.dlang.org/show_bug.cgi?id=11216

   What|Removed |Added

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

--


[Issue 13253] use more scoped imports in phobos

2014-11-08 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13253

--- Comment #5 from Илья Ярошенко ilyayaroshe...@gmail.com ---
https://github.com/D-Programming-Language/phobos/pull/2665
https://github.com/D-Programming-Language/phobos/pull/2666
https://github.com/D-Programming-Language/phobos/pull/2667

--