www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bug tracker best practices

reply Regan Heath <regan netmail.co.nz> writes:
Hi all,

I'm a little out of practice with reporting bugs so I just wanted to check I
was doing the right things.  First I managed to change my email associated with
my account on the bug tracker (old account was old work account that I no
longer have access to), yay me!

Next I logged in and looked for a bug report on the same topic... I think issue
463 is closely related though coming from another angle.  What do people here
reckon?

Here is my bug test case:

[bug001.d]
import std.random;
void main() { index++; }

Error reported on compile is:
"C:\D\src\tmp\bug001.d: module bug001 std.random.index is private"

Notes:
0 - Obviously this occurs because there is no local 'index' variable. This was
a typo in the original code.

1 - There is no line number in the error message.  This occurred inside a small
piece of code so it was easy-ish to find, imagine a larger block of code!

2 - std.random.index is private so it's not likely I am actually trying to
modify it.  I think I should get the error:
"C:\D\src\tmp\bug001.d(2): Error: undefined identifier index"
instead.

Regan
Jun 25 2007
parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Regan Heath skrev:


 Here is my bug test case:
 
 [bug001.d]
 import std.random;
 void main() { index++; }
 
 Error reported on compile is:
 "C:\D\src\tmp\bug001.d: module bug001 std.random.index is private"


[snip]


 2 - std.random.index is private so it's not likely I am actually trying to
modify it.  I think I should get the error:
 "C:\D\src\tmp\bug001.d(2): Error: undefined identifier index"
 instead.


Compiler error messages are a tricky business. What if you were actually 
trying to refer to a private identifier in another module. Wouldn't it 
be helpful to be told that a protection attribute prevented the access 
instead of an unhelpful "undefined identifier"? I believe the best 
(only?) approach to compiler diagnostic messages is for the compiler to 
tell, as descriptively as possible and from its own perspective, why 
something failed. Not trying to second-guess the users intentions.

More serious is that the following altered program compiles without error:

import std.random;
void main() { std.random.index++; }

/Oskar
Jun 25 2007
next sibling parent Regan Heath <regan netmail.co.nz> writes:
Oskar Linde Wrote:

 Regan Heath skrev:
 

 Here is my bug test case:
 
 [bug001.d]
 import std.random;
 void main() { index++; }
 
 Error reported on compile is:
 "C:\D\src\tmp\bug001.d: module bug001 std.random.index is private"


 
 [snip]
 

 2 - std.random.index is private so it's not likely I am actually trying to
modify it.  I think I should get the error:
 "C:\D\src\tmp\bug001.d(2): Error: undefined identifier index"
 instead.


 
 Compiler error messages are a tricky business. What if you were actually 
 trying to refer to a private identifier in another module. Wouldn't it 
 be helpful to be told that a protection attribute prevented the access 
 instead of an unhelpful "undefined identifier"? 


There is that... at the very least it needs a line number in the error as it
can be difficult to find otherwise.


 I believe the best 
 (only?) approach to compiler diagnostic messages is for the compiler to 
 tell, as descriptively as possible and from its own perspective, why 
 something failed. Not trying to second-guess the users intentions.
 
 More serious is that the following altered program compiles without error:
 
 import std.random;
 void main() { std.random.index++; }


That's not good.

Regan
Jun 26 2007
prev sibling next sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Mon, 25 Jun 2007 16:37:25 +0200, Oskar Linde wrote:
 

 More serious is that the following altered program compiles without error:
 
 import std.random;
 void main() { std.random.index++; }


What really annoys me about this oft reported bug is that Walter is still
silent as to whether he regards it as a bug or not. At this stage all I'd
like is either "No that is not a bug because <whatever>..." or "Yes it is a
bug and its on my TODO list".

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
26/06/2007 6:30:56 PM
Jun 26 2007
parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Derek Parnell" <derek nomail.afraid.org> wrote in message 
news:1uh6rpcdf3j1o.10ejke9tjk8w1$.dlg 40tude.net...

 On Mon, 25 Jun 2007 16:37:25 +0200, Oskar Linde wrote:


 More serious is that the following altered program compiles without 
 error:

 import std.random;
 void main() { std.random.index++; }


 What really annoys me about this oft reported bug is that Walter is still
 silent as to whether he regards it as a bug or not. At this stage all I'd
 like is either "No that is not a bug because <whatever>..." or "Yes it is 
 a
 bug and its on my TODO list".


What possible excuse is there for thinking this isn't a bug?

Stewart.
Jun 26 2007
parent Derek Parnell <derek psych.ward> writes:
On Tue, 26 Jun 2007 12:53:48 +0100, Stewart Gordon wrote:


 "Derek Parnell" <derek nomail.afraid.org> wrote in message 
 news:1uh6rpcdf3j1o.10ejke9tjk8w1$.dlg 40tude.net...

 On Mon, 25 Jun 2007 16:37:25 +0200, Oskar Linde wrote:


 More serious is that the following altered program compiles without 
 error:

 import std.random;
 void main() { std.random.index++; }


 What really annoys me about this oft reported bug is that Walter is still
 silent as to whether he regards it as a bug or not. At this stage all I'd
 like is either "No that is not a bug because <whatever>..." or "Yes it is 
 a
 bug and its on my TODO list".


 
 What possible excuse is there for thinking this isn't a bug?


None that I can think of, but I was not trying to second-guess Walter's
Theory of Good Programming Practice, because I've done that in the past and
discovered that Walter and I have sharply different opinions about that
subject. <G>

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
Jun 26 2007
prev sibling parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Oskar Linde" <oskar.lindeREM OVEgmail.com> wrote in message
news:f5ojv9$13sj$1 digitalmars.com...
<snip>

 2 - std.random.index is private so it's not likely I am actually trying
 to modify it.  I think I should get the error:
 "C:\D\src\tmp\bug001.d(2): Error: undefined identifier index"
 instead.


 Compiler error messages are a tricky business. What if you were actually
 trying to refer to a private identifier in another module.


Debatable indeed.  But my thought is: if it's another module, why should you 
be aware that this private identifier exists?

If an identifier is declared as private, it is strictly part of the module's 
internal workings.  Its creator never intended it to be _seen_ outside of 
the module, let alone accessed.  Would you expect an error to this effect on 
using a name that matches that of a local variable in some obscure function?


 Wouldn't it be helpful to be told that a protection attribute prevented
 the access instead of an unhelpful "undefined identifier"?


Instead?  If it didn't prevent the access, you'd be able to tinker 
arbitrarily with a module's internal workings.


 I believe the best (only?) approach to compiler diagnostic messages is for
 the compiler to tell, as descriptively as possible and from its own
 perspective, why something failed. Not trying to second-guess the users
 intentions.


AISI, what the compiler is actually doing is third-guessing the user's 
intention.

But you could ask what's best.  There are three distinct possibilities:
(a) it isn't in any imported module
(b) it's in one imported module
(c) something private by that name exists in more than one imported module

If (a), then there's obviously only one option.
If (b), there's a slim chance that the coder misread the code of an imported 
module by missing the word "private", but how likely is this?  So maybe it 
makes a bit of sense to point this out, just in case.  But it can also be 
confusing.
If (c), what should happen?  It doesn't make sense to single out one of the 
modules to mention it in, but to list them all would clutter the error 
message.  Nor does it make sense to complain that the identifiers conflict 
if they're private.


 More serious is that the following altered program compiles without error:

 import std.random;
 void main() { std.random.index++; }


http://d.puremagic.com/issues/show_bug.cgi?id=257

Stewart.
Jun 26 2007
next sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Stewart Gordon skrev:

 "Oskar Linde" <oskar.lindeREM OVEgmail.com> wrote in message
 news:f5ojv9$13sj$1 digitalmars.com...
 <snip>

 2 - std.random.index is private so it's not likely I am actually trying
 to modify it.  I think I should get the error:
 "C:\D\src\tmp\bug001.d(2): Error: undefined identifier index"
 instead.


 Compiler error messages are a tricky business. What if you were actually
 trying to refer to a private identifier in another module.


 
 Debatable indeed.  But my thought is: if it's another module, why should 
 you be aware that this private identifier exists?


Maybe you are developing both modules in parallel.


 If an identifier is declared as private, it is strictly part of the 
 module's internal workings.  Its creator never intended it to be _seen_ 
 outside of the module, let alone accessed. 


Unless the creator and the one requesting access are the same person. Or 
maybe a module's api changed making something that used to be public 
private. The current error message is certainly helpful in those cases 
(if it only contained line numbers of course).



 Wouldn't it be helpful to be told that a protection attribute prevented
 the access instead of an unhelpful "undefined identifier"?


 
 Instead?  If it didn't prevent the access, you'd be able to tinker 
 arbitrarily with a module's internal workings.


Huh? You must have misunderstood me. The error message text doesn't 
prevent or allow anything. Instead refers to an hypothetical alternative 
wording.


 I believe the best (only?) approach to compiler diagnostic messages is 
 for
 the compiler to tell, as descriptively as possible and from its own
 perspective, why something failed. Not trying to second-guess the users
 intentions.


 
 AISI, what the compiler is actually doing is third-guessing the user's 
 intention.
 
 But you could ask what's best.  There are three distinct possibilities:
 (a) it isn't in any imported module
 (b) it's in one imported module
 (c) something private by that name exists in more than one imported module
 
 If (a), then there's obviously only one option.
 If (b), there's a slim chance that the coder misread the code of an 
 imported module by missing the word "private", but how likely is this?  
 So maybe it makes a bit of sense to point this out, just in case.  But 
 it can also be confusing.


This is the case discussed above and the optimal message may be 
something along the lines of "undefined identifier 'index', however a 
private identifier is matched in module std.random".


 If (c), what should happen?  It doesn't make sense to single out one of 
 the modules to mention it in, but to list them all would clutter the 
 error message.  Nor does it make sense to complain that the identifiers 
 conflict if they're private.


You have a point, although I don't see much wrong in listing all 
conflicting symbols. In fact, I remember being confused once when typing 
something like:

pow(1.0,-1);

expecting it to call the (real, int) overload and being told:

function std.math.pow called with argument types:
         (double,int)
matches both:
         std.math.pow(real,uint)
and:
         std.math.pow(real,real)

But the overload I wanted (real, int) isn't even mentioned. IMO, the 
best behavior would be for the compiler to list all conflicting overloads.


 More serious is that the following altered program compiles without 
 error:

 import std.random;
 void main() { std.random.index++; }


 
 http://d.puremagic.com/issues/show_bug.cgi?id=257


Another serious (and confusing) one:

m1.d:
void foo(int x) {}

m2.d:
private foo(double x) {}

main.d:
import m1,m2;
void main() { foo(1); }

Yields:

main.d:2: Error: m1.foo at m1.d:1 conflicts with m2.foo at m2.d:1

This one means that adding a private function to a module may break code 
in other modules.

/Oskar
Jun 26 2007
parent "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Oskar Linde" <oskar.lindeREM OVEgmail.com> wrote in message 
news:f5rarh$2a82$1 digitalmars.com...

 Stewart Gordon skrev:


<snip>

 If an identifier is declared as private, it is strictly part of the 
 module's internal workings.  Its creator never intended it to be _seen_ 
 outside of the module, let alone accessed.


 Unless the creator and the one requesting access are the same person. Or 
 maybe a module's api changed making something that used to be public 
 private. The current error message is certainly helpful in those cases (if 
 it only contained line numbers of course).


Yes, you have a point there.  But if it's an API change, it probably ought 
to start off deprecated.  It's a shame that D doesn't support 'deprecatedly 
public', though you should be able to improvise with an alias.


 Wouldn't it be helpful to be told that a protection attribute prevented
 the access instead of an unhelpful "undefined identifier"?


 Instead?  If it didn't prevent the access, you'd be able to tinker 
 arbitrarily with a module's internal workings.


 Huh? You must have misunderstood me. The error message text doesn't 
 prevent or allow anything. Instead refers to an hypothetical alternative 
 wording.


Oops....

<snip>

 You have a point, although I don't see much wrong in listing all 
 conflicting symbols. In fact, I remember being confused once when typing 
 something like:

 pow(1.0,-1);

 expecting it to call the (real, int) overload and being told:

 function std.math.pow called with argument types:
         (double,int)
 matches both:
         std.math.pow(real,uint)
 and:
         std.math.pow(real,real)

 But the overload I wanted (real, int) isn't even mentioned. IMO, the best 
 behavior would be for the compiler to list all conflicting overloads.


Yes, that's a case where we do want it to list them all.

<snip>

 Another serious (and confusing) one:

 m1.d:
 void foo(int x) {}

 m2.d:
 private foo(double x) {}

 main.d:
 import m1,m2;
 void main() { foo(1); }

 Yields:

 main.d:2: Error: m1.foo at m1.d:1 conflicts with m2.foo at m2.d:1


<snip>

That's one I found reported, albeit in relation to a particular identifier 
in Phobos.  I changed the summary line to be more generic:
http://d.puremagic.com/issues/show_bug.cgi?id=1238

Stewart.
Jun 26 2007
prev sibling parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stewart Gordon schrieb am 2007-06-26:

 "Oskar Linde" <oskar.lindeREM OVEgmail.com> wrote in message
 news:f5ojv9$13sj$1 digitalmars.com...
<snip>

 2 - std.random.index is private so it's not likely I am actually trying
 to modify it.  I think I should get the error:
 "C:\D\src\tmp\bug001.d(2): Error: undefined identifier index"
 instead.


 Compiler error messages are a tricky business. What if you were actually
 trying to refer to a private identifier in another module.


 Debatable indeed.  But my thought is: if it's another module, why should you 
 be aware that this private identifier exists?

 If an identifier is declared as private, it is strictly part of the module's 
 internal workings.  Its creator never intended it to be _seen_ outside of 
 the module, let alone accessed.


This might be what you expect, but in D "private" is always visable but
not accessable outside of the modle it was defined in.

Yes, this behaviour might be unexpected for many but has been so for a long
time.

Thomas


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

iQIVAwUBRoIt+rZlboUnBhRKAQLZVhAA65ko7RSG1sG3ETptnBDeZ3RaApgCOu4x
8TRweTMNKiyNe2Qz3vHTxygJkS9ZesJwcO8T1mKQZ9nt80rUi9xfQl2gnKf5zS+Y
+EPLbQpQScmVcrUgUcq5MhmhLGeWZKJKTLmRlWD6DeyroyS9eLio41TAS03t32bh
rFghzJ+JPY6L0qJilQ4NPrTqPtWT+4Bi8F7mD23ZVhQf9yU6qaRq4Rf7sTSACMij
FHVPS30C/mACkNDlccfPbQuhns2H5HMBkWihIqTFw2QUyrC74pUJn51D1SRojmQr
KcdTgMtqii26ahqbTJTzAwdMS7rapKKhiI/Rxpxyf/njrLHrw+uArS9sb7BNwJV9
5dtSiOGca85xitoTxmMVaVasvACWtgyGZ78H6kehLS50BlHrch5P6qxh9UPKNE7H
3NXoifsHpg463cPzZFqllcgzbPUI8nVmFCFgOsab3A3hI6FwdUIfMKsAQn8v/vP5
ozx7xHLjwhFP/fcnwzZqXDKnYm8A4cErJMs9SytwQu7rpRnq0zwcUwyOm2wEMtUA
qZuMI0bRqY1uL5h4owNCyKg+q7LfCsITdsArpsXLVNxz2rmugvXvMS+cP2B8GsLn
lFwtDFOJ0XZ3iDF6+E0p4GiX/3R3HIxU2aKEdh6Vtg/9BxfYPqIrtgdi4KilBj+w
9PBZcaVqCZY=
=o/q4
-----END PGP SIGNATURE-----
Jun 27 2007