[Issue 18282] [Scope][DIP1000]Assignment of local variable to `scope` variable not recognized by compiler
https://issues.dlang.org/show_bug.cgi?id=18282 Walter Bright changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #3 from Walter Bright --- I'll reopen it and look at it again. --
[Issue 13727] std.stdio.File not thread-safe
https://issues.dlang.org/show_bug.cgi?id=13727 --- Comment #13 from Walter Bright --- (In reply to Steven Schveighoffer from comment #12) > This was pulled in May 2016, so I'm assuming dmd release has been > updated with new snn.lib? The test case passes, so yes. > In any case, there are still threading issues. Not > sure whether they are all related. In order to keep this open, it needs specifics. --
[Issue 18597] more unsafe unaligned pointer errors
https://issues.dlang.org/show_bug.cgi?id=18597 --- Comment #2 from Walter Bright --- (In reply to ag0aep6g from comment #1) > (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. Sorry about that, but I just copy pasted from the public page: https://issues.dlang.org/show_bug.cgi?id=15399 I.e. your email address appears with every comment you write, including the one this is in reply to. You might want to check your bugzilla profile. --
[Issue 18592] Associative array assignment with a destructor should be @safe if the destructor is @safe
https://issues.dlang.org/show_bug.cgi?id=18592 Carsten Blüggel changed: What|Removed |Added CC||chi...@posteo.net --
[Issue 18592] Associative array assignment with a destructor should be @safe if the destructor is @safe
https://issues.dlang.org/show_bug.cgi?id=18592 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=18000 --- Comment #1 from Walter Bright --- The solution is likely the same as for https://github.com/dlang/dmd/pull/8011 --
[Issue 18000] [scope] auto-generated opAssign not scope aware
https://issues.dlang.org/show_bug.cgi?id=18000 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=18592 --
[Issue 17448] Move semantics cause memory corruption and cryptic bugs
https://issues.dlang.org/show_bug.cgi?id=17448 Carsten Blüggel changed: What|Removed |Added CC||chi...@posteo.net --
[Issue 18548] [2.079] std.format ignores templated toString if another toString is not a template
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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 ~= &foo; > > } > > > > 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 ~ &foo; } The only difference from the original code is `ls ~= &foo;` -> `ls = ls ~ &foo;`. 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 --