date:20170706

[Issue 17606] dmd wrongly accepts field without type when annotated with a UDA

2017-07-06 Thread via Digitalmars-d-bugs

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Linux   |All

--- Comment #2 from Vladimir Panteleev  ---
Yeah, pretty sure you can add anything to a declaration that distinguishes it
from a statement, which apparently includes UDAs. "auto" is a no-effect keyword
that you can use if you have nothing else to write there. Same reason why
`const foo() { return 1; }` is valid inside a method.

--

[Issue 15304] [REG 2.068.0] Error about SortedRange not being nothrow in debug mode

2017-07-06 Thread via Digitalmars-d-bugs

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

--- Comment #6 from Vladimir Panteleev  ---
Fixed by https://github.com/dlang/dmd/pull/5881.

--

[Issue 17601] [REG2.075.0-b1] segmentation fault for dmd -deps

2017-07-06 Thread via Digitalmars-d-bugs

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

--- Comment #2 from Vladimir Panteleev  ---
Reduced:

 a.d 
import b;
 b.d 
void foo() {
import c;
}
 c.d 
struct {
void ()
}
// build.sh /
dmd -c -deps a.d -of/dev/null
/

Bisection points to https://github.com/dlang/dmd/pull/6748 but it's more likely
that that change simply exposed a latent bug.

--

[Issue 17605] [REG2.066.0] __traits(compiles, closure) adds link-time reference to _d_allocmemory

2017-07-06 Thread via Digitalmars-d-bugs

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

Vladimir Panteleev  changed:

   What|Removed |Added

Summary|__traits(compiles, closure) |[REG2.066.0]
   |adds link-time reference to |__traits(compiles, closure)
   |_d_allocmemory  |adds link-time reference to
   ||_d_allocmemory
   Severity|normal  |regression

--- Comment #3 from Vladimir Panteleev  ---
It looks like this was temporarily fixed in
https://github.com/dlang/dmd/pull/2845 and then broken again shortly after in
https://github.com/dlang/dmd/pull/3625. I suppose that makes this a regression.

--

[Issue 17614] [REG2.075.0-b2] VERSION has the wrong value

2017-07-06 Thread via Digitalmars-d-bugs

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

greenify  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from greenify  ---
*** Issue 17608 has been marked as a duplicate of this issue. ***

--

[Issue 17608] [REG2.075.0-b2] No [] operator overload for type object.TypeInfo_Class

2017-07-06 Thread via Digitalmars-d-bugs

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

greenify  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greeen...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #3 from greenify  ---
Sönke also found this issue, marking this one as a duplicate because his issue
has the correct title.

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

--

[Issue 17614] New: [REG2.075.0-b2] VERSION has the wrong value

2017-07-06 Thread via Digitalmars-d-bugs

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

  Issue ID: 17614
   Summary: [REG2.075.0-b2] __VERSION__ has the wrong value
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: slud...@outerproduct.org

Reports 75 instead of 2075.

--

[Issue 17612] [REG2.063] Segmentation fault with bad object.d

2017-07-06 Thread via Digitalmars-d-bugs

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/6975

--

[Issue 16564] KRRegion.empty sometimes returns Ternary.no

2017-07-06 Thread via Digitalmars-d-bugs

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

--- Comment #5 from Vladimir Panteleev  ---
(In reply to Temtaime from comment #4)
>   ubyte[1024 * 1024] buf;


Are you sure that's not just because you have a 1MB static array on the stack?

This program, by itself, crashes on Windows (because of stack overflow):

void main()
{
ubyte[1024 * 1024] buf;
}

--

[Issue 17369] [Module std.traits] Documentation lists ditto in table

2017-07-06 Thread via Digitalmars-d-bugs

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

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

   What|Removed |Added

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

--

[Issue 17369] [Module std.traits] Documentation lists ditto in table

2017-07-06 Thread via Digitalmars-d-bugs

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

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

https://github.com/dlang/phobos/commit/43eadc38e3e31258470b53237db4176876ad54c5
Fix Issue 17369 - [Module std.traits] Documentation lists ditto in table

https://github.com/dlang/phobos/commit/0d7ce7f65969af6cb7c06f1a48ed4ead77194d80
Merge pull request #5558 from RazvanN7/Issue_17369

Fix Issue 17369 - [Module std.traits] Documentation lists ditto in table
merged-on-behalf-of: Sebastian Wilzbach 

--

[Issue 8472] Replace walkLength() with an improved count()

2017-07-06 Thread via Digitalmars-d-bugs

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

--- Comment #2 from Andrei Alexandrescu  ---
thx!

--

[Issue 8472] Replace walkLength() with an improved count()

2017-07-06 Thread via Digitalmars-d-bugs

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

RazvanN  changed:

   What|Removed |Added

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

--- Comment #1 from RazvanN  ---
walkLength wasn't deprecated, but the enhancement for count was added. Since
the title is replace walkLength, I'm closing this with WONTFIX.

--

[Issue 4923] immutable module variables are modifiable in non-shared module constructors

2017-07-06 Thread via Digitalmars-d-bugs

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

Steven Schveighoffer  changed:

   What|Removed |Added

   Keywords|pull|
 CC||schvei...@yahoo.com

--

[Issue 6114] immutable class variable not properly initialized when the constructor initializing it is non-shared

2017-07-06 Thread via Digitalmars-d-bugs

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

Steven Schveighoffer  changed:

   What|Removed |Added

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

--- Comment #6 from Steven Schveighoffer  ---
The example isn't exactly pointing out the error.

There are 2 problems here, one is an expectation that a non-shared static ctor
might run before the shared one (it doesn't, the order is clearly defined).
That's not really a bug.

The second is that immutable (shared) data is changing from one thread to the
next.

I think this should be closed as a dup of 4923.

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

--

[Issue 4923] immutable module variables are modifiable in non-shared module constructors

2017-07-06 Thread via Digitalmars-d-bugs

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

--- Comment #7 from Steven Schveighoffer  ---
*** Issue 6114 has been marked as a duplicate of this issue. ***

--

[Issue 17540] std.net.curl: HTTP no possibillity to set CURLOPT_NOPROXY

2017-07-06 Thread via Digitalmars-d-bugs

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

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

https://github.com/dlang/phobos/commit/e40a35675a89ec9346ba90cf973a423ff8e5d973
Fix Issue 17540 - std.net.curl: HTTP no possibillity to set CURLOPT_NOPROXY

https://github.com/dlang/phobos/commit/1a5ae4aee5a0c4c509ea55dd88e1a26941f932d3
Merge pull request #5538 from RazvanN7/Issue17540

[Trivial] Fix Issue 17540 - setting CurlOption.noproxy is cumbersome 
merged-on-behalf-of: Sebastian Wilzbach 

--

[Issue 17613] New: Inconsistent behaviour in code coverage

2017-07-06 Thread via Digitalmars-d-bugs

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

  Issue ID: 17613
   Summary: Inconsistent behaviour in code coverage
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

Reduced code:

import std.stdio;
struct MyFile
{
this(string filename) { }
auto byLine() { return 0; }
}
struct Wrapper
{
this(Args...)(Args args) {}
}
auto func(F = std.stdio.File)(bool[] args)
{
import std.algorithm.iteration : map;
foreach (x; args.map!(arg => arg ?  Wrapper(
F("A").byLine) :
Wrapper(
0)))
{ }
}
void main()
{
import std.algorithm : each;
func!MyFile([ true, false ]);
func([ false ]);
}


Compile with dmd -unittest -cov, and run the program.  Here is the obtained
.lst file:


   |import std.stdio;
   |struct MyFile
   |{
  1|this(string filename) { }
  1|auto byLine() { return 0; }
   |}
   |struct Wrapper
   |{
  3|this(Args...)(Args args) {}
   |}
   |auto func(F = std.stdio.File)(bool[] args)
   |{
   |import std.algorithm.iteration : map;
 17|foreach (x; args.map!(arg => arg ?  Wrapper(
000|F("A").byLine) :
  2|Wrapper(
   |0)))
   |{ }
   |}
   |void main()
   |{
   |import std.algorithm : each;
  1|func!MyFile([ true, false ]);
  1|func([ false ]);
   |}
util.d is 87% covered


Note the line with 000.  This is clearly wrong, because the first call to
func!MyFile ought to have traversed both branches of the ?: operator, so
F("A").byLine must have been invoked at least once.

Now comment out the second call to func (func([ false ])), recompile, and run
again. Here is the obtained .lst file:


   |import std.stdio;
   |struct MyFile
   |{
  1|this(string filename) { }
  1|auto byLine() { return 0; }
   |}
   |struct Wrapper
   |{
  2|this(Args...)(Args args) {}
   |}
   |auto func(F = std.stdio.File)(bool[] args)
   |{
   |import std.algorithm.iteration : map;
 11|foreach (x; args.map!(arg => arg ?  Wrapper(
   |F("A").byLine) :
  1|Wrapper(
   |0)))
   |{ }
   |}
   |void main()
   |{
   |import std.algorithm : each;
  1|func!MyFile([ true, false ]);
   |//func([ false ]);
   |}
util.d is 100% covered


Note that the call to F("A").byLine is now *no longer part of the coverage
count*.  So here we have a paradoxical situation where decreasing code coverage
(by not instantiating func with the default parameter for F) increases the
reported code coverage to 100%.

Note that defaulting F to std.stdio.File seems to be an essential part of this
bug; I could not get rid of the reference to std.stdio.File without making the
bug also vanish.  (I tried declaring my own version of File in a different
module and importing that, but that made the bug disappear.)

Also, the odd formatting of the Wrapper lines are necessary to expose this bug;
in the original, unreduced code, the lines were wrapped this way because the
original code had longer lines that needed to be wrapped. However, wrapping
lines should not affect the code coverage percentage(!).

--

[Issue 17608] [REG2.075.0-b2] No [] operator overload for type object.TypeInfo_Class

2017-07-06 Thread via Digitalmars-d-bugs

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

ZombineDev  changed:

   What|Removed |Added

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

--

[Issue 17601] [REG2.075.0-b1] segmentation fault for dmd -deps

2017-07-06 Thread via Digitalmars-d-bugs

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

--- Comment #1 from Vladimir Panteleev  ---
Reducing.

--

[Issue 17605] __traits(compiles, closure) adds link-time reference to _d_allocmemory

2017-07-06 Thread via Digitalmars-d-bugs

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

--- Comment #2 from ZombineDev  ---
Agreed. From my superficial understanding of dmd's internals, I think the
culprit is around `needsCodegen()`. AFAIR, changes to that code often led to
regressions and undefined symbol references and in the past 3-4 years it was
relatively often tweaked, though I think it was stable / unchanged over the
last year or so.
I don't remember if Walter and Kenji agreed that they have reached the perfect
design, so that no further changes to the general emission strategy were
necessary, but judging from these bug reports, there's still work to be done.

See also:
https://github.com/ldc-developers/ldc/issues/2168#issuecomment-312494490 and
https://issues.dlang.org/show_bug.cgi?id=17577.

--

[Issue 17605] __traits(compiles, closure) adds link-time reference to _d_allocmemory

2017-07-06 Thread via Digitalmars-d-bugs

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

Adam D. Ruppe  changed:

   What|Removed |Added

 CC||destructiona...@gmail.com

--- Comment #1 from Adam D. Ruppe  ---
I think this is a general case of CT-only functions in use still ending up in
the object file simply because they were defined in the code...

--

[Issue 17602] improve message for deprecated enum comparison

2017-07-06 Thread via Digitalmars-d-bugs

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||diagnostic
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 17612] [REG2.063] Segmentation fault with bad object.d

2017-07-06 Thread via Digitalmars-d-bugs

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Priority|P1  |P5

--

[Issue 17612] New: [REG2.063] Segmentation fault with bad object.d

2017-07-06 Thread via Digitalmars-d-bugs

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

  Issue ID: 17612
   Summary: [REG2.063] Segmentation fault with bad object.d
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: ice
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: dlang-bugzi...@thecybershadow.net

// object.d //
module object;

class Object
{
string toString();
}

class TypeInfo {}
//

$ dmd object.d
object.d(5): Error: undefined identifier 'string'
27160 Segmentation fault  (core dumped) dmd object.d

Introduced in https://github.com/dlang/dmd/pull/1822

--

[Issue 15625] Internal error: backend/elfobj.c 1014

2017-07-06 Thread via Digitalmars-d-bugs

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

Marco Leise  changed:

   What|Removed |Added

 CC||marco.le...@gmx.de

--- Comment #7 from Marco Leise  ---
This patch seems to work for me:

--- dmd2/src/dmd/backend/backconfig.c2016-03-03 11:42:12.0 +0100
+++ dmd2/src/dmd/backend/backconfig.c2017-07-06 16:32:03.540184944 +0200
@@ -95,7 +95,7 @@
 #if TARGET_LINUX
 if (model == 64)
 {   config.exe = EX_LINUX64;
-config.ehmethod = EH_DWARF;
+config.ehmethod = EH_DM;
 config.fpxmmregs = TRUE;
 }
 else

It switches exception handling on 64-bit Linux back from DWARF to the old
druntime method, in case someone needs a quick fix to get this old version
compiling again.

--

[Issue 17599] Abbreviate too long type definitions in error messages

2017-07-06 Thread via Digitalmars-d-bugs

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||diagnostic

--

[Issue 4851] Three suggestions for std.random

2017-07-06 Thread via Digitalmars-d-bugs

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

RazvanN  changed:

   What|Removed |Added

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

--

[Issue 17440] Nullable.nullify() resets referenced object

2017-07-06 Thread via Digitalmars-d-bugs

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

--- Comment #6 from RazvanN  ---
(In reply to Marenz from comment #5)
> Closing? Well.. It is _very_ unexpected that Nullable would just follow a
> reference and kills everything. It's like you add a pointer to an array and
> after setting it to null your pointed object is also reset.
> 
> While this is not a terrible problem to work around, it is quite
> inconsistent and surprising behavior and I think this should really be fixed.
> 
> Do you really want to have such behavior in the std lib?

Nullable wasn't design for reference types. I guess that a check could be added
to reject creating Nullable's from data structures that are not value types.

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

2017-07-06 Thread via Digitalmars-d-bugs

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

--- Comment #4 from Vladimir Panteleev  ---
(In reply to Cy Schubert from comment #3)
> The implementer of inode64 has done a great job of avoiding ABI breakage.
> Applications built before inode64 continue to run due to code in libc to
> detect "old" v.s. "new". Most newly compiled code builds and runs okay. DMD
> is different however because many data structures are replicated in DMD. For
> example stat_t and dirent_t headers have issues.

How does the old/new detection work? Does it look at the ELF timestamp, or
something like that?

Because D has binary releases for FreeBSD (and compiling it from source is a
bit onerous as it requires bootstrapping through an older version of D), we
will probably want to ensure, if possible, that the binary D releases will work
on both new and old versions of the system for a while. This likely means that
we would want to use the old fstat ABI exclusively for a few years, so if it's
possible to opt in to the old ABI, that would probably be the way to go for
now.

Is the new functionality available via a new function akin to fstat64 on Linux?

> I wasn't able to find a stub that DMD D might use to make the actual call.
> If you can point me in the right direction I should be able to do the work
> myself (when I can find the time).

dmd/src/root/file.d is now located at dmd/src/ddmd/root/file.d:

https://github.com/dlang/dmd/blob/master/src/ddmd/root/file.d#L97

For FreeBSD, fstat is defined here:

https://github.com/dlang/druntime/blob/master/src/core/sys/posix/sys/stat.d#L1207

and stat_t here:

https://github.com/dlang/druntime/blob/master/src/core/sys/posix/sys/stat.d#L730-L758

Finally, ino_t is defined here:

https://github.com/dlang/druntime/blob/master/src/core/sys/posix/sys/types.d#L135

I believe that fstat is called by linking to the respective libc, i.e. D does
not perform the syscall directly.

> Having said that, any change would be incompatible with older releases of
> FreeBSD so, a possible solution might be a version check for
> version(FreeBSD12+) -- (FreeBSD uses a version check in
> /usr/include/sys/param.h.) Is there a way to determine which release of
> FreeBSD within DMD D? Such as version(something)?

Not as far as I know. I guess it would require changing the compiler to detect
the FreeBSD release and enable a corresponding version, which would also need
to be added.

--

[Issue 17440] Nullable.nullify() resets referenced object

2017-07-06 Thread via Digitalmars-d-bugs

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

--- Comment #5 from Marenz  ---
Closing? Well.. It is _very_ unexpected that Nullable would just follow a
reference and kills everything. It's like you add a pointer to an array and
after setting it to null your pointed object is also reset.

While this is not a terrible problem to work around, it is quite inconsistent
and surprising behavior and I think this should really be fixed.

Do you really want to have such behavior in the std lib?

--

[Issue 17440] Nullable.nullify() resets referenced object

2017-07-06 Thread via Digitalmars-d-bugs

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

RazvanN  changed:

   What|Removed |Added

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

--

[Issue 17440] Nullable.nullify() resets referenced object

2017-07-06 Thread via Digitalmars-d-bugs

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

--- Comment #4 from RazvanN  ---
Eveyone ok with closing this?

--

[Issue 17600] implicit float->int cast using += operator

2017-07-06 Thread via Digitalmars-d-bugs

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

--- Comment #2 from Simon  ---
I expected "x += y" to be equivalent to "x = x + y" (in which case an error is
generated). Sorry I didn't check the spec, everything is actually correct. (but
really surprising behavior IMHO). My bad.

--

[Issue 17440] Nullable.nullify() resets referenced object

2017-07-06 Thread via Digitalmars-d-bugs

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

--- Comment #3 from Marenz  ---
>Is there any particular reason you need to use Nullify with a class type 
>instead of simply using the class type directly and use "null" to indicate the 
>unset state?

There is no pressing need to do this.
I am having a special array class that wraps every member in a Nullable and of
course it's templated.

So I needed to add a special overload/case for class types to work around that.

It's less a 'need' but more a 'this was very unexpected'.

--

[Issue 17440] Nullable.nullify() resets referenced object

2017-07-06 Thread via Digitalmars-d-bugs

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

--- Comment #2 from Vladimir Panteleev  ---
(In reply to Marenz from comment #0)
> I am not sure if it is desired, but it was highly unintuitive and unexpected
> for me:
> 
> If you use Nullable with a class type and call .nullify(), all members of
> the class are set to the uninitialized state. Example:

That is almost certainly not intended, and (as RazvanN wrote) is because the
Nullable implementation makes no attempt to do anything different when used
with a class. What happens is that it calls object.destroy on the class, which
instead of setting the class reference to null, it clobbers the class data.

However, I think your example is also incorrect, because it accesses the value
of a nullified object.

Is there any particular reason you need to use Nullify with a class type
instead of simply using the class type directly and use "null" to indicate the
unset state?

--

[Issue 17227] deprecation messages building Phobos

2017-07-06 Thread via Digitalmars-d-bugs

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

Seb  changed:

   What|Removed |Added

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

--- Comment #2 from Seb  ---
Fixed with https://github.com/dlang/phobos/pull/5546 - unfortunately forgot to
link the issue in the PR, so it won't show up in the changelog. Sorry.

--

[Issue 11594] synchronized causing segfault instead of Error.

2017-07-06 Thread via Digitalmars-d-bugs

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

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

https://github.com/dlang/druntime/commit/a2ead6dd04efdfeb283b72daf167e85fe8db9c49
Fix issue 11594: Check if the monitor is null in _d_monitorenter

In case of

```
synchronized (null)
{
// ...
}
```

runtime will try to access __monitor field on a null,
without checking if it's a null and it will segfault,
leaving programmer clueless.

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

--

[Issue 11594] synchronized causing segfault instead of Error.

2017-07-06 Thread via Digitalmars-d-bugs

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

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

   What|Removed |Added

 Resolution|WORKSFORME  |FIXED

--

[Issue 17369] [Module std.traits] Documentation lists ditto in table

2017-07-06 Thread via Digitalmars-d-bugs

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

RazvanN  changed:

   What|Removed |Added

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

--- Comment #1 from RazvanN  ---
PR : https://github.com/dlang/phobos/pull/5558

--

[Issue 17611] New: core.demangle cannot demangle delegates with function attributes

2017-07-06 Thread via Digitalmars-d-bugs

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

  Issue ID: 17611
   Summary: core.demangle cannot demangle delegates with function
attributes
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: r.sagita...@gmx.de

The symbol "_D4test2dgDxFiYd" is not demangled by core.demangle or ddemangle.

It should demangle as "double delegate(int, ...) const test.dg".

--

41 matches

Mail list logo