[Issue 18548] [2.079] std.format ignores templated toString if another toString is not a template

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

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

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

   What|Removed |Added

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

--

[Issue 18548] [2.079] std.format ignores templated toString if another toString is not a template

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

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

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

https://github.com/dlang/phobos/commit/3d5cb4a0f7d0889a1f6b3830d3efada7177260aa
Fix Issue 18548 - std.format ignores templated toString if another toString is
not a template

https://github.com/dlang/phobos/commit/2612d38b55d8aa313b3f8d47352f6d45fc341a85
Merge pull request #6247 from JackStouffer/issue18548

Fix Issue 18548 - std.format ignores templated toString if another to…

--

[Issue 18565] std.regex Captures opAssign returns void since v2.079.0

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

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

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

https://github.com/dlang/phobos/commit/0b9ca7107c49cd995e3de8886a884b34dcba435a
Fix Issue 18565 - std.regex Captures opAssign returns void

https://github.com/dlang/phobos/commit/f1d69eb64eab38b815d176db8e5c8b37187697e9
Merge pull request #6263 from WebFreak001/stable

Fix Issue 18565 - std.regex Captures opAssign returns void
merged-on-behalf-of: Sebastian Wilzbach 

--

[Issue 18565] std.regex Captures opAssign returns void since v2.079.0

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

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

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

   What|Removed |Added

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

--

[Issue 18601] alias m = __traits(getMember, ...) doesn't work

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

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

--- Comment #3 from Manu  ---
I'm trolling my Blizzard colleagues by trying to get them interested in D...
but the quality bar needs to be a LOT higher here to be convincing compared to
my former workplaces.

--

[Issue 18601] alias m = __traits(getMember, ...) doesn't work

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

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

--- Comment #2 from Manu  ---
Indeed, I am aware of the workaround, but that doesn't make the problem any
better.
People don't expect to have to wrap a thing in an Alias!() statement for no
logical reason... so it's just a gotcha that looks bad to new users (case in
question).

--

[Issue 18601] alias m = __traits(getMember, ...) doesn't work

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

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #1 from Jonathan M Davis  ---
It can be trivially worked around by wrapping the __traits expression in a
std.meta.Alias, but I don't understand why that should be necessary. Certainly,
it seems like it shouldn't be necessary.

--

[Issue 18603] New: Illegal instruction: 4 on Mac OS 10.7.5 Leopard

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

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

  Issue ID: 18603
   Summary: Illegal instruction: 4 on Mac OS 10.7.5 Leopard
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: normal
  Priority: P1
 Component: installer
  Assignee: nob...@puremagic.com
  Reporter: ss...@cam.ac.uk

After downloading version 2.079.0 of the Mac OS DMG file on a Mac OS 10.7.5
system, the installer runs OK but the files it leaves in /usr/local/bin (e.g.
dmd or dub) all say "Illegal instruction: 4" when you try to run them.  This is
despite the fact that the installer says it aims at Mac OS 10.6 or above.

I suspect the files have been compiled with a Mac complier that targets a
minimum version of Mac OS higher than 10.7 (perhaps 10.9 or higher?) - if this
cannot be fixed, perhaps the minimum Mac OS requirement needs to be updated? 
Thanks.

(Filing against Installer because I'm not sure which component this should be
filed against.  Hopefully it's easy to reassign if necessary.)

--

[Issue 18602] New: [Better C] docs

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

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

  Issue ID: 18602
   Summary: [Better C] docs
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: trivial
  Priority: P3
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: rjkub...@gmail.com

"Dynamic arrays" shows up in both "Retained Features" and "Not Available"
sections

--

[Issue 18601] New: alias m = __traits(getMember, ...) doesn't work

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

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

  Issue ID: 18601
   Summary: alias m = __traits(getMember, ...) doesn't work
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

It's annoying that this doesn't work:

```
struct S
{
int x;
}

void f()
{
S s;
alias m = __traits(getMember, s, "x");
}
```

> Error: basic type expected, not `__traits`
> Error: semicolon expected to close `alias` declaration


I'm pretty sure this could be trivially supported...?

I feel like that __traits statement should be semantically identical to:
   alias m = s.x;

The __traits(getMember) docs make you feel like that's true...

--

[Issue 18166] std.array.replace should be usable in @safe for dstrings

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

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

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

https://github.com/dlang/phobos/commit/13cf12dfda5d9564ea2f63dfbeee0f1d129af94c
Fix Issue 18166 - std.array.replace should be usable in @safe for dstrings

https://github.com/dlang/phobos/commit/7c9c07552dc289997887675d7cc74a51f5a1c103
Merge pull request #6255 from JackStouffer/issue18166

Fix Issue 18166 - std.array.replace should be usable in @safe for dst…
merged-on-behalf-of: Jack Stouffer 

--

[Issue 18166] std.array.replace should be usable in @safe for dstrings

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

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

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

   What|Removed |Added

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

--

[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
Issue 18110 depends on issue 18166, which changed state.

Issue 18166 Summary: std.array.replace should be usable in @safe for dstrings
https://issues.dlang.org/show_bug.cgi?id=18166

   What|Removed |Added

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

--

[Issue 18600] New: Regex performance enhancement for repeated matchFirst calls

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

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

  Issue ID: 18600
   Summary: Regex performance enhancement for repeated matchFirst
calls
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: jrdemail2000-dl...@yahoo.com

This is a follow-up to https://issues.dlang.org/show_bug.cgi?id=18114, which
identified a regex performance regression introduced in the 2.078 release. A
number of improvements in 2.079 cut the performance regression meaningfuly
enough to close the issue, but a meaningful delta remained, from 10-25% in my
tests, depending on the regex issued. This indicates headroom for improvement
exists.

Subsequently, Dmitry Olshansky identified another performance opportunity. The
test cases make repeated calls to matchFirst. This is the usage in eBay's TSV
Utilities where this was identified. In this usage, a regex match is made
against every line of input in turn.

Each call to matchFirst instantiates a new version of the regex engine, a
relatively expensive operation. Caching and reusing the engine on subsequent
calls would be faster. This optimization has been available for a while,
however, an increase in instantiation cost may have contributed to the
performance regression identified in 2.078.

In Dmitry's tests, caching the regex engine showed approximately 3x
improvement. This would be an improvement significantly beyond the regression
introduced in 2.078.

My performance tests from issue 18114 (see issue 18114 for test details):

| Regex | 2.077.1  | 2.078.0-beta1 | 2.079.0  |
|---+--+---+--|
| 'abc' |  3819.314 ms |  6202.892 ms  |  5077.937 ms |
| '(aa)+(cc)+g' |  5457.678 ms |  8209.269 ms  |  6672.057 ms |
| '(aa|ax).+[gxb][cyw]' | 10121.181 ms | 12448.443 ms  | 11254.978 ms |

A material improvement over 2.078.0-beta1, but still 10-25% off 2.077.1,
depending on the regex.

Dimitry's tests caching the engine, using the second regex:

# Before
▶ ./find_regex '(aa)+(cc)+g' strings.txt   
106437 matches; 5538.671 milliseconds

# After
▶ ./find_regex '(aa)+(cc)+g' strings.txt
106437 matches; 1880.550 milliseconds

This would be approximately a 3x improvement.

--

[Issue 18599] New: std.format %(...%) format does not allow modifiers that take additional arguments

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

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

  Issue ID: 18599
   Summary: std.format %(...%) format does not allow modifiers
that take additional arguments
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

Currently, this is supported:
-
import std.format;
format("%(%.14f, %)", [ 1.1, 2.2, 3.3 ]);
-

and so is this:
-
format("%(%10.3f, %)", [ 1.1, 2.2, 3.3 ]);
-

However, this is not supported:
-
format("%(%.*f, %)", double.dig, [ 1.1, 2.2, 3.3 ]);
-

Nor this:
-
format("%(%*.3f, %)", 5, [ 1.1, 2.2, 3.3 ]);
-

Basically, any nested specifier that takes an additional argument is not
supported, because of the way nested specifiers are implemented.

It would be nice if this could somehow be made to work.

--

[Issue 18000] [scope] auto-generated opAssign not scope aware

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

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

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

   What|Removed |Added

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

--

[Issue 18000] [scope] auto-generated opAssign not scope aware

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

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

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

https://github.com/dlang/dmd/commit/ddef69767da510fce048fc13f8b66e79765cccb5
fix Issue 18000 - [scope] auto-generated opAssign not scope aware

https://github.com/dlang/dmd/commit/133973354df526664b22cacdf488785fa911209f
Merge pull request #8011 from WalterBright/fix18000

fix Issue 18000 - [scope] auto-generated opAssign not scope aware
merged-on-behalf-of: Walter Bright 

--

[Issue 14680] Investigate the use of .di files for Phobos

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

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

Issue 14693 Summary: @property return type not generated in .di file
https://issues.dlang.org/show_bug.cgi?id=14693

   What|Removed |Added

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

--

[Issue 14693] @property return type not generated in .di file

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

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

RazvanN  changed:

   What|Removed |Added

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

--- Comment #4 from RazvanN  ---
This has been fixed. Running the .di generator on the original post results in
the following .di file:

// D import file generated from 'test.d'
struct A
{
@property foo()
{
return 42;
}
}

which is correct D compilable code. Closing as fixed.

--

[Issue 14688] dmd writes paren-less expression in generated .di, subsequently refuses it

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

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

RazvanN  changed:

   What|Removed |Added

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

--- Comment #1 from RazvanN  ---
This has been fixed by [1]. Closing as fixed.

[1] https://github.com/dlang/dmd/pull/7270

--

[Issue 14680] Investigate the use of .di files for Phobos

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

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

Issue 14688 Summary: dmd writes paren-less expression in generated .di, 
subsequently refuses it
https://issues.dlang.org/show_bug.cgi?id=14688

   What|Removed |Added

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

--

[Issue 14461] Header generation fails for definitions of string,wstring and dstring

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

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

RazvanN  changed:

   What|Removed |Added

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

--

[Issue 18332] rt.util.random.Rand48 remove unnecessary assert

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

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

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

https://github.com/dlang/druntime/commit/3d02a6e72533ee9399a7f2d40caa7c463f2f4020
Issue 18332 - rt.util.random.Rand48 remove unnecessary assert

https://github.com/dlang/druntime/commit/01643aadf0c28be03ca64e6614fb592356a3d40e
Merge pull request #2069 from n8sh/rand48

Issue 18332 - rt.util.random.Rand48 remove unnecessary assert

--

[Issue 18325] `dmd/core/exception.d(686): _store is thread local` when building dmd

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

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

Seb  changed:

   What|Removed |Added

   Keywords||pull
 CC||greensunn...@gmail.com

--- Comment #2 from Seb  ---
PR https://github.com/dlang/druntime/pull/2138

>  I'm guessing that's because of `-vtls`  was added?

Yes.

> why was it added?

no idea, maybe because of:

https://dlang.org/articles/migrate-to-shared.html

--

[Issue 8341] topN(zip()) too?

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

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

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

https://github.com/dlang/phobos/commit/ede44cbc63bb596085f2aa049ba924a481921bb7
Fix Issue 8341 - topN(zip()) doesn't work

https://github.com/dlang/phobos/commit/78f7209c4a701749b1ed45c2da5bf1511309402f
Merge pull request #6156 from wilzbach/fix-8341

Fix Issue 8341 - topN(zip()) doesn't work
merged-on-behalf-of: Jack Stouffer 

--

[Issue 13727] std.stdio.File not thread-safe

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

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

--- Comment #12 from Steven Schveighoffer  ---
(In reply to Walter Bright from comment #11)
> (In reply to Vladimir Panteleev from comment #8)
> > https://github.com/DigitalMars/dmc/pull/2 (access required)
> 
> This was pulled.

issue 18483 is related and was still showing there are threading issues
recently. This was pulled in May 2016, so I'm assuming dmd release has been
updated with new snn.lib? In any case, there are still threading issues. Not
sure whether they are all related.

See also: http://bugzilla.digitalmars.com/issues/show_bug.cgi?id=327

--

[Issue 17959] [DIP1000] Can store scope delegate in non-scope member

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

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

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

   What|Removed |Added

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

--

[Issue 17959] [DIP1000] Can store scope delegate in non-scope member

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

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

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

https://github.com/dlang/dmd/commit/28879f6379bca25d6b2c984dcb43dc7cce8560f9
fix Issue 17959 - [DIP1000] Can store scope delegate in non-scope member

https://github.com/dlang/dmd/commit/44c37732cbb54236c53e407f2be8e0789ef2346e
Merge pull request #8008 from WalterBright/fix17959

fix Issue 17959 - [DIP1000] Can store scope delegate in non-scope member
merged-on-behalf-of: Walter Bright 

--

[Issue 18282] [Scope][DIP1000]Assignment of local variable to `scope` variable not recognized by compiler

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

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #2 from ag0ae...@gmail.com ---
(In reply to Walter Bright from comment #1)
> (In reply to Mike Franklin from comment #0)
> > void main() @safe
> > {
> > string foo = "foo";
> > scope string*[] ls;
> > ls ~= 
> > }
> > 
> > Compile with `-dip1000`
> > 
> > onlineapp.d(5): Error: reference to local variable foo assigned to non-scope
> > ls
> 
> While ls is scope, ls[] is not scope. Scope is not transitive, hence the
> compiler error.

I assume that you don't mean `ls[]` literally, but rather that the elements of
`ls` aren't `scope`, right?

That means, it should be okay to return `ls[0]` because that's not `scope`,
right? But that doesn't work:


string* f() @safe
{
scope string*[] ls;
return ls[0]; /* Error: scope variable ls may not be returned */
}


On the other hand, this works:


void main() @safe
{
string foo = "foo";
scope string*[] ls;
ls = ls ~ 
}


The only difference from the original code is `ls ~= ` -> `ls = ls ~
`. Those two assignments should be equivalent [1], no? Either both should
be accepted, or both should be rejected.


[1] https://dlang.org/spec/expression.html#assignment_operator_expressions

--

[Issue 17284] Template function attribute inference wrongly infers @safe for accessing overlapping pointer fields in unions

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

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

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

https://github.com/dlang/dmd/commit/36eb3834efa4e792221fffb3badd0fff5d3323a7
fix Issue 17284 - Template function attribute inference wrongly infers @safe
for accessing overlapping pointer fields in unions

https://github.com/dlang/dmd/commit/976e82f990fa9852894d0d6d3ac496129543c930
Merge pull request #7982 from WalterBright/fix17284

fix Issue 17284 - Template function attribute inference wrongly infer…
merged-on-behalf-of: Walter Bright 

--

[Issue 17284] Template function attribute inference wrongly infers @safe for accessing overlapping pointer fields in unions

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

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

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

   What|Removed |Added

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

--

[Issue 18598] New: cyclic constructor calls have undefined behavior but are accepted in @safe code

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

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

  Issue ID: 18598
   Summary: cyclic constructor calls have undefined behavior but
are accepted in @safe code
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: safe
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

On class constructors, the spec says [1]:

> It is illegal for constructors to mutually call each other, although
> the compiler is not required to detect it. It will result in undefined
> behavior.

But DMD accepts this:


class C
{
this() @safe { this(1); }
this(int i) @safe { this(); }
}

void main() @safe
{
auto c = new C;
}


According to the spec, the code has undefined behavior, so it shouldn't be
accepted with the @safe attribute.

Also according to the spec, "the compiler is not required to detect" this, but
that can't apply to @safe code, because the compiler is required to ensure that
there is "no possibility of undefined behavior" in @safe code [2].

(As always, this can be fixed by letting DMD reject the code, or by changing
the spec to give the code defined behavior.)


[1] https://dlang.org/spec/class.html#constructors
[2] https://dlang.org/spec/function.html#function-safety

--

[Issue 15399] unaligned pointers are not @safe

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

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|REOPENED|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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
(In reply to Walter Bright from comment #0)
> ag0aep6g@[...].com writes:

Please don't give away people's email addresses like that. It doesn't matter
too much for me, because that's my D address, but generally it's not a nice
thing to do.

--

[Issue 15399] unaligned pointers are not @safe

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

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

--- Comment #9 from Walter Bright  ---
Closed and new bug created for variations:

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

--

[Issue 15399] unaligned pointers are not @safe

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

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 18597] more unsafe unaligned pointer errors

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

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 18597] more unsafe unaligned pointer errors

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

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||safe

--

[Issue 18597] New: more unsafe unaligned pointer errors

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

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

  Issue ID: 18597
   Summary: more unsafe unaligned pointer errors
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

ag0ae...@gmail.com writes:

 test.d 
@safe:

struct Victim
{
bool alive = true;
~this() { alive = false; }
}

align(1)
struct Unaligned
{
align(1):
ubyte filler;
Victim* p;
}

pragma(msg, Unaligned.sizeof);

void main()
{
enum N = 100;

Unaligned[N] hosts;

foreach (n; 0..N)
{
version (original) hosts[n].p = new Victim;
else version (variation1) hosts[n] = Unaligned(0, new Victim);
else version (variation2)
{
Unaligned u = { p: new Victim };
hosts[n] = u;
}
else static assert(false);
assert(hosts[n].p.alive);
}

// Unaligned.p is invisible to the GC due to alignment

void trustedCollect() @trusted { import core.memory; GC.collect(); }
trustedCollect();

foreach (n; 0..N)
assert(hosts[n].p.alive); // Dangling pointer!
}


These should all fail with the same error:

dmd -version=original test.d
dmd -version=variation1 test.d
dmd -version=variation2 test.d

The different versions effectively do the same thing, just with different
syntax.

--

[Issue 15399] unaligned pointers are not @safe

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

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

--- Comment #8 from Walter Bright  ---
(In reply to ag0aep6g from comment #5)
> Reopening because these very slight variations are still accepted:

Since the original bug was fixed, I'd prefer opening new bugs for new problems,
not reopening fixed bugs with variations.

--

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

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

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

  Issue ID: 18596
   Summary: std.random.unpredictableSeed could use something
better than MinstdRand0
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

Currently `std.random.unpredictableSeed` returns the result of a thread-local
MinstdRand0 instance xor'd against the clock. MinstdRand0 is slow (due to
integer division) and somewhat outdated. A particular weakness of using
MinstdRand0 is that it is very likely that consecutive calls to
`unpredictableSeed` will return numbers that are identical in the high bit,
since MinstdRand0 only produces results in the range `1 .. 2 ^^ 31 - 1`. There
are modern PRNG algorithms that have comparable state size to MinstdRand0 (64
bits or 32 bits) but are faster than MinstdRand0 and have output that scores
better on randomness tests like BigCrush. On some platforms we can use
functions like `arc4random` which incorporate system entropy and remove the
need to roll our own entropy-gathering function to set an initial state for a
PRNG.

--

[Issue 13983] RefCounted needs to be pure, @safe, nothrow

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

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

--- Comment #6 from Walter Bright  ---
Partial fix (@safe not done) pulled here:

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

--

[Issue 13727] std.stdio.File not thread-safe

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

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

--- Comment #11 from Walter Bright  ---
(In reply to Vladimir Panteleev from comment #8)
> https://github.com/DigitalMars/dmc/pull/2 (access required)

This was pulled.

--

[Issue 18595] New: std.random: add unpredictableSeedOf!UIntType for non-uint unpredictableSeed

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

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

  Issue ID: 18595
   Summary: std.random: add unpredictableSeedOf!UIntType for
non-uint unpredictableSeed
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

It would be convenient if `std.random.unpredictableSeed` could be used to
produce `ulong`. To avoid any backwards compatibility issues I propose calling
the new method `unpredictableSeedOf!UIntType` and aliasing `unpredictableSeed`
to `unpredictableSeed!uint`.

--

[Issue 13639] std.internal.math.biguintcore.fromDecimalString from @trusted to @safe fails unittests

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

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

Walter Bright  changed:

   What|Removed |Added

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

--- Comment #1 from Walter Bright  ---
The 2612 PR was merged.

--

[Issue 12516] TypeInfo.getHash should not be trusted

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
To fix this would probably involve creating a template called getHash2(T)(ref T
v) or something like that in TypeInfo, and then using parametric polymorphism
on it.

--

[Issue 18168] std.base64.encode for output ranges should be usable in @safe

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

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

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

https://github.com/dlang/phobos/commit/e826c82e3286a8f9f34713ae321c1261a3164d1a
Fix Issue 18168 - std.base64.encode for output ranges should be usable in @safe

https://github.com/dlang/phobos/commit/f78194889fdd47036133ad995bb4bee9d68fe0c8
Merge pull request #6251 from JackStouffer/issue18168

Fix Issue 18168 - std.base64.encode output ranges @safe
merged-on-behalf-of: Sebastian Wilzbach 

--

[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
Issue 18110 depends on issue 18168, which changed state.

Issue 18168 Summary: std.base64.encode for output ranges should be usable in 
@safe
https://issues.dlang.org/show_bug.cgi?id=18168

   What|Removed |Added

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

--

[Issue 18000] [scope] auto-generated opAssign not scope aware

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

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

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8011

--

[Issue 17448] Move semantics cause memory corruption and cryptic bugs

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

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

--- Comment #36 from Shachar Shemesh  ---
Hello Walter,

I see two problems with your comment. The first is that I think you are missing
the real point of this bug report. It is not about controlling movability. It
is about being able to hook the object's lifetime.

The second problem is that I think you are trying to use optimization as a tool
for solving semantic problems. I take issue with that, as there are always
cases where optimizations are not possible.

(In reply to Walter Bright from comment #35)
> Why was it moving the stack allocated objects in these examples? Because
> when it went out of scope, it is safe to assume that there are no extant
> pointers to it.

Before an object goes out of scope, its destructor needs to be called. Else,
you give me no tool to make sure the above assertion is actually true.

In this case, the object "went out of scope" but its destructor was not called.
This is the real trigger for the dangling external pointer.

> This is why the compiler (now) complains when the code
> registers a pointer to the stack object. Of course, making the code @trusted
> enables code like this to be written, leaving it up to the programmer to
> ensure the safety.

I have no problem with the saying that some code that is safe is not @safe. My
issue is with saying that I am facing a lifetime management problem that has no
solution within the language, no matter how aware I am of it.

> But there's another wrinkle. With RVO (Return Value Optimization)
...

There are cases where it is impossible to RVO:

SomeStruct func(bool which) {
  SomeStruct struct1, struct2;

  // Do something on both struct1 and struct2 to make this meaningful.
  if( which )
return struct1;
  else
return struct2;
}

There is simply no way to allocate the correct object on the caller's memory.

> So, to guarantee RVO:
...

That's, to me, missing the point. The point, for me, is to be able to design a
struct that will be safe without asking the users of the struct to live up to
some conditions. I don't think anything else is a viable answer.

> Obviously, I am not familiar with your code and usage patterns. But the
> above ought to offer some hope (!) for getting your code working properly.

RVO is important, and definitely a welcome enhancement. The issue here,
however, is not about Weka's code (the bug that triggered this bug report is
long solved now). The point here is that there is an exceedingly useful tool
designed to create code that is easier to maintain that D makes impossible.

I am going to write a DIP for introducing a mechanism for hooking the move, as
discussed in comment #31. There reason I'm keeping this discussion alive is
because I will need your buy-in to get it integrated, and for that I need you
to see the need.

> If there are more pernicious problems with moving that aren't covered by
> this, please let me know. Perhaps I can think of a solution.

See above.

--

[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate

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

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

--- Comment #12 from Rainer Schuetze  ---
This looks like a variation of https://issues.dlang.org/show_bug.cgi?id=17959,
with -dip1000 inferring "scope".

--

[Issue 18587] Context pointer not set for delegate template parameter when declared in struct body

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

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

Simen Kjaeraas  changed:

   What|Removed |Added

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

--- Comment #1 from Simen Kjaeraas  ---
Since structs in D are movable by simple blitting with no cleanup step, this is
impossible. If we consider this code again:

struct S {
int n;
R!(() => n) a;
}

struct R(alias fn) {
int get() {
return fn();
}
}

The layout of R would essentially be this:

struct R(alias fn) {
S* context;
}

Thus, the layout of S would essentially be this:

struct S {
int n;
S* a.context;
}

That's an internal pointer, and runs afoul of this section of the GC spec[0]:

> Do not have pointers in a struct instance that point back to the same 
> instance. The trouble with this is if the instance gets moved in memory, the 
> pointer will point back to where it came from, with likely disastrous results.

[0]: https://dlang.org/spec/garbage.html

--

[Issue 18594] X is not an lvalue should have a better error message

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

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

--- Comment #3 from Seb  ---
A start: https://github.com/dlang/dmd/pull/8009

--

[Issue 18568] partially overlapping assignments have undefined behavior but are accepted in @safe code

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dlang.org/pull/2271

--

[Issue 17892] Scope analysis with -dip1000 fails for templated structs

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

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

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

https://github.com/dlang/dmd/commit/3dd5b8ca04c0d25bb34d4d8dff3de4949ab066a1
supplemental fix for Issue 17892

--

[Issue 18594] X is not an lvalue should have a better error message

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

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

--- Comment #2 from Seb  ---
Hmm, just modifying the error message isn't enough. We should probably look up
in the tree to check whether we are in if expression, assert, ...

diff --git a/src/dmd/expression.d b/src/dmd/expression.d
index d93c1ffda..997423b85 100644
--- a/src/dmd/expression.d
+++ b/src/dmd/expression.d
@@ -1855,7 +1855,7 @@ extern (C++) abstract class Expression : RootObject
 }
 }
 }
-error("cannot modify `%s` expression `%s`. Did you mean
`==`?", MODtoChars(type.mod), toChars());
+error("cannot modify `%s` expression `%s`",
MODtoChars(type.mod), toChars());
 return new ErrorExp();
 }
 else if (!type.isAssignable())
@@ -2604,7 +2604,7 @@ extern (C++) final class IntegerExp : Expression
 e = this;
 else if (!loc.isValid())
 loc = e.loc;
-e.error("constant `%s` is not an lvalue. Did you mean `==`?",
e.toChars());
+e.error("constant `%s` is not an lvalue", e.toChars());
 return new ErrorExp();
 }

diff --git a/test/fail_compilation/test18594.d
b/test/fail_compilation/test18594.d
deleted file mode 100644
index 631df3033..0
--- a/test/fail_compilation/test18594.d
+++ /dev/null
@@ -1,11 +0,0 @@
-/*TEST_OUTPUT:

-fail_compilation/test18594.d(8): Error: constant `1` is not an lvalue. Did you
mean `==`?
-fail_compilation/test18594.d(10): Error: cannot modify `const` expression `a`.
Did you mean `==`?

-*/
-void main() {
-assert(1 = 2);
-const a = 1;
-assert(a = 2);
-}

--