[Issue 704] `class` destructor is called even if constructor throws
https://issues.dlang.org/show_bug.cgi?id=704 --- Comment #14 from anonymous4 --- (In reply to Steven Schveighoffer from comment #13) > (what the dtor is expecting) D has options there unlike C++. --
[Issue 5377] Ranges do not support tail-const
https://issues.dlang.org/show_bug.cgi?id=5377 Andrei Alexandrescu changed: What|Removed |Added CC||and...@erdani.com Resolution|WONTFIX |REMIND --- Comment #3 from Andrei Alexandrescu --- This would require a DIP if it is to be pursued. I'll re-close with REMIND. --
[Issue 17630] selective imports find symbols in private imports of other modules
https://issues.dlang.org/show_bug.cgi?id=17630
Timothee Cour changed:
What|Removed |Added
CC||timothee.co...@gmail.com
--- Comment #6 from Timothee Cour ---
just to make sure this is the same bug right?
```
// fun.d:
module fun;
import std.stdio;
// main.d:
import fun:writeln; // should not compile
void main(){ writeln("ok"); }
```
`rdmd main.d` works but should not compile
--
[Issue 18261] Linkage information isn't part of the json output
https://issues.dlang.org/show_bug.cgi?id=18261 --- Comment #1 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/984ebcbf5950e2416e2c87f802adc7a1d9701cdc Fix Issue 18261 - Linkage information isn't part of the json output --
[Issue 18149] Add a compiler trait to detect if a function is @disable
https://issues.dlang.org/show_bug.cgi?id=18149 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/43ef5ce21db45461138a0a313a9219ef15bdd900 fix issue 18149 - Add a compiler trait to detect if a function is @disabled https://github.com/dlang/dmd/commit/c68ae009586c128182c7ce268a9dd58f8d4d6969 Merge pull request #7569 from BBasile/issue-18149 fix issue 18149 - Add a compiler trait to detect if a function is @disable merged-on-behalf-of: unknown --
[Issue 18149] Add a compiler trait to detect if a function is @disable
https://issues.dlang.org/show_bug.cgi?id=18149 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 11747] Better error message with @disabled toString
https://issues.dlang.org/show_bug.cgi?id=11747 Issue 11747 depends on issue 18149, which changed state. Issue 18149 Summary: Add a compiler trait to detect if a function is @disable https://issues.dlang.org/show_bug.cgi?id=18149 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 17044] Bugzilla integration fails with reverts and multiple branches
https://issues.dlang.org/show_bug.cgi?id=17044 Seb changed: What|Removed |Added CC||greensunn...@gmail.com Assignee|nob...@puremagic.com|greensunn...@gmail.com --- Comment #2 from Seb --- The Bugzilla integration has been changed to be only active for `master`. This should reduce the noise significantly. --
[Issue 18260] ICE on template this parameter and alias this
https://issues.dlang.org/show_bug.cgi?id=18260
--- Comment #2 from Andrei Alexandrescu ---
A better workaround:
struct R {
int[] arr;
alias get this;
This get(this This)()
{
return This.init;
}
}
unittest
{
const(R) b = const(R).init;
}
I suspect the problem is an infinite recursion during semantic checking.
--
[Issue 18260] ICE on template this parameter and alias this
https://issues.dlang.org/show_bug.cgi?id=18260
Andrei Alexandrescu changed:
What|Removed |Added
CC||and...@erdani.com
--- Comment #1 from Andrei Alexandrescu ---
There is a workaround to this:
struct R {
int[] arr;
alias get this;
R get(this This)()
{
return R.init;
}
R get(this This)() const
{
return R.init;
}
}
unittest
{
const(R) b = const(R).init;
}
--
[Issue 17652] [DIP1000] opApply allow to escape reference to scope variable
https://issues.dlang.org/show_bug.cgi?id=17652 Carsten Blüggel changed: What|Removed |Added CC||chi...@posteo.net --
[Issue 17764] [scope][DIP1000] Escape checker defeated by composition transformations
https://issues.dlang.org/show_bug.cgi?id=17764 Carsten Blüggel changed: What|Removed |Added CC||chi...@posteo.net --
[Issue 17784] [scope][DIP1000] Confusing error message for escaping local via new-expression
https://issues.dlang.org/show_bug.cgi?id=17784 Carsten Blüggel changed: What|Removed |Added CC||chi...@posteo.net --
[Issue 17892] Scope analysis with -dip1000 fails for templated structs
https://issues.dlang.org/show_bug.cgi?id=17892 Carsten Blüggel changed: What|Removed |Added CC||chi...@posteo.net --
[Issue 17932] [scope] __traits(compiles, stmt) cannot test scope violations
https://issues.dlang.org/show_bug.cgi?id=17932 Carsten Blüggel changed: What|Removed |Added CC||chi...@posteo.net --
[Issue 17959] [DIP1000] Can store scope delegate in non-scope member
https://issues.dlang.org/show_bug.cgi?id=17959 Carsten Blüggel changed: What|Removed |Added CC||chi...@posteo.net --
[Issue 18000] [scope] auto-generated opAssign not scope aware
https://issues.dlang.org/show_bug.cgi?id=18000 Carsten Blüggel changed: What|Removed |Added CC||chi...@posteo.net --
[Issue 18145] Phobos makefile incorrectly sets --dip1000 for DMD when BUILD=debug
https://issues.dlang.org/show_bug.cgi?id=18145 Carsten Blüggel changed: What|Removed |Added CC||chi...@posteo.net --
[Issue 18264] New: Make Phobos buildable on low-memory machines
https://issues.dlang.org/show_bug.cgi?id=18264 Issue ID: 18264 Summary: Make Phobos buildable on low-memory machines Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: hst...@quickfur.ath.cx Currently, Phobos can't be built on low-memory Linux systems because compiling every Phobos module on a single command-line causes dmd to soak up all memory and invoke the dreaded kernel OOM killer. (The system tested on has 1GB memory. Not a lot, but not meager either.) I managed to build Phobos by splitting that large compile command into smaller chunks, basically by compiling 1/3 of Phobos into libphobos2-part1.a, then another 1/3 into libphobos2-part2.a, then another into libphobos2-part3.a, then a final link with druntime and the C object files to link everything together into libphobos2.a. While this may not be representative usage, it would be very nice to provide the option to compile Phobos this way in posix.mak. See also issue #10906, which was partly alleviated, but ultimately doesn't solve the fundamental problem that asking dmd to compile the entirety of Phobos all at once causes extreme memory usage. --
[Issue 17440] Nullable.nullify() resets referenced object
https://issues.dlang.org/show_bug.cgi?id=17440 --- Comment #17 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/5b04f455711a517cec273dad5eb4e4fda193ebff Fix issue 17440: do not call .destroy on class instances in .nullify. https://github.com/dlang/phobos/commit/0666fc6e21b594321fe638d30865b0eef472f7a5 Merge pull request #6043 from quickfur/issue17440b Fix issue 17440: do not call .destroy on class instances in Nullable.nullify merged-on-behalf-of: Steven Schveighoffer --
[Issue 17440] Nullable.nullify() resets referenced object
https://issues.dlang.org/show_bug.cgi?id=17440 github-bugzi...@puremagic.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --
[Issue 704] `class` destructor is called even if constructor throws
https://issues.dlang.org/show_bug.cgi?id=704
Steven Schveighoffer changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- Comment #13 from Steven Schveighoffer ---
(In reply to anonymous4 from comment #12)
> Isn't it only true for C++ that destructor can't be called on an object that
> wasn't constructed? In C++ destructor can't be called because there's no
> default initialization before constructor, but in D I think destructor can
> be called because it won't run on garbage.
It's not garbage, but it's also potentially not a valid object (what the dtor
is expecting).
I'm unsure who is responsible for cleaning up the non-GC resources. Normally
the destructor does this, but if you are throwing in the constructor, then you
could do it there. However, base constructors will not be able to catch this
condition.
If I had to define it myself, I think it shouldn't be left to the GC to clean
it up. If the destructor should be called after the constructor fails via
exception, it should happen immediately (and only the destructors for which the
constructors have completed).
e.g.:
class A
{
int x;
this() { writeln("A.ctor"); x = 5; }
~this() { writeln("A.dtor"); assert(x == 5); x = 0; }
}
class B : A
{
int y;
this(bool bad) { writeln("B.ctor"); super(); if(bad) throw new Exception();
y = 6; }
~this() { writeln("B.dtor"); assert(y == 6); y = 0; }
}
void main()
{
try { new B(true); } catch() {}
writeln("done main");
}
expected output:
A.ctor
B.ctor
A.dtor
done main
--
[Issue 704] `class` destructor is called even if constructor throws
https://issues.dlang.org/show_bug.cgi?id=704 --- Comment #12 from anonymous4 --- Isn't it only true for C++ that destructor can't be called on an object that wasn't constructed? In C++ destructor can't be called because there's no default initialization before constructor, but in D I think destructor can be called because it won't run on garbage. --
[Issue 18262] stdx.allocator.building_blocks.bitmapped_block has spurious failures on the auto-tester
https://issues.dlang.org/show_bug.cgi?id=18262 Basile B. changed: What|Removed |Added Status|NEW |RESOLVED CC||b2.t...@gmx.com Resolution|--- |DUPLICATE --- Comment #1 from Basile B. --- *** This issue has been marked as a duplicate of issue 18140 *** --
[Issue 18140] experimental allocators, bitmapped_block UB on OSX 64 bits
https://issues.dlang.org/show_bug.cgi?id=18140 Basile B. changed: What|Removed |Added CC||greensunn...@gmail.com --- Comment #1 from Basile B. --- *** Issue 18262 has been marked as a duplicate of this issue. *** --
[Issue 18263] New: selective import with same name masks out this reference in mixin template
https://issues.dlang.org/show_bug.cgi?id=18263
Issue ID: 18263
Summary: selective import with same name masks out this
reference in mixin template
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: default_357-l...@yahoo.de
The following code fails with an error:
mixin template HappyFunTime()
{
static void foo()
{
import std.meta : Filter;
alias bar = this.bar;
}
}
struct Filter
{
void bar() { }
mixin HappyFunTime;
}
test.d(9): Error: identifier 'bar' of 'Filter.bar' is not defined
What happens is that because both Filter and std.meta.Filter have the same
name, the import for std.meta.Filter somehow masks out the struct Filter for
the "this" lookup in the alias.
This is horrifying. If this lookup absolutely has to be done by name, it should
at least be done by fqn.
--
[Issue 18262] New: stdx.allocator.building_blocks.bitmapped_block has spurious failures on the auto-tester
https://issues.dlang.org/show_bug.cgi?id=18262 Issue ID: 18262 Summary: stdx.allocator.building_blocks.bitmapped_block has spurious failures on the auto-tester Product: D Version: D2 Hardware: x86_64 OS: Mac OS X Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: greensunn...@gmail.com core.exception.AssertError@std/experimental/allocator/building_blocks/bitmapped_block.d(177): Data must be aligned properly 4 test_runner 0x00010ab6496b onAssertErrorMsg + 107 5 test_runner 0x00010ab64bc8 _d_assert_msg + 68 6 test_runner 0x00010a68049b pure ref std.experimental.allocator.building_blocks.bitmapped_block.BitmappedBlock!(128uL, 16u, std.experimental.allocator.building_blocks.null_allocator.NullAllocator).BitmappedBlock std.experimental.allocator.building_blocks.bitmapped_block.BitmappedBlock!(128uL, 16u, std.experimental.allocator.building_blocks.null_allocator.NullAllocator).BitmappedBlock.__ctor(ubyte[]) + 111 7 test_runner 0x00010a682dd2 pure std.experimental.allocator.building_blocks.bitmapped_block.BitmappedBlock!(128uL, 16u, std.experimental.allocator.building_blocks.null_allocator.NullAllocator).BitmappedBlock std.experimental.allocator.building_blocks.bitmapped_block.BitmappedBlock!(128uL, 16u, std.experimental.allocator.building_blocks.null_allocator.NullAllocator).BitmappedBlock.__unittest_std_experimental_allocator_building_blocks_bitmapped_block_57_16().__lambda2() + 102 8 test_runner 0x00010a68258b void std.experimental.allocator.common.testAllocator!(std.experimental.allocator.building_blocks.bitmapped_block.BitmappedBlock!(128uL, 16u, std.experimental.allocator.building_blocks.null_allocator.NullAllocator).BitmappedBlock.__unittest_std_experimental_allocator_building_blocks_bitmapped_block_57_16().__lambda2()).testAllocator() + 39 9 test_runner 0x00010a680316 void std.experimental.allocator.building_blocks.bitmapped_block.BitmappedBlock!(128uL, 16u, std.experimental.allocator.building_blocks.null_allocator.NullAllocator).BitmappedBlock.__unittest_std_experimental_allocator_building_blocks_bitmapped_block_57_16() + 74 10 test_runner 0x00010a67ed65 void std.experimental.allocator.building_blocks.affix_allocator.__modtest() + 53 11 test_runner 0x000109610683 void test_runner.doTest(object.ModuleInfo*, ref core.runtime.UnitTestResult) + 99 12 test_runner 0x00010961058b core.runtime.UnitTestResult test_runner.testModules() + 395 13 test_runner 0x0001096103d7 core.runtime.UnitTestResult test_runner.tester() + 31 14 test_runner 0x00010ab656a3 runModuleUnitTests + 151 15 test_runner 0x00010ab7a3b5 void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() + 37 16 test_runner 0x00010ab7a333 void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) + 51 17 test_runner 0x00010ab7a296 _d_run_main + 814 18 test_runner 0x000109610285 main + 33 19 test_runner 0x000109610243 start + 51 20 ??? 0x0001 0x0 + 1 make[1]: *** [unittest/std/experimental/allocator/building_blocks/affix_allocator.run] Error 1 make[1]: *** Waiting for unfinished jobs 0.031s PASS debug64 std.experimental.allocator.building_blocks.allocator_list --
[Issue 14907] DMD crash when using template name as a default value of template's typed argument
https://issues.dlang.org/show_bug.cgi?id=14907 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/a49866792e19631fed5d352aebc83ca6aa3222b2 fix Issue 14907 - DMD crash when using template name as a default value of template's typed argument https://github.com/dlang/dmd/commit/6dd820f9c09bd757fb3e31600b1dec8ce0628a12 Merge pull request #7702 from ibuclaw/fix14907 fix Issue 14907 - DMD crash when using template name as a default value of template's typed argument merged-on-behalf-of: Mike Franklin --
[Issue 18260] ICE on template this parameter and alias this
https://issues.dlang.org/show_bug.cgi?id=18260 anonymous4 changed: What|Removed |Added Hardware|x86 |All OS|Windows |All --
[Issue 18261] New: Linkage information isn't part of the json output
https://issues.dlang.org/show_bug.cgi?id=18261 Issue ID: 18261 Summary: Linkage information isn't part of the json output Product: D Version: D2 Hardware: x86_64 OS: All Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: greensunn...@gmail.com --
[Issue 18260] New: ICE on template this parameter and alias this
https://issues.dlang.org/show_bug.cgi?id=18260
Issue ID: 18260
Summary: ICE on template this parameter and alias this
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Keywords: ice
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: simen.kja...@gmail.com
The following code causes DMD to hang:
struct R {
int[] arr;
alias get this;
R get(this This)() {
return R.init;
}
}
unittest {
const(R) b = const(R).init;
}
As far as my testing shows, every line is necessary, and arr must be a dynamic
array. Changing get() to assert(false) instead of return, removes the bug.
--
