date:20171026

[Issue 2447] There's no disconnectall for std.signals

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

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

https://github.com/dlang/phobos/commit/f0d2655d7535ae16fd681679d75b4c42014348c9
Fix issue 2447 - add disconnectAll for std.signals

https://github.com/dlang/phobos/commit/b5e6365a9bb9e0ca3af194d7add212c092ad1b13
Merge pull request #5812 from edi33416/signals_disconnectall

Fix issue 2447 - add disconnectAll for std.signals
merged-on-behalf-of: Andrei Alexandrescu 

--

[Issue 2447] There's no disconnectall for std.signals

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

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

   What|Removed |Added

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

--

[Issue 5332] Undefined reference to zero length array

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

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

https://github.com/dlang/dmd/commit/239c35233e62f289e6e868b7d4eafdcd63c72ea4
fix Issue 5332 - Undefined reference to zero length array

https://github.com/dlang/dmd/commit/ff4bdb660e6ed2ab1eb6c8725bd673417ef21a41
Merge pull request #7249 from WalterBright/fix5332

fix Issue 5332 - Undefined reference to zero length array

--

[Issue 17942] Enums are evaluated differently in global scope

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
Reduced:


alias AliasSeq(TList...) = TList;
enum B = AliasSeq!(); // fails
void main()
{
enum A = AliasSeq!(); //works
}


--

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

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #6 from Steven Schveighoffer  ---
(In reply to briancschott from comment #5)
> 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.

Right, the issue here is not so much that you need a certain number of
concurrent fibers, it's that the limited resource (64K items per process) is
tied to memory management (essentially infinite number of items per process,
and no requirement to release).

It's the same argument as to why File is ref-counted with malloc and not a
class.

So toy examples may fail, large concurrent webservers may fail (but arguably,
those can be tuned to work), OR reasonable innocuous code may fail if it falls
into the right trap using GC-managed data.

Worth noting that simply turning off GC collections can trigger this error.

A heavy-handed solution might be that if there is a limit on Fiber creation,
then you should have an object to manage them. But that would be a drastic
design change.

Another possibility is that we make a type-change to track the "good" behavior
and the "bad" behavior separately. For example, SafeFiber, which does the guard
page. Then at least it's opt-in.

(In reply to Martin Nowak from comment #4)
> Why isn't the number of guard pages a problem on Windows? That kernel also
> needs to keep track of lots of memory regions.

The limit is 64k *per process*, so obviously, the kernel can handle quite a bit
more.

Worth noting that Windows has a much different memory layout than Unix.

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

That's also a possible option. We could do that along with the reversal of the
guard page.

--

[Issue 17541] Function attribute deduction depends on compile invocation

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

johanenge...@weka.io changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #7 from johanenge...@weka.io ---
reopening, because it is not fixed for safe/trusted, nor for impure/pure,
throw/nothrow.

--

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

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #5 from briancsch...@gmail.com ---
> 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.

--

[Issue 11847] sub-pkg not available as qualified name

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Martin Nowak  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #13 from Martin Nowak  ---
https://github.com/dlang/dmd/pull/7218

--

[Issue 5332] Undefined reference to zero length array

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #11 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7249

--

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

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #4 from Martin Nowak  ---
(In reply to Steven Schveighoffer from comment #3)
> > I'd err on the side of memory safety. Stack overflows are an actual problem
> > with Fibers and hard to debug.
> 
> 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.

The problem is, this either break toy code that just creates lots of useless
Fibers or heavy production code that actually needs 30K Fibers.

For the latter it's reasonable to ask for manual tuning of either the kernel or
the Fiber stack size.
For the former it's fairly hard to justify that the default has such a severe
memory and safety hole.

Why isn't the number of guard pages a problem on Windows? That kernel also
needs to keep track of lots of memory regions.

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

--

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

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #3 from Steven Schveighoffer  ---
(In reply to Martin Nowak from comment #2)
> What's actually causing the limit is the fact that the kernel can no longer
> merge the mappings, hence the limit gets reached much quicker.

This would explain why the limit wasn't being reached before the change!

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

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.

> Any better idea to detect/prevent stack overflows?

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?)

You can also check the current SP on yield to make sure it's in-bounds (cheap
but doesn't cover everything).

Another option is to put a read-only guard page on only some of the fibers. If
you are allocating a lot of similar fibers, you are bound to hit one
eventually.

Still another option is to allocate the guard page on as many fibers as you
can, and then back off when you can't. This could be difficult, however, as the
relationship between mmap'd regions and the number of fibers may not be linear.

None of this prevents 100% of corruption, but they are better than nothing.

--

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

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu
Summary|Accidental per-process  |[Reg 2.075] Fibers guard
   |limit of fiber uses |page uses a lot more memory
   ||mappings

--- Comment #2 from Martin Nowak  ---
Here is what I'm seeing, calling mprotect splits the mapped range into 2, a 16K
rw--- and a 4K - mapping.
Calling GC.collect finalizes all unreachable Fibers and unmaps *both* regions
with a single `munmap(p, 20K)` call, so we don't really leak anything here.

What's actually causing the limit is the fact that the kernel can no longer
merge the mappings, hence the limit gets reached much quicker.


foreach (i; 0 .. 32 * 1_024) { new Fiber(function{}, 4 * 4096, 0); }

7f63304e9000 123184K rw---   [ anon ]

vs.

foreach (i; 0 .. 32 * 1_024) { new Fiber(function{}, 3 * 4096, 4096); }

7f2819cbf000 12K rw---   [ anon ]
7f2819cc2000  4K -   [ anon ]
7f2819cc3000 12K rw---   [ anon ]
7f2819cc6000  4K -   [ anon ]
7f2819cc7000 12K rw---   [ anon ]
7f2819cca000  4K -   [ anon ]
7f2819ccb000 12K rw---   [ anon ]
7f2819cce000  4K -   [ anon ]
7f2819ccf000 12K rw---   [ anon ]
7f2819cd2000  4K -   [ anon ]
7f2819cd3000 12K rw---   [ anon ]
7f2819cd6000  4K -   [ anon ]

I'd err on the side of memory safety. Stack overflows are an actual problem
with Fibers and hard to debug.
For using 32K+ Fibers it doesn't seem too reasonable to use custom stack and
guard sizes, e.g. a fairly big default stack size without guard page would
prevent most issues.

Any better idea to detect/prevent stack overflows?

--

[Issue 17942] New: Enums are evaluated differently in global scope

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

  Issue ID: 17942
   Summary: Enums are evaluated differently in global scope
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: temta...@gmail.com

import std.meta;


enum B = aliasSeqOf!(gen()); // fails

void main()
{
enum A = aliasSeqOf!(gen()); //works
}

string[] gen()
{
return null; // change to [ `` ] makes error go away
}

--

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

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

  Issue ID: 17941
   Summary: arity (and probably others) only consider the first
lexically present function
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

Consider:

import std.traits;

void fun(int);
void fun(int, int);

void gun(int, int);
void gun(int);

static assert(arity!fun == 1);
static assert(arity!gun == 2);

This code passes, indicating that only the first name in lexical order of an
overload set is considered by arity. This is definitely surprising. Worst case
the behavior should be documented, but a real solution would allow people to
indicate which overload they're interested in.

--

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

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #2 from FeepingCreature  ---
Hah! It tries to reload the cse into ESI, but since that's a 1-byte operation
(since bool), it actually becomes a move to DH. ESI is not even reachable with
1-byte ops, because those register values were used to address high regs. So
for reg8 opcodes like 0x8A, code->setReg should assert on reg & 4.

How to actually fix this though, no idea.

--

[Issue 17741] std.range.transposed does not work with Map

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Alexandru Razvan Caciulescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #4 from Alexandru Razvan Caciulescu  
---
Decided to close this issue. The simple workaround is to use:
auto result = ror.array.transposed;

--

[Issue 17918] [Reg 2.072] ICE with unknown symbol in base class

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Martin Nowak  changed:

   What|Removed |Added

   Keywords||ice, ice-on-invalid-code
   Priority|P3  |P2
 CC||c...@dawg.eu
Summary|Segmentation fault dmd  |[Reg 2.072] ICE with
   |failed with exit code 139.  |unknown symbol in base
   ||class
   Severity|regression  |critical

--- Comment #5 from Martin Nowak  ---
cat > a.d << CODE
class Base
{
auto byNode()
{
return _listMap;
}
}
CODE
cat > b.d << CODE
import a;

class Derived : Base
{
}
CODE
dmd -c b.d

a.d(5): Error: undefined identifier _listMap
Segmentation fault

#0  0x007280f5 in totym(Type*) ()
#1  0x007231c8 in ToCtypeVisitor::visit(Type*) ()
#2  0x007018ea in Visitor::visit(TypeError*) ()
#3  0x00698949 in TypeError::accept(Visitor*) ()
#4  0x0072df3a in toSymbol::ToSymbol::visit(FuncDeclaration*) ()
#5  0x0062b5b9 in FuncDeclaration::accept(Visitor*) ()
#6  0x0072d46f in toSymbol(Dsymbol*) ()
#7  0x00736cd2 in toObjFile::ToObjFile::visit(ClassDeclaration*) ()
#8  0x0056c30d in ClassDeclaration::accept(Visitor*) ()
#9  0x00735e23 in toObjFile(Dsymbol*, bool) ()
#10 0x0072527f in genObjFile(Module*, bool) ()
#11 0x0068c371 in ddmd.mars.tryMain(ulong, const(char)**) ()
#12 0x0068cdaf in D main ()


Changed severity from regression to major as this was always an ICE.
The difference between version in the example from comment 4, comes from map no
longer being importable from std.algorithm.

--

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

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

FeepingCreature  changed:

   What|Removed |Added

 CC||default_357-l...@yahoo.de

--- Comment #1 from FeepingCreature  ---
Simplified a bit:

struct Array
{
long length, ptr;
}

struct Struct
{
bool b = true;
}

void fun1(int) { }

void fun2(Array arr, int, int)
{
assert(!arr.length);
}

void fn(Struct* str)
{
Array arr;
if (!str) return;
if (str)
{
fun1(str.b);
}
if (str.b)
{
fun2(arr, str.b, 0);
}
}

void main()
{
Struct s;
fn();
}

--

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

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

  Issue ID: 17940
   Summary: bool function parameters loaded from struct sometimes
miscompiled with -O
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: be...@caraus.de

Code (test.d):

struct Array
{
long length, ptr;
}

struct Struct
{
bool b1 = true, b2;
}

void fun(Array arr, int, int)
{
if (arr.length != 0) asm { int 3; }
}

void fn(Struct* str)
{
Array arr;
if (!str) return;
if (str.b1)
{
fun(arr, str.b2, 0);
}
if (str.b1)
{
fun(arr, str.b1, 0);
}
}

void main()
{
Struct s;
fn();
}

Then:

dmd -O test.d  && ./test

causes "Trace/breakpoint trap"

--

[Issue 2447] There's no disconnectall for std.signals

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Eduard Staniloiu  changed:

   What|Removed |Added

 CC||edi33...@gmail.com
   Assignee|nob...@puremagic.com|edi33...@gmail.com

--

[Issue 17897] Incorrect number of destructor calls in example

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #11 from Steven Schveighoffer  ---
(In reply to Temtaime from comment #10)
> After fixing https://issues.dlang.org/show_bug.cgi?id=17246 this outputs:
> 
> Bar.this(int): 14FB84
> fun: 14FB20
> Bar.~this(): 14FB20
> 
> Object gets moved without notification.
> This should not behave this way

This is perfectly valid. You are allowed to move a struct without calling the
postblit. See the spec here: https://dlang.org/spec/struct.html

"A struct is defined to not have an identity; that is, the implementation is
free to make bit copies of the struct as convenient."

In fact, I think we can close this as a duplicate, as it now works properly.

However, I'm kind of surprised there is a move here, should be unnecessary if
implemented properly.

--

[Issue 17897] Incorrect number of destructor calls in example

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Temtaime  changed:

   What|Removed |Added

 CC||temta...@gmail.com

--- Comment #10 from Temtaime  ---
After fixing https://issues.dlang.org/show_bug.cgi?id=17246 this outputs:

Bar.this(int): 14FB84
fun: 14FB20
Bar.~this(): 14FB20

Object gets moved without notification.
This should not behave this way

--

[Issue 17897] Incorrect number of destructor calls in example

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #9 from Jack Applegame  ---
Seems this bug related to https://issues.dlang.org/show_bug.cgi?id=17246

--

[Issue 17741] std.range.transposed does not work with Map

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Alexandru Razvan Caciulescu  changed:

   What|Removed |Added

 CC||alexandru.razva...@gmail.co
   ||m

--- Comment #2 from Alexandru Razvan Caciulescu  
---
Created a PR for this. I had to change a test for issue #8764
https://issues.dlang.org/show_bug.cgi?id=8764
However I checked and it's not introducing any regression.

--

[Issue 17741] std.range.transposed does not work with Map

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #3 from Alexandru Razvan Caciulescu  
---
https://github.com/dlang/phobos/pull/5810

--

[Issue 17939] extern(C) function support with non-C attributes/types should be documented

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #1 from Martin Nowak  ---
On one hand it's definitely a requirement to attribute C functions, so that
root primitives have correct attributes and people can actually write attribute
correct code using those.

--

[Issue 17379] Mangle voldemort types as if they are defined in the outer scope to avoid exponential symbol name length with templates

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

ZombineDev  changed:

   What|Removed |Added

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

--

[Issue 15831] IFTI voldemort type exploding bloat

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Steven Schveighoffer  changed:

   What|Removed |Added

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

--

[Issue 17379] Mangle voldemort types as if they are defined in the outer scope to avoid exponential symbol name length with templates

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schvei...@yahoo.com
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=15831
 Resolution|--- |WONTFIX

--- Comment #6 from Steven Schveighoffer  ---
I think actually, we can close this, as Rainer's fix for issue (in the latest
version of the compiler) mitigates the need for this.

There are also ambiguity problems when there are function overloads.

--

[Issue 17541] Function attribute deduction depends on compile invocation

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

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

   What|Removed |Added

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

--

[Issue 17541] Function attribute deduction depends on compile invocation

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

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

https://github.com/dlang/dmd/commit/df847ccb60a37f4dbc349e8cee4a2ee6081e0c3c
fix Issue 17541 - Function attribute deduction depends on compile invocation

https://github.com/dlang/dmd/commit/aabeeb0a550a0d4ba066209290c799c5cf812e87
Merge pull request #6995 from WalterBright/fix17541

fix Issue 17541 - Function attribute deduction depends on compile inv…

--

[Issue 17842] [scope] array append allows for escaping references

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

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

https://github.com/dlang/dmd/commit/a3859d9529f2505e2736e37c0ee0d8123080c90a
fix Issue 17842 - [scope] array append allows for escaping references

https://github.com/dlang/dmd/commit/7815bdab2df7569edfc27721fde99e82f7d0fe91
Merge pull request #7236 from WalterBright/fix17842

fix Issue 17842 - [scope] array append allows for escaping references

--

[Issue 17927] [scope] `scope inout` parameter value can be escaped via return

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

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

https://github.com/dlang/dmd/commit/3f7544f355eacc0ad390a89b1bc07ca2dbcf835e
fix Issue 17927 - [scope]  parameter value can be escaped via return

https://github.com/dlang/dmd/commit/b46ac59c637723877b52b98ed50167e0f68aca5d
Merge pull request #7235 from WalterBright/fix17927

fix Issue 17927 - [scope]  'scope inout' parameter value can be escaped via
return

--

[Issue 7854] Non-C attributes allowed on extern(C) function parameters

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Steven Schveighoffer  changed:

   What|Removed |Added

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

--

[Issue 17246] [REG2.053] Extra destructor call.

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

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

https://github.com/dlang/dmd/commit/6eccdeee1d4c41abb0a6e8733e13a85b63765266
fix Issue 17246 - [REG2.053] Extra destructor call.

https://github.com/dlang/dmd/commit/614da7260f173ae5dc0ec87e8fa85d3edfb031ce
Merge pull request #7238 from WalterBright/fix17246

fix Issue 17246 - [REG2.053] Extra destructor call.

--

[Issue 17939] New: extern(C) function support with non-C attributes/types should be documented

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

  Issue ID: 17939
   Summary: extern(C) function support with non-C attributes/types
should be documented
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: spec
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: schvei...@yahoo.com

In issue 7854, Walter says that allowing non-C attributes in extern(C) function
parameters is a "feature":

https://issues.dlang.org/show_bug.cgi?id=7854#c15

Therefore, I'm opening this enhancement request for making the spec reflect
definitively how this feature works. I think a clear explanation will help
compiler developers, and will help users understand what actually happens.

See also Walter's PR that uses this feature:
https://github.com/dlang/druntime/pull/1917

--

[Issue 7997] Optlink issues 'Index Range' error with static zero length array

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

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

   What|Removed |Added

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

--

[Issue 7997] Optlink issues 'Index Range' error with static zero length array

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

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

https://github.com/dlang/dmd/commit/d4883f2a95a3e7ffe9feb09c688b7a1ef38e45f2
fix Issue 7997 - Optlink issues 'Index Range' error with static zero length
array

https://github.com/dlang/dmd/commit/4a62e8479c64b371878f23f0e77c154893613aea
Merge pull request #7243 from WalterBright/fix7997

fix Issue 7997 - Optlink issues 'Index Range' error with static zero …

--

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

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #1 from RazvanN  ---
PR : https://github.com/dlang/dmd/pull/7244

--

[Issue 14178] C++ linux name mangling does not handle standard abbreviations for const types

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

--- Comment #9 from Guillaume Chatelet  ---
Unfortunately no. I can't find the time to work on this anymore :(

--

[Issue 17938] New: Detect immutable variadic arguments

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

  Issue ID: 17938
   Summary: Detect immutable variadic arguments
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: performance
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: dfj1es...@sneakemail.com

---
void f(in string[] a...);
void g()
{
f("a","b","c");
}
void h()
{
static immutable string[3] b=["a","b","c"];
f(b);
}
---
void example.g():
 push   %rbp
 mov%rsp,%rbp
 sub$0x40,%rsp
 mov%rbx,-0x38(%rbp)
 mov$0x0,%ecx
 mov$0x1,%eax
 mov%rax,-0x30(%rbp)
 mov%rcx,-0x28(%rbp)
 mov$0x0,%edx
 mov$0x1,%ebx
 mov%rbx,-0x20(%rbp)
 mov%rdx,-0x18(%rbp)
 mov$0x0,%ecx
 mov$0x1,%esi
 mov%rsi,-0x10(%rbp)
 mov%rcx,-0x8(%rbp)
 lea-0x30(%rbp),%rdx
 mov$0x3,%edi
 mov%rdx,%rsi
 xor%eax,%eax
 callq  55 
 mov-0x38(%rbp),%rbx
 leaveq 
 retq   
void example.h():
 push   %rbp
 mov%rsp,%rbp
 mov$0x0,%edx
 mov$0x3,%edi
 mov%rdx,%rsi
 xor%eax,%eax
 callq  18 
 pop%rbp
 retq   
---
The calls are equivalent, but function h looks more efficient and has less code
generated. Function g amounts to 24 instructions and 91 bytes, h - to 9
instructions and 32 bytes.

--

[Issue 17937] New: Dsymbol.checkDeprecated also checks if a symbol is disabled

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

  Issue ID: 17937
   Summary: Dsymbol.checkDeprecated also checks if a symbol is
disabled
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: razvan.nitu1...@gmail.com

Currently the checkDeprecated method of the Dsymbol class first checks if a
symbol is deprecated and regardless of that result it then checks if a symbol
is disabled. This leads to the impossibility of checking for only one of the
attributes and also if you declare a symbol as deprecated and disabled at the
same time it outputs both messages, instead of the single more important error.

This also makes it hard to work with alias declarations which include a
deprecated or disabled function.

--

[Issue 17636] Support pragma(mangle) on types

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 17310] [SPEC] Ambiguous mangling for 'Y', Objective-C function or variadic arguments?

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 17379] Mangle voldemort types as if they are defined in the outer scope to avoid exponential symbol name length with templates

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 17359] C++ Interfacing: function with 'static' array parameter cannot be linked (x64)

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 17302] [SPEC] QualifiedName mangling does not match compiler.

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||pull

--

[Issue 17302] [SPEC] QualifiedName mangling does not match compiler.

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 16623] Support C++ Name Mangling

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||C++, mangling
 CC||bugzi...@digitalmars.com

--

[Issue 16289] no extern(C++) mangling for size_t/unsigned long parameters

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||C++, mangling
 CC||bugzi...@digitalmars.com

--

[Issue 15843] D-type mangling used for extern(C) (extern) function declaration inside function body, on LDC, GDC, and DMD.

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 15523] extern(C++) support TLS (C++ 'thread_local') linkage?

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||C++
 CC||bugzi...@digitalmars.com

--

[Issue 15473] C++ mangling problem

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||C++, mangling

--

[Issue 15143] core.demangle: Superfluous * when demangling function pointers

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 14894] mangling of mixins and lambdas is not unique and depends on compilation flags

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||mangling

--

[Issue 14831] Each function local symbols should have unique mangled name

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 14739] Immutable alias to template triggers dmd assert

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||ice, mangling
 CC||bugzi...@digitalmars.com

--

[Issue 14591] [SPEC] Ambiguity between extern(Pascal) and template value parameters

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 14178] C++ linux name mangling does not handle standard abbreviations for const types

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||mangling

--- Comment #8 from Walter Bright  ---
any progress with this?

--

[Issue 13984] Mangling of /ENTRY depends on DLL imports

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 12959] nothrow should be required for extern(C) functions

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |WONTFIX

--- Comment #2 from Walter Bright  ---
A D function that calls a C function that calls a D function that throws should
work, even if the current implementation doesn't. So, I don't think it should
be a requirement for extern(C) functions to be nothrow.

--

[Issue 12575] extern(C) mangling ignored inside mixin template

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 11586] core.demangle should understand _D16TypeInfo_HAyayAa6__initZ etc.

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 11131] variables without linkage shouldn't have a mangling (.mangleof)

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 11248] template value parameter cause too long mangling

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 8789] mangling of const member function

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 7854] Non-C attributes allowed on extern(C) function parameters

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |INVALID

--- Comment #15 from Walter Bright  ---
This is actually a feature. I used it to good effect to define a function for
errno:

https://github.com/dlang/druntime/blob/master/src/core/stdc/errno.d#L34

extern (C)
{
ref int _errno();
alias errno = _errno;
}

The actual function in the C runtime library returns an int*, but by making it
a ref int it will automatically dereference in D, enabling the simple use of
`errno` as in C.

Other uses are being able to hook up to functions based on their underlying
representation and bypass the stronger type checking D has. Such as FILE is a
shared type in D, but in C it's just another type. Sending it as extern(C) is
very convenient.

--

[Issue 7024] inconsistent mangling of shared in extern(C++)

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 4620] C++ constructor and template mangling, C++ ABI patch

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 17772] Wrong C++ mangled names for templated functions

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 16479] Wrong C++ mangling for template

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 16359] Mangling of const static arrays does not match C++

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||mangling

--

[Issue 15970] C++ mangling of templated arg type

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 15505] extern(C++) array parameter mangling gains surprise const

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 15608] extern(C++) mangling problem

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||mangling

--

[Issue 14956] C++ Mangling incompatible with C++11

2017-10-26 Thread d-bugmail--- via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

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

--

76 matches

Mail list logo