[Issue 7016] local import does not create -deps dependency
http://d.puremagic.com/issues/show_bug.cgi?id=7016 --- Comment #8 from thelastmamm...@gmail.com 2013-07-11 23:26:15 PDT --- see http://forum.dlang.org/post/mailman.1984.1373610213.13711.digitalmar...@puremagic.com [fix for enumerating local import dependencies, resolving all rdmd link errors] -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10620] New: ICE when using TypeInfo.getHash at compile time
http://d.puremagic.com/issues/show_bug.cgi?id=10620 Summary: ICE when using TypeInfo.getHash at compile time Product: D Version: future Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: d...@me.com --- Comment #0 from Jacob Carlborg d...@me.com 2013-07-11 23:48:56 PDT --- The following code: enum typeId = typeid(int); enum hash = typeId.getHash(cast(void*) 3); Results in the following error: Assertion failed: (thisval thisval-op == TOKclassreference), function interpret, file interpret.c, line 4067. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4841] -inline wrecks certain nested structs causing error *** is a nested function and cannot be accessed from ***
http://d.puremagic.com/issues/show_bug.cgi?id=4841 --- Comment #19 from github-bugzi...@puremagic.com 2013-07-11 23:49:29 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/1fbbe5966e372abb20e70c4ac69ecfaeaa6db952 fix Issue 4841 - -inline wrecks certain nested structs causing error *** is a nested function and cannot be accessed from *** https://github.com/D-Programming-Language/dmd/commit/c19b8a43f45da1347302d3b49a3d1b0b53997003 Merge pull request #2329 from 9rnsr/fix4841 Issue 4841 - -inline wrecks certain nested structs causing error *** is a nested function and cannot be accessed from *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4841] -inline wrecks certain nested structs causing error *** is a nested function and cannot be accessed from ***
http://d.puremagic.com/issues/show_bug.cgi?id=4841 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6829] Unsigned rotate standard function in Phobos
http://d.puremagic.com/issues/show_bug.cgi?id=6829 --- Comment #21 from Iain Buclaw ibuc...@ubuntu.com 2013-07-12 00:58:49 PDT --- 1. Not my problem. :) 2. When comparing gdc and dmd, make sure your actually looking at object files generated by gdc, and not dmd. :) 3. That's highly unlikely as I've tested on x86_64. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6829] Unsigned rotate standard function in Phobos
http://d.puremagic.com/issues/show_bug.cgi?id=6829 --- Comment #23 from Iain Buclaw ibuc...@ubuntu.com 2013-07-12 01:02:52 PDT --- (In reply to comment #22) (In reply to comment #21) 1. Not my problem. :) 2. When comparing gdc and dmd, make sure your actually looking at object files generated by gdc, and not dmd. :) 3. That's highly unlikely as I've tested on x86_64. :) and 4. Under simple test conditions where all parameter values are const/known, templated function calls tend to have a habit of being inlined / optimised away. and 5. Make sure that you use bearophiles last implementation example. ;) http://d.puremagic.com/issues/show_bug.cgi?id=6829#c12 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6829] Unsigned rotate standard function in Phobos
http://d.puremagic.com/issues/show_bug.cgi?id=6829 --- Comment #22 from Iain Buclaw ibuc...@ubuntu.com 2013-07-12 01:00:57 PDT --- (In reply to comment #21) 1. Not my problem. :) 2. When comparing gdc and dmd, make sure your actually looking at object files generated by gdc, and not dmd. :) 3. That's highly unlikely as I've tested on x86_64. :) and 4. Under simple test conditions where all parameter values are const/known, templated function calls tend to have a habit of being inlined / optimised away. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6829] Unsigned rotate standard function in Phobos
http://d.puremagic.com/issues/show_bug.cgi?id=6829
--- Comment #24 from bearophile_h...@eml.cc 2013-07-12 01:59:52 PDT ---
(In reply to comment #23)
and 5. Make sure that you use bearophiles last implementation example. ;)
Updated code, lacks unittests:
import std.traits: isIntegral, isUnsigned;
/// Left-shift x by n bits.
T rol(T)(in T x, in uint nBits) @safe pure nothrow
if (isIntegral!T isUnsigned!T)
in {
assert(nBits (T.sizeof * 8));
} body {
return cast(T)((x nBits) | (x ((T.sizeof * 8) - nBits)));
}
/// Right-shift x by n bits.
T ror(T)(in T x, in uint nBits) @safe pure nothrow
if (isIntegral!T isUnsigned!T)
in {
assert(nBits (T.sizeof * 8));
} body {
return cast(T)((x nBits) | (x ((T.sizeof * 8) - nBits)));
}
void main() {
// Tests to check for assembly output.
{
__gshared static ubyte xb;
__gshared static ushort xs;
__gshared static uint xi;
__gshared static ulong xl;
__gshared static uint yi;
rol(xb, yi); // rolb
ror(xb, yi); // rorb
rol(xs, yi); // rolw
ror(xs, yi); // rorw
rol(xi, yi); // roll
ror(xi, yi); // rorl
rol(xl, yi); // version(X86_64) rolq
ror(xl, yi); // version(X86_64) rorq
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10621] New: dirEntry is (now) useless
http://d.puremagic.com/issues/show_bug.cgi?id=10621 Summary: dirEntry is (now) useless Product: D Version: D2 Platform: All URL: http://d.puremagic.com/issues/show_bug.cgi?id=10607 OS/Version: All Status: ASSIGNED Severity: enhancement Priority: P2 Component: Phobos AssignedTo: monarchdo...@gmail.com ReportedBy: monarchdo...@gmail.com --- Comment #0 from monarchdo...@gmail.com 2013-07-12 06:13:45 PDT --- By fixing Issue 10607 - DirEntry has no constructor http://d.puremagic.com/issues/show_bug.cgi?id=10607 The function dirEntry is now completely useless. It can be replaced by a straight up DirEntry call in all cases. It should be removed (deprecated). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10621] dirEntry is (now) useless
http://d.puremagic.com/issues/show_bug.cgi?id=10621 --- Comment #1 from monarchdo...@gmail.com 2013-07-12 06:15:51 PDT --- https://github.com/D-Programming-Language/phobos/pull/1407/files -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10622] New: Wrong this pointer in methods called via IUnknown derived interfaces
http://d.puremagic.com/issues/show_bug.cgi?id=10622
Summary: Wrong this pointer in methods called via IUnknown
derived interfaces
Product: D
Version: D2
Platform: x86_64
OS/Version: Windows
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: slud...@outerproduct.org
--- Comment #0 from S�nke Ludwig slud...@outerproduct.org 2013-07-12 07:52:57
PDT ---
The following program crashes in the second invocation of AddRef (could be any
other method defined by IUnknown or a derived interface) because the this
pointer points to the IUnknown vtable instead of the object's base, which is
assumed by the code.
---
import std.c.windows.com;
import std.c.windows.windows;
class Test : IUnknown {
int i = 1;
ULONG AddRef() { assert(i == 1); return 0; }
ULONG AddRef() { assert(i == 1); return 0; }
HRESULT AddRef(IID*, void**) { assert(i == 1); return E_FAIL; }
}
void main()
{
auto t = new Test;
t.AddRef(); // works
auto u = cast(IUnknown)t;
u.AddRef(); // crash in _d_invariant
}
---
Setting this to major severity because it makes defining any COM objects in D
impossible on Win64 (and thus many COM APIs are unusable). Tested on DMD
2.063.2
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6829] Unsigned rotate standard function in Phobos
http://d.puremagic.com/issues/show_bug.cgi?id=6829 --- Comment #25 from hst...@quickfur.ath.cx 2013-07-12 08:13:16 PDT --- Nope, it's still not working. I copied-n-pasted exactly the code posted above, and compiled with gdc -frelease -O3 test.d, and here is the disassembly output: 004042d0 _D4test10__T3rolThZ3rolFNaNbNfxhxkZh: 4042d0:40 0f b6 ff movzbl %dil,%edi 4042d4:b9 08 00 00 00 mov$0x8,%ecx 4042d9:29 f1sub%esi,%ecx 4042db:89 f8mov%edi,%eax 4042dd:d3 f8sar%cl,%eax 4042df:89 f1mov%esi,%ecx 4042e1:d3 e7shl%cl,%edi 4042e3:09 f8or %edi,%eax 4042e5:c3 retq 4042e6:66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 4042ed:00 00 00 004042f0 _D4test10__T3rorThZ3rorFNaNbNfxhxkZh: 4042f0:40 0f b6 ff movzbl %dil,%edi 4042f4:b9 08 00 00 00 mov$0x8,%ecx 4042f9:29 f1sub%esi,%ecx 4042fb:89 f8mov%edi,%eax 4042fd:d3 e0shl%cl,%eax 4042ff:89 f1mov%esi,%ecx 404301:d3 ffsar%cl,%edi 404303:09 f8or %edi,%eax 404305:c3 retq 404306:66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 40430d:00 00 00 00404310 _D4test10__T3rolTtZ3rolFNaNbNfxtxkZt: 404310:0f b7 ff movzwl %di,%edi 404313:b9 10 00 00 00 mov$0x10,%ecx 404318:29 f1sub%esi,%ecx 40431a:89 f8mov%edi,%eax 40431c:d3 f8sar%cl,%eax 40431e:89 f1mov%esi,%ecx 404320:d3 e7shl%cl,%edi 404322:09 f8or %edi,%eax 404324:c3 retq 404325:66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 40432c:00 00 00 40432f:90 nop 00404330 _D4test10__T3rorTtZ3rorFNaNbNfxtxkZt: 404330:0f b7 ff movzwl %di,%edi 404333:b9 10 00 00 00 mov$0x10,%ecx 404338:29 f1sub%esi,%ecx 40433a:89 f8mov%edi,%eax 40433c:d3 e0shl%cl,%eax 40433e:89 f1mov%esi,%ecx 404340:d3 ffsar%cl,%edi 404342:09 f8or %edi,%eax 404344:c3 retq 404345:66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 40434c:00 00 00 40434f:90 nop 00404350 _D4test10__T3rolTkZ3rolFNaNbNfxkxkZk: 404350:b9 20 00 00 00 mov$0x20,%ecx 404355:89 f8mov%edi,%eax 404357:29 f1sub%esi,%ecx 404359:d3 e8shr%cl,%eax 40435b:89 f1mov%esi,%ecx 40435d:d3 e7shl%cl,%edi 40435f:09 f8or %edi,%eax 404361:c3 retq 404362:66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 404369:00 00 00 40436c:0f 1f 40 00 nopl 0x0(%rax) 00404370 _D4test10__T3rorTkZ3rorFNaNbNfxkxkZk: 404370:b9 20 00 00 00 mov$0x20,%ecx 404375:89 f8mov%edi,%eax 404377:29 f1sub%esi,%ecx 404379:d3 e0shl%cl,%eax 40437b:89 f1mov%esi,%ecx 40437d:d3 efshr%cl,%edi 40437f:09 f8or %edi,%eax 404381:c3 retq 404382:66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 404389:00 00 00 40438c:0f 1f 40 00 nopl 0x0(%rax) 00404390 _D4test10__T3rolTmZ3rolFNaNbNfxmxkZm: 404390:b9 40 00 00 00 mov$0x40,%ecx 404395:48 89 f8 mov%rdi,%rax 404398:29 f1sub%esi,%ecx 40439a:48 d3 e8 shr%cl,%rax 40439d:89 f1mov%esi,%ecx 40439f:48 d3 e7 shl%cl,%rdi 4043a2:48 09 f8 or %rdi,%rax 4043a5:c3 retq 4043a6:66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 4043ad:00 00 00 004043b0 _D4test10__T3rorTmZ3rorFNaNbNfxmxkZm: 4043b0:b9 40 00 00 00 mov$0x40,%ecx 4043b5:48 89 f8 mov%rdi,%rax 4043b8:29 f1sub%esi,%ecx 4043ba:48 d3 e0 shl%cl,%rax
[Issue 6829] Unsigned rotate standard function in Phobos
http://d.puremagic.com/issues/show_bug.cgi?id=6829 --- Comment #26 from Iain Buclaw ibuc...@ubuntu.com 2013-07-12 08:21:21 PDT --- Don't currently have a gdc 4.8 compiler at hand to test... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6829] Unsigned rotate standard function in Phobos
http://d.puremagic.com/issues/show_bug.cgi?id=6829 --- Comment #27 from hst...@quickfur.ath.cx 2013-07-12 08:40:43 PDT --- Huh? So which gdc have you been using to test this earlier? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10622] Wrong this pointer in methods called via IUnknown derived interfaces
http://d.puremagic.com/issues/show_bug.cgi?id=10622 --- Comment #1 from S�nke Ludwig slud...@outerproduct.org 2013-07-12 08:50:03 PDT --- Actually, as far as I understand, the pointer is correct and the function body is wrong in assuming that it points to the object's base. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10623] New: destructor not called for function argument if constructing another argument throws
http://d.puremagic.com/issues/show_bug.cgi?id=10623
Summary: destructor not called for function argument if
constructing another argument throws
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: and...@erdani.com
--- Comment #0 from Andrei Alexandrescu and...@erdani.com 2013-07-12 08:52:50
PDT ---
Consider:
import std.stdio;
struct S1 {
this(int) { writeln(constructed); }
~this() { writeln(destroyed); }
}
struct S2 { this(int) { throw new Exception(a); } }
void fun(S1, S2, S1) {}
void main()
{
fun(S1(2), S2(2), S1(2));
}
Running this code will create an object of type S1 that is never destroyed.
This is somewhat related to http://d.puremagic.com/issues/show_bug.cgi?id=9704,
just there's no postblit.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10623] destructor not called for function argument if constructing another argument throws
http://d.puremagic.com/issues/show_bug.cgi?id=10623 Maxim Fomin ma...@maxim-fomin.ru changed: What|Removed |Added CC||ma...@maxim-fomin.ru --- Comment #1 from Maxim Fomin ma...@maxim-fomin.ru 2013-07-12 09:08:36 PDT --- I think this can be marked as a dup because it is a particular situation of essentially the same case described in issue 9704. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10624] New: [REG2.064a] ICE with tuple comparison
http://d.puremagic.com/issues/show_bug.cgi?id=10624
Summary: [REG2.064a] ICE with tuple comparison
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: ice
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2013-07-12 09:32:43 PDT ---
The regression was caused by:
https://github.com/D-Programming-Language/dmd/commit/d9c710351028452533241e069bdde9034fc4cde8
Following code causes ICE with -c switch.
$ dmd -c test.d
Internal error: backend\cod3.c 1953
With debug build dmd:
$ dmd -c test.d
DMD v2.064 DEBUG
el:00382D4C cnt=0 cs=0 TYbool 00382E64 00382CA4
el:00382E64 cnt=0 cs=0 * 1 TYstruct 003820D8
el:003820D8 cnt=1 cs=0 var TY* zis
el:00382CA4 cnt=0 cs=0 * 1 TYstruct 00382C6C
el:00382C6C cnt=1 cs=0 var TY* rhsPA
TYstruct Internal error: backend\cod3.c 1953
struct Msg {}
struct Tuple(Specs...)
{
Specs expand;
alias expand this;
}
void main()
{
Variant data;
data = Tuple!Msg();
}
struct Variant
{
ptrdiff_t function() fptr = handler!(void);
static ptrdiff_t handler(A : void)()
{
return 0;
}
static ptrdiff_t handler(A)()
{
A* zis;
A* rhsPA;
{
return *zis *rhsPA ? -1 : 1;
// Tupple!(Msg) Tupple!(Msg)
// Tupple!(Msg).expand Tupple!(Msg).expand
// CmpExp(TOKtuple, TOKtuple) is incorrectly compiled in front-end
}
return 0;
}
Variant opAssign(T)(T rhs)
{
fptr = handler!(T);
return this;
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10625] New: Compiler should warn or disallow using slice syntax in initialization
http://d.puremagic.com/issues/show_bug.cgi?id=10625
Summary: Compiler should warn or disallow using slice syntax in
initialization
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-07-12
09:57:21 PDT ---
-
void main()
{
int[] source = [0, 1];
int[] arr1 = new int[](2);
arr1[] = source[];
assert(arr1 !is source); // ok
int[] arr2 = source[]; // looks like a copy
assert(arr2 !is arr2); // assert fails: but in fact it's not!
}
-
The 'int[] arr2 = source[];' syntax appears as though the source contents are
copied into arr2, but in fact this is the same code as 'int[] arr2 = source;'.
Since [] has a very special meaning, the above should either:
1) Become an actual deep copy, meaning arr2 would have to allocate space first
and then copy contents. This would be a breaking and negative change due to
performance implications.
2) Not compile. It looks like a deep copy but it isn't, and this can cause
issues down the road (for example using memcpy or even OpenGL functions can
create hard to track problems due to using the source and target arrays which
point to the same memory).
I'd vote heavily towards 2.
Of course one can always use 'int[] arr2 = source.dup'.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10577] 2.063 Mixin Regression (works with 2.062)
http://d.puremagic.com/issues/show_bug.cgi?id=10577
Puneet Goel pun...@coverify.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WORKSFORME |
--- Comment #5 from Puneet Goel pun...@coverify.org 2013-07-12 10:30:43 PDT
---
Slightly different test case. But since this too is related, I am re-opening
the same bug. Let me know if I should instead be opening a separate bug for
this.
With this code, I am getting a *spurious* deprecation warning (compiles without
warning with version 2.062).
test.d(37): Deprecation: class test.derived use of test.base.foo() hidden by
derived is deprecated. Use 'alias base.foo foo;' to introduce base class
overload set.
// test.d Code starts here
enum sync;
public template get_sync(size_t I, A...) {
static if(I == A.length) enum bool get_sync = false;
else static if(is(A[I] == sync)) enum bool get_sync = true;
else enum bool get_sync = get_sync!(I+1, A);
}
template add_sync(T, size_t ITER=0) {
static if(ITER == (__traits(derivedMembers, T).length)) {
enum string add_sync = ;
} else {
enum string mem = __traits(derivedMembers, T)[ITER];
enum string add_sync =
static if(! __traits(isVirtualMethod, ~ mem ~ )) { ~
mixin(add_sync!(get_sync!(0, __traits(getAttributes,
~ mem ~ )), \ ~ mem ~ \));} ~ add_sync!(T, ITER+1);
}
}
template add_sync(bool A, string M) {
static if(A) {
enum string add_sync = auto ~ M[1..$] ~
() {synchronized(this) return ~ M ~ ;};
} else {
enum string add_sync = ;
}
}
abstract class base {
mixin(add_sync!(base));
@sync private bool _bar;
public void foo();
}
class derived: base {
public override void foo() {}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10600] regression(2.063.2) ICE: Assertion failed: (type-ty != Tstruct || ((TypeStruct *)type)-sym == this), function semantic, file struct.c, line 741.
http://d.puremagic.com/issues/show_bug.cgi?id=10600 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||ice, pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-07-12 10:51:30 PDT --- https://github.com/D-Programming-Language/dmd/pull/2338 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10624] [REG2.064a] ICE with tuple comparison
http://d.puremagic.com/issues/show_bug.cgi?id=10624 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-07-12 10:51:33 PDT --- https://github.com/D-Programming-Language/dmd/pull/2338 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9704] Destructor not called on function calls if postblit throws
http://d.puremagic.com/issues/show_bug.cgi?id=9704 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #4 from monarchdo...@gmail.com 2013-07-12 11:07:53 PDT --- (In reply to comment #3) *** Issue 10623 has been marked as a duplicate of this issue. *** For reference, this was also discussed in learn. http://forum.dlang.org/group/digitalmars.D.learn http://forum.dlang.org/thread/20130628005448.0969@unknown -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9704] Destructor not called on function calls if postblit throws
http://d.puremagic.com/issues/show_bug.cgi?id=9704 monarchdo...@gmail.com changed: What|Removed |Added CC||and...@erdani.com --- Comment #3 from monarchdo...@gmail.com 2013-07-12 11:05:06 PDT --- *** Issue 10623 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10599] CTFE: assert failure interpret.c 310
http://d.puremagic.com/issues/show_bug.cgi?id=10599 --- Comment #3 from github-bugzi...@puremagic.com 2013-07-12 11:44:35 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/8a9421b4d1e8b577a412a40bce0979a17a63a9c8 Fix bug 10599 CTFE assert with bad struct initializer This is an ErrorExp propagation/gagging bug. Errors in struct initializers don't generate error messages when used, but still need to report an error to the enclosing function. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10599] CTFE: assert failure interpret.c 310
http://d.puremagic.com/issues/show_bug.cgi?id=10599 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10589] GC.malloc(sz, GC.BlkAttr.APPENDABLE) fails after a certain size
http://d.puremagic.com/issues/show_bug.cgi?id=10589 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #1 from Rainer Schuetze r.sagita...@gmx.de 2013-07-12 13:37:39 PDT --- I think you are mixing two levels of abstractions here: ubyte* p = cast(ubyte*)GC.malloc(i, GC.BlkAttr.APPENDABLE); ubyte[] s = p[0 .. 0]; writefln(%6s: s.capacity is %6s, i, s.capacity); GC.malloc requests raw memory from the GC. capacity is a function very specific to the way arrays are implemented on top of it in rt/lifetime.d. It assumes that any allocation with bit APPENDABLE set and that is larger than a page of 4kB reserves 16 bytes at the start of the allocation to store the actually used length of the memory. So, to create an empty array manually that works with capacity, you'd have to set s to auto start = i = 2048 ? 0 : 16; ubyte[] s = p[start .. start]; and you'd better clean that full memory block first to avoid the length field containing garbage. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1982] [CTFE] Problems with compile-time null
http://d.puremagic.com/issues/show_bug.cgi?id=1982 --- Comment #2 from github-bugzi...@puremagic.com 2013-07-12 14:07:00 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/64ea3d8a7223f6c9b1d00e167a5ced4bf20e7992 Fix bug 1982 [CTFE] Problems with compile-time null Test case only. This was fixed by doing const-folding in CTFE. https://github.com/D-Programming-Language/dmd/commit/a0ba3b2aa31d93709a1ed3e21f5a2deca6c761fc Merge pull request #2339 from donc/fourCTFEtestcases Test cases for bugs 1982, 7988, 8253, and 8285. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7988] [CTFE] CTFE return values should be allowed in compile-time expressions
http://d.puremagic.com/issues/show_bug.cgi?id=7988 --- Comment #1 from github-bugzi...@puremagic.com 2013-07-12 14:07:10 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/9d8d7864c85f4e07be7a7d24ba92108f2206b9f4 Fix issue 7988 allow CTFE return values in compile-time exprs Test case only. This bug was fixed by doing constfolding in CTFE. https://github.com/D-Programming-Language/dmd/commit/a0ba3b2aa31d93709a1ed3e21f5a2deca6c761fc Merge pull request #2339 from donc/fourCTFEtestcases Test cases for bugs 1982, 7988, 8253, and 8285. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8285] Issue with slice returned from CTFE function
http://d.puremagic.com/issues/show_bug.cgi?id=8285 --- Comment #3 from github-bugzi...@puremagic.com 2013-07-12 14:07:19 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f5c5d43e35a48d6cc63a2fe05c68f8b88ef5e21d Fix issue 8285 Issue with slice returned from CTFE function Test case only; fixed by using CTFE to do constfolding. https://github.com/D-Programming-Language/dmd/commit/a0ba3b2aa31d93709a1ed3e21f5a2deca6c761fc Merge pull request #2339 from donc/fourCTFEtestcases Test cases for bugs 1982, 7988, 8253, and 8285. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8253] CTFE ICE: calling of member function of non-CTFE class variable
http://d.puremagic.com/issues/show_bug.cgi?id=8253 --- Comment #3 from github-bugzi...@puremagic.com 2013-07-12 14:07:14 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/339ff2a11b95a42b31e0d11ba17ea970c8cb391b Fix issue 8253 ICE: calling of member function of non-CTFE class variable Test case only, already fixed by doing constfolding in CTFE. https://github.com/D-Programming-Language/dmd/commit/a0ba3b2aa31d93709a1ed3e21f5a2deca6c761fc Merge pull request #2339 from donc/fourCTFEtestcases Test cases for bugs 1982, 7988, 8253, and 8285. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9704] Destructor not called on function calls if postblit throws
http://d.puremagic.com/issues/show_bug.cgi?id=9704
--- Comment #5 from Andrei Alexandrescu and...@erdani.com 2013-07-12 14:17:12
PDT ---
Pasting the additional example here for reference:
import std.stdio;
struct S1 {
this(int) { writeln(constructed); }
~this() { writeln(destroyed); }
}
struct S2 { this(int) { throw new Exception(a); } }
void fun(S1, S2, S1) {}
void main()
{
fun(S1(2), S2(2), S1(2));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10589] GC.malloc(sz, GC.BlkAttr.APPENDABLE) fails after a certain size
http://d.puremagic.com/issues/show_bug.cgi?id=10589 --- Comment #2 from monarchdo...@gmail.com 2013-07-12 14:29:45 PDT --- (In reply to comment #1) I think you are mixing two levels of abstractions here: ubyte* p = cast(ubyte*)GC.malloc(i, GC.BlkAttr.APPENDABLE); ubyte[] s = p[0 .. 0]; writefln(%6s: s.capacity is %6s, i, s.capacity); GC.malloc requests raw memory from the GC. capacity is a function very specific to the way arrays are implemented on top of it in rt/lifetime.d. It assumes that any allocation with bit APPENDABLE set and that is larger than a page of 4kB reserves 16 bytes at the start of the allocation to store the actually used length of the memory. So, to create an empty array manually that works with capacity, you'd have to set s to auto start = i = 2048 ? 0 : 16; ubyte[] s = p[start .. start]; Hum. That worked. Is the memory layout for the APPENDABLE data documented somewhere, or are these just reverse-engineered magic numbers? and you'd better clean that full memory block first to avoid the length field containing garbage. Nope (I think). Length is carried in the slice, not the block. Block only contains capacity/used info. Thank you for your answer. I suppose the behavior isn't going to change. Still, this requires more support. I think APPENDABLE should be better documented. In particular, the magic numbers should be user accessible via manifest constants, or functions, so as to not have to guess/reverse engineer them. This is what I've discovered: 0 - 256 bytes: 1 Byte APPENDABLE info at end; Capacity = memory size - 1; 257 - 2048 bytes: 2 Byte APPENDABLE info at end; Capacity = memory size - 2; 2049 - bytes: 16 Byte APPENDABLE info at beginning; 1 Byte unknown info at end; Capacity = memory size - 17; Are these numbers platform depending? What the heck is that 1 byte that leads to 17 byte difference I'm seeing. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8441] mixin containing template functions causes compiler errors
http://d.puremagic.com/issues/show_bug.cgi?id=8441 --- Comment #17 from jfanati...@gmx.at 2013-07-12 14:43:48 PDT --- I just finished a new implementation, replacing the template mixin with a string mixin. You can find it here: https://github.com/phobos-x/phobosx/blob/master/source/phobosx/signal.d All unittests pass, you don't need any patched compiler. I still have to add some more checks and do some polishing, I will also put it in the dub registry. But you and David seem to have an urgent need, so feel free to try it out immediately - Be my pre-alpha Testers :-) Best regards, Robert -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10589] GC.malloc(sz, GC.BlkAttr.APPENDABLE) fails after a certain size
http://d.puremagic.com/issues/show_bug.cgi?id=10589 --- Comment #3 from Rainer Schuetze r.sagita...@gmx.de 2013-07-12 14:59:12 PDT --- Is the memory layout for the APPENDABLE data documented somewhere, or are these just reverse-engineered magic numbers? There is some description in rt/lifetime.d starting around line 200. Nope (I think). Length is carried in the slice, not the block. Block only contains capacity/used info. Sorry, I meant the used info that must be reset. In particular, the magic numbers should be user accessible via manifest constants, or functions, so as to not have to guess/reverse engineer them. The constants are defined privately in lifetime.d as SMALLPAD, MEDPAD and LARGEPAD. I suspect the trailing byte for large arrays is added so that arr[$..$] always points into the same memory block, and not the next one. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10626] New: ICE with ternary operator and vector operation
http://d.puremagic.com/issues/show_bug.cgi?id=10626
Summary: ICE with ternary operator and vector operation
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Keywords: ice
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: nilsboss...@googlemail.com
--- Comment #0 from Nils nilsboss...@googlemail.com 2013-07-12 18:44:07 PDT
---
Fails with v2.064-devel-a0ba3b2.
Works with v2.063.2.
---
cat test.d code
void main()
{
double[2] v;
bool b;
double[2] result = (b ? 1 : -1) * v[];
}
code
dmd -c -o- test.d
---
dmd: arrayop.c:525: virtual void BinExp::buildArrayIdent(OutBuffer*,
Expressions*): Assertion `0' failed.
Aborted (core dumped)
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9400] initializing enum T[n] with a single value changes its type to T
http://d.puremagic.com/issues/show_bug.cgi?id=9400 Nils nilsboss...@googlemail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Nils nilsboss...@googlemail.com 2013-07-12 18:56:42 PDT --- apparently fixed in the meantime -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10626] ICE with vector operation
http://d.puremagic.com/issues/show_bug.cgi?id=10626
Nils nilsboss...@googlemail.com changed:
What|Removed |Added
Summary|ICE with ternary operator |ICE with vector operation
|and vector operation|
--- Comment #1 from Nils nilsboss...@googlemail.com 2013-07-12 19:31:20 PDT
---
Looks like the ternary operator is innocent. Another trigger:
---
cat test2.d code
void main()
{
double[2] v, x;
double[2] r = v[] * x[0];
}
code
dmd -c -o- test2.d
---
dmd: arrayop.c:525: virtual void BinExp::buildArrayIdent(OutBuffer*,
Expressions*): Assertion `0' failed.
Aborted (core dumped)
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
