[Issue 5237] writefln doesn't respect Complex.toString
http://d.puremagic.com/issues/show_bug.cgi?id=5237 --- Comment #1 from Don clugd...@yahoo.com.au 2010-11-19 01:25:33 PST --- Partial fix in svn 2183. This fixes the last 3 cases, not the first one. It would be very straightforward to implement the first case, but we need to think if it would really be a sensible design, since we'd be doing atoi(itoa(atoi(original_string))). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5231] BigInt lacks a normal toString()
http://d.puremagic.com/issues/show_bug.cgi?id=5231 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #16 from Don clugd...@yahoo.com.au 2010-11-19 01:27:43 PST --- This is a bug in format. Even the partial fix I made for bug 5237, makes BigInt print correctly, without any change to the BigInt code. *** This issue has been marked as a duplicate of issue 5237 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5237] writefln doesn't respect Complex.toString
http://d.puremagic.com/issues/show_bug.cgi?id=5237 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #2 from Don clugd...@yahoo.com.au 2010-11-19 01:27:43 PST --- *** Issue 5231 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 5237] writefln doesn't respect Complex.toString
http://d.puremagic.com/issues/show_bug.cgi?id=5237 Lars T. Kyllingstad bugzi...@kyllingen.net changed: What|Removed |Added CC||bugzi...@kyllingen.net --- Comment #3 from Lars T. Kyllingstad bugzi...@kyllingen.net 2010-11-19 02:26:47 PST --- (In reply to comment #1) Partial fix in svn 2183. This fixes the last 3 cases, not the first one. It would be very straightforward to implement the first case, but we need to think if it would really be a sensible design, since we'd be doing atoi(itoa(atoi(original_string))). Couln't that be easily solved by storing the full format string in FormatSpec? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5237] writefln doesn't respect Complex.toString
http://d.puremagic.com/issues/show_bug.cgi?id=5237 --- Comment #4 from Don clugd...@yahoo.com.au 2010-11-19 04:19:11 PST --- (In reply to comment #3) (In reply to comment #1) Partial fix in svn 2183. This fixes the last 3 cases, not the first one. It would be very straightforward to implement the first case, but we need to think if it would really be a sensible design, since we'd be doing atoi(itoa(atoi(original_string))). Couln't that be easily solved by storing the full format string in FormatSpec? Probably. My guess is that positional parameters will make it more complicated, but possibly it's really simple. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5237] writefln doesn't respect Complex.toString
http://d.puremagic.com/issues/show_bug.cgi?id=5237 --- Comment #5 from Lars T. Kyllingstad bugzi...@kyllingen.net 2010-11-19 04:32:21 PST --- (In reply to comment #4) My guess is that positional parameters will make it more complicated, but possibly it's really simple. Regarding positional parameters, allow me to restate a point I made in the DIP9 thread on the newsgroup: I think it's best to leave out the '%' from the format string that is sent to toString(). This will facilitate the use of positional parameters, in which the percent is followed by a position specifier which necessarily has to be handled at a higher level than toString(). Example: BigInt i = 456; BigInt j = 123; writefln(%2$s %1$s, i, j); // Prints 123 456 The only thing BigInt.writeTo() needs to see is the part after the '$' character. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5237] writefln doesn't respect Complex.toString
http://d.puremagic.com/issues/show_bug.cgi?id=5237 --- Comment #6 from Lars T. Kyllingstad bugzi...@kyllingen.net 2010-11-19 04:35:04 PST --- (In reply to comment #3) (In reply to comment #1) Partial fix in svn 2183. This fixes the last 3 cases, not the first one. It would be very straightforward to implement the first case, but we need to think if it would really be a sensible design, since we'd be doing atoi(itoa(atoi(original_string))). Couln't that be easily solved by storing the full format string in FormatSpec? One problem is of course when the user passes a non-immutable format string, as in char[] fmt = %s %s.dup; writefln(fmt, 1, 3.14); Then each format specifier has to be dup-ed before being stored in FormatSpec. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5238] PATCH: fix return of uninitialised var in interpret.c
http://d.puremagic.com/issues/show_bug.cgi?id=5238
--- Comment #4 from simon s.d.hamm...@googlemail.com 2010-11-19 06:21:24 PST
---
(In reply to comment #1)
With this patch applied on my system, I still fail to pass
runnable/interpret.d
with -O, but now a few lines later at 2110:
2106 int goodfoo3()
2107 {
2108S[4] w = void; // uninitialized array of structs
2109w[$-2].x = 217; // initialize one member
2110return w[2].x;
2111 }
2112 static assert(goodfoo3()==217);
Simon, did you find this due to a failure with no changes to interpret.d or
with -O added to the set of compilation flags to test?
Neither.
I've build DMD with Visual studio; the vc compiler does a pretty good
job of detected these sorts of bugs in debug builds.
I'll run the rest of the tests when I get home, see if there are any
other gotchas lurking.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2954] [tdpl] Appalling bug in associative arrays (D2 only)
http://d.puremagic.com/issues/show_bug.cgi?id=2954 --- Comment #5 from Don clugd...@yahoo.com.au 2010-11-19 06:36:06 PST --- (In reply to comment #4) The fix still isn't right, as it fails at compile time on line 10. It works for me. Hmm. I think this might also be relying on the patch for bug 5218, which I still have active in my local copy. Sorry about that -- it needs to be included as well. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5231] BigInt lacks a normal toString()
http://d.puremagic.com/issues/show_bug.cgi?id=5231 --- Comment #17 from bearophile_h...@eml.cc 2010-11-19 07:14:29 PST --- (In reply to comment #16) This is a bug in format. Even the partial fix I made for bug 5237, makes BigInt print correctly, without any change to the BigInt code. *** This issue has been marked as a duplicate of issue 5237 *** See also: http://d.puremagic.com/issues/show_bug.cgi?id=4122 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5240] New: Faster std.random.uniform() for [0.0, 1.0) range
http://d.puremagic.com/issues/show_bug.cgi?id=5240
Summary: Faster std.random.uniform() for [0.0, 1.0) range
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 2010-11-19 07:16:51 PST ---
std.random.uniform() is a powerful and flexible function, but some tests show
that it's slow. It also calls nextafter() that is not fast.
A very common use case is the generation of random doubles in the [0.0, 0.1[
range (open on the right). So I suggest to speed up this special case. This
special case is present in the Python standard module random too, it is just
named random().
A way to support it is just to add a uniform() that takes no arguments (and
hopefully it doesn't need to call nextafter() inside):
import std.random: uniform;
void main() {
double d = uniform(); // equivalent to uniform(0.0, 1.0) but faster
}
This function that takes no arguments may also have a name like uniform01()
or random().
Another special case that may be worth supporting is the generation of a random
size_t. This is useful because it avoids using floating point values at all,
and probably minimizes other operations too to generate it, so it may be faster
still than the uniform() with no arguments.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5219] @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219 SHOO zan77...@nifty.com changed: What|Removed |Added CC||zan77...@nifty.com --- Comment #5 from SHOO zan77...@nifty.com 2010-11-19 07:17:10 PST --- I agree this suggestion. This is not only performance but also behavior. When GC runs, it is a very huge cause of trouble to lack in real-time processing. All programs may not work under the abundant resources. There are software that put emphasis on point that should work in limited resource and limited duration like embedded software. There are software that cannot offer performance to be satisfied with if they don't control it by a high-speed period of 1,000Hz like haptic device controlling. There are software to control the medical device that the delay of moment takes the human life. It is fatal to lack in this property. Of course it will be impossible to encode not to use GC at all. In that case, you may move processing to another thread that never use GC. It is not important that a heap is assigned, and it is important that GC does not work. Therefore I prefer @nogc to @noheap. On the other hand, there is a problem of the readability. It does not appear on the code even if I introduced a profile to observe a behavior of the real-time processing. The property is clear if @nogc/@noheap is given to the attribute of the function. It is the best that the thing which wants not to be compiled is not compiled. And I think it to be the information that a compiler can grasp like nothrow. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5241] New: dmd: ABI breakage/regression
http://d.puremagic.com/issues/show_bug.cgi?id=5241 Summary: dmd: ABI breakage/regression Product: D Version: D1 Platform: Other OS/Version: All Status: NEW Severity: regression Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: nfx...@gmail.com --- Comment #0 from nfx...@gmail.com 2010-11-19 08:19:30 PST --- At some point, both dmd and Phobos1 added a new member to TypeInfo_Struct: m_flags. The way dmd handles this causes an ABI breakage: dmd will use the _calculated_ size of the struct to calculate the offset of the name string. After that, dmd _unconditionally_ writes the new m_flags field, and writes it at the same offset where the name string is supposed to start. As a result, TypeInfo names for structs are broken. The first 4 items of typeid(somestruct).toString() will contain garbage. I'm not really sure why after these 4 bytes, the expected string starts. Either I got it wrong, or the backend data segment writer does strange things? The problem doesn't appear if the object.d[i] contains the proper m_align. E.g. compare: http://www.dsource.org/projects/phobos/browser/branches/phobos-1.x/phobos/object.d#L141 http://www.dsource.org/projects/tango/browser/trunk/object.di#L163 (WARNING: BSD LICENSED CODE) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5241] dmd: ABI breakage/regression
http://d.puremagic.com/issues/show_bug.cgi?id=5241 --- Comment #1 from nfx...@gmail.com 2010-11-19 08:20:24 PST --- (In reply to comment #0) At some point, both dmd and Phobos1 added a new member to TypeInfo_Struct: m_flags. Damn, that should be m_align. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4966] Loops and closures break immutable
http://d.puremagic.com/issues/show_bug.cgi?id=4966 Bruno Medeiros bdom.pub+deeb...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bdom.pub+deeb...@gmail.com Resolution||DUPLICATE --- Comment #1 from Bruno Medeiros bdom.pub+deeb...@gmail.com 2010-11-19 08:59:45 PST --- There is not just one variable 'v', there are several instances of variable 'v', each of them created on each iteration of the loop. Each of them is immutable during its lifecycle (and cease to exist after their lifecycle, by definition). The orthogonal solution is: * make each 'v' variable be heap-allocated (have unscoped lifecycle). This is consistent to how variables work in the top scope in functions. I'm starting to reconsider though, if closures should automatically make variables be heap-allocated. Maybe its best to require a keyword/annotation in such referenced variables, and make the code not compile if such keywords is not present. *** This issue has been marked as a duplicate of issue 2043 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly.
http://d.puremagic.com/issues/show_bug.cgi?id=2043 Bruno Medeiros bdom.pub+deeb...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #5 from Bruno Medeiros bdom.pub+deeb...@gmail.com 2010-11-19 08:59:46 PST --- *** Issue 4966 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 5027] Ghost fields for Contract Programming
http://d.puremagic.com/issues/show_bug.cgi?id=5027 Bruno Medeiros bdom.pub+deeb...@gmail.com changed: What|Removed |Added CC||bdom.pub+deeb...@gmail.com --- Comment #1 from Bruno Medeiros bdom.pub+deeb...@gmail.com 2010-11-19 09:36:07 PST --- Or alternatively, have the compiler define a debug/version identifier when compiled in release mode, and then just use conditional compilation. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5193] SList cannot have struct elements that have immutable members.
http://d.puremagic.com/issues/show_bug.cgi?id=5193
chuck chuck.so...@gmail.com changed:
What|Removed |Added
CC||chuck.so...@gmail.com
--- Comment #1 from chuck chuck.so...@gmail.com 2010-11-19 09:35:14 PST ---
WARNING: N00B ALERT! Similar issues with Array and/or SList initializer?
Similar but slightly different:
main.d
import std.container;
void main() {
auto aList = Array!string();
}
Result
$ dmd -run main
/opt/dmd2/bin/../../src/phobos/std/container.d(1536): Error: this for _data
needs to be type Array not type Payload
/opt/dmd2/bin/../../src/phobos/std/container.d(1537): Error: this for _data
needs to be type Array not type Payload
/opt/dmd2/bin/../../src/phobos/std/container.d(1538): Error: this for _data
needs to be type Array not type Payload
Different but slightly similar:
main.d
import std.container;
void main() {
auto s = SList!string(hello);
}
Result
$ dmd -run main
main.d(5): Error: template std.container.SList!(string).SList.__ctor(U) if
(isImplicitlyConvertible!(U,T)) does not match any function template
declaration
main.d(5): Error: template std.container.SList!(string).SList.__ctor(U) if
(isImplicitlyConvertible!(U,T)) cannot deduce template function from argument
types !()(string)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5027] Ghost fields for Contract Programming
http://d.puremagic.com/issues/show_bug.cgi?id=5027 --- Comment #2 from bearophile_h...@eml.cc 2010-11-19 09:45:30 PST --- (In reply to comment #1) Or alternatively, have the compiler define a debug/version identifier when compiled in release mode, and then just use conditional compilation. In that case the compiler can't enforce this constraint: can't be accessed inside static or instance methods of the class/struct/union, The idea is that ghost field may be read/written only inside pre/post-conditions and invariants. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5103] Container Documentation missing syntax
http://d.puremagic.com/issues/show_bug.cgi?id=5103 --- Comment #5 from Nick Treleaven ntrel-pub...@yahoo.co.uk 2010-11-19 09:45:51 PST --- It's defined in docsrc/std.ddoc, but not in phobos/std.ddoc I can confirm that building with docsrc/std.ddoc fixes this bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4122] More handy BigInt.toString()
http://d.puremagic.com/issues/show_bug.cgi?id=4122 --- Comment #1 from bearophile_h...@eml.cc 2010-11-19 10:06:24 PST --- See: http://www.dsource.org/projects/phobos/changeset/2183 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5121] Make std.algorithm.swap weakly pure
http://d.puremagic.com/issues/show_bug.cgi?id=5121 --- Comment #1 from bearophile_h...@eml.cc 2010-11-19 10:05:01 PST --- See: http://www.dsource.org/projects/phobos/changeset/2180 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5240] Faster std.random.uniform() for [0.0, 1.0) range
http://d.puremagic.com/issues/show_bug.cgi?id=5240 --- Comment #1 from bearophile_h...@eml.cc 2010-11-19 12:10:42 PST --- A specialized overload/function like this is useful in Phobos even if it's not faster. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5242] New: self referencing template constraint crashes compiler
http://d.puremagic.com/issues/show_bug.cgi?id=5242
Summary: self referencing template constraint crashes compiler
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: michal.min...@gmail.com
--- Comment #0 from Michal Minich michal.min...@gmail.com 2010-11-19 14:30:59
PST ---
I wanted to restrict template parameter X to allow only derived classes of A.
class A (X : A!(X)) { }
class B : A!(B) { }
void main () {}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5242] self referencing template constraint crashes compiler
http://d.puremagic.com/issues/show_bug.cgi?id=5242
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||ice-on-invalid-code, patch
CC||clugd...@yahoo.com.au
--- Comment #1 from Don clugd...@yahoo.com.au 2010-11-19 14:42:41 PST ---
PATCH: template.c, line 2509
void deduceBaseClassParameters(BaseClass *b,
Scope *sc, Type *tparam, TemplateParameters *parameters, Objects *dedtypes,
Objects *best, int numBaseClassMatches)
{
-TemplateInstance *parti = b-base-parent-isTemplateInstance();
+TemplateInstance *parti = b-base ? b-base-parent-isTemplateInstance()
: NULL;
if (parti)
{
// Make a temporary copy of dedtypes so we don't destroy it
Objects *tmpdedtypes = new Objects();
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5027] Ghost fields for Contract Programming
http://d.puremagic.com/issues/show_bug.cgi?id=5027 --- Comment #3 from Bruno Medeiros bdom.pub+deeb...@gmail.com 2010-11-19 15:11:32 PST --- If instead of: @ghost static int x; you have: debug(contracts) static int x; and contracts is said identifier that is only defined in non-release mode, then the compiler can enforce those constraints equally well: Just compile it in release and see if it compiles without errors or not. It might be a minor drawback in compiling performance (if you need to compile twice), but it is not any less of a drawback on compiler checking power. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2095] covariance w/o typechecks = bugs
http://d.puremagic.com/issues/show_bug.cgi?id=2095 --- Comment #21 from Bruno Medeiros bdom.pub+deeb...@gmail.com 2010-11-19 15:29:24 PST --- (In reply to comment #20) (In reply to comment #19) Classes are not like arrays and pointers. These are supposed to be lightweight data types, it's out of place for D to have that extra runtime data in these lightweight data types (arrays and pointers). It worries me that you suggested this change without even considering an approach based on fixing/improving the (static) type system. A solution based on the type system (plus a bit of syntax) as in C#/Java seems better. But it's probably better to implement it after the current group of features is implemented. Yes, like I mentioned, Steven's solution has some limitations. For example, if you have B[] the best you have is being allowed to cast it to const(A)[]. But that means you wont be able to call mutable methods on the elements of that array, whereas with a wildcard type such as: ? extends A[] you would be able to call mutable methods of A. So this solution is not perfect, but it works with existing concepts in D (it only needs const), whereas we are far away from the point where can add such disrupting and complex features such as wildcard type. (D's type system seems to be struggling already as it is) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2095] covariance w/o typechecks = bugs
http://d.puremagic.com/issues/show_bug.cgi?id=2095 --- Comment #22 from Bruno Medeiros bdom.pub+deeb...@gmail.com 2010-11-19 15:31:03 PST --- Yes, like I mentioned, Steven's solution has some limitations. I meant Stewart (Gordon), not Steven. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5219] @noheap annotation
http://d.puremagic.com/issues/show_bug.cgi?id=5219 Michal Minich michal.min...@gmail.com changed: What|Removed |Added CC||michal.min...@gmail.com --- Comment #6 from Michal Minich michal.min...@gmail.com 2010-11-19 15:39:03 PST --- both @nogc and @noheap are very usefull, and I would like to have them available. @nogc being less strict - allowing for manual memory management. I think that both these attributes should be processed by some other tool. Performance considerations are not usually part of the language, but are common as third party solutions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5243] New: dmd -run potentially removes user files
http://d.puremagic.com/issues/show_bug.cgi?id=5243
Summary: dmd -run potentially removes user files
Product: D
Version: D1 D2
Platform: All
OS/Version: All
Status: NEW
Severity: critical
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: llu...@gmail.com
--- Comment #0 from Leandro Lucarella llu...@gmail.com 2010-11-19 16:09:43
PST ---
See this example:
$ mkdir x
$ echo 'void main() {}' x/test.d
$ echo my very important data that shouldn't be ereased test
$ ls test
test
$ cat test
my very important data that shouldn't be ereased
$ dmd -run x/test.d
$ ls test
ls: cannot access test: No such file or directory
$ cat test
cat: test: No such file or directory
I think this is a very serious bug. It's really unexpected that DMD removes the
test file (I can understand why it happens, but it shouldn't). test.d being in
another directory is just to point how much surprising could be that running a
script in an unrelated directory removes files in the current directory.
If DMD wants to put D in the scripting world, this should be fixed ASAP, as no
scripting language EVER will remove your files unexpectedly.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5244] New: PATCH: fix use of uninitialised variable in toObj.c
http://d.puremagic.com/issues/show_bug.cgi?id=5244 Summary: PATCH: fix use of uninitialised variable in toObj.c Product: D Version: D2 Platform: Other OS/Version: All Status: NEW Severity: minor Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: s.d.hamm...@googlemail.com --- Comment #0 from simon s.d.hamm...@googlemail.com 2010-11-19 16:20:39 PST --- Created an attachment (id=822) PATCH: fix use of uninitialised variable in toObj.c As summary: triggered by test\compilable\header.d, line 135. pretty minor, but the affected codes needs a look at JIC -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5244] PATCH: fix use of uninitialised variable in toObj.c
http://d.puremagic.com/issues/show_bug.cgi?id=5244 Brad Roberts bra...@puremagic.com changed: What|Removed |Added Attachment #822|application/octet-stream|text/plain mime type|| Attachment #822 is|0 |1 patch|| -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4860] Taking delegates to a member function broken if method is also aliased in from a base class
http://d.puremagic.com/issues/show_bug.cgi?id=4860
--- Comment #7 from Don clugd...@yahoo.com.au 2010-11-19 22:16:42 PST ---
That patch was a bit too early in the function. Should be e2ir.c, line 3308.
Still in DelegateExp::toElem().
{
// Get pointer to function out of virtual table
unsigned vindex;
assert(ethis);
ep = el_same(ethis);
ep = el_una(OPind, TYnptr, ep);
vindex = func-vtblIndex;
+if (vindex 0)
+error(Internal compiler error: malformed delegate. See Bugzilla
4860);
// Build *(ep + vindex * 4)
ep = el_bin(OPadd,TYnptr,ep,el_long(TYsize_t, vindex * 4));
ep = el_una(OPind,TYnptr,ep);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
