www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dmd: why not use fully qualified names for types in error messages?

reply Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
eg:
Error: no property 'IF_gray' for type 'ImageFormat'
=>
Error: no property 'IF_gray' for type 'foo.bar.ImageFormat'

and also, why not show where the symbol is defined?

would PR's for that be accepted? is that hard to implement?
Jun 13 2017
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-06-14 06:50, Timothee Cour via Digitalmars-d wrote:
 eg:
 Error: no property 'IF_gray' for type 'ImageFormat'
 =>
 Error: no property 'IF_gray' for type 'foo.bar.ImageFormat'
 
 and also, why not show where the symbol is defined?
 
 would PR's for that be accepted? is that hard to implement?
Technically, for templates, the fully qualified name include all the template arguments. In many (some) cases this will be way too long to print. -- /Jacob Carlborg
Jun 13 2017
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 14 June 2017 at 06:33:26 UTC, Jacob Carlborg wrote:
 On 2017-06-14 06:50, Timothee Cour via Digitalmars-d wrote:
 eg:
 Error: no property 'IF_gray' for type 'ImageFormat'
 =>
 Error: no property 'IF_gray' for type 'foo.bar.ImageFormat'
 
 and also, why not show where the symbol is defined?
 
 would PR's for that be accepted? is that hard to implement?
Technically, for templates, the fully qualified name include all the template arguments. In many (some) cases this will be way too long to print.
Perhaps some simple heuristic of length (> 80 chars?) would suffice? Or perhaps Error: no property 'IF_gray' for type 'ImageFormat' from module 'foo.bar'. One of the most confusing errors to get is
 Error: no property 'IF_gray' for type 'ImageFormat'
when 'ImageFormat ' does have that property but it uses a different 'ImageFormat' (in another module) that doesn't.
Jun 14 2017
parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
http://forum.dlang.org/post/fyzwknqumopldiktiuvj forum.dlang.org

http://forum.dlang.org/post/xpmpakmusudanwuzzezl forum.dlang.org

https://issues.dlang.org/show_bug.cgi?id=9631

On Wed, Jun 14, 2017 at 10:21 AM, Nicholas Wilson via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Wednesday, 14 June 2017 at 06:33:26 UTC, Jacob Carlborg wrote:

 On 2017-06-14 06:50, Timothee Cour via Digitalmars-d wrote:

 eg:
 Error: no property 'IF_gray' for type 'ImageFormat'
 =>
 Error: no property 'IF_gray' for type 'foo.bar.ImageFormat'

 and also, why not show where the symbol is defined?

 would PR's for that be accepted? is that hard to implement?
Technically, for templates, the fully qualified name include all the template arguments. In many (some) cases this will be way too long to print.
Perhaps some simple heuristic of length (> 80 chars?) would suffice? Or perhaps Error: no property 'IF_gray' for type 'ImageFormat' from module 'foo.bar'. One of the most confusing errors to get is
 Error: no property 'IF_gray' for type 'ImageFormat'
when 'ImageFormat ' does have that property but it uses a different 'ImageFormat' (in another module) that doesn't.
Jun 14 2017
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, June 14, 2017 08:33:26 Jacob Carlborg via Digitalmars-d wrote:
 On 2017-06-14 06:50, Timothee Cour via Digitalmars-d wrote:
 eg:
 Error: no property 'IF_gray' for type 'ImageFormat'
 =>
 Error: no property 'IF_gray' for type 'foo.bar.ImageFormat'

 and also, why not show where the symbol is defined?

 would PR's for that be accepted? is that hard to implement?
Technically, for templates, the fully qualified name include all the template arguments. In many (some) cases this will be way too long to print.
It's also frequently something that you wouldn't want to read even if it were shorter. And having the fully qualified names in the error messages would tend to make them harder to read in many cases when you're not dealing with nasty, long templates. Likely, the best solution is for the compiler to do what it does now in the typical case but to be more specific when needed for clarity (e.g. when dealing with multiple types with the same name or with overloads). But the examples that we sometimes get now where the same name is listed multiple times, and it's actually different symbols from different modules with the same name are definitely the sort of thing that indicates that we need to improve how we handle qualifying names in error messages. - Jonathan M Davis
Jun 14 2017