[Issue 14666] [REG2.061] Bogus forward reference error
https://issues.dlang.org/show_bug.cgi?id=14666 --- Comment #8 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/711944c56bf50a7e7323cd34008311345e53f57c Add deferred semantic2 mechanism, and run semantic2 for all imported modules When a module is only imported from function local scopes, it couldn't get a change to run semantic2 analysis. It was "fix" for the issue 14666 case, but the deferred instance size finalization collides with that. Now, function local imports can cause module level mutual forward references. Their resolutions can be deferred until the global level analysis loop in `mars.d` at maximum, and all function local imports will work as same as module level ones. --
[Issue 15726] [REG2.068.0] forward reference error for circular classes, RefCounted
https://issues.dlang.org/show_bug.cgi?id=15726 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/ebc83d3c8ef9f16e7aff201757850a9c738650b0 fix Issue 15726 - forward reference error for circular classes, RefCounted https://github.com/D-Programming-Language/dmd/commit/1d8ce9d8d2669693cb59efd8b00e4a6554467079 Merge pull request #5500 from 9rnsr/fix15726 [REG2.068.0] Issue 15726 - forward reference error for circular classes, RefCounted --
[Issue 15836] [REG 2.071-b1] memory error when a class is not implicitly destructed and constructed with new
https://issues.dlang.org/show_bug.cgi?id=15836 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #2 from Rainer Schuetze --- The trouble is that the destructor of MemoryStream is calling GC.addrOf in the finalization stage of a collection, and there is a new check that explicitly disallows this. At the sweep stage, the GC is in an intermediate state that might not yield sensible results for GC.addrOf and friends. I think using this as an indicator whether a block of memory is allocated by the GC depends on its exact implementation (block immediately "freed" after finalization?), and it might restrict the inner workings of the GC too much if we make this a requirement. --
[Issue 15836] [REG 2.071-b1] memory error when a class is not implicitly destructed and constructed with new
https://issues.dlang.org/show_bug.cgi?id=15836 b2.t...@gmx.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #3 from b2.t...@gmx.com --- Ok I close. The problem can be solved without using AddrOf. --
[Issue 15830] UFCS prevents to select a free function when the parameter has a member with the same name
https://issues.dlang.org/show_bug.cgi?id=15830 b2.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --
[Issue 15839] this.outer is of wrong type
https://issues.dlang.org/show_bug.cgi?id=15839 --- Comment #7 from Jacob Carlborg --- I tried modifying my code to explicitly pass in the outer this reference. That works until you have nested anonymous classes. For example: interface A {} interface B {} class Foo { void foo() { auto a = new class(this) A { Foo outer; this(Foo outer) { this.outer = outer; this.outer.bar(); auto b = new class(this) B { A outer; this(A outer) { this.outer = outer; this.outer.outer.bar(); // line 20 } }; } }; } void bar() {} } The above will of course fail to compile since there's no "bar" in "A": main.d(20): Error: no property 'outer' for type 'main.A' Any suggestions? --
[Issue 13116] Should not be able to return ref to 'this'
https://issues.dlang.org/show_bug.cgi?id=13116 --- Comment #14 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/b0f45b08924511891473c7a2cb18dc8446a9ad30 fix Issue 13116 - Should not be able to return ref to 'this' https://github.com/D-Programming-Language/dmd/commit/2d59f2e43e59b1a3c66745c6d9ac9039ff09eed3 Merge pull request #5591 from 9rnsr/fix13116 Issue 13116 - Should not be able to return ref to 'this' --
[Issue 15831] IFTI voldemort type exploding bloat
https://issues.dlang.org/show_bug.cgi?id=15831 Johan Engelen changed: What|Removed |Added CC||jbc.enge...@gmail.com --- Comment #2 from Johan Engelen --- Hi Anon, I've started implementing your idea. But perhaps you already have a beginning of an implementation? If so, please contact me :) Thanks, Johan --
[Issue 15831] IFTI voldemort type exploding bloat
https://issues.dlang.org/show_bug.cgi?id=15831 Ivan Kazmenko changed: What|Removed |Added CC||ga...@mail.ru --
[Issue 15855] "a[{for" causes dmd to segfault
https://issues.dlang.org/show_bug.cgi?id=15855 Kenji Hara changed: What|Removed |Added Keywords||pull Hardware|x86_64 |All OS|Linux |All --- Comment #1 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/5612 --
[Issue 15179] Local imports cause outer imports to be excluded from overload set
https://issues.dlang.org/show_bug.cgi?id=15179 Steven Schveighoffer changed: What|Removed |Added Severity|regression |enhancement --- Comment #9 from Steven Schveighoffer --- (In reply to Jesse Phillips from comment #8) > It does not. Since I wrote code where selective imports was not necessary, > an update to a second library being used hijacked my call and the compiler > gave no warning. That is the hijack problem, the fact that I can modify my > code to use the desired function is not relevant to how the compiler is > supposed to help prevent hijacking: http://dlang.org/hijack.html Of course selective imports aren't necessary. But importing locally without using selective imports is prone to this issue. I would argue any time you do a scoped import of a module you don't control, you should use static, renamed, or selective imports. This narrows the focus of what you are looking for, and is not subject to overriding or hijacking since it's treated as a local alias. D can do some things to prevent hijacking, but you must remember that it doesn't have a history of code. It cannot always deduce that something was hijacked and that's not what you intended. Note, I just realized this isn't a regression, it's an enhancement. The import rules are working as they were designed. If we are to change anything, it would be a new design. --
[Issue 15855] "a[{for" causes dmd to segfault
https://issues.dlang.org/show_bug.cgi?id=15855 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/8511fe7ade95dc3a9fd64e214dee15633250 fix Issue 15855 - "a[{for" causes dmd to segfault https://github.com/D-Programming-Language/dmd/commit/c2276c702eb3237c798584eaccc6ff314474efac Merge pull request #5612 from 9rnsr/fix15855 Issue 15855 - "a[{for" causes dmd to segfault --
[Issue 15855] "a[{for" causes dmd to segfault
https://issues.dlang.org/show_bug.cgi?id=15855 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 15839] [REG2.071-b1] this.outer is of wrong type
https://issues.dlang.org/show_bug.cgi?id=15839 Kenji Hara changed: What|Removed |Added Keywords||pull Summary|this.outer is of wrong type |[REG2.071-b1] this.outer is ||of wrong type --- Comment #8 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/5613 If a nested class has a parent class over some nested functions, '.outer' will properly point instance of the parent class. --
[Issue 15853] [std.random] save method must be immutable
https://issues.dlang.org/show_bug.cgi?id=15853 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #2 from hst...@quickfur.ath.cx --- It's sufficient to make .save const. --
[Issue 15850] [VisualD] Host gh-pages at official repo
https://issues.dlang.org/show_bug.cgi?id=15850 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx Summary|Host gh-pages at official |[VisualD] Host gh-pages at |repo|official repo --
[Issue 15842] struct is being copied when returned directly
https://issues.dlang.org/show_bug.cgi?id=15842 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords|wrong-code | CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx --- I'm pretty sure this behaviour is according to spec. Structs are supposed to behave like glorified ints, meaning they are value types and may be freely copied around and moved when passing between functions. This is one reason it's a bad idea to keep internal pointers to a struct, as the pointers will become invalid once the struct is moved. Returning a struct from a function is generally implemented as storing in a temporary area on the stack, and moving to the final stack variable once control returns to the caller. --
[Issue 15842] struct is being copied when returned directly
https://issues.dlang.org/show_bug.cgi?id=15842 --- Comment #2 from hst...@quickfur.ath.cx --- (Small structs may also be returned via registers alone, but I surmise that using & on the struct will suppress this.) --
[Issue 15856] New: Confusing error message with -transition=checkimports
https://issues.dlang.org/show_bug.cgi?id=15856 Issue ID: 15856 Summary: Confusing error message with -transition=checkimports Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: d...@me.com Compiling the following code: class Foo { import core.stdc.config; struct Bar { c_long a; // line 7 } } With the -transition=checkimports flag the compiler gives the following error messages: main.d(1): Deprecation: class main.Foo alias core.stdc.config.c_long found in local import main.d(7): Deprecation: local import search method found nothing (null) instead of alias core.stdc.config.c_long I'm not sure if the error message is just bad or if there's a bug in the compiler. --
[Issue 15857] New: Confusing/wrong error message with -transition=checkimports
https://issues.dlang.org/show_bug.cgi?id=15857 Issue ID: 15857 Summary: Confusing/wrong error message with -transition=checkimports Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: major Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: d...@me.com Here's an other issue with the -transition=checkimports flag. I've not been able to create a reduced test case but I get the following error message when compiling DStep: clang/Type.d(114,24): Deprecation: local import search method found overloadset clang.Type.isEmpty instead of overloadset clang.Type.isEmpty This is where it complains [1], "isEmpty" pulled in from here [2] and declared here [3]. [1] https://github.com/jacob-carlborg/dstep/blob/master/clang/Type.d#L114 [2] https://github.com/jacob-carlborg/dstep/blob/master/clang/Type.d#L9 [3] https://github.com/jacob-carlborg/mambo/blob/master/mambo/core/Array.d#L110 --
[Issue 15858] New: core.sys.posix.dirent.dirent for glibc is invalid
https://issues.dlang.org/show_bug.cgi?id=15858 Issue ID: 15858 Summary: core.sys.posix.dirent.dirent for glibc is invalid Product: D Version: D2 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: ket...@ketmar.no-ip.org core.sys.posix.dirent.dirent struct is invalid: it should be `align(1):` (i.e. not aligned). at least on GNU/Linux x86. --
[Issue 15858] core.sys.posix.dirent.dirent for glibc is invalid
https://issues.dlang.org/show_bug.cgi?id=15858 Ketmar Dark changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --
[Issue 15839] [REG2.071-b1] this.outer is of wrong type
https://issues.dlang.org/show_bug.cgi?id=15839 --- Comment #9 from Jacob Carlborg --- (In reply to Kenji Hara from comment #8) > https://github.com/D-Programming-Language/dmd/pull/5613 > > If a nested class has a parent class over some nested functions, '.outer' > will properly point instance of the parent class. So, this pull request will fix the issues I'm having? --
[Issue 14503] BigInt to binary/octal and lower case "%x" (hexadecimal format)
https://issues.dlang.org/show_bug.cgi?id=14503 --- Comment #5 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/630e227c5a50985cbd5d96144e3dcb95ec9aef21 Merge pull request #3992 from quickfur/bigint_octal Issue 14503: Implement formatting BigInt in octal --