[Issue 9978] Can override interface function

https://issues.dlang.org/show_bug.cgi?id=9978 Martin Nowak changed: What|Removed |Added CC||c...@dawg.eu --- Comment #4

[Issue 15086] import doesn't verify module declaration

https://issues.dlang.org/show_bug.cgi?id=15086 --- Comment #24 from Jonathan Marler --- > I have not thought about this thoroughly, but I suspect the core of a fix can > be along the lines of detecting that an explicit import of bar.d is done > using two different names

[Issue 15086] import doesn't verify module declaration

https://issues.dlang.org/show_bug.cgi?id=15086 --- Comment #23 from Jonathan Marler --- > I have not thought about this thoroughly, but I suspect the core of a fix can > be along the lines of detecting that an explicit import of bar.d is done > using two different names

[Issue 18436] New: broken opCast fails silently when used with std.conv.to

https://issues.dlang.org/show_bug.cgi?id=18436 Issue ID: 18436 Summary: broken opCast fails silently when used with std.conv.to Product: D Version: D2 Hardware: All OS: All Status: NEW

[Issue 15086] import doesn't verify module declaration

https://issues.dlang.org/show_bug.cgi?id=15086 --- Comment #22 from Timothee Cour --- I don't understand why the current behavior is desired. Is there any single use case that can't be achieved without existing option such as -mv? -mv== use as source file for --

[Issue 15086] import doesn't verify module declaration

https://issues.dlang.org/show_bug.cgi?id=15086 --- Comment #21 from Walter Bright --- (In reply to ag0aep6g from comment #19) Thank you for providing a simple and clear test case to illustrate the issue. It is indeed a problem that the order of imports is mattering, as

[Issue 18435] New: Use StatsCollector in shared environment

https://issues.dlang.org/show_bug.cgi?id=18435 Issue ID: 18435 Summary: Use StatsCollector in shared environment Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement

[Issue 15086] import doesn't verify module declaration

https://issues.dlang.org/show_bug.cgi?id=15086 --- Comment #20 from Jonathan Marler --- Confirmed ag0aep6g's example. Also confirmed the proposed PR treats the example as an error. version=A foo.d(3): Deprecation: module `bar` from file baz.d must be imported with

[Issue 15086] import doesn't verify module declaration

https://issues.dlang.org/show_bug.cgi?id=15086 --- Comment #19 from ag0ae...@gmail.com --- (In reply to Andrei Alexandrescu from comment #16) > The example in which the order of imports makes or breaks the build is > compelling. Even better would be a bug whereby the project builds both ways >

[Issue 15086] import doesn't verify module declaration

https://issues.dlang.org/show_bug.cgi?id=15086 --- Comment #18 from Timothee Cour --- > Even better would be a bug whereby the project builds both ways but does > different things. That would be the smoking gun. could shorten but this shows it: ./asdf/wrong.d

[Issue 15086] import doesn't verify module declaration

https://issues.dlang.org/show_bug.cgi?id=15086 --- Comment #17 from Jonathan Marler --- I was able to reproduce Timothee's example. The error only occurs if the modules are specified in a particular order. I also tested this using PR

[Issue 15086] import doesn't verify module declaration

https://issues.dlang.org/show_bug.cgi?id=15086 --- Comment #16 from Andrei Alexandrescu --- The example in which the order of imports makes or breaks the build is compelling. Even better would be a bug whereby the project builds both ways but does different things. That would

[Issue 15086] import doesn't verify module declaration

https://issues.dlang.org/show_bug.cgi?id=15086 --- Comment #15 from Timothee Cour --- the example I just posted breaks this spec: > The order in which ImportDeclarations occur has no significance. --

[Issue 15086] import doesn't verify module declaration

https://issues.dlang.org/show_bug.cgi?id=15086 ag0ae...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID

[Issue 18434] BigInt gcd asserts when one argument is zero.

https://issues.dlang.org/show_bug.cgi?id=18434 hst...@quickfur.ath.cx changed: What|Removed |Added Summary|Failing case of BigInt gcd |BigInt gcd asserts when one

[Issue 18434] Failing case of BigInt gcd

https://issues.dlang.org/show_bug.cgi?id=18434 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||pull --- Comment #1 from

[Issue 15086] import doesn't verify module declaration

https://issues.dlang.org/show_bug.cgi?id=15086 --- Comment #13 from Timothee Cour --- I don't see what's controversial about the fact that this is broken and breaks the module system. Hopefully this other example will convince you, where all I do is change the order of

[Issue 18434] New: Failing case of BigInt gcd

https://issues.dlang.org/show_bug.cgi?id=18434 Issue ID: 18434 Summary: Failing case of BigInt gcd Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1

[Issue 15086] import doesn't verify module declaration

https://issues.dlang.org/show_bug.cgi?id=15086 --- Comment #12 from Andrei Alexandrescu --- Also enclosing the file name in double quotes might be nice. --

[Issue 15086] import doesn't verify module declaration

https://issues.dlang.org/show_bug.cgi?id=15086 --- Comment #11 from Andrei Alexandrescu --- (In reply to Jonathan Marler from comment #10) > > I think at the least we can do a vastly better job at issuing error > > messages. > > I'm limiting focus to this issue alone. Do you

[Issue 15086] import doesn't verify module declaration

https://issues.dlang.org/show_bug.cgi?id=15086 --- Comment #10 from Jonathan Marler --- > I think at the least we can do a vastly better job at issuing error messages. I'm limiting focus to this issue alone. Do you have an idea on a way to improve the error message for

[Issue 15086] import doesn't verify module declaration

https://issues.dlang.org/show_bug.cgi?id=15086 --- Comment #9 from Andrei Alexandrescu --- Meant to write: Per the discussion in https://github.com/dlang/dmd/pull/7778 --

[Issue 15086] import doesn't verify module declaration

https://issues.dlang.org/show_bug.cgi?id=15086 --- Comment #8 from Andrei Alexandrescu --- I think at the least we can do a vastly better job at issuing error messages. Per the discussion in : === This error occurs becase the module foo/bar.d is being loaded twice with 2

[Issue 15086] import doesn't verify module declaration

https://issues.dlang.org/show_bug.cgi?id=15086 Jonathan Marler changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 18433] New: rdmd ignores DFLAGS

https://issues.dlang.org/show_bug.cgi?id=18433 Issue ID: 18433 Summary: rdmd ignores DFLAGS Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: enhancement Priority: P1

[Issue 18433] rdmd ignores DFLAGS

https://issues.dlang.org/show_bug.cgi?id=18433 Jonathan Marler changed: What|Removed |Added Hardware|x86 |All

[Issue 18384] std.net.isemail is slow to import due to regex

https://issues.dlang.org/show_bug.cgi?id=18384 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/06e40304b21a29420b40c3f2b8d4edeeaf96aa1f Fix Issue 18384 - std.net.isemail is slow to import due

[Issue 18384] std.net.isemail is slow to import due to regex

https://issues.dlang.org/show_bug.cgi?id=18384 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 18429] alias this enum causes segmentation fault

https://issues.dlang.org/show_bug.cgi?id=18429 RazvanN changed: What|Removed |Added CC|

[Issue 18430] isSame is wrong for non global lambdas

https://issues.dlang.org/show_bug.cgi?id=18430 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 18430] isSame is wrong for non global lambdas

https://issues.dlang.org/show_bug.cgi?id=18430 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/1701bf9f7ff68538ca4ae279078233e74bc3b617 Fix Issue 18430 - isSame is wrong for non global lambdas

[Issue 18427] `Symbol FOO is not visible because it is privately imported` => compiler should show how to import it

https://issues.dlang.org/show_bug.cgi?id=18427 RazvanN changed: What|Removed |Added CC|

[Issue 18432] alias x = x where x is an imported symbol should result in an error

https://issues.dlang.org/show_bug.cgi?id=18432 --- Comment #1 from RazvanN --- Actually, import std.stdio : writeln; alias writeln = std.stdio.writeln; Does not compile successfully, it issues an error : "Undefined identifier std.stdio.writeln". --

[Issue 18403] [REG2.078.2] Access violation when dmd tries to print highlighted code

https://issues.dlang.org/show_bug.cgi?id=18403 ag0ae...@gmail.com changed: What|Removed |Added CC||do.m...@foxmail.com --- Comment #4 from

[Issue 18431] Access Violation on printing error message

https://issues.dlang.org/show_bug.cgi?id=18431 ag0ae...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Issue 18430] isSame is wrong for non global lambdas

https://issues.dlang.org/show_bug.cgi?id=18430 RazvanN changed: What|Removed |Added CC|

[Issue 18432] New: alias x = x where x is an imported symbol should result in an error

https://issues.dlang.org/show_bug.cgi?id=18432 Issue ID: 18432 Summary: alias x = x where x is an imported symbol should result in an error Product: D Version: D2 Hardware: x86_64 OS: Linux

[Issue 7721] Nested template loses context when mixin'd

https://issues.dlang.org/show_bug.cgi?id=7721 Simen Kjaeraas changed: What|Removed |Added Summary|Loss of template context|Nested template

[Issue 8295] Struct member destructor can not be called from shared struct instance

https://issues.dlang.org/show_bug.cgi?id=8295 --- Comment #9 from anonymous4 --- It might own the struct, but not the referenced data. Again example is reference counter: destruction can depend on sharing. Another example is that shared data can't be (de)allocated with

[Issue 17928] [scope] `in` is not treated as `const scope`

https://issues.dlang.org/show_bug.cgi?id=17928 --- Comment #7 from anonymous4 --- (In reply to Carsten Blüggel from comment #5) > I submitted PR https://github.com/dlang/dlang.org/pull/2126 It only applies to @safe code and dip1000 as a fix to safety checks, @system