[Issue 10766] Variant does not accept pointers to incomplete (opaque) types
http://d.puremagic.com/issues/show_bug.cgi?id=10766 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Kenji Hara k.hara...@gmail.com 2013-09-28 23:02:28 PDT --- *** This issue has been marked as a duplicate of issue 10451 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10451] Array of pointers to opaque struct gives forward reference errors.
http://d.puremagic.com/issues/show_bug.cgi?id=10451 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #11 from Kenji Hara k.hara...@gmail.com 2013-09-28 23:03:48 PDT --- https://github.com/D-Programming-Language/dmd/pull/2594 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10451] Array of pointers to opaque struct gives forward reference errors.
http://d.puremagic.com/issues/show_bug.cgi?id=10451 --- Comment #10 from Kenji Hara k.hara...@gmail.com 2013-09-28 23:02:28 PDT --- *** Issue 10766 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 10495] Incorrect initializer required error using lambdas in class with fields with disabled default construction
http://d.puremagic.com/issues/show_bug.cgi?id=10495 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-09-28 23:05:17 PDT --- https://github.com/D-Programming-Language/dmd/pull/2595 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7892] Compiler-generated struct copies can result in errors when ctor is @disable'd
http://d.puremagic.com/issues/show_bug.cgi?id=7892 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #2 from Kenji Hara k.hara...@gmail.com 2013-09-28 23:06:13 PDT --- https://github.com/D-Programming-Language/dmd/pull/2596 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10504] Tuple error: no property 'offsetof' for type 'int'
http://d.puremagic.com/issues/show_bug.cgi?id=10504 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Kenji Hara k.hara...@gmail.com 2013-09-28 23:13:19 PDT --- This is already-fixed issue in git head. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10842] Some integer casts wrongly remove side-effect of the operand.
http://d.puremagic.com/issues/show_bug.cgi?id=10842 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Summary|auto return function not|Some integer casts wrongly |executed depending on how |remove side-effect of the |it's called |operand. --- Comment #4 from Kenji Hara k.hara...@gmail.com 2013-09-28 23:12:47 PDT --- https://github.com/D-Programming-Language/dmd/pull/2597 The problem is in CastExp::toElem, it sometimes remove the side effect of the cast operand. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11138] New: real appender missing
http://d.puremagic.com/issues/show_bug.cgi?id=11138 Summary: real appender missing Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: verylonglogin@gmail.com --- Comment #0 from Denis Shelomovskij verylonglogin@gmail.com 2013-09-29 14:23:28 MSD --- Lets call real an appender which will create the one and only array, i.e. it will not randomly create a copy of array on appending. Such copy is bad as: 1. Almost no use. In 99% appender is used as real appender and the copy is not needed. 2. Performance. It will cause calls of postblits and then destructors on collection of copy array. 3. Needless restriction on element type. One may want to create and array of uncopyable type which non-real appender can't do by definition. Obviously, real appender is uncopyable and don't give safe access to its array until it finished. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10789] Struct destructor erroneously called
http://d.puremagic.com/issues/show_bug.cgi?id=10789 S�nke Ludwig slud...@outerproduct.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #7 from S�nke Ludwig slud...@outerproduct.org 2013-09-29 04:38:40 PDT --- The original test case still fails on DMD HEAD: --- 0018FD74 this() 0 0018FD75 this(this) 1 0018FD74 ~this() 2 0018FD9C ~this() 1 core.exception.AssertError@app(47): Assertion failure --- This is due to the last destructor running on an uninitialized instance (initialized == false). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11139] New: malloc/emplace resulting in memory corruption
http://d.puremagic.com/issues/show_bug.cgi?id=11139
Summary: malloc/emplace resulting in memory corruption
Product: D
Version: D2
Platform: All
OS/Version: Linux
Status: NEW
Severity: blocker
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: pun...@coverify.org
--- Comment #0 from Puneet Goel pun...@coverify.org 2013-09-29 06:42:22 PDT
---
On my linux box I get:
$ rdmd test.d
4000
$ rdmd -version=EMPLACE test.d
4000
Segmentation fault (core dumped)
The code runs fine if I comment out line 19 or line 23 -- both of which are
producing only a side effect.
class Frop { // 01
int[] _var; // 02
int[] var() {// 03
return _var; // 04
}// 05
this() { // 06
this._var.length = 1; // 07
}// 08
} // 09
class Foo {// 10
long[] nodes;// 11
Frop[] frops;// 12
long[] table;// 13
this() { // 14
nodes.length = 12; // 15
frops.length = 1; // 16
frops[0] = new Frop(); // 17
initTable(); // 18
zoo(frops[0].var); // 19
}// 20
void initTable() { // 21
import std.stdio; // 22
writeln(4000); // 23
table.length = 4; // 24
}// 25
void zoo(int[] varset) {}// 26
} // 27
class Bar {// 28
Foo _foo;// 29
this() { // 30
version(EMPLACE) { // 31
import std.conv, core.stdc.stdlib; // 32
enum size_t size = __traits(classInstanceSize, Foo); // 33
// static assert(size is 32); // 64 on x64 // 34
void* tmp = core.stdc.stdlib.malloc(size); // 35
if (!tmp)// 36
throw new Exception(Memory allocation failed); // 37
void[] mem = tmp[0..size]; // 38
_foo = emplace!(Foo)(mem); // 39
} // 40
else { // 41
_foo = new Foo();// 42
} // 43
}// 44
} // 45
void main() { // 46
auto bar = new Bar; // 47
} // 48
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11138] real appender missing
http://d.puremagic.com/issues/show_bug.cgi?id=11138 --- Comment #2 from Denis Shelomovskij verylonglogin@gmail.com 2013-09-29 19:12:23 MSD --- (In reply to comment #1) (In reply to comment #0) 3. Needless restriction on element type. ... Appender supports immutable construction (mostly bug free, AFAIK). I don't think a real appender would do any better than appender could anyways, so this is a non-argument (IMO). Mutability have nothing to do with copyability. Struct with disabled postblits are meant here. And current appender design can't accept them. 2. Performance. It will cause calls of postblits and then destructors on collection of copy array. Technically, the destructors don't need to be called, since the GC will leak them anyways :/ See below about postblits Lets call real an appender which will create the one and only array, i.e. it will not randomly create a copy of array on appending. Such copy is bad as: 1. Almost no use. In 99% appender is used as real appender and the copy is not needed. I've thought about this before. The *only* case this would really change anything, is on structs that have an elaborate CC. Arguably, these things have no business being in a GC managed array, since it never finalizes its elements (and arguably, if you have a CC, you have a destructor). If we ever get a finalizing GC, then things will be different. So, you are talking that GC bug must force us to do bad design? I will accept it only for an iron-WONTFIXed one. One workaround I've though about is that when the type has a CC, Appender could carry an extra ownsArray boolean. If appender must relocate its array, and owns the array, then postblit is not necessary. In the future, if the GC is finalizing, it may also have to re-initialize to T.init, if there is an elaborate destructor. Such flag will not work as Appender API allows safe access to the array so the array can never be owned. Obviously, real appender is uncopyable Appender having ref semantics, there would be absolutely no problem copying it (read: pass by value). Yes. And such ref semantic is not generally needed and just results in needless GC allocation in stuff aimed for performance-critical tasks. I can see the motivation behind this real appender. Another (dis)advantage it has is that it wouldn't be initialize-able from an existing array. This means it would have 100% ownership of its internals, but on the other hand, it also means, it also means it can't extend an exiting array :/ It of course can't initialize from existing array if element isn't copyable. Otherwise it will create its own copy of array. Where is the problem? Also we talk here about very rare usage of the appender which I'd rather ignore just like the case when its content is needed in the middle of appending as non-general. So, at the end of the day, I'm not really sure a real appender would pull its weight compared to the standard appender (IMO). Exactly what I expect for each my proposal. :) So as always I will just create one for my own use. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10789] Struct destructor erroneously called
http://d.puremagic.com/issues/show_bug.cgi?id=10789 --- Comment #8 from Kenji Hara k.hara...@gmail.com 2013-09-29 08:36:03 PDT --- (In reply to comment #7) The original test case still fails on DMD HEAD: --- 0018FD74 this() 0 0018FD75 this(this) 1 0018FD74 ~this() 2 0018FD9C ~this() 1 core.exception.AssertError@app(47): Assertion failure --- This is due to the last destructor running on an uninitialized instance (initialized == false). To me it looks like that the original test case contains a bug. In S.this(this), `initialized` field is incorrectly set to false. It will stop to decrement S.count at the destruction of the copied objects. Therefore the last assertion in main fails because S.count == 1. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11140] Destructor/postblit bug for struct members
http://d.puremagic.com/issues/show_bug.cgi?id=11140 --- Comment #1 from S�nke Ludwig slud...@outerproduct.org 2013-09-29 09:12:33 PDT --- Created an attachment (id=1252) Test case -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11140] New: Destructor/postblit bug for struct members
http://d.puremagic.com/issues/show_bug.cgi?id=11140 Summary: Destructor/postblit bug for struct members Product: D Version: D2 Platform: All OS/Version: All Status: NEW Keywords: wrong-code Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: slud...@outerproduct.org --- Comment #0 from S�nke Ludwig slud...@outerproduct.org 2013-09-29 09:12:04 PDT --- The attached program simulates a simple reference counted struct. Compiled with dmd -unittest both unit tests fail on current DMD HEAD (2.064 dev). This is similar to http://d.puremagic.com/issues/show_bug.cgi?id=10789 but probably has a different root cause. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11140] Destructor/postblit bug for struct members
http://d.puremagic.com/issues/show_bug.cgi?id=11140 S�nke Ludwig slud...@outerproduct.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from S�nke Ludwig slud...@outerproduct.org 2013-09-29 09:18:38 PDT --- Bug in test case - closing. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11141] New: Missing .pdb file with phobos64
http://d.puremagic.com/issues/show_bug.cgi?id=11141 Summary: Missing .pdb file with phobos64 Product: D Version: D2 Platform: x86_64 OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: turkey...@gmail.com --- Comment #0 from Manu turkey...@gmail.com 2013-09-29 09:24:56 PDT --- Link warning occurs: 1phobos64.lib(errno_c.obj) : warning LNK4099: PDB 'vc100.pdb' was not found with 'phobos64.lib(errno_c.obj)' or at 'D:\Projects\sandpit\vc100.pdb'; linking object as if no debug info Warning 4099: http://msdn.microsoft.com/en-us/library/b7whw3f3%28VS.80%29.aspx This is just some annoying spam that can't be turned off. Suggest: include the .pdb with phobos64.lib in lib64/ or disable debug info when building phobos? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10789] Struct destructor erroneously called
http://d.puremagic.com/issues/show_bug.cgi?id=10789 S�nke Ludwig slud...@outerproduct.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #9 from S�nke Ludwig slud...@outerproduct.org 2013-09-29 09:20:09 PDT --- Sorry, you are absolutely right. The initialized = false was supposed to go to the destructor instead to test if the destructor is called twice on the same instance. I'm still seeing a similar issue in my project, but I can't reproduce it with the fixed this(this). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11138] real appender missing
http://d.puremagic.com/issues/show_bug.cgi?id=11138 --- Comment #3 from monarchdo...@gmail.com 2013-09-29 09:41:29 PDT --- (In reply to comment #2) (In reply to comment #1) (In reply to comment #0) 3. Needless restriction on element type. ... Appender supports immutable construction (mostly bug free, AFAIK). I don't think a real appender would do any better than appender could anyways, so this is a non-argument (IMO). Mutability have nothing to do with copyability. Struct with disabled postblits are meant here. And current appender design can't accept them. Right. Sorry. Wait. How do you append something that can't be copied? Is this even relevant? I've thought about this before. The *only* case this would really change anything, is on structs that have an elaborate CC. Arguably, these things have no business being in a GC managed array, since it never finalizes its elements (and arguably, if you have a CC, you have a destructor). If we ever get a finalizing GC, then things will be different. So, you are talking that GC bug must force us to do bad design? I will accept it only for an iron-WONTFIXed one. You have a point. One workaround I've though about is that when the type has a CC, Appender could carry an extra ownsArray boolean. If appender must relocate its array, and owns the array, then postblit is not necessary. In the future, if the GC is finalizing, it may also have to re-initialize to T.init, if there is an elaborate destructor. Such flag will not work as Appender API allows safe access to the array so the array can never be owned. Not really, the appender API is rich enough for appender to know if anybody else has yet accessed the array, either through arr, or via construction. If no one else has a handle on the array, and appender is about to relocate, then it can pretty much do anything it wants. Maybe the word owns is inadequate. The bool would be called arrayHasExternalView. Obviously, real appender is uncopyable Appender having ref semantics, there would be absolutely no problem copying it (read: pass by value). Yes. And such ref semantic is not generally needed and just results in needless GC allocation in stuff aimed for performance-critical tasks. I think appender was mostly to offset how ridiculously slow ~= is. I'm not sure it wasn't design with *absolute* performance in mind. BTW, you might want to know about: http://d.puremagic.com/issues/show_bug.cgi?id=10864 Off topic: I'd like to try to make a push for some templatization in druntime. I thought you might be interested in the project. I'll keep you posted. I can see the motivation behind this real appender. Another (dis)advantage it has is that it wouldn't be initialize-able from an existing array. This means it would have 100% ownership of its internals, but on the other hand, it also means, it also means it can't extend an exiting array :/ It of course can't initialize from existing array if element isn't copyable. Otherwise it will create its own copy of array. Where is the problem? You are creating a copy. Appender can be used to append to an existing array, whith lots of capacity, without relocating it. This can be very useful for say, processing lines in IO, where you are re-using the same buffer for each line. Also we talk here about very rare usage of the appender which I'd rather ignore just like the case when its content is needed in the middle of appending as non-general. Well very rare remains to be proven. Still, I don't think it's that big of a problem if a real appender simply duplicated before allocating: To each their own behavior. You can't get super speed if you aren't willing to give appended total ownership of the passed data. So, at the end of the day, I'm not really sure a real appender would pull its weight compared to the standard appender (IMO). Exactly what I expect for each my proposal. :) So as always I will just create one for my own use. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10451] Array of pointers to opaque struct gives forward reference errors.
http://d.puremagic.com/issues/show_bug.cgi?id=10451 --- Comment #12 from github-bugzi...@puremagic.com 2013-09-29 12:23:40 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/e7d3e97cdaf4653a39f7f9c68a4868ede2c4bb6b fix Issue 10451 - Array of pointers to opaque struct gives forward reference errors. https://github.com/D-Programming-Language/dmd/commit/f2cc07963d2ade375c056b48580d7c638d11f60c Merge pull request #2594 from 9rnsr/fix10451 Issue 10451 - Array of pointers to opaque struct gives forward reference errors. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10451] Array of pointers to opaque struct gives forward reference errors.
http://d.puremagic.com/issues/show_bug.cgi?id=10451 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10864] [REG 2.064][PERFORMANCE] new Safe appender is slower than ~=
http://d.puremagic.com/issues/show_bug.cgi?id=10864 Denis Shelomovskij verylonglogin@gmail.com changed: What|Removed |Added CC||verylonglogin@gmail.com --- Comment #1 from Denis Shelomovskij verylonglogin@gmail.com 2013-09-30 01:39:04 MSD --- We can create a single @trusted `impl*` function and then call it from main one. Then e.g. make a fake call to stuff wich defines @safe-ness to get right attributes. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11139] malloc/emplace resulting in memory corruption
http://d.puremagic.com/issues/show_bug.cgi?id=11139
--- Comment #1 from Puneet Goel pun...@coverify.org 2013-09-29 19:33:05 PDT
---
Another reduced testcase. This one does not have dependency on writeln.
class Frop { // 01
void zoo(int ) { } // 02
} // 03
class Foo {// 04
int[] table; // 05
int[] table2;// 06
Frop frop; // 07
this() { // 08
frop = new Frop(); // 09
table2.length = 1; // 10
table.length = 32; // 11
frop.zoo(0); // 12
}// 13
} // 14
class Bar {// 15
Foo foo; // 16
this() { // 17
version(EMPLACE) { // 18
import std.conv, core.stdc.stdlib; // 19
enum size_t size = __traits(classInstanceSize, Foo); // 20
static assert (size % size_t.sizeof is 0); // 21
void* tmp = core.stdc.stdlib.malloc(size); // 22
if (!tmp)// 23
throw new Exception(Memory allocation failed); // 24
void[] mem = tmp[0..size]; // 25
foo = emplace!(Foo)(mem);// 26
} // 27
else { // 28
foo = new Foo(); // 29
} // 30
}// 31
} // 32
void main() { // 33
auto bar = new Bar; // 34
} // 35
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11142] Wrong error message no size yet for forward reference for opaque struct
http://d.puremagic.com/issues/show_bug.cgi?id=11142 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-09-29 20:04:54 PDT --- https://github.com/D-Programming-Language/dmd/pull/2598 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11142] New: Wrong error message no size yet for forward reference for opaque struct
http://d.puremagic.com/issues/show_bug.cgi?id=11142
Summary: Wrong error message no size yet for forward
reference for opaque struct
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: minor
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2013-09-29 20:01:26 PDT ---
From fail_compilation/fail91.d
struct S;
void main()
{
S* s = new S();
}
Prints:
fail_compilation/fail91.d(13): Error: struct fail91.S unknown size
fail_compilation/fail91.d(13): Error: struct fail91.S no size yet for forward
reference
However, no size yet for forward reference is a wrong message, because opaque
struct size never be calculated during compilation.
So, the code should print:
fail_compilation/fail91.d(13): Error: struct fail91.S unknown size
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10760] compiler drops opDispatch if it contains an error(s)
http://d.puremagic.com/issues/show_bug.cgi?id=10760 Manu turkey...@gmail.com changed: What|Removed |Added CC||turkey...@gmail.com --- Comment #1 from Manu turkey...@gmail.com 2013-09-29 21:19:19 PDT --- This had me scratching my head for a few hours today. Please fix. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11143] New: Error highlighting incorrect
http://d.puremagic.com/issues/show_bug.cgi?id=11143
Summary: Error highlighting incorrect
Product: D
Version: D2
Platform: All
OS/Version: Windows
Status: NEW
Severity: minor
Priority: P2
Component: VisualD
AssignedTo: nob...@puremagic.com
ReportedBy: turkey...@gmail.com
--- Comment #0 from Manu turkey...@gmail.com 2013-09-29 21:37:49 PDT ---
Paste into VS with Visual-D installed.
private template getComponent(char c, alias v)
{
static if(c == 'x')alias getComponent = v.x;
else static if(c == 'y')alias getComponent = v.y;
else static if(c == 'z')alias getComponent = v.z;
else static if(c == 'w')alias getComponent = v.w;
else static if(c == '0')float getComponent = 0;
else static if(c == '1')float getComponent = 1;
else static if(c == '2')float getComponent = 2;
else static assert(false, Invalid swizzle component: ' ~ c ~ ');
}
Note the first '=' underlines red, and then every 'else' that follows.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11143] Error highlighting incorrect
http://d.puremagic.com/issues/show_bug.cgi?id=11143 --- Comment #2 from Manu turkey...@gmail.com 2013-09-29 22:16:04 PDT --- (In reply to comment #1) This seems to be fixed, but a new issue has taken it's place; if there is an error in the opDispatch, or even in it's constraint, it will silently fail and produce the error No property: blah, as if there were no opDispatch at all. Ie, it no longer gives compile errors within opDispatch, and compile errors are useful :) Oops! Bloody bugzilla! Posted on the wrong bug! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8097] opDispatch produces confusing error message when rejected by a template constraint
http://d.puremagic.com/issues/show_bug.cgi?id=8097 --- Comment #1 from Manu turkey...@gmail.com 2013-09-29 22:16:31 PDT --- This seems to be fixed, but a new issue has taken it's place; if there is an error in the opDispatch, or even in it's constraint, it will silently fail and produce the error No property: blah, as if there were no opDispatch at all. Ie, it no longer gives compile errors within opDispatch, and compile errors are useful :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11143] Error highlighting incorrect
http://d.puremagic.com/issues/show_bug.cgi?id=11143 --- Comment #1 from Manu turkey...@gmail.com 2013-09-29 22:15:27 PDT --- This seems to be fixed, but a new issue has taken it's place; if there is an error in the opDispatch, or even in it's constraint, it will silently fail and produce the error No property: blah, as if there were no opDispatch at all. Ie, it no longer gives compile errors within opDispatch, and compile errors are useful :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
