[Issue 13798] New: Suggestions for classes and methods that can be final
https://issues.dlang.org/show_bug.cgi?id=13798
Issue ID: 13798
Summary: Suggestions for classes and methods that can be final
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
I suggest to add a compiler tip (enabled with warnings) that suggests the
programmer to add a final to methods and to classes definitions like this
that don't need to be virtual, to avoid some virtual calls:
class Bar {}
class Foo : Bar {}
void main() {}
This is similar to the -Wsuggest-final-types and -Wsuggest-final-methods
warnings of G++ 5.0, that also tells how many virtual calls are avoided:
/aux/hubicka/firefox/docshell/base/nsDocShell.h:124:0: warning: Declaring type
‘struct nsDocShell’ final would enable devirtualization of 216 calls
[-Wsuggest-final-types]
class nsDocShell : public nsDocLoader,
^
--
[Issue 13799] New: Whole-array initialization for static fixed-size arrays of arrays too
https://issues.dlang.org/show_bug.cgi?id=13799
Issue ID: 13799
Summary: Whole-array initialization for static fixed-size
arrays of arrays too
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Keywords: rejects-valid
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
Please allow the missing common case too:
int[2][2] m1 = [[1, 1], [1, 1]]; // OK
int[2][2] m2 = 1; // Error
void main() {
int[2][2] m3 = [[1, 1], [1, 1]]; // OK
int[2][2] m4 = 1; // OK
}
dmd 2.067alpha:
test.d(2,16): Error: cannot implicitly convert expression (1) of type int to
int[2][2]
It's expecially useful when the size is a compile-time constant defined
elsewhere that is not known locally:
enum N = 5;
int[N][N] m = 1; // Error
void main() {}
--
[Issue 12735] imports via mixin template become public imports
https://issues.dlang.org/show_bug.cgi?id=12735
nick nicolas.jincher...@gmail.com changed:
What|Removed |Added
CC||nicolas.jincher...@gmail.co
||m
--- Comment #2 from nick nicolas.jincher...@gmail.com ---
bump
//
module one;
int someSymbol = 1;
//
module two;
import one;
//
module main;
import two;
void main() {
enum hasMember = __traits(hasMember, two, someSymbol);
writeln(hasMember.stringof); // true
enum compiles = __traits(compiles, { __traits(getMember, two,
someSymbol); });
writeln(compiles.stringof);// false
// Error: undefined identifier 'someSymbol'
// writeln(__traits(getMember, two, someSymbol).stringof);
}
--
[Issue 13800] New: Class from mixin template missing from ModuleInfo
https://issues.dlang.org/show_bug.cgi?id=13800
Issue ID: 13800
Summary: Class from mixin template missing from ModuleInfo
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: nicolas.jincher...@gmail.com
program output does not contain SomeClass.
///***
module main;
import std.stdio;
mixin template Test() {
class SomeClass { }
}
mixin Test;
void main() {
auto sc = new SomeClass;
assert(sc);
foreach(m; ModuleInfo) {
foreach(c; m.localClasses) {
writeln(c.name);
}
}
}
--
[Issue 13587] Symbols In Template Mixin Conflict Across Modules
https://issues.dlang.org/show_bug.cgi?id=13587 nick nicolas.jincher...@gmail.com changed: What|Removed |Added CC||nicolas.jincher...@gmail.co ||m --- Comment #1 from nick nicolas.jincher...@gmail.com --- possible duplicate: https://issues.dlang.org/show_bug.cgi?id=12735 --
[Issue 12773] Compiler implicitly converts delegate into function when taking an address of a method
https://issues.dlang.org/show_bug.cgi?id=12773
nick nicolas.jincher...@gmail.com changed:
What|Removed |Added
CC||nicolas.jincher...@gmail.co
||m
--- Comment #2 from nick nicolas.jincher...@gmail.com ---
I believe this behaviour is by design. There is no implicit conversion, because
C.bar is not a delegate, it is a function pointer. The following code works as
expected:
alias Func = void function();
alias Del = void delegate();
class C
{
string str = bar;
static void foo() { }
void bar() { writeln(str); }
}
void main()
{
{
// Func func = C.foo; // disallowed, since this is a function call
}
{
Func func = C.foo; // ok, the proper syntax usage.
func(); // ok
}
{
Func func = C.bar; // correct
C c = new C;
Del del = c.bar;// correct
Del del2;
del2.funcptr = func;
del2.ptr = cast(void*)c;
del2(); // works, output is bar
}
}
--
[Issue 12735] imports via mixin template become public imports
https://issues.dlang.org/show_bug.cgi?id=12735 nick nicolas.jincher...@gmail.com changed: What|Removed |Added Severity|normal |major --
[Issue 13801] New: Garbage collector fails to work after lots of small allocations
https://issues.dlang.org/show_bug.cgi?id=13801
Issue ID: 13801
Summary: Garbage collector fails to work after lots of small
allocations
Product: D
Version: D2
Hardware: x86_64
OS: Mac OS X
Status: NEW
Severity: critical
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: dl...@chillichef.com
The program below uses around 3.5GB of RAM on my machine.
- Commenting out the arr allocation reduces it to 860KB.
- Commenting out the list appending reduces it to 8.8MB.
This is seriously affecting me as my program is now allocating over 10GB before
OOM'ing.
Things to note:
- Reduce the size multiplier to only 1000 and the amount of memory being used
drops to hardly anything.
- Increase the multiplier to 3000 and the amount of memory being used
drastically increases.
---
import core.memory : GC;
import std.range : iota;
const ulong size = chunkSize * 2000;
const ulong chunkSize = 4 * 1024 * 1024;
immutable struct S {
string a;
ulong b;
}
void main() {
S[] list;
foreach(i; iota(0, size, chunkSize)) {
list ~= S(, i);
}
while(true) {
ubyte[] arr = new ubyte[chunkSize];
//GC.collect();
//GC.minimize();
}
}
--
[Issue 13801] Garbage collector fails to work after lots of small allocations
https://issues.dlang.org/show_bug.cgi?id=13801 --- Comment #1 from Ben Grabham dl...@chillichef.com --- Also, adding GC.collect() and GC.minimize() explicitly did nothing as well. --
[Issue 13801] Garbage collector fails to work after lots of small allocations
https://issues.dlang.org/show_bug.cgi?id=13801 --- Comment #2 from Ben Grabham dl...@chillichef.com --- If you take out iota as well, it works again. If you add a sleep into the while, the memory increases more gradually. --
[Issue 13766] std.range and std.regex documentation is now broken
https://issues.dlang.org/show_bug.cgi?id=13766 --- Comment #7 from hst...@quickfur.ath.cx --- Follow-up PR: https://github.com/D-Programming-Language/dlang.org/pull/713 https://github.com/D-Programming-Language/phobos/issues/2774 --
[Issue 13799] Whole-array initialization for static fixed-size arrays of arrays too
https://issues.dlang.org/show_bug.cgi?id=13799 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Hardware|x86 |All OS|Windows |All --- Comment #1 from Kenji Hara k.hara...@gmail.com --- I think the multi-dimensional block initializing for static array type should consistently work in arbitrary scope. To increase behavior consistency of variable initializing, my following PR will fix it. https://github.com/D-Programming-Language/dmd/pull/3680 --
[Issue 13595] Extend std.algorithm.groupBy to support non-equivalence relations
https://issues.dlang.org/show_bug.cgi?id=13595 --- Comment #6 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/5986e740873d6af793610381a942df78ab41f137 Merge pull request #2654 from quickfur/issue13595b Issue 13595: Extend groupBy to handle non-equivalence relations. --
[Issue 13595] Extend std.algorithm.groupBy to support non-equivalence relations
https://issues.dlang.org/show_bug.cgi?id=13595 hst...@quickfur.ath.cx changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
