www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Some stuff to add to DStress

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
I've got together a bunch of testcases for bugs that have been known for 
a while but which don't seem to have testcases in DStress at the moment 
(unless I've missed them).

The test code itself is DStress-ready, but I haven't gone through with 
module names, DStress comments or making sure that the names are 
suitable.  Each one has a comment to explain the testcase.

There's more to come before all of my bug list is covered, but this 
should keep you going for a while.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++  a->--- UB  P+ L E  W++  N+++ o K-  w++  O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Dec 12 2005
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stewart Gordon schrieb am 2005-12-12:

 I've got together a bunch of testcases for bugs that have been known for 
 a while but which don't seem to have testcases in DStress at the moment 
 (unless I've missed them).

 The test code itself is DStress-ready, but I haven't gone through with 
 module names, DStress comments or making sure that the names are 
 suitable.  Each one has a comment to explain the testcase.

 There's more to come before all of my bug list is covered, but this 
 should keep you going for a while.

 Stewart.


Thanks for the test cases Stewart. Here are the first additions to
Dstress:

array_chain:
http://dstress.kuehne.cn/run/o/opSlice_02_A.d
http://dstress.kuehne.cn/run/o/opSlice_02_B.d
http://dstress.kuehne.cn/run/o/opSlice_02_C.d

array_ops:
http://dstress.kuehne.cn/run/a/arrayOp_01.d

const_struct:
(known) http://dstress.kuehne.cn/run/const_15.d

in_inherit:
http://dstress.kuehne.cn/run/i/in_out_body_11_A.d
http://dstress.kuehne.cn/run/i/in_out_body_11_B.d
http://dstress.kuehne.cn/run/i/in_out_body_11_C.d
http://dstress.kuehne.cn/run/i/in_out_body_11_D.d
http://dstress.kuehne.cn/run/i/in_out_body_11_E.d
http://dstress.kuehne.cn/run/i/in_out_body_11_F.d
http://dstress.kuehne.cn/run/i/in_out_body_11_G.d
http://dstress.kuehne.cn/run/i/in_out_body_11_H.d

Why is in_inherit_5.d in your view undefined?

no_return:
http://dstress.kuehne.cn/nocompile/r/return_08_A.d
http://dstress.kuehne.cn/nocompile/r/return_08_B.d
http://dstress.kuehne.cn/nocompile/r/return_08_C.d

Why is that restriction in place? As a consequence
the following code is illegal:

| int func(){
|     throw new Exception("not yet implemented");
| }

out_inherit:
http://dstress.kuehne.cn/run/in_out_body_10_A.d
http://dstress.kuehne.cn/norun/in_out_body_10_B.d
http://dstress.kuehne.cn/norun/in_out_body_10_C.d

wchar:
The test case are buggy - do a diff between them to see what I mean.
I'm not sure if only "\uD808\uDF45"w or 
"\uD808\uDF45"c, "\uD808\uDF45"w and "\uD808\uDF45"d should be legal.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFDpVen3w+/yD4P9tIRAkw+AKCpyXPLVql9WUP/f0v4h1t1dJgsFwCdEX+H
kp5HJD0jUWHxP8ox+cHoEhI=
=bB9Z
-----END PGP SIGNATURE-----
Dec 18 2005
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Thomas Kuehne wrote:
<snip>

 const_struct:
 (known) http://dstress.kuehne.cn/run/const_15.d


Oh yes.  I must've missed that that one tests this issue as well.


 in_inherit:
 http://dstress.kuehne.cn/run/i/in_out_body_11_A.d
 http://dstress.kuehne.cn/run/i/in_out_body_11_B.d
 http://dstress.kuehne.cn/run/i/in_out_body_11_C.d
 http://dstress.kuehne.cn/run/i/in_out_body_11_D.d
 http://dstress.kuehne.cn/run/i/in_out_body_11_E.d
 http://dstress.kuehne.cn/run/i/in_out_body_11_F.d
 http://dstress.kuehne.cn/run/i/in_out_body_11_G.d
 http://dstress.kuehne.cn/run/i/in_out_body_11_H.d
 
 Why is in_inherit_5.d in your view undefined?


http://www.digitalmars.com/d/dbc.html

"If a function in a derived class overrides a function in its super 
class, then only one of the in contracts of the base functions must be 
satisified [sic] Overriding functions then becomes a process of 
loosening the in contracts."

Good question.  The way I saw it, not specifying an in contract when 
overriding could be seen either as:
- wanting anything to be allowed (such a function implicitly has an 
empty in contract)
- wanting no change from the inherited in contract (such a function has 
no in contract at all, so it cannot be "one of the in contracts" 
mentioned above)


 no_return:
 http://dstress.kuehne.cn/nocompile/r/return_08_A.d
 http://dstress.kuehne.cn/nocompile/r/return_08_B.d
 http://dstress.kuehne.cn/nocompile/r/return_08_C.d
 
 Why is that restriction in place?


Because a non-void function that doesn't return at all is obviously a 
coding error.


 As a consequence the following code is illegal:
 
 | int func(){
 |     throw new Exception("not yet implemented");
 | }


Yes, that's cropped up once or twice.  The spec could be changed so that 
a throw is allowed instead of a return.  But since in many cases it'll 
mean that the normal program logic fails to return, maybe it should be 
changed to

"At least one return statement is required if the function specifies a 
return type that is not void and does not unconditionally throw an 
exception or assert(false)."

or something....


 out_inherit:
 http://dstress.kuehne.cn/run/in_out_body_10_A.d
 http://dstress.kuehne.cn/norun/in_out_body_10_B.d
 http://dstress.kuehne.cn/norun/in_out_body_10_C.d
 
 wchar:
 The test case are buggy - do a diff between them to see what I mean.


I don't know how this happened.  As you've probably guessed, the types 
of text are supposed to be char[], wchar[] and dchar[] respectively.


 I'm not sure if only "\uD808\uDF45"w or 
 "\uD808\uDF45"c, "\uD808\uDF45"w and "\uD808\uDF45"d should be legal.


AIUI what a string literal may contain is unaffected by what type suffix 
it has.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++  a->--- UB  P+ L E  W++  N+++ o K-  w++  O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Dec 19 2005