[Issue 7932] Corrupted argument inside out contract for protected methods when compiling with -O in x86_64
http://d.puremagic.com/issues/show_bug.cgi?id=7932 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don 2012-04-17 22:37:23 PDT --- Adding assert(this); at the start of the body of f() makes the bug disappear. I think this is why 'protected' is required; if it is public, the assert(this) is automatically added. Comparing the generated code for the three cases (a) -O, fails (b) without -O, passes (c) -O + assert(this), passes I can't see any obvious explanation. case (a) has the f() body of case (b), and the main() body of case (c). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7931] Error message with _error_ with var[1,2]
http://d.puremagic.com/issues/show_bug.cgi?id=7931 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7931] Error message with _error_ with var[1,2]
http://d.puremagic.com/issues/show_bug.cgi?id=7931 --- Comment #1 from github-bugzi...@puremagic.com 2012-04-17 20:37:55 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/b1f8d74893fa1d34095e82b5e040a100f6bce64d fix Issue 7931 - Error message with _error_ with var[1,2] -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7931] Error message with _error_ with var[1,2]
http://d.puremagic.com/issues/show_bug.cgi?id=7931 --- Comment #2 from github-bugzi...@puremagic.com 2012-04-17 20:38:14 PDT --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/3b92cba684e1c9d03a54781bf60582e7d7e34b22 fix Issue 7931 - Error message with _error_ with var[1,2] -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7933] Illegal interaction of templates
http://d.puremagic.com/issues/show_bug.cgi?id=7933 Kenji Hara changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #1 from Kenji Hara 2012-04-17 19:41:27 PDT --- https://github.com/D-Programming-Language/dmd/pull/887 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7935] New: Struct-by-pointer field access in TypeTuple
http://d.puremagic.com/issues/show_bug.cgi?id=7935
Summary: Struct-by-pointer field access in TypeTuple
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: diagnostic
Severity: minor
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-04-17 14:43:43 PDT ---
This is wrong D2 code:
import std.typecons: TypeTuple;
struct Node {
Node* left, right;
}
void main() {
Node* n = new Node();
auto le = n.left;
auto t = TypeTuple!(n.left);
}
DMD 2.059 gives this error message, but I think it's better to give a different
error message:
test.d(8): Error: no property 'left' for type 'Node*'
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7934] New: std.algorithm.sum and std.algorithm.reduce for fixed size arrays too
http://d.puremagic.com/issues/show_bug.cgi?id=7934 Summary: std.algorithm.sum and std.algorithm.reduce for fixed size arrays too Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2012-04-17 14:13:46 PDT --- This is a second part of Issue 4725 The D type system supports both dynamic arrays and fixed-sized arrays. Despite Phobos regards fixed-sized arrays as second-class citizens of the language, they are quite important and useful in high-performance code, because they reduce the pressure on the garbage collector and allow for some extra optimizations. An example: their length is known at compile time, so if such length is small, the compiler finds it simple to unroll loops. In scientific code loop unrolling is very important. Sometimes the JavaHotSpot is able to beat C++ in Scientific code on loops with bounds that aren't known at compile-time because the Just-in-time compiler is able to see that an array length known only at run-time is indeed constant for this run, so it's able to partially unroll the loop. I have verified this beats all C++ compilers in some number-crunching code. A JIT is not needed with fixed-sized D arrays. Throwing away the length known at compile-time to turn them into dynamic arrays to make them ranges, is a waste of optimization opportunities. If I see code: int[5] a = foo(); auto s = sum(a); I'd like that sum() to be replaced by an inlined unrolled loop, if the input array length is known at compile-time, and it's small. (I think it's not hard to do. The test on the length is easy to do with a template constraint plus a compile-time function that essentially generates a "a[0] + a[1] + a[2] + a[3] + a[4]" mixin). I'd like a specialization of std.algorithm.reduce too for small fixed-sized arrays. Both sum and reduce call their normal dynamic array versions (slicing the input with []) if the fixed size inout array is long enough (like more than 8 or 16 items), because a full loop unroll is not good in this case (still, even in this case the back-end of the compiler will enjoy to know the array size at compile-time). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4725] std.algorithm.sum()
http://d.puremagic.com/issues/show_bug.cgi?id=4725 --- Comment #16 from bearophile_h...@eml.cc 2012-04-17 14:14:24 PDT --- See also Issue 7934 for an extra improvement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6253] Refuse definition too of impossible associative arrays
http://d.puremagic.com/issues/show_bug.cgi?id=6253 --- Comment #8 from bearophile_h...@eml.cc 2012-04-17 13:35:45 PDT --- One more comment: http://forum.dlang.org/thread/mailman.1834.1334688099.4860.digitalmar...@puremagic.com#post-wnepqlefxamfbhddpaqs:40forum.dlang.org This bug report is based on this idea: http://en.wikipedia.org/wiki/Principle_of_least_astonishment If I define: Foo[] a; I expect those Foo items to be mutable. If I see: int[Foo] I expect those Foo keys to be mutable. If I see: immutable(Foo)[] a; I expect those Foos to be immutable. If I see: int[immutable Foo] I expect those Foo keys to be immutable. If I see a int[Foo] and I get immutable Foo keys, I am astonished. Not doing what I am saying here will add another special case to D language. Avoiding many special cases is a reasons to choose D over C++. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7917] -inline option fails for complex expressions
http://d.puremagic.com/issues/show_bug.cgi?id=7917
--- Comment #6 from bearophile_h...@eml.cc 2012-04-17 11:37:14 PDT ---
I am hitting the same "Internal error: toir.c 178" even without -inline with
this reduced code:
import std.algorithm: sort;
struct Foo(int m) {
int x;
}
void bar(int m)(Foo!m[] foos) {
void spam() {
//sort!((Foo!m a, Foo!m b) => true)(foos); // no error
sort!((a, b) => true)(foos);
}
}
void main() {
alias Foo!2 F2;
bar([F2(1)]);
alias Foo!3 F3;
bar([F3(2)]);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7917] -inline option fails for complex expressions
http://d.puremagic.com/issues/show_bug.cgi?id=7917
--- Comment #5 from bearophile_h...@eml.cc 2012-04-17 11:15:02 PDT ---
(In reply to comment #4)
> As far as I can see in the time available any further reduction loses the
> error
> message.
A first reduction:
import std.algorithm: map;
import std.typecons: tuple, Tuple;
int foo(Tuple!(int)) {
return 1;
}
void main() {
int x = 2;
map!foo(map!(_ => tuple(x))([3]));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7933] New: Illegal interaction of templates
http://d.puremagic.com/issues/show_bug.cgi?id=7933
Summary: Illegal interaction of templates
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: maxim...@gmail.com
--- Comment #0 from Maksim Zholudev 2012-04-17 10:01:53
PDT ---
Compiler version: DMD64 D Compiler v2.058 on 64-bit Linux
The following code causes compiler errors:
--
struct Boo(size_t dim){int a;}
struct Baa(size_t dim){Boo!dim a;}
//struct Baa(size_t dim){Boo!1 a;} //(1) This version causes no errors
auto foo()(Boo!1 b){return b;}
//auto fuu(Boo!1 b){return b;} //(2) This line neutralizes the error
void main()
{
Baa!1 a; //(3) This line causes the error message
Baa!2 a1;
auto b = foo(Boo!1(1));
}
--
Error messages:
--
test.d(12): Error: template test.foo() does not match any function template
declaration
test.d(12): Error: template test.foo() cannot deduce template function from
argument types !()(Boo!(1LU))
--
These errors occure only if there is line markes as (3).
If the definition of `Baa` is changed with the one marked as (1) there is no
errors.
If there is line marked as (2) there is no errors (even though the function
`fuu` is not used anywhere).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7704] RangeError when using key optainey by AA byKey() iteration
http://d.puremagic.com/issues/show_bug.cgi?id=7704 --- Comment #2 from hst...@quickfur.ath.cx 2012-04-17 08:18:16 PDT --- Now that 2.059 is out, could you re-test this bug to see if it has been fixed? I believe what you're seeing is the same as bug 7512, which has been fixed. Thanks! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6758] std.c.stdarg problems with 8 or more integer arguments on x86_64
http://d.puremagic.com/issues/show_bug.cgi?id=6758 --- Comment #10 from Don 2012-04-17 06:33:40 PDT --- The problem is worse than I thought. cod1.c, line 2450, cdfunc() puts an array parameter into registers, instead of the stack, if there are enough free registers. Nothing that fits into a register ever has additional stack alignment. So effectively, it is aligned as size_t. ie, parameter[i].numalign = 0. But, once the registers are full, it becomes treated as a ucent, and gets extra stack alignment. parameter[i].numalign = 8; Then, in line 2528, if it was on the stack, the code to align the stack (SUB RSP, numalign) is generated. But, in 2564, this doesn't get happen for register parameters. Instead, the registers are just saved without any padding. So it is NOT sufficient to adjust stdc.stdarg, to treat delegates and d arrays as if their alignof was ucent.alignof. Rather, they should be treated as sizeof.alignof, unless there are no registers left, in which case it should be ucent.alignof. Perhaps it would be enough to set cod1.c line 2452: // Parameter i goes on the stack parameters[i].reg = -1; // -1 means no register -unsigned alignsize = el_alignsize(ep); +unsigned alignsize = ty64reg(ty) ? 0 : el_alignsize(ep); parameters[i].numalign = 0; if (alignsize > stackalign) so that if it fits into a register, it is never aligned. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7932] New: protected method
http://d.puremagic.com/issues/show_bug.cgi?id=7932
Summary: protected method
Product: D
Version: D1 & D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: leandro.lucare...@sociomantic.com
--- Comment #0 from Leandro Lucarella
2012-04-17 06:31:25 PDT ---
This is a weird one:
---
extern (C) int printf(char* fmt, ...);
size_t N;
class C
{
protected void f(size_t n)
out
{
printf("out: this=%p &n=%p n=%zu\n",
cast(void*) this, &n, n);
assert (N == n);
}
body
{
int dummy;
//printf("\n");
N = n;
printf("body: this=%p &dummy=%p &N=%p N=%zu\n",
cast(void*) this, &dummy, &N, N);
}
}
void main()
{
auto x = new C;
x.f(1);
}
---
Compiling with dmd -m64 -O, the assertion fails, and the output is:
body: this=0x7f457090dcf0 &dummy=0x7fffc16ece98 &N=0x6fe2d0 N=1
out: this=0x7f457090dcf0 &n=0x7fffc16ecea8 n=4401614
All other flags seems to be irrelevant except for -release, of course, as the
out contract is not generated.
Uncommenting the commented out printf() fixes the problem. Removing the
protected attribute, or changing it to either public, private or package fixes
the problem too.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7442] ctRegex!`\p{Letter}` uses a lot memory in compilation
http://d.puremagic.com/issues/show_bug.cgi?id=7442 --- Comment #8 from Dmitry Olshansky 2012-04-17 04:35:31 PDT --- Created an attachment (id=1096) Benchmark unicode Trie Benchmark runs core part of parse step with huge character classes. Currently it chokes on 2 iterations. Unless it can swallow at least 5 CTFE _parsing_ is almost unusable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7442] ctRegex!`\p{Letter}` uses a lot memory in compilation
http://d.puremagic.com/issues/show_bug.cgi?id=7442
--- Comment #7 from Dmitry Olshansky 2012-04-17
04:26:21 PDT ---
I investigated this further and conclude that there are 2 factors at work.
I removed few thousands of codepoints from Letter, so it doesn't run out of RAM
outright.(see code below)
Also separated parse from build steps.
Here are collected stats on CTFE.
parse only:
CTFE Performance
max call depth = 20 max stack = 44
array allocs = 2761 assignments = 430837
build:
CTFE Performance
max call depth = 20 max stack = 73
array allocs = 8264 assignments = 1293421
Parsing creates all the datastructures for unicode table machinery
it takes slightly less then half of all allocs already.
Another thing to notice is it fetures higher allocations per assigment.
Then comes the codegen step and it's CTFE only and far more alloc happy.
Frankly I see no way to reduce all of this alloc fun because of COW
that will ruin any attempt to preallocate buffer for generated code.
Am I right that arrays do dup on every write?
--- test program ---
import std.regex;
void main(){
version(parse)
static r = regex(set);
else //build
static r = ctRegex!set;
}
enum set =
`[A-Za-z\u00AA\u00B5\u00BA\u00C0-\u00D6\u00D8-\u00F6\u00F8-\u02C1\u02C6-\u02D1\u02E0-\u02E4\u02EC\u02EE\u0370-\u0374\u0376\u0377
\u037A-\u037D\u0386\u0388-\u038A\u038C\u038E-\u03A1\u03A3-\u03F5\u03F7-\u0481\u048A-\u0527\u0531-\u0556\u0559\u0561-\u0587\u05D0-\u05EA
\u05F0-\u05F2\u0620-\u064A\u066E\u066F\u0671-\u06D3\u06D5\u06E5\u06E6\u06EE\u06EF\u06FA-\u06FC\u06FF\u0710\u0712-\u072F\u074D-\u07A5
\u07B1\u07CA-\u07EA\u07F4\u07F5\u07FA\u0800-\u0815\u081A\u0824\u0828\u0840-\u0858\u08A0\u08A2-\u08AC\u0904-\u0939\u093D\u0950\u0958-\u0961
\u0971-\u0977\u0979-\u097F\u0985-\u098C\u098F\u0990\u0993-\u09A8\u09AA-\u09B0\u09B2\u09B6-\u09B9\u09BD\u09CE\u09DC\u09DD\u09DF-\u09E1
\u09F0\u09F1\u0A05-\u0A0A\u0A0F\u0A10\u0A13-\u0A28\u0A2A-\u0A30\u0A32\u0A33\u0A35\u0A36\u0A38\u0A39\u0A59-\u0A5C\u0A5E\u0A72-\u0A74
\u0A85-\u0A8D\u0A8F-\u0A91\u0A93-\u0AA8\u0AAA-\u0AB0\u0AB2\u0AB3\u0AB5-\u0AB9\u0ABD\u0AD0\u0AE0\u0AE1\u0B05-\u0B0C\u0B0F\u0B10
\u0B13-\u0B28\u0B2A-\u0B30\u0B32\u0B33\u0B35-\u0B39\u0B3D\u0B5C\u0B5D\u0B5F-\u0B61\u0B71\u0B83\u0B85-\u0B8A\u0B8E-\u0B90
\u0B92-\u0B95\u0B99\u0B9A\u0B9C\u0B9E\u0B9F\u0BA3\u0BA4\u0BA8-\u0BAA\u0BAE-\u0BB9\u0BD0\u0C05-\u0C0C\u0C0E-\u0C10\u0C12-\u0C28
\u0C2A-\u0C33\u0C35-\u0C39\u0C3D\u0C58\u0C59\u0C60\u0C61\u0C85-\u0C8C\u0C8E-\u0C90\u0C92-\u0CA8\u0CAA-\u0CB3\u0CB5-\u0CB9
\u0CBD\u0CDE\u0CE0\u0CE1\u0CF1\u0CF2\u0D05-\u0D0C\u0D0E-\u0D10\u0D12-\u0D3A\u0D3D\u0D4E\u0D60\u0D61\u0D7A-\u0D7F\u0D85-\u0D96
\u0D9A-\u0DB1\u0DB3-\u0DBB\u0DBD\u0DC0-\u0DC6\u0E01-\u0E30\u0E32\u0E33\u0E40-\u0E46\u0E81\u0E82\u0E84\u0E87\u0E88\u0E8A\u0E8D
\u0E94-\u0E97\u0E99-\u0E9F\u0EA1-\u0EA3\u0EA5\u0EA7\u0EAA\u0EAB\u0EAD-\u0EB0\u0EB2\u0EB3\u0EBD\u0EC0-\u0EC4\u0EC6\u0EDC-\u0EDF
\u0F00\u0F40-\u0F47\u0F49-\u0F6C\u0F88-\u0F8C\u1000-\u102A\u103F\u1050-\u1055\u105A-\u105D\u1061\u1065\u1066\u106E-\u1070\u1075-\u1081
\u108E\u10A0-\u10C5\u10C7\u10CD\u10D0-\u10FA\u10FC-\u1248\u124A-\u124D\u1250-\u1256\u1258\u125A-\u125D\u1260-\u1288\u128A-\u128D
\u1290-\u12B0\u12B2-\u12B5\u12B8-\u12BE\u12C0\u12C2-\u12C5\u12C8-\u12D6\u12D8-\u1310\u1312-\u1315\u1318-\u135A\u1380-\u138F\u13A0-\u13F4
\u1401-\u166C\u166F-\u167F\u1681-\u169A\u16A0-\u16EA\u1700-\u170C\u170E-\u1711\u1720-\u1731\u1740-\u1751\u1760-\u176C\u176E-\u1770\u1780-\u17B3
\u17D7\u17DC\u1820-\u1877\u1880-\u18A8\u18AA\u18B0-\u18F5\u1900-\u191C\u1950-\u196D\u1970-\u1974\u1980-\u19AB\u19C1-\u19C7\u1A00-\u1A16\u1A20-\u1A54
\u1AA7\u1B05-\u1B33\u1B45-\u1B4B\u1B83-\u1BA0\u1BAE\u1BAF\u1BBA-\u1BE5\u1C00-\u1C23\u1C4D-\u1C4F\u1C5A-\u1C7D\u1CE9-\u1CEC\u1CEE-\u1CF1\u1CF5\u1CF6
\u1D00-\u1DBF\u1E00-\u1F15\u1F18-\u1F1D\u1F20-\u1F45\u1F48-\u1F4D\u1F50-\u1F57\u1F59\u1F5B\u1F5D\u1F5F-\u1F7D\u1F80-\u1FB4\u1FB6-\u1FBC\u1FBE\u1FC2-\u1FC4
\u1FC6-\u1FCC\u1FD0-\u1FD3\u1FD6-\u1FDB\u1FE0-\u1FEC\u1FF2-\u1FF4\u1FF6-\u1FFC\u2071\u207F\u2090-\u209C\u2102\u2107\u210A-\u2113\u2115\u2119-\u211D\u2124
\u2126\u2128\u212A-\u212D\u212F-\u2139\u213C-\u213F\u2145-\u2149\u214E\u2183\u2184\u2C00-\u2C2E\u2C30-\u2C5E\u2C60-\u2CE4\u2CEB-\u2CEE\u2CF2
\u2CF3\u2D00-\u2D25\u2D27\u2D2D\u2D30-\u2D67\u2D6F\u2D80-\u2D96\u2DA0-\u2DA6\u2DA8-\u2DAE\u2DB0-\u2DB6\u2DB8-\u2DBE\u2DC0-\u2DC6\u2DC8-\u2DCE
\u2DD0-\u2DD6\u2DD8-\u2DDE\u2E2F\u3005\u3006\u3031-\u3035\u303B\u303C\u3041-\u3096\u309D-\u309F\u30A1-\u30FA\u30FC-\u30FF\u3105-\u312D\u3131-\u318E
\u31A0-\u31BA\u31F0-\u31FF\u3400-\u4DB5\u4E00-\u9FCC\uA000-\uA48C\uA4D0-\uA4FD\uA500-\uA60C\uA610-\uA61F\uA62A\uA62B\uA640-\uA66E\uA67F-\uA697\uA6A0-\uA6E5
\uA717-\uA71F\uA722-\uA788\uA78B-\uA78E\uA790-\uA793\uA7A0-\uA7AA\uA7F8-\uA801\uA803-\uA805\uA807-\uA80A\uA80C-\uA822\uA840-\uA873\uA882-\uA8B3\uA8F2-\uA8F7
\uA8FB\uA90A-\uA925\uA930-\uA946\uA960-\uA97C\uA984-\uA9B2\uA9CF\uAA00-\uAA28\uAA40-\uAA42\uAA44-\uAA4B\uAA60-\uAA76\uAA7A\uAA80-\uAAAF\uAAB1\uAAB5
\uAAB6\uAAB9-\uAA
[Issue 7440] ctRegex does not work when using alternatives ('|') involving a '+' inside non-capturing group ('(?:…)')
http://d.puremagic.com/issues/show_bug.cgi?id=7440 Dmitry Olshansky changed: What|Removed |Added CC||dmitry.o...@gmail.com Component|Phobos |DMD --- Comment #2 from Dmitry Olshansky 2012-04-17 02:11:15 PDT --- Not a Phobos bug. It's in CTFE side of things. Nowadays it triggers assert. Judging by the assert firing off it's a likely duplicate of Issue 7810. Issue 7810 also features smaller test case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7440] ctRegex does not work when using alternatives ('|') involving a '+' inside non-capturing group ('(?:…)')
http://d.puremagic.com/issues/show_bug.cgi?id=7440 --- Comment #1 from Dmitry Olshansky 2012-04-17 02:08:05 PDT --- Created an attachment (id=1095) Stripped down regex parser #2 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7921] Two order of magnitude file size increase (up to 111 MiB for GtkD) mostly from zeroes
http://d.puremagic.com/issues/show_bug.cgi?id=7921 --- Comment #7 from Denis 2012-04-17 13:07:46 MSD --- The example with built binaries for dmd 2.057 and dmd 2.058 (~10 MiB, uncompressed ~250 MiB): http://deoma-cmd.ru/files/other/huge-build-gtkD-full.7z One can use Vladimir Panteleev's treemap visualization tool with *.map files from the archive (as for me, it hangs Chrome). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7919] Sample code works on GDC but fails with DMD
http://d.puremagic.com/issues/show_bug.cgi?id=7919 Kenji Hara changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #4 from Kenji Hara 2012-04-17 02:03:03 PDT --- https://github.com/D-Programming-Language/phobos/pull/540 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7854] Non-C attributes allowed on extern(C) function parameters
http://d.puremagic.com/issues/show_bug.cgi?id=7854 --- Comment #10 from Don 2012-04-17 02:03:47 PDT --- (In reply to comment #9) > (In reply to comment #6) > > > I'm not exactly talking about binding or calling convention, I'm more > > > talking > > > about types. To me, the two are orthogonal. > > > > Whereas I would argue that since you're declaring a C function, it should > > be a > > _C_ function and therefore not include features which C doesn't have. The > > only > > reason that I think that permitting pure and nothrow on C functions makes > > any > > sense is out of pure necessity. > > No. An extern(C) function does not mean it's a C function. It just means it > has C linkage. See here: http://dlang.org/attribute.html#linkage > > extern(C) has nothing to do with parameters, only calling conventions. I don't understand that statement. Do you mean 'parameters, only name mangling" ? If so, that that isn't true. On 32-bit x86 Windows, extern(D) void foo(int x) passes x in the EAX register. extern(C) void foo(int x) passes x on the stack. It's not just a name mangling issue. The confusion comes because there are some druntime functions which use C name mangling but the extern(D) calling convention! This is not true of all extern(C) functions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7810] ctRegex!`a|b` asserts at regex.d:1150
http://d.puremagic.com/issues/show_bug.cgi?id=7810 Dmitry Olshansky changed: What|Removed |Added CC||dmitry.o...@gmail.com Component|Phobos |DMD --- Comment #2 from Dmitry Olshansky 2012-04-17 01:57:52 PDT --- It's a bug in CTFE not in Phobos. R-T version runs the same code and doesn't hit the assert. See reduced test case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7810] ctRegex!`a|b` asserts at regex.d:1150
http://d.puremagic.com/issues/show_bug.cgi?id=7810 --- Comment #1 from Dmitry Olshansky 2012-04-17 01:55:53 PDT --- Created an attachment (id=1094) Stripped down regex parser -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7921] Two order of magnitude file size increase (up to 111 MiB for GtkD) mostly from zeroes
http://d.puremagic.com/issues/show_bug.cgi?id=7921 Denis changed: What|Removed |Added Attachment #1091|0 |1 is obsolete|| --- Comment #6 from Denis 2012-04-17 12:54:37 MSD --- Created an attachment (id=1093) Example with GtkD -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7931] New: Error message with _error_ with var[1,2]
http://d.puremagic.com/issues/show_bug.cgi?id=7931 Summary: Error message with _error_ with var[1,2] Product: D Version: D1 & D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: clugd...@yahoo.com.au --- Comment #0 from Don 2012-04-17 01:41:31 PDT --- static assert( undefined[2, 4] == 2); bug.d(9): Error: undefined identifier undefined bug.d(9): Error: only one index allowed to index _error_ index ed4c6c6..de8498e 100644 --- a/src/expression.c +++ b/src/expression.c @@ -9382,6 +9382,8 @@ Expression *ArrayExp::semantic(Scope *sc) #endif UnaExp::semantic(sc); e1 = resolveProperties(sc, e1); +if (e1->op == TOKerror) +return new ErrorExp(); t1 = e1->type->toBasetype(); if (t1->ty != Tclass && t1->ty != Tstruct) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7874] [CTFE] internal error: unsupported assignment (x OP= y) = z
http://d.puremagic.com/issues/show_bug.cgi?id=7874
Don changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
Summary|[CTFE] CTFE internal error: |[CTFE] internal error:
|unsupported assignment |unsupported assignment (x
||OP= y) = z
--- Comment #1 from Don 2012-04-17 01:43:48 PDT ---
Applies to many forms of op= assignment, including some cases of ref
assignment.
Eg.
int foo(int[] x){ auto b = (x~=x)=[1,2,3]; return 3; }
enum bar = foo([7,5]);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7418] Overloading doesn't work with aliases declared inside templates
http://d.puremagic.com/issues/show_bug.cgi?id=7418 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara 2012-04-17 01:27:45 PDT --- https://github.com/D-Programming-Language/dmd/pull/886 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7928] Regex regression - out of memory.
http://d.puremagic.com/issues/show_bug.cgi?id=7928
--- Comment #4 from Vincent 2012-04-17 00:49:18 PDT ---
(In reply to comment #3)
> Aha, I think I know what it is! Give me the prize ;)
> Don't you have globals defined like this?
Yep, OF COURSE I made 'em global! Take your prize:
(*)(*)
(tits) :)))
Damn... what a hell that CTFE meddle into my code when I didn't ask for it??
> The workaround is to init them in the module constructor static this(){ ... )
Thanks, Dmitry! Will use it.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7824] isInputRange fails to recognize inout(T)[]
http://d.puremagic.com/issues/show_bug.cgi?id=7824 Kenji Hara changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #1 from Kenji Hara 2012-04-17 00:44:01 PDT --- https://github.com/D-Programming-Language/phobos/pull/539 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7928] Regex regression - out of memory.
http://d.puremagic.com/issues/show_bug.cgi?id=7928
--- Comment #3 from Dmitry Olshansky 2012-04-17
00:20:35 PDT ---
Aha, I think I know what it is! Give me the prize ;)
Don't you have globals defined like this?
auto httpReqRegex = regex(`^(\w+)\s+((\w+)://([^/]+)(\S+))\s*(.*)`);
then it tries to init it at compile time. That makes it _parse_ them all at
CTFE.
Nice feature if it wasn't for bugs. The workaround is to init them in the
module constructor static this(){ ... )
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7921] Two order of magnitude file size increase (up to 111 MiB for GtkD) mostly from zeroes
http://d.puremagic.com/issues/show_bug.cgi?id=7921 Vladimir Panteleev changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #5 from Vladimir Panteleev 2012-04-17 00:18:30 PDT --- Have you looked at the map file? If not, try my map treemap visualization tool: http://thecybershadow.net/d/mapview/ -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7928] Regex regression - out of memory.
http://d.puremagic.com/issues/show_bug.cgi?id=7928 --- Comment #2 from Vincent 2012-04-17 00:16:55 PDT --- > It might be the case that you use ctRegex... Function 'regex' returns Regex object, not ctRegex. BUT my feeling is that long compiling of my small program caused by 'compile time Regex'! Probably some trick in library makes all Regex as 'compile time'? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7921] Two order of magnitude file size increase (up to 111 MiB for GtkD) mostly from zeroes
http://d.puremagic.com/issues/show_bug.cgi?id=7921 --- Comment #4 from Denis 2012-04-17 11:09:30 MSD --- (In reply to comment #3) > Make sure first that it is not this issue: > > http://dlang.org/faq.html#bss AFAIK there was no changes with BSS in dmd 2.058. And GtkD doesn't use __gshared arrays at all. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
