[Issue 2630] ddoc should be able to document unittests
http://d.puremagic.com/issues/show_bug.cgi?id=2630 Andrei Alexandrescu changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|nob...@puremagic.com|bugzi...@digitalmars.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5455] ICE(cgcod.c): Optimization (register allocation?) regression in DMD 1.065
http://d.puremagic.com/issues/show_bug.cgi?id=5455 --- Comment #4 from Don 2011-01-24 14:03:21 PST --- The regression was introduced in git revision 0eb915bf22045b3c34f23e63859bf8361b2d5a7a, 2010-10-24 with the helpful commit comment "more 64 bit stuff". That commit was TYint-> TYsizet changes, so it shouldn't have had any effect at all on the generated code for 32 bits. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5481] Support deprecated("message")
http://d.puremagic.com/issues/show_bug.cgi?id=5481
Jonathan M Davis changed:
What|Removed |Added
CC||jmdavisp...@gmx.com
--- Comment #1 from Jonathan M Davis 2011-01-24 08:09:34
PST ---
A related feature would be to be able to have "soft" vs "hard" deprecation, so
that you can mark a symbol as scheduled for deprecation (so, the programmer is
notified like you get with the pragma messages now - though preferably with
something more like what's being suggested here with deprecated) without fully
deprecating it yet. Then you make it full deprecated and -d becomes required
for compilation to succeed (in addition to giving the programmer the message
about what they should be using instead).
Right now, the best we have is the ill-suited pragma messages for indicating
"scheduled for deprecation." And then we're stuck changing them (to indicate
deprecated rather than scheduled for deprecation) and keeping them around on
top of marking something as deprecated so that they'll tell the programmer what
to use now that the symbol in question has been deprecated.
So, I'm not sure what the best syntax is, but doing something like adding an
enum indicating Soft or Hard deprecation which could be fed to deprecated along
with the message would be ideal. e.g.
deprecated("Use newStuff instead.", Soft);
deprecated("Use newStuff instead.", Hard);
Presumably, Hard would be the default, as that how deprecated currently works.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5481] New: Support deprecated("message")
http://d.puremagic.com/issues/show_bug.cgi?id=5481
Summary: Support deprecated("message")
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don 2011-01-24 07:59:52 PST ---
A simple feature which has been discussed in the ng but not yet added to
Bugzilla:
An optional message should be added to 'deprecated'. This can provide a
detailed explanation of how the code should be updated (replacing the ugly
usage of pragma(msg), which doesn't even work properly).
deprecated("Use newStuff instead.")
{
int oldStuff;
}
int newstuff;
void main()
{
oldStuff = 6;
}
---> Should give:
bug.d(15): oldStuff is deprecated
Use newStuff instead.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5480] New: TDPL exception chaining not implemented (except on Windows)
http://d.puremagic.com/issues/show_bug.cgi?id=5480 Summary: TDPL exception chaining not implemented (except on Windows) Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: clugd...@yahoo.com.au --- Comment #0 from Don 2011-01-24 07:50:38 PST --- My Windows exception chaining code (in rt/deh.d) needs to be ported to other systems. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5354] formatValue: range templates introduce 3 bugs related to class & struct cases
http://d.puremagic.com/issues/show_bug.cgi?id=5354 --- Comment #17 from Max Samukha 2011-01-24 06:27:00 PST --- (In reply to comment #16) > > It is an obvious choice: programmers explicitely define toString (later, > writeTo) precisely for that ;-) > > Denis I agree that user-specified toString should take precedence over the ranges. What I wanted to point out is that static checks for classes are not enough. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4890] GC.collect() deadlocks multithreaded program.
http://d.puremagic.com/issues/show_bug.cgi?id=4890 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #4 from Steven Schveighoffer 2011-01-24 06:03:14 PST --- (In reply to comment #3) > I've also stumbled over the racing condition in thread_processGCMarks() where > a > thread was already added to the global thread list but didn't had it's m_tls > set yet. It seems fine to test for m_tls being null at that specific place. That's something that I recently added. Sean, can you confirm that if a thread's m_tls is not yet set, then it's actual TLS can not have been used yet? It seems reasonable to check the tls block for null at that point. (will have to start using github soon...) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5354] formatValue: range templates introduce 3 bugs related to class & struct cases
http://d.puremagic.com/issues/show_bug.cgi?id=5354 --- Comment #16 from Denis Derman 2011-01-24 05:40:24 PST --- (In reply to comment #15) > This wouldn't work because the dynamic type of the object being formatted can > differ from the static type the template was instantiated with. Even if the > compile-time check won't detect the overriden toString, we would still need to > perform the check at run-time. The easiest way is to compare the address of > the > passed-in object's toString to that of Object.toString. Unfortunately that > won't work for objects coming from DLLs since they have distinct > Object.toString functions. So the correct way is to do proper lookup by name > via run-time reflection. We may find a way to tell apart, for classes, builtin from toString from custom one. If we cannot, then in doubt toString must have precedence for classes. Note there is another bug: one currently cannot implement a range interface on a class that defines toString (because formatValue template constraints are not mutually exclusive). In any case, struct toString must have precedence. It is an obvious choice: programmers explicitely define toString (later, writeTo) precisely for that ;-) Denis -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5354] formatValue: range templates introduce 3 bugs related to class & struct cases
http://d.puremagic.com/issues/show_bug.cgi?id=5354
Max Samukha changed:
What|Removed |Added
CC||samu...@voliacable.com
--- Comment #15 from Max Samukha 2011-01-24 05:23:19
PST ---
(In reply to comment #14)
>
> bool hasCustomToStringHelper(T)() {
> foreach(type; TypeTuple!(T,TransitiveBaseTypeTuple!T) ) {
> if(is(Unqual!type == Object))
> return false;
> foreach(member;__traits(derivedMembers,type)) {
> if(member == "toString")
> return true;
> }
> }
> return false;
> }
> template hasCustomToString(T) {
> static if( __traits(hasMember,T,"toString") ) {
> static if( is(T==class) ) {
> enum hasCustomToString = hasCustomToStringHelper!T;
> } else { // structs, etc
> enum hasCustomToString = true;
> }
> } else {
> enum hasCustomToString = false;
> }
> }
This wouldn't work because the dynamic type of the object being formatted can
differ from the static type the template was instantiated with. Even if the
compile-time check won't detect the overriden toString, we would still need to
perform the check at run-time. The easiest way is to compare the address of the
passed-in object's toString to that of Object.toString. Unfortunately that
won't work for objects coming from DLLs since they have distinct
Object.toString functions. So the correct way is to do proper lookup by name
via run-time reflection.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4307] spawn()'ed thread doesn't terminate
http://d.puremagic.com/issues/show_bug.cgi?id=4307 Jonathan M Davis changed: What|Removed |Added Component|DMD |druntime OS/Version|Windows |All Severity|normal |major --- Comment #10 from Jonathan M Davis 2011-01-24 03:19:32 PST --- Actually, I'm going to bump this up to major, since spawn is pretty much useless in my experience without this being fixed. Also, I'm 99.99% sure it's a druntime bug, so I'm moving it to druntime (which I probably would have done before had I noticed that it was marked as dmd). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5076] std.algorithm.sorted / schwartzSorted
http://d.puremagic.com/issues/show_bug.cgi?id=5076 --- Comment #10 from bearophile_h...@eml.cc 2011-01-24 03:04:20 PST --- In Python sort() is in-place. To help programmers remember this, sort() returns None (like void in D): >>> a = [10, 30, 5] >>> sorted(a) [5, 10, 30] >>> a [10, 30, 5] >>> a.sort() >>> a [5, 10, 30] But in DMD 2.051 std.algorithm.sort() returns the sequence sorted in-place. Once a sorted/schwartzSorted are present, I suggest to let std.algorithm.sort() return void, as in Python. sorted/schwartzSorted may be tagged with @nodiscard from bug 5464 to further help programmers remember their semantics. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
