[Issue 18600] Regex performance enhancement for repeated matchFirst calls
https://issues.dlang.org/show_bug.cgi?id=18600 --- Comment #1 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/4318073f40ae3e82ac1847da5e037ab2f091d6fc Fix issue 18600 Revamp std.regex caching for matchFirst case --
[Issue 18600] Regex performance enhancement for repeated matchFirst calls
https://issues.dlang.org/show_bug.cgi?id=18600 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18644] [dip1000] escape of outer local not detected
https://issues.dlang.org/show_bug.cgi?id=18644 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/51565f362fd318ceb0cf94519819c3232b1adb22 fix Issue 18644 - [dip1000] escape of outer local not detected https://github.com/dlang/dmd/commit/0e0df72c1d3b70cb2f1a7fb2f6b26ac7bb8dcc39 Merge pull request #8062 from WalterBright/fix18644 fix Issue 18644 - [dip1000] escape of outer local not detected --
[Issue 18644] [dip1000] escape of outer local not detected
https://issues.dlang.org/show_bug.cgi?id=18644 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18634] std.container.rbtree does not work with delegate comparators
https://issues.dlang.org/show_bug.cgi?id=18634 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/a3f8992766b1baf4d4dd2d57043a734db29c221b Fix issue 18634 - support for delegate comparators in rbtree RedBlackTree.opEquals() was preventing the use of delegates by explicitly forcing the equal() check to go through a function. https://github.com/dlang/phobos/commit/63397e57a95c33dd3f8207822cff34bbabbbcfd4 Merge pull request #6304 from chvor/rbtree-delegate Fix issue 18634 - support for delegate comparators in rbtree merged-on-behalf-of: Sebastian Wilzbach --
[Issue 18634] std.container.rbtree does not work with delegate comparators
https://issues.dlang.org/show_bug.cgi?id=18634 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 17906] Use of delete should be allowed without a deprecation in a deprecated scope
https://issues.dlang.org/show_bug.cgi?id=17906 Seb changed: What|Removed |Added Keywords||pull --- Comment #5 from Seb --- > I guess this bug report is about Mathias Lang's problem now. PR https://github.com/dlang/dmd/pull/8066 (and changed the title accordingly) --
[Issue 17906] Use of delete should be allowed without a deprecation in a deprecated scope
https://issues.dlang.org/show_bug.cgi?id=17906 Seb changed: What|Removed |Added CC||greensunn...@gmail.com Summary|Deprecated functions should |Use of delete should be |not cause deprecated|allowed without a |warnings for using |deprecation in a deprecated |deprecated features |scope --
[Issue 18461] codegen bug - OPbt expressions and assignments to ambiguous symbols
https://issues.dlang.org/show_bug.cgi?id=18461 --- Comment #11 from Walter Bright --- https://github.com/dlang/dmd/pull/8065 --
[Issue 18461] codegen bug - OPbt expressions and assignments to ambiguous symbols
https://issues.dlang.org/show_bug.cgi?id=18461 Walter Bright changed: What|Removed |Added Summary|codegen bug in dmd -|codegen bug - OPbt |assignments to ambiguous|expressions and assignments |symbols |to ambiguous symbols --
[Issue 17906] Deprecated functions should not cause deprecated warnings for using deprecated features
https://issues.dlang.org/show_bug.cgi?id=17906 --- Comment #4 from FeepingCreature --- Huh, seems like you're right. Not sure if this was fixed or it always worked that way. Either way, good to know! I guess this bug report is about Mathias Lang's problem now. --
[Issue 17906] Deprecated functions should not cause deprecated warnings for using deprecated features
https://issues.dlang.org/show_bug.cgi?id=17906 --- Comment #3 from Mathias Lang --- Could you paste the message generated ? In your example, I would expect a deprecation to be generated for the import, but not on the actual function declaration. --
[Issue 17906] Deprecated functions should not cause deprecated warnings for using deprecated features
https://issues.dlang.org/show_bug.cgi?id=17906 --- Comment #2 from FeepingCreature --- That's also true, but my example refers specifically to deprecated functions using deprecated types. However, I labelled the bug report wrong, and your example actually fits it better. :) --
[Issue 18645] New: DMD segmentation fault
https://issues.dlang.org/show_bug.cgi?id=18645 Issue ID: 18645 Summary: DMD segmentation fault Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: major Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: mihails.strasuns.contrac...@sociomantic.com DMD 2.079 (but also happens with earlier versions). Happens in large private codebase, will try to dustmite later this week. For now full stack trace: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00593a1c in BinExp::setNoderefOperands() (this=0x7f14983db410) at dmd/expression.d:5036 5036if (e1.op == TOK.dotIdentifier) (gdb) bt #0 0x00593a1c in BinExp::setNoderefOperands() (this=0x7f14983db410) at dmd/expression.d:5036 #1 0x005b2dbb in ExpressionSemanticVisitor::visit(CmpExp*) (this=0x7ffdec919508, exp=0x7f14983db410) at dmd/expressionsem.d:8714 #2 0x00597172 in CmpExp::accept(Visitor*) (this=0x7f14983db410, v=0x7ffdec919508) at dmd/expression.d:6841 #3 0x005b4e5b in expressionSemantic(Expression*, Scope*) (e=0x7f14983db410, sc=0x7f149837b840) at dmd/expressionsem.d:9437 #4 0x00535e9e in EnumDeclaration::getMaxMinValue(Loc const&, Identifier*) ( this=0x7f149b4489d0, loc=..., id=0x7f14a04ab3a0) at dmd/denum.d:235 #5 0x00607854 in TypeEnum::getProperty(Loc const&, Identifier*, int) (this=0x2365700, loc=..., ident=0x7f14a04ab3a0, flag=0) at dmd/mtype.d:7874 #6 0x005675d2 in DsymbolSemanticVisitor::visit(EnumMember*) (this=0x7ffdec919930, em=0x7f149b448d10) at dmd/dsymbolsem.d:2044 #7 0x0053649a in EnumMember::accept(Visitor*) (this=0x7f149b448d10, v=0x7ffdec919930) at dmd/denum.d:382 #8 0x00561459 in dsymbolSemantic(Dsymbol*, Scope*) (dsym=0x7f149b448d10, sc=0x7f149837b840) at dmd/dsymbolsem.d:103 #9 0x00566bf2 in DsymbolSemanticVisitor::visit(EnumDeclaration*) (this=0x7ffdec919ab0, ed=0x7f149b4489d0) at dmd/dsymbolsem.d:1868 #10 0x00536242 in EnumDeclaration::accept(Visitor*) (this=0x7f149b4489d0, v=0x7ffdec919ab0) at dmd/denum.d:324 #11 0x00561459 in dsymbolSemantic(Dsymbol*, Scope*) (dsym=0x7f149b4489d0, sc=0x7f149836fcc0) at dmd/dsymbolsem.d:103 #12 0x00565193 in DsymbolSemanticVisitor::attribSemantic(AttribDeclaration*) ( this=0x7ffdec919bb0, ad=0x7f149b4492f0) at dmd/dsymbolsem.d:1290 #13 0x005651f5 in DsymbolSemanticVisitor::visit(AttribDeclaration*) (this=0x7ffdec919bb0, atd=0x7f149b4492f0) at dmd/dsymbolsem.d:1302 #14 0x0063b757 in ParseTimeVisitor::visit(ProtDeclaration*) ( this=0x7ffdec919bb0, s=0x7f149b4492f0) at dmd/parsetimevisitor.d:71 #15 0x00507676 in ProtDeclaration::accept(Visitor*) (this=0x7f149b4492f0, v=0x7ffdec919bb0) at dmd/attrib.d:605 #16 0x00561459 in dsymbolSemantic(Dsymbol*, Scope*) (dsym=0x7f149b4492f0, sc=0x7f149b449560) at dmd/dsymbolsem.d:103 #17 0x0056652e in DsymbolSemanticVisitor::visit(Module*) (this=0x7ffdec919c60, m=0x7f149b447f30) at dmd/dsymbolsem.d:1677 #18 0x005521aa in Module::accept(Visitor*) (this=0x7f149b447f30, v=0x7ffdec919c60) at dmd/dmodule.d:1322 #19 0x00561459 in dsymbolSemantic(Dsymbol*, Scope*) (dsym=0x7f149b447f30, sc=0x0) at dmd/dsymbolsem.d:103 #20 0x00564779 in DsymbolSemanticVisitor::visit(Import*) (this=0x7ffdec919f80, imp=0x7f149b623a30) at dmd/dsymbolsem.d:1146 #21 0x0053703b in Import::accept(Visitor*) (this=0x7f149b623a30, v=0x7ffdec919f80) at dmd/dimport.d:309 #22 0x00561459 in dsymbolSemantic(Dsymbol*, Scope*) (dsym=0x7f149b623a30, sc=0x7f149b63ef10) at dmd/dsymbolsem.d:103 #23 0x0056652e in DsymbolSemanticVisitor::visit(Module*) (this=0x7ffdec91a030, m=0x7f149b623170) at dmd/dsymbolsem.d:1677 #24 0x005521aa in Module::accept(Visitor*) (this=0x7f149b623170, v=0x7ffdec91a030) at dmd/dmodule.d:1322 #25 0x00561459 in dsymbolSemantic(Dsymbol*, Scope*) (dsym=0x7f149b623170, sc=0x0) at dmd/dsymbolsem.d:103 #26 0x00564779 in DsymbolSemanticVisitor::visit(Import*) (this=0x7ffdec91a350, imp=0x7f149b61d130) at dmd/dsymbolsem.d:1146 #27 0x0053703b in Import::accept(Visitor*) (this=0x7f149b61d130, v=0x7ffdec91a350) at dmd/dimport.d:309 #28 0x00561459 in dsymbolSemantic(Dsymbol*, Scope*) (dsym=0x7f149b61d130, sc=0x7f149b622e10) at dmd/dsymbolsem.d:103 #29 0x0056652e in DsymbolSemanticVisitor::visit(Module*) (this=0x7ffdec91a400, m=0x7f149b61cdd0) at dmd/dsymbolsem.d:1677 #30 0x005521aa in Module::accept(Visitor*) (this=0x7f149b61cdd0, v=0x7ffdec91a400) at dmd/dmodule.d:1322 #31 0x00561459 in dsymbolSemantic(Dsymbol*, Scope*) (dsym=0x7f149b61cdd0, sc=0x0) at dmd/dsymbolsem.d:103 #32 0x00564779 in
[Issue 17906] Deprecated functions should not cause deprecated warnings for using deprecated features
https://issues.dlang.org/show_bug.cgi?id=17906 Mathias Lang changed: What|Removed |Added CC||mathias.l...@sociomantic.co ||m --- Comment #1 from Mathias Lang --- Yeah, put simply, the following code: ``` deprecated void main () { Object o = new Object; delete o; } ``` should compile with `dmd -de test.d` (DMD v2.079) Currently this is done for other deprecated symbols: deprecated functions can call other deprecated functions, use deprecated types, and a deprecated aggregate can have fields of deprecated types... So it should be done for language deprecations as well. --
[Issue 10933] findSplitBefore/After should have needle-less overloads
https://issues.dlang.org/show_bug.cgi?id=10933 --- Comment #1 from Luís Marques --- Yup, I've ran into the same issue multiple times. This last time with the plain findSplit; I don't recall if also with findSplitBefore/After. This workaround works: range.byCodeUnit.findSplit!((a, b) => a.isWhite)(" "); Interestingly, if you use "" instead of " " it won't work, which arguably is a bug, since the predicate doesn't even use b. --
[Issue 10933] findSplitBefore/After should have needle-less overloads
https://issues.dlang.org/show_bug.cgi?id=10933 Luís Marques changed: What|Removed |Added CC||l...@luismarques.eu --
[Issue 7930] Static initialization of static-sized array in union fails
https://issues.dlang.org/show_bug.cgi?id=7930 bitter.ta...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bitter.ta...@gmx.com Resolution|--- |FIXED --- Comment #2 from bitter.ta...@gmx.com --- Works on master. --
[Issue 18172] std.getopt should allow taking parameters by `ref` (like std.format.formattedRead), s.t. it can be used in @safe
https://issues.dlang.org/show_bug.cgi?id=18172 --- Comment #11 from Jack Stouffer --- (In reply to Walter Bright from comment #10) > (In reply to Jack Stouffer from comment #7) > > I should have emphized more the fact that I had already modified getopt. > > I've attached my changes as a patch > > Please submit this as a Pull Request to https://github.com/dlang/phobos It's at https://github.com/dlang/phobos/pull/6281 It's currently stalled due to a copying issue inherent in DIP1000's design that I'm planning on making a forum post on. --
[Issue 18461] codegen bug in dmd - assignments to ambiguous symbols
https://issues.dlang.org/show_bug.cgi?id=18461 Walter Bright changed: What|Removed |Added Hardware|x86_64 |All OS|Linux |All --
[Issue 18461] codegen bug in dmd - assignments to ambiguous symbols
https://issues.dlang.org/show_bug.cgi?id=18461 Walter Bright changed: What|Removed |Added Keywords||wrong-code CC||bugzi...@digitalmars.com Summary|codegen bug in dmd |codegen bug in dmd - ||assignments to ambiguous ||symbols --- Comment #10 from Walter Bright --- https://github.com/dlang/dmd/pull/8015 --
[Issue 16037] assigning delegate to a scope variable shouldn't allocate closure
https://issues.dlang.org/show_bug.cgi?id=16037 --- Comment #10 from anonymous4 --- (In reply to Mathias Lang from comment #9) > The web can get wide > pretty quickly, and suddenly your user is stuck in a situation where he has > to spend an unreasonable amount of time to change code that was not buggy to > begin with. Correct code won't be broken by this optimization. --
[Issue 18444] [DIP25][DIP1000] Tracking issue for: "The implementation doesn't match DIPs 25/1000"
https://issues.dlang.org/show_bug.cgi?id=18444 --- Comment #4 from Walter Bright --- (In reply to Carsten Blüggel from comment #3) > If it's of no special value for You, then it's worth to be/remain RESOLVED. > My vision is, phobos to be fully -dip1000 compilable before DConf2018 and > Seb and others are great in going this same direction. I agree with your agenda of making phobos fully -dip1000 by DConf. I'm glad you're focusing on that, enabling me to focus on making the compiler -dip1000 correct, as doing that gives a solid foundation for your goal. --
[Issue 18644] [dip1000] escape of outer local not detected
https://issues.dlang.org/show_bug.cgi?id=18644 --- Comment #3 from Walter Bright --- (In reply to Jonathan M Davis from comment #1) > int i; > int* foo() { return &i; } should behave like: int* foo(int* p) { return p; } and then the error is detected: int*[] b = [foo(&i)]; The [ ] puts things on the heap, where they escape. --
[Issue 18644] [dip1000] escape of outer local not detected
https://issues.dlang.org/show_bug.cgi?id=18644 --- Comment #2 from Walter Bright --- https://github.com/dlang/dmd/pull/8062 --
[Issue 18644] [dip1000] escape of outer local not detected
https://issues.dlang.org/show_bug.cgi?id=18644 Jonathan M Davis changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m --- Comment #1 from Jonathan M Davis --- Shouldn't the error be that int* foo() { return &i; } is trying to convert scope int* to int* in @safe code? Unless foo isn't inferred as @safe in spite of it being declared in an @safe function, but if that's the case, then calling foo should be an error, since otherwise, an @safe function would be calling an @system function without @trusted being involved. Certainly, given the fact that foo() returns int*, I don't see how int*[] b = [foo()]; // should detect error is invalid. It's only dealing with int*. So, there's no escaping as far is that bit of code is concerned. --
[Issue 18644] [dip1000] escape of outer local not detected
https://issues.dlang.org/show_bug.cgi?id=18644 Walter Bright changed: What|Removed |Added Keywords||safe --
[Issue 18644] New: [dip1000] escape of outer local not detected
https://issues.dlang.org/show_bug.cgi?id=18644 Issue ID: 18644 Summary: [dip1000] escape of outer local not detected Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com Consider: @safe void test() { int i; int*[] a = [&i]; // error detected correctly int* foo() { return &i; } int*[] b = [foo()]; // should detect error } --
[Issue 18637] [scope][DIP1000] "copying & i into allocated memory escapes a reference to local variable i" where it's inappropriate
https://issues.dlang.org/show_bug.cgi?id=18637 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #3 from Walter Bright --- Simplifying the test case: void test() { int i; int*[] a = [&i]; // Error: copying `& i` into allocated memory escapes a reference to local variable `i` } This can be worked around with: void test() { int i; int*[] a = [foo(&i)]; } int* foo(int* p) { return p; } It can be reasonably argued either way whether the original test case should be allowed in @system. I'll argue the workaround makes it obvious what one is doing, and unlikely to do it by accident. It's similar to: int* test() { int i; return &i; } being an error even in @system code. --
[Issue 15660] break immutable with pure function and mutable reference params
https://issues.dlang.org/show_bug.cgi?id=15660 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 15660] break immutable with pure function and mutable reference params
https://issues.dlang.org/show_bug.cgi?id=15660 --- Comment #8 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/ab5a18635adaa3e2271e0f4b569500a89ac74235 fix Issue 15660 - break immutable with pure function and mutable reference params https://github.com/dlang/dmd/commit/54ab04e0ab6d27d96c78eccf10bc162fd08535cf Merge pull request #8048 from WalterBright/fix15660 fix Issue 15660 - break immutable with pure function and mutable refe… merged-on-behalf-of: Walter Bright --
[Issue 18598] cyclic constructor calls have undefined behavior but are accepted in @safe code
https://issues.dlang.org/show_bug.cgi?id=18598 --- Comment #3 from Walter Bright --- (In reply to ag0aep6g from comment #2) > Is that a problem for normal (non-constructor) functions as well? Yes. I'm open to advice on what to do about it. --