[Issue 15007] core.atomic match C++11

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

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

Manu  changed:

   What|Removed |Added

   Keywords||industry

--

[Issue 8985] Get default parameter value as alias

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

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

Manu  changed:

   What|Removed |Added

   Keywords||industry

--

[Issue 13428] Add template to perform appropriate substitution for inout when it appears in a type

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

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

Manu  changed:

   What|Removed |Added

   Keywords||industry

--

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

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

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

Manu  changed:

   What|Removed |Added

   Keywords||industry

--

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

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

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

Manu  changed:

   What|Removed |Added

   Keywords||industry

--

[Issue 15473] C++ mangling problem

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

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

Manu  changed:

   What|Removed |Added

   Keywords||industry

--

[Issue 16107] [ICE] - Internal error: backend/cgcod.c 2297

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

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||industry

--

[Issue 15511] fork: Invalid memory operation

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

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 17949] ICE in dmangle.d

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

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 16189] Optimizer bug, with simple test case

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

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 16317] Wrong binop evaluation/load order when optimizing

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

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 17942] Enums are evaluated differently in global scope

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

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 18055] exception handling cause EXC_BAD_ACCESS when linking against shared libraries using vibe

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

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 17949] ICE in dmangle.d

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

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

Mike Franklin  changed:

   What|Removed |Added

 CC||slavo5...@yahoo.com

--- Comment #1 from Mike Franklin  ---
See https://run.dlang.io/is/7Vljp1

This needs a better test case.  I can't reproduce it.

--

[Issue 16107] [ICE] - Internal error: backend/cgcod.c 2297

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

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

Mike Franklin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--

[Issue 16107] [ICE] - Internal error: backend/cgcod.c 2297

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

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

--- Comment #8 from Mike Franklin  ---
> import std.stdio, std.traits;
> 
> struct TreeItemChildren(T){}
> 
> struct TreeItemSiblings(T){}
> 
> class Foo
> {
> alias TreeItemType = typeof(this);
> 
> TreeItemSiblings!TreeItemType _siblings;// remove this decl
> TreeItemChildren!TreeItemType _children;// or this one  : OK
> }
> 
> template Bug(T)
> {
> bool check()
> {
> bool result;
> import std.meta: aliasSeqOf;
> import std.range: iota;
> 
> foreach(i;  aliasSeqOf!(iota(0, T.tupleof.length)))
> {
> alias MT = typeof(T.tupleof[i]);
> static if (is(MT == struct))
> result |= Bug!MT;   // result = result | ... : OK
> if (result) break; // remove this line   : OK
> 
> }
> return result;
> }
> enum Bug = check();
> }
> 
> void main()
> {
> assert(!Bug!Foo);
> }

According to https://run.dlang.io/is/kosY23, this has been fixed since 2.070.2

--

[Issue 18242] DMD Segmentation fault.

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

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

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

https://github.com/dlang/dmd/commit/94b728c0f9d1071d30f87ff0e261cfeb0a1c2ac1
Fix issue 18242 - Warn if object.Exception is missing

https://github.com/dlang/dmd/commit/2b4c6269828213655f624134ccd8af27c1395737
Merge pull request #8050 from LemonBoy/throw-miss

Fix issue 18242 - Warn if object.Exception is missing
merged-on-behalf-of: Mike Franklin 

--

[Issue 18242] DMD Segmentation fault.

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

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

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

   What|Removed |Added

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

--

[Issue 16107] [ICE] - Internal error: backend/cgcod.c 2297

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

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

Mike Franklin  changed:

   What|Removed |Added

 CC||slavo5...@yahoo.com

--- Comment #7 from Mike Franklin  ---
> bool check()
> {
>bool result = false;
>
>result |= false;   // result = result | ... : OK
>if (result) goto ret; // remove this line   : OK
>
>result |= false;   // result = result | ... : OK
>if (result) {} // remove this line   : OK
>
>ret: return true;
> }
> 
> enum e = check();

According to https://run.dlang.io/is/98Uf5T, this has been working since
2.067.1.

--

[Issue 18597] more unsafe unaligned pointer errors

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

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

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

   What|Removed |Added

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

--

[Issue 18597] more unsafe unaligned pointer errors

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

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

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

https://github.com/dlang/dmd/commit/3afbfb2c1b6328c18bdfd1f122091a74e22f9d69
fix Issue 18597 - more unsafe unaligned pointer errors

https://github.com/dlang/dmd/commit/a0764d9ea0e7b3132d0a362b2f32a6e74e6e76e0
Merge pull request #8019 from WalterBright/fix18597

fix Issue 18597 - more unsafe unaligned pointer errors
merged-on-behalf-of: Mike Franklin 

--

[Issue 17862] std.random.XorshiftEngine.min is wrong when bits == 32

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

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

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

https://github.com/dlang/phobos/commit/fa9215198226a1377fcb06ab2051319e3710b72a
Fix Issue 17862 - std.random.XorshiftEngine.min is wrong when bits == 32

XorshiftEngine.min is defined as 0 regardless of template parameters
but an XorshiftEngine cannot produce a value of zero if its internal
state has the same number of bits as the output element type.

https://github.com/dlang/phobos/commit/cc256d8dc93ffe3d1e5149b3438b60aa8d01cd87
Merge pull request #5746 from n8sh/xorshift-fix

Fix Issue 17862 - std.random.XorshiftEngine.min is wrong when bits == 32
merged-on-behalf-of: Andrei Alexandrescu 

--

[Issue 18110] most of phobos should be @safe-ly useable

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

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 18596] std.random.unpredictableSeed could use something better than MinstdRand0

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

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

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

   What|Removed |Added

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

--

[Issue 18596] std.random.unpredictableSeed could use something better than MinstdRand0

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

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

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

https://github.com/dlang/phobos/commit/f39686c771955c912273f9f15d2ae37862f885a8
Partially Fix Issue 18596: use arc4random when available for unpredictableSeed

https://github.com/dlang/phobos/commit/b87d28f2c77e0d56e313fa120e3cab2198dde24f
Merge pull request #6267 from n8sh/unpredictableSeedOf-arc4random

Partially Fix Issue 18596: use arc4random when available for unpredictableSeed
merged-on-behalf-of: unknown

--

[Issue 18444] [DIP25][DIP1000] Tracking issue for: "The implementation doesn't match DIPs 25/1000"

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

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

Carsten Blüggel  changed:

   What|Removed |Added

 Depends on|17512, 18478|


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17512
[Issue 17512] [REG 2.073] [DIP1000] Error on bad interplay of 'auto ref' and
'return' attribute deduction.
https://issues.dlang.org/show_bug.cgi?id=18478
[Issue 18478] Spurious "escapes a reference to local variable" error in
function that does not return by reference
--

[Issue 17512] [REG 2.073] [DIP1000] Error on bad interplay of 'auto ref' and 'return' attribute deduction.

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

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

Carsten Blüggel  changed:

   What|Removed |Added

 Blocks|18444   |


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18444
[Issue 18444] [DIP25][DIP1000] Tracking issue for: "The implementation doesn't
match DIPs 25/1000"
--

[Issue 18478] Spurious "escapes a reference to local variable" error in function that does not return by reference

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

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

Carsten Blüggel  changed:

   What|Removed |Added

 Blocks|18444   |


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18444
[Issue 18444] [DIP25][DIP1000] Tracking issue for: "The implementation doesn't
match DIPs 25/1000"
--

[Issue 18187] std.uni.Grapheme should be usable in @safe

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

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

--- Comment #3 from John Colvin  ---
https://github.com/dlang/phobos/pull/6330

--

[Issue 17360] std.range.only doesn't allow ref access

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

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

--- Comment #1 from John Colvin  ---
Adding `auto ref` to `front`, `back` and `opIndex` is an obvious fix but falls
foul of https://issues.dlang.org/show_bug.cgi?id=17512

--

[Issue 18648] Document the type of std.stdio.stdin and friends

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #1 from Seb  ---
PR https://github.com/dlang/phobos/pull/6329

--

[Issue 18648] Document the type of std.stdio.stdin and friends

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

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

|  changed:

   What|Removed |Added

   Priority|P1  |P3

--

[Issue 18648] New: Document the type of std.stdio.stdin and friends

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

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

  Issue ID: 18648
   Summary: Document the type of std.stdio.stdin and friends
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: dhase...@gmail.com

For those familiar with D, you can look at the unittest documentation for
std.stdio.stdin and reasonably guess that it's a std.stdio.File. That's not
explicitly stated. The template used to initialize it is not documented. So a
new user might reasonably look at the docs and be confused about what they can
actually do with the variable. They might have to ask on D.learn and wait an
hour for a response before they can make progress, because they aren't
confident or perspicacious or knowledgeable enough to look at the Phobos source
code or add in a `pragma(msg, typeof(stdin).stringof)`.

Is this another case of "we might want to change the type later so we can't
document it"?

--

[Issue 17512] [REG 2.073] [DIP1000] Error on bad interplay of 'auto ref' and 'return' attribute deduction.

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

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

John Colvin  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||john.loughran.colvin@gmail.
   ||com
 Resolution|FIXED   |---

--- Comment #7 from John Colvin  ---
This seems to not to be totally resolved in very similar cases:

struct S0(T)
{
int a;
auto ref immutable(int) getA() { return a; }
}

alias A = S0!int;

test.d(4): Error: function type pure nothrow @nogc return @safe
immutable(int)() has return but does not return any indirections

--

[Issue 18444] [DIP25][DIP1000] Tracking issue for: "The implementation doesn't match DIPs 25/1000"

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

https://issues.dlang.org/show_bug.cgi?id=18444
Issue 18444 depends on issue 17512, which changed state.

Issue 17512 Summary: [REG 2.073] [DIP1000] Error on bad interplay of 'auto ref' 
and 'return' attribute deduction.
https://issues.dlang.org/show_bug.cgi?id=17512

   What|Removed |Added

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

--

[Issue 16426] Templated opAssign do not forward on Alias this.

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

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

John Hall  changed:

   What|Removed |Added

 CC||john.michael.h...@gmail.com

--- Comment #1 from John Hall  ---
Structs have opAssign defined by default. Alias this only forwards undefined
lookups. Below is a workaround.

import std.stdio : writeln;

struct Base{
void opAssign(T)(T x){
writeln("assigning : ",x);
}   
}
struct Derived{
Base parent;
alias parent this;

void opAssign(T)(T x){
parent = x;
}   
}

void main()
{
Base a;
a = 10; //ok

Derived b;
b = 20; //Error
}

--

[Issue 14286] `alias this` not considered sub-typing in is() expression

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

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

John Hall  changed:

   What|Removed |Added

 CC||john.michael.h...@gmail.com

--- Comment #1 from John Hall  ---
The issue seems to be related to templated variables in alias this. Not an
issue without templates.

struct V
{
}

struct S {
V x;
alias x this;
}

void main()
{
S a;
static if(is(typeof(a) : V)) 
pragma(msg, "yep"); //prints "yep"
else
pragma(msg, "nope");
}

--

[Issue 18187] std.uni.Grapheme should be usable in @safe

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

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

--- Comment #2 from Seb  ---
That's great then.
There have been a few changed in std.uni recently, e.g.

https://github.com/dlang/phobos/pull/6041

So maybe these changes made the test @safe
There's also the fact that Phobos's testsuite now uses -dip1000 to test
std.uni, but I just checked and it seems like the tests are now @safe even
without -dip1000 :)

Up for a quick PR?

--

[Issue 18187] std.uni.Grapheme should be usable in @safe

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

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

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com

--- Comment #1 from John Colvin  ---
Do you have an example? Changing the unittests for those 2 functions to be
@safe just works for me.

--

[Issue 18256] Using std.range.put to put a character into a dchar[] segfaults

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

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

John Colvin  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from John Colvin  ---
This is nothing to do with `put`. As far as `put` is concerned it's been given
a mutable buffer.

A segfault is a good outcome when you try to write to a string literal.

Do you mean a compile-time error? If so:

I suggest opening an enhancement request for something like "Disallow obvious
cases of writing to string literals" or similar, but I doubt you'll get much
traction with it as it's only practically possible to do in trivial cases and
only occurs when someone has already broken the rules by casting away
immutable.

If you mean a runtime error:

That's what the segfault is for. There's no need to duplicate the work that the
CPU does (with all the performance implications that would have).


I'm gonna close this again, re-open if you're really motivated but I think a
new issue would be better, without the confusion of `put`.

--

[Issue 18256] Using std.range.put to put a character into a dchar[] segfaults

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #2 from Jack Stouffer  ---
(In reply to John Colvin from comment #1)
> You're writing to a string literal, which isn't allowed.
> 
> change to 
> 
> dchar[] a = "aaa"d.dup;
> 
> and it works fine.

I'm aware it's not allowed. The operative term was segfault, as opposed to
giving an error.

--

[Issue 18256] Using std.range.put to put a character into a dchar[] segfaults

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

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

John Colvin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||john.loughran.colvin@gmail.
   ||com
 Resolution|--- |INVALID

--- Comment #1 from John Colvin  ---
You're writing to a string literal, which isn't allowed.

change to 

dchar[] a = "aaa"d.dup;

and it works fine.

--

[Issue 18525] Constraint on std.algorithm.mutation.remove fails with char[]

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

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

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com
   Hardware|x86_64  |All
 OS|Mac OS X|All

--- Comment #1 from John Colvin  ---
Totally separate algorithms required for this case, because of auto-decoding.

https://github.com/dlang/phobos/pull/6328

--

[Issue 17906] Deprecated Language features should be allowed without a deprecation in a deprecated scope

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

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

--- Comment #6 from Seb  ---
Copying Mathias's from GH (in case it gets lost)

The bug report was more general (before you changed the title).
I took delete as an example, because it's what hits me, but I'm pretty sure it
affects other deprecations.
For example:

---
deprecated void main ()
{
int i, o;
switch (i)
{
case 1:
o = 1;
case 2:
o = 2;
break;
default:
}
}
---

--

[Issue 18645] DMD segmentation fault

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

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

--- Comment #2 from Mihails Strasuns 
 ---
Even more reduced case:

```
immutable INIT = 42;

enum A
{
x = INIT,
y
}
```

--

[Issue 18645] DMD segmentation fault

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

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

--- Comment #1 from Mihails Strasuns 
 ---
This crashes 2.079 and 2.078, but compiles on 2.071 (haven't checked versions
in between yet):

```
enum A
{
x = global,
y
}

static global = INIT;

immutable INIT = 42;
```

--

[Issue 18647] New: Use of delete should be allowed without a deprecation in a deprecated scope

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

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

  Issue ID: 18647
   Summary: Use of delete should be allowed without a deprecation
in a deprecated scope
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com
Blocks: 17906

deprecated void main ()
{
Object o = new Object;
delete o;
}


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17906
[Issue 17906] Deprecated Language features should be allowed without a
deprecation in a deprecated scope
--

[Issue 17906] Deprecated Language features should be allowed without a deprecation in a deprecated scope

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

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

Seb  changed:

   What|Removed |Added

 Depends on||18647


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18647
[Issue 18647] Use of delete should be allowed without a deprecation in a
deprecated scope
--

[Issue 17906] Deprecated Language features should be allowed without a deprecation in a deprecated scope

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

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

Seb  changed:

   What|Removed |Added

Summary|Use of delete should be |Deprecated Language
   |allowed without a   |features should be allowed
   |deprecation in a deprecated |without a deprecation in a
   |scope   |deprecated scope

--

[Issue 18637] [scope][DIP1000] "copying & i into allocated memory escapes a reference to local variable i" where it's inappropriate

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

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

Carsten Blüggel  changed:

   What|Removed |Added

   Keywords|rejects-valid, spec |
 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--

[Issue 18627] std.complex is a lot slower than builtin complex types at number crunching

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

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

--- Comment #9 from ponce  ---
I think at the very least std.complex should contain a function to divide
Complex without the additional precision provided by the check with the 2
fabs().

People that want speed could opt-in, and others will enjoy increased precision
without noticing.

--

[Issue 18607] using labelled continue in tuple foreach can break pure and @safe

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

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

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

https://github.com/dlang/dmd/commit/5ccd55ff54eb1c3502f0a435b48c6c63122ce213
fix Issue 18607 - using labelled continue in tuple foreach can break pure and
@safe

https://github.com/dlang/dmd/commit/b19832e0f150461a5d39204d8efb49871756e38d
Merge pull request #8061 from WalterBright/fix18607

fix Issue 18607 - using labelled continue in tuple foreach can break …
merged-on-behalf-of: Walter Bright 

--

[Issue 18607] using labelled continue in tuple foreach can break pure and @safe

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

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

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

   What|Removed |Added

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

--

[Issue 18604] in parameter storage class should be deprecated

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

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

Carsten Blüggel  changed:

   What|Removed |Added

 CC||chi...@posteo.net

--

[Issue 18607] using labelled continue in tuple foreach can break pure and @safe

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

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

Carsten Blüggel  changed:

   What|Removed |Added

 CC||chi...@posteo.net

--

[Issue 18553] Inline assembler: CR2, CR3 control registers not available in 64-bit code

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

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

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

https://github.com/dlang/dmd/commit/77bab61f3c4ad2fbd5cef4289677e926ff7771ef
Fix issue 18553 - Allow mov reg64,crn and mov crn,reg64

Also add support for reading/writing the CR8 register on x64.

https://github.com/dlang/dmd/commit/a73766db46abe86fd0c2e74ce60920b0a50669f0
Merge pull request #8017 from LemonBoy/b18553

Fix issue 18553 - Allow mov reg64,crn and mov crn,reg64
merged-on-behalf-of: Walter Bright 

--

[Issue 18553] Inline assembler: CR2, CR3 control registers not available in 64-bit code

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

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

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

   What|Removed |Added

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

--

[Issue 18646] Recursive template expansion incorrectly reported for certain templated classes

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

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

--- Comment #1 from Ontonator  ---
It also should be noted that the aliases don't have to be aliases. Any
reference to the class works (e.g. variable with type, method with parameter or
return type, etc.).

--

[Issue 18646] Recursive template expansion incorrectly reported for certain templated classes

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

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

Ontonator  changed:

   What|Removed |Added

 CC||publicna...@gmail.com

--

[Issue 18646] New: Recursive template expansion incorrectly reported for certain templated classes

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

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

  Issue ID: 18646
   Summary: Recursive template expansion incorrectly reported for
certain templated classes
   Product: D
   Version: D2
  Hardware: x86_64
OS: Mac OS X
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: publicna...@gmail.com

With certain configurations of templated classes/interfaces with refinements, a
recursive template expansion is incorrectly reported. This only occurs if the
classes are in a certain order.

To reproduce:

1) Create a D file and enter the following code:

void main() {}

class SuperClass {}

class TemplatedClass(T : SuperClass) {}

class A : SuperClass {
alias T = TemplatedClass!B;
}

class B : SuperClass {
alias T = TemplatedClass!C;
}

class C : SuperClass {}

2) Compile the code.

Actual result:
test.d(12): Error: class `test.TemplatedClass(T : SuperClass)` recursive
template expansion
test.d(12):while looking for match for TemplatedClass!(C)

Expected result: no error

Build 2018-03-22 on Mac OS 10.12.6 on DMD64 D Compiler v2.079.0

On the other hand, the following two examples both work:

1) Changed specialisation to constraint:

void main() {}

class SuperClass {}

class TemplatedClass(T)
if (is(T : SuperClass)) {}

class A : SuperClass {
alias T = TemplatedClass!B;
}

class B : SuperClass {
alias T = TemplatedClass!C;
}

class C : SuperClass {}

2) Reordered:

void main() {}

class SuperClass {}

class TemplatedClass(T : SuperClass) {}

class B : SuperClass {
alias T = TemplatedClass!C;
}

class A : SuperClass {
alias T = TemplatedClass!B;
}

class C : SuperClass {}

--