[Issue 18692] New: assignment of std.regex.Captures reads freed memory from 2.072.0 to 2.078.3 inclusive

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

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

  Issue ID: 18692
   Summary: assignment of std.regex.Captures reads freed memory
from 2.072.0 to 2.078.3 inclusive
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: martin.do...@hitachivantara.com

When I was working on:

Issue 18691: assigning a std.regex.Captures with 3 or more groups causes double
free

... I couldn't understand how this change:

https://github.com/dlang/phobos/commit/872673d5570f1ee79df4b9e47d8f3d2cf4e49536

... the "Use ref-counting for Captures struct" from @DmitryOlshansky, could be
right.  How can he get away with having the _refcount that applies to
big_matches not stored in an object with the same lifetime as big_matches?  I
have about two days' familiarity with D, so I assume I'm missing something. 
That said, here's a program that goes wrong with the first release of dmd that
included that change.  First, it working on the preceding version.

martind@swiftboat:~/tmp/D134366$ cat two_years.d
import std.regex;

void main() {
auto rx = regex("()()()");
auto ma = "".matchFirst(rx);
auto ma2 = ma;
ma = ma2;
ma[1];
}
martind@swiftboat:~/tmp/D134366$ dmd --version
DMD64 D Compiler v2.071.0
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
martind@swiftboat:~/tmp/D134366$ dmd two_years.d && MALLOC_PERTURB_=1
./two_years 
martind@swiftboat:~/tmp/D134366$ 

2.072.0 was afflicted by
https://digitalmars.com/d/archives/digitalmars/D/dmd_or_phobos_were_broken_in_ubuntu_16.10_d-apt_294148.html,
hence the extra shared library parameters, which make no difference on 2.071.0.

martind@balance:~/tmp/D134366$ dmd --version
DMD64 D Compiler v2.072.0
Copyright (c) 1999-2016 by Digital Mars written by Walter Bright
martind@balance:~/tmp/D134366$ dmd -defaultlib=libphobos2.so -fPIC two_years.d
&& MALLOC_PERTURB_=1 ./two_years 
core.exception.RangeError@std/regex/package.d(565): Range violation

??:? _d_arraybounds [0xf693d091]
??:? std.regex.__array [0xf68f6f1e]
??:? std.regex.Captures!(immutable(char)[],
ulong).Captures.opIndex!().opIndexinout(pure nothrow @trusted
inout(immutable(char)[]) function(ulong)) [0xb4f37081]
??:? _Dmain [0xb4f0f60f]
??:? _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv
[0xf696d68f]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) [0xf696d5bb]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll() [0xf696d634]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).tryExec(scope void delegate()) [0xf696d5bb]
??:? _d_run_main [0xf696d51f]
??:? main [0xb4f3a67f]
??:? __libc_start_main [0xf55f52b0]
martind@balance:~/tmp/D134366$ 

valgrind is unhappy too and more verbosely, making it explicit that the problem
is reading from freed memory.  The problems continue up to and including
2.078.3 but disappear for 2.079.0 and are absent in master.  I suspect that the
@MartinNowak change I finger in Issue 18691 fixed this particular reference
counting issue at the expense of introducing that one.

--

[Issue 18691] assigning a std.regex.Captures with 3 or more groups causes double free

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

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

--- Comment #3 from Martin Dorey  ---
If you're interested in this bug, then you're likely to also be interested in:

Issue 18692: assignment of std.regex.Captures reads freed memory from 2.072.0
to 2.078.3 inclusive

--

[Issue 18694] New: pure functions using static/global structs with no fields should pass compilation

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

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

  Issue ID: 18694
   Summary: pure functions using static/global structs with no
fields should pass compilation
   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:

struct S { enum int x = 42; }
static S dummy;
pure int fun(int x)
{
return dummy.x + x;
}

This code fails to compile:

Error: pure function onlineapp.fun cannot access mutable static data dummy

However, there is no mutable data to talk about in the first place so the code
should pass compilation.

The technique of using static data for a zero-sized struct is frequently used
in the allocator framework.

--

[Issue 18694] pure functions using static/global structs with no fields should pass compilation

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

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

RazvanN  changed:

   What|Removed |Added

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

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

--

[Issue 18688] Constructors shouldn't have implicit super call if it throws

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

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 18694] pure functions using static/global structs with no fields should pass compilation

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

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 18615] Rebindable!A doesn't use class A's opEquals (returns a is b instead)

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

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

--- Comment #4 from Simon Na.  ---
I've got a PR for Phobos ready at:
https://github.com/dlang/phobos/pull/6370

The root cause was that union equality is always bitwise. The compiler issue is
15828, and the consensus seems that implicit union comparison should be a
compiler error:
https://issues.dlang.org/show_bug.cgi?id=15828

My PR for 18615 works independently of 15828 because I compare the class
reference inside the union explicitly with == against rhs's class reference.

> Cool! Please let us know if you hit any road bumps etc. ;-)

Thanks, it's been smooth sailing so far!

-- Simon

--

[Issue 18615] Rebindable!A doesn't use class A's opEquals (returns a is b instead)

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

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

Simon Naarmann  changed:

   What|Removed |Added

   Keywords||pull

--

[Issue 15828] DMD should refuse comparing unions

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

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

Simon Na.  changed:

   What|Removed |Added

 CC||eiderd...@gmail.com

--- Comment #3 from Simon Na.  ---
I agree that implicitly comparing unions should be a compiler error.

The spec doesn't mention == for unions at all:
https://dlang.org/spec/expression.html#compare_expressions

The failure to call opEquals on a class reference in the union caused
https://issues.dlang.org/show_bug.cgi?id=18615
Rebindable!A doesn't use class A's opEquals (returns a is b instead).

I've submitted a PR for Phobos to fix 18615 by explicitly comparing the class
references in Rebindable's union:
https://github.com/dlang/phobos/pull/6370

I hope that such removal of implicit union comparision eases the pain of fixing
this 15828. :-)

--

[Issue 17991] ICE with imports without module

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

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

RazvanN  changed:

   What|Removed |Added

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

--- Comment #1 from RazvanN  ---
I cannot reproduce. Compiling on git HEAD (Ubuntu 16.04) from toplevel with the
command:

> dmd a/b/package.d a/b/c.d a/e/f.d

Yields: 

a/e/f.d(2): Error: module `c` from file a/b/c.d must be imported with 'import
c;'

Modifying f.d to `import a.b, c;` results in successful compilation. Please
close if you cannot reproduce.

--

[Issue 18692] assignment of std.regex.Captures reads freed memory from 2.072.0 to 2.078.3 inclusive

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

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

Dmitry Olshansky  changed:

   What|Removed |Added

 CC||dmitry.o...@gmail.com

--- Comment #1 from Dmitry Olshansky  ---
> ... the "Use ref-counting for Captures struct" from @DmitryOlshansky, could 
> be right.  How can he get away with having the _refcount that applies to 
> big_matches not stored in an object with the same lifetime as big_matches?  I 
> have about two days' familiarity with D, so I assume I'm missing something.  
> That said, here's a program that goes wrong with the first release of dmd 
> that included that change.  First, it working on the preceding version.

Indeed looking at it now, it doesn't seem right. Awfully so.

It likely passed though because captures is typically a temporary.

Instead it should allocate and equivalent of 

struct Payload {
 uint refcount;
 Group[0] matches;
}

Thanks for reporting!

--

[Issue 17965] Unexplained usage of the FPU while function result already in right XMM registers

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

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

Citrus  changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #4 from Citrus  ---
This is a side-effect of a silly optimization that turns Point into a complex
number instead of a double[2] as one would expect.
You can see by yourself how the codegen improves if `TYcdouble` is replaced by
`TYdouble` in `elstruct` (in the `if (I64 && targ1 && targ2)` branch):

---
   33090:   55  push   rbp
   33091:   48 8b ecmovrbp,rsp
   33094:   48 8d 05 b5 bf 02 00learax,[rip+0x2bfb5]# 5f050
<_D3foo5Point6__initZ>
   3309b:   66 0f 28 00 movapd xmm0,XMMWORD PTR [rax]
   3309f:   5d  poprbp
   330a0:   c3  ret
---

But I'm pretty sure this change may wreak havoc due to various concerns
regarding the alignment and scalar broadcasting.

The bottom line here is:

> You can avoid such FPU <=> XMM round trips by using the LDC compiler.

Or GDC, everything but DMD is fine.

--

[Issue 18692] assignment of std.regex.Captures reads freed memory from 2.072.0 to 2.078.3 inclusive

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

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

Dmitry Olshansky  changed:

   What|Removed |Added

   Keywords||pull
URL||https://github.com/dlang/ph
   ||obos/pull/6379

--

[Issue 18691] assigning a std.regex.Captures with 3 or more groups causes double free

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

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

Dmitry Olshansky  changed:

   What|Removed |Added

   Keywords||pull
URL||https://github.com/dlang/ph
   ||obos/pull/6379
 CC||dmitry.o...@gmail.com

--- Comment #5 from Dmitry Olshansky  ---
This is the same issue - bogus CoW implementation.
PR is out

--

[Issue 18691] assigning a std.regex.Captures with 3 or more groups causes double free

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

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

--- Comment #4 from Dmitry Olshansky  ---
*** Issue 18692 has been marked as a duplicate of this issue. ***

--

[Issue 18692] assignment of std.regex.Captures reads freed memory from 2.072.0 to 2.078.3 inclusive

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

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

Dmitry Olshansky  changed:

   What|Removed |Added

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

--- Comment #2 from Dmitry Olshansky  ---


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

--

[Issue 18688] Constructors shouldn't have implicit super call if it throws

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

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

RazvanN  changed:

   What|Removed |Added

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

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

--

[Issue 9646] std.algorithm.splitter for strings has opportunities for improvement

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #5 from Seb  ---
New numbers:

DMD (2.079.0):

std.algorithm.splitter took 2 secs, 736 ms, 348 μs, and 3 hnsecs
MySplitter took 3 secs, 176 ms, 18 μs, and 9 hnsecs

LDC (1.8.0):

>  ldc -O4 -mcpu=native -release -flto=full

std.algorithm.splitter took 1 sec, 954 ms, 444 μs, and 9 hnsecs
MySplitter took 1 sec, 635 ms, 394 μs, and 8 hnsecs

So I there's still an opportunity for improvement with LDC.

--

[Issue 18438] hasStaticMember fails with a T* while hasMember passes

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

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

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

   What|Removed |Added

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

--

[Issue 18438] hasStaticMember fails with a T* while hasMember passes

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

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

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

https://github.com/dlang/phobos/commit/4e222b856b30a41d330067a2bb5c6cf38a80de1f
Fix issue 18438 - Handle T* in hasStaticMember

hasMember treats T* as T, so lets make hasStaticMember do the
same

https://github.com/dlang/phobos/commit/0372d48dc00c2f4e6c7b9fa5ac101a43810e3222
Merge pull request #6179 from aliak00/has-static-member

Fix issue 18438 - Handle T* in hasStaticMember like hasMember
merged-on-behalf-of: Nathan Sashihara 

--

[Issue 13568] refactor std.format to eliminate redundant dependencies if the format string doesn't ask for it

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com
Summary|Support compile-time format |refactor std.format to
   |strings in std.format   |eliminate redundant
   ||dependencies if the format
   ||string doesn't ask for it

--- Comment #13 from Seb  ---
> This is not completely fixed yet.  Part II is to refactor std.format to 
> eliminate redundant dependencies if the format string doesn't ask for it

This should have been a separate issue (bugzilla even allows meta issues that
depend on other issues), but I renamed this for now.

--

[Issue 15451] dlang.org should use cache busting

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

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

Seb  changed:

   What|Removed |Added

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

--- Comment #1 from Seb  ---
This looks good since Brad enabled it ~ six months ago: 

https://imgur.com/a/6wYJt

--

[Issue 15449] CSS and JS files should be minified and concatenated

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
The currently optional solution to make POST request to some external site
isn't enabled because it doesn't work well.

I just looked at our options in 2018 and it looks really bad.
Everyone just seems to be packaging huge JS bundles or Java archives .. Great
:/
I found:

- YUI (Java)
- Closure Compiler (Java)
- https://github.com/mishoo/UglifyJS2 (NPM)
- https://github.com/matthiasmullie/minify (PHP)

I will pick YUI because it's in Debian stable
(https://packages.debian.org/wheezy/yui-compressor) and supports JS + CSS.

--

[Issue 15449] CSS and JS files should be minified and concatenated

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

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

--- Comment #2 from Seb  ---
https://github.com/dlang/dlang.org/pull/2311 for the minification.

I opened https://issues.dlang.org/show_bug.cgi?id=18695 to track the
concatenation (might be trickier because not everything is needed on every
page)

--

[Issue 18695] New: Concatenate CSS + JS files during build

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

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

  Issue ID: 18695
   Summary: Concatenate CSS + JS files during build
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

Separate network requests aren't free, each incurs non-trivial overhead.

--

[Issue 18694] pure functions using static/global structs with no fields should pass compilation

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

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

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

   What|Removed |Added

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

--

[Issue 18694] pure functions using static/global structs with no fields should pass compilation

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

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

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

https://github.com/dlang/dmd/commit/55eb8544850f4024280f1661ad0379cd9a43052b
Fix Issue 18694 - pure functions using static/global structs with no fields
should pass compilation

https://github.com/dlang/dmd/commit/0e33d7cc27c489e8121823c1a38d5d6b2781f4c5
Merge pull request #8101 from RazvanN7/Issue_18694

Fix Issue 18694 - pure functions using static/global structs with no fields
should pass compilation
merged-on-behalf-of: Andrei Alexandrescu 

--

[Issue 18638] The main override of std.range.zip could infer @nogc and nothrow

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

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

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

https://github.com/dlang/phobos/commit/259cf754bb42ad30039c1b82ea6d43109ecc6c9b
Fix Issue 18638 - The main override of std.range.zip could infer @nogc and
nothrow

ZipShortest impl. a bit more efficient than Zip because doesn't need
switch statements with code for each stopping policy. Also in some cases
only needs to check one range for `empty` or `length` rather than all.
Also correctly handles `back` when ranges have unequal lengths.

https://github.com/dlang/phobos/commit/1db9cbedd8c1bf29256c60776b7cba214fb1cc0a
Merge pull request #6307 from n8sh/zip-shortest

Fix Issue 18638 - The main override of std.range.zip could infer @nogc and
nothrow
merged-on-behalf-of: Jack Stouffer 

--

[Issue 18638] The main override of std.range.zip could infer @nogc and nothrow

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

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

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

   What|Removed |Added

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

--

[Issue 15448] dlang.org should use gzip compression on all text files

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
That's no longer an issue since Jan enabled it a few months ago:

https://imgur.com/a/zFSfu

Though HTML Expiration period could be a bit higher. I will write Jan.

--

[Issue 18693] New: std.math.rndtonl and core.math.rndtonl result in link errors

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

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

  Issue ID: 18693
   Summary: std.math.rndtonl and core.math.rndtonl result in link
errors
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

import std.stdio;
static import core.math;

void main()
{
writeln(core.math.rndtonl(9.0));
}

It seems like this is a DMC only function.

--

[Issue 17206] [Tracking] Check that opEquals and toHash are both defined or neither are defined

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

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

Issue 18677 Summary: std.datetime.date.Date has opCmp but no toHash
https://issues.dlang.org/show_bug.cgi?id=18677

   What|Removed |Added

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

--

[Issue 18677] std.datetime.date.Date has opCmp but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

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

--- Comment #2 from Jack Stouffer  ---
https://github.com/dlang-community/D-Scanner/issues/575

--

[Issue 17206] [Tracking] Check that opEquals and toHash are both defined or neither are defined

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

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

Issue 18678 Summary: std.datetime.date.TimeOfDay has opCmp but no toHash
https://issues.dlang.org/show_bug.cgi?id=18678

   What|Removed |Added

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

--

[Issue 18678] std.datetime.date.TimeOfDay has opCmp but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

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

--- Comment #4 from Jack Stouffer  ---
https://github.com/dlang-community/D-Scanner/issues/575

--

[Issue 18676] std.datetime.date.DateTime has opCmp but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID
Summary|std.datetime.date.DateTime  |std.datetime.date.DateTime
   |has opEquals but no toHash  |has opCmp but no toHash

--- Comment #2 from Jack Stouffer  ---
https://github.com/dlang-community/D-Scanner/issues/575

--

[Issue 17206] [Tracking] Check that opEquals and toHash are both defined or neither are defined

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

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

Issue 18676 Summary: std.datetime.date.DateTime has opCmp but no toHash
https://issues.dlang.org/show_bug.cgi?id=18676

   What|Removed |Added

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

--

[Issue 18672] Error in @safe transitive propagation with associative arrays

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

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

RazvanN  changed:

   What|Removed |Added

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

--- Comment #3 from RazvanN  ---
(In reply to ag0aep6g from comment #2)
> (In reply to Seb from comment #1)
> > So DMD already does transitively apply @safe, but apparently if it generated
> > for associative arrays this generation doesn't work in all cases.
> 
> It's not the associative array. It's just that the generated opAssign isn't
> @safe (for no reason):
> 
> 
> void main() @safe
> {
> struct ThrowingElement
> {
> ~this() {}
> }
> 
> ThrowingElement aa;
> /* Accepted. The destructor is apparently inferred as @safe. */
> aa = aa;
> /* Error: @safe function D main cannot call @system generated
> function onlineapp.main.ThrowingElement.opAssign */
> }
> 

That's because the generated opAssign is not @safe. Look at [1] : it injects a
pointer which is void initialized, after that the function is inferred to be
@system. I tried replacing the void initializer with null, or with a new
ExpInitializer(loc, new ThisExp(loc)). That solves the current test case, but
ends up failing other tests (for reasons unknown)

[1] https://github.com/dlang/dmd/blob/master/src/dmd/clone.d#L273

--