[Issue 18594] X is not an lvalue should have a better error message
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
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
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
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); -} --
[Issue 18133] BitArray constructors are poorly documented.
https://issues.dlang.org/show_bug.cgi?id=18133 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/3609d7233414fbd8a9d0c21313be21aff02d6829 Merge pull request #6112 from byebye/issue_18133 Fix issue 18133 - improve docs and add code examples for BitArray constructors merged-on-behalf-of: Jack Stouffer --
[Issue 18591] DMD should allow access to mixin template declarations
https://issues.dlang.org/show_bug.cgi?id=18591 Simen Kjaeraas changed: What|Removed |Added CC||simen.kja...@gmail.com --- Comment #2 from Simen Kjaeraas --- Issue example from PR: struct TypeObj { alias This = typeof(this); mixin template MixinTempl() { int value; } } ref TypeObj Obj() { static TypeObj a; return a; } void main() { mixin Obj.This.MixinTempl; // ok mixin Obj.MixinTempl; // error: "MixinTempl!()" is not defined } --
[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|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution|--- |INVALID --- Comment #1 from Walter Bright --- (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. > The compiler doesn't seem to recognize that ls is attributed with `scope`. > However due to the way D's attributes are parsed, I'm not sure if it should > actually be `scope string*[]`, `scope(string*)[]`, or `scope(string*[])`. > Anyway, if you use `scope()` (i.e. with parens) the compiler confuses it > with `scope(exit)` and friends. > > > void main() @safe > { > string foo = "foo"; > scope(string*[]) ls; > ls ~= &foo; > } > > Compile with `-dip1000` > > onlineapp.d(4): Error: valid scope identifiers are exit, failure, or > success, not string Scope is a storage class, not a type constructor. (`const`, for example, is a type constructor, and `static` is a storage class.) --
[Issue 17961] std.uni does not compile with -unittest -dip1000
https://issues.dlang.org/show_bug.cgi?id=17961 Carsten Blüggel changed: What|Removed |Added Blocks||18585 Referenced Issues: https://issues.dlang.org/show_bug.cgi?id=18585 [Issue 18585] Linker error if compiled with -dip1000 --
[Issue 18585] Linker error if compiled with -dip1000
https://issues.dlang.org/show_bug.cgi?id=18585 Carsten Blüggel changed: What|Removed |Added Keywords||rejects-valid, safe CC||chi...@posteo.net Depends on||17961 --- Comment #1 from Carsten Blüggel --- The origin of errors seems to be, that std.uni is not -dip1000 compilable currently. Referenced Issues: https://issues.dlang.org/show_bug.cgi?id=17961 [Issue 17961] std.uni does not compile with -unittest -dip1000 --
[Issue 18000] [scope] auto-generated opAssign not scope aware
https://issues.dlang.org/show_bug.cgi?id=18000 --- Comment #1 from Walter Bright --- Attributes are inferred for the generated opAssign, the result looks like: @nogc ref return @trusted File opAssign(File p) Not sure why scope is not inferred. In any case, the example has problems as well: scope File f; f = File(); The lifetime of File() is less than that of f, so this example should fail to compile for that reason. https://issues.dlang.org/show_bug.cgi?id=17977 addresses that. --
[Issue 18591] DMD should allow access to mixin template declarations
https://issues.dlang.org/show_bug.cgi?id=18591 --- Comment #1 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/786bdb338a64fa52b24ab515edf6706b259447de Fix Issue 18591 - Allow getting type from template declarations. --
[Issue 17959] [DIP1000] Can store scope delegate in non-scope member
https://issues.dlang.org/show_bug.cgi?id=17959 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright --- https://github.com/dlang/dmd/pull/8008 --
[Issue 17932] [scope] __traits(compiles, stmt) cannot test scope violations
https://issues.dlang.org/show_bug.cgi?id=17932 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Walter Bright --- Adding @safe to the lambda: void test() @safe { int var; scope int* p; static int* escape; static assert(!__traits(compiles, () @safe { escape = p; })); //escape = p; } and it compiles without error. The lambda does not inherit @safe from the function. Perhaps it should, but that would be an enhancement request, and would possibly break existing code. It should be the subject of a separate issue. --
[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate
https://issues.dlang.org/show_bug.cgi?id=17449 --- Comment #11 from Rainer Schuetze --- BTW: AFAIK -dip1000 is only supposed to affect @safe code, but there is no @safe in the original test cases. --
[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate
https://issues.dlang.org/show_bug.cgi?id=17449 Rainer Schuetze changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #10 from Rainer Schuetze --- I didn't mean to change the status, but reopening is probably appropriate. --
[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate
https://issues.dlang.org/show_bug.cgi?id=17449 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #9 from ag0ae...@gmail.com --- (In reply to Rainer Schuetze from comment #8) > As with the modified reduced test case with @safe, this is still crashing > for me (Win32 and Win64 with git HEAD). Checking the disassembly for > compiling with -dip1000 it doesn't generate the closure that it is > generating without the switch. If it still crashes, did you mean to reopen this issue? (You changed it from WORKSFORME to FIXED.) --
[Issue 18594] X is not an lvalue should have a better error message
https://issues.dlang.org/show_bug.cgi?id=18594 Seb changed: What|Removed |Added Summary|constant 1 is not an lvalue |X is not an lvalue should |should have a better error |have a better error message |message | --
[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate
https://issues.dlang.org/show_bug.cgi?id=17449 Rainer Schuetze changed: What|Removed |Added Resolution|WORKSFORME |FIXED --- Comment #8 from Rainer Schuetze --- > Fixing the code with @safe and @trusted: As with the modified reduced test case with @safe, this is still crashing for me (Win32 and Win64 with git HEAD). Checking the disassembly for compiling with -dip1000 it doesn't generate the closure that it is generating without the switch. --
[Issue 18594] constant 1 is not an lvalue should have a better error message
https://issues.dlang.org/show_bug.cgi?id=18594 --- Comment #1 from Seb --- (PR incoming) --
[Issue 18594] New: constant 1 is not an lvalue should have a better error message
https://issues.dlang.org/show_bug.cgi?id=18594 Issue ID: 18594 Summary: constant 1 is not an lvalue should have a better error message Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: greensunn...@gmail.com --- void main() { assert(1 = 2); } --- currently errors with "foo.d(2): Error: constant 1 is not an lvalue". The error message should be better: (1) not mention lvalue and (2) suggesting `==`. --
[Issue 17764] [scope][DIP1000] Escape checker defeated by composition transformations
https://issues.dlang.org/show_bug.cgi?id=17764 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Walter Bright --- The following remain: --- @safe: struct Context0x0 { char[] str; } struct Parent0x1 { Context0x0 c; } struct Parent0x2 { Context0x0[1] csa; } struct Parent0x3 { Context0x0[] csl; } struct Parent0x4 { Context0x0*cp; } struct Parent0x5 { Parent0x1 p1; } struct Parent0x6 { Parent0x5 p5; } struct Parent0x7 { Parent0x6 p6; } struct Parent0x8 { Parent0x2[1]* p2; } struct Parent0x9 { Parent0x8[1] p8; } struct Parent0xA { Parent0x9[1] p9; } struct Parent0xB { Parent0x4* p4; } struct Parent0xC { Parent0xB* pb; } struct Parent0xD { Parent0xC* pc; } char[] global; void use0x2(scope char[]* arr) { global = *arr; // NG - accepts invalid } void use0x9(scope ref Parent0x4 p) { global = p.cp.str; // NG - accepts invalid } void use0xB(scope ref Parent0xA p) { global = (*p.p9[0].p8[0].p2)[0].csa[0].str; // NG - accepts invalid } void use0xC(scope ref Parent0xD p) { global = p.pc.pb.p4.cp.str; // NG - accepts invalid } --- All of them are instances of transitive scope, but scope is not transitive. Not compiler bugs. --
[Issue 18593] New: std.datetime.stopwatch.benchmark shouldn't optimize away its functions
https://issues.dlang.org/show_bug.cgi?id=18593 Issue ID: 18593 Summary: std.datetime.stopwatch.benchmark shouldn't optimize away its functions Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: pull Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: greensunn...@gmail.com See: https://github.com/dlang/phobos/pull/5416 --
[Issue 15653] IFTI fails for immutable parameter
https://issues.dlang.org/show_bug.cgi?id=15653 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 15653] IFTI fails for immutable parameter
https://issues.dlang.org/show_bug.cgi?id=15653 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/d68e181bda060f8e61253620695a3aadf0ad1093 Fix issue 15653 - IFTI fails for immutable parameter https://github.com/dlang/dmd/commit/5fa45d1a355b5bd24caaeddf71b21d94561c3174 Add links to bugzilla for issue 15653 https://github.com/dlang/dmd/commit/25fbcbe2baaf085e679bc281954b208e076d7471 Merge pull request #7977 from JinShil/fix_15653 Fix issue 15653 - IFTI fails for immutable parameter merged-on-behalf-of: Sebastian Wilzbach --
[Issue 17512] [REG 2.073] [DIP1000] Error on bad interplay of 'auto ref' and 'return' attribute deduction.
https://issues.dlang.org/show_bug.cgi?id=17512 --- Comment #5 from Walter Bright --- https://github.com/dlang/dmd/pull/8001 --
[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate
https://issues.dlang.org/show_bug.cgi?id=17449 Walter Bright changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Walter Bright --- Fixing the code with @safe and @trusted: --- module test; @safe: struct Event9834 { @safe: void delegate() dg; void set(void delegate() @safe h) pure { dg = h; } // AV occurs void call() { dg(); } } void main() { Event9834 ev; auto a = new class { Object o; this() @safe { o = new Object; ev.set(() @trusted { o.toString(); }); } }; ev.call(); } --- and it compiles and runs without error, with or without -dip1000. --
[Issue 17448] Move semantics cause memory corruption and cryptic bugs
https://issues.dlang.org/show_bug.cgi?id=17448 --- Comment #35 from Walter Bright --- (In reply to Shachar Shemesh from comment #33) > You cannot be notified when the object > moves, and once it does, the global linked list will get completely > corrupted. That is correct, and you are right to be concerned about it. However, from a pragmatic point of view, the compiler cannot move objects that have external pointers to them (unless it can unambiguously find them all and update them). This is why, for example, there is an API in the GC to register pointers to objects that are unknown to the GC. 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. 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. But there's another wrinkle. With RVO (Return Value Optimization), if the stack object is returned, and it is not returned in registers, it is actually not returned. It is allocated in the caller's stack frame! and is not moved. This is now the case with all the examples you've provided. So, to guarantee RVO: 1. the object must be returned on the stack, not in registers. This can be tested as shown in the documentation: https://dlang.org/spec/traits.html#isReturnOnStack Generally speaking, a struct that is larger than two registers, or is not POD (Plain Old Data), will return on the stack and not in registers. 2. use only one return statement in the function. Having multiple returns can defeat RVO. 3. do not pass the object as a parameter to other functions, as the compiler may 'move' it onto the parameter stack if there are no more references to the object. If you must pass it as a parameter, pass it by `ref`. Objects can also be constructed directly into their final destination by passing them as `out` parameters. 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. 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. --
[Issue 18024] checkedint.Abort should be @safe
https://issues.dlang.org/show_bug.cgi?id=18024 Seb changed: What|Removed |Added Summary|checkedint.Warn should be |checkedint.Abort should be |@safe |@safe --
[Issue 17423] pointer assignment to `this` in member function is not accounted for
https://issues.dlang.org/show_bug.cgi?id=17423 --- Comment #8 from Walter Bright --- (In reply to Walter Bright from comment #7) > https://github.com/dlang/dmd/pull/7999 For this to work, -dip1000 must be used. --
[Issue 18519] freebsd 11 + phobos + curl, timing out
https://issues.dlang.org/show_bug.cgi?id=18519 Seb changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from Seb --- REOPENED as I just tested the PR with https://github.com/dlang/phobos/pull/6264 and the problem still seems to be existent. --
[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 Seb changed: What|Removed |Added Keywords||safe --
[Issue 18592] New: Associative array assignment with a destructor should be @safe if the destructor is @safe
https://issues.dlang.org/show_bug.cgi?id=18592 Issue ID: 18592 Summary: Associative array assignment with a destructor should be @safe if the destructor is @safe Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: greensunn...@gmail.com cat > main.d << EOF void main() @safe { struct ThrowingElement { int i; ~this() { assert(1); } } ThrowingElement[int] aa; aa[0] = ThrowingElement(0); } EOF The problem is that the generated opAssign is @system: ref return @system ThrowingElement opAssign(ThrowingElement p) { (ThrowingElement __swap2 = void;) , __swap2 = this , this = p , __swap2.~this(); return this; } --
[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate
https://issues.dlang.org/show_bug.cgi?id=17449 --- Comment #6 from Rainer Schuetze --- > Adding more @safe Makes it compile and run successfully. Your safe code also fails with -dip1000. (tried on Windows/OMF). --
[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate
https://issues.dlang.org/show_bug.cgi?id=17449 --- Comment #5 from Rainer Schuetze --- > This is because 'scope' for delegates now means something with dip1000, it > means the delegate must not escape. There is no "scope" in the test cases. I suspect it is falsely inferred. --
[Issue 18549] name gets overwritten in template definition
https://issues.dlang.org/show_bug.cgi?id=18549 Johannes Nordhoff changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #3 from Johannes Nordhoff --- ah, sorry, i get it. sorry --
[Issue 18591] New: DMD should allow access to mixin template declarations
https://issues.dlang.org/show_bug.cgi?id=18591 Issue ID: 18591 Summary: DMD should allow access to mixin template declarations Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: greensunn...@gmail.com https://github.com/dlang/dmd/pull/7973 --
[Issue 18549] name gets overwritten in template definition
https://issues.dlang.org/show_bug.cgi?id=18549 Johannes Nordhoff changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #2 from Johannes Nordhoff --- > > the compiler was using the same name for multiple > > template-definitions. > > I don't understand what you mean by this. If you still think the compiler > should do something differently here, please feel free to reopen. > yeah, the error message should say: sth.d(11): Error: sth.tmpl called with argument types () matches both: sth.d(6): sth.tmpl!(SS).tmpl() and: sth.d(7): sth.tmpl!(tt).tmpl() but instead it says: sth.d(11): Error: sth.tmpl called with argument types () matches both: sth.d(6): sth.tmpl!(SS).tmpl() and: sth.d(7): sth.tmpl!(SS).tmpl() --
[Issue 18110] most of phobos should be @safe-ly useable
https://issues.dlang.org/show_bug.cgi?id=18110 Issue 18110 depends on issue 18158, which changed state. Issue 18158 Summary: std.file.getcwd should be usable in @safe https://issues.dlang.org/show_bug.cgi?id=18158 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18178] std.path should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18178 Issue 18178 depends on issue 18158, which changed state. Issue 18158 Summary: std.file.getcwd should be usable in @safe https://issues.dlang.org/show_bug.cgi?id=18158 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18158] std.file.getcwd should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18158 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18158] std.file.getcwd should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18158 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/767d1c51d4ae2e24c9d1752db4c1f1b881a3b658 Fix Issue 18158 - std.file.getcwd should be usable in @safe https://github.com/dlang/phobos/commit/ba11d630a02345fa634d098694273f145fc5428f Merge pull request #6252 from JackStouffer/issue18158 Fix Issue 18158 - std.file.getcwd should be usable in @safe merged-on-behalf-of: Jack Stouffer --
[Issue 17819] static foreach segfaults on __traits(allMembers)
https://issues.dlang.org/show_bug.cgi?id=17819 bitter.ta...@gmx.com changed: What|Removed |Added CC||bitter.ta...@gmx.com --- Comment #3 from bitter.ta...@gmx.com --- There's a stack overflow in Dsymbol's _foreach, every time it recurses into a AttribDeclaration (such as the `static foreach') the stack gets deeper until it explodes. --
[Issue 18126] [internal] Reduce number of turned off warnings.
https://issues.dlang.org/show_bug.cgi?id=18126 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Iain Buclaw --- This was implemented in https://github.com/dlang/dmd/pull/7958 --
[Issue 18182] std.uri should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18182 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/9d44d7c13fc312bc39669df441f8b931789471c1 Fix Issue 18182 - std.uri should be usable in @safe https://github.com/dlang/phobos/commit/8ec15a80ff844bd3457939cb4662952f736e7f50 Merge pull request #6256 from JackStouffer/issue18182 Fix Issue 18182 - std.uri should be usable in @safe merged-on-behalf-of: Jack Stouffer --
[Issue 18182] std.uri should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18182 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 18182, which changed state. Issue 18182 Summary: std.uri should be usable in @safe https://issues.dlang.org/show_bug.cgi?id=18182 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18590] New: nothrow constructor call still type-checks destructor for purity
https://issues.dlang.org/show_bug.cgi?id=18590 Issue ID: 18590 Summary: nothrow constructor call still type-checks destructor for purity Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: dmd Assignee: nob...@puremagic.com Reporter: c...@dawg.eu cat > bug.d << CODE extern(C) int printf(const char*, ...); struct F { static F create() pure nothrow { return F(1); } this(int) pure nothrow { } ~this() { printf("~this\n"); } } CODE dmd -c bug Error: pure function 'bug.F.create' cannot call impure function 'bug.F.~this' Apparently happens because `F(1)` is lowered to `(tmp = F(1)),tmp` internally. https://github.com/dlang/dmd/blob/93804714c4091a8d867c09ca7b5bf332acb34dfb/src/dmd/expression.d#L3931 --
[Issue 18537] Cannot pass absolute path to coverage options
https://issues.dlang.org/show_bug.cgi?id=18537 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/feb6e9b2f035f2b564765120e6fb794abfd53622 fix Issue 18537 - Cannot pass absolute path to coverage options allow DRT arguments to include '=' or ':', splitting is done by ' ' https://github.com/dlang/druntime/commit/ab14e9af2b9f4bbea00d543fe229047ede4dd909 Merge pull request #2120 from rainers/issue18537 fix Issue 18537 - Cannot pass absolute path to coverage options --
[Issue 18519] freebsd 11 + phobos + curl, timing out
https://issues.dlang.org/show_bug.cgi?id=18519 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/b8e5bca94b661c1d1ffb9ec6f7e37b9fa7a0d09d fix issue 18519 freebsd 11 + phobos + curl, timing out stop the TestServer waiting in accept() before thread_joinall https://github.com/dlang/phobos/commit/35e9807bbec392658ecdc8b4ed93d1f6c02f2845 Merge pull request #6234 from rainers/curl_freeze fix issue 18519 freebsd 11 + phobos + curl, timing out merged-on-behalf-of: Petar Kirov --
[Issue 17448] Move semantics cause memory corruption and cryptic bugs
https://issues.dlang.org/show_bug.cgi?id=17448 --- Comment #34 from Eyal --- Walter: Thanks, the RVO fixes are very useful and important - and will be part of any future solution we have! --
[Issue 18547] Win32: throwing exception in fiber crashes application
https://issues.dlang.org/show_bug.cgi?id=18547 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/a1a5ad8d70464534228839ad8f1f2a7938cb9524 fix issue 18547 - Win32: throwing exception in fiber crashes application increase the default stack size because exception handling might need up to 16k. The actually used stack can depend on the version of DbgHelp.dll, the existence of debug information and possibly other conditions. https://github.com/dlang/druntime/commit/86cd40a036a67d9b1bff6c14e91cba1e5557b119 Merge pull request #2129 from rainers/issue18547 fix issue 18547 - Win32: throwing exception in fiber crashes application merged-on-behalf-of: Petar Kirov --
[Issue 18547] Win32: throwing exception in fiber crashes application
https://issues.dlang.org/show_bug.cgi?id=18547 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 17512] [REG 2.073] [DIP1000] Error on bad interplay of 'auto ref' and 'return' attribute deduction.
https://issues.dlang.org/show_bug.cgi?id=17512 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com Summary|[REG 2.073] [DIP1000] Error |[REG 2.073] [DIP1000] Error |on bad interplay of "auto |on bad interplay of 'auto |ref" and "return" attribute |ref' and 'return' attribute |deduction. |deduction. --
[Issue 18589] New: Windows header files: bcrypt and ncrypt
https://issues.dlang.org/show_bug.cgi?id=18589 Issue ID: 18589 Summary: Windows header files: bcrypt and ncrypt Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: an...@s-e-a-p.de Could you add the windows header files for bcrypt and ncrypt to src\druntime\src\core\sys\windows? Thanks a lot. --
[Issue 17449] [DIP1000] crash due to covariant conversion of scope delegate to delegate
https://issues.dlang.org/show_bug.cgi?id=17449 --- Comment #4 from Walter Bright --- (In reply to Rainer Schuetze from comment #3) > Are you saying that it is ok that adding -dip1000 can change code gen so > that it crashes? Yes. This is because 'scope' for delegates now means something with dip1000, it means the delegate must not escape. If it does, and this is not checked for in non-@safe functions, it will likely crash. > I don't see anything unsafe and invalid in the original code. Could you > elaborate? Please note that it it also in the dmd test suite. The problem is the delegate escapes from its stack frame, and no closure was allocated. The scope checking with delegates is a backwards compatibility thing, as people often pass scope delegates to non-scope delegate parameters. --
[Issue 17448] Move semantics cause memory corruption and cryptic bugs
https://issues.dlang.org/show_bug.cgi?id=17448 --- Comment #33 from Shachar Shemesh --- Like we said earlier, the safe implications are important, but are not the core of this bug report. The problem is that, as things stand with D, certain types of programming become impossible. For example, consider a RAII object protecting a resource (say, a file descriptor). For debugging purposes, we want to have a version(debug) option for tracking all such objects within the system. Under C++, what we'd do is to have a global linked list head, and have each RAII object register itself with the linked list in the constructor and deregister itself in the destructor. If necessary, we would have a move constructor that shifts the registration when the RAII is moved. This last step is impossible in D. You cannot be notified when the object moves, and once it does, the global linked list will get completely corrupted. --
[Issue 17448] Move semantics cause memory corruption and cryptic bugs
https://issues.dlang.org/show_bug.cgi?id=17448 --- Comment #32 from Walter Bright --- I filed two bug reports based on Tomer's work: https://issues.dlang.org/show_bug.cgi?id=18575 https://issues.dlang.org/show_bug.cgi?id=18576 which have PRs: https://github.com/dlang/dmd/pull/7989 https://github.com/dlang/dmd/pull/7990 The second example in comment 1 is a bug in the example, as: auto f() {auto x = g();} should be: auto f() { return g();} This addresses all the issues in examples provided. I.e. the escapes are properly detected with -dip1000, and the structs don't move due to RVO (Return Value Optimization) where the results are written into the caller's stack frame. If you discover more problems with escape detection and moved stack objects, please let me know with examples. Thanks! --
[Issue 17423] pointer assignment to `this` in member function is not accounted for
https://issues.dlang.org/show_bug.cgi?id=17423 --- Comment #7 from Walter Bright --- https://github.com/dlang/dmd/pull/7999 --
[Issue 17423] pointer assignment to `this` in member function is not accounted for
https://issues.dlang.org/show_bug.cgi?id=17423 --- Comment #6 from Walter Bright --- The opApply is actually working correctly. The bug is that the dlg parameter was incorrectly inferred as `scope`. --
[Issue 17423] pointer assignment to `this` in member function is not accounted for
https://issues.dlang.org/show_bug.cgi?id=17423 Walter Bright changed: What|Removed |Added Summary|@safe code seg faults |pointer assignment to ||`this` in member function ||is not accounted for --